Announcement

Collapse
No announcement yet.

KScreensaver, KRandR Dropped From KDE Workspaces

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

  • #21
    Originally posted by mgraesslin View Post
    it's QtQuick2 - so we plan to have the possibility of Plasma applets there.
    A la screensaver? i really like the fact that i can use a large monitor as a 10-foot interface dashboard to display useful information whilst not using the computer directly.

    Comment


    • #22
      Originally posted by Alex Sarmiento View Post
      A la screensaver? i really like the fact that i can use a large monitor as a 10-foot interface dashboard to display useful information whilst not using the computer directly.

      Comment


      • #23
        Originally posted by mgraesslin View Post
        it's QtQuick2 - so we plan to have the possibility of Plasma applets there.
        Are you planning to let users change the lock-screen background, or at least use their normal desktop background for it? The non-XScreensaver screen locker in 4.11 uses a background image that's hardcoded by the current theme and it's not really to my taste.

        Comment


        • #24
          Originally posted by schmalzler View Post
          Yeah, that's a serious bug that the kde developers should solve promptly . But what have that to do with my question?

          Comment


          • #25
            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?

            Comment


            • #26
              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.

              Comment


              • #27
                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.)

                Comment


                • #28
                  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)

                  Comment


                  • #29
                    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?

                    Comment


                    • #30
                      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.

                      Comment

                      Working...
                      X