After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769030 - On Thinkpad Yoga 260 (integrated wacom tablet + touchscreen), GIMP is sometimes stuck in a state where right-click doesn't work
On Thinkpad Yoga 260 (integrated wacom tablet + touchscreen), GIMP is sometim...
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
2.8.18
Other Linux
: Normal critical
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2016-07-21 12:20 UTC by el
Modified: 2018-05-24 16:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log of input events that result in the bad state (297.02 KB, text/plain)
2017-01-04 19:39 UTC, Øyvind Kolås (pippin)
Details
shorter event capture of input events that makes X / GIMP unstuck (85.10 KB, text/plain)
2017-01-04 19:40 UTC, Øyvind Kolås (pippin)
Details

Description el 2016-07-21 12:20:52 UTC
On Thinkpad Yoga 260 (integrated wacom tablet + touchscreen), GIMP is sometimes stuck in a state where right-click doesn't work. Sometimes this can be remedied by randomly touching on the screen and hoping it gets somehow unstuck, sometimes this can be remedied by reloading the gnome shell (but this is now unavailable under the new Wayland GNOME Session), and sometimes it just doesn't go away.

Since this makes GIMP effectively impossible to use when this happens and you can't get rid of it, this is a fairly big problem.

I have never seen this on any other laptop or my desktop, so I suspect it is somehow related to GTK+'s/GIMP's handling of the touchscreen and/or the integrated wacom pen tablet thing. No other application is affected either when GIMP is stuck in such a broken state, context menus and everything work perfectly fine in everything else.
Comment 1 el 2016-07-21 12:22:50 UTC
I mainly recall seeing this when an external monitor is attached and the internal one is turned off in the gnome control center. I don't know if it's strictly required for reproducing this though
Comment 2 el 2016-07-21 12:26:02 UTC
I also just discovered that right now after that bug has triggered, the close button of the GIMP window does absolutely nothing and the menu bar at the top will highlight any entry when clicked (like "File" or "Colors") but not open up the menu either.

This issue happens both with Xorg and under a Wayland session by the way.
Comment 3 Michael Natterer 2016-07-21 12:37:53 UTC
Does restarting GIMP fix that problem, or only restarting gnome-shell
(under and Xorg session)?
Comment 4 el 2016-07-21 12:42:32 UTC
Restarting GIMP doesn't fix it, which is why I'm currently stuck with this state.
Since I'm currently running under a wayland session, I can't restart GNOME either. I would assume that restarting the laptop might fix it, at least temporarily.

However, I manage getting it somehow to work again under Xorg. I just wildly restarted GNOME shell, GIMP and touched the screen and somehow got it unstuck. It took me a while though, and I'm still not sure how to get rid of it reliably, and the issue reappears quite often.
Comment 5 Michael Natterer 2016-07-24 22:02:45 UTC
If restarting GIMP doesn't fix it, I see no reason how this could
be GIMP's fault.
Comment 6 el 2016-07-24 23:12:45 UTC
I'm not in any position to guess what upstream party could be responsible or even more so notably assist such an upstream party in debugging with the unique application that is GIMP in any smart manner (since no other program seems to be affected).

However, if you want me to run some command or collect some logs the next time this happens so you can identify the problematic component, I'd be happy to do so
Comment 7 Øyvind Kolås (pippin) 2016-12-27 02:32:38 UTC
I have also observed this issue, another way GIMP misbehaves in this state is that the marching ants outline of the current brush does not track the cursor. And the triangles of the levels tool are grabbed and dragged when just hovering over them without pressing.

I suspect touching the screen to activate touch screen mode, and alt-tabbing to other applications to deactivate it to be part of unscrewing this behavior.
Comment 8 Carlos Garnacho 2016-12-27 13:36:20 UTC
I'm unclear with the given info about whether this is seen on the gnome X11 session too or just on wayland.

If it's seen just on wayland I might suspect to some degree of gnome-shell or Xwayland, if it's seen on X11 too I think it points further down to X11/kernel driver issues.

All the described behavior seems to me (X)wayland specific though, if Xwayland is left with a stuck grab, it would only affect X clients, while the compositor and wayland clients could keep working (to some extent, even if the touchpoint is stuck at a lower level).

But I guess libinput-debug-events is a good starting point anyway. if TOUCH_DOWN and TOUCH_UP events are not paired, that's certainly a sign of trouble.
Comment 9 Øyvind Kolås (pippin) 2016-12-27 13:44:17 UTC
The original reporter doesn't mention wayland, and I am not using wayland either, and have only experienced this under gnome X11 sessions with the touchscreen + touchpad combo of my yoga300-11ibr. I'll bring my misbehaving yoga to the catalan masia for the week jan 27th->fosdem, we could debug it there if it remains unresolved.
Comment 10 el 2016-12-29 17:40:01 UTC
This is an X11 bug showing for me with a touchscreen + touchpad + trackpoint + wacom pen device in a regular classic X11 GNOME 3 session.

Wayland is an absolute disaster due to GTK2 not receiving pen events at all so you can't interact with lots of applications at all, so I don't use GIMP with Wayland.
Comment 11 Peter Hutterer 2017-01-04 00:43:34 UTC
As carlos said in comment 8, please run sudo libinput-debug-events in the background and try to reproduce it. This should show up any unbalanced events that may cause the button to be held down. Note that l-d-e listens to all devices, any passwords you type will show up in the output.
If you can't reproduce the bug quickly enough, please restart l-d-e to keep the recording short.
Comment 12 Øyvind Kolås (pippin) 2017-01-04 19:39:26 UTC
Created attachment 342888 [details]
log of input events that result in the bad state
Comment 13 Øyvind Kolås (pippin) 2017-01-04 19:40:45 UTC
Created attachment 342889 [details]
shorter event capture of input events that makes X / GIMP unstuck
Comment 14 Peter Hutterer 2017-01-09 05:12:44 UTC
(In reply to Øyvind Kolås from comment #12)
> Created attachment 342888 [details]
> log of input events that result in the bad state

button, touch and key events are balanced so this is unlikely an issue in libinput or lower. I noticed a mix of touch and button events towards the end, so my first guess is that there may be something off with the pointer emulation bits in X11 that results in a stuck grab. it could be that gimp is the only one to trigger this because it (iirc) still uses active grabs on input devices directly.
Comment 15 Øyvind Kolås (pippin) 2017-07-28 14:52:03 UTC
Testing during GUADEC, I am currently able to reproduce this under debian stretch with xorg, thankfully when using wayland this particular stuck right button state does not occur, and the hardware is almost fully usable.

There is however race conditions/lock ups that are similar which seem to be resolved by forcing switches between clients/windows by keyboard shortcuts, where wayland seems to receive no pointer events until unblocked.
Comment 16 GNOME Infrastructure Team 2018-05-24 16:37:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/936.