This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9025 - Gigabeat's keypad unusable
Attached to Project:
Rockbox
Opened by Clément Pit--Claudel (CFP) - Wednesday, 21 May 2008, 22:52 GMT+1
Last edited by Michael Sevakis (MikeS) - Thursday, 29 May 2008, 23:29 GMT+1
Opened by Clément Pit--Claudel (CFP) - Wednesday, 21 May 2008, 22:52 GMT+1
Last edited by Michael Sevakis (MikeS) - Thursday, 29 May 2008, 23:29 GMT+1
|
DetailsHello,
r17549 and 17559 change gigabeat's handling of button inputs. Installing this new versions causes my gigabeat to turn unusable. I hard-reseted it, tried again, but encountered the same problem. Sometimes pressing a key has an actual effect, but sometimes it considers the key is still being pressed though it's been released, and sometimes it just does not react at all. Furthermore, reverting the firmware to previous versions fixed the problem. Is anybody experiencing the same problem ? Shouldn't these changes just be reverted ? Or am I doing something wrong ? |
This task depends upon
Closed by Michael Sevakis (MikeS)
Thursday, 29 May 2008, 23:29 GMT+1
Reason for closing: Accepted
Additional comments about closing: Mulled it over in IRC and other's felt the patch as-is was the best way to handle it.
Thursday, 29 May 2008, 23:29 GMT+1
Reason for closing: Accepted
Additional comments about closing: Mulled it over in IRC and other's felt the patch as-is was the best way to handle it.
The firmware is actually quite unusable. Reverted to r17548.
CFP
CFP.
FS#9045but I've thought about a bit and so will try to suggest something better.I'm not one really to like adding settings for things but in this case I propose the following addition which will be workable for everyone (so I'll kick it off right here since I'm not inclined to produce a patch atm):
Keypad Sensitivity
Low (default, reads one line per direction [++] works like before)
Medium (same as SVN, reads two lines per direction [+, ++])
High (reads all three lines per direction [ , +, ++)
Setting the sensitivity will only require changing of the master bitmask dynamically to one of three values and no change to the code inside the if(touchpad) clause.
void button_read_device(void)
{
...
touchpad = GPJDAT & touchpad_mask;
if (touchpad)
{
/* Keep direction-desensitization code for center-press */
...
/* Each direction check may now simply bit-test all three lines unconditionally */
...
}
...
}
void set_keypad_sensitivity(int level)
{
static const uint32_t masks[3] =
{
0x10c9, 0x19eb, 0x1fff
};
if ((unsigned)level >= 3)
level = 0; /* Wrong...use default */
touchpad_mask = masks[level];
}
Also, given the choice between the current revision, which some people prefer, but also appears to break many people, and the old revision, which apparently worked for everyone, it seems like an easy decision.
CFP
The change was made because the old version didn't work so well for everyone (it wasn't even my idea) or it would never have been done. The old worked for me but not nearly as well as current SVN which just requires a light touch - the direction would require making sure I always pressed toward the extreme ends or it would miss.
Perhaps just use "Low" and "High" meaning 0x10c9 or 0x19eb and forget about 0x1fff since I have a feeling that's too much for anything and triggers inner directions before the center.
Also, it seems to me that the version I'm currently running (r17500) works better with the touchpad than it used to, though I can't remember when it improved. Looking at the changelog it may have been r17219, since that change seems to be about the correct amount of time ago for the improvement. I can try to test a bit and see if I can track down when it was if you want.
I'll update to latest again and see if similar issues are apparent.
I can bring previous functionality back by default and throw together whatever later so everyone can have the touchpad useable to their liking.
Brett,
FS#9035doesn't in any way sound related to this.