Intuos BT M multimonitor misbehavior

[FMuro]

Running an up-to-date Ubuntu 20.04 under X with two monitors, if I connect the tablet (Intuos BT M) via bluetooth and then wired, I can't map it to one monitor anymore using the GNOME control center (xsetwacom works). I find it strange because the changes in the GNOME control center are reflected in dconf. Whatever reads dconf to honor the configuration is not working well. Even more strange. If if leave the GNOME control center with the option to map it to a single monitor and then reboot, upon reboot it works correctly for a couple of seconds, and then goes back to a non-mapped setting (this strange and rapid change can even be checked by running xinput twice right after reboot). The only way of getting it to work as expected is restarting X within the GNOME session (ALT+F2 r), but most of the times it misbehaves again after rebooting. I think the bug can also be reproduced by disconnecting and connecting again the USB. I've tried with a new user and it also happens as described. Nothing of this happens under Wayland, that's why I'm filing this againts the Wacom X driver. I apologize if this issue doesn't belong here (I'd just like to know where to file it in that case).

EDIT: Looking at the output of xinput, I've noticed than, when the tablet misbehaves, changes in GNOME control center are reflected by "Wacom Intuos BT M Pad pad", and when it works as expected, they are reflected in "Wacom Intuos BT M Pad stylus".

[whot]

Whatever reads dconf to honor the configuration is not working well.

that would be mutter, it reads gsettings and applies it (in the X case) to this driver's properties. In the Wayland case, mutter handles the mappings directly since it is the display server.

changes in GNOME control center are reflected by "Wacom Intuos BT M Pad pad", and when it works as expected, they are reflected in "Wacom Intuos BT M Pad stylus".

that is... strange. It would indicate that mutter can get confused about which device is which, but I'm not sure why it would do that. Doubly so at runtime...

[FMuro]

I've tried downgrading mutter to no avail, it looks like the bug is here since the beginning of the 3.36 series (at least, it didn't happen with Ubuntu 18.04, which I had until recently). Should I then close this bug and file one against mutter or maybe there's something that can be done here?

[jigpu]

The fact that the mapping seems to work for a few seconds and then stop working (after a reboot or restart of the GNOME session) makes me wonder if you're experiencing the Android misdetect issue.

I would suggest running lsusb the next time you encounter this issue. This should let us see which VID the tablet is using at that time. You could also try the workaround mentioned in the link to force the tablet to change its mode and VID.

[FMuro]

The fact that the mapping seems to work for a few seconds and then stop working (after a reboot or restart of the GNOME session) makes me wonder if you're experiencing the Android misdetect issue.

I also experience this one from time to time, but this is a different one.

I would suggest running lsusb the next time you encounter this issue. This should let us see which VID the tablet is using at that time. You could also try the workaround mentioned in the link to force the tablet to change its mode and VID.

I'll do so.

[jigpu]

Closing due to inactivity. If you reproduce this issue again, I'll be happy to re-open it.