[PATCH weston v4 00/15] Add a fullscreen shell protocol

Jason Ekstrand jason at jlekstrand.net
Tue Feb 25 17:26:32 PST 2014

This patch series adds a fullscreen shell protocol as well as support in
various clients and pieces of weston to fully demonstrate it.  The idea
is to make a shell for clients that run entirely fullscreen as the sole
client visible to the user.  I have four basic use-cases for this.

 1) Simple full-screen clients.  David Hermann has suggested such a
    protocol could be used for splash screens, terminal emulators, etc.
    While DRM/KMS isn't terribly hard to do, this allows simple clients to
    simply start weston and let it handle DRM/KMS and it simply provides
    buffers.  I'm not sure how much this will actually save us, but it
    could be more convenient.  These clients don't want much control, they
    basically want to throw surfaces on the screen.

 2) As an input/output abstraction.  While the "big boys" (GNOME-Shell, E,
    etc.) will be running on KMS directly, there may be benifit to
    supporting running on top of wl_fullscreen_shell.  One of the things
    we're losing when we move away from X is a common input/output
    mechanism.  Most of the time, we're running directly on the hardware
    and we can just use DRM/KMS.  However, there are a variety of VNC/RDP
    servers and other input/output mechanisms that we may want to keep.
    Previously, if you simply implemented an X server or the appropreate
    bits to plug into Xorg, all the DE's would happly run on top of it.
    (GNOME being the major exception here because it 100% requires
    acceleration).  My hope is to provide a mechanism for writing other
    backends for Wayland compositors by implementing a fullscreen shell

 3) Other compositors.  This kind of rolls into 2), but it's worth mention
    on it's own.  Some compositors, such as KWin, would rather not mess
    with DRM/KMS themselves.  Instead, they would rather spawn weston and
    make it do the actual modesetting.  Unlike the simple clients, these
    clients want to basically do full modesetting.  For these clients, we
    provide a slightly different interface that allows far more direct
    control over the mode of the output.  This interface also allows
    more-or-less atomic modesetting.

 4) Screen sharing and recording.  The security discussion on how to allow
    clients to request screen sharing and things of the like is still going
    on and I have no intention of solving that question here.  Most
    proposals for screen sharing and capture have been based on weston's
    screenshooter protocol which allows the screenshooter client to hand a
    surface to weston that weston then fills with the contents of the
    screen.  While this works for screenshots, there are a lot of race
    conditions involved in doing it this way.  People have also suggested
    screen sharing protocols.  However, these usually involve re-writing
    most of the wayland protocol in the other (client -> server) direction.

    For this reason, I propose that, instead of having complicated screen
    sharing protocols, the screen sharing or recording program simply act
    as a wayland compositor supporting the fullscreen shell protocol.  The
    primary compositor (the DE) can then spawn the sharing program and
    connect to it as a client.  This way we can use the normal Wayland
    protocol for communication rather than re-writing it in reverse.

To this end, I have written code to implement the fullsreen shell and to
demonstrate it in all these capacities:

 1) A wl_fullscreen_shell implementation in fullscreen-shell.c.

 2) simple-shm now supports wl_fullscreen_shell as a "simple client"

 3) Support is added to clients/fullscreen.c to exercise the fullscreen
    shell protocol.

 4) wayland-backend.so now supports running in a wl_fullscreen_shell.  It
    automatically detects and runs on all outputs and has full modesetting
 5) A new screen-share.so plugin.  This plugin registers the CTRL+ALT+s
    keybinding.  When this key combination is typed, it spawns another copy
    of weston, this time running the RDP backend, and mirrors the current
    output (where the cursor is) to that RDP session.  Seats from RDP are
    added as aditional seats.

I hope you all like it!  Feedback is appreciated.
--Jason Ekstrand

Jason Ekstrand (15):
  Add a fullscreen shell protocol
  Generate/build the fullscreen shell protocol files
  Add a signal for when a seat updates its capabilities
  Add a wl_fullscreen_shell implementation
  simple-shm: Add fullscreen shell support
  toytoolkit: Only require xdg_shell if the window is not custom
  toytoolkit:Expose output make and model
  Add wl_fullscreen_shell support to weston-fullscreen
  compositor-wayland: Add support for running on top of
  compositor-wayland: Add a --sprawl option
  Automatically select the wayland backend if WAYLAND_SOCKET is set
  Properly handle running inside a compositor that does not provide
  Add support for running with a primary client
  gl-renderer: Fix read_pixels in the case where we have output borders
  Add a screen sharing plugin

 Makefile.am                   |   54 ++
 clients/fullscreen.c          |  165 ++++++-
 clients/simple-shm.c          |   31 +-
 clients/window.c              |   24 +-
 clients/window.h              |    6 +
 configure.ac                  |   17 +
 protocol/fullscreen-shell.xml |  158 ++++++
 src/compositor-wayland.c      |  537 ++++++++++++++++++--
 src/compositor.c              |   49 +-
 src/compositor.h              |    1 +
 src/fullscreen-shell.c        |  822 +++++++++++++++++++++++++++++++
 src/gl-renderer.c             |    4 +
 src/input.c                   |    2 +
 src/screen-share.c            | 1082 +++++++++++++++++++++++++++++++++++++++++
 14 files changed, 2881 insertions(+), 71 deletions(-)
 create mode 100644 protocol/fullscreen-shell.xml
 create mode 100644 src/fullscreen-shell.c
 create mode 100644 src/screen-share.c


More information about the wayland-devel mailing list