see summary Reproducible: Always Steps to Reproduce: 1. Pick-up some screensaver (euphoria in my case) in 'display and monitor' settings menu. 2. Wait 'till it starts. 3. Or just try to lock the screen (ctrl+alt+L) 4. Profit. Actual Results: Cursor still remains. Expected Results: It should disappear! This bug lasts from KDE's 4.11.* to 4.13.1 (to which I updated yesterday) version.
According to bug 316459, this should be fixed with KDE Workspaces 4.11.6 (which was shipped the same time as KDE SC 4.12.2). Adding Wolfgang for investigation.
Maybe it will be useful: I use GeForce GTX 550 Ti with 331.38 'recommended' driver. Another man with openSUSE 12.3 x64 and 8600GT on-board says that it works fine to him. Should I try another version of driver?
(In reply to comment #0) > Steps to Reproduce: > 1. Pick-up some screensaver (euphoria in my case) in 'display and monitor' > settings menu. > 2. Wait 'till it starts. > 3. Or just try to lock the screen (ctrl+alt+L) Hm, I can indeed reproduce this with the euphoria screen saver here (openSUSE 13.1, radeon driver). Can you confirm that the cursor disappears with other screen savers? Seems to be a problem specific to euphoria.
(In reply to comment #3) > Hm, I can indeed reproduce this with the euphoria screen saver here > (openSUSE 13.1, radeon driver). > > Can you confirm that the cursor disappears with other screen savers? > Seems to be a problem specific to euphoria. Just played out with other screens and cursor disappeared. It seems that cursor remains only with 'OpenGL Screen Savers' group. Tried out to switch compositing type from OpenGL 3.1, which I currently use, to 2.0, 1.2 and even XRender, but with no success.
(In reply to comment #4) > Just played out with other screens and cursor disappeared. Thanks for confirming! > It seems that cursor remains only with 'OpenGL Screen Savers' group. No, not with all of them (with most of them I cannot reproduce). And also with some _not_ in the "OpenGL Screen Savers" group. For the record, I tried _all_ screen savers now and can reproduce it with the following ones only: ktux, julia, kpendulum.kss, krotation.kss, kflux.kss, kfountain.kss, kgravity.kss, ksolarwinds.kss. (the last 4 look very similar anyway, so I suppose they share most of the code) And even with those, the mouse cursor disappears for a short while, and is unblanked again when the screen saver appears (at least that's how it looks here). So something in those particular screen savers seems to trigger the unblanking of the mouse cursor. I will try to investigate further.
(In reply to comment #5) > (In reply to comment #4) > > It seems that cursor remains only with 'OpenGL Screen Savers' group. > No, not with all of them (with most of them I cannot reproduce). And also > with some _not_ in the "OpenGL Screen Savers" group. On second look all the other screen savers I have in the "Open GL Screen Savers" group, and julia, are from the xscreensavers package, not KDE. And I somehow missed kwave.kss (and euphoria.kss, but that was mentioned already anyway). So to sum it up: _all_ of KDE's OpenGL screen savers plus ktux unblank the mouse pointer.
Sorry for the delay. Apparently the QGLWidget that is used by KDE's OpenGL screensavers causes this. I found a workaround by setting a blank override cursor in libkscreensavers startup code, see https://git.reviewboard.kde.org/r/119663/ This works now with _all_ screensavers I have on my system, also those mentioned in comment #5 and #6, and I didn't notice any unwanted side-effect. One exception is julia though: this one still shows a mouse pointer. The reason is that it explicitely sets one on purpose, in its demo mode you can select the starting point to be used by clicking on the position on the screen. This is useless when used as screensaver of course, because it will disappear as soon as you move the mouse or click, but it sets it anyway. Nothing much we can do there from KDE's side though I suppose.
The screen locker architecture changed with Plasma 5. The classic screen savers are no longer supported. The 4.x series won't see any further feature development, so this bug report won't be implemented as it doesn't apply to our current version any more. I want to thank you for your bug report and for helping improving the quality of our software and I'm sorry that we were not able to provide a fix before we retired the affected component.