https://bugs.kde.org/show_bug.cgi?id=411877
--- Comment #16 from lo...@kde.bt.alestan.publicvm.com --- (In reply to Abel Yang from comment #15) > I can reproduce this bug on 5.24.5 (Fedora 36 Kernel 5.18.6). In my case, I > have an external touchscreen connected to a laptop, both screens are > 1920x1080. > > Laptop: Thinkpad T470s (Mesa Intel HD 620) > Touchscreen HID device: ILI Multi-Touch-V3000 (USB 222A:004D) on Inknoe Lite > Touchscreen display device: reports as unknown in info center > > The touchscreen maps to the laptop internal display when it should map to > the external display. An added complication that can mess up the heuristic > is that the display output connects through HDMI while the touch device > connects through a separate USB port (this is a rather old device) so going > by EDID may not always work. > > The easiest way to cover all use cases is probably to have an option for a > manual override in system settings to map a touchscreen device to a specific > display output (something like the target display setting in the drawing > tablets page). Worth noting that the resolution of the screens does not matter. It is the screens' reported physical sizes, compared to the touch device's reported size. The issue is your external display does not report the same physical size for the touch and display components. If they are off by *any* amount, it does not pick the closest fit, it just falls back to the first display. For a first step, if it hits the "don't know, just guess" part of the code, it could guess the screen with the closest matching size, but that does not handle the "two identical displays with two identical APDs" issue. A fingerprint of the touchscreen, along with remembering its bus address (USB or otherwise) should be able to handle remembering which device goes where across restarts. Use the fingerprint, ignoring the bus address, unless there are duplicate devices in play. But a graphical way to reattach them would make the (re)configuration much easier. In March I went to the recommended matrix channel, and got a bit of a runaround about how best to implement this. There was some suggestion of making it use an extension system rather than a core part of kwin. There was some suggestion of making it use custom udev rules, so that anyone without write access to /etc/udev/rules.d is screwed (not to mention requiring a replug (impossible on integrated i2c screens) or restart of kwin). I'll try again next time I'm between paying work. -- You are receiving this mail because: You are watching all bug changes.
