On Sa, 2009-11-14 at 17:52 +0000, Dave wrote: > Hello Sebastian, I had to give it a rest for a day and a half. I hope to > start coding tomorrow. > > If you don't mind, I'll be working on the vanilla .31 kernel source + > your first 9p extension. It seems the cleanest and I have nice packet > dumping integrated. :)
I believe the latest patchset fixes the locked buttons, and I'd like to see if that is, in fact, true. It does that by keeping both input layer devices in sync, i.e. broadcasting each button bit from the hardware to both devices. So I'm happy about any testing this patch gets :-) > One extra thing I found, which caused desync was an unfinished impl of > 9p. There's a check for 0's at 0x80 bit from byte 2-6. You had a note > there that it's different for 9p (4 and 5 don't have 0's), but the check > was unchanged! Which check exactly? In function process_byte? Note that for 9p packets, there's an extra return statement. If you change the conditions which recognize 9p/6p, you'll have to change that code, too. > When I was experimenting with the 9p flag, I got desync > when using the FIN, but only becase this test reported BAD_DATA to > psmouse. :) I didn't notice it at first, but now it's fixed (testing 0's > for 6p and 9p only in proper places) and I'm going for the 9p flag like > a hungry hound! :) You can see from the 0 & 1 masks I posted which 0x80 > bits remain 0's. The code that determines whether it's 9p or 6p is scattered in two places. That's mainly an artefact of the previous driver implementation which I didn't want to change drastically. I'm a little confused now, in what way do you use FIN to distinguish between packets? > When that's finished, I'm definitely going to implement the state > machine. We agreed the ALPS has only one set of button states and > merging is the obvious easy way to fix it, but I really need independent > behaviour. What do you mean by 'independent behaviour'? I don't see how you want to achieve this. The hardware just doesn't give you the data from what I can tell. Our first priority should be to fix the desyncs associated with the three-button-pressing IMHO. > I believe keeping an internal buttons state and masking > button events from the input layer will provide orthogonal equivalent of > TWO independent mice. >From my experience I now beleive the hardware doesn't give us the actual state of the buttons, but LOGICALOR(touchpad_button,trackpoint_button). In this constellation, we only can lose, because there will always be some corner cases where stuff breaks. YMMV. > As you said, this works only for the CORE pointer, > but in reality, that's exactly how the ALPS is going to be used. You can > see all modern distros removed not only Input configuration from > xorg.conf - everything is dynamic via HAL. I don't see where the core pointer comes in here -- I think all the core pointer does is, again, LOGICALOR(dev,dev2). So if one of your devices has invalid button data, the core pointer's data may be invalid too. Is your goal to be able to disable e.g. the touchpad buttons? I'm a little confused about your intentions. > You are right, games or a proper xorg.conf (as was usual 2 years ago) > would discover that button events are masked and the behaviour wouldn't > be orthogonal, but let's be honest here - merging buttons wouldn't be > either in this situation. What's more, Stick & Pad aren't going to be > used like this. Their HW just doesn't support it, so we can merge or we > can mask - either way it'll fix stuck buttons. I just prefer masking, > because it can emulate 2 mice perfectly (under common X configs). > > Do you agree? What about your latest patches? Did you find something > new? Did you deal with the 9p flag vs. 3-buttons? No, I havent found anything new in that direction. All the second patchset does is keep both input layer devices in sync. I found this necessary to deal with the locked buttons. Maybe you're right and we can 'demux' the two sets of buttons somehow, but I just don't see how at the moment. The second problem, de-syncs at three buttons, is still open (though probably not relevant in practice). Greets :-) -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread! -- 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
