KScreensaver, KRandR Dropped From KDE Workspaces

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • steveriley
    replied
    Originally posted by Panix View Post
    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.
    I like feeding trolls. Here, have a configuration snack:

    Leave a comment:


  • Panix
    replied
    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.

    Leave a comment:


  • steveriley
    replied
    Originally posted by Ericg View Post
    Hell I've still never had a linux machine boot with the TUX Boot logo >_>
    Get the Liquorix kernel.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by mgraesslin View Post
    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.
    I see.

    Originally posted by mgraesslin View Post
    It means KWin/Wayland not KWin/X11. On KWin/X11 it will still be possible to run non-composited.
    Make sense.

    Thank you.

    Leave a comment:


  • mgraesslin
    replied
    Originally posted by TheBlackCat View Post
    I am confused, isn't that what this says:

    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.

    Originally posted by TheBlackCat View Post
    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.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by mgraesslin View Post
    no and no (random text to make this forum software happy)
    I am confused, isn't that what this says:

    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?

    Leave a comment:


  • mgraesslin
    replied
    Originally posted by TheBlackCat View Post
    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)

    Leave a comment:


  • makomk
    replied
    Originally posted by TheBlackCat View Post
    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.)

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by Rallos Zek View Post
    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.

    Leave a comment:


  • Rallos Zek
    replied
    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:

Working...
X