Right nub not acting right on new 1ghz pandora

[notaz]

Do they act correctly in the input tester when this starts?


Still I think that code just can't start acting different out of the sudden, if there is a bug it's in nub firmware, not kernel.

 

[EvilDragon]

I'll check on a rebirth unit if this happens in both kernels or not.


Would it be a hard thing to code a little tool that displays the data from the input tester somewhere as an overlay on the X11 desktop (or just the coordinates?)


That way I could check live what's going on when accidental double clicks happen.

 

[notaz]

That would need a debug kernel, the coords are not exposed in mouse and mbutton modes.


BTW just ran diff on 2.6 and 3.2 drivers, and they only differ by init sequence and 3.2 has suspend support.

 

[EvilDragon]

Okay, so basically it can only be the init or suspend sequence causing this... hmm.


Is there an easy way to disable suspend for a test?

 

[notaz]

Don't suspend (flick power switch) and that code won't be called. The suspend code doesn't really do anything anyway, just disables the interrupt so that it wont try to talk to nubs while i2c portion of OMAP is turned off during suspend/resume process.


And I don't really think init sequence could be cause of this, I'd guess it's some kind of wear or something. There is so little software control of these things (actually none) so there is simply no code where a bug could be. Only thing that comes to mind is the nub polling interval, but that is exactly the same as in 2.6 kernel.

 

[EvilDragon]

Okay, I usually don't suspend, so that shouldn't be the issue.


It's certainly not wear, as it happens with brand new nubs out of the box.


And I'm sure I read somewhere here on the boards that someone who had a similar issue on a rebirth unit. He made some tests and while kernel 2.6 worked perfect for hours, his nubs acted up with 3.2 within minutes.


I'll try to reproduce this as good as possible and will also check whether the nub only acts up as mousebutton or whether it also does this as joystick.

 

[dgame]

I have been playing N64 on a 1GHz SZ 1.51/3.2 and it happens in joystick mode.


This is my third Pandora and the first one to behave like this.


The reset nub script temporarily fixes it in mouse and joystick mode.

 

[notaz]

This is my third Pandora and the first one to behave like this.

So others don't have that problem? Are they on the same firmware?

 

[manic23]

If you get a solution, i would appreciate it if you post it here, as it is really effecting emulators like the N64 emulation, as the right stick is used for the yellow arrow keys. Thanks.

 

[dgame]

This is my third Pandora and the first one to behave like this.

So others don't have that problem? Are they on the same firmware?

They do have the same firmware, though I have been mainly using the 1GHz with 1.51/3.2. I only have the 1GHz with me and can test the others when I return.

 

[EvilDragon]

They do have the same firmware, though I have been mainly using the 1GHz with 1.51/3.2. I only have the 1GHz with me and can test the others when I return.

If you have another unit which has these issues with the 3.2 kernel, be sure to also excessively test it with 2.6 as well.

 

[dgame]

The left nub on my 1Ghz unit may be physically faulty.


I tested a CC unit and it did not exhibit this problem.


I verified the problem on my 1Ghz using the Pandora input-checker.


What happens is the left nub does not register the full range for the "up' direction or Y axis.


The input-tester shows (0,-17) with the left nub pushed all the way up. The right nub works fine.


If I run the rest_nubs.sh script it will register the correct (0,-32) but with use will eventually reduce the Y value to (0,-17).


With normal use the input-tester shows (0,-17) with the left nub pushed all the way up.


At boot and some times during use it will register the correct (0,-32) but will eventually reduce the Y value to (0,-17).


It seems like the left nub is losing calibration or has physical problems.

 

[PowerGod]

I think to have an hardware issue regarding the right nub, I always used it as mouse click, but it's a week that I use it to play "Pew Pew 2" and after different rotation, it seems to have like something stuck inside... seems like glued and I have to press it with more strenght to move it... I tried to rotate it faster than I can, but seems it's becoming more and more "glued" it got stuck in every direction I put it... (it's like having auto-fire in pew pew 2), anyway the left nub doesn't have problems at all, it always goes to the center, and it's soft to move


EDIT: I have a pandora rebirth

 

[ZenphiR]

The functions don't shift to another position within the right nub anymore since I updated my Pandora to Kernel 3.2 / FW 1.52


Thanx for the update

 

[Quipacorn]

I JUST (as in a few minutes ago) received my 1Ghz pandora. The first thing I noticed during the setup was the left nub did not want to register a full push to the right.


Checking with input-tester the right nub likes to go to around 9 when its fully pushed, and with a light touch it sometimes will jump to 32.


So, I basically have the same issue as everyone else on this thread :/


I'm going to play with it for a week or two and see if it fixes itself (though from what I've read, my hopes are low) and then maybe send it in (if no other solution appears).

 

[EvilDragon]

The nub won't work right away correctly after booting.


It autocalibrates while you are using it.


To speed this up, fully move it to each direction multiple times.


After a few seconds, it should move the same speed in all directions.

 

[grydholt]

How does this autocalibrating work? Does it sample for some time and then take the mode (the value that is seen most often) as the calibrated maximum in each direction? Because if it takes the observed maximum value as the calibrated maximum in each direction then it is problematic if you can only obtain the maximum value by a light touch as in Quipacorn's case.