Re: [E-devel] enlightenment blanking issue

On 6/20/22 16:21, Carsten Haitzler wrote:
> On Mon, 20 Jun 2022 14:01:44 +0200 [email protected] said:
>
>> On 6/13/22 11:42, Carsten Haitzler wrote:
>>> On Sun, 12 Jun 2022 17:13:15 +0200 [email protected] said:
>>>
>>>> On 6/10/22 10:22, Carsten Haitzler wrote:
>>>>> On Fri, 10 Jun 2022 08:45:44 +0200 [email protected] said:
>>>>>
>>>>>> On 6/9/22 23:53, Carsten Haitzler wrote:
>>>>>>> On Thu, 9 Jun 2022 22:41:08 +0200 [email protected] said:
>>>>>>>
>>>>>>>> On 6/9/22 12:16, Carsten Haitzler wrote:
>>>>>>>>> On Thu, 9 Jun 2022 10:41:25 +0200 [email protected] said:
>>>>>>>>>
>>>>>>>>>> On 6/9/22 09:55, Carsten Haitzler wrote:
>>>>>>>>>>> On Wed, 8 Jun 2022 19:50:27 +0200 [email protected] said:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/8/22 19:17, Carsten Haitzler wrote:
>>>>>>>>>>>>> On Wed, 8 Jun 2022 15:39:17 +0200 [email protected] said:
>>>>>>>>>>>>>
>>>>>>>>>>>>> actually wait - is this a laptop? or using ddc? dimming timeout
>>>>>>>>>>>>> set? then the 30 sec may be the dimming timeout. e will run a
>>>>>>>>>>>>> timer after that that then totally blanks the screen. this timer
>>>>>>>>>>>>> is cancelled when the screensaver is cancelled (when the screen
>>>>>>>>>>>>> dims the screen is basically in screensaver mode)
>>>>>>>>>>>> It's just a laptop
>>>>>>>>>>>
>>>>>>>>>>> ok - that explains the 30 sec then - that's the dimming timeout.
>>>>>>>>>>> does the screen dim automatically after 30 sec of idle input?
>>>>>>>>>> No, screen doesn't dim after 30 sec of idle input.
>>>>>>>>>> Screen blanks after 2 minutes (according to settings), but sometimes,
>>>>>>>>>> maybe once a day, it doesn't blank at all. If i restart e, it blanks
>>>>>>>>>> normally.
>>>>>>>>>
>>>>>>>>> that's odd. screen should dim. you have backlight support? does it
>>>>>>>>> work manually with the gadget?
>>>>>>>>
>>>>>>>> Yes that's odd...I have backlight support and gadget in shelf. See
>>>>>>>> settings in  attached file
>>>>>>>
>>>>>>> so backlight controls work? you can manually change brightness? does the
>>>>>>> backlight dim after 30 sec of no input if you leave things idle? btw
>>>>>>> your normal backlight is 5% .. that's really odd.... it should be
>>>>>>> HIGHER than the dim level of 30%...
>>>>>>
>>>>>> I set backlight higher than dim level, and dim works now.
>>>>>> Maybe this explains why, sometimes, blanking doesn't work, but it
>>>>>> happens randomly...
>>>>>
>>>>> well now you at least have saner backlight settings (these are not
>>>>> defaults
>>>>> - the defaults are 100% and 30% for normal and dim levels). the first
>>>>> thing you should look for is if the screen dims after 30 sec od idle - if
>>>>> it does then screensaver is then activating. e uses the x screensaver
>>>>> notify event fromto dim the backlight (and screensaver deactivate to
>>>>> un-dim (go back to bright)). once idle e runs a timer that then waits for
>>>>> "the rest of the time" until the screen needs to go blank. so if dim
>>>>> timeout is 30 sec, and blanking time is 2 min, then e runs a timer for
>>>>> 1.5min. when this timer is hit then e will "fade to blank" and fade out
>>>>> the rest of the backlight to off too. x's dpms timeouts are set to expire
>>>>> a little bit after this "fade to black" (about 10 seconds after as you
>>>>> can see in xset's dpms settings) so the screen will completely power off
>>>>> then (but will appear black by this point).
>>>>>
>>>>> so the first thing to do is to notice... is the dimming happening? if it
>>>>> is not then there is a problem earlier on with screensaver notify events
>>>>> not happening. that means either the x screensaver has been suspended in
>>>>> some way (it was totally turned off - some apps go mess with screensaver
>>>>> settings - xset q will tell you if screensaver is on or off and the
>>>>> timeout) and some apps may take a screensaver "block" from x and ask it to
>>>>> temporarily suspend the screensaver. chromium and chrome based browsers
>>>>> will do this when playing videos - sometimes ads on a web page can cause
>>>>> this if they play videos. youtube does it... the best way to eliminate
>>>>> this is to close your browser and see if the problem continues. steam
>>>>> will also kill off blanking even if it just runs as a service in the
>>>>> background and no game is running. this s an ongoing issue with sdl/steam
>>>>> actively trying to keep the screen alive. in git i just added support for
>>>>> a dbus service used by some other wm's and de's that does the same as the
>>>>> x screensaver suspend/block feature - but it's asking whoever runs the
>>>>> dbus service to suspend blanking/screensaver - in this case e will
>>>>> advertise this service and it gets the requests. now e knows who asked to
>>>>> block the screensaver and will list who asked in a submenu of the main e
>>>>> menu under "blanking block". some apps will prefer to use this dbus
>>>>> service instead of the x screensaver suspend extension feature, thus it
>>>>> may help identify the problem too. you can remove that blank clock by
>>>>> just selecting it in the menu and e will remove that blocker. like here:
>>>>>
>>>>> http://www.enlightenment.org/ss/e-62a2fefb1df8c2.44000455.png
>>>>>
>>>>> it's very basic but enough to debug it. i'll make it prettier in future
>>>>> with eventually a proper dialog or some gadget with popups or some shelf
>>>>> indicators etc.
>>>>
>>>> I see DPMS blanking (but blanking works) doesn't work when other X
>>>> session is launched from other user account in the same time.
>>>> This issue doesn't happen when using other wm like xfce4, fluxbox...
>>>
>>> even without screensaver active, dpms should still kick in. e.g.:
>>>
>>> Screen Saver:
>>>     prefer blanking:  yes    allow exposures:  yes
>>>     timeout:  0    cycle:  0
>>> ...
>>> DPMS (Energy Star):
>>>     Standby: 46    Suspend: 47    Off: 48
>>>     DPMS is Enabled
>>>     Monitor is On
>>>
>>> a timeout of 0 on screensaver disables it - but with dpms still set to a
>>> value ... dpms now turns on instantly at 46 seconds. you won't see e nicely
>>> fade to black because it won't get a screensaver notify event .. but dpms
>>> still happens. dpms is controlled by the xserver. when the timeout is hit
>>> then dpms will automatically just happen (it does here). the screen turns
>>> off. if this is not happening then the xserver is choosing not to make it
>>> happen. either the xserver (and/or driver) has a bug OR more likely some
>>> process is suspending screensaver/blanking entirely - as i mentioned. there
>>> is an extension to do that. xset q will show if something has manually
>>> messed with dpms/screen saver settings but you can't see who/what requested
>>> a suspend. something that is an x client has asked to suspend. check what
>>> apps you are running that are x clients. something has done this - what - i
>>> don't know. check all your processes in details and kill off anything that
>>> is not from e or efl ... i guess the problem will go away then. then it's a
>>> matter of eliminating the client that causes it. as i mentioned - there are
>>> some clients that do this like browsers. steam is worse - it plays with x
>>> screesnaver/dpms settings directly AND it has bugs and gets it wrong. i
>>> know rage will auto-suspend screensaver if in fullscreen mode. it does this
>>> assuming when in fullscreen you want a "media experience". you may have
>>> other apps around that do this. you could write a LD_PRELOAD that wraps
>>> XScreenSaverSuspend() from libXss and then log all processes calling this
>>> to suspend or unsuspend and then find out if someone is doing it... but as
>>> i said - the other option is a bug... but dpms is entirely done by the
>>> xserver internally. e sets the timeouts to go off after screensaver and so
>>> thats why they are set to the timeouts you see - if dpms is not working
>>> even with these timeouts set and dpms is enabled (xset q) then ... its the
>>> xserver not doing this.
>>>
>>> there is only one other option i can think of ... there is some input coming
>>> in. mouse, touchpad, keyboard ... something .. so input is going into x to
>>> keep it alive. i don't remember if the x test extension will have events
>>> reset the idle timeout. this would be very very very odd if something was
>>> doing this... but it's possible and as i said - i am not sure if xtest
>>> extension events reset idle timeout. i'd have to test.
>>>
>>
>> I see enlightenment blanking issue happens when spotify web page is
>> opened in firefox. There's no option in firefox, like in vlc or smplayer
>> to choose wether allow blanking or no blanking. I think enlightenment
>> has too many  rights, only the user should be able to choose.
>
> this is not an enlightenment thing. it's the xserver. any x client can ask the
> xserver to suspend blanking. thgere is no permissioning or way to block it.
> close firefox (or spotify) and i think it'll start blanking again. i have
> noticed if you have some videos playing browsers will suspend blanking (even
> video oadvertisments can do it). the browsers do this DIRECTLY with the xserver.
> e has no choice in this. they talk to the xserver, not e. they use the x
> screensaver extension and ask it to suspend blanking. e is not told. e has no
> choice. read up on the x screensaver extension and the suspend api call i
> mentioned: XScreenSaverSuspend()
>
Precisions:
I connect to spotify web interface with firefox and play music
When music is played, blanking doesn't work but if i stop music playing,
blanking works.
I tested with e16 'xset s 5 +dpms'
Same behaviour...

--
Maderios