When using a touchscreen display in a multihead-setup the touch event coordinates are currently calculated wrongly because they are mapped to the whole display and not to the part which is displayed on the touchscreen only. To fix this the X system needs to be told how to map the coordinates. Some background information can be found here: https://wiki.ubuntu.com/X/InputCoordinateTransformation Benjamin Tissoires, who´s one of the maintainers of the usbhid-module of the Linux kernel, explained it to me like this: >> Basically, you need to tell Xorg how your device is mapped to your >> displays. Integrating this in the window Manager is the thing to do >> because it knows how the displays are mapped and how they are rotated, For Gnome, the problem was fixed in v3.12; the bug report in which the problem was tracked was https://bugzilla.gnome.org/show_bug.cgi?id=709600 (But there is a lot of history in Gnome as they supported this feature for Wacoms already) Currently I´m manually using the xinput command to achieve the desired behavior like so (after the touchscreen is attached): ~> xinput set-prop 15 'Coordinate Transformation Matrix' 0.54545455 0 0.45454545 0 1 0 0 0 1 (with 15 being the X device id of the touchscreen). Unless one uses rotations, calculating the matrix (three rows with three values each; that´s why there are 9 numbers in the command line shown above) isn´t really complicated: {screen_width / total_width} {0} {offset_x / total_width}, {0} {screen_height / total_height} {offset_y / total_height}, {0} {0} {1} with screen_width/height being the resolution of the touchscreen, total_width/height being the total resolution of the virtual screen (so laptop + touchscreen), and offset_x/y being the positions of the touchscreen within the total space (0,0 if your screen is at the left of your laptop; laptop_width,0 if it is on the right). Reproducible: Always Current behavior tested on openSUSE 13.1 / KDE 4.11.5
To me this looks like kscreen material, but I am not sure.
"Depends" on what is the bug here. I could think of a zoomed display might require a special mapping. Other than that I would have guessed that this is the device drivers job (eg. the egalax drivers do this), but I also guess, the driver cannot make calls to the server. (egalax has a daemon running) This: Integrating this in the window Manager is the thing to do because it knows how the displays are mapped and how they are rotated is "wrong", the screen setup is public knowledge - every X client can - and quite some do - query it. Now, the question is what is actually required here: (The gnome patch seems to perform a heuristic check on what is a touchscreen) * If the user needs to adjust mapping parameters, i'd say that the mouse kcm would provide them? * the kscreen daemon seems most reasonable to listen to screen setup changes (does so anyway) and update the matrix * kwin should imo only update the matrix if that is required for visual screen transformation (zoom effect) since otherwise we'd end up with input configuration in the windowmanager or you'd configure input mapping and it fails when replacing kwin by compiz/openbox/fvwm/sawfish/whatever FYI, "Multihead" points the zaphod setup - no way nearly related ;-)
to me it looks out-of-scope for KWin, also out of scope for kscreen. In GNOME it was reported against gnome-settings-daemon/wacom. I think it should also be moved to a product for touchpads (if that exists). Obviously WONTFIX is a viable option given that it is a corner case setup using multi-head (which is and has been unmaintained in KDE for years).
> given that it is a corner case setup using multi-head I don't think it is, rather the opposite. If the wacom device was an extra head, there'd probably be no mapping requirement at all. iiuc, the issue is that one "screen" is a touchdevice, the other is not. The server needs to be informed what region map touch inputs to - this smells like root coordinate mapping (thus no issue with multihead)
> > given that it is a corner case setup using multi-head > > I don't think it is, rather the opposite. If the wacom device was an extra > head, there'd probably be no mapping requirement at all. > > iiuc, the issue is that one "screen" is a touchdevice, the other is not. The > server needs to be informed what region map touch inputs to - this smells > like root coordinate mapping (thus no issue with multihead) Sorry, got confused by the initial chosen component and trusted that multihead means multihead
Have similar issue too. I have a laptop with touchscreen display, which works fine, until add external monitor. So i need manualy update touch area offset and scale, to fit only primary screen. It will be realy great, if i could do it by GUI in KDE display settings. Or may be there is a way, to associate touchscreen input device to self screen.
Same problem here, and since quite a long time (was there ins plasma4, still there in plasmashell). I understand that all the discussions about where it is "right" to implement this feature are important. Wouldn't it be possible in the meantime to provide a script or some UI *anywhere* to fix this bug? Maybe just using under the hood the xinput hack suggested above? This is making touchscreens completely unusable everytime a second screen is connected. Also: why exactly is this still "UNCONFIRMED"? The comments here point to the fact that it is a known problem...
out of scope for KWin/X11 -> RESOLVED WONTFIX
Just to report here, for people finding this report, that there is a followup bug on plasmashell (kde5) reporting the same problem, which hopefully will find a better resolution (Bug 346795)
Rather the same issue - "out of scope". This isn't something to be performed/"fixed" by some application - the coordinate transformation happens in X11 (resp. wayland somewhen later) You basically want a config module to calibrate this. It *might* be added to the KScreen config and daemon *if* the touchscreen is detectable as touchscreen - otherwise it makes no sense there as well.
I am no expert here, but it seems to me that if you dig enough, everything happens in X11, at some point. Even when I attach the second screen, and I tell to kde's display manager if I want it on top to the left or to the right of my main screen and so on, I am at some deeper level performing the same operations I used to do on text xconfig files some years ago. KDE just takes over the task of talking to x11 for me. So from my point of view the issue is this: kde's display manager allows me to configure the second screen, but it does not correct the touchscreen mapping accordingly. This is a wrong configuration of the second display. It is a bug of the display manager, sorry, and there is no design/architectural/technical argument that can make it look like a feature instead. If you want to configure the second display at my place, you must to it properly (whenever it is possible, and in this case it clearly is, since a one-line xinput command would solve everything). You say the issue may be that the touchscreen is not detectable. Ok then allow the users, on the display manager, to specify which screen are touch-sensitive (a small clickable icon like the "rotate" one would be adequate). But still the display manager has to correct the touch mapping according to the actual screen configuration, since this *is* part of the display configuration. jm2c, Andrea.
(In reply to Andrea from comment #11) > I am no expert here, but it seems to me that if you dig enough, everything > happens in X11, at some point. > > Even when I attach the second screen, and I tell to kde's display manager if rest assured that KDM is for sure not the proper component here. And that is the problem, you -as mentioned- hope for a kscreen kcm (whether that's the proper solution or not), but file bugs against the window manager and the desktop shell as if this could/should be handled in a particular client, which is totally unrelated to the task but probably randomly running anyway. And there's the next misconception: oc. everything GUI related *talks* to the X11 server (being the display server), but this is somewhat about *configuring* the X11 server, XInput in particular. And then the final issue: you do not actually want this for some desktop environment, but also at the display server (whether xdm, gdm, kdm, sddm, ...) level ie. a rather KDE-free daemon starting w/ Xorg that monitors randr and reconfigures the input (the proprietary egalax driver operates this way)
(In reply to Thomas Lübking from comment #12) > but file bugs against the window manager > and the desktop shell as if this could/should be handled in a particular > client, which is totally unrelated to the task but probably randomly running > anyway. Sorry if this is not the right component. When this happens to me on some bugtracking systems I manage, common practice is to redirect the submitters to the proper component, rather than trying to convince them that the problem they have is no problem at all :) > you do not actually want this for some desktop environment, but also at the > display server (whether xdm, gdm, kdm, sddm, ...) level ie. a rather > KDE-free daemon starting w/ Xorg that monitors randr and reconfigures the > input (the proprietary egalax driver operates this way) Ok, I understand your argument. But then, if this is valid, I think KDE should add to its feature list that touchscreen is not supported in multi-display setups. Because other desktops do properly configure the touchscreen. The (perfectly valid) reasons why KDE chooses not to do so are rather irrelevant for the end user, as long as you properly advertise the final result you achieved.
> Sorry if this is not the right component. When this happens to me on some > bugtracking systems I manage, common practice is to redirect the submitters > to the proper component, rather than trying to convince them that the > problem they have is no problem at all :) Well the problem is, that (at least the KWin devs) think that this is in general out of scope for any component provided by KDE. So there is no component we could have moved the bugreport to. > Ok, I understand your argument. But then, if this is valid, I think KDE > should add to its feature list that touchscreen is not supported in > multi-display setups. Because other desktops do properly configure the > touchscreen. The (perfectly valid) reasons why KDE chooses not to do so are > rather irrelevant for the end user, as long as you properly advertise the > final result you achieved. We do not have such lists to add this.
Stupid questions a) does xinput --map-to-output <INPUT ID> <SCREEN NAME> ie. eg. xinput --map-to-output 13 LVDS1 "stick" for you, ie. is the mapping persistent? The wacom X11 driver seems to know a MapToOutput Option for its Device section as well? b) does rotating the screen w/ the kscreen kcm "fix" the input rotation as well? (If it "just works", try by rotating "xrandr -o left", "xrandr -o normal" to reset)