Bug 328987

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 ~]$