From: Brian Cully <bjc@spork.org>
To: Po Lu <luangruo@yahoo.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
rms@gnu.org
Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp
Date: Sun, 10 Apr 2022 14:08:00 -0400 [thread overview]
Message-ID: <87mtgsyeg0.fsf@ditto.jhoto.spork.org> (raw)
In-Reply-To: <87v8vh845k.fsf@yahoo.com>
Po Lu <luangruo@yahoo.com> writes:
> That's not true on X. This is implementation dependent, but the X.Org
> server will always try to reuse a device ID that is currently available.
From what I could make out from the code, you are correct, but I
was speaking of how Linux assigns USB device addresses. In any event,
the index into the inputInfo.devices array isn’t useful as a stable
identifier.
> That's only a last resort. On X Windows, the input driver is supposed
> to take care of that using serial numbers and any other information that
> might serve to identify a device uniquely.
So I’ve tried to verify this, and couldn’t. I trawled the Xorg
xserver code, and from what I can tell, the “name” field that gets
assigned to a device comes from the driver level, which, in my case at
least, is libinput. I couldn’t find any place in the X server code that
changes the name as passed in from the driver level (although I may have
missed it, but I doubt it, as I’ll show below).
Moreover, it appears as though, at least with udev and libinput,
device names are *not* unique. This time, rather than trying to go
through their code, I created a simple test: I updated the firmware on a
USB device to have the same name, model, vid, and pid as my keyboard,
but a different serial number. I think this reflects how this would work
in the real world.
When I plugged it in, here’s the relevant output from lsusb:
---[snip]---
Bus 001 Device 059: ID 1209:2301 Generic Keyboardio Model 01
Device Descriptor:
⋮
idProduct 0x2301 Keyboardio Model 01
bcdDevice 1.00
iManufacturer 1 Keyboardio
iProduct 2 Model 01
iSerial 3 kbio01D
⋮
Bus 001 Device 083: ID 1209:2301 Generic Keyboardio Model 01
Device Descriptor:
⋮
idProduct 0x2301 Keyboardio Model 01
bcdDevice 1.00
iManufacturer 1 Keyboardio
iProduct 2 Model 01
iSerial 3 8995E84D0119
⋮
---[snip]---
You can see the only difference is the serial number. This is reflected
in the Linux device names in /dev/input/by-id:
---[snip]---
usb-Keyboardio_Model_01_8995E84D0119-if02-event-kbd -> ../event28
usb-Keyboardio_Model_01_kbio01D-if03-event-kbd -> ../event26
---[snip]---
The serial number is clearly visible (8995... is my mock
device), and you can see that they reference separate event devices in
/dev/input.
From there, I launched an X session to see how the name would be
reported in the logs:
---[snip]---
⋮
[2308240.861] (II) config/udev: Adding input device Keyboardio Model 01 (/dev/input/event28)
[2308240.861] (**) Keyboardio Model 01: Applying InputClass "evdev keyboard catchall"
[2308240.861] (**) Keyboardio Model 01: Applying InputClass "libinput keyboard catchall"
[2308240.861] (**) Keyboardio Model 01: Applying InputClass "system-keyboard"
[2308240.861] (II) Using input driver 'libinput' for 'Keyboardio Model 01'
[2308240.861] Option "_source" "server/udev"
[2308240.861] Option "name" "Keyboardio Model 01"
[2308240.861] Option "path" "/dev/input/event28"
[2308240.861] Option "device" "/dev/input/event28"
[2308240.861] Option "major" "13"
[2308240.861] Option "minor" "92"
[2308240.899] (II) XINPUT: Adding extended input device "Keyboardio Model 01" (type: KEYBOARD, id 8)
⋮
[2308241.075] (II) config/udev: Adding input device Keyboardio Model 01 (/dev/input/event26)
[2308241.075] (**) Keyboardio Model 01: Applying InputClass "evdev keyboard catchall"
[2308241.075] (**) Keyboardio Model 01: Applying InputClass "libinput keyboard catchall"
[2308241.075] (**) Keyboardio Model 01: Applying InputClass "system-keyboard"
[2308241.075] (II) Using input driver 'libinput' for 'Keyboardio Model 01'
[2308241.075] Option "_source" "server/udev"
[2308241.075] Option "name" "Keyboardio Model 01"
[2308241.075] Option "path" "/dev/input/event26"
[2308241.075] Option "device" "/dev/input/event26"
[2308241.075] Option "major" "13"
[2308241.075] Option "minor" "90"
[2308241.125] (II) XINPUT: Adding extended input device "Keyboardio Model 01" (type: KEYBOARD, id 12)
⋮
---[snip]---
And here you can see that the two input devices have the same
name (Keyboardio Model 01). In particular the last set of XINPUT lines
which echo the name come from device activation in xf86input.c at line
412 of the xserver code, just before the device is enabled, and I would
assume far too late in the process to adjust the name (but again, I
admit I may be missing something).
AFAICT this is the name that’s presented to
toolkit layers. There may be a place where it’s modified by X, but,
again, I couldn’t find it.
So, the tl;dr here is that I flashed a USB device to look like one of my
existing ones, and from everything I can tell, they have the same name,
at least coming out of X.
-bjc
next prev parent reply other threads:[~2022-04-10 18:08 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org>
[not found] ` <20220407133623.9C209C009A8@vcs2.savannah.gnu.org>
2022-04-07 14:05 ` master 3b41141708: Expose the name of an event's input device to Lisp Stefan Monnier
2022-04-07 23:31 ` Po Lu
2022-04-07 23:41 ` Stefan Monnier
2022-04-08 0:07 ` Po Lu
2022-04-08 6:02 ` Eli Zaretskii
2022-04-08 6:08 ` Po Lu
2022-04-08 6:26 ` Eli Zaretskii
2022-04-08 7:36 ` Po Lu
2022-04-08 11:12 ` Eli Zaretskii
2022-04-08 11:31 ` Po Lu
2022-04-08 12:12 ` Eli Zaretskii
2022-04-08 12:35 ` Po Lu
2022-04-09 6:48 ` Eli Zaretskii
2022-04-09 9:06 ` Po Lu
2022-04-09 9:09 ` Lars Ingebrigtsen
2022-04-09 9:30 ` Eli Zaretskii
2022-04-09 10:03 ` Po Lu
2022-04-09 11:03 ` Eli Zaretskii
2022-04-09 11:44 ` Po Lu
2022-04-09 14:04 ` Eli Zaretskii
2022-04-09 16:33 ` Stefan Monnier
2022-04-09 16:41 ` Lars Ingebrigtsen
2022-04-09 17:06 ` Eli Zaretskii
2022-04-09 17:16 ` Eli Zaretskii
2022-04-09 17:52 ` Brian Cully
2022-04-09 19:18 ` Eli Zaretskii
2022-04-10 0:54 ` Po Lu
2022-04-10 1:46 ` Brian Cully
2022-04-10 2:11 ` Po Lu
2022-04-10 2:45 ` Brian Cully
2022-04-10 3:30 ` Po Lu
2022-04-10 0:37 ` Po Lu
2022-04-10 5:49 ` Eli Zaretskii
2022-04-10 6:09 ` Po Lu
2022-04-10 6:44 ` Eli Zaretskii
2022-04-10 7:31 ` Po Lu
2022-04-10 8:28 ` Eli Zaretskii
2022-04-10 8:50 ` Po Lu
2022-04-10 9:17 ` Eli Zaretskii
2022-04-10 9:25 ` Po Lu
2022-04-10 11:15 ` Po Lu
2022-04-10 15:16 ` Stefan Monnier
2022-04-11 1:02 ` Po Lu
2022-04-10 11:46 ` Lars Ingebrigtsen
2022-04-10 11:41 ` Lars Ingebrigtsen
2022-04-10 0:48 ` Po Lu
2022-04-10 6:04 ` Eli Zaretskii
2022-04-10 6:17 ` Po Lu
2022-04-10 6:49 ` Eli Zaretskii
2022-04-10 7:01 ` Po Lu
2022-04-10 8:24 ` Eli Zaretskii
2022-04-10 8:42 ` Po Lu
2022-04-10 9:13 ` Eli Zaretskii
2022-04-10 12:51 ` Brian Cully
2022-04-10 13:21 ` Po Lu
2022-04-10 18:08 ` Brian Cully [this message]
2022-04-11 0:58 ` Po Lu
2022-04-11 1:08 ` Brian Cully
2022-04-11 2:00 ` Po Lu
2022-04-11 2:03 ` Po Lu
2022-04-11 2:21 ` Brian Cully
2022-04-11 3:12 ` Po Lu
2022-04-11 4:11 ` Brian Cully
2022-04-11 5:20 ` Po Lu
2022-04-11 11:33 ` Brian Cully
2022-04-11 14:09 ` Po Lu
2022-04-11 16:26 ` Brian Cully
2022-04-11 10:10 ` Lars Ingebrigtsen
2022-04-10 12:44 ` Brian Cully
2022-04-10 13:14 ` Po Lu
2022-04-08 14:27 ` Stefan Monnier
2022-04-09 0:24 ` Po Lu
2022-04-09 2:52 ` Stefan Monnier
2022-04-09 3:17 ` Po Lu
2022-04-09 13:31 ` Stefan Monnier
2022-04-09 13:37 ` Po Lu
2022-04-09 14:20 ` Stefan Monnier
2022-04-10 0:58 ` Po Lu
2022-04-09 14:31 ` Eli Zaretskii
2022-04-10 0:56 ` Po Lu
2022-04-10 6:11 ` Eli Zaretskii
2022-04-10 6:23 ` Po Lu
2022-04-10 6:52 ` Eli Zaretskii
2022-04-10 7:37 ` Po Lu
2022-04-10 8:12 ` Eli Zaretskii
2022-04-09 6:22 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mtgsyeg0.fsf@ditto.jhoto.spork.org \
--to=bjc@spork.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=luangruo@yahoo.com \
--cc=monnier@iro.umontreal.ca \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.