SUMMARY *** Touchscreen mapping does nothing when you have multiple monitors *** STEPS TO REPRODUCE 1. Have 2 or more screens 2. Have 1 of them be a touch screen 3. Make sure all of them are independent (no cloning) 4. Under touchscreen, set the "Target display" to be one of the displays (not automatic) 5. Use touch screen OBSERVED RESULT 1. The mouse sill gets mapped to 3 different screens rather than that 1 screen EXPECTED RESULT Have the mouse mapped to that one screeen SOFTWARE/OS VERSIONS Linux/KDE Plasma: Using KDE Neon Testing 20240207-1524 Using Plasma 6 and Wayland; I haven't tested for X11 yet but I can if need be
Video of problem: https://youtube.com/shorts/OCvdNAS4tuQ
Cannot reproduce on Plasma 6 Wayland with hardware capable of demonstrating the problem. I can choose which display I want to target, and that display is the only one that gets the touchscreen input. What happens if you change the target display to another value that isn't "Automatic"? Does *anything* change, or is the tap still mapped to both screens? Something unusual I notice in your screen recording is that the pointer is still visible when you tap. That's not expected on Wayland, and it's not what I see. Are you sure you're using Wayland? Very cool setup, BTW.
(In reply to Nate Graham from comment #2) Please see inline: > Cannot reproduce on Plasma 6 Wayland with hardware capable of demonstrating > the problem. I can choose which display I want to target, and that display > is the only one that gets the touchscreen input. For what it's worth, I am using a Viewsonic TD2210 resistive display. Resistive touchscreens tend to have a different Linux driver compared to a normal capacitive touchscreen. > > What happens if you change the target display to another value that isn't > "Automatic"? Does *anything* change, or is the tap still mapped to both > screens? No, nothing changes. I can set it to any display including automatic and it still maps the same exact way. > > Something unusual I notice in your screen recording is that the pointer is > still visible when you tap. That's not expected on Wayland, and it's not > what I see. Are you sure you're using Wayland? Yes, it is using Wayland. The thing about resistive displays is that it pretends to be a mouse but with absolute coordinates rather than relative coordinates. > > Very cool setup, BTW. Thanks :-). My dental practice is right now using KDE/Plasma 5 and I am hoping to upgrade to Plasma 6 later this year once these kinds of issues are fixed.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Hi, what exact info would be helpful? (In reply to Bug Janitor Service from comment #4) > Dear Bug Submitter, > > This bug has been in NEEDSINFO status with no change for at least > 15 days. Please provide the requested information as soon as > possible and set the bug status as REPORTED. Due to regular bug > tracker maintenance, if the bug is still in NEEDSINFO status with > no change in 30 days the bug will be closed as RESOLVED > WORKSFORME > due to lack of needed information. > > For more information about our bug triaging procedures please read the > wiki located here: > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging > > If you have already provided the requested information, please > mark the bug as REPORTED so that the KDE team knows that the bug is > ready to be confirmed. > > Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Here is how the touchscreen looks to libinput: Device: HID TOUCH HID Touch Panel Kernel: /dev/input/event13 Group: 6 Seat: seat0, default Size: 455x273mm Capabilities: touch Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: n/a Nat.scrolling: n/a Middle emulation: n/a Calibration: identity matrix Scroll methods: none Click methods: none Disable-w-typing: n/a Disable-w-trackpointing: n/a Accel profiles: n/a Rotation: 0.0 Device: HID TOUCH HID Touch Panel Kernel: /dev/input/event14 Group: 6 Seat: seat0, default Capabilities: keyboard Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: n/a Nat.scrolling: n/a Middle emulation: n/a Calibration: identity matrix Scroll methods: none Click methods: none Disable-w-typing: n/a Disable-w-trackpointing: n/a Accel profiles: n/a Rotation: 0.0 Device: HID TOUCH HID Touch Panel Kernel: /dev/input/event15 Group: 6 Seat: seat0, default Capabilities: pointer Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: disabled Nat.scrolling: disabled Middle emulation: disabled Calibration: identity matrix Scroll methods: none Click methods: none Disable-w-typing: n/a Disable-w-trackpointing: n/a Accel profiles: n/a Rotation: 0.0 So it's almost like it's a mouse, keyboard all in one. Maybe the libinput code in KWin is getting confused?
Also, it seems like https://github.com/KDE/kwin/blob/master/src/backends/libinput/device.cpp#L329 is part of the issue where it sees "LIBINPUT_DEVICE_CAP_POINTER" and just assumes it is a mouse rather than a touchscreen.