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
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
