RFC: libwacom_new_from_uuid()

[whot]

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 a WacomDevice
• compositor sends libwacom_get_uuid() via Wayland/DBus/whatever to the other client
• other client does libwacom_new_from_uuid() and gets the same WacomDevice 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...

[whot]

Another benefit of this approach: it would allow applications to use the uuid as local key for configuration storage. Right now GNOME uses vid:pid in the gsettings path but that falls apart once users have more than one device with the same vid:pid - which in the case of Huion devices can happen if you have e.g. the Huion mini keydial (KD100) connected as well as one of the 0x6d huion tablets.