Created attachment 587446 [details]
Xorg.conf

The xorg used to create a working Twinview setup.

Which version of the NVidia driver is installed/used?

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.

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.

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.

Created attachment 587744 [details]
Test program output

Olivier, here is the output from your attached program.

    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.

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()

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.

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.

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.

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.

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.

After testing all of the screen tablets in my possession, I no longer have this issue.

Verified.

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.

http://rhn.redhat.com/errata/RHBA-2013-0312.html