Op 07-04-10 20:30, Max Schwarz schreef: > Am Mittwoch 07 April 2010 16:13:09 schrieben Sie: >> First, you could have one factor which governs how many valuator scroll >> steps are needed to trigger one button scroll event, as discussed above. >> This would need to be enforced by the driver. If a mouse is clicky, it >> may be 1 or the driver would multiply it to match some target value like >> 100. The main question is whether apps need to or shouldn't know that >> factor. I think that's what Eric meant. > Eric wanted to scale the reported valuator value so that it is in relative > units to the old clicks, if I understood correctly. What I wanted to say is that there is a need for an _official_ value of how much is a click in this new (almost) continue space. Otherwise we might end up with drivers saying that a click is 20u, other drivers converting it to 33u, and others to 100u. Similarly, without a specific value, an app could move three lines for 10 units, while another would would move only 2.3 lines. And it's especially important for when those clicks are currently mapped to actions that cannot be cut in small pieces (like moving to the next picture in a slideshow, going back and forward in the webpage history...).
Failure to have a single value to map one click to one action would lead to lots of small very frustrating regressions. That's why I was suggesting 100u (or whatever other number which fits) to be set in stone. That said, the usage of the resolution field to carry the "units/scrollclick" would probably work as well. It's like an official value dependant on the driver. It just requires to make sure that the normal meaning of resolution will never be useful in this context (and a priori, I cannot think of any use), and that the core pointer does the appropriate conversion when merging several devices. Eric _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
