[Bazzite fork] Menu entries unresponsive on input method change

[Raltay]

Summary

If touch input is used (via touchscreen) to execute 'mouse-click' event any entry configured in the menu, said menu entry will stop responding to 'mouse-click' events generated by either bluetooth peripherals (capable of generating 'mouse-click' events) or Steam Deck built-in controller. This issue can be reproduced separately for each menu entry and will persist until Logo menu is restarted (via DE restart most probably).

HW/SW versions

Hardware: Steam Deck OLED
BIOS version: F7G0107
Kernel version: 6.6.11-201.fsync.fc39.x86_64
OS type - Bazzite OS - image for Steam Deck with Gnome DE (Logo menu is used there in Desktop Mode's GNOME)
Ostree-Image version: bazzite-deck-gnome:testing - 2024-01-17T08:10:50Z
Reported Logo menu version: 27

Initial SW Setup

1. Install bazzite-deck-gnome:testing (by editing grub entry) directly from the installer on OLED.
2. After install, perform (and finish) initial OS setup via Bazzite Portal (nothing additional which isn't included in Bazzite Portal was performed on OS).
3. Back in gamescope, login into Steam.
4. After waiting a bit, turn off device.

Bug reproduction

Test Steps

1. Boot Steam Deck (OLED).
2. Wait until it boots into Gamescope mode ('Steam Big Picture' mode).
3. Go into (GNOME) Desktop mode.
4. (Optional) Connect bluetooth peripheral (capable of generating 'mouse-click' events).
5. Direct mouse cursor (via either bluetooth peripheral or Steam Deck's built-in controller) over Logo menu icon (top left screen corner). Generate 'left-mouse-click' event via chosen control method to open menu.
6. Via chosen control method, generate 'left-mouse-click' event on one or more menu entries (to launch their associated app/command) (this should work as expected).
7. Repeat points 5-6, but this time use touch input via Steam Deck's built-in touchscreen (utilize the same menu entries that you chose in point 6) (this should work as expected).
8. Now, repeat points 5-6, but this time use again either built-in Steam Deck controller or connected bluetooth peripheral (for the same menu entries).

Expected Outcome

• All menu entries continue to work as expected - 'left-mouse-click' events generated via either Steam Deck's controller or bluetooth peripheral are registered and respective apps/commands are executed.

Present Outcome

• 'left-mouse-click' events (generated either via SD's controller or bluetooth peripheral) are 'ignored' for menu entries which were interacted with via touch input - apps/commands are not launched, 'clicked-menu-entry' highlight animation doesn't appear at all for click actions and Logo menu doesn't close whenever 'left-mouse-click' event is generated over affected menu entry.
• touch input via SD's touchscreen continues to work as expected for all menu entries (including those which were interacted with via touch input before).

I haven't included any log files, because I didn't know how to effectively gather (debug) logs for GNOME plugin. If you could provide me with instructions on how to gather such logs, I'll happily provide them.

Best Regards.

[Aryan20]

Hey! Thanks for reporting this.

I'm CC'ing the maintainer of the Logo Menu fork which is shipped with Bazzite as I don't have access to that hardware for testing and debugging purposes and I'm not aware of the current state of the project in terms of driver support for Steam Deck hardware.

Hopefully, they will have some insights or can test and verify your findings.

CC: @KyleGospo

Also, for logs, you can use the command - "dbus-run-session -- gnome-shell --nested --wayland" which will open a nested shell where you can test the extension and you will get the complete shell logs on the terminal. They are full of lots of other things as well, but can maybe give a clue to what's happening.

[KyleGospo]

Hi there, I'm afraid I'm the one who pointed him here.

I am able to reproduce this with a touch screen laptop so it's possible this is a GNOME bug, but it may be fixable downstream. I'll poke around similar projects.

[Aryan20]

Sorry for the late reply, exam season.

Thanks for verification, It's quite a weird behaviour then, can you see if normal GNOME menus also face this or do other extensions with menus have such an issue?
As we are not using any custom logic, it is most probably something with GNOME ig, but if other extensions and menus work fine then that will be peculiar.