<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#c11">Comment # 11</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:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>(In reply to x414e54 from <a href="show_bug.cgi?id=85715#c10">comment #10</a>) > I still have a few issues because this does not solve the problem that the > delta is going to be different on Linux than on Windows for the same > hardware. To get the same value I would have to find the dpi of the mouse > that was used and then un-normalize the relative deltas. good news, I guess :) as of libinput 0.19 the unaccelerated deltas are as the hardware sends it. only the accelerated deltas are normalized (for mice with 100dpi and above, lower-res mice are a bit different). main problem that forced our hand there was the rounding up of deltas, a 400dpi mouse normalized to 1000dpi will send a min delta of 2.5 and that's not discoverable. normalizing down is easier to deal with, even if current systems may drop the data. > Is it actually part of the wayland spec that the mouse deltas would be > normalized to 1000dpi for example? > As it is not specifically mentioned, so there might be some window managers > that do not normalize and some that do. it's not part of the spec, no. libinput does it and I expect virtually all general-purpose compositors to use it though. > Well it may or may no be an issue. If you are sure every compositor is going > to be able to process and queue every mouse event within <1ms without adding > additional latency then I guess it is not an issue. I'm not sure because I haven't measured it. feel free to do so though, if we find issues we can fix them. right now it's speculation though. > Yes this works fine for normal GUI use but for certain applications you may > need to know the timestamp of each individual event or actually receive each > individual event within 1ms. Maybe to draw the specific path the mouse took > or to calculate who clicked first. So coalescing them is going to be a > problem and seems to defeats the purpose of a high poll rate mouse. There > would need to be some way to disable the coalescing or squashing. X has that too, for that reason. it would squash the pointer-moving motion events when needed (i.e. events come in faster than the server can process them) but still keep the history intact. XGetMotionEvents() gets you that history so you can rebuild the path. > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>