After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782032 - Unable to map Wacom tablet to second monitor
Unable to map Wacom tablet to second monitor
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 783752 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-05-01 21:00 UTC by Jason Gerecke
Modified: 2017-06-29 23:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backends: Fix typo (1.12 KB, patch)
2017-06-16 17:48 UTC, Carlos Garnacho
committed Details | Review
backends: Fix output cycling in non display-attached tablets (1012 bytes, patch)
2017-06-16 17:49 UTC, Carlos Garnacho
committed Details | Review

Description Jason Gerecke 2017-05-01 21:00:24 UTC
The tablet correctly maps to the entire desktop when the "Map to single monitor" option is disabled, and can be mapped to the first display without issues by either selecting the output from the list, or assigning an ExpressKey to the "Switch monitor" action. It fails to map to my second monitor for some reason, however. No change in mapping is noticed when selecting the second monitor from the list or pressing the "Switch monitor" button a second time. The mapping appears to be "stuck" on the first monitor.

The `/org/gnome/desktop/peripherals/tablets/$VID:$PID/display` key appears to update properly. The output of `xinput watch-props` indicates that the X server is notified of that a change is desired, but regardless of the display chosen, the Matrix is repeatedly set to the first monitor:

````
# First display chosen
Property 'Coordinate Transformation Matrix' changed.
	Coordinate Transformation Matrix (149):	0.500000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Property 'Wacom Tablet Area' changed.
	Wacom Tablet Area (280):	0, 0, 44800, 29600

# Second display chosen
Property 'Coordinate Transformation Matrix' changed.
	Coordinate Transformation Matrix (149):	0.500000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Property 'Wacom Tablet Area' changed.
	Wacom Tablet Area (280):	0, 0, 44800, 29600
````

System Info
--------------
Arch Linux
gnome-control-center 3.24.1-1
gnome-settings-daemon 3.24.1+7+g42f75ed4-1
mutter 3.24.1+1+geb394f19d-1
xf86-input-wacom 0.34.2-1
xorg-server 1.19.3-2

Left Display: ['WAC', 'Cintiq 24HDT', '2BANP00035']; 1920x1200+0+0
Right Display: ['WAC', 'DTH-2242', '2KDQS00028  ']; 1920x1080+1920+0

Xorg session
Comment 1 Jason Gerecke 2017-05-01 23:31:52 UTC
I've further tested this under a Wayland session and find that it behaves the same. The tablet can map to the entire desktop or the left display, but not the right display.
Comment 2 Tyson Tan 2017-05-13 10:13:37 UTC
I can confirm the same issue happens on Ubuntu Gnome 17.04 and Manjaro Gnome 17.0.1. Both of them uses Gnome 3.24.
Comment 3 Carlos Garnacho 2017-06-16 17:46:09 UTC
Seems to happen since the introduction of logical monitors (https://bugzilla.gnome.org/show_bug.cgi?id=779745). My bad, I reviewed the tablet bits there on IRC and missed some things.
Comment 4 Carlos Garnacho 2017-06-16 17:48:57 UTC
Created attachment 353909 [details] [review]
backends: Fix typo

Instead of checking all MetaMonitors in the monitor manager, we want to
look (as the function name says) in the MetaMonitors contained in the
given logical monitor.

Otherwise, it will return TRUE for every logical monitor, given we are
querying for an existing EDID.
Comment 5 Carlos Garnacho 2017-06-16 17:49:03 UTC
Created attachment 353910 [details] [review]
backends: Fix output cycling in non display-attached tablets

It would only allow to alternate between the logical monitors, we actually
want to return NULL here so it can cycle to the whole span of monitors.
Comment 6 Jason Gerecke 2017-06-16 20:11:34 UTC
Confirmed that these patches fix the mapping issue under Wayland. It also works under X11, though if I use a pad button mapped to the "switch monitor" action rather than the "Map to Monitor..." button in g-c-c, Xorg crashes shortly after bringing the pen into proximity and moving it towards an edge.

My system is running several packages with patches applied (including all of the mutter and g-c-c patches you just posted here and in 782040, 782027, 781703) so there's a chance of this being some kind of bad interaction... Could you possibly test the "switch monitor" action under Xorg to see if it causes a crash for you with these patches?
Comment 7 Carlos Garnacho 2017-06-16 21:27:46 UTC
I can confirm the crash... wonder how is it related though, from the bt I see in journald (sadly coredumpd didn't do its job) code paths seem fairly unrelated.

Process 1418 (Xorg) of user 1000 dumped core.
                                               
Stack trace of thread 1432:
#0  0x00007fc4def7cfb6 drmmode_set_cursor.isra.17 (modesetting_drv.so)
#1  0x00000000004af913 xf86_set_cursor_position (Xorg)
#2  0x00000000004ba532 xf86MoveCursor (Xorg)
#3  0x00000000005842fb miPointerMoveNoEvent (Xorg)
#4  0x00000000005850c9 miPointerSetPosition (Xorg)
#5  0x000000000044bf6e positionSprite.part.8 (Xorg)
#6  0x000000000044c710 fill_pointer_events (Xorg)
#7  0x000000000044df4f GetPointerEvents (Xorg)
#8  0x000000000044e4f0 QueuePointerEvents (Xorg)
#9  0x0000000000486236 xf86PostMotionEventP (Xorg)
#10 0x00007fc4d8ca93cd wcmSendEvents (wacom_drv.so)
#11 0x00007fc4d8caa6e0 wcmEvent (wacom_drv.so)
#12 0x00007fc4d8cafb6e usbParse (wacom_drv.so)
#13 0x00007fc4d8ca7f7f wcmReadPacket (wacom_drv.so)
#14 0x00007fc4d8ca81b6 wcmDevReadInput (wacom_drv.so)
#15 0x000000000059a983 InputReady (Xorg)
#16 0x000000000059cff1 ospoll_wait (Xorg)
#17 0x000000000059a7ce InputThreadDoWork (Xorg)
#18 0x00007fc4e27b336d start_thread (libpthread.so.0)
#19 0x00007fc4e24ebe9f __clone (libc.so.6)
                                               
Stack trace of thread 1418:
#0  0x00007fc4e24ec403 epoll_wait (libc.so.6)
#1  0x000000000059cfa4 ospoll_wait (Xorg)
#2  0x000000000059603b WaitForSomething (Xorg)
#3  0x00000000004355e3 Dispatch (Xorg)
#4  0x0000000000439850 dix_main (Xorg)
#5  0x00007fc4e23fb4da __libc_start_main (libc.so.6)
#6  0x000000000042357a _start (Xorg)
Comment 8 Carlos Garnacho 2017-06-16 21:53:01 UTC
And actually... I also get the crash without these patches.
Comment 9 Jason Gerecke 2017-06-16 22:14:26 UTC
I'd also noticed the crash without the patches and thought it might be a further symptom of odd patches being applied... Good to know its not just my system. Agreed that the crash doesn't seem to make much sense. I managed to catch it in GDB by attaching to Xorg.

Looks like the issue is due to xf86CurrentCursor returning a NULL pointer just before we try to dereference it in frame 0.


Thread 3 "InputThread" received signal SIGSEGV, Segmentation fault.

Thread 140328094074624 (LWP 3472)

  • #0 drmmode_set_cursor
    at drmmode_display.c line 767
  • #1 drmmode_show_cursor
    at drmmode_display.c line 843
  • #2 xf86_crtc_show_cursor
    at xf86Cursors.c line 340
  • #3 xf86_crtc_set_cursor_position
    at xf86Cursors.c line 451
  • #4 xf86_set_cursor_position
    at xf86Cursors.c line 468
  • #5 xf86ScreenMoveCursor
    at xf86HWCurs.c line 306
  • #6 xf86MoveCursor
    at xf86HWCurs.c line 322
  • #7 xf86CursorMoveCursor
    at xf86Cursor.c line 424
  • #8 miPointerMoveNoEvent
    at mipointer.c line 567
  • #9 miPointerSetPosition
    at mipointer.c line 669
  • #10 positionSprite
    at getevents.c line 984
  • #11 fill_pointer_events
    at getevents.c line 1457
  • #12 GetPointerEvents
    at getevents.c line 1714
  • #13 QueuePointerEvents
    at getevents.c line 1313
  • #14 xf86PostMotionEventM
    at xf86Xinput.c line 1278
  • #15 xf86PostMotionEventP
    at xf86Xinput.c line 1172
  • #16 0x00007fa0ae3387c1 in
  • #17 0x00007fa0ae339b14 in
  • #18 0x00007fa0ae33f807 in
  • #19 0x00007fa0ae33739b in
  • #20 0x00007fa0ae3375d6 in
  • #21 xf86ReadInput
    at xf86Events.c line 261
  • #22 InputReady
    at inputthread.c line 180
  • #23 ospoll_wait
    at ospoll.c line 412
  • #24 InputThreadDoWork
    at inputthread.c line 367
  • #25 start_thread
  • #26 clone

Comment 10 Carlos Garnacho 2017-06-20 20:20:53 UTC
The patches are now on master and gnome-3-24.

I think there's enough clues that the Xorg crash is unrelated :), I'm leaving the bug link in my todo list to investigate the crash, but will close this bug already. Please reopen if reality proves me wrong.

Attachment 353909 [details] pushed as dc5b2e3 - backends: Fix typo
Attachment 353910 [details] pushed as 9b9bb9c - backends: Fix output cycling in non display-attached tablets
Comment 11 Carlos Garnacho 2017-06-29 23:10:56 UTC
*** Bug 783752 has been marked as a duplicate of this bug. ***