GNOME BUG: Second windows ignores tablet input in gnome-shell #107778
Operating system: Linux-5.18.6-200.fc36.x86_64-x86_64-with-glibc2.35 64 Bits
Graphics card: AMD Radeon RX 550 / 550 Series (polaris12, LLVM 14.0.0, DRM 3.46, 5.18.6-200.fc36.x86_64) AMD 4.6 (Core Profile) Mesa 22.1.2
Broken: version: 3.5.1, branch: blender-v3.5-release, commit date: 2023-04-24 18:11, hash:
Short description of error
Any secondary window doesn't register input from pen tablet
Exact steps for others to reproduce the error
Open a "new file window" and see as the tablet input stops being registered by blender on that window
Hello, thank for report that. I can't repoduce this on Windows 10 & Huion table h430p
Edit: Are you on Wayland? So then that could be a bug in blender's wayland implementation.
Hi @toastamore I can't reproduce the issue with linux and wacom cintiq. I suspect it could possibly be a libwacom issue. Is the "new file window" on a separate monitor? (But I don't think this could cause any problem either)
While testing on my device I found that once my pen is over any blender window,
xinput doesn't seem to be able to print events any more so that's pretty weird, not sure why, but probably some x11 hook functions prevented the event from passing along.
One likely issue could be that your window manager is not behaving correctly (like if you have a window that's somehow on top but not showing that way).
But anyway could you please do this:
xinput --listand see the list of devices, check the id of your stylus.
xinput test <that id>and you should be able to see events when you move your stylus
- Are you able to see events at all?
- Move the stylus to the subwindow that's supposedly not working, does it stop to generate any specific events?
Hi, @ChengduLittleA I am on fedora 36, so yes, I'm on Wayland.
The new window is not on a different monitor. I noticed that if I alt+tab to a different window and then come back to blender, at least the tablet can interact with the elements of the window but is unable to interact with the top bar (the one with the three icons, reduce to icon, maximize and close)
The same thing happens if I click on the empty part of the editable file name text (not on the written part).
I'm using a bamboo tablet CTH-670, and as I stated in the bug report this behaviour didn't happen at least on 3.3.1
I never used xinput before, but I tried, so:
Are you able to see events at all?
Move the stylus to the subwindow that's supposedly not working, does it stop to generate any specific events?
I'll try to update to fedora 38 and see if the issue is still present
Confirmed, this doesn't happen every time but it happens often (GNOME Shell 44.3).
This is a bug in gnome-shell (it doesn't happen with KDE), see: https://gitlab.gnome.org/GNOME/mutter/-/issues/2658
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?