I play games using a joystick. After 10 min, the monitor turns off until I hit a key or move the mouse.
It is not detecting that there is input activity, but in the joystick, not via mouse or keyboard.
Adding back the option to turn off power saving when fullscreen is another possibility.
I have the same problem in kde from debian testing.
When I play games using a joystick, the monitor decrease luminosity.
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 . 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.
*** 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.
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.
> All these are not reasons against a workaround for sloppily programmed games
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:
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
*** Bug 471047 has been marked as a duplicate of this bug. ***
*** Bug 472465 has been marked as a duplicate of this bug. ***