Page MenuHomePhabricator

Lock on suspend actually locks on resume, letting screen briefly viewable before lock
Closed, ResolvedPublic

Description

I'm not sure when that behavior started, nor if it is E fault, but this what is happening.
I'm using "lock screen on suspend". I also have "suspend when lid is closed".
Now, when I'm closing my laptop's lid, I correclty have it suspends.
But when I open the lid, I see my screen unlocked, and a moment after (less than a second), the screen is locked. It was not the case in the past, but I don't have ideas of when/what caused the change.

Version info:
% pacman -Q | grep efl
efl-git 1.20.99.55185.g6e30535a3c-1
% pacman -Q | grep enli
enlightenment-git 0.21.99.23005.gcc5eec5cc-1

Is there any log/information I can send you to help understand what is causing that behaviour?

Thanks,

fanf42 created this task.Sep 3 2017, 5:57 AM
zmike assigned this task to raster.Sep 13 2017, 9:07 AM

Same issue here with 0.22.4-2 on Debian Buster. For debugging, I have set a custom screenlock command (i3lock) and the screen is still visible for a few seconds. Then I have disabled 'Lock on Suspend' in enlightenment completely and added a systemd service with Before=sleep.target. Starting 'systemd suspend' from the console works fine and the screen is locked accordingly using i3lock which I have defined in the systemd service. Suspending from enlightenment still behaves the same and the screen is visible for a few seconds. This is the point which is difficult for me to understand, as it seems that enlightenment is also using a combination of acpid and systemd calls as defined in sysactions.conf. So why it behaves different than 'systemd suspend'?

can you try this. run this on your screen then do the above close/open lid:

elementary_test -to animation

when you see the screen - is that window there animating or is it a still image? or is it even there at all? also systemd or not, but code-wise desklock is shown before suspend:

if (e_config->desklock_on_suspend)
// XXX: this desklock - ensure its instant
  e_desklock_show(EINA_TRUE);
_e_sys_begin_time = ecore_time_get();
if (e_config->suspend_connected_standby == 0)
  {
     if (systemd_works)
       _e_sys_systemd_suspend();
     else
       {
          _e_sys_susp_hib_check();
          e_system_send("power-suspend", NULL);
       }
     ret = 1;
  }

now of course there could be a race condition where logically we've turned on the desklock but e never manages to render a single frame before the system actually suspends...

BUT... the standard comp theme has already rendered a fade to black so the framebuffer should all have been filled with black already ... unless you changed this. also perhaps you are not using e to suspend? if you are using some acpid thing to suspend then e has no idea a suspend is taking place - perhaps the only thing it knows is that on wakeup maybe the screen idle times out and blanks and maybe you have suspend on blank? but the face you can see your screen at all hen its suspending hints to me either you modified the theme so this fade to black isn't happening somehow which would cover up race conditions like the above as logically the screen and display were locked already but just no frame yet pumped to the output of a "rendered lock screen" but as it's black - that's all ok. the very next frame right after this when it wakes up will then begin showing the lock screen. this will.. also be black as it will have to start the fade in ... ?

now for custom lock commands... that is a race condition e can do nothing about. the lock tool may take an arbitrary amount of time to start and e has no idea how long. it could take 0.1sec, 0.5sec, 5sec ... how long should e wait? don't use external lock commands. i actually plan on removing that feature partly for these reasons. it adds complexity to the code and adds unsolvable race conditions. the above "last frame didnt render" could be solved by me adding a very short delay before issuing a suspend to systemd or the e_system service to allow for at least 1 frame to render ... that's easy enough. an external command is unknown as to how long it takes. a built in lock is known as it's always there and ready to go.

ProhtMeyhet triaged this task as Normal priority.Oct 8 2020, 9:40 AM
raster closed this task as Resolved.Oct 9 2020, 4:25 AM

not sure this is going anywhere. external lock commands are a "asking for there to be a bug and race condition". so going to remove that anyway. my other queries are to do with perhaps literally frames just not being rendered. he fade to black should hide that... so why would they see junk on the screen .. unless this is some other buffer that the driver is displaying in the swap chain - not what e rendered. some older buffer from long ago and this is displayed until enough of e and xorg wake up to render things again... this would then be a bug in the kernel and/or xorg stack. shall resolve the i3 lock issue with not having an external lock command.