+++ This bug was initially created as a clone of Bug #1397898 +++ Description of problem: This is a follow up to an earlier bug, originally reported for Fedora 25. Things got a lot better with xwayland and Wacom tablets in Fedora 27, since it was not usable at all on the two previous releases. Unfortunately, there are still some issues. When I plug my Wacom tablet in my machine, I get two cursors: one for my laptop's touchpad and another that is controlled by my tablet's stylus. That's fine, but the behaviour of the cursor icon is not consistent and the Wacom-controlled cursor often becomes invisible and non-functional. To fix the sudden invisibility, I have to quickly move my stylus around and take the invisible cursor over the top bar. After one or two times I do this, the cursor becomes visible again, usually with a crosshair icon. The cursor icon also changes with poor consistency. While the touchpad-controlled cursor icon gets the expected changes (like the crosshair icon, resize window, hand for moving files...), the stylus icon does not change consistently. Sometimes, the windows also seem to lose focus only to the stylus controlled cursor, so I have to click with the touchpad cursor, click again with the stylus cursor and repeat this process a few times until the window starts recognizing my stylus' cursor again. Sometimes, if I have the two cursors over the same window and I perform an action with the stylus-controlled one (normally, a click), the action gets activated on the place where the touchpad-controlled cursor is. For one example, I can't get to click with the stylus-controlled cursor on the window menu from Gnome Terminal. Dragging folders to the Bookmarks session on a Nautilus window also gets unexpected results when using the sylus-controlled cursor. Another example has occurred while I was writing this bug report: I couldn't click on this textarea html element without first clicking a few times over my Firefox's window elements until it get 'focus' to the correct cursor. It wasn't a single click. Only after 3 or 4 clicks the window focus was correctly assigned to one cursor. Version-Release number of selected component (if applicable): Fedora 27 How reproducible: Must have a Wacom Tablet for reproducing this bug Steps to Reproduce: 1. Log into a Wayland-managed Gnome session in Fedora 27 2. Plug a USB Wacom Tablet 3. Perform click and drag actions on some windows with the two cursors. In my experience, web browsers (Firefox and Chromium), nautilus and gnome terminal are enough to repeat these issues. Actual results: Non-recognized click and drag actions, wrong cursor icons. Expected results: Normal click and drag actions with both cursors.
I see similar issues with The GIMP, using the tablet makes the mouse completely unresponsive (until input focus is set on anohter toplevel and back). Seems 100% reproducible.
Here's what I can reproduce quite reliably: 1. run gtk3-demo event_axes with the x11 backend: $ GDK_BACKEND=x11 gtk3-demo --run=event_axes 2. Move the mouse pointer on the demo window, the axis show up, source is "xwayland-pointer:13" 3. move the stylus pointer over the same window, the axis show upo, source is "xwayland-stylus:13" 4. lift up the stylus out of proximity while keeping the cursor within the window 5. try to move the mouse pointer, the axis do not move, click inside the demo window, nothing happens. Additional data: $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ xwayland-stylus:13 id=9 [slave pointer (2)] ⎜ ↳ xwayland-eraser:13 id=10 [slave pointer (2)] ⎜ ↳ xwayland-cursor:13 id=11 [slave pointer (2)] ⎜ ↳ xwayland-pointer:13 id=6 [slave pointer (2)] ⎜ ↳ xwayland-relative-pointer:13 id=7 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ xwayland-keyboard:13 id=8 [slave keyboard (3)]
Note: moving to xorg-x11-server for Xwayland (Wayland, the package or rather libwayland is just an IPC library). Fix has been puxhed in Xserver for this: https://patchwork.freedesktop.org/patch/191698/
I believe I have same problem, but the cursor do not show on my Fedora 27 virtual machine at all, independently if tablet is connected or not. Usually I need to click on the title bar of the VM and move it, then (usually) the cursor is shown again, although in my Fedora vm I need to open the terminal for the mouse to show up again (not sure why). If I select X11 instead of wayland, the cursor shows fine all the time (except on the login script). If I change the video from QXL to VMVGA, I get no cursor problems at all. Host is fedora 27 with qemu-kvm-2.10.1-2.fc27.x86_64 and kernel 4.14.8-300.fc27.x86_64.
xorg-x11-server-1.19.6-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f985e8e9e6
xorg-x11-server-1.19.6-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f985e8e9e6
xorg-x11-server-1.19.6-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Well... first of all, thank you for this fix. The wacom cursor behaviour got better. Unfortunately, not all issues went away, and I'm not sure if this thread is the appropriate place for this: - while the cursor icon gets consistent and (for the most part) no longer gets invisible, the focus is not yet consistent. Dragging a file from Nautilus to itself (to change folders or creating a bookmark, for instance) or to another app (like an attachment Thunderbird), does not work at all with the tablet cursor. It only works with the (in my case) trackpad cursor, and only after a few clicks with it so the window manager understands that now it is the action cursor. - in some apps not built with GTK (like Krita or even Chromium) the behavior gets unstable. In Krita, the tablet cursor gets hidden when moved around the UI buttons and other elements than the canvas, so there is no way to know which button, layer or option you are going to select. In Chromium, I've got this strange focus behavior where my tablet cursor was over it and my trackpad cursor was over Firefox: when clicking with the trackpad over Firefox, the action was triggered under the tablet cursor in the Chromium UI. I don't know if that is useful, but I can record a video of these odd behaviors. - a last, but definitely not least, issue is that I'm getting random workspace crashes and I'm sent back to the login screen. I only can log back in if I reset the gdm service via systemctl. This used to happen in a previous Fedora version, when Wayland got to be the default display manager, but seems to be back. :( If you need additional info, just tell me what I should bring here. :)
(In reply to Virgilio from comment #8) > - while the cursor icon gets consistent and (for the most part) no longer > gets invisible, the focus is not yet consistent. Dragging a file from > Nautilus to itself (to change folders or creating a bookmark, for instance) > or to another app (like an attachment Thunderbird), does not work at all > with the tablet cursor. It only works with the (in my case) trackpad cursor, > and only after a few clicks with it so the window manager understands that > now it is the action cursor. In Wayland I do not think the tablet pointer can be used in place of the regular pointing device, so I think this is somehow expected. But you may want to file a bug against gtk+ upstream (in gitlab) or Nautilus, not sure which component is the problem there (this needs to be investigated) > - in some apps not built with GTK (like Krita or even Chromium) the behavior > gets unstable. In Krita, the tablet cursor gets hidden when moved around the > UI buttons and other elements than the canvas, so there is no way to know > which button, layer or option you are going to select. In Chromium, I've got > this strange focus behavior where my tablet cursor was over it and my > trackpad cursor was over Firefox: when clicking with the trackpad over > Firefox, the action was triggered under the tablet cursor in the Chromium UI. > > I don't know if that is useful, but I can record a video of these odd > behaviors. Again I don't think the tablet stylus can be used in place of a regular pointer in Wayland (I am not entirely sure of this, Carlos Garnacho would know better), so it could be that krita hides the cursor when the stylus exits the drawing area. > - a last, but definitely not least, issue is that I'm getting random > workspace crashes and I'm sent back to the login screen. I only can log back > in if I reset the gdm service via systemctl. This used to happen in a > previous Fedora version, when Wayland got to be the default display manager, > but seems to be back. :( That would be better off separate bugs, if you're session crashes you need to look at the logs to determine which component actually crashes (either Xwayland or gnome-shell) and possibly provide a backtrace.
(In reply to Olivier Fourdan from comment #9) > (In reply to Virgilio from comment #8) > > - while the cursor icon gets consistent and (for the most part) no longer > > gets invisible, the focus is not yet consistent. Dragging a file from > > Nautilus to itself (to change folders or creating a bookmark, for instance) > > or to another app (like an attachment Thunderbird), does not work at all > > with the tablet cursor. It only works with the (in my case) trackpad cursor, > > and only after a few clicks with it so the window manager understands that > > now it is the action cursor. > > In Wayland I do not think the tablet pointer can be used in place of the > regular pointing device, so I think this is somehow expected. But you may > want to file a bug against gtk+ upstream (in gitlab) or Nautilus, not sure > which component is the problem there (this needs to be investigated) > Pen input is intended to be largely interchangeable with regular pointer (or touch) input for UI interaction. GTK3 and xwayland are wired up to make things work, but there are still implementation bugs lurking throughout the stack. The Wayland tablet code hasn't been nearly as well battle-tested since there are fewer people with the necessary hardware. Hard to say where in the stack this particular bug lies, but definitely make sure Carlos Garnacho is added to the CC list of the bug that is filed since he's GNOME's resident tablet expert. > > - in some apps not built with GTK (like Krita or even Chromium) the behavior > > gets unstable. In Krita, the tablet cursor gets hidden when moved around the > > UI buttons and other elements than the canvas, so there is no way to know > > which button, layer or option you are going to select. In Chromium, I've got > > this strange focus behavior where my tablet cursor was over it and my > > trackpad cursor was over Firefox: when clicking with the trackpad over > > Firefox, the action was triggered under the tablet cursor in the Chromium UI. > > > > I don't know if that is useful, but I can record a video of these odd > > behaviors. > > Again I don't think the tablet stylus can be used in place of a regular > pointer in Wayland (I am not entirely sure of this, Carlos Garnacho would > know better), so it could be that krita hides the cursor when the stylus > exits the drawing area. > Krita hides the cursor over the drawing area so that it can draw its own brush-shaped cursor (at least, I assume it doesn't give the brush-shaped cursor to X since it may need to be changed every frame...) and then restores the cursor when leaving.
Thanks for the replies, Jason and Olivier. :) (In reply to Jason G. from comment #10) > > (In reply to Olivier Fourdan from comment #9) > > In Wayland I do not think the tablet pointer can be used in place of the > > regular pointing device, so I think this is somehow expected. But you may > > want to file a bug against gtk+ upstream (in gitlab) or Nautilus, not sure > > which component is the problem there (this needs to be investigated) > > Pen input is intended to be largely interchangeable with regular pointer (or > touch) input for UI interaction. GTK3 and xwayland are wired up to make > things work, but there are still implementation bugs lurking throughout the > stack. The Wayland tablet code hasn't been nearly as well battle-tested > since there are fewer people with the necessary hardware. Hard to say where > in the stack this particular bug lies, but definitely make sure Carlos > Garnacho is added to the CC list of the bug that is filed since he's GNOME's > resident tablet expert. I can help with reports and other tests you may need. :) I will report it to Nautilus too. > Krita hides the cursor over the drawing area so that it can draw its own > brush-shaped cursor (at least, I assume it doesn't give the brush-shaped > cursor to X since it may need to be changed every frame...) and then > restores the cursor when leaving. Yeah, the problem definitely starts with this action. There's no problem hiding the main cursor over the drawing area to replace it with the brush-shaped cursor. The problem is that it does not 'unhide' it when it goes over other UI areas, such as toolbars, layers and other dockable dialogs. After I draw something, there's no way to know exactly where the cursor is over these areas in order to activate a tool, option or a layer, for instance. After further testing, I get the same error with the Gimp, so it does not seem to be related to the UI toolkit. When going fullscreen with either Gimp and Krita, the brush-shaped cursor is correctly displayed over the canvas, but the default cursor is not restored when moving it over the other UI elements.
I have the same problems (fedora 28, wacom intuos4 wireless PTK-540WL over usb and bluetooth). The session crash probably generated this in dmesg: [ 800.670119] gnome-shell[8837]: segfault at 20 ip 00007fd891605957 sp 00007fff279ab380 error 4 in libmutter-2.so.0.0.0[7fd8914f4000+18f000] but there are also problems with bluetooth communication in kernel: [ 607.012361] Bluetooth: hci0: last event is not cmd complete (0x0f) [ 623.015275] Bluetooth: hci0: last event is not cmd complete (0x0f) [ 639.010165] Bluetooth: hci0: last event is not cmd complete (0x0f) [ 655.016039] Bluetooth: hci0: last event is not cmd complete (0x0f) [ 671.010961] Bluetooth: hci0: last event is not cmd complete (0x0f) so it might be more than just one problem. The situation seems to be more stable when the tablet is connected over usb. Still inconsistent, but usable at times.
Opening firefox (required) and scrolling with focus on firefox crashes session immediately and consistently with dmesg: [ 1643.754004] Chrome_~dThread[15600]: segfault at 0 ip 00007f98864745b3 sp 00007f98834e3b00 error 6 in libxul.so[7f9886460000+5635000]
seems to be the same on f29. crosshair icon and crash with middle-button scrolling. also edge or 'hidden' docks aren't revealable :(