I have the same problem in kde from debian testing.
When I play games using a joystick, the monitor decrease luminosity. 

Reproducible: Always

PowerDevil uses KIdleTime to track an idle session, re-assigning.

This is a big problem!
It basically means I can’t play videogames without having to disable screensaver first…

Is this a complicated thing to fix?

*** Bug 356636 has been marked as a duplicate of this bug. ***

As I don't have a joystick: could someone please run the tool "xev" and see whether there are input events shown when using the joystick and if what kind of events are reported?

(In reply to Martin Gräßlin from comment #5)
> As I don't have a joystick: could someone please run the tool "xev" and see
> whether there are input events shown when using the joystick and if what
> kind of events are reported?

No, nothing shows up in xev when I press buttons on my gamepad.

Tried this in both Kubuntu 15.10 and Ubuntu 15.10, xev doesn't show any notifications from the gamepad. Don't mind testing it on other systems as well if you think this helps.

Thanks a lot for the testing! It's unfortunately what I expected, the gamepad bypasses the X-Server which means our normal interaction in KIdleTime just doesn't/cannot work :-(

Would donating a gamepad to a developer help or is this issue too far out of scope for KIdleTime? The input-devices in systemsettings seems to be aware of of the joysticks and be able to get their events, so perhaps it is dealt with in another part of KDE already.

Out of curiosity, is this X specific or will this affect Wayland as well? (i.e. will this bug solve itself as soon as the Wayland transition is complete?)

> Would donating a gamepad to a developer help or is this issue too far out of scope for KIdleTime?

I have a gamepad for my playstation. Need to try whether it works at all on linux.

> Out of curiosity, is this X specific or will this affect Wayland as well?

I don't know yet. But actually that's the part I want to test with the gamepad. If it's fixed on Wayland it's unlikely that we will get support for it in KIdleTime on X11. If it works in neither, I will look into what could be a solution for KIdleTime. It might mess with the functionality a lot, so no promise that it can be fixed.

gamepad works, I see the events in the joystick kcm. Now the bad news: libinput doesn't provide support for it, see [1]. Which means also on Wayland we don't get the events into KIdleTime.

Now getting this into KIdleTime is tricky. We would need to add a second source for checking idle and only consider the session as idle if both sources are idle. Not an easy change. Even more we would need to move the monitoring of joysticks into the applications, while monitoring of pointer/keyboard/touch is inside the display server. All applications using KIdleTime would then get woken up on each event. Not good. This needs serious thinking on how to integrate it and will take time.

[1] http://lists.freedesktop.org/archives/wayland-devel/2015-January/019462.html

*** Bug 364592 has been marked as a duplicate of this bug. ***

*** Bug 366529 has been marked as a duplicate of this bug. ***

What if we had instead a standard way for applications to say "hey, I'm using the joystick, please don't lock the screen" ? Would it be possible from a technical point of view?

On the other hand, from the Martin's link above the reason why X11 and libinput ignore joysticks seems to be "too much joysticks; no real use case".

But I think that idle detection is a valid use case, not every game out there uses modern libraries like SDL. And to have working idle detection we would need a very simple information from xcb/libinput: "joystick unused" vs "something pressed on the joystick".

(In reply to Elvis Angelaccio from comment #14)
> What if we had instead a standard way for applications to say "hey, I'm
> using the joystick, please don't lock the screen" ? Would it be possible
> from a technical point of view?

The API to disable power saving/screen locking must already exist - most video players use it. The problem is that the API must be used by the application, and you can't expect every game disable power saving. Also, in case if the application crashes, chances are high that the power saving remains disabled.

I wonder if KIdleTime could instead listen for /dev/input/js* and /dev/input/event* events as an indication of user input.

Right, I didn't think about video players. It seems we already have a standard dbus api for this. We surely can't expect every game to use it, but at least "hubs" like steam and dolphin-emu could, imho.

Most games do, in fact, inhibit power saving. If you have a game running and open the energy management tray thingie, it will even tell you the name of the game blocking power saving (unfortunately, most don't bother changing the default so they are called something like "an SDL application").
AFAIK the power management inhibition is tied to the DBus name of the application. If the application dies, its DBus name vanishes, and the inhibition is removed as well.
All these are not reasons against a workaround for sloppily programmed games, I am just saying that the power management inhibition system works very well when it is used.

(In reply to Andreas Hartmetz from comment #18)
> If the application dies, its DBus name vanishes, and the
> inhibition is removed as well.

[offtopic]
In the past, I had multiple cases when a video player died and power saving was not restored. Granted, I am not familiar with technical details and have no idea what could have caused this or if this was fixed somewhere (I didn't have player crashes for a long time). It's just apparently there might be a case where power saving remains disabled.
[/offtopic]

> All these are not reasons against a workaround for sloppily programmed games

Absolutely.

Hi ! Would it be possible to add an option in the "KWin Rules" utility to bypass the screen blanking ? 

I noticed this problem occurs when playing Wine games (i.e. through Steam Play). My monitor is put to sleep after 10 mins when playing with a gamepad/joystick controller.

I did add a kwin rule to disable compositing for wine but it seems there no option related to the energy settings.

Of course, the other way would be to make wine / steam play disable the screensaver.

(In reply to Mahendra Tallur from comment #20)
> Hi ! Would it be possible to add an option in the "KWin Rules" utility to
> bypass the screen blanking ? 
> 
No, KWin is not involved in dpms.

*** Bug 406853 has been marked as a duplicate of this bug. ***

*** Bug 419460 has been marked as a duplicate of this bug. ***

Since this is such a longstanding bug with apparently no easy solution, maybe a possible workaround or alternative way of dealing with it could be adding a sort of "Gsme Mode" to KDE. It could simply be a quick-access widget of some kind that's configurable to do things like disable the screensaver, power management and compositing. Maybe it would even be possible to add a list of applications to it do that, whever an application on the list is launched, game mode automatically activates. The widget could monitor whether the specified applications are running, and then deactivate game mode automatically when the application is either exited normally or crashes. Would something like that be possible?

Battery Monitor → Uncheck "Enable power management".

Most modern games actually do.

(In reply to Kai Uwe Broulik from comment #25)
> Most modern games actually do.

No, I wouldn't say so. You can see it happen even on Windows if you leave a game running with no user input - the display turns off after a while. But on Windows games don't have to do anything about it as gamepad input cancels powersaving on that OS.

As a personal workaround I'm using the lightsOn.sh script written by someone. Here is my fork with some improvements:

https://github.com/lastique/lightson

It works on X11 system and blocks powersaving if there are any fullscreen windows. It works for fullscreen video players in browsers and games.

I know that KWin is not involved in DPMS, but I wonder if it would be possible to implement that kind of rule in it. Or more generally - block DPMS if there is a window matching some criteria set by user, with "fullscreen" being one example. As a bonus, it could work in Wayland as well (I'm not sure if lightsOn.sh is even possible to implement on Wayland).

*** Bug 420359 has been marked as a duplicate of this bug. ***

Any progress on this?

Right now as workaround i use https://github.com/FeralInteractive/gamemode

What is interesting to me is that when only using a controller, the screen eventually turns off but it does not lock. I.e. controller input seems to prevent the "Lock screen automatically --> After X" setting from triggering but not the "Screen Energy Saving" setting. Do these two settings use different methods for checking input activity?

Plasma 5.25.5 (wayland), frameworks 5.98.0, Qt 5.15.5

*** Bug 465541 has been marked as a duplicate of this bug. ***

I noticed this problematic behavior with a Switch Pro Controller, wired or in Bluetooth, Wayland or X11.

I have the issue on two systems:

Operating System: MocaccinoOS (Gentoo based)
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Kernel Version: 6.1.32-mocaccino (64-bit)
Graphics Platform: X11
Processors: 16 × 11th Gen Intel® Core™ i7-11700K @ 3.60GHz
Memory: 61.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2
Manufacturer: ASUS

*** Bug 471047 has been marked as a duplicate of this bug. ***

*** Bug 472465 has been marked as a duplicate of this bug. ***

Same here using Wayland. Wired MS XBOX 360 Pad / Switch Pro Controller.

Operating System: openSUSE Tumbleweed 20231206
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
Kernel Version: 6.6.3-1-default (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Graphics Processor: AMD Radeon RX 7600
Product Name: B550M Phantom Gaming 4

Also experiencing this bug. It is a problem when using Steam.

System details:

Operating System: Gentoo Linux 2.14
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.113.0
Qt Version: 5.15.11
Kernel Version: 6.1.67-gentoo-x86_64 (64-bit)
Graphics Platform: Wayland

Wow this is an ELEVEN (!) year old bug. Same issue here. Dual Shock 4 controller connected via bluetooth, playing on Steam.

(In reply to timonoj from comment #39)
> Wow this is an ELEVEN (!) year old bug. Same issue here. Dual Shock 4
> controller connected via bluetooth, playing on Steam.

XD LOL ... I guess this is your first bug confirmation/report... I have reported errors the same and even more years ago than this one. But the priorities or importance (in this case "HI normal") we (users) give to it is relative - that's what I've been told when I've asked about it - so, this may be here until Windows creates a desktop for Linux ....

Fedora 39, Wayland, KDE, Steam installed via Flatpak, using not joystick but gamepad (Vader 2) and my Monitor switches off according to power settings.

Just a note to help those effected, launching the game through "gamemoderun" wrapper (Or adding it to the steam launch commands [gamemoderun %command%]) Will keep the screen awake while playing, and can have some other benefits to system tweaking if desired, there is also an applet in kde that allows you to temporarily disable screen timeout

(In reply to Michael Rogers from comment #42)
> Just a note to help those effected, launching the game through "gamemoderun"
> wrapper (Or adding it to the steam launch commands [gamemoderun %command%])
> Will keep the screen awake while playing, and can have some other benefits
> to system tweaking if desired, there is also an applet in kde that allows
> you to temporarily disable screen timeout

Thank you for sharing. I didn't know that feature of "gamemoderun". It's a interesting workaround if only using one games launcher. In my case, I use more tha four (Heroic, Yuzu, PPSP, Lutris) so in my case, I prefer to wait for a fix for this.

I'm experiencing this bug as well.

Operating System: Void Linux
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.11
Kernel Version: 6.6.16_1 (64-bit)
Graphics Platform: Wayland

Is there any hope that this bug will be fixed before the heat death of the universe?

Same issue here - using xone with the Xbox wireless dongle.

Distro: Arch
Kernel: 6.7.8-arch1-1
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 5.155.0
Display Server: Wayland

Looks like this might actually be an issue with KWin though as opposed to kidletime. Ultimately, the idle detector here drives the behaviour in kidletime, and by extension kscreenlocker. Currently this is only listening for key, pointer, touch, gesture and tablet events as a trigger for inhibiting the idle detector. Presumably the fix for this would be to also include gamepad events here too.

Did a bit more digging into this, and it seems non-trivial. As of now, KWin receives input from "backends", of which there are several (Wayland, X11, libinput etc).

It seems like gamepads exist outside of this usual architecture, as the input would come from the gamepad device itself, rather than via X11, Wayland, libinput etc.

Not the nicest solution ever, but I wonder if we might get around this by adding the gamepad read functionality to the base `InputDevice` class? That way it would work across multiple backends, even if it is a bit of a deviation from the current design.

I also just experienced this using a Steam Controller on the latest Plasma 6.0.1 release when trying out the FF7 remake. Screen goes to sleep even with controller input - work around right now is just manually inhibiting sleep/suspend and re-enabling.

(In reply to Joe from comment #48)
> I also just experienced this using a Steam Controller on the latest Plasma
> 6.0.1 release when trying out the FF7 remake. Screen goes to sleep even with
> controller input - work around right now is just manually inhibiting
> sleep/suspend and re-enabling.

I have the same issue.

I have the same problem with Logitech G29 gaming racing wheel. The screen locks after a few minutes of playing. This was on Fedora 39 KDE Plasma 5.27 too.

Operating System: Fedora Linux 40
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.8.10-300.fc40.x86_64 (64-bit)
Graphics Platform: Wayland

*** Bug 486292 has been marked as a duplicate of this bug. ***

Is it worth raising a bug with libinput

*** Bug 447099 has been marked as a duplicate of this bug. ***

*** Bug 489177 has been marked as a duplicate of this bug. ***

Regardless of whether you have control or not, this bug of turning off, blocking the screen happens when you watch videos on firefox or telegram for example, Plasma is not respecting the rule that shows on the power plasmoid that the application is preventing from turning off the screen!
It also happens if the game is paused without using the mouse, the monitor turns off and locks!

Arch Linux
Plasma 6.1.1
KDE Frameworks: 6.3.0
Qt: 6.7.2
Kernel 6.9.7-arch1-1
Wayland

Fedora Atomic Kinoite 40
Plasma 6.1.1
KDE Frameworks: 6.3.0
Qt: 6.7.1
Kernel: 6.9.6-200.fc40.x86_64
Wayland

I'm actually a little confused - shouldn't "block sleep and screen locking" just block it period, regardless of whether there is user input or not?

Also FWIW I can't recall encountering this bug when using my Xbox 360 wired controller, only when using my G923.

(In reply to spamless.9v5xj from comment #57)
> I'm actually a little confused - shouldn't "block sleep and screen locking"
> just block it period, regardless of whether there is user input or not?
> 
> Also FWIW I can't recall encountering this bug when using my Xbox 360 wired
> controller, only when using my G923.

yes it should, but plasma doesn't seem to respect that.

(In reply to José Rafael from comment #56)
> Regardless of whether you have control or not, this bug of turning off,
> blocking the screen happens when you watch videos on firefox or telegram for
> example, Plasma is not respecting the rule that shows on the power plasmoid
> that the application is preventing from turning off the screen!
> It also happens if the game is paused without using the mouse, the monitor
> turns off and locks!
> 
> Arch Linux
> Plasma 6.1.1
> KDE Frameworks: 6.3.0
> Qt: 6.7.2
> Kernel 6.9.7-arch1-1
> Wayland
> 
> Fedora Atomic Kinoite 40
> Plasma 6.1.1
> KDE Frameworks: 6.3.0
> Qt: 6.7.1
> Kernel: 6.9.6-200.fc40.x86_64
> Wayland

you're talking about other bug, that got fixed in 6.1.4

I'm having the same issue

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
When playing retroarch with a joypad, the screen locks after 5 minutes (it's my configured time) as if the joypad actions wouldn't count as activity. 

STEPS TO REPRODUCE
1. Connect a joypad
2. Use it for 5 minutes (playing a game or whatever)
3. Wait until the screen locks

OBSERVED RESULT
Screen locks after the time and have to unlock it moving the mouse or touching the keyboard.

EXPECTED RESULT
Screen just not locks, only stays active until real inactivity happens.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedroa 40 plasma
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
My joypad is Logitech RumblePad 2 USB

I was not having this issue on KDE Plasma 6 until about the middle of last week.  Somehow it started last week, and now I have to use a workaround of setting "Sleep and Screen Locking after Inactivity" to "Blocked" in the Plasma "Power Management" menu that's accessed from the panel's "System Tray" widget's "Power Management" icon.  It didn't happen before last week, even though I have been playing the same game as I was before last week regularly.

I am using Manjaro with the "unstable" set of repositories, which gets updates consistently multiple times per day from the Arch Linux "stable" set of repositories, and I regularly update my system daily, with a full reboot each time.  Therefore, I expect that some update I applied last week caused this to happen.  I'm not sure what the exact update was, but here's the current output of `pacman -Qi kidletime` which shows the version of the `kidletime` package I have installed right now:

[alex@alex-pc ~]$ pacman -Qi kidletime
Name            : kidletime
Version         : 6.5.0-1
Description     : Monitoring user activity
Architecture    : x86_64
URL             : https://community.kde.org/Frameworks
Licenses        : LGPL-2.0-only  LGPL-3.0-only
Groups          : kf6
Provides        : None
Depends On      : gcc-libs  glibc  qt6-base
Optional Deps   : libx11: XCB plugin [installed]
                  libxcb: XCB plugin [installed]
                  libxext: XCB plugin [installed]
                  libxss: XCB plugin [installed]
                  qt6-wayland: Wayland plugin [installed]
                  wayland: Wayland plugin [installed]
Required By     : baloo  discover  drkonqi  konversation  kscreenlocker  kwin  plasma-workspace  powerdevil
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 395.11 KiB
Packager        : Tomaz Canabrava <tcanabrava@archlinux.org>
Build Date      : Fri 09 Aug 2024 07:32:20 PDT
Install Date    : Thu 05 Sep 2024 12:09:31 PDT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

[alex@alex-pc ~]$

I can confirm this is still a problem with plasma 6.2.4 and kde framework/qt version 6.8. Using a dualsense controller, the system goes to sleep while I'm playing.

Same problem with Plasma 6.2.4 in Opensuse Tumbleweed.

I can confirm this occurs in EndevourOS

Operating System: EndeavourOS 
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.11.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics
Memory: 12.6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: AZW
Product Name: SER

*** Bug 498245 has been marked as a duplicate of this bug. ***

For anyone having this problem, using feral gamemode is a good work around as it prevents sleep/suspend

I also would like to say I experience this issue. Just happened to me and thus I found this thread.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.7-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7600 6-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4060/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B650M C V2-Y1
System Version: -CF

This issue is so old it can you to middle school.

Anyway, Gamemode is a pain to set up cause it needs to be configured for each game individually. A solution I found is this: 

https://github.com/rafaelrc7/wayland-pipewire-idle-inhibit

It inhibits sleep if there is any application playing a sound, which means it is global. Frankly, KDE could have an option that inhibits sleeps based on sound playing, as it is useful outside of the gamepad issue

(In reply to WS from comment #68)
> This issue is so old it can you to middle school.
> 
> Anyway, Gamemode is a pain to set up cause it needs to be configured for
> each game individually. A solution I found is this: 
> 
> https://github.com/rafaelrc7/wayland-pipewire-idle-inhibit
> 
> It inhibits sleep if there is any application playing a sound, which means
> it is global. Frankly, KDE could have an option that inhibits sleeps based
> on sound playing, as it is useful outside of the gamepad issue

Any audio player inhibiting display power saving does not seem like an adequate solution.

Not as a proper solution for this issue, but as an unrelated option hidden somewhere it doesn't seem so bad. 

Regardless, it doesn't appear that a solution is being worked right now, and it appears that gamepads work very differently than mouse, keyboard and other input devices.

As an unrelated example: I've recently gotten a Dualsense controller, and my expectation was that while Steam Input was translating to Xinput, it would "grab" and suppress the original Dualsense input, but KDE still interpreted the touchpad as a touchpad even while Steam was using it as a controller, had to disable the touchpad in KDE, which wasn't really what I expected to happen

Chiming in that I've had this issue with Wayland. X11 seems to somehow let Steam not make trigger the screen dimming and going to sleep, native or Flatpak. Been dealing with this issue since 2023.

Just joining in to report that this is still an issue for me on Gentoo w/ Plasma 6.3.5 and Frameworks 6.14.0. This is using the xpadneo driver for an Xbox Series controller with Ryujinx under Wayland. 

Would really love a solution, even though it's not a big deal moving my mouse every so often.  The wayland-pipewire-idle-inhibit seems akin to applying a sledgehammer to a problem where a small screwdriver wouid do, too.

I've had this issue too. I am using the xpadneo driver for an Xbox Series controller with Yuzu.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.4.1
KDE Frameworks Version: 6.15.0
Qt Version: 6.8.3
Kernel Version: 6.15.3-100.fc41.x86_64 (64-bit)
Graphics Platform: Wayland

Just created this account to join in on the choir of the doomed.
Same issue here, my specs:

Operating System: CachyOS Linux 
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.15.7-3-cachyos (64-bit)
Graphics Platform: Wayland

(In reply to Linux Newbie from comment #74)
> Just created this account to join in on the choir of the doomed.
> Same issue here, my specs:
> 
> Operating System: CachyOS Linux 
> KDE Plasma Version: 6.4.3
> KDE Frameworks Version: 6.16.0
> Qt Version: 6.9.1
> Kernel Version: 6.15.7-3-cachyos (64-bit)
> Graphics Platform: Wayland

OMG, I made such a fool of myself. Forget what I wrote, everything is working fine. Power saving is suspended when I use the controller.

I can replicate this bug on Arch when I use my Logitech X56 Pro HOTAS Joystick. All works fine however, if I use an Xbox one controller via bluetooth. Will gladly follow this bug to track its progress, and I am available for testing if required.

I also have this issue when using a Stadia controller connected via USB, this is what dmesg shows when it is connected:

[172421.461371] usb 3-1: new high-speed USB device number 23 using xhci_hcd
[172421.648278] usb 3-1: New USB device found, idVendor=18d1, idProduct=9400, bcdDevice= 1.00
[172421.648291] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[172421.648295] usb 3-1: Product: Stadia Controller rev. A
[172421.648298] usb 3-1: Manufacturer: Google LLC
[172421.648300] usb 3-1: SerialNumber: 9A110YCAC27GDX
[172421.659853] input: Google LLC Stadia Controller rev. A as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.1/0003:18D1:9400.001C/input/input56
[172421.711694] stadia 0003:18D1:9400.001C: input,hidraw5: USB HID v1.11 Gamepad [Google LLC Stadia Controller rev. A] on usb-0000:00:14.0-1/input1
[172421.711711] stadia 0003:18D1:9400.001C: Force Feedback for Google Stadia controller
[172428.300284] usb 3-9: reset full-speed USB device number 3 using xhci_hcd
[172428.557030] usb 3-9: reset full-speed USB device number 3 using xhci_hcd

There is an ongoing GSOC project implementing support for this bug. Just today there was an update on planet.kde.org. Please see: https://blogs.kde.org/2025/09/15/gsoc25-kwin-project-blog-post-week-3-4/

*** Bug 511786 has been marked as a duplicate of this bug. ***

Relevant MRs have been created by Yelsin Sepulveda (resulting from the GSoC project) and are now both approved for merging:
https://invent.kde.org/plasma/kwin/-/merge_requests/8126
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3229

Git commit 3110eaef472059749a2f683de7f399a391ea145a by Xaver Hugl, on behalf of Yelsin Sepulveda.
Committed on 02/01/2026 at 13:56.
Pushed by zamundaaa into branch 'master'.

plugins: add gamecontroller plugin

This plugin provides some integration for game controllers.
While no other process is using a given controller device, it
translates controller inputs to keyboard and mouse events, to
make the device useful for input on the desktop.
It also prevents the system from going idle (turning the screen
off or going to standby) while any gamepad is used.

M  +4    -0    CMakeLists.txt
M  +3    -0    autotests/integration/CMakeLists.txt
A  +527  -0    autotests/integration/gamecontroller_test.cpp     [License: GPL(v2.0+)]
M  +3    -0    src/plugins/CMakeLists.txt
A  +28   -0    src/plugins/gamecontroller/CMakeLists.txt
A  +393  -0    src/plugins/gamecontroller/emulatedinputdevice.cpp     [License: GPL(v2.0+)]
A  +63   -0    src/plugins/gamecontroller/emulatedinputdevice.h     [License: GPL(v2.0+)]
A  +145  -0    src/plugins/gamecontroller/gamecontroller.cpp     [License: GPL(v2.0+)]
A  +58   -0    src/plugins/gamecontroller/gamecontroller.h     [License: GPL(v2.0+)]
A  +227  -0    src/plugins/gamecontroller/gamecontrollermanager.cpp     [License: GPL(v2.0+)]
A  +61   -0    src/plugins/gamecontroller/gamecontrollermanager.h     [License: GPL(v2.0+)]
A  +32   -0    src/plugins/gamecontroller/main.cpp     [License: GPL(v2.0+)]
A  +10   -0    src/plugins/gamecontroller/metadata.json

https://invent.kde.org/plasma/kwin/-/commit/3110eaef472059749a2f683de7f399a391ea145a

Git commit 7493110869a4e595e553218a9b5b34ecfeb7e21a by Jakob Petsovits, on behalf of Yelsin Sepulveda.
Committed on 02/01/2026 at 23:00.
Pushed by jpetso into branch 'master'.

kcms/gamecontroller: Add switch for KWin "gamecontroller" plugin

Add the ability to enable/disable the new KWin "gamecontroller"
plugin from KWin commit 3110eaef. The new UI element will be
added as part of the existing gamecontroller KCM.

This plugin provides some integration for game controllers.
While no other process is using a given controller device, it
translates controller inputs to keyboard and mouse events, to
make the device useful for input on the desktop.
It also prevents the system from going idle (turning the screen
off or going to standby) while any gamepad is used.

M  +1    -0    .gitignore
M  +1    -0    kcms/gamecontroller/CMakeLists.txt
M  +41   -1    kcms/gamecontroller/kcm.cpp
M  +10   -2    kcms/gamecontroller/kcm.h
M  +39   -1    kcms/gamecontroller/ui/main.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/7493110869a4e595e553218a9b5b34ecfeb7e21a

This "fix" is incredibly hacky and in my opinion is not a fix at all. In order to block sleeping, the user has to enable the "Allow using as pointer and keyboard" toggle under the Game Controller settings. This is very non-intuitive and I don't think any normal user would ever find this, but that's beside the point.

Piggybacking off of the mouse functionality to block sleeping means that any controller we want this to work with will be constantly controlling the mouse. This should be obviously not desired. There might be edge cases where people want to use controllers to control the mouse/keyboard, but I absolutely do not want that to happen while I'm playing a game.

This has actually put me in a state where I can't even plug my racing wheel in, because I toggled the option on and now my gas pedal corresponds to the vertical mouse axis. This constantly drags my mouse cursor to the bottom of the screen. I unplugged the wheel and now my system settings dialogue is frozen and unkillable, which I suppose is a separate bug.

Please reconsider this fix and implement a proper one. I think it's reasonable that any human input device that's receiving input should block sleep, and we shouldn't have to manually enable the functionality. But if we do have to, it certainly should not also start controlling the mouse.

(In reply to aldrenean from comment #83)
> Piggybacking off of the mouse functionality to block sleeping means that any
> controller we want this to work with will be constantly controlling the
> mouse. This should be obviously not desired. There might be edge cases where
> people want to use controllers to control the mouse/keyboard, but I
> absolutely do not want that to happen while I'm playing a game.
> 
> This has actually put me in a state where I can't even plug my racing wheel
> in, because I toggled the option on and now my gas pedal corresponds to the
> vertical mouse axis. This constantly drags my mouse cursor to the bottom of
> the screen. I unplugged the wheel and now my system settings dialogue is
> frozen and unkillable, which I suppose is a separate bug.
Can you open a new bug report for this?

> Please reconsider this fix and implement a proper one. I think it's
> reasonable that any human input device that's receiving input should block
> sleep, and we shouldn't have to manually enable the functionality. But if we
> do have to, it certainly should not also start controlling the mouse.
if it was that easy, it would have been done a decade ago.