Comment 94 for bug 296610

@Sebastian: you forgot the patch. :)

Basically, there are TWO issues remaining:
A) Identify a definite 9p flag (not a priority)
B) Find out why some packets aren't processed, causing stuck buttons (priority)

I'm thinking aloud now, please comment, Sebastian (or *email* me - would be faster and not clutter this forum):

1) I'm studying the source now. As you say, you detect 9p by 1111 in place of Stick's 1MRL - this is OK for your model, but our model must flag differently... Or it better be! :) Pressing all 3 buttons would make the driver lose sync (think it's 9p when it isn't). Right?

2) Our model flags the same, so I think there must be another bit comprising the flag, we just haven't identified it yet. The HW cannot use only 1MRL as the flag, it would be a huge bug! Causing lost sync even on Windows...

3) Also, cloning TouchPad's buttons from 9p to both devices - as is now - is problematic. It could cause a drift between the driver state and real world anytime. It may pass without issues, but eventually, we'll drift until reset again. Have you tried *not* *updating* Stick buttons using this packet? If "(p[3] & 0xf) == 0xf" really is the 9p flag (or part of it), it means HW isn't in fact telling us about Stick's buttons - so why update them? If there *is* a button change, HW will probably send a separate packet. What do you think?

4) I'll dump all packet types, it might tell us some news. Then, I'll try to identify a complete 9p flag. However, 9p isn't causing the problem with stuck buttons. With DEBUG on, we could see 9p isn't triggered at all while the button gets stuck, so that's a different bug.