<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - wl_fixed is not precise enough for high dpi mice" href="https://bugs.freedesktop.org/show_bug.cgi?id=85715#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - wl_fixed is not precise enough for high dpi mice" href="https://bugs.freedesktop.org/show_bug.cgi?id=85715">bug 85715</a> from <a class="email" href="mailto:x414e54@linux.com" title="x414e54@linux.com">x414e54@linux.com</a> <pre>Okay great if the unaccelerated deltas are not normalize that solves that problem! I did think of another issue is that client relies on the timestamp of the click event to work out where the cursor was at that time but the timestamps are in milliseconds? Some mice are now reaching over 2000hz which means the button event would loose the precision to match to the correct motion event. Again more theoretical than practical but probably seems like we are already at the limit of 1ms with 1000hz mice. > > This is why I was thinking towards something more of a real raw input system > > and just take the compositor out of the loop completely. > > any raw input event system usually runs into the issue of "how much non-raw > will you support" and that's where it gets tricky, because suddenly you're > not that raw anymore. example: most touchpads these days only have a single > button, if you want right-click/tap/etc. functionality then you need more > than a raw system. if you're happy to ignore that and just support mice, > passing evdev fds to the client is the easiest approach - no input system as > such required here. Yeah I guess this is a fair point, there are also those "magic mice" which work the same for secondary click. But you could have the game engine implement full multitouch functionality and use gestures. You could use as many click buttons as fingers or separate the touchpad into four click areas. So it kinda seems a better way even for touch-pads. Though maybe conflicts/prevents with system specified gestures so you would probably want to have a system for an application to register gestures with Wayland or a way for Wayland to listen in for gestures and grab the fd back. I was originally hoping for something like the Android MotionEvent which seems mostly just a java abstraction of evdev. You just get all axis motion routed through one event system and then have an enum for the "pointer" or device type e.g. finger, mouse, joystick etc. It is then really easy for games to support every type of input because it always falls back to the default implementation (e.g. simulating clicks as touches, mouse as a joystick axis, etc.).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>