This is a list of all bits in a REAL 9p packet, which remain ON no matter what you do:
alps.c: [0] 11001111 alps.c: [1] 00000000 alps.c: [2] 00000000 alps.c: [3] 00001111 alps.c: [4] 00000000 alps.c: [5] 00000000 alps.c: [6] 00001000 alps.c: [7] 00000000 alps.c: [8] 00000000 This is a list of all bits in a REAL 9p packet which remain OFF no matter what you do: alps.c: [0] 11001111 alps.c: [1] 01111111 alps.c: [2] 00111010 alps.c: [3] 00111111 alps.c: [4] 11111111 alps.c: [5] 11111111 alps.c: [6] 01111000 alps.c: [7] 01111111 alps.c: [8] 01111111 If 9p packet has something which identifies it, it might be possible to find it using these two masks (possibly superimposed). The other possibility is that your current test is correct and it is the "1+2+3 Pad click", which identifies itself as *NOT 9p*. Considering the HW design, I wouldn't be surprised if they didn't expect 3 button Pads while making your model, and now that there *are* 3 buttons, they have to signal (backwards-compatible) that 1+2+3 packet *IS NOT a real 9p*. We'll talk tomorrow, for now read up what I prepared for you this evening! :)) -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
