Announcement

Collapse
No announcement yet.

Screensaver Inhibition Support Is Being Worked On For Wayland/Weston

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

  • Screensaver Inhibition Support Is Being Worked On For Wayland/Weston

    Phoronix: Screensaver Inhibition Support Is Being Worked On For Wayland/Weston

    Among the features not putting Wayland at feature parity with X11/X.Org is screensaver inhibition. You know, when you're watching a movie or gaming and don't want the screensaver to interrupt the experience? It's now being worked on for Wayland's reference compositor...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2

    I'd like to take a shot at defining the protocol for this and implementing it for Weston. The design I have in mind mostly follows xdg-screensaver and the DBUS screensaver API[1], which provide a desktop-neutral 'inhibit' mechanism to temporarily disable the screensaver/screenblanker on a per-process basis, except that it will be per-surface instead of per-process.
    Nice. With this design, maybe we can finally force all compositors to listen on the same API and guarantee a single, reliable API to all clients.
    So, after issuing the inhibit request for a surface, the screensaver (and screenblanking) will be blocked until the surface is destroyed, disabled, or otherwise loses visibility or becomes occluded.
    Nice! This means that compositors will have official blessing to suspend buggy applications' overzealous screensaver suppression when their windows are minimized.

    (The exact opposite of KDE's legacy-burdened API where the app manually turns off the screensaver and you have to hope it will turn it back on again.)

    Comment


    • #3
      could this possibly fix the irritating issue if a VM has focus it wont initiate the linux host screensaver?

      Comment


      • #4
        Originally posted by stanna View Post
        could this possibly fix the irritating issue if a VM has focus it wont initiate the linux host screensaver?
        Hard to say without knowing more details about your use case, and probably depends on details about what your VM is doing on the input side of things.

        Comment


        • #5
          Originally posted by Bryce Harrington View Post

          Hard to say without knowing more details about your use case, and probably depends on details about what your VM is doing on the input side of things.
          sorry, fedora 22, vmware workstation pro with a Windows 7 guest. if the guest had focus i would get a message the screensaver was prevented. i have never found a solution to it and thought this might be it but i suspect its the other way around?

          Comment


          • #6
            Originally posted by stanna View Post

            sorry, fedora 22, vmware workstation pro with a Windows 7 guest. if the guest had focus i would get a message the screensaver was prevented. i have never found a solution to it and thought this might be it but i suspect its the other way around?
            Heh, weird. Yes, vmware would not be able to twiddle the screensaver off other than through this protocol to request an inhibition.

            The protocol leaves a lot of discretion to your compositor as to when it will honor clients' inhibition requests. In this Weston implementation, for example, the client is only able to keep the screensaver blocked so long as it is "active". Weston's architecture allows you to select from a range of different 'shells' such as a desktop shell, full screen shell, etc., and we build some flexibility in here by allowing different shells to define what "active" means, to provide behaviors that match what makes sense for them. So, "active" might mean "the surface has the keyboard focus" in Weston's desktop shell, so that the app can't inhibit the screensaver when it's minimized or in the background; but some other different shell might define "active" some other way.

            The compositor also has some leeway as to what exact system functionality will be inhibited; in Weston this includes screensavers, locking, screen blanking, and DPMS, but other compositors I suppose could define it a bit differently.

            In any case, your vmware client running under a Wayland compositor would have no other means of disabling screensaving other than this protocol, and if it chooses to use this protocol it would have no choice but to accept the behavior that your chosen compositor+shell implement.
            Last edited by Bryce Harrington; 05 March 2016, 04:54 AM.

            Comment


            • #7
              Will this be adjustable on a per-application basis? I would like to be able to see which application inhibits the screensaver, and disable this inhibition if needed, directly from the statusbar or notification area.

              Comment


              • #8
                Indeed, wrong thread. Sorry.
                Last edited by Adarion; 05 March 2016, 09:15 AM. Reason: wrong thread
                Stop TCPA, stupid software patents and corrupt politicians!

                Comment


                • #9
                  Originally posted by Adarion View Post
                  > Gentoo or one of its derivatives like Calculate or Sabayon

                  Gentoo makes only sense if used as Gentoo. Everything else is a binary distribution and thus not that much different from all the others - besides having rolling release, maybe.
                  Of course, Gentoo - since it is all about choice - offers a plethora of configuration options. It supports a broad variety of HW architectures and features a broad spectrum of userland software. With or without SystemD . And it's even possible to run it on a FreeBSD kernel.
                  But one could set up a system that is comparable to a normal install of a binary distribution.
                  Wrong thread.
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #10


                    When designing an interface, imagine that your program is all that stands between the user and hot, sweaty, tangled-bedsheets-fingertips-digging-into-the-back sex.

                    Comment

                    Working...
                    X