Created attachment 1242163 [details] Output of xsetwacom --get 9 all Hello, I'm using a wacom tablet Intuos pro with dual monitors of same resolution and model, than right and left of each other. However the virtual space made of both monitor spaces is mapped to the tablet, with no regards for the aspect ratio. It's particularity inconvenient, as of now, drawing a circle yields an ellipse with a 2:1 ratio. Changing anything about monitors in the gnome-control-panel doesn't do alter the behaviour. Weirdly enough, I have a similar issues with key bindings, where the wacom panel of gnome-control-center registers the bindings, but they do not translate into anything when pressing the actual wacom tablet keys. I'm attaching the output of `xsetwacom --get 9 all` to this ticket.
Just to be clear, do you see a "Map to Monitor" button [1] in the Wacom Tablet preferences, and does enabling the "Map to single monitor" checkbox inside do anything? My Fedora 25 testbed (which admittedly has a number of modifications) doesn't seem to react to checking that box with either an Intuos Pro or an Intuos 5.
Yes, I can see a "Map to Monitor Button", I can check/uncheck a box "Map to a single monitor", and I can select which monitor. I configured a button to switch the monitor to use (a configuration that seems to work with buttons unlike key signals), and it even gives the icon pop-up on the correct screen. The options are remembered by the gnome wacom tablet preferences. However regardless of the state of those settings, the driver maps both monitors to the tablet surface, without preserving the aspect ratio.
run xinput watch-props "... the device name..." and change the monitor mapping in the settings. Do you see any changes in the properties? If not, then this is a gnome issue.
I can see the following line emitted three times each time I change the monitor mapping, whether I check/uncheck "Map to single monitor" or I change the monitor. Property 'Wacom Tablet Area' changed. Wacom Tablet Area (288): 0, 0, 44704, 27940 In every case the Area is mapped to the same rectangle (0,0,44704,27940), which I guess correspond the area occupied by both screens.
The following command : xsetwacom xsetwacom --set 'Wacom Intuos Pro M Pen stylus' 'MapToOutput' 'DVI-I-1' where DVI-I-1 is one of the displays reported by `xrandr -q` (and gnome-settings), does not work, with the following error : Unable to find an output 'DVI-I-1'. However, hardcoding the screen coordinates, as below, do work. xsetwacom --set 'Wacom Intuos Pro M Pen stylus' 'MapToOutput' 1680x1050+1680+0 I guess gnome-settings tries somehow to let libwacom to autoguess the display's screen coordinates and do a call of something only the display names, hence fails for the same reason than xsetwacom.
libwacom is a tablet description library only, it does nothing at runtime. Either way, this is weird, what's the output of xrandr -q? are you using the nvidia binary driver? Is this something that recently broke? I wonder if there's a regression somewhere
Created attachment 1244196 [details] Output of xrandr -q I admit I making blind guesses, I don't know what's wrong. It just seems strange to me that xsetwacom and the wacom gnome-settings have the same error. I do indeed use the nvidia binary driver, version 375.26 on a GTX970. The computer on which I have dual monitors is a recent one; I installed Fedora two weeks ago. I'm creating a new attachement containing the output of `xrandr -q`.
if you run xsetwacom --verbose ... you should get a lot of debug statements, that may show us where the bug is. right now my guess is: xsetwacom has code to detect the binary driver. Check if NV-CONTROL is present in xdpyinfo -queryExtensions. If that's the case, we switch to xinerama instead of xrandr which may cause the bug. xdpyinfo -ext XINERAMA should list the info we use, maybe that's out of sync. Try xinput map-to-output, that doesn't have the nvidia code and always uses xrandr. if that works, we've narrowed it down. GNOME has that same NV code, iirc.
Created attachment 1244649 [details] Output of `xdpyinfo -ext XINERAMA` I found two lines interesting in the output of `xsetwacom --verbose --set 'Wacom Intuos Pro M Pen stylus' 'MapToOutput' DVI-I-1`, ... Display is '(null)', and ... RandR extension not found, too old, or NV-CONTROL extension is also present. Indeed NV-CONTROL is also present, as running `xdpyinfo -queryExtensions | grep -i nv-control` yields : NV-CONTROL (opcode: 155, base event: 120) I attached the output of `xdpyinfo -ext XINERAMA`. The last three lines about xinerama are : XINERAMA version 1.1 opcode: 140 head #0: 1680x1050 @ 1680,0 head #1: 1680x1050 @ 0,0
Just a note: xsetwacom does not support the version of the RandR extension used by the binary nVidia driver. As indicated in the xsetwacom man page, you have to use output names like "HEAD-0", "HEAD-1", etc. instead which causes the driver to use Xinerama instead. I think the xsetwacom issue might be a red herring. My test box experiences the same issue under GNOME, but `xsetwacom set <id> maptooutput DVI-I-1` is able to map the display properly (it uses the nouveau driver, not the binary driver).
punting this to gsd. xinput watch-props shows that the only thing happens when I select any map-to-monitor for the intuos5 is that the "Wacom Tablet Area" property is set to the same values Property 'Wacom Tablet Area' changed. Wacom Tablet Area (275): 0, 0, 44704, 27940 Property 'Wacom Tablet Area' changed. Wacom Tablet Area (275): 0, 0, 44704, 27940
Okay, I've updated Fedora today and later after I rebooted the problem did not appear any more.
As per comment 12.