On Mon, 20 Jun 2022 14:01:44 +0200 leoutat...@gmx.fr said: > On 6/13/22 11:42, Carsten Haitzler wrote: > > On Sun, 12 Jun 2022 17:13:15 +0200 leoutat...@gmx.fr said: > > > >> On 6/10/22 10:22, Carsten Haitzler wrote: > >>> On Fri, 10 Jun 2022 08:45:44 +0200 leoutat...@gmx.fr said: > >>> > >>>> On 6/9/22 23:53, Carsten Haitzler wrote: > >>>>> On Thu, 9 Jun 2022 22:41:08 +0200 leoutat...@gmx.fr said: > >>>>> > >>>>>> On 6/9/22 12:16, Carsten Haitzler wrote: > >>>>>>> On Thu, 9 Jun 2022 10:41:25 +0200 leoutat...@gmx.fr said: > >>>>>>> > >>>>>>>> On 6/9/22 09:55, Carsten Haitzler wrote: > >>>>>>>>> On Wed, 8 Jun 2022 19:50:27 +0200 leoutat...@gmx.fr said: > >>>>>>>>> > >>>>>>>>>> On 6/8/22 19:17, Carsten Haitzler wrote: > >>>>>>>>>>> On Wed, 8 Jun 2022 15:39:17 +0200 leoutat...@gmx.fr 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() -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
