Bug 826128 - Nvidia Twinview Maps Tablet to Incorrect Screen
Summary: Nvidia Twinview Maps Tablet to Incorrect Screen
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnome-settings-daemon
Version: 6.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Olivier Fourdan
QA Contact: Desktop QE
Depends On:
TreeView+ depends on / blocked
Reported: 2012-05-29 16:29 UTC by Michael Boisvert
Modified: 2013-03-04 02:50 UTC (History)
4 users (show)

Fixed In Version: gnome-settings-daemon-2.28.2-23.el6
Doc Type: Bug Fix
Doc Text:
On some tablets, using the NVIDIA Graphics drivers to configure Twinview causes the tablet motions to be incorrectly mapped to the laptop screen instead of the tablet itself. Using the stylus on the tablet moves the cursor on the laptop screen.
Clone Of:
Last Closed: 2013-02-21 08:24:10 UTC
Target Upstream Version:

Attachments (Terms of Use)
Debug logs (23.03 KB, text/plain)
2012-05-29 16:29 UTC, Michael Boisvert
no flags Details
Xorg.conf (1.84 KB, text/plain)
2012-05-29 16:30 UTC, Michael Boisvert
no flags Details
Test program output (439 bytes, text/plain)
2012-05-30 14:15 UTC, Michael Boisvert
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0312 0 normal SHIPPED_LIVE gnome-settings-daemon bug fix and enhancement update 2013-02-20 20:35:14 UTC

Description Michael Boisvert 2012-05-29 16:29:09 UTC
Created attachment 587445 [details]
Debug logs

Description of problem:

I have a Wacom 21UX tablet connected to a Dell laptop with a Quadro FX 3700M. When using the Nvidia Graphics drivers to configure Twinview, the tablet motions are incorrectly mapped to the laptop screen instead of the tablet itself. So using the stylus on the tablet moves the cursor around on the laptop screen.

When used as the only monitor, it works fine.

How reproducible:

Steps to Reproduce:
1. Install Nvidia graphics drivers
2. Configure a Twinview setup
3. Try to use the tablet
Actual results:
The tablet's graphic motions are displayed on the laptop monitor instead of the tablet itself. If you try to calibrate the tablet, the calibration window is placed on the laptop screen etc.

Expected results:
The tablet's pen should move the cursor on the tablets screen and all graphic motions should be displayed correctly on the tablet when used in a twinview setup.

Additional info:
Testing on the newer Cintiq 21UX2 showed a correctly mapped display when using the same setup.

Comment 1 Michael Boisvert 2012-05-29 16:30:53 UTC
Created attachment 587446 [details]

The xorg used to create a working Twinview setup.

Comment 5 Olivier Fourdan 2012-05-29 20:49:35 UTC
Which version of the NVidia driver is installed/used?

Comment 6 Olivier Fourdan 2012-05-30 07:28:04 UTC
From what I see in the xorg.conf, the version of NVidia is 295.53 and the layout is 2 monitors, DFP-1 being placed to the right of DFP-0 which is 1440 pixels wide.

Looking at the g-s-d debug logs, the layout matches and the EDID of each monitor is rightfully retrieved and parsed:

** (gnome-settings-daemon:3369): DEBUG: Failed to create GnomeRRScreen: Existing but partial RANDR extension ignored

  That's normal, precisely it shows that the NVidia driver does not support XRandR 1.2 nor 1.3 (which causes the Wacom plugin to use its own nv-control aware routines).

** (gnome-settings-daemon:3369): DEBUG: Checking for match between 'WAC','4116','808530744' and 'LPL','0','0'
** (gnome-settings-daemon:3369): DEBUG: Checking for match between 'WAC','4116','808530744' and 'WAC','4116','808530744'

  The EDID is retrieved and parsed correctly, one monitor is a LG Philips (LPL) and the other one is the Wacom tablet, g-s-d finds the match for the tablet.

** (gnome-settings-daemon:3369): DEBUG: Area: 1440,0 1600x1200
** (gnome-settings-daemon:3369): DEBUG: Matrix is 0.526316,0.000000,0.473684,0.000000,1.000000,0.000000,0.000000,0.000000,1.000000.
** (gnome-settings-daemon:3369): DEBUG: Applying matrix to device...

And applies the correct area to match the Wacom which is placed tight ofthe laptop monitor, ie at 1440 pixels. The Wacom resolution is believed to be 1600x1200 which seems correct.

So I don't really see any obvious problem with these logs. One thing though, I am somehow surprised that the matching is including the product/serial as automatic matching would have tried to match ("WAC", NULL, NULL) (any Wacom monitor, that's the find_output_by_heuristic() routine in gsd-wacom-device.c) whereas here it uses actual product/serial.

Comment 7 Olivier Fourdan 2012-05-30 07:44:36 UTC
The full matching is expected if the GConf database already contains a matching display key (as it tries a full matching and will only use the heuristic matching if no match is found and we're dealing with a screen tablet).

So all seems fine in the logs.

Comment 8 Michael Boisvert 2012-05-30 13:12:25 UTC
Also, I tried the 21UX on VGA and display port and it did the same on each connection. I also tested the 24HD and re-tested the 21UX2. I am getting the same failing results.

Comment 10 Michael Boisvert 2012-05-30 14:15:24 UTC
Created attachment 587744 [details]
Test program output

Olivier, here is the output from your attached program.

Comment 12 Martin Prpič 2012-05-31 08:55:54 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    New Contents:
On some tablets, using the NVIDIA Graphics drivers to configure Twinview causes the tablet motions to be incorrectly mapped to the laptop screen instead of the tablet itself. Using the stylus on the tablet moves the cursor on the laptop screen.

Comment 13 Olivier Fourdan 2012-05-31 11:16:59 UTC
I think I know what happens here.

If the device is plugged via USB before the video connection is made, the GNOME settings daemon will try find a match automatically for the screen tablet, but since the video is not connected (or activated in nvidia-settings) yet, there is no match for EDID and it will falls back to the only monitor available, the one of the laptop (LPL in this case).

The (wrong) display value is then saved in the settings so that even when the Cintiq monitior is connected and enabled, the wrong value is still pick by the daemon as the existing value takes precedence on automatic mapping (which occurs only when no display value is set).

This happens most notably when using the NVidia driver because it won't enable an output automatically until it's enaled with nvidia-settings, thus making the issue more likely to happen.

The fix is fairly simple:

1. Do not fallback to any single output if no match is found using EDID matching for Wacom in find_output_by_heuristic().

2. Instead, search a single output as fallback value in find_output() if find_output_by_heuristic() did not return any value, yet do not save that value to the settings database so that automatic discovery has a chance again next time.

This explanation above is actually longer than the actual patch wich is just moving the call to find_single_output() from find_output_by_heuristic() to find_output()

Comment 14 Olivier Fourdan 2012-05-31 11:18:39 UTC
Note: Workaround is simple, unset the "display" value in GConf for the tablet using either gvontftool-2 or gconf-editor so that automatic mapping can occur.

Comment 15 Olivier Fourdan 2012-05-31 11:30:05 UTC
Other possibility to avoid the issue, when setting up a new screen tablet, make sure to connect, configure and enable the display in X before plugging the USB.

Comment 19 RHEL Program Management 2012-07-10 08:15:43 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 20 RHEL Program Management 2012-07-10 23:21:09 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 22 RHEL Program Management 2012-08-10 15:38:59 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 27 Michael Boisvert 2013-01-10 18:55:18 UTC
After testing all of the screen tablets in my possession, I no longer have this issue.


Comment 29 errata-xmlrpc 2013-02-21 08:24:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.