there's a very short blurb here: https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html

and there's a long explanation of seats here: https://wayland.freedesktop.org/libinput/doc/latest/seats.html

I guess I should link the two :)

Peter, I do not see either page having the word "WL_OUTPUT" at all, nor even just "output".

oops, sorry, I found WL_SEAT and then didn't think from there. sorry about the noise and yes, you're right, WL_OUTPUT isn't documented. fwiw, iirc WL_OUTPUT is mostly a leftover for a fairly specific use-case and not really well defined, but I'll write something up.

As it so happens, I am currently working on a use case where Weston is driving a dual-head configuration where *both* heads have a touchscreen input device. Each input device needs to be somehow associated with the right DRM connector. This is also in a clone mode, but that's beside the point.

The displays are using standard display connectors and touchscreens are using USB, everything can be hotplugged individually. I need to do things like disabling the touch device if the display get unplugged.

I assume using libinput_device_get_output_name() is the right thing to use here?

Is the udev property WL_OUTPUT the right thing to control that, or should we be doing something else?

Created attachment 130955 [details] [review]
0001-Add-doc-to-discourage-use-of-libinput_device_get_out.patch

Probably not what you expected, but throwing up our hands is (I think) the only practical thing we can do in libinput.

For you, this would mean you'd set some udev property and get that property value from weston to interpret it as you need it. Having libinput pretend to be a middle man for this is not future-proof.

Hi Peter,

the patch is fine by me, it tells us where we stand and I can work with that. :-)
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

I'm not sure udev is the only place where would want to configure the association. It works fine in my use case, where we have labelled connectors and one has to plug the right thing to the right connector, or it doesn't work at all.

But I can also envision a different use case, where you would associate a monitor and a touch device in the compositor's (or system's if such existed) configuration based on their inherent properties like serial numbers. Then the user could plug the monitor to any display connector and the touch device to any USB port, and have them automatically associated.

Or would that too be good with udev rules, maybe tagging the input device with a monitor serial number, or something? Unfortunately I don't think udev can do anything with monitors, so the monitor matching must always be done in the compositor.

Yeah, the udev property in the doc seems good. I just wonder how one would make a desktop GUI to configure them, but that's another matter.

> But I can also envision a different use case, where you would associate a
> monitor and a touch device in the compositor's (or system's if such existed)
> configuration based on their inherent properties like serial numbers. Then
> the user could plug the monitor to any display connector and the touch
> device to any USB port, and have them automatically associated.

that's the case with e.g. Wacom Cintiq devices that are monitors and touchscreens+tablets. gnome already implements some heuristics there to search for the right monitor but in the end most of this will have some device-specifics.

So as you say, udev is often not enough, you'll still need more. I've amended the patch to add another sentence to say that.

https://lists.freedesktop.org/archives/wayland-devel/2017-April/033943.html

commit 7b9aa96d0230b9b1328c43e8421ddea3ffa310cb
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Apr 21 08:47:31 2017 +1000

    Add doc to discourage use of libinput_device_get_output_name()