miki223
commented
1 year ago does kdialog have the same issue i wonder
Open aclist opened 1 year ago
miki223
commented
1 year ago does kdialog have the same issue i wonder
aclist
commented
1 year ago I tested it, and kdialog does accept keyboard input. However, as both zenity and kdialog (among other utilities) are installed out of the box on the system, it's reasonable to target either of them, and they expose different functionality.
aclist
commented
9 months ago As a further data point, programs calling zenity invoked as non-Steam games in Desktop Mode prevent mouse input entirely; only the touchpad works.
Minimum reproducible example:
#!/usr/bin/env bash
echo "test" | zenity --list --column=fooMake the script executable and add as a non-Steam game, then launch through Desktop Mode. The trackpads and joysticks stop working and only the touchpad can be used to cancel the dialog. The same script launched outside of Steam (e.g., as a desktop shortcut or via the terminal) works correctly on Steam Deck.
Putting it all together:
bertogg
commented
8 months ago programs calling zenity invoked as non-Steam games in Desktop Mode prevent mouse input entirely; only the touchpad works.
If I'm understanding this correctly, you're not talking about an external mouse, right? With an external mouse I can use that Zenity dialog just fine in all cases.
If you're talking about using e.g. the right trackpad as a mouse/touchpad and it stops working as soon as you launch the Zenity dialog as a non-Steam app then edit the controller settings of that non-Steam game and make sure that the trackpad is configured to behave as a mouse and not as a joystick.
bertogg
commented
8 months ago I forgot to add, I can otherwise reproduce the problem with Zenity: I won't let me enter text with the keyboard, whereas Kdialog works as expected.
aclist
commented
7 months ago If I'm understanding this correctly, you're not talking about an external mouse, right?
Sorry if this was unclear; I was talking about the on-screen virtual keyboard. When I mentioned keyboard/mouse/touchpad input, I was talking about what is available OOB on the device.
If you're talking about using e.g. the right trackpad as a mouse/touchpad and it stops working as soon as you launch the Zenity dialog as a non-Steam app then edit the controller settings of that non-Steam game and make sure that the trackpad is configured to behave as a mouse and not as a joystick.
I recently came across an undocumented (?) method whereby you long-press on the three dots button on the right side of the device and it toggles between Game Mode (controller-style) bindings and Desktop Mode (KBM-style) bindings. This didn't actually unblock the typing issue, but it did seem to "unstick" the mouse in both Game Mode and Desktop Mode when using third-party applications developed with the desktop in mind.
After rewriting the application with GTK bindings and dropping zenity, virtual keyboard input from Desktop Mode works natively (did not test Game Mode yet). I cannot say for certain whether the issue is localized to zenity or is more generalized. Steam Deck ships with <4.0 version of zenity as of this writing, so I don't think it has to do with GTK 4.0 issues.
Anecdotally, though, I noticed that applications sending fullscreen window hints to the window manager behave erratically when the virtual keyboard is spawned, because the keyboard actually spawns below the window and is inaccessible. Is this expected? It seems unlikely if we assume that the sole source of fallback input for any input fields in a kiosk-style application would be the virtual keyboard, so it seems like it should exist as a meta layer on top of all other windows, even ones sending fullscreen window hints.
bertogg
commented
7 months ago After rewriting the application with GTK bindings and dropping zenity, virtual keyboard input from Desktop Mode works natively (did not test Game Mode yet). I cannot say for certain whether the issue is localized to zenity or is more generalized. Steam Deck ships with <4.0 version of zenity as of this writing, so I don't think it has to do with GTK 4.0 issues.
Hi, I need to investigate the problem further but I think that I have identified it already.
It seems to be related to the GTK input method set by default (GTK_IM_MODULE=Steam). If you remove that environment variable before starting your program it should work as expected (although you'll need to open the virtual keyboard manually), can you confirm that?
aclist
commented
7 months ago It seems to be related to the GTK input method set by default (GTK_IM_MODULE=Steam). If you remove that environment variable before starting your program it should work as expected (although you'll need to open the virtual keyboard manually), can you confirm that?
I can confirm that unsetting this env var prior to launch unblocks the input issue on both generic zenity tests (zenity --entry) and on a full GTK application using Gtk.Entry.
However, I still see the issue with certain GTK applications launched in Game Mode not responding to keyboard events for navigation, because the inputs on the device are currently registered as a gamepad. Only after doing the long-press on dots button hack does the application register, e.g., the D-pad as a keyboard arrows, but whenever the application switches contexts or draws a dialog onscreen, the Steam Deck reverts to gamepad mode and has to be switched back to the keyboard mode every time.
Short of using Steamworks, Is there a flag to set to enforce keyboard as the preferred input when launching a third-party app?
bertogg
commented
7 months ago We're fixing the GTK input method to at least solve the problem with Zenity.
If you have additional examples of GTK apps behaving incorrectly I would appreciate if you can mention a few (explaining what is broken) so we can also have a look at those. Thanks!
aclist
commented
7 months ago Attached is a MRE using PyGObject (rename to .py as it is not supported as a GitHub extension) that can be used to test the cases below.
Invoke with one of these flags:
$ python3 test.py <flag>
--button: button dialog
--entry: text entry dialog
--entry-fs: fullscreen text entry dialogTest target: Steam OS 3.5.13, 1705108172
In all of the tests, it is assumed that the Steam + X key combination will be used to spawn the virtual keyboard, rather than it appearing automatically.
I don't know if the desired behavior of applications is to call the virtual keyboard as soon as focus switches to a text entry field, or whether the user is responsible for manually spawning it. If it's the former, it seems like it would be helpful (not as a fix for the below, but as an additional option) to expose a system command that could be called from generic scripts or other utilities in order to spawn the virtual keyboard in an ad-hoc way without emitting a specific signal.
For the Desktop Mode test, it can be run as a standalone Python script and need not be added as a non-Steam game.
For the Game Mode test, it should be wrapped in, e.g., a shell script and added as a non-Steam game.
--entry)To reproduce: run with the provided flag and set the GTK_IM_MODULE accordingly. Focus the text entry field and attempt to enter text via the Steam Deck's virtual keyboard.
Expectation: the virtual keyboard will appear onscreen when using the Steam + X key, and virtual keyboard input will go into the text entry field.
Case 1a
Mode: Game Mode
GTK_IM_MODULE: system default (Steam)
FAIL: Virtual keyboard is blocked. The IME can be spawned, but input does not pass through to the dialog.
Case 1b Mode: Game Mode GTK_IM_MODULE: explicitly unset
PASS: Virtual keyboard is working.
Case 1c
Mode: Desktop Mode
GTK_IM_MODULE: system default (ibus)
PASS: Virtual keyboard is working.
Case 1d Mode: Desktop Mode GTK_IM_MODULE: explicitly unset
PASS: Virtual keyboard is working.
--entry-fs)(The window is created by GTK with hints to the window manager to spawn it in fullscreen, on top of the window stack)
To reproduce: run with the provided flag and set the GTK_IM_MODULE accordingly. Focus the text entry field and attempt to enter text via the Steam Deck's virtual keyboard.
Expectation: the virtual keyboard will appear onscreen when using the Steam + X key, and virtual keyboard input will go into the text entry field.
Case 2a
Mode: Game Mode
GTK_IM_MODULE: system default (Steam)
PASS: Virtual keyboard is working.
Case 2b Mode: Game Mode GTK_IM_MODULE: explicitly unset
PASS: Virtual keyboard is working.
Case 2c
Mode: Desktop Mode
GTK_IM_MODULE: system default (ibus)
FAIL: Behavior is erratic; the virtual keyboard spawns behind the window. The user can input text during this time and it appears in the entry field, but no visual indication of this happening on the onscreen IME.
Sending fullscreen window hints to the window manager can be useful if an application needs to be scaled and locked to the dimensions of the viewport/device, or if running as a kiosk-style application. Even though it is expected that the application is on the top of the window stack, given that the virtual keyboard is a meta layer, it seems like an oversight that it should appear underneath the current window and still allow typing input into a text field. Since the virtual keyboard acts as a fallback mechanism and method of last resort for cases where there is no external keyboard attached, it seems like it should have priority over other windows and appear on top of the entire window stack if it is to fulfill its purpose as a floating IME. In effect, the virtual keyboard should have the highest priority even when other windows emit fullscreen hints.
Case 2d Mode: Desktop Mode GTK_IM_MODULE: explicitly unset
FAIL: Same as above.
--button)To reproduce: run with the provided flag and set the GTK_IM_MODULE accordingly. Use the D-pad, joysticks, or trackpads to change focus between button elements. You need not activate a button for this test.
Expectation: navigation is unblocked and the user can navigate between buttons using the D-pad/joysticks/trackpad.
Case 3a Mode: Game Mode GTK_IM_MODULE: not relevant for this test
FAIL: Movement keys are blocked. Must use the 'three dots' button to toggle keyboard mode in order for surface buttons to work.
Case 3b Mode: Desktop Mode GTK_IM_MODULE: not relevant for this test
PASS: All movement works as expected with any of the input methods.
--button)To reproduce: run with the provided flag and set the GTK_IM_MODULE accordingly. Use the D-pad, joysticks, or trackpads to change focus between button elements. After doing so, activate a button with the A button or a click action to spawn a secondary entry dialog. Attempt to enter text in this dialog, activate the OK button, and then return to the underlying dialog. Now attempt to resume navigation between button elements as before.
Expectation: after navigating to a button selection, the user spawns a new entry dialog by activating the button. The spawned dialog takes window focus, and the user can type into it with the virtual keyboard. After closing the entry dialog, the user can continue moving around the original dialog using the surface buttons (D-pad, joystick, trackpad) without having to use the three dots button to switch between input modes.
Case 4a Mode: Game Mode GTK_IM_MODULE: explicitly unset
FAIL: Initially, movement keys are blocked as in Test 3. Must use the 'three dots' button to toggle keyboard mode in order for navigation to work. However, after spawning an entry dialog, the virtual keyboard is blocked from spawning unless the following is done:
However, the act of entering text via the virtual keyboard loses the toggle to keyboard mode, so the user cannot navigate to the 'OK' button without pulsing the three dots button yet again.
Outcome: in a multi-dialog context, using the virtual keyboard to enter text seems to lose the modal state of the underlying window, causing it to revert to Game Mode-style input.
Additional observations:
Case 4b
Mode: Game Mode
GTK_IM_MODULE: system default (Steam)
FAIL: Same as above, with the additional caveat that keyboard input does not work altogether, thereby blocking the rest of the test.
Case 4c
Mode: Desktop Mode
GTK_IM_MODULE: system default (ibus)
PASS: All movement works as expected, including after returning from the second spawned dialog. Since keyboard-style input is already the default for Desktop Mode, this outcome is expected.
Case 4d Mode: Desktop Mode GTK_IM_MODULE: explicitly unset
PASS: Same as above
bertogg
commented
7 months ago First of all, thanks for all the details. I'll write a longer message tomorrow about the rest of the test cases, but I wanted to point out something quickly:
Case 1c Mode: Desktop Mode GTK_IM_MODULE: 'Steam'
PASS: Virtual keyboard is working.
I think that this part is incorrect. In game mode GTK_IM_MODULE is Steam, but in desktop mode it is not, and that's the reason why the virtual keyboard is working. If you set the variable explicitly to Steam before running the program the virtual keyboard won't work in desktop mode either (and it should appear automatically when you focus the entry, which usually doesn't happen in desktop mode).
aclist
commented
7 months ago OK, I understand better now. I erroneously assumed (should have checked) that the default for GTK_IM_MODULE was Steam on both Game Mode and Desktop Mode, rather than ibus in the latter, but I did not explicitly set it in any of the tests, simply using the system-provided default. I will edit the post for clarity.
bertogg
commented
7 months ago Ok, I finally had the chance to check your example. Thanks again for writing it and for the detailed explanation.
There are two different issues here:
The Steam GTK input method is definitely broken and it is being fixed. The new version will allow you to enter text using a keyboard (virtual or physical).
The problems to spawn the virtual keyboard are also probably related to the GTK input mehtod and are being investigated.
The other navigation problems that you mention are due to a completely different reason. The Steam Deck controller is not a keyboard nor a mouse and you cannot generally navigate throught the buttons of a desktop application using a joystick.
The controller does have however a basic keyboard/mouse emulation mode where the dpad works as the arrow keys, A/B as Enter and Escape, the right pad as a touchpad, etc., and if I'm not wrong that's what happens when you press the three dots button, or when the Steam client is closed.
When the Steam client is running the controller works according to the active layout, so since we're talking about running an app from the game mode, I think that the proper solution is to change the controller layout for that non-Steam game to something that suits your needs. There are several templates available, the Web Browser layout or a similar one should work for this case.
aclist
commented
7 months ago Thanks for the reply. I want to clarify a few things here in order to align future expectations.
The Steam GTK input method is definitely broken and it is being fixed. The new version will allow you to enter text using a keyboard (virtual or physical).
If I understood correctly: once this is implemented, in Game Mode, some environment variable will be set by default, presumably GTK_IM_MODULE=Steam. When this is enabled, applications with a text entry field will support entering text via any keyboard type.
Will the act of focusing the text entry field raise the virtual keyboard, or is this considered the responsibility of the user?
The controller does have however a basic keyboard/mouse emulation mode where the dpad works as the arrow keys, A/B as Enter and Escape, the right pad as a touchpad, etc., and if I'm not wrong that's what happens when you press the three dots button, or when the Steam client is closed.
There are two use cases here. Using an application standalone in Desktop Mode or adding it to Steam as a non-Steam game for the purposes of being able to access it in Game Mode. If you run the application example above, in Desktop Mode, the button-to-keyboard mappings you mention are working out of the box when it is run directly, i.e., not added as a non-Steam game. Is this behavior expected? Will these keybindings stop working in Desktop Mode if Steam is open?
Admittedly, I did not test running the application from Steam while already in Desktop Mode, since it is superfluous at that point. So my questions about navigation and input when in Desktop Mode are directed at how applications behave out of the box without intervention from Steam. (Here the point at issue is behavior of the SteamOS/Steam Deck hardware, not the Steam client.)
I did not see any mention of test 2c: this is where, in Desktop Mode, an application is fullscreen and the virtual keyboard spawns underneath the top window in the stack. Is there any scenario where it would be desirable or expected for a virtual keyboard overlay to be anywhere other than on top of the window stack?
When the Steam client is running the controller works according to the active layout, so since we're talking about running an app from the game mode, I think that the proper solution is to change the controller layout for that non-Steam game to something that suits your needs. There are several templates available, the Web Browser layout or a similar one should work for this case.
I understand what you are saying, but does this actually address the underlying issue in test 4a? Is there a reason why the current toggle mode is lost when the window changes contexts? This seems underspecified or at least unexpected. Having to manually pulse the three dots button as a method of last resort is fine, but it's not clear why this mode changes before and after the virtual keyboard is spawned.
Moving on to the final point about controller layouts, let me give some additional context. This is about Game Mode only. The application in question is used by a large number of Steam Deck users. These users mostly prefer to avoid having to drop into Desktop Mode for the purposes of launching the application. They also tend to have a lower technical literacy and have some expectation of basic navigation being available out of the box. However, this is originally a desktop application that I am hard-pressed to rewrite from the ground up, so I am trying to make concessions here to at least pass the right parameters to Steam Deck to make the OOB experience behave in a more expected fashion.
As a stopgap, I actually created and provide a community controller layout that maps those buttons to navigation commands, but this is undesirable because a) the application itself is responsible for launching other games, so the user effectively has to toggle between two layouts or layers (the initial application keybindings and the actual game's bindings once launched) and b) it can be pretty difficult to communicate to users that they need to fetch and use this layout. At least in the case of the three dots button toggle, the mechanism is simple and easy to explain (just push it on or off, no swapping controller layouts as such).
Maybe exposing some facility, such as via an environment variable, for the calling program to set Steam Deck's current "three dots mode" at runtime to one or the other (and then flip it again if necessary) would bridge this gap with third-party applications.
E.g.,
$ cat somescript.sh
MODE=keyboard
<some menu creation and display logic here>
<user interacts with menus>
...
MODE=gamepad
<menu kicks off a game with certain parameters>If I understood correctly: once this is implemented, in Game Mode, some environment variable will be set by default, presumably
GTK_IM_MODULE=Steam. When this is enabled, applications with a text entry field will support entering text via any keyboard type.
Correct (for GTK applications).
Will the act of focusing the text entry field raise the virtual keyboard, or is this considered the responsibility of the user?
It should raise the keyboard, that's what that IM module was written for. Note that due to details in the implementation there might be inconsistencies once in a while and situations where the user has to open the keyboard manually, but in general it should be automatic.
There are two use cases here. Using an application standalone in Desktop Mode or adding it to Steam as a non-Steam game for the purposes of being able to access it in Game Mode. If you run the application example above, in Desktop Mode, the button-to-keyboard mappings you mention are working out of the box when it is run directly, i.e., not added as a non-Steam game. Is this behavior expected? Will these keybindings stop working in Desktop Mode if Steam is open?
In Desktop mode (without Steam) the controller emulates the arrow keys with the dpad, A/B work as Enter/Escape, etc., The driver calls this the "lizard mode".
If Steam is open then it takes over the handling of the controller and it works according to the layout defined in Steam.
I did not see any mention of test 2c: this is where, in Desktop Mode, an application is fullscreen and the virtual keyboard spawns underneath the top window in the stack. Is there any scenario where it would be desirable or expected for a virtual keyboard overlay to be anywhere other than on top of the window stack?
Ideally the virtual keyboard should appear on top but I haven't had the chance to investigate this yet. My first reaction anyway is that a dialog should not be opened in fullscreen mode so if this happens in a real-world scenario I would see why that dialog is opened like that.
I understand what you are saying, but does this actually address the underlying issue in test 4a? Is there a reason why the current toggle mode is lost when the window changes contexts? This seems underspecified or at least unexpected. Having to manually pulse the three dots button as a method of last resort is fine, but it's not clear why this mode changes before and after the virtual keyboard is spawned.
That part is handled by the Steam client and I actually don't know how it works.
Moving on to the final point about controller layouts, let me give some additional context. This is about Game Mode only. The application in question is used by a large number of Steam Deck users. These users mostly prefer to avoid having to drop into Desktop Mode for the purposes of launching the application. They also tend to have a lower technical literacy and have some expectation of basic navigation being available out of the box. However, this is originally a desktop application that I am hard-pressed to rewrite from the ground up, so I am trying to make concessions here to at least pass the right parameters to Steam Deck to make the OOB experience behave in a more expected fashion.
As a stopgap, I actually created and provide a community controller layout that maps those buttons to navigation commands, but this is undesirable because a) the application itself is responsible for launching other games, so the user effectively has to toggle between two layouts or layers (the initial application keybindings and the actual game's bindings once launched) and b) it can be pretty difficult to communicate to users that they need to fetch and use this layout. At least in the case of the three dots button toggle, the mechanism is simple and easy to explain (just push it on or off, no swapping controller layouts as such).
Thanks for the context, this makes it easier to understand the use case. As I said I'm not too familiar with how Steam handles the different layouts but I'll come back to you if I have more information.
One additional question: from what you say it sounds like if users take the extra steps to switch the desktop mode and run the app from there then it works fine, is that so? Isn't that more or less the same as running it from game mode with a layout that maps the dpad to the arrow keys, etc.?
aclist
commented
7 months ago Thanks, that explains a lot of things for me. One point of clarification and one reply:
Ideally the virtual keyboard should appear on top but I haven't had the chance to investigate this yet. My first reaction anyway is that a dialog should not be opened in fullscreen mode so if this happens in a real-world scenario I would see why that dialog is opened like that.
While the test provided just spawns a dialog, I was talking about an actual application (Gtk.App) which creates an entire outer window context (Gtk.Window), and may or may not have dialogs or menus within it. The fullscreen property would be set on the outer window itself. I think this is a reasonable real-world scenario for a kiosk-style application.
One additional question: from what you say it sounds like if users take the extra steps to switch the desktop mode and run the app from there then it works fine, is that so? Isn't that more or less the same as running it from game mode with a layout that maps the dpad to the arrow keys, etc.?
While I fully agree, I think users' behavior here is telling: for one, only a sliver of users actually want to drop into Desktop Mode, seeing it as a last resort for the purposes of system maintenance and the like, or to install third-party applications before going back to Game Mode. They want to always be in Game Mode when launching/navigating games or apps. Many have no prior usage context for Linux and find Desktop Mode to be overly complicated for day-to-day use.
At one point, I decided to block the application from launching on Game Mode (due to the bugs above) and trigger a dialog warning the user to go into Desktop Mode to use it properly. Users were vocally against this change and wanted it reverted. Even with the presence of keyboard input bugs, they wanted to stay in Game Mode--boot the device, navigate the library, and launch the game/app, no Desktop Mode. The application even ships with XDG shortcuts in the start menu and an icon gets placed on the desktop as a turnkey way of launching it, but despite this, the vast majority of (Steam Deck) users seem to shy away from this method.
From what I've gathered, they use Desktop Mode as a one-off to add the application as a non-Steam game, then prefer to "set it and forget it" and exclusively use it in Game Mode alongside their other library titles. This use case may differ if the user has a lot of third-party applications/productivity apps and is used to flipping over to Desktop Mode, but it seems like this is only a small subset of users.
bertogg
commented
7 months ago Hi, I'm not sure that I made myself clear, I was referring to this paragraph:
I actually created and provide a community controller layout that maps those buttons to navigation commands, but this is undesirable because a) the application itself is responsible for launching other games, so the user effectively has to toggle between two layouts or layers (the initial application keybindings and the actual game's bindings once launched) and b) it can be pretty difficult to communicate to users that they need to fetch and use this layout.
The problem of the user having to toggle between two layouts also exists doesn't go away if the app is run directly from desktop mode, or is it ?
aclist
commented
7 months ago The problem of the user having to toggle between two layouts also exists doesn't go away if the app is run directly from desktop mode, or is it ?
The problem does go away (just tested it again to confirm). Because in Desktop Mode, the default lizard brain bindings suffice to allow navigation with D-pad and confirmation with surface buttons. Once the third-party application launches the game, the game defaults to whatever the default Steam controller layout was, which is not the same as lizard brain bindings. Whether or not the user set a specific controller layout here, the game will already have controller bindings (such as joystick, trackpad, etc.) of some type ready to go, so the user never has to toggle between states. Whereas in Game Mode, they have to not only search for and install, but also continually toggle between, an application-specific layout and the game layout.
bertogg
commented
7 months ago Once the third-party application launches the game, the game defaults to whatever the default Steam controller layout was
Why does it get the Steam controller layout? Is the game is launched through Steam?
aclist
commented
7 months ago Yes, the launcher requests Steam to launch games by invoking them with certain command line parameters.
bertogg
commented
2 months ago Coming back to this, sorry that it took so long. As you have probably seen the fixed IM module is available in SteamOS 3.6, so I understand that the original problem is fixed.
If I haven't forgotten anything important I think that the other problem was:
In desktop mode your application works fine by default: the default bindings ("lizard mode") allow the user to navigate the dialogs using the D-Pad, and when you launch a game you do it through Steam, and that changes the controller layout to what the game needs. So everything works fine.
In gaming mode Steam defaults to a different layout (not lizard mode) that won't allow your application to use the D-Pad to navigate the dialogs. Long pressing the three dots button switches back and forth between this layout and lizard mode. Earlier it was the case that you could only do this once but now I can switch modes many times without problems.
Can you confirm that the original problem is solved and that using the three dots button solves the other issue, or is there anything else that I missed?
Thanks!
aclist
commented
2 months ago Thanks for the follow-up. I have just tested it on the latest version.
In desktop mode your application works fine by default: the default bindings ("lizard mode") allow the user to navigate the dialogs using the D-Pad, and when you launch a game you do it through Steam, and that changes the controller layout to what the game needs. So everything works fine.
This is working.
In gaming mode Steam defaults to a different layout (not lizard mode) that won't allow your application to use the D-Pad to navigate the dialogs. Long pressing the three dots button switches back and forth between this layout and lizard mode. Earlier it was the case that you could only do this once but now I can switch modes many times without problems.
For the most part, yes. But one problem (room for improvement) I see here is that the three dots button is bound to three actions with different input timing windows:
The timing for medium press falls very narrowly between these two, so more often than not you are invoking a short or long press by mistake and causing unwanted modals to appear. Sometimes, it seems like you can also toggle lizard mode as a side effect of opening these modals, but the effect feels inconsistent. There is also no onscreen indication of the lizard mode toggle, which further exacerbates the issue.
The only other outstanding issue mentioned above has to do with the virtual keyboard sometimes failing to spawn or behaving erratically on Game Mode:
I do not know why the virtual keyboard is more liable to spawn when other modals have been spawned before it.
I've alluded to this issue before in this ticket, but it is orthogonal to the lizard mode issue. If you feel this merits its own ticket, and the original issue in this ticket is (tentatively) solved, that seems like a good course of action.
While we are on the subject of GTK applications, I also observed that dialogs (modal or otherwise) spawned in Game Mode are created in a kind of "pseudo fullscreen mode," where the background goes black and the dialog is shown centered and scaled in the viewport. For some reason, these dialogs always have low resolution text, as though the dialog was forcibly upscaled from its original resolution, rather than being resized accordingly. (Possibly a side effect of GDK_SCALE or GDK_DPI_SCALE settings being set incorrectly by Steam? How is Game Mode attempting to scale applications?) I think this deserves its own ticket if it does not exist already.
bertogg
commented
1 month ago one problem (room for improvement) I see here is that the three dots button is bound to three actions with different input timing windows:
* Short press: pop out the sidebar overlay * Medium press: toggle lizard mode * Long press: pop out the keybindings modalThe timing for medium press falls very narrowly between these two, so more often than not you are invoking a short or long press by mistake and causing unwanted modals to appear. Sometimes, it seems like you can also toggle lizard mode as a side effect of opening these modals, but the effect feels inconsistent. There is also no onscreen indication of the lizard mode toggle, which further exacerbates the issue.
I see. This behavior of the three dots button is probably an issue for https://github.com/ValveSoftware/steam-for-linux
The only other outstanding issue mentioned above has to do with the virtual keyboard sometimes failing to spawn or behaving erratically on Game Mode:
This probably merits its own separate ticket.
While we are on the subject of GTK applications, I also observed that dialogs (modal or otherwise) spawned in Game Mode are created in a kind of "pseudo fullscreen mode," where the background goes black and the dialog is shown centered and scaled in the viewport. For some reason, these dialogs always have low resolution text, as though the dialog was forcibly upscaled from its original resolution, rather than being resized accordingly. (Possibly a side effect of
GDK_SCALEorGDK_DPI_SCALEsettings being set incorrectly by Steam? How is Game Mode attempting to scale applications?) I think this deserves its own ticket if it does not exist already.
That's exactly what happens. Apps and games run at a certain resolution and the Gamescope compositor scales the content.
Your system information
Please describe your issue in as much detail as possible:
This issue has been present since release, afaik. Form dialogs spawned through zenity and invoked through, e.g., a shell script and added as a non-Steam application do not receive keyboard input when in Gaming Mode. They work as intended in Desktop Mode.
Steps for reproducing this issue: