On Mon, 20 Jun 2022 22:50:17 +0200 leoutat...@gmx.fr said: > On 6/20/22 16:21, Carsten Haitzler wrote: > > 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() > > > Precisions: > I connect to spotify web interface with firefox and play music
yeah - i assumed that :) close the spotify tab/web page and blanking probably works again. > When music is played, blanking doesn't work but if i stop music playing, > blanking works. it's the browser insisting on suspending blanking because spotify probably is using some media element. the browser talks to the xserver to suspend blanking as i mentioned. i recently implemented the dbus api above for inhibiting blanking and some apps prefer to use this instead of talking to the xserver to suspend blanking. in the end the source of your problem is the browser asking to suspend blanking (as i mentioned above). if it uses the dbus api i added in git then e will have a submenu as i showed showing who asked to do this and selecting that item removes it from the blanking inhibitor list. the root cause still is the browser asking to suspend blanking because spotify is playing media. > I tested with e16 'xset s 5 +dpms' > Same behaviour... > > -- > Maderios > -- ------------- 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
