SUMMARY When two identical touchscreen devices are connected, it is not possible to configure their output mappings properly due to them having the exact same name. Looking at ~/.config/kcminputrc, the problem seems to be that when the first touch input is configured, the configuration for the second touch input simply overwrites the first entry due to the identical device names. Strangely enough, directly after the changes from the system settings are applied, everything seems fine. The problem occurs when the configuration is loaded after a reboot, where both touch inputs seem to be mapped to one display. It seems like extra information is needed to uniquely identify identical touch input devices. STEPS TO REPRODUCE 1. Have two identical touchscreen displays connected 2. Map each touch input to their corresponding display output (through trial and error because both devices have the same name) 3. Observe how the mappings seem to be correct 4. Reboot 5. Observe how the mappings are no longer correct OBSERVED RESULT Both touchscreen inputs are mapped to the same display output. EXPECTED RESULT The touchscreen inputs are mapped to their corresponding display output, as was the case before the reboot.
Can you please attach the output of "sudo libinput list-devices" when the two devices are connected?
Created attachment 162765 [details] Output of 'sudo libinput list-devices'
(In reply to Nicolas Fella from comment #1) > Can you please attach the output of "sudo libinput list-devices" when the > two devices are connected? I have added the output of that command in the attachments. In this case, the problem lies with the two 'ILITEK...' devices.
Some version information about my system I forgot to add in the original report: KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.5.9-arch2-1 (64-bit) Graphics Platform: Wayland
Thanks. This is a tough one. Currently the identification is done via (USB?) vendor/product/name triple. I'm not sure what else we could use to identify a device that isn't inherently unstable/volatile
(In reply to Nicolas Fella from comment #5) > Thanks. > > This is a tough one. Currently the identification is done via (USB?) > vendor/product/name triple. I'm not sure what else we could use to identify > a device that isn't inherently unstable/volatile Would the USB port number be possible? That would of course change when the devices are plugged into different ports, but apart from that they should always remain the same.
Is there any way we could look at the serial number of the devices too, as an additional data point?
(In reply to Nate Graham from comment #7) > Is there any way we could look at the serial number of the devices too, as > an additional data point? I'm not sure if that would work, since udev at least doesn't show any Serial ID for my specific device. I will attach the output of 'udevadm info --attribute-walk' for one of the touch devices for reference.
Created attachment 162815 [details] Output of 'udevadm info --attribute-walk' for one of the touch devices
One interesting thing is that the touch assignment does seem to work properly once the configuration is applied. The problems occur as soon is the computer is restarted and the configuration is loaded again as KDE starts. This has me wondering: what happens when you click apply in System Settings that doesn't happen when the configuration is loaded at boot?
I've tried this again today with the exact same hardware setup as in the original report and the issue still occurs in the exact same way. The version information for today's setup: Distro: Arch Linux (same as in the original bug report) KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.15.9-arch1-1 (64-bit) Graphics Platform: Wayland