Tablet stylus stops working with maximized windows when lifted away

[iacri]

Things to do first

• Confirm that the problem persists when Dash-to-Panel is the only enabled extension. To do so, disable every other extension, then restart gnome-shell by running the r command from the prompt that appears when pressing Alt+F2 on an X.org session, or by logging out/in on a Wayland session. -> done, reproduced
• Look for Dash-to-Panel errors in your log. To do so, run the journalctl /usr/bin/gnome-shell -f -o cat & command and reproduce the problem. -> some warnings appear regardless of me reproducing the issue, nothing appears while reproducing
• Search existing opened and closed issues to see if the problem has already been reported. -> couldn't find anything

Describe the bug When lifting a wacom tablet pen away from the hovering range of the tablet and then bringing it back in range over a maximized window, the cursor doesn't reappear and the pen has no interaction with the window until it is dragged over the dash-to-panel panel. This is problematic while using krita maximized. Doesn't happen with windowed windows.

• use a pen tablet, I'm using Wacom CTL-672 aka One M
• maximize a window, Krita installed via RPM from fedora repos will work
• hover on the window with the pen
• lift the pen outside the tablet's hover range
• bring it back down to the tablet

Expected: the pen controls the cursor as it was doing before being lifted from the tablet Actual: the cursor disappears and doesn't reappear as long as the pen hovers the maximized window and not the dash-to-panel panel; the pen also can't interact with the maximized window.

Linux distribution and version Fedora 40

GNOME Shell version GNOME Shell 46.3.1

Dash-to-Panel version 62

Where was Dash-to-Panel installed from? Gnome Extensions

Additional Info Available to both troubleshoot more and look into the code to find what could be causing this, given some directions

I noticed it doesn't only happen when maximized. As long as the window occupies 90% of the free screen estate I can repro.

[Hirnmoder]

Hi, I stumbled across this very issue yesterday and I also thought Dash-to-Panel was the culprit. I've taken similar steps to reproduce the issue but i found it to be more intricate than it seems at first glance.

I tried several configurations and it seems that it's not Dash-to-Panel's sole fault. The issue arises on my machine when the default gnome top panel is hidden on the Wacom-Display. This is afaik the default configuration of Dash-to-Panel, which makes it harder to pinpoint. This hints that the underlying issue is not Dash-to-Panel but rather GNOME itself.

You can verify this, using the following configuration:

• Disable Dash-to-Panel or activate the option "Keep original gnome-shell top panel" in the extension settings ("Fine-Tune")
• Set up Wacom Display as a secondary screen and do not mirror the main display
• This makes the top panel disappear on the Wacom Display
• Now use a maximized program on the Wacom Display On my machine, this results in the exact behavior you described above. However, I strongly assume that Dash-to-Panel is not the culprit.

I found this (quite unelegant) Workaround:

• Activate the option "Keep original gnome-shell top panel" in the extension settings
• Set up Wacom Display as the primary screen
• This makes the top panel appear only on the Wacom Display (and mirrored screens), which works around the aforementioned issue whilst simultaneously looking ugly and wasting screen real-estate

In fairness, this does not solve the issue, so maybe someone needs to escalate this issue (after checking and repoducing) to the GNOME project.

My HW/SW stack:

• Wacom One 13 touch (acts as an external display, conncected via a single USB-C-to-USB-C connection)
• GNOME Shell 46.4
• Dash-to-Panel 62
• Fedora 40

[Hirnmoder]

Addendum The proposed workaround does not work out-of-the-box for non-display-based Wacom tablet such as the One M or similar since there is no external display. I assume that if you enable the original gnome-shell top panel on the monitor that is receiving the drawing inputs from the One M it will work. However, due to the lack of available hardware I cannot test my hypothesis.

[Hirnmoder]

Maybe related to https://gitlab.gnome.org/GNOME/mutter/-/issues/3535