I noticed my Manjaro Test branch has a strange behavior on Wacom One tablet device. A repro step looks like below. The issue can be reproduced constantly on my GNOME+Wayland combination. I also verified the problem does not happen with GNOME+X.Org. It does not happen either on GNOME/Gtk application such as Settings dialog, Gnome Terminal or Firefox.
Could anyone give any hints to help how I can do futhter diagnose?
Repro steps:
Full system update since 20230515.
Make sure Wacom One Tablet device is plugged before reboot machine.
Reboot machine. Login to GNOME 44.1 + Wayland.
Launch a non-GNOME application. What I used: Steam, Godot4.
When using mouse to click title bar and drag, everything looks fine. The window can be dragged as expected.
When using Tablet pen tip to click and drag their title bar. The following phenomamon happens
Godot/Steam windows do not move when dragged. Mouse icon shape stuck as 4-direction moving icon.
When I move tablet pen tip hovers high in the air, the mouse icon disappears from desktop. (Expected should be: mouse icon still display)
Then I use my finger to touch surface of my laptop touchpad, the Steam/Godot window immediately starts moving on desktop as if I have already clicked left key on mouse/touchpad.
After manually click touchpad to complete first window move, neither mouse nor Tablet pen tip can move Godot or Steam window via title bar any more.
System info:
Machine mode: DELL Vostro 13 5310 desktop
OS: Manjaro test branch, 20230515 update
uname -a output: Linux fcdvh01 6.2.15-1-MANJARO #1 SMP PREEMPT_DYNAMIC Thu May 11 22:03:37 UTC 2023 x86_64 GNU/Linux
Wayland is still developed. X11 is more or less only maintained and considered stable. So it depends on what the exact issue is. Does it mean if you start the same PC in X11 session your Wacom tablet works as expected?
Yes exactly. Actually, I’ve been using GNOME + Wayland with my Wacom One Tablet since this Feburary for my daily works. Everything works fine until the update today. Fallback to X.Org + GNOME is a workaround as I need something to unlock my work.
Before reporting bug I also tried other ways like kernel rollback. I tried kernel 6.2.15-1 and 6.1.28-1. Both have same issues.
I’m thinking it could be either something incompatible in either GNOME 44 (seems new) or Wayland (which means it could be a regression bug ). Unfortunately I can’t predict as I’m not an expert of input devices. I can also try collecting logs if it helps.
You can always check what got updated in /var/log/pacman.log. But yes, if you updated from Gnome 43 to 44 a lot can happen there too. The testing update was actually availalbe since 13.05.2023. So you could try to boot up the Plasma Build of that day and install plasma-wayland-session via sudo pacman -Sy plasma-wayland-session and re-login to Wayland after. This you can do all in RAM without installing anything to your harddrive. So you might have an option to test if it is a Gnome or Wayland thing by not using Gnome.
I see. Thank you Phil for the suggestion. Yes, it makes sense to try with KDE so we know whether it’s a GNOME problem. I may need to do it later this week due to a deadline I must catch up this week. I will probably try at weekend and update if I find something.
I managed to make a quick try by “pacman -S plasma-wayland-session”. After rebooting and login with Plasma (Wayland) from SDDM dialog, the whole screen turns black with only an console mode blinking cursor on my laptop screen, and it automatically shutdown if I hit hardware poweroff button (I supposed it should be suspend but actually not the case).
It appears Plasma (Wayland) failed to load a KDE session.
By the way, I also tried login with Plasma (X11). It allows me login with a mouse pointer displayed on screen. So it enters graphic mode. In this mode, Tablet pointer works but the full screen is black without start menu. So I can’t verify whether Godot or Steam works with Tablet.
I also tried XFCE4 but it does not have different session for choice. As far as I know it should be Xorg, so I suppose it does not help.
Quick try before going bed. (I’m based in China :)). Yes you are right. With Sway I can successfully move Godot window with my Tablet pen tip, as expected. So shall we say this is more likely a GNOME 44.1 problem?
most likely. Gnome is more complex on Wayland. KDE Plasma is also not good on all aspects. For graphical design, most use Gnome anyway. The question is only on how to report that issue to Gnome. I enabled wayland-session on the profiles for KDE, so tomorrows build should include it for easy testing …
You may also try different kernel series to see if those might change anything. Always check what is used.
Thanks Philip, I will try when wayland-session is included. As for kernel, I’ll expand my check to 6.3.2 and 5.15 LTS series tonight and see if I can find something new.
Btw, does Manjaro team has channel to report the bug to Gnome team? I can provide logs or machine info if needed.
@philm Hey Philip, quick update: I tried kernel 6.1, 6.2 and 6.3 series on my machine. I can confirm the results are the same. Left click with Tablet pen tip can’t drag screen. I think it’s safe to predict the kernel does not contribute to the issue. Seems we can point to Gnome now.
If the issue is with non GTK+ applications you could try to add to your ~/.bash_profile the line:
export QT_XCB_TABLET_LEGACY_COORDINATES=1
Then reboot and see if the issue you experienced is still present.
Edit:
Anyway, there are countless issues with tablets under wayland, mostly due the way mutter works, and are reported here Issues · GNOME / mutter · GitLab
Hey @bogdancovaciu Thank you for suggestion. I can confirm the problem happens on QT applications as well, even with envronment variable you mentioned. I tried Kdealive and Manjaro-settings-manager.
Btw, my daily work application is not based on QT/KDE toolkit, but Godot. Godot maintains its own UI toolkit based on OpenGL directly. Thus QT settings do not affect it.
Also, regarding to Mutter issue list. Thank you for pointing a direction. But before I go ahead reporting, is it possible we have some diagnose steps I can do (e.g. collect logs, confirm versions) locally to make sure I can confirm the issue is really a Mutter problem? I’m happy to provide more details, yet I may need some help to know where to start.
There’s no response yet. Before the issue is fixed, I have moved back to Xorg+Gnome. With support from touchegg, I can mimic same experience with Gnome+Wayland. So far everything looks fine, except Xorg has a sensible performance degradation than Wayland. Anyway I don’t need to bother the annoying click-and-stuck issue.
For anyone who is experiencing the same problem, hope it helps
