https://bugs.kde.org/show_bug.cgi?id=520692

--- Comment #4 from [email protected] ---
(In reply to jwl from comment #3)
> I am also seeing this happen in multiple games, and even outside of games. I
> have a controller that can swap between DirectInput (emulating a PS4
> controller) and Xinput (emulating a wired Xbox 360 controller) and I see
> this behavior in both modes, both in and out of games (tested with Street
> Fighter 6 running on Proton through Steam). The observed result is the same
> as reported by [email protected].

It seems like by default, what is normally the `Start` button on many
controllers is mapped to send a `Meta` input. If one wanted to use a controller
to control a system running KDE, that's not an unreasonable mapping to make.
And, as per the dialog that surfaces when the user disables 'Allow using as
pointer and keyboard', allowing the controller to send mouse and keyboard
inputs is one way to prevent the screen from locking when the user is seemingly
not producing input. But when combined with the reality that a great many games
will often have the user pressing `Start` for any number of reasons (ie.
pausing the game, opening a menu, confirming any number of options etc.), this
mapping seems problematic.

I am not a developer, but it seems like there are a few of solutions here:

1. Change whatever controls lock screen behavior to accept game controller
input as valid input
2. Change the mapping of `Start` to something other than `meta`. It should also
be noted that there are other problematic mappings, such as XInput B being
mapped to `Esc`, XInput Right Shoulder being mapped to `Alt`, XInput Left
Shoulder being mapped to `Ctrl`.
3. Allow user re-mapping of all Game Controller inputs so that `Start` can be
remapped to something else, along with any other problematic inputs.

I have no idea as to the feasibility of any of these, so maybe none of these
are realistic however.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to