Reassigning this to mutter, where this would be implemented.

Isn't enough to use ClutterDeviceManager in g-c-c (instead of GsdDeviceManager), which is already used in mutter? There is x11 backend, which can provide device ids, and evdev backend which can provide libinput_device structs. We can detect the capabilities using libinput api if we will have those structs...

(In reply to Ondrej Holy from comment #2)
> Isn't enough to use ClutterDeviceManager in g-c-c (instead of
> GsdDeviceManager), which is already used in mutter? There is x11 backend,
> which can provide device ids, and evdev backend which can provide
> libinput_device structs. We can detect the capabilities using libinput api
> if we will have those structs...

No, because ClutterDeviceManager won't have access to the devices directly, only through wayland. You're confusing the compositor and clients features, which could both be clutter in this case.

ClutterDeviceManager, in mutter, will talk directly to the input devices through libinput. In client applications, they will talk to the compositor, using a wayland protocol. Client applications will never see the actual devices.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.