Bug 1683844

Wayland is merely a display protocol, think of it like HTTP. What matters for HTTP is the browser, not the protocol and for Wayland it's the same except there it's the compositor. The GNOME Wayland compositor is mutter, so that's the component you're looking for when you're looking for "Wayland".


xorg-x11-drv-* are no longer used when running under a Wayland compositor as those need to implement their own input handling (most use libinput) instead of using the X drivers. Notable: the compositors are now in charge of all input and that includes the ability to handle multiple cursors/keyboards where necessary. And this leads us to:

The decision to have two cursors was a conscious decision for mutter on wayland. Tablet devices are usually direct-input devices and don't usually even need a cursor. So that's a feature, but applications (especially those going through XWayland) may get confused by two cursors. The easiest solution to the confusion is to not use both devices at the same time :)

It *should* work fine as long as you use the devices separately. Coincidentally, touch works the same except it's not as obvious because no cursor gets rendered for touch devices.

Reassigning to mutter but I'm also closing this because it's not a bug per-se. We'd need some more specific examples of bugs given all the above as the baseline.

"the tablet cursor will become invisible" - yes, it should be invisible whenever the pen leaves proximity and is not interacting with the tablet anymore.

Adding link to related upstream merge request.

Okay, understood.  Thank you for your help.

A few points remain however:

First, I cannot "not use" the mouse when I'm using the tablet.  As long as the mouse is plugged, I will see its cursor.  Having to bend to the back of my computer to plug or unplug the mouse every time I want to switch device is quite troublesome.  Could there be a workaround is software ?

Second, when the table cursor is disappearing, it's not about the stylus getting too far away from the tablet.  I mean at times I am actually pressuring with it and tracing strokes in krita, but the cursor for the tablet is invisible.
The mouse cursor, despite being left out at the same pixel position is updated with all the cursor icon states of where my invisible cursor moves to, but that one may be related to krita instructing all cursors to update their icons because it cannot handle multiple cursors.
Maybe I should report a bug against krita for that specific issue.

Created attachment 1539674 [details]
Video of invisible cursor

I'd like te reopen the ticket because there's a true bug regarding point two I made in comment 3, but this time I reproduced it with firefox, not only krita.  I'm going to rename the ticket to match this specific sub-issue as well.

So here's what I did:
1. I unplugged my mouse and plugged my tablet.
2. I restarted the computer.
3. I log in using the keyboard.  I notice the mouse cursor exists even when the mouse is not plug, which I guess is fair enough, you might want a cursor to hack through a ui using keyboard hacks to move it.  But since there's the second cursor for the tablet as well, that means I still cannot use the tablet in single-cursor mode even without the mouse :'(
4. I open firefox.  The cursor for the tablet vanishes.  The cursor for the unplugged mouse remains.
5. When I use the tablet, it behaves at the invisible cursor, however it's the mouse cursor which react to the events.
6. If I hover the gnome UI (top bar, menu from extensions, ...) with the tablet, I can see the tablet cursor again.  However even in gnome, it's still the mouse cursor that reacts to the tablet behaviour : the tablet cursor is permanently a cross-hair symbol while the mouse cursor is the arrow or the vertical bar to notify a text entry correctly matching what the cross hair hover.

This is not 100% repro case.  Regarding the invisible cursor, it seems to be some windows applications that messes things up, because that's when it can appear/disappear.  For setting the icon of the wrong cursor, this seems to always happen, regardless of what's done.

This makes fedora unusable with wacom products on a desktop computer, even with mouse unplugged.  I hope we can figure out a workaround.

Reopening the bug for the more specific case of the wacom cursor being mixed up with the mouse cursor, even with the mouse unplugged.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.