Touchscreen controls both screens in dual-monitor setup

Did this work correctly in 13.10?

@Maarten: I did not try 13.10, but I did try in 12.04. It was broken in 12.04 too.

@Steve: please attach the output of the following commands:

xinput list

Then look at the output and see what id matches your touchscreen (e.g. id=12), and finally type:

xinput list-props $the_id_you_found

@Alberto:

steve@aether:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SYNAPTICS Synaptics Large Touch Screen id=12 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ Integrated_Webcam_HD id=13 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)]
    ↳ Dell WMI hotkeys id=16 [slave keyboard (3)]
    ↳ Integrated_Webcam_HD id=9 [slave keyboard (3)]

steve@aether:~$ xinput list-props 12
Device 'SYNAPTICS Synaptics Large Touch Screen':
 Device Enabled (135): 1
 Coordinate Transformation Matrix (137): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (260): 0
 Device Accel Constant Deceleration (261): 1.000000
 Device Accel Adaptive Deceleration (262): 1.000000
 Device Accel Velocity Scaling (263): 10.000000
 Device Product ID (252): 1739, 2808
 Device Node (253): "/dev/input/event12"
 Evdev Axis Inversion (264): 0, 0
 Evdev Axis Calibration (265): <no items>
 Evdev Axes Swap (266): 0
 Axis Labels (267): "Abs MT Position X" (283), "Abs MT Position Y" (284), "None" (0), "None" (0)
 Button Labels (268): "Button Unknown" (256), "Button Unknown" (256), "Button Unknown" (256), "Button Wheel Up" (141), "Button Wheel Down" (142)
 Evdev Middle Button Emulation (269): 0
 Evdev Middle Button Timeout (270): 50
 Evdev Third Button Emulation (271): 0
 Evdev Third Button Emulation Timeout (272): 1000
 Evdev Third Button Emulation Button (273): 3
 Evdev Third Button Emulation Threshold (274): 20
 Evdev Wheel Emulation (275): 0
 Evdev Wheel Emulation Axes (276): 0, 0, 4, 5
 Evdev Wheel Emulation Inertia (277): 10
 Evdev Wheel Emulation Timeout (278): 200
 Evdev Wheel Emulation Button (279): 4
 Evdev Drag Lock Buttons (280): 0

Seb wrote in an email:

"In fact discussing a bit on IRC and looking at
https://bugzilla.gnome.org/show_bug.cgi?id=698284 it might not be as easy

Xorg/the hardware doesn't give us a way to determine that an input
system is linked to a screen. It's easy enough when you have 1 of each
to match them, it's less trivial if you have e.g 2 screens and an input
device. We can probably come up with some heuristics for common cases
(like assuming that if you have a laptop screen and an external monitor
and a touch input, that's probably the laptop screen one) but not sure
how well that's going to work..."

Related discussion in #ubuntu-desktop

18:24 < seb128> "we don't map touchscreens to an output, we map it to a portion of the desktop."
18:24 < seb128> " don't know how to fix this other than a database in the style of libwacom"
18:24 < tjaalton> that doesn't sound too promising..
18:24 < mlankhorst> probably needs to happen :/
18:26 < bregma> big problem with a generalized solution to that touchscreen problem is that there is no association between the touch device and the display
18:26 < mlankhorst> yeah..
18:27 < bregma> not even at the kernel level
18:28 < mlankhorst> but for now assuming touchscreen maps to the eDP or integrated screen would be best bet :/
18:29 < bregma> it would makea reasonable starting default but isn't anything like a good solution since there are lots of external touchscreens out there
18:30 < seb128> yeah
18:31 < mlankhorst> how are they handled on other platforms?
18:31 < seb128> it would also mean that if I dock my 3 years non-touch laptop on an external touch monitor things would be the wrong way around
18:31 < tjaalton> but confirmed..
18:31 < tjaalton> *bug
18:31 < mlankhorst> tjaalton: which?
18:31 < tjaalton> the touch one
18:32 < mlankhorst> ah
18:32 < tjaalton> i've got this lovely harris beach sdp..
18:32 < bregma> mlankhorst, how are they handled on other platforms? poorly, just like high-DPI
18:32 < tjaalton> now excuse me while it dist-upgrades trusty->trusty for the next two hours..
18:33 < tjaalton> hmm I have win8 on this too
18:35 < mlankhorst> could we make it a ui thing perhaps?
18:36 < mlankhorst> let the user suffer for next few years until things standardize :/

Just as an update, I'm working on some code that will detect the touch screen, couple it with the laptop's screen, and map the touch input device onto the output whenever the screen configuration changes (e.g. on rotations, when new outputs become available, etc.). This won't require any user interaction.

I already have a prototype that solves the use case mentioned in this bug report.

Apparently upstream also has code that fixes the same issue and covers more use cases. It doesn't seem like a small amount of code though. For this reason I'll take some time to see if a backport is possible or recommended over using my current implementation.

I've gone through all the relevant upstream commits, and here are my conclusions:

1) The upstream code covers the use case of Wacom tablets with built-in displays (which, although useful, is not the use case discussed in this bug report). It would be way too much code to backport, especially for an SRU.

2) The upstream code covers the use case mentioned in the original description of this bug report, but I think backporting the new GsdDeviceMapper (a tool to couple input devices with displays) to unity-settings-daemon would be an overkill, just for this single use case. This said, introducing the GsdDeviceMapper is something definitely worth exploring, as a long term plan.

3) I can provide a fix for the use case in the original description with a much smaller amount of code. For this reason I'm going to complete and integrate my current prototype with the unity-settings-daemon. The result will be effective and good for an SRU.

I've built packages for both i386 and amd64 with my fix. You will find them here:

http://people.canonical.com/~amilone/lp1287341/

Please install the package for your architecture, then log out, log back in, and try to reproduce the problem.

It would be interesting to test my fix on laptops with a touchscreen and on all-in-one desktop systems that have a touchscreen.

@Alberto: The package in http://people.canonical.com/~amilone/lp1287341/ fixes the behavior of the touchscreen for me. The touschreen now works as expected with and without an external monitor. Tested on a Dell XPS13 with factory-installed touchscreen.

Thanks!

It works for me :)

Lenovo Yoga 2 Pro with 32-bit Ubuntu 14.04.

Hi, I tested it on Dell OptiPlex 9030 AIO with 64-bit Ubuntu 14.04, but it doesn't work.
The touchscreen remaps to the whole extended screen.
I tried to re-login, reboot the system, and re-plug the hdmi cable, the symptom is the same.

ii unity-settings-daemon 14.04.0+14.04.20140414-0ubuntu1.1 amd64 daemon handling the Unity session settings

@Acelan: please download the following binary, run it on that system, and attach the output:

http://people.canonical.com/~amilone/simple-xinput

Also please attach your /var/log/Xorg.0.log and the output of the "xinput list --long" command.

Note: in this case there's no need to reproduce the problem before collecting the data, this is just to see what type of touchscreen we're dealing with.

Here comes the logs

ok, what happens if you type:

killall unity-settings-daemon

unity-settings-daemon --debug &> mylog.log

then reproduce the problem and attach the log

The problem with all-in-one systems that don't use connectors such as eDP is that we don't have a generic way to match the display with the input device. This means that we have to quirk such systems using the display EDID and the input controller.

AceLan: please attach the output of the following commands for all the all-in-one systems you have available (with no external screens connected):

1) xrandr --verbose
2) xinput list --long
3) /var/log/Xorg.0.log

You can collect the data using a livecd of Ubuntu 14.04

Tested on Dell Inspiron 20 Model 3048, it works well.

Dell Inspiron 20 Model 3048 is an All-in-One system : ftp://ftp.dell.com/Manuals///all-products/esuprt_desktop/esuprt_inspiron_desktop/inspiron-20-3048-aio_Owner%27s%20Manual_en-us.pdf

Yes, the Dell Inspiron 20 Model 3048 works without quirks because it uses an eDP connector.

I've just implemented a quirks system which should fix the Dell OptiPlex 9030 AIO and possibly other Dells with similar specs.

Please try the updated packages available here:
http://people.canonical.com/~amilone/lp1287341/

Here comes the Inspiron 2350 AIO log

Ok, I've corrected the quirk for the OptiPlex and I've added one for the Inspiron 2350.

Please try the updated packages available here:
http://people.canonical.com/~amilone/lp1287341/

The latest unity-settings-daemon fix this issue on Dell OptiPlex 9030.
The touchscreen works well when connects an external monitor and it still works well after rotate the screen.

It works on Dell OptiPlex 9030 AIO

Just an update: I've backported a system that should work better than single quirks. This is also what AceLan tested for me.

I've made a merge request into the bazaar branch of unity-settings-daemon, so that my code can be reviewed and accepted into 14.10. As soon as the merge is complete, we'll backport the feature to 14.04 (it's the same codebase).

This bug was fixed in the package unity-settings-daemon - 14.04.0+14.10.20140604-0ubuntu1

---------------
unity-settings-daemon (14.04.0+14.10.20140604-0ubuntu1) utopic; urgency=medium

  [ Alberto Milone ]
  * gsd-xrandr-manager.c:
    - Add support for mapping the main touchscreen onto the laptop
      display (LP: #1287341).
      This makes sure that the input device knows exactly the area
      that represents the display when the screen configuration
      changes. Note: this doesn't cover the tablet use case.
    - Add support for matching displays with touch input devices
      according to the reported size. This is particularly
      useful on systems that don't use embedded display connectors
      i.e. all-in-one systems such as the Dell Optiplex 9030 AIO.
    - This work is a partial backport of the upstream work on
      touchscreens. When we finally sync with the upstream code
      we can drop this.
 -- Ubuntu daily release <email address hidden> Wed, 04 Jun 2014 15:42:47 +0000

Hello Steve, or anyone else affected,

Accepted unity-settings-daemon into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/unity-settings-daemon/14.04.0+14.04.20140606-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello,

I was affected by this issue.

After installing unity-settings-daemon 14.04.0+14.04.20140606-0ubuntu1 from trusty-proposed I confirm that this is fixed.

I have tested that the touchscreen in my Dell XPS 13 behaves properly without an external monitor attached, and that it keeps behaving properly after connecting a non-touch external monitor to it.

I will mark this as verification-done

The verification of the Stable Release Update for unity-settings-daemon has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package unity-settings-daemon - 14.04.0+14.04.20140606-0ubuntu1

---------------
unity-settings-daemon (14.04.0+14.04.20140606-0ubuntu1) trusty; urgency=medium

  [ Alberto Milone ]
  * gsd-xrandr-manager.c:
    - Add support for mapping the main touchscreen onto the laptop
      display (LP: #1287341).
      This makes sure that the input device knows exactly the area
      that represents the display when the screen configuration
      changes. Note: this doesn't cover the tablet use case.
    - Add support for matching displays with touch input devices
      according to the reported size. This is particularly
      useful on systems that don't use embedded display connectors
      i.e. all-in-one systems such as the Dell Optiplex 9030 AIO.
    - This work is a partial backport of the upstream work on
      touchscreens. When we finally sync with the upstream code
      we can drop this.
 -- Ubuntu daily release <email address hidden> Fri, 06 Jun 2014 14:39:15 +0000

Status changed to 'Confirmed' because the bug affects multiple users.

Still affects me on 14.04.

As it is already said, there is no reliable way to assign a touch device to a certain display device. So I suggest a two phase design:

1) Check if there is information for making an automatic assignment in some database. If there are more then one equal device, use display output and USB port id for identification.

2) If none is found, select the by some simple heuristics. Then launch a (to be made) settings program, that displays a centered button the first screen "PLEASE TOUCH HERE". If the button is pressed, the coordinates are checked against the center of all possible displays from 'xrandr' or gnome-display-settings information. If it matches, the assignment is stored to the local database. The procedure continues with the second screen, if there is a third one and so on.

If for some reason the database gets outdated (eg the user exchanges screens) phase 2 will be entered autmatically as you see.

The only caveat may be exchanging the output assignments of multiple equal display devices. For this case, the phase 2 program should be integrated into the system settings center, and easily be reached without proper touch operation (eg. launch via Unity by keyboard).

There is a regression of this bug in Ubuntu 20.04 using the default Gnome desktop

Setup is a Shuttle POS P511
using a Weida CoolTouch controller with driver integrated into the Linux kernel
Second screen is a AOC USB-3.1 Display Link monitor without display capabilities only (no touch).

When the AOC screen is disconnected the touch works normally.
When the AOC screen is connected the touch is out of sync and touches over both screens from the Shutlle/Weida screen.

Here is xinput list-props with both screens connected.

xinput list-props 11
Device 'Weida Hi-Tech CoolTouch® System':
 Device Enabled (169): 1
 Coordinate Transformation Matrix (171): 0.500000, 0.000000, 0.500000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Calibration Matrix (308): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Calibration Matrix Default (309): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Send Events Modes Available (291): 1, 0
 libinput Send Events Mode Enabled (292): 0, 0
 libinput Send Events Mode Enabled Default (293): 0, 0
 Device Node (294): "/dev/input/event4"
 Device Product ID (295): 9589, 49920

Here is the xinput list-props while the second screen (AOC) is disconnected
Here the touch works as expected

xinput list-props 11
Device 'Weida Hi-Tech CoolTouch® System':
 Device Enabled (169): 1
 Coordinate Transformation Matrix (171): 0.500000, 0.000000, 0.500000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Calibration Matrix (308): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Calibration Matrix Default (309): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 libinput Send Events Modes Available (291): 1, 0
 libinput Send Events Mode Enabled (292): 0, 0
 libinput Send Events Mode Enabled Default (293): 0, 0
 Device Node (294): "/dev/input/event4"
 Device Product ID (295): 9589, 49920

There is a workaround via

xinput map-to-output "Weida Hi-Tech CoolTouch® System" eDP-1

There needs to be some kind of detection to do this automatically and create a systemD systemctl file.