Comment 105 for bug 296610

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! :))