Version: unspecified OS: Linux After some testing and leaving my Wetab running, I have discovered that sometimes the screenlocker is black. You can still unlocking it by moving an imaginary locker up. This is similar to another screen locker issue; you get a rectangle with the locker on and the rest is transparent - you can see whatever is below; the peek area, a window, etc. Tested on 2012-01-10-09-09-basyskom-plasma-active-devel-meego-usb-live.iso Tested on. Reproducible: Sometimes Steps to Reproduce: 1. Use PA for some time 2. Leave it running 3. Observe the display Expected Results: The screenlocker shouldn't turn black.
Clarification: I left my Wetab running for some minutes and whenever it happened, it was on a subsequent boot (not on first boot).
Sometimes the screenlocker is completely transparent. You can see the windows, the top bar, everything. At some point, the middle part of the screenlocker appears (with the locker) while the rest continues to be transparent. Tested on 2012-01-13-11-27-basyskom-plasma-active-devel-meego-usb-live.iso
I've been able to reproduce it on 2012-01-20-19-26-basyskom-plasma-active-devel-meego-usb-live.iso. This is what ~/.xsession-errors says file:///usr/share/kde4/apps/kscreenlocker/lockscreen-active.qml:145:5: QML Image: Cannot anchor to a null item.
Has anyone been able to reproduce this problem? Some problems with kwin's opengl acceleration has been fixed in the last week, so this problem may have been fixed as well.
here didn't happen since a while, let's still keep an eye on it (i suspect different behavior between xrender/opengl and different behavior between meego/mer
Yesterday I saw the transparent problem happening sometimes in the lastest testing image (2012-04-10-10-37-basyskom-plasma-active-testing-meego-usb-live.iso) installed in VirtualBox. The interesting part is that compositing is now working with VirtualBox.
pot. either driver bug or utilization of MSAA and no glClearColor in the screensaver hack - see bug #263974 There's been some talk on screensavers, Martin actually wanted to move it to kwin, but there've been opposing statements. My personally favorite location would actually be kdm and invoke a kdm greeter as security layer. See http://lists.kde.org/?t=131818348300001&r=1&w=2 for the k-c-d thread and -self promoting- http://lists.kde.org/?l=kde-core-devel&m=131853544901721&w=2 for ossis talk on kdm usage
(In reply to comment #7) > pot. either driver bug or utilization of MSAA and no glClearColor in the > screensaver hack - see bug #263974 Ok, I do not understand much about OpenGL programming. Where the hack you are talking about is located? In kwin or in the screensavers? > There's been some talk on screensavers, Martin actually wanted to move it to > kwin, but there've been opposing statements. My personally favorite location > would actually be kdm and invoke a kdm greeter as security layer. > > See http://lists.kde.org/?t=131818348300001&r=1&w=2 for the k-c-d thread and > -self promoting- > http://lists.kde.org/?l=kde-core-devel&m=131853544901721&w=2 for ossis talk > on kdm usage I followed some of those discussions. Well, it seems there are people interested in using light-dm instead of kdm, how that would affect moving screenlocker to kdm? What about this approach to move it to ksmserver? If the locker crashes the user is just logged off, there is less security risk, just the possible data loss is the problem :-) Specialy if you use one of those crazy optimizations filesystems use to make them look good in benchmarks.
(In reply to comment #8) > Ok, I do not understand much about OpenGL programming. Where the hack you > are talking about is located? In kwin or in the screensavers? *ggg* xscreensaver "modules" (eg. glmatrix) are traditionally called "xscreensaver hacks" - sorry for confusion :-) What basically happens (for that bug) is that the GL code in the screensaver *assumes* there's some black background (w/o actually causing it) what is no longer necessarily true for a composited desktop and esp. MSAA (multiscreen sampling for antialiasing) > I followed some of those discussions. Well, it seems there are people > interested in using light-dm instead of kdm, how that would affect moving > screenlocker to kdm? you could not (easily) invoke the greeter as actual lock layer (and fancy animations as optional, well... fancy animations) > What about this approach to move it to ksmserver? similar good protection against ctrl+alt+* but the (ksmserver) code is (i think) more complex (at least doing a lot of unrelated stuff) and doesn't actually handle logging in atm (think of other PAM stuff, eg. logging in by touching some image points etc.) - in terms of security the actual login handler seemed the far more natural location to me (but of course spellbinds you to that DM)
> (In reply to comment #7) >> pot. either driver bug or utilization of MSAA and no glClearColor in >> the >> screensaver hack - see bug #263974 > > Ok, I do not understand much about OpenGL programming. Where the hack > you are > talking about is located? In kwin or in the screensavers? The hack is no longer used in the screenlocker branch used in PA. Which reminds me: I should finish it for 4.9
This issue had vanished on Meego a while ago, but it has returned on Mer.
Can anybody still reproduce this problem? I haven't seen it in a while, so it's probably fixed in Mer by now.
Since nobody has reportedly been able to reproduce the bug lately, I'll mark it as fixed.