If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
KDE is shit. I can't even the time because the designers of this pathetic DE decided it would be smart to have 'white' text on a grey background. The widgets thing is crap as well.
outdated information :-) We had to change the approach as we found a security flaw in case KWin was crashing. The locking is as already mentioned performed in ksmserver.
Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the …
"We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor."
outdated information :-) We had to change the approach as we found a security flaw in case KWin was crashing. The locking is as already mentioned performed in ksmserver.
One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, …
"Given that we have to enforce compositing in future, it?s good to know that all backends work."
Would it be possible to clarify exactly what is going on?
It means KWin/Wayland not KWin/X11. On KWin/X11 it will still be possible to run non-composited.
Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the …
"We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor."
One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, …
"Given that we have to enforce compositing in future, it’s good to know that all backends work."
Would it be possible to clarify exactly what is going on?
If my understanding is correct, kwin has moved the lockscreen into the compositor when compositing is enabled even in the KDE 4 series. (...) I think for kwin for frameworks 5 compositing will be enforced
no and no (random text to make this forum software happy)
Xscreensaver is inherently insecure. If my understanding is correct, kwin has moved the lockscreen into the compositor when compositing is enabled even in the KDE 4 series. This is much more secure. The xscreensaver implementation was deprecated and only used when there is no way to use compositing. I think for kwin for frameworks 5 compositing will be enforced, so there is no longer any reason to keep using the insecure Xscreensaver.
Unless they've changed it, in the KDE 4 series locking the screen is handled by ksmserver with minor optional assistance from KWin's compositor - this is secure enough under X since it aggressively reacquires its lock and if it dies the X session is terminated. Then the screensaver (if any) runs as a seperate process that's composited by KWin and even if it gets killed somehow the screen still remains locked. KDE hasn't had the security problem mentioned in the article for a long time, and the only recent security issue I'm aware of was actually in the Plasma-based replacement that Xscreensaver is being removed in favour of. (Also, moving screen locking to the compositor is not necessarily safe under X.)
Since Wayland will not be mainstream for another 2 to 5 years why get rid of the X Screensaver code? Xorg will still be on the desktop for the next 10 years. Will there be a way to control X screensavers under KDE? I loved the KDE frontend/control of XScreensaver it was the best I used.
So please tell how will one use KDE 5 with Xscreensaver?
Xscreensaver is inherently insecure. If my understanding is correct, kwin has moved the lockscreen into the compositor when compositing is enabled even in the KDE 4 series. This is much more secure. The xscreensaver implementation was deprecated and only used when there is no way to use compositing. I think for kwin for frameworks 5 compositing will be enforced, so there is no longer any reason to keep using the insecure Xscreensaver.
Since Wayland will not be mainstream for another 2 to 5 years why get rid of the X Screensaver code? Xorg will still be on the desktop for the next 10 years. Will there be a way to control X screensavers under KDE? I loved the KDE frontend/control of XScreensaver it was the best I used.
So please tell how will one use KDE 5 with Xscreensaver?
Leave a comment: