Dear all this is just to report that, when attaching a second display to my touch-screen laptop, the coordinates of the touches are wrongly detected. There is a similar bug report from one year ago (Bug 333099), which AFAICT is till unconfirmed and only relates to kde4. So please consider this confirmed on kde5 too :) Reproducible: Always Steps to Reproduce: 1. attach a second display (to the left of the touch-screen) 2. touch the screen 3. the mouse pointer does not move to where you touched, but somewhere else Actual Results: the mouse pointer does not move to where you touched, but somewhere else Expected Results: it should go where you touch...
Confirming. There is a wacom KCM, which might have options that we can adjust the work area. Will have to see.
Would be nice if KScreen could do that, you need to set a matrix transform on the touchscreen device, see [1]. [1] https://wiki.archlinux.org/index.php/Calibrating_Touchscreen
We've discussed this, and it's not libkscreen's business (kscreen is about monitors / screens, not about input devices). This is probably an upstream bug, either in Xorg or in libinput, and if libinput isn't currently used, the distribution should use it (may actually solve this bug). Under Wayland, it's a compositor bug, but we currently don't have anybody with a touchscreen who could take care of this bug, although it's reproducable. I honestly don't know what to do with it. :/
Martin Gräßlin has added a note to look into this, so it doesn't get forgotten. We'll leave it under KScreen for now.
This is a thing that X should take care of. We can't do anything about it in libkscreen.
To be honest: I don´t know anything about the systems architecture and the dependencies between KDE components and X. And generally KDE developers seem to know what they´re doing - otherwise KDE wouldn´t probably be my favorite desktop env ;-) But still I´m wondering: back when I reported Bug 333099 Ben Tissoires had already pointed me to https://bugzilla.gnome.org/show_bug.cgi?id=709600 where the Gnome folks apparently solved the same issue in 2014 all on their side in a Gnome Settings Daemon component without involving X... @sebas: If X should take care of it - could you open the appropriate bug report with them yourself or could you please tell me what X component should be fixed and where to create the report?
The problem here is that our client side code does not have enough knowledge to properly do that. There is no hint in xrandr that the output supports touch. This is knowledge only the display server has (e.g. on X11 that's xorg, on Wayland that's KWin). We could do heuristics to try to look for whether there's a touch screen and then transform it, but that's not a good idea. It can break any time when the x-stack changes, e.g. like recently when some distributions started to switch the input handling to libinput. Heuristics also have the problem of being wrong. If we have two identical screens with a touch screen how should we know which one belongs to which xrandr output? That's just non-existing knowledge for us. Thus the solutions must be to fix it in the layer which has the chance to fix it: that's Xorg. It's not our (nor GNOME's) job to work around bugs in the X server. It needs to be fixed by X. I have to ask you to report this yourself: we don't have the resources to track user bug reports over multiple upstreams. The right tracker would be bugs.freedesktop.org.
Thanks for the clarifications, but there is still something I just don't understand. You say kde has not enough information to solve the issue, but isn't all you need already available in the "Display and Monitor" panel in the system settings? Once the relative position of the multiple monitors is set, it seems to me all the offsets are also fully known. I also don't see why the touch capability of the screens is an issue here. If I have a touch screen, and I attach a second screen to the left of it, all the touches on the first screen must receive an offset, regardless of whether the new screen is touch-capable or not.
> Once the relative position of the multiple monitors is set, it seems to me all the offsets are also fully known. It's not that simple obviously. I spent quite some thinking about the issue since March when I was first made aware of it as KWin needs to handle this situation correctly on Wayland. We have two not connected pieces of information: there is a touch input device, and an output. We don't know that they belong together (neither the touch screen yells "I belong to HDMI1", nor the xrandr output yells "/dev/input/event7 is my touch screen"). We just don't have that information. If the system starts up with two displays one of them being a touch screen, we simply don't know to which one the touch screen belongs. So yes it needs to be translated, just we don't know how. We can try all kind of heuristics, but at some point (two identical displays) our heuristics are going to fail, because we don't have sufficient knowledge.
Hi Martin, thanks for the explanation, I finally understand the problem, and I agree that having kde guessing is not optimal. Still, in the case we are discussing here, there is a configuration with one output screen and one touch input. All works smoothly until, at some point, a second screen is added. The only correct behavior here (regardless of whether a new touch device appears together with the new screen) is clearly to properly offset all inputs from the "old" touch according to the positioning of the new screen. I don't think one needs any sophisticated heuristics here. I guess things get more complicated if, after hot-plugging, I reboot with the second monitor connected, since then the system sees two screens and one touch and has no robust way to pair them. But then, if the system does not provide the info itself, why not asking the user? If given the opportunity, I would be happy to touch "HDMI1" and help KDE determine that it needs to be connected to "/dev/input/event7". I expect most people to use a limited number of screen configurations, so the results of these manual calibrations could very likely be saved and reused.
@Andrea: why do you insist that we should do something about it? You even agree that us guessing is not optimal? Why are you asking us for writing code which will break, which will be broken while the code could be implemented in a different layer which doesn't have these problems? This code does not belong to us, it's something the display server needs to take care of. It belongs to X and the Wayland compositors.
@Martin because other DE do not have this problem. If this were really something inherently missing upstream and impossible to solve, as you say, everybody would have the same problem. So, setting aside the discussions on whose design is flawed and where the missing functionality should be implemented, I see this apparent impossibility of KDE to implement a workaround as a limitation. YMMV of course, but don't expect me to agree with you as long as plugging a second screen keeps screwing up a perfectly working touch device, because there is no argument you can possibly build that can make this appear as a feature. And I am sorry, but asking users to report bugs or missing functionalities upstream is not a good practice, imvho. When one of my clients reports a bug on my code due to some upstream dependencies, what I do is 1) implement a workaround ASAP and 2) report the bug upstream myself. I believe this is a much more effective development model, but again, YMMV.
> @Martin because other DE do not have this problem. I don't care what GNOME does. If GNOME tried to fix that, it's great for them. But it doesn't mean anything for us. Please don't bring such things up. We are able to evaluate the situation for ourselves. > When one of my clients I assume your clients pay you, right? That's a completely different story Anyway, I'm out of this.
@Martin, the argument "I am not payed to do this and I don't want to, so stop bothering me" is, at last, a very convincing one :) Much more convicing than "we know what's good for the users stop complaining and be happy instead" Since we apparently agree that this has nothing to do with providing a usable DE to your users, I am also happy to close the discussion here.