@Kevin (#305) > Are you seeing incorrect readings when using MT, or is your comment just based on the code? It would not be too surprising if > different initialization sequences altered the data format (ala Dolphin's 8-byte vs. 9-byte setting).
Just inspecting the packets traveling through. Some MT reports, with one of the finger close to the edges, were not working. This was most visible when enabling 2-finger scrolling, since this would prevent scrolling if one of the fingers happens to be in the dead zones. Looking at the packets, it seems clear that there's one extra MT slot in each direction (and 16 and 12 are nicer numbers than 15 and 11). > Along similar lines, it would be nice if we could adjust the Rushmore > trackstick sensitivity so that it used the existing V3 > trackstick report code as-is, with no special divisor. My code at https://github.com/emmanuelthome/psmouse-alps does work with the V3 trackstick report code as-is (report by Malte Skoruppa who tested it). I think that the key is probably the weird thing which I called alps_e6_sort_of_setmode there. > E6230 has: > > - touchpad (80mm x 40mm) > - 2 lower buttons > - no middle button :( > > E6430 has: > > - touchpad (80mm x 45mm) > - trackstick > - 3 upper buttons > - 2 lower buttons ok, I stand corrected then. I should have made my point clearer, though. At some point it was thought that E6230/E6430 needed two entirely different init sequences, and needed to be detected based on some yet- to-be-determined magic going beyong E6/E7/EC reports. Not. It's only that trying to talk to the missing trackstick on the E6230 freezes the device, but that can be encompassed by a unified init. > "My reverse-engineering work and merge with bgamari's patches show this. > These are differentiated by querying the 0xc2c8 > register, which is not queried in Kevin's patch." > > Do you feel comfortable making the statement that checking the 0xc2c8 > register on Rushmore will unambiguously indicate > whether the configuration has a trackstick present (even if we're dealing > with a completely new, unknown PC)? Hell, if someone knew for sure, situation would be easier ;-) No, I'm not sure. What I observe is that based on the observation of E6230/E6430, bit 7 (0x80) of register c2c8 is used to choose between two code paths, one of which probably talks to the trackstick. The code structure here is almost in one-to-one mapping with the v3 code, and goes as follows: - check for presence of trackstick (bit 7 of register 0x8 on alps_v3, bit 7 of register 0xc2c8 on ``rushmore''). - if trackstrick: - enable trackstick passthrough mode by setting bit 0 of that same register - get an E7 report directly from the trackstick, although nothing is done with it. - send a magic command which sets something to the value 0x94. Might be your desired ``divisor''. - set bit 1 of register above (activate trackstick ???) - leave trackstick passthrough mode. > I did not see the ALPS driver checking this register, so if we don't know for > certain that this is the purpose > of the 0xc2c8 register, it might just be safer to always create the virtual > trackstick device on a > Rushmore-equipped PC (even if we never send it any reports). Yes. However, if the 0x94 thing above has any use, we'd better send it only conditionally, and the windows driver seems to do so only if it finds bit 0x80 in register 0xc2c8. Also, consistency with plain v3 code sort of increases the slim confidence we may have. > "Briefly put, I think we should work making all this stuff cleaner." > One thing that would probably make sense is to store the appropriate function > pointers + constants > in the alps_data struct, so we do not need case statements all over the code. The current alps_get_model logic seems hairy, too. Maybe it can be streamlined a bit, but that's just aesthetics. We could probably fetch the E6/E7/EC reports at once, and decide later. Do you have an idea of how many models will match any of the rushmore/pinnacle/pinnacle_agx rules ? Anyway. Whatever people find best doing for a patch to mainline is fine with me. I think we all have more important things to work with than silly touchpads... Best, E. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/606238 Title: synaptic touchpad not recognized on dell latitude e6510 and others To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/606238/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
