@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. -- ALPS DualPoint Touchpad flaky performance https://bugs.launchpad.net/bugs/296610 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
