Repository navigation
Proper device names in IPTS driver #4
Description
My little concern is that we cannot distinguish touch devices by name anymore:
# before
$ libinput list-devices | grep ipts
Device: ipts 1B96:005E UNKNOWN
Device: ipts 1B96:005E
Device: ipts 1B96:005E Touchscreen
Device: ipts 1B96:005E Mouse
# after
$ libinput list-devices | grep ipts
Device: ipts 1B96:005E
Device: ipts 1B96:005ENo impact on functionality, though.
I hope we can change the name by IPTS driver side rather than patching to hid-multitouch.c at some point, like ipts 1B96:005E Pen and ipts 1B96:005E Touchscreen (for human).
(The ipts 1B96:005E UNKNOWN device was a single-touch device.)
(I don't know what was the purpose of the ipts 1B96:005E Mouse. It seems to be not used by any input for me.)
Originally posted by @kitakar5525 in #3 (comment)
Activity
qzed commentedon Sep 21, 2019
@kitakar5525 Right, we should probably use better device names for this. For classical USB devices, the name is (as far as I know) supplied by the device attached to the bus. It would also be nice if we could get some naming that is properly understandable for non-developers (e.g.
Microsoft Surface IPTS TouchscreenandMicrosoft Surface IPTS Stylus), where the prefix would ideally be supplied by attached the device itself somehow (or maybe the firmware files?).qzed commentedon Sep 21, 2019
Names are set here:
https://github.com/qzed/linux-surface-kernel/blob/1d902b5208160d98d1e35f690d3c47d97c2193fc/drivers/misc/ipts/ipts-hid.c#L284-L285
Edit: I am currently not sure how this creates multiple input devices and how we can give them different names.
StollD commentedon Sep 21, 2019
IPTS creates one single
hid_deviceand uses it to forward all (hardware-generated) HID events to the kernels hid subsystem. There, they are split into multiplehid_inputs (using the HID descriptor I believe), which are then processed byhid-multitouchetc.The IPTS driver is not much more than a relay for those messages. If we wanted to split them into two seperate devices that can be controlled from IPTS we would have to reprocess the HID messages coming from the hardware / firmware.
qzed commentedon Sep 21, 2019
@StollD Thanks, makes sense. So we don't have direct control over the suffix, at least without changing hid system internals, which then would probably involve some convincing of the upstream maintainers if we ever get to upstream this.
perf stat: Fix a segmentation fault when using repeat forever
perf tools: Fix segfault in cpu_cache_level__read()
btrfs: relocation: fix use-after-free on dead relocation roots
KVM: X86: Fix userspace set invalid CR4
raid5: don't set STRIPE_HANDLE to stripe which is in batch list
md/raid6: Set R5_ReadError when there is read failure on parity disk
KVM: X86: Fix userspace set invalid CR4
KVM: nVMX: handle page fault in vmread fix
285 remaining items
PCI/MSI: Enable and mask MSI-X early
perf env: Fix memory leak of bpf_prog_info_linear member
perf record: Fix memory leak in vDSO found using ASAN
regulator: vctrl: Avoid lockdep warning in enable/disable ops
PCI/MSI: Enable and mask MSI-X early
rtc: cmos: Disable irq around direct invocation of cmos_interrupt()
perf machine: Initialize srcline string member in add_location struct
btrfs: update the bdev time directly when closing
btrfs: delay blkdev_put until after the device remove
block: genhd: don't call blkdev_show() with major_names_lock held
libperf evsel: Make use of FD robust.
net: usb: asix: do not call phy_disconnect() for ax88178
btrfs: do not take the uuid_mutex in btrfs_rm_device
NFS: Fix an Oops in pnfs_mark_request_commit()
PCI: Do not enable AtomicOps on VFs