Re: master 3b41141708: Expose the name of an event's input device to Lisp

[Po Lu]

Brian Cully <bjc@spork.org> writes:

>       I think I must be misunderstanding something, because I have
> devices that are identically named within X and also operate
> correctly. That seems to me to run counter to “can only operate
> correctly if each name uniquely identifies a device”.

That means it's not operating correctly because of a problem in the
input driver.  It might work, but it's not correct behavior.

>       I bring up USB because libinput has to get its information from
> somewhere, and in the cases of the devices I have that libinput
> publishes, that is USB. I could potentially dig out some bluetooth ones,
> but that seems uneccesary.

libinput in most cases gets its information from evdev.  What the kernel
driver exposing the evdev device does is outside its scope.

>       I am at a loss, then. I do not know why libinput would choose to
> give your devices unique names but not mine. Does the “Device” line of
> ‘libinput list-devices’ also show unique names?

It does not.

>       This thread began with a claim that devices were uniquely named,
> and thus could be disambiguated within Emacs to provide different
> functionality based on their names. If I wanted to treat the pointer on
> one Steam Controller as a vertical scroll, and on the other a horizontal
> scroll, I do not currently see how I could do that.

That's a bug in the input driver.  If the input driver works correctly,
then that will be possible.  If not (like in your case), you lose,
sorry, but there is no way to fix that problem.  IOW, the devices are
uniquely named, but from the point of view of Emacs the input driver is
reporting two devices as a single device.

>       What this shows to me is that precious little in the X stack
> actually cares about device names. For the most part, they are
> irrelevant, as devices are self-describing in terms of capabilities.

They are not.  If you want to configure a program to behave differently
based on the individual steam controllers, that will not work, because
to them the X server is reporting those two controllers as the same
device.

And as I already explained, devices are nowhere close to self-describing
in their capabilities.  Joysticks send motion events, foot pedals send
keyboard events, and so on and so forth.

>       That it is useful for a user to modify the way a device behaves
> in the context of Emacs I take at face value, and I also grant that the
> name is one possible, though hopefully as is clear by now, not
> fool-proof way to do that.

It's the only reliable way to do that.  What else would you suggest?

(Reliable doesn't have to mean it has to work when the input driver is
buggy.  It just happens to be the only way to single out an input
device, and because of that, it's what programs use.)

>       I do not actually believe this to be a huge problem. Outside of
> hardware hackers I don’t think I know anyone who attaches two identical
> devices. Maybe musicians? I’m sure they exist, but it’s not a lot of
> people. But I also don’t believe this is a problem Emacs can solve using
> only the device name, for reasons already stated.

If the input driver's naming is broken, they can configure the devices
statically in their X server configuration files.  "Only the device
name" is enough with a correctly functioning input driver, and if
xf86-input-libinput is not, then too bad, the users lose.  (Or have to
mess with their xorg.conf.d.)

> prefix the device name with 'pointer:' or 'keyboard:' as appropriate.

This message sort of demonstrates my point.  It is OK for there to be a
pointer and a keyboard extension device with the same name, because they
are the same device sending both motion and keyboard events.  But it is
not correct for there to be more than one physical device with the same
name.

> $ xinput list-props 24
> Device 'Valve Software Steam Controller':
>       Device Enabled (154):   1
>       Coordinate Transformation Matrix (156): 1.000000, 0.000000, 0.000000, 
> 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
>       libinput Send Events Modes Available (275):     1, 0
>       libinput Send Events Mode Enabled (276):        0, 0
>       libinput Send Events Mode Enabled Default (277):        0, 0
>       Device Node (278):      "/dev/input/event30"
>       Device Product ID (279):        10462, 4418

> $ xinput list-props 9
> Device 'Valve Software Steam Controller':
>       Device Enabled (154):   1
>       Coordinate Transformation Matrix (156): 1.000000, 0.000000, 0.000000, 
> 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
>       libinput Natural Scrolling Enabled (290):       0
>       libinput Natural Scrolling Enabled Default (291):       0
>       libinput Scroll Methods Available (292):        0, 0, 1
>       libinput Scroll Method Enabled (293):   0, 0, 0
>       libinput Scroll Method Enabled Default (294):   0, 0, 0
>       libinput Button Scrolling Button (295): 2
>       libinput Button Scrolling Button Default (296): 2
>       libinput Button Scrolling Button Lock Enabled (297):    0
>       libinput Button Scrolling Button Lock Enabled Default (298):    0
>       libinput Middle Emulation Enabled (299):        0
>       libinput Middle Emulation Enabled Default (300):        0
>       libinput Accel Speed (301):     -0.200000
>       libinput Accel Speed Default (302):     0.000000
>       libinput Accel Profiles Available (303):        1, 1
>       libinput Accel Profile Enabled (304):   0, 1
>       libinput Accel Profile Enabled Default (305):   1, 0
>       libinput Left Handed Enabled (306):     0
>       libinput Left Handed Enabled Default (307):     0
>       libinput Send Events Modes Available (275):     1, 0
>       libinput Send Events Mode Enabled (276):        0, 0
>       libinput Send Events Mode Enabled Default (277):        0, 0
>       Device Node (278):      "/dev/input/event30"
>       Device Product ID (279):        10462, 4418
>       libinput Drag Lock Buttons (308):       <no items>
>       libinput Horizontal Scroll Enabled (309):       1
>       libinput Scrolling Pixel Distance (310):        15
>       libinput Scrolling Pixel Distance Default (311):        15
>       libinput High Resolution Wheel Scroll Enabled (312):    1

One of those is a keyboard, the other is a pointer.  They are not
ambiguous, since they are extension devices corresponding to the same
"real" device.

The other pair (25, 10) is a bug, and from the POV of programs is the
same controller as the the first pair.