| Summary: | Default resolution fallback for libinput missing / devices changing resolution | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Simon <sur3> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | evemu-describe for gfxtablet using motorola zoom tablet. | ||
|
Description
Simon
2018-03-05 09:27:37 UTC
Created attachment 137790 [details]
evemu-describe for gfxtablet using motorola zoom tablet.
libinput makes a few promises in its API that make using libinput more useful. One of these is that some calls return the data in mm - and for that we need to know the resolution of the tablet. There is no good reason for a tablet to not have a resolution set. We have the 60-evdev.hwdb now for physical devices that lack it (or have wrong values set) and in the case of networked tablets like this - just set it in the software that creates the tablet. This is a one-liner to set in gfxtablet but it's many lines of code, APIs set in stone, required configuration interfaces, etc. in libinput. Not a good trade-off, tbh.
There is no default resolution, some touchpads have 12 units/mm some tablets have hundreds of units/mm.
The 'outside expected range' is just a warning and indicates that the ranges are set up wrongly. For physical devices this would require a 60-evdev.hwdb fix, but in this case it's a uinput device and can just be fixed in code there.
> I think libinput should add devices anyway with a default resolution and
> provide a user interface to change resolutions on the fly, e.g. to change
> between different android devices.
config interfaces in libinput are difficult. libinput has no GUI, so it relies on the caller to implement any actual user-facing bits. which means implementing it in gnome, kde, enlightenment, xorg, ... unless there's a reasonable chance this will happen, there's little point in putting it in libinput. And quite frankly, libinput right now is not set up to deal with changing resolution on the fly so the best you could do would be to have it as static configuration on startup. But this is all moot because the other side of the device is a uinput device and there's really no excuse for sending garbage data here.
sorry, definitely a wontfix on the libinput side, this needs to be addressed in gfxtablet.
I looked into the gfxtablet code and it is using "struct uinput_user_dev" to set the devices properties, but struct uinput_user_dev does not have a resolution setting.. https://github.com/torvalds/linux/blob/master/include/uapi/linux/uinput.h#L223 So I suppose every device using old uinput interface will have problems using libinput then if libinput expects a resolution.. :-/ using libevdev instead of straight uinput ioctls would've helped with that in gfxtablet, it handles that case transparently (albeit with a potential race condition in old clients). and yes, libinput will not work with those tablets. We have, over the last years, added infrastructure to fix those tablets in userspace where the kernel drivers or firmware cannot be fixed. But we're not talking about physical hardware here that got released once and now has to work. This is a software package, expecting it to use an interface that's now 2 years old is not too much to ask (kernel 4.5 and later). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.