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.
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
