Re: [E-devel] enlightenment blanking issue
[email protected] Thu, 18 Aug 2022 17:08:31 +0200
| Newsgroups | gmane.comp.window-managers.enlightenment.devel |
|---|---|
| Message-ID | <[email protected]> |
On 8/13/22 23:05, Carsten Haitzler wrote: > On Sat, 13 Aug 2022 10:58:17 +0200 [email protected] said: > >> On 8/12/22 20:27, Carsten Haitzler wrote: >>> On Fri, 12 Aug 2022 10:02:55 +0100 Carsten Haitzler <[email protected]> >>> said: >>> >>>> On Fri, 12 Aug 2022 10:18:32 +0200 [email protected] said: >>>> >>>>> On 6/20/22 16:23, Carsten Haitzler wrote: >>>>>> On Mon, 20 Jun 2022 15:46: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 >>>>>>> >>>>>>> I use last e and efl git master versions but this function is not >>>>>>> available for me >>>>>> >>>>>> that menu only appears if some application has used the screensaver >>>>>> suspend dbus api that i added recently to e. if no one used the api then >>>>>> that menu will not be there. i do see chromium uses it if it is there. if >>>>>> it's not there 9the dbus api) then browsers seem to use the x screensaver >>>>>> extension to suspend blanking. >>>>>> >>>>> Enlightenment blanking issue appears after watching Twitter video inside >>>>> Firefox, even after closing Twitter window. >>>>> But not for all Twitter videos: sometimes blanking works normally, >>>>> sometimes not... >>>> >>>> if e has disabled blanking itself due to a dbus call like above (to inhibit >>>> blanking) then you will see from 'set q': >>>> >>>> Screen Saver: >>>> prefer blanking: yes allow exposures: yes >>>> timeout: 0 cycle: 0 >>>> >>>> when blanking is on again you will see: >>>> >>>> Screen Saver: >>>> prefer blanking: yes allow exposures: yes >>>> timeout: 1800 cycle: 0 >>>> >>>> or some timeout number that is more than 0. if there is anything in in the >>>> "Blanking Block" submenu of e's main menu - then something has asked to >>>> block blanking (e.g. your web browser). if there is nothing in that menu >>>> then nothing has asked to do this. you should see the xset q output show a >>>> timeout that is more than 0 like above. >>>> >>>> remember that ANY x client can change screensver timeout - not just q. so >>>> this is not a guarantee that e is messing up and not setting this right - >>>> some other client might. steam certainly likes to play with screensaver >>>> timeout. >>>> >>>> if the screensaver timeout is more than 0 and the screen doesn't blank, >>>> then the problem is probably because some client is using the xscreensaver >>>> library to inhibit suspending. clients do this directly to the xserver. >>>> the wm is not involved. the only way to release this screensaver >>>> inhibiting is for the client that requested it to release it OR to >>>> kill/close that client. my guess is your problem lies with firefox. the >>>> best test is - kill/close firefox (actually kill/close all x apps/clients >>>> other than e) and if the screen starts blanking again - then you know your >>>> problem is one of these apps/clients. set your screen blank timeout to >>>> something very short like 0.1 minutes in e and test this. that's how i've >>>> figured out all the blanking problems and that they are all seemingly >>>> coming from web browsers these days and them having video content (n >>>> youtube or even in advertisements and other content you don't realize is a >>>> video). web browsers only recently started inhibiting screen suspending >>>> (in the last year or 2 or so). before that the big culprits were steam and >>>> games and they have their own bugs related to this too. >>> >>> I just tested this with chromium ... and guess what - i saw the same issue >>> as you - no blanking blocks but blanking doesnt work... close chromium - >>> now it begins to work again. you have bug reports to file with the browser >>> developers. they are forcibly holding open some inhibition lock - probably >>> with xscreensaver extension. >>> >> I can't report this bug to firefox team because issue happens only with >> enlightenment... As i said, only e has a blanking issue with firefox. >> Other solution that works with other wm: xset. >> I could use 'xset s 120 +dpms' but it doesnt work with enlightenment > > I'm doing some deep testing right now. chromium is broken,. firefox works fine > actually. chromium itself is broken. proof. using xtrace to trace protocol: > > https://github.com/yuq/xtrace.git > > ./xtrace chromium | grep MIT-SCREEN-SAVER-Request > ... > 000:<:06e0: 8: MIT-SCREEN-SAVER-Request(144,0): QueryVersion major version=1 > minor version=1 > 000:<:06e1: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > 000:<:06e4: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > 000:<:09e9: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > 000:<:0aa3: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=false(0x00) > 000:<:0aa8: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > 000:<:0aaa: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > 000:<:0aad: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=false(0x00) > 000:<:0adf: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > 000:<:0ae1: 8: MIT-SCREEN-SAVER-Request(144,5): Suspend suspend=true(0x01) > > manual page for XScreenSaverSuspend: > > XScreenSaverSuspend temporarily suspends the screensaver and DPMS timer > if suspend is 'True', and restarts the timer if suspend is 'False'. > This function should be used by applications that don't want the > screensaver or DPMS to become activated while they're for example in > the process of playing a media sequence, or are otherwise continuously > presenting visual information to the user while in a non-interactive > state. This function is not intended to be called by an external > screensaver application. > If XScreenSaverSuspend is called multiple times with suspend set to > 'True', it must be called an equal number of times with suspend set to > 'False' in order for the screensaver timer to be restarted. This re‐ > quest has no affect if a client tries to resume the screensaver without > first having suspended it. XScreenSaverSuspend can thus not be used by > one client to resume the screensaver if it's been suspended by another > client. > > the 2nd paragraph specifically: "If XScreenSaverSuspend is called multiple > times with suspend set to 'True', it must be called an equal number of > times with suspend set to 'False' in order for the screensaver timer to be > restarted." > > chromium is provably BROKEN. it suspends multiple times then only un-suspends > once to match, it keeps gaining more suspend counts without releasing them. > chromium does this even though e offers the dbus screensaver inhibit protocol > - it does BOTH. > > firefox works fine for me here. tested it with youtube videos playing. only tab > open is youtube so not complicating things with multiple tabs. chromium is > broken. provably. e is not broken. proof above that at least one browser is > totally broken. > > as i said - check set q. see what screensaver and dpms are set to with xset q - > if they are set to non-zero values then e has set everything right. if they are > set and closing firefox makes it work again... guess what? firefox has a bug. > 'set q' does nothing for me 'set' gives a lot of informations but nothing about blanking For 2 minutes e blanking setting, i get strange 'timeout: 30' xset q Xcreen Saver: prefer blanking: yes allow exposures: yes timeout: 30 cycle: 0 Issue doesn't happen with youtube but only with twitter videos. Other thing, i forgot to say that, sometimes, enlightenment blanking works but not dpms However i can see: xset q DPMS (Energy Star): Standby: 130 Suspend: 131 Off: 132 DPMS is Enabled Monitor is On But DPMS doesn't work... As I said, blanking works with all other windowmanager in same conditions (after twitter videos playing) with : xset s 120 +dpms I should like to use xset but strangely, it doesn't work with enlightenment -- Maderios _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel