RFC: libwacom_new_from_uuid()
Opened this issue · 0 comments
As of 2.12 we have mostly solved the issue with re-used firmware ids and with libwacom_new_from_builder()
we can re-create any device even if we don't have the actual device path. Except: this requires the caller to have the information libwacom uses to look up a device - and realistically this is only possible if using libwacom_new_from_path()
.
Luckily the path is exported via xf86-input-* (Device Node
property) and in Wayland's zwp_tablet_v2.path
so clients can actually re-create the required libwacom tablet. Except that may not work where the tablet path is not available, e.g. flatpak.
A possible option to avoid this (and possibly ambiguity/race condition) would be to assign each device a uuid, recorded in the .tablet
file - that uuid is public API can cannot be changed for that tablet, ever. But it can be used to recreate a tablet on the other side of a protocol via libwacom_new_from_uuid()
.
So the flow is:
- compositor opens a device,
libwacom_new_from_path()
returns aWacomDevice
- compositor sends
libwacom_get_uuid()
via Wayland/DBus/whatever to the other client - other client does
libwacom_new_from_uuid()
and gets the sameWacomDevice
without knowing anything else about the device.
Bonus point: this uuid is stable so it could even be used in configuration storage.
The only immediate drawback is that libwacom_get_match()
can only ever return what is the first listed match since we don't actually have a match in this case. Should not be an issue in the intended use-cases.
I'm not 100% there is an immediate use-case, Flatpak applications are the only one I can think of since it won't have access to the device path but to my knowledge no application currently requires libwacom. The ones that do (e.g. gnome-control-center) exist outside the sandbox.
Thoughts?
cc @jigpu, @Pinglinux, @JoseExposito, @jadahl, @garnacho
Note: I have a strong deja-vu here, I think I started implementing it once and dropped it but I can't find anything in my notes or local branches...