Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gnome 42: Mouse clicks stop working after usage of Fly-Pie #222

Closed
raven2cz opened this issue May 2, 2022 · 11 comments
Closed

Gnome 42: Mouse clicks stop working after usage of Fly-Pie #222

raven2cz opened this issue May 2, 2022 · 11 comments
Labels

Comments

@raven2cz
Copy link

raven2cz commented May 2, 2022

Bug Description

The mouse clicks stop working after usage of fly-pie. Click to window components, movement of windows, titlebars don't work. GTK applications mainly. For Qt and X11 apps the top titlebar works, but clicking inside ANY application doesn't work anymore. GTK apps all clicking and titlebar stop working.

It happens always, it is NOT random. After first usage of fly-pie, mouse clicks is stopped working.

This happen for Gnome 42 with NVIDIA proprietary drivers. I have more stations with AMD cards and there are behavior correct.

To see what happens check this my video link.

https://1drv.ms/u/s!Aq_X66v0FnfLjttPly2Zz4qPY6CmsA?e=kUSNJj

You may also check the output of GNOME Shell for any error messages related to Fly-Pie.
This can be done with the following terminal command:

journalctl -f -o cat | grep -E 'flypie|'
no error present there for this command

Expected Behavior

The mouse clicking will work after usage of fly-pie for all applications parts and titlebars. Independent on gtk, x11, qt and new adwaita lib.

System

  • Linux distribution: Arch Linux x86_64
  • Kernel: 5.17.5-arch1-1
  • Fly-Pie version: 16
  • GNOME Shell version: 42
  • DE: GNOME
  • WM: Mutter
  • GPU: NVIDIA GeForce RTX 3060 Ti Lite Hash Rate
@raven2cz raven2cz added the bug label May 2, 2022
@Schneegans
Copy link
Owner

Thanks for the report, I'll look into it. However, It'll be hard to debug as I cannot reproduce it in a virtual machine.

However, a similar thing happened to me very rarely also on GNOME 40. Yet I was never able to reproduce it consistently. When it happened, I had been summoning a menu with a key combination involving the a modifier key such as Ctrl. After the menu was closed, for some reason GNOME Shell behaved as if the modifier key was still held down. This felt a bit like not being able to click. After physically pressing the involved modifiers again, all resumed back to normal. Can you make clicking work again by pressing all involved modifier keys?

@sudoyang
Copy link

Hey Schneegans,

It seems I got a similar issue with gnome-pie.

Schneegans/Gnome-Pie#202

@raven2cz
Copy link
Author

raven2cz commented May 26, 2022

Thanks for the report, I'll look into it. However, It'll be hard to debug as I cannot reproduce it in a virtual machine.

However, a similar thing happened to me very rarely also on GNOME 40. Yet I was never able to reproduce it consistently. When it happened, I had been summoning a menu with a key combination involving the a modifier key such as Ctrl. After the menu was closed, for some reason GNOME Shell behaved as if the modifier key was still held down. This felt a bit like not being able to click. After physically pressing the involved modifiers again, all resumed back to normal. Can you make clicking work again by pressing all involved modifier keys?

No. In Gnome 42, it was stop working forever, just restart of gnome helps. The situation is much more worst, complete clicking to windows stops working too. It is not possible to use mouse or handling windows after usage of fly-pie. I cannot simulate this with amd cards on other stations. This is strictly problem with stations with nvidia cards on arch now. It happens after first usage, there is no randomness it is consists bug after first usage of fly-pie.

@Schneegans
Copy link
Owner

I am using GNOME Shell 42.0 as well and I am running on proprietary NVIDIA drivers using a GTX 1650 TI. However, I still cannot reproduce this behavior. So I think the reason must be something else, more or less specific to your setup.

Have you tried running the command journalctl -f -o cat | grep -E 'flypie|' while reproducing the error? Just keep it running in the terminal and watch for any additional output.

Besides, does this happen both on Wayland and X11?

@raven2cz
Copy link
Author

Nothing in journalctl, just normal messages, no error or some potential info.

Wayland works ok! It seems that it is a bug for X11. I haven't additional idea, it will be some specific setup problem. Extensions are disabled, I tried to switch off all, but the problem persists.

@Vinnyboiler
Copy link

Vinnyboiler commented Oct 31, 2022

Hi, I recently distro-hopped to Fedora Linux 36.1.5 (Silverblue) and am currently having this issue, I'm on GNOME Shell 42.0 using X11. Wayland don't have the bug but I would love to help debug this as I currently have a issue preventing me from using Wayland.

Edit: It managed to randomly fix itself. I wish I logged what I did but unfortunately I'm not sure what the fix is. Some things I did before it I noticed it was fixed was temporally going back to Wayland and messing with User Themes. One thing I did notice when I still had the bug was when testing with live preview tab tin the Fly-Pie settings that afterwards only half the screen was unresponsive to mouse clicks instead of the whole screen.

@Schneegans
Copy link
Owner

I have still no idea what could be the reason here. Is this still an issue?

@Vinnyboiler
Copy link

2023-03-04.17-40-40.mp4

Yes it seems to still be an issue. I have no idea when it randomly broke again. I'm currently on Fedora Linux 37 (Silverblue) with GNOME 43.2.

@Schneegans
Copy link
Owner

@Vinnyboiler: Thanks for the answer - however the video you posted looks more like issue #266...?

@Vinnyboiler
Copy link

Sorry I was getting the two issues mixed up, The mouse click issue does indeed seem to be fixed on my end, I haven't encountered that issue when checking.

@Schneegans
Copy link
Owner

I'll close this for now. If the issue still exists, feel free to drop a note here.

@Schneegans Schneegans closed this as not planned Won't fix, can't repro, duplicate, stale Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants