Re: [e-users] E 0.25.3 locking resets dpms to Standby: 11 Suspend: 12 Off: 13

in my config, I can see some values close to the ones I may get after 
suspend, in
Config>Screen>Blanking
and
Config>Screen>Backlight

Those config are claimed to be ignored, because the values are assigned 
to fields that are disabled, but, maybe some glitch goes to read and use 
those values dispite the unticked box ...

I should not have any interfeerence with other tools. 15y ago I used to 
mix E with some Gnome and KDE components; but today, my current conf is 
clean from this kind of mix. I do use DBus, but no funky component 
should be able to mess E via DBus. 2 years I have this funny glitch 
after suspend, and never could correlate it with anything in particular. 
Especially in my case, it does not occur frequently or reliably; it's 
"some times".

The only thing that could be a lead, may be the fact I unplug the power 
of my laptop during the suspend to ram; that was the best lead I had: go 
sleep wired to live, unplug, and wakeup without PSU. That increased the 
probability to a good 30%. I am using Debian, and I probably have the 
package LaptopTools. Maybe some sysconf catches power-unplug and tries 
to overwrite X timeouts, and, for some reason, E does not catch them ... 
(race concurencies).

Just thoughts.

The glitch is very ennoying, but, the fix was easy. So even if this 
technically renders the system completely unusable ... I don't class it 
as critical, cause the fix is just trivial. So, WA it, and forget it.

By over scripting / rewraping the sleep command, it could be possible to 
dump the system (list all process, check APM states) before sleep, just 
after, and track which process or event could correlate with a DPMS change.

Linux is becoming a very complex system, and I don't have time anymore 
to track the root cause of every single issue. And it may not be E ...

But if you do:
- rewrap the sleep commands
- check if the values after sleep match the E config that should be ignored
- try to correlate with any event that could be catched by laptop-tools 
(sleep by keyboard shortcut to BIOS, sleep by LID, PSU disconnexion, 
temperatures ... )


On 03/10/2023 23:22, Marc MERLIN wrote:
> On Tue, Oct 03, 2023 at 08:55:26PM +0200, Benoît-Pierre Demaine wrote:
>> As said earlier, I have a similar issue; my fix was this in .xinitrc . Since
>> that bit of code, I never had the issue again. Issue happens to me when I
>> resume from suspend to ram (not each time, one out of 10).
>   
> Thanks. I can go into workarounds like this one indeed, but kind of was
> hoping the root cause would be identified and fixed in E, or somehow a
> setting I'm missing.
>   


-- 
  >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would'nt have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)



_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users