! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
XFCE doesn't allow inhibiting screensaver
Status:
RESOLVED: FIXED
Product:
Xfce4-power-manager
Component:
General

Comments

Description Konstantin Svist 2014-08-16 18:23:46 CEST
According to VLC devs:
https://trac.videolan.org/vlc/ticket/9718#comment:19

In older versions, VLC used to be able to inhibit screensaver while a movie is playing. Now they're claiming XFCE doesn't support this feature anymore...
Comment 1 Eric Koegel editbugs 2014-08-26 19:03:24 CEST
This belongs in xfpm, moving. I think it might be a good idea to add a heartbeat to stop xscreensaver in presentation mode for the people stuck using xscreensaver.
Comment 2 Eric Koegel editbugs 2014-09-01 17:22:25 CEST
*** Bug 11111 has been marked as a duplicate of this bug. ***
Comment 3 Eric Koegel editbugs 2014-09-01 19:25:00 CEST
Created attachment 5622 
Use XScreenSaverSuspend and XTestFakeKeyEvent

Can you try this patch out? It tries a couple different ways to get the screensaver to stop running when xfce4-power-manager is placed into presentation mode or if a program requests an inhibit lock.
Comment 4 Marcel Dopita 2014-09-06 00:50:53 CEST
Created attachment 5630 
debug log

To my surprise I was still using 1.2.0 on Arch Linux. I tried 1.3.2 but it was the same so I tried your patches. I set the lowest timeout to 2 minutes to avoid issues if some timers are one minute long but I still experience screen turning off itself after some time when running VLC (fullscreen or windowed).
Weird thing is that first the screen with video freezes for a few seconds when the screensaver timeout is hit. But I don't use any screensaver (my setup for various testing looks like this https://github.com/moneytoo/myarch/blob/master/arch.sh).
Comment 5 Marcel Dopita 2014-09-06 00:51:14 CEST
Created attachment 5631 
timeouts
Comment 6 Olivier Duchateau 2015-02-14 17:13:01 CET
(In reply to Eric Koegel from comment #3)
> Created attachment 5622 
> Use XScreenSaverSuspend and XTestFakeKeyEvent
> 
> Can you try this patch out? It tries a couple different ways to get the
> screensaver to stop running when xfce4-power-manager is placed into
> presentation mode or if a program requests an inhibit lock.

Tested, and everything is fine.

Note: I created manually the /xfce4-power-manager/presentation-mode property, because panel plugin crashes (bug #11101), so I could not have access to this feature.
Comment 7 Steve Dodier-Lazaro editbugs 2015-02-15 03:32:23 CET
Eric,

Do you need more testing before you decide to push this patch? If so, can you clarify that we should:

- set presentation mode, and a timeout for the screen to be shutdown
- do nothing until the timeout is hit
- notice that the presentation mode prevents the screen from shutting down

- set normal mode, and a timeout...
- do nothing...
- notice the screen turns off
Comment 8 Eric Koegel editbugs 2015-06-11 17:47:42 CEST
Rebased the patch on git master and applied.

commit a805071464ecf0fee27d59de15620b035d855eb0
Author: Eric Koegel <eric.koegel@gmail.com>
Date:   Thu Jun 11 18:34:27 2015 +0300

    Use XScreenSaverSuspend and XTestFakeKeyEvent (Bug 11083)
    
    Use the XScreenSaverSuspend and XTestFakeKeyEvent calls to suspend
    the screensaver when we're in presentation mode or something has
    requested an inhibit lock. This tries several different ways of
    getting the screensaver to stop running since there's no standard
    way listed on: http://www.freedesktop.org/wiki/Specifications/
http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=a805071464ecf0fee27d59de15620b035d855eb0

I'm leaving this report open since one person reported it not working. xfce4-power-manager --debug will provide output at what xfpm is doing with inhibiting the screensaver.
Comment 9 timo.teras 2015-10-26 16:01:38 CET
(In reply to Eric Koegel from comment #8)
> Rebased the patch on git master and applied.
> 
> commit a805071464ecf0fee27d59de15620b035d855eb0
> Author: Eric Koegel <eric.koegel@gmail.com>
> Date:   Thu Jun 11 18:34:27 2015 +0300
> 
>     Use XScreenSaverSuspend and XTestFakeKeyEvent (Bug 11083)
>     
>     Use the XScreenSaverSuspend and XTestFakeKeyEvent calls to suspend
>     the screensaver when we're in presentation mode or something has
>     requested an inhibit lock. This tries several different ways of
>     getting the screensaver to stop running since there's no standard
>     way listed on: http://www.freedesktop.org/wiki/Specifications/
> http://git.xfce.org/xfce/xfce4-power-manager/commit/
> ?id=a805071464ecf0fee27d59de15620b035d855eb0

Please revert XTestFakeKeyEvent usage. It breaks certain things. For example:
 - xfce4-terminal resets back to the bottom of the terminal (when scrolled up) and this event is received
 - firefox e.g. when playing in youtube fullscreen pops up the seek controls everytime this event is received

Or should the keycode 255 blocked somewhere somehow? But currently it breaks several things for me.
Comment 10 Stephane Chazelas 2016-01-06 20:34:19 CET
(In reply to timo.teras from comment #9)
> Please revert XTestFakeKeyEvent usage. It breaks certain things. For example:
>  - xfce4-terminal resets back to the bottom of the terminal (when scrolled
> up) and this event is received
>  - firefox e.g. when playing in youtube fullscreen pops up the seek controls
> everytime this event is received

Other person affected there: http://unix.stackexchange.com/questions/253184/my-keyboard-generates-spurious-events

gnome-terminal and xterm do scroll back to the bottom upon that 255 keypress. They don't upon Ctrl though (alone unlikely to be mapped by a window manager).
Comment 11 Eric Koegel editbugs 2016-02-15 18:19:26 CET
Created attachment 6611 
Replace XTestFakeKeyEvent with inhibit/heartbeat

So this is what I've been looking at. Using any real key events can cause issues with an app (i.e., using ctrl might mess up the user playing a game). So if we can't use the fake key we'll have to do something else.

Instead of using XTestFakeKeyEvent, attempt to contact whatever
screensaver is running via its dbus interface. Failing that,
a /xfce4-power-manager/heartbeat-command xfconf property will be
executed every 30 seconds to keep the screensaver from
launching. This way xscreensaver, xdg-screensaver, caffeine or
a similar tool can be used.

It checks for the org.freedesktop.ScreenSaver dbus service, as well as the same for cinnamon, mate, and gnome.
Comment 12 ToZ editbugs 2016-02-15 22:16:09 CET
Just tested this patch with xscreensaver and the xfconf heartbeat-command set to "xscreensaver-command -deactivate" and it works. Also didn't notice the firefox video controls popping up.
Comment 13 Eric Koegel editbugs 2016-02-16 17:27:58 CET
Thanks ToZ! Pushed to master in:
commit d0ea6d9202b0433f562ac30ad53d1f9480f51895
Author: Eric Koegel <eric.koegel@gmail.com>
Date:   Mon Feb 15 20:11:12 2016 +0300

    Replace XTestFakeKeyEvent with inhibit/heartbeat (Bug #11083)
    
    Instead of using XTestFakeKeyEvent, attempt to contact whatever
    screensaver is running via its dbus interface. Failing that,
    a /xfce4-power-manager/heartbeat-command xfconf property will be
    executed every 30 seconds to keep the screensaver from
    launching. This way xscreensaver, xdg-screensaver, caffeine or
    a similar tool can be used.
http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=d0ea6d9202b0433f562ac30ad53d1f9480f51895
Comment 14 Eric Koegel editbugs 2016-05-24 14:07:36 CEST
This is available in 1.6.0. Marked resolved.

Bug #11083

Reported by:
Konstantin Svist
Reported on: 2014-08-16
Last modified on: 2016-05-24
Duplicates (1):

People

Assignee:
Eric Koegel
CC List:
13 users

Version

Version:
Unspecified

Attachments

Use XScreenSaverSuspend and XTestFakeKeyEvent (7.97 KB, patch)
2014-09-01 19:25 CEST , Eric Koegel
no flags
debug log (17.26 KB, text/plain)
2014-09-06 00:50 CEST , Marcel Dopita
no flags
timeouts (1.11 KB, text/plain)
2014-09-06 00:51 CEST , Marcel Dopita
no flags
Replace XTestFakeKeyEvent with inhibit/heartbeat (9.55 KB, patch)
2016-02-15 18:19 CET , Eric Koegel
no flags

Additional information