Bug 2560

Kris,
can you post a list (or screenshot) of yuor settgins? it may help trying to reproduce the problem.
Also can you check if the kdesktop_lock process is blocked or not when this happens?

(In reply to Michele Calgaro from comment #1)
> Kris,
> can you post a list (or screenshot) of yuor settgins? it may help trying to
> reproduce the problem.
> Also can you check if the kdesktop_lock process is blocked or not when this
> happens?

Which settings would you need? At quick glance, I can't find anything specific to desktop locking in Control Center other than the screen saver settings, and I haven't messed with that since R14.0.0 (basically, two point-versions ago).

How would I tell if kdesktop_lock is blocking? Checking top from a VT, it ranges between 0.5% and 1.5% CPU usage, which seems odd to me since the computer should be completely idle when locked (barring a few applications like my chat clients that occaisionally need to do stuff).

>Which settings would you need? At quick glance, I can't find anything specific 
>to desktop locking in Control Center other than the screen saver settings, and 
>I haven't messed with that since R14.0.0 (basically, two point-versions ago).
I was not saying the problem was caused by the settings.
From TDE control panel -> appearance & settings ->screensaver. This may help reproducing the problem, perhaps.

> How would I tell if kdesktop_lock is blocking?
From CLI, try 
ps aux |grep kdesktop
and post the result here. This will give some indication. I remember in the past we had issues we kdesktop_lock.

Created attachment 2594 [details]
Screensaver Settings

(In reply to Michele Calgaro from comment #3)
> >Which settings would you need? At quick glance, I can't find anything specific 
> >to desktop locking in Control Center other than the screen saver settings, and 
> >I haven't messed with that since R14.0.0 (basically, two point-versions ago).
> I was not saying the problem was caused by the settings.
> From TDE control panel -> appearance & settings ->screensaver. This may help
> reproducing the problem, perhaps.

Attached. Although this bug happens even when I manually lock my desktop, i.e. by going through TMenu -> Lock Session instead of waiting for the screensaver.

> > How would I tell if kdesktop_lock is blocking?
> From CLI, try 
> ps aux |grep kdesktop
> and post the result here. This will give some indication. I remember in the
> past we had issues we kdesktop_lock.

With username intentionally censored:

<username>     15201  0.3  2.3  53424 24376 ?        S    10:45   0:00 /opt/trinity/bin/kdesktop_lock --internal 3580
<username>     15279  0.0  0.1   4792  1972 tty1     S+   10:50   0:00 grep kdesktop_lock

I left my computer without locking it, and came back to find that the auto-locking properly hid desktop contents. However, the screensaver was not active as it should be.

I will try to see whether or not the auto-hiding always works when I let my computer auto-lock itself.

> <username>     15201  0.3  2.3  53424 24376 ?        S    10:45   0:00 
> /opt/trinity/bin/kdesktop_lock --internal 3580
Uhm... everything looks as it should be.
Does it happen all the times or occasionally? And what about after a computer reboot? Just trying to collect as many info as possible because it looks like it may be a difficult one to track down.
Can you also attach gdb to the kdesktop_lock process when you screen is frozen and post a backtrace?

> I will try to see whether or not the auto-hiding always works when I let my 
> computer auto-lock itself.
Good. That may be a clue :-)

(In reply to Michele Calgaro from comment #7)
> > <username>     15201  0.3  2.3  53424 24376 ?        S    10:45   0:00 
> > /opt/trinity/bin/kdesktop_lock --internal 3580
> Uhm... everything looks as it should be.
> Does it happen all the times or occasionally? And what about after a
> computer reboot? Just trying to collect as many info as possible because it
> looks like it may be a difficult one to track down.
> Can you also attach gdb to the kdesktop_lock process when you screen is
> frozen and post a backtrace?

It seems to alternate between working every time, and not work every time -- as in, sometimes it hides the desktop every time I lock, sometimes it happens as described in my original report. There seems to be no rhyme or reason to when it decides to work, and when it doesn't.

Rebooting seems to have no effect.

> > I will try to see whether or not the auto-hiding always works when I let my 
> > computer auto-lock itself.
> Good. That may be a clue :-)

Still need to test this more thoroughly.

Created attachment 2596 [details]
gdb full backtrace from when screen is locked

Kris, thanks for all the feedback.

> Created attachment 2596 [details]
> gdb full backtrace from when screen is locked
This bt was taken when the screen was lock (manually/automatically?) and everything was correctly hidden? 

It would also be useful if you could post a gdb backtrace in the other case, when the screen remains visible. Comparing the two backtrace may reveal a different path of function calls for example ;-) Thanks again

Created attachment 2598 [details]
gdb full backtract (again)

I wasn't really paying attention last time to whether or not the desktop was being hidden. This time, it was *not* being hidden for this backtrace.

Thanks. I may come back with more requests when I look into this problem. It is something important, so we definitely have to look into it for r14.0.3.

Created attachment 2601 [details]
Screenshot of the bug

The taskbar buttons are intentionally censored through KolourPaint. Nothing else is modified.

Such a situation generally occurs to me on TDE 3.5.13.x.

Now I tested on my old notebook (Jessie, 32bit, TDE R14.0.3~pre). I tested the lock by shortcut and also by menu item. And in both cases in order initially display the background image and then the screen was locked.

Note: I do not use the SAK.

(In reply to Slávek Banko from comment #14)
<snip>
> Note: I do not use the SAK.

Hmm, that makes me wander if SAK may affect it. I'll enable SAK to test it.

(In reply to Kristopher from comment #15)
> (In reply to Slávek Banko from comment #14)
> <snip>
> > Note: I do not use the SAK.
> 
> Hmm, that makes me wander if SAK may affect it. I'll enable SAK to test it.

Caution - I have SAK disabled, you have SAK enabled.

However, now I conducted a test on a second test machine with Jessie (64bit). I enable SAK, but again, locking works in all possible ways: Ctrl+Alt+L, item from T-Menu, item from desktop context menu, Ctrl+Alt+Del + button Lock Session.

I also rememebr problems like this before R14.0.0 and Tim and I worked on this for a while. Since R14.0 I have not incurred into this problem and I have not even being able to reproduce it.
I wonder if the key could be that in some special circumstances the combination of "delay saver start after lock" and "Use SAK" causes the screen to get locked but the saver not to be started.
Kris, if you are still experiencing the problem, could you try to run for a few days without the "delay saver start after lock" set and see if there is any difference? Same applies for "Use SAK".

Kris, what is the status of this issue? Still happening on your system?

(In reply to Michele Calgaro from comment #18)
> Kris, what is the status of this issue? Still happening on your system?

As far as I can tell, it still happens on Debian, but is *partially* fixed on CentOS (I see a flurry of notifications from kdbusnotification flicker on then off too quick to read, most likely from my chat program changing my online status).

Thanks Kris.
Are you using R14.0.3 or Slavek's preliminary R14.0.4 packages?
There has been some work done in between, so it is important to know.

(In reply to Michele Calgaro from comment #20)
> Thanks Kris.
> Are you using R14.0.3 or Slavek's preliminary R14.0.4 packages?
> There has been some work done in between, so it is important to know.

I am using 14.0.3. I did not know there were preliminary builds available.

> I am using 14.0.3. I did not know there were preliminary builds available.
Preliminary stable builds is basically a preliminary of next maintenance release (in this case R!4.0.4) maintained by Slavek on his own server. It contains all bug fixes that will be release in R14.0.4, but only available for Debian/Ubuntu distros. See here: https://wiki.trinitydesktop.org/Preliminary_Stable_Builds

Regarding this bug, there are two choices:
1) if you have a chance to test using the preliminary stable builds and you are willing to do so, please go ahead and let us know your feedback
2) otherwise I will move this bug to the R14.0.5 request list and you will be able to test again after R14.0.4 is officially released (which should be reasonable soon).

Is that ok for you?

(In reply to Michele Calgaro from comment #22)
> > I am using 14.0.3. I did not know there were preliminary builds available.
> Preliminary stable builds is basically a preliminary of next maintenance
> release (in this case R!4.0.4) maintained by Slavek on his own server. It
> contains all bug fixes that will be release in R14.0.4, but only available
> for Debian/Ubuntu distros. See here:
> https://wiki.trinitydesktop.org/Preliminary_Stable_Builds
> 
> Regarding this bug, there are two choices:
> 1) if you have a chance to test using the preliminary stable builds and you
> are willing to do so, please go ahead and let us know your feedback
> 2) otherwise I will move this bug to the R14.0.5 request list and you will
> be able to test again after R14.0.4 is officially released (which should be
> reasonable soon).
> 
> Is that ok for you?

Unless the builds are provided for EL6-based distros (e.g. CentOS 6 et al.) or build instructions/scripts provided for LFS/CLFS, I have to go with option number 2.

Then no choice, we have to go for option 2 since preliminary stable builds are only available for Debian/Ubuntu.
Bug moved to R14.0.5 bug list.

Kris, please test again after R14.0.4 is released and let us know whether the problem has been fixed or not.

FYI: I have configured the lock screen (screensaver) to hide content in my office profile since 14.0.3 on debian jessie and I never experienced a problem like the one described here.

I am unable to test this thoroughly due to SAK not working on CentOS (which is what I'm using right now). I commented about this on bug 925.

With "Hide active windows from screen saver" enabled in the screen saver options, everything is properly hidden from the lock screen. With that option disabled, my whole desktop and all active windows are shown behind the lock screen, HOWEVER this was never the case in the past -- this option would allow my windows & desktop to be shown in certain screen savers, but *NOT* behind the lock screen, so I still consider this broken.

As for whether or not this bug is valid with SAK enabled, I have to wait until SAK is fixed before testing.

If I ever get the chance to run TDE on Debian again, I'll test there too.

you mean the random screensaver option can show the desktop?
It has an option not to use screensavers that manipulate the screen.

maybe "hide active windows" option should adjust this option.

Hi Kris,
I am planning to look at this bug again soon. 
Can you update us on whether this is still happening after the update to R14.0.4? That was one pending point we were waiting for in the past (see comment 24)

(In reply to Michele Calgaro from comment #28)
> Hi Kris,
> I am planning to look at this bug again soon. 
> Can you update us on whether this is still happening after the update to
> R14.0.4? That was one pending point we were waiting for in the past (see
> comment 24)

I have not seen the problem occur in awhile, though I don't remember whether it was before or after upgrading to R14.0.4 that it stopped happening. Considering how sporadic it was before, I don't rule out the possibility of it happening again, though it's probably safe to close it for now unless you still want to look into it.

Ok, the work done between R14.0.3 and R14.0.4 was probably the key to fix the problem.
Since you have not seen this problem anymore and you also agree, let's close the bug for the time being.
Should you run into this problem again, please reopen the bug :-)