hs-wayland-scanner (empty) → 0.1.0
raw patch · 33 files changed
+12981/−0 lines, 33 filesdep +basedep +bytestringdep +containers
Dependencies added: base, bytestring, containers, directory, filepath, process, text, xml
Files
- LICENSE +26/−0
- README.md +195/−0
- examples/hello-world/Buffer.hs +65/−0
- examples/hello-world/HelloWorld.hs +135/−0
- examples/hello-world/README.md +52/−0
- examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/build/autogen/PackageInfo_HelloWorld.hs +25/−0
- examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/build/autogen/Paths_HelloWorld.hs +77/−0
- examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/x/hello-world/build/hello-world/autogen/PackageInfo_HelloWorld.hs +25/−0
- examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/x/hello-world/build/hello-world/autogen/Paths_HelloWorld.hs +77/−0
- examples/hello-world/hello-world.cabal +47/−0
- examples/hello-world/hs-wayland-scanner.cfg +10/−0
- examples/hello-world/protocols/wayland.xml +3151/−0
- examples/hello-world/protocols/xdg-shell.xml +1282/−0
- examples/simple-client/README.md +65/−0
- examples/simple-client/hs-wayland-scanner.cfg +8/−0
- examples/simple-client/protocols/wayland.xml +3151/−0
- examples/simple-client/simple-client.cabal +42/−0
- examples/simple-client/simple-client.hs +60/−0
- examples/simple-server/README.md +65/−0
- examples/simple-server/hs-wayland-scanner.cfg +8/−0
- examples/simple-server/protocols/wayland.xml +3151/−0
- examples/simple-server/simple-server.cabal +42/−0
- examples/simple-server/simple-server.hs +63/−0
- hs-wayland-scanner.cabal +71/−0
- src/Graphics/Wayland/Scanner.hs +30/−0
- src/Graphics/Wayland/Scanner/Generate.hs +102/−0
- src/Graphics/Wayland/Scanner/Main.hs +90/−0
- src/Graphics/Wayland/Scanner/Parse.hs +88/−0
- src/Graphics/Wayland/Scanner/Render.hs +210/−0
- src/Graphics/Wayland/Scanner/RenderC.hs +81/−0
- src/Graphics/Wayland/Scanner/Solve.hs +66/−0
- src/Graphics/Wayland/Scanner/Text.hs +285/−0
- src/Graphics/Wayland/Scanner/Types.hs +136/−0
+ LICENSE view
@@ -0,0 +1,26 @@+Redistribution and use in source and binary forms, with or without+modification, are permitted provided that the following conditions are+met:++1. Redistributions of source code must retain the above copyright+notice, this list of conditions and the following disclaimer.++2. Redistributions in binary form must reproduce the above copyright+notice, this list of conditions and the following disclaimer in the+documentation and/or other materials provided with the distribution.++3. Neither the name of the copyright holder nor the names of its+contributors may be used to endorse or promote products derived from+this software without specific prior written permission.++THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT+HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ README.md view
@@ -0,0 +1,195 @@+About+=====++`hs-wayland-scanner` is an implementation of the Wayland [Message+Definition+Language](https://wayland.freedesktop.org/docs/book/Message_XML.htm). It+will produce low-level Haskell bindings for Wayland client/server+protocols.++It will process multiple protocols in a single run, checking for+dependencies, in order to properly generate imports for all+modules. All depending protocols must be generated at once and+unresolved dependencies will produce an error.++The generated Haskell modules will also include the documentation that+can be processed with `Haddock`.++`hs-wayland-scanner` also exposes a library.++Quick Start+===========++You can install `hs-wayland-scanner` from+[Hackage](https://hackage.haskell.org/):++``` shell+cabal install hs-wayland-scanner+```++or locally:++``` shell+tar xvfz hs-wayland-scanner-0.1.0.tar.gz+cd hs-wayland-scanner-0.1.0+cabal [run|build|install]+```++Building with `MicroHs`+=======================++This package relies on a very minimal set of dependencies, most of+which included in `base`, so it can be easily built with+[MicroHs](https://github.com/augustss/MicroHs.git):++``` shell+git clone https://github.com/augustss/MicroHs.git+cd MicroHs+make install++# add the `mhs` path to the environment (change accordingly):+export PATH=/home/username/.mcabal/bin:$PATH+```++There are few dependencies that must be installed for+`hs-wayland-scanner`: the major one, which requires some special+handling, is [xml](https://github.com/GaloisInc/xml) that must be+installed from https://github.com/konsumlamm/xml++``` shell+mcabal install ghc-compat+mcabal install --git=https://github.com/konsumlamm/xml xml+```++Then:++``` shell+mcabal -r install hs-wayland-scanner+```++Done!++Generated files and modules+===========================++In order to make it possible to generate both client and server+protocol bindings for the same project, each protocol will produce two+different modules:++```+Graphics.Wayland.Protocol.ProtocolName+Graphics.Wayland.(Client|Server).Protocol.ProtocolName+```++The first module will export the defined `Enumerations`, which are+shared by client and server protocols. A single module for both avoids+name clashes.++The default `Graphics` may be changed with the `-n` command line+option.++All bindings will be written in the `generated/` directory, by+default, but that can be changed with the `-p` command line option.++The Haskell bindings will be located in the `src/` sub-directory of+`generated/`. This location can be changed with the `--src` command+line option.++Additionally the bindings to the core wayland-client and/or+wayland-server will also be generated:++```+Graphics.Wayland.(Client|Server).Core+```++This module exports the bindings to+`wayland-[client|server]-core.h`. Not all foreign functions of those+libraries are presently implemented.++`hws` will report the generated modules to be included in the `.cabal`+file.++Additional C wrappers will be generated in the default `cbits`+directory: this can be changed with the "--cbits" command line option.++By default:++```+generated/cbits/wayland-[client|server]-protocols.c+```++This file must be included in the `c-sources` cabal field, together+with the dependency to `libwayland`:++```+ c-sources: ./cbits/wayland-[client|server]-protocols.c+ pkgconfig-depends: wayland-[client|server]+```++It is also possible to create a configuration file and run `hws -c+path/to/config`. The included examples will ship a configuration file+that can be used as a template.++Command line options+====================++```+Usage: hws [OPTIONS] [PROTOCOLS]++Options:+-h Print help+-p PATH Root directory for generated files (Default: "./generated")+-n STRING Namespace for generated modules (Default: "Graphics")+-r ROLE Generate Client or Server protocols (Default: "Client")+-c PATH Path to a configuration file+--cbits PATH Sub-directory for generated C files (Default: "cbits")+--src PATH Sub-directory for generated Haskell files (Default: "src")+[PROTOCOLS] The Wayland XML files to be processed+```++Examples+========++The source code comes with three examples: a `simple-server` and a+`simple-client` which may interact, and a `hello-world` example: a+standalone client that demonstrates `XDG-shell` handshaking and+renders a semi-transparent blue window using `POSIX` shared memory.++Each example comes with a `hws` configuration file and a `.cabal` file+to build them. Refer to their respective `README` for further+information.++Known issues and future improvements+====================================++# Versioning++Protocol interfaces may add (but not remove) requests and events over+time. Because interface listeners are represented as Haskell records,+generating bindings against a newer version of a protocol may lead to+"missing field" warnings if your implementation doesn't account for+the newly added events and requests for the server side.++Protocols themselves do not have versions; only individual interfaces+do. Requests and events often include a "since" attribute in the XML,+which is preserved in the generated Haddock documentation for each+module.++`hs-wayland-scanner` is currently intended to be used as a+pre-processing tool rather than being invoked during every build. For+this reason, I have included the specific protocol XML files used for+the examples to ensure they always compile out of the box.++# Bindings to core libraries (client and server)++I plan to expand the number of foreign imports for the core server and+client libraries. Note that Variadic Functions (like+`wl_proxy_marshal_flags`) cannot be implemented in Haskell via direct+foreign calls.++However, since this scanner generates specific, type-safe wrappers for+all protocol messages, these generic variadic dispatchers are+generally not needed by end-users. See the `hello-world` example for+an idiomatic approach using the generated wrappers and opaque+pointers. Ideas or suggestions for expanding the core bindings are+welcome.
+ examples/hello-world/Buffer.hs view
@@ -0,0 +1,65 @@+{-# LANGUAGE ForeignFunctionInterface #-}+module Buffer where++import Foreign+import Foreign.C.Types+import Control.Monad+import System.Posix.Types (Fd(..), COff(..))+import System.Posix.IO (closeFd)+import System.Posix.Files (setFdSize, stdFileMode)+import System.Posix.SharedMem++-- Using the mmap package would be nice but there are some portabilty+-- issues (see below), so we will use mmap from the standard C library.+-- import System.IO.MMap++import Graphics.Wayland.Protocol.Wayland+import Graphics.Wayland.Client.Protocol.Wayland++-- Use mmap from the Standard C library.+foreign import ccall "sys/mman.h mmap"+ c_mmap :: Ptr () -> CSize -> CInt -> CInt -> CInt -> COff -> IO (Ptr ())++-- Helper to get the CInt out of Fd+unFd :: Fd -> CInt+unFd (Fd n) = n++-- Create a buffer and fill it with green pixels.+createBuffer :: Ptr WlShm -> Int -> Int -> IO (Ptr WlBuffer)+createBuffer shm width height = do+ let stride = width * 4+ size = fromIntegral $ stride * height+ -- A unique name for the shared memory segment.+ shmName = "/hs-wayland-example-" ++ show width ++ "x" ++ show height++ -- Create a shared memory object, with shmReadWrite and shmCreate.+ fd <- shmOpen shmName (ShmOpenFlags True True False False) stdFileMode++ -- Resize the memory segment to the correct size.+ setFdSize fd size++ -- Map the memory into our process.+ -- mmapFilePtr from the mmap package requires the full path which+ -- may be different in different POSIX systems.+ -- (ptr, _, _, _) <- mmapFilePtr ("/dev/shm" ++ shmName) ReadWrite (Just (0, fromIntegral size))+ ptr <- c_mmap nullPtr (fromIntegral size) (1 .|. 2) 1 (unFd fd) 0++ -- Fill with blue with 50% transparency (0x800000FF)+ let pixels = castPtr ptr :: Ptr Word32+ forM_ [0 .. width * height - 1] $ \i ->+ pokeElemOff pixels i 0x800000ff++ -- Create Wayland objects.+ pool <- wl_shm_create_pool shm (unFd fd) (fromIntegral size)+ buffer <- wl_shm_pool_create_buffer pool+ 0+ (fromIntegral width)+ (fromIntegral height)+ (fromIntegral stride)+ WL_SHM_FORMAT_ARGB8888 -- 32-bit ARGB format++ -- Cleanup.+ shmUnlink shmName+ closeFd fd++ return buffer
+ examples/hello-world/HelloWorld.hs view
@@ -0,0 +1,135 @@+module Main where++import Foreign hiding ( void )+import Foreign.C.String++import Control.Monad+import System.Exit+import Data.IORef++import Graphics.Wayland.Protocol.Wayland+import Graphics.Wayland.Client.Core+import Graphics.Wayland.Client.Protocol.Wayland+import Graphics.Wayland.Client.Protocol.XdgShell++import Buffer++-- A simple state as user data+data State = State+ { display :: Ptr WlDisplay+ , compositor :: Ptr WlCompositor+ , wlShm :: Ptr WlShm+ , wmBase :: Ptr XdgWmBase+ , surface :: Ptr WlSurface+ }++-- xdg_wm_base ping: let the server know we are still alive+wmBasePingCb :: Ptr () -> Ptr XdgWmBase -> Word32 -> IO ()+wmBasePingCb _ wm serial = xdg_wm_base_pong wm serial++-- xdg_surface configure+configureCb :: Ptr () -> Ptr XdgSurface -> Word32 -> IO ()+configureCb dataPtr xdgSurf serial = do+ putStrLn "[CLIENT] Received xdg_surface.configure"+ stRef <- deRefStablePtr (castPtrToStablePtr dataPtr)+ st <- readIORef stRef+ void $ xdg_surface_ack_configure xdgSurf serial++ -- draw after configure+ buffer <- createBuffer (wlShm st) 600 400++ void $ wl_surface_attach (surface st) buffer 1 1+ void $ wl_surface_damage (surface st) 0 0 600 400+ void $ wl_surface_commit (surface st)++ -- send the commit to the server+ void $ wl_display_flush (display st)+ return ()++-- global registry callback+globalCb :: WlRegistryGlobalCb+globalCb dataPtr registry name interface _ = do+ iface <- peekCString interface+ stRef <- deRefStablePtr (castPtrToStablePtr dataPtr)++ case iface of+ "wl_compositor" -> do+ comp <- wl_registry_bind registry name wl_compositor_interface 4+ surf <- wl_compositor_create_surface (castPtr comp)+ modifyIORef' stRef (\s -> s { compositor = castPtr comp, surface = surf })+ putStrLn "[CLIENT] Bound compositor"++ "wl_shm" -> do+ shm <- wl_registry_bind registry name wl_shm_interface 1+ modifyIORef' stRef (\s -> s { wlShm = castPtr shm })++ "xdg_wm_base" -> do+ wm <- wl_registry_bind registry name xdg_wm_base_interface 1+ modifyIORef' stRef (\s -> s { wmBase = castPtr wm })+ putStrLn "[CLIENT] Bound xdg_wm_base"++ -- add the ping listener+ pingFun <- mkXdgWmBasePingCb wmBasePingCb+ let wmListener = XdgWmBaseListener pingFun+ alloca $ \ptr -> do+ poke ptr wmListener+ void $ xdg_wm_base_add_listener (castPtr wm) ptr (castPtr dataPtr)+ _ -> return ()++main :: IO ()+main = do+ -- connect+ dpy <- wl_display_connect nullPtr+ when (dpy == nullPtr) $ do+ putStrLn "Failed to connect to Wayland."+ exitFailure+ putStrLn "Connected!"+ + -- the state+ stRef <- newIORef State+ { display = dpy+ , compositor = nullPtr+ , wlShm = nullPtr+ , wmBase = nullPtr+ , surface = nullPtr+ }+ sp <- newStablePtr stRef++ -- get the registry+ registry <- wl_display_get_registry dpy++ -- add the global listener+ cb <- mkWlRegistryGlobalCb globalCb+ let listener = WlRegistryListener+ { wlRegistryGlobal = cb+ , wlRegistryGlobalRemove = nullFunPtr+ }++ alloca $ \ptr -> do+ poke ptr listener+ void $ wl_registry_add_listener registry ptr (castStablePtrToPtr sp)+ void $ wl_display_roundtrip dpy++ st <- readIORef stRef+ xdgSurf <- xdg_wm_base_get_xdg_surface (wmBase st) (surface st)+ top <- xdg_surface_get_toplevel xdgSurf++ -- identify your window+ withCString "hello world" $ \str -> do+ xdg_toplevel_set_title top str+ xdg_toplevel_set_app_id top str++ -- configure listener+ cfgFun <- mkXdgSurfaceConfigureCb configureCb+ let surfListener = XdgSurfaceListener cfgFun+ alloca $ \ptr -> do+ poke ptr surfListener+ void $ xdg_surface_add_listener xdgSurf ptr (castStablePtrToPtr sp)++ void $ wl_surface_commit (surface st)+ -- send the commit to the server+ void $ wl_display_flush dpy++ forever $ do+ void $ wl_display_dispatch dpy+ void $ wl_display_flush dpy
+ examples/hello-world/README.md view
@@ -0,0 +1,52 @@+About+=====++A simple standalone client that demonstrates `XDG-shell` handshaking+and renders a semi-transparent blue window using `POSIX` shared+memory.++It also uses opaque pointers for managing the state.++Building+========++Use `hws -c hs-wayland-scanner.cfg` to generate the bindings:++``` shell+cd examples/hello-world+/path/to/hws -c hs-wayland-scanner.cfg+```++Alternatively run:++``` shell+/path/to/hws -p ./ protocols/wayland.xml protocols/xdg-shell.xml+```++Now you can build it with `cabal`:++``` shell+cabal [run|build|install]+```++Run with:++``` shell+/path/to/hello-world+```++or, if `WAYLAND_DISPLAY` is not set:++``` shell+WAYLAND_DISPLAY="wayland-0" /path/to/hello-world+```++Documentation+=============++This example exposes a library also to show the documentation+generated by `hws`. To produce the documentation run:++``` shell+cabal haddock+```
+ examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/build/autogen/PackageInfo_HelloWorld.hs view
@@ -0,0 +1,25 @@+{-# LANGUAGE NoRebindableSyntax #-}+{-# OPTIONS_GHC -fno-warn-missing-import-lists #-}+{-# OPTIONS_GHC -w #-}+module PackageInfo_HelloWorld (+ name,+ version,+ synopsis,+ copyright,+ homepage,+ ) where++import Data.Version (Version(..))+import Prelude++name :: String+name = "HelloWorld"+version :: Version+version = Version [0,1] []++synopsis :: String+synopsis = "a simple wayland client"+copyright :: String+copyright = ""+homepage :: String+homepage = "https://codeberg.org/andrea_rossato/hs-wayland-scanner"
+ examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/build/autogen/Paths_HelloWorld.hs view
@@ -0,0 +1,77 @@+{-# LANGUAGE CPP #-}+{-# LANGUAGE NoRebindableSyntax #-}+#if __GLASGOW_HASKELL__ >= 810+{-# OPTIONS_GHC -Wno-prepositive-qualified-module #-}+#endif+{-# OPTIONS_GHC -fno-warn-missing-import-lists #-}+{-# OPTIONS_GHC -w #-}+module Paths_HelloWorld (+ version,+ getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir,+ getDataFileName, getSysconfDir+ ) where+++import qualified Control.Exception as Exception+import qualified Data.List as List+import Data.Version (Version(..))+import System.Environment (getEnv)+import Prelude+++#if defined(VERSION_base)++#if MIN_VERSION_base(4,0,0)+catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a+#else+catchIO :: IO a -> (Exception.Exception -> IO a) -> IO a+#endif++#else+catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a+#endif+catchIO = Exception.catch++version :: Version+version = Version [0,1] []++getDataFileName :: FilePath -> IO FilePath+getDataFileName name = do+ dir <- getDataDir+ return (dir `joinFileName` name)++getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir, getSysconfDir :: IO FilePath+++++bindir, libdir, dynlibdir, datadir, libexecdir, sysconfdir :: FilePath+bindir = "/home/andrea/.cabal/bin"+libdir = "/home/andrea/.cabal/lib/x86_64-linux-ghc-9.10.1-7767/HelloWorld-0.1-inplace"+dynlibdir = "/home/andrea/.cabal/lib/x86_64-linux-ghc-9.10.1-7767"+datadir = "/home/andrea/.cabal/share/x86_64-linux-ghc-9.10.1-7767/HelloWorld-0.1"+libexecdir = "/home/andrea/.cabal/libexec/x86_64-linux-ghc-9.10.1-7767/HelloWorld-0.1"+sysconfdir = "/home/andrea/.cabal/etc"++getBinDir = catchIO (getEnv "HelloWorld_bindir") (\_ -> return bindir)+getLibDir = catchIO (getEnv "HelloWorld_libdir") (\_ -> return libdir)+getDynLibDir = catchIO (getEnv "HelloWorld_dynlibdir") (\_ -> return dynlibdir)+getDataDir = catchIO (getEnv "HelloWorld_datadir") (\_ -> return datadir)+getLibexecDir = catchIO (getEnv "HelloWorld_libexecdir") (\_ -> return libexecdir)+getSysconfDir = catchIO (getEnv "HelloWorld_sysconfdir") (\_ -> return sysconfdir)++++joinFileName :: String -> String -> FilePath+joinFileName "" fname = fname+joinFileName "." fname = fname+joinFileName dir "" = dir+joinFileName dir fname+ | isPathSeparator (List.last dir) = dir ++ fname+ | otherwise = dir ++ pathSeparator : fname++pathSeparator :: Char+pathSeparator = '/'++isPathSeparator :: Char -> Bool+isPathSeparator c = c == '/'
+ examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/x/hello-world/build/hello-world/autogen/PackageInfo_HelloWorld.hs view
@@ -0,0 +1,25 @@+{-# LANGUAGE NoRebindableSyntax #-}+{-# OPTIONS_GHC -fno-warn-missing-import-lists #-}+{-# OPTIONS_GHC -w #-}+module PackageInfo_HelloWorld (+ name,+ version,+ synopsis,+ copyright,+ homepage,+ ) where++import Data.Version (Version(..))+import Prelude++name :: String+name = "HelloWorld"+version :: Version+version = Version [0,1] []++synopsis :: String+synopsis = "a simple wayland client"+copyright :: String+copyright = ""+homepage :: String+homepage = "https://codeberg.org/andrea_rossato/hs-wayland-scanner"
+ examples/hello-world/dist-newstyle/build/x86_64-linux/ghc-9.10.1/HelloWorld-0.1/x/hello-world/build/hello-world/autogen/Paths_HelloWorld.hs view
@@ -0,0 +1,77 @@+{-# LANGUAGE CPP #-}+{-# LANGUAGE NoRebindableSyntax #-}+#if __GLASGOW_HASKELL__ >= 810+{-# OPTIONS_GHC -Wno-prepositive-qualified-module #-}+#endif+{-# OPTIONS_GHC -fno-warn-missing-import-lists #-}+{-# OPTIONS_GHC -w #-}+module Paths_HelloWorld (+ version,+ getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir,+ getDataFileName, getSysconfDir+ ) where+++import qualified Control.Exception as Exception+import qualified Data.List as List+import Data.Version (Version(..))+import System.Environment (getEnv)+import Prelude+++#if defined(VERSION_base)++#if MIN_VERSION_base(4,0,0)+catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a+#else+catchIO :: IO a -> (Exception.Exception -> IO a) -> IO a+#endif++#else+catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a+#endif+catchIO = Exception.catch++version :: Version+version = Version [0,1] []++getDataFileName :: FilePath -> IO FilePath+getDataFileName name = do+ dir <- getDataDir+ return (dir `joinFileName` name)++getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir, getSysconfDir :: IO FilePath+++++bindir, libdir, dynlibdir, datadir, libexecdir, sysconfdir :: FilePath+bindir = "/home/andrea/.cabal/bin"+libdir = "/home/andrea/.cabal/lib/x86_64-linux-ghc-9.10.1-7767/HelloWorld-0.1-inplace-hello-world"+dynlibdir = "/home/andrea/.cabal/lib/x86_64-linux-ghc-9.10.1-7767"+datadir = "/home/andrea/.cabal/share/x86_64-linux-ghc-9.10.1-7767/HelloWorld-0.1"+libexecdir = "/home/andrea/.cabal/libexec/x86_64-linux-ghc-9.10.1-7767/HelloWorld-0.1"+sysconfdir = "/home/andrea/.cabal/etc"++getBinDir = catchIO (getEnv "HelloWorld_bindir") (\_ -> return bindir)+getLibDir = catchIO (getEnv "HelloWorld_libdir") (\_ -> return libdir)+getDynLibDir = catchIO (getEnv "HelloWorld_dynlibdir") (\_ -> return dynlibdir)+getDataDir = catchIO (getEnv "HelloWorld_datadir") (\_ -> return datadir)+getLibexecDir = catchIO (getEnv "HelloWorld_libexecdir") (\_ -> return libexecdir)+getSysconfDir = catchIO (getEnv "HelloWorld_sysconfdir") (\_ -> return sysconfdir)++++joinFileName :: String -> String -> FilePath+joinFileName "" fname = fname+joinFileName "." fname = fname+joinFileName dir "" = dir+joinFileName dir fname+ | isPathSeparator (List.last dir) = dir ++ fname+ | otherwise = dir ++ pathSeparator : fname++pathSeparator :: Char+pathSeparator = '/'++isPathSeparator :: Char -> Bool+isPathSeparator c = c == '/'
+ examples/hello-world/hello-world.cabal view
@@ -0,0 +1,47 @@+cabal-version: 3.0+name: HelloWorld+version: 0.1+author: Andrea Rossato+maintainer: andrea.rossato@unitn.it+homepage: https://codeberg.org/andrea_rossato/hs-wayland-scanner+synopsis: a simple wayland client+description: a simple wayland client++category: System+license: BSD-3-Clause+extra-source-files: README.md+build-type: Simple++library+ hs-source-dirs: ./src+ exposed-modules: Graphics.Wayland.Client.Core+ Graphics.Wayland.Client.Protocol.Wayland+ Graphics.Wayland.Protocol.Wayland+ Graphics.Wayland.Client.Protocol.XdgShell+ Graphics.Wayland.Protocol.XdgShell+ include-dirs: ./cbits+ c-sources: ./cbits/wayland-client-protocols.c+ build-depends: base, unix+ pkgconfig-depends: wayland-client+ ghc-options: -O -Wall+ ghc-prof-options: -auto-all+ default-language: Haskell2010+ default-extensions: ForeignFunctionInterface++executable hello-world+ main-is: HelloWorld.hs+ hs-source-dirs: ., ./src+ other-modules: Graphics.Wayland.Client.Core+ Graphics.Wayland.Client.Protocol.Wayland+ Graphics.Wayland.Protocol.Wayland+ Graphics.Wayland.Client.Protocol.XdgShell+ Graphics.Wayland.Protocol.XdgShell+ Buffer+ include-dirs: ./cbits+ c-sources: ./cbits/wayland-client-protocols.c+ build-depends: base, unix+ pkgconfig-depends: wayland-client+ ghc-options: -O -Wall+ ghc-prof-options: -auto-all+ default-language: Haskell2010+ default-extensions: ForeignFunctionInterface
+ examples/hello-world/hs-wayland-scanner.cfg view
@@ -0,0 +1,10 @@+HwsConfig+ { genPrefix = "./"+ , hsNameSpace = "Graphics"+ , protoRole = Client+ , protocols = [ "protocols/wayland.xml"+ , "protocols/xdg-shell.xml"+ ]+ , cbitsPrefix = "cbits"+ , srcPrefix = "src"+ }
+ examples/hello-world/protocols/wayland.xml view
@@ -0,0 +1,3151 @@+<?xml version="1.0" encoding="UTF-8"?>+<protocol name="wayland">++ <copyright>+ Copyright © 2008-2011 Kristian Høgsberg+ Copyright © 2010-2011 Intel Corporation+ Copyright © 2012-2013 Collabora, Ltd.++ Permission is hereby granted, free of charge, to any person+ obtaining a copy of this software and associated documentation files+ (the "Software"), to deal in the Software without restriction,+ including without limitation the rights to use, copy, modify, merge,+ publish, distribute, sublicense, and/or sell copies of the Software,+ and to permit persons to whom the Software is furnished to do so,+ subject to the following conditions:++ The above copyright notice and this permission notice (including the+ next paragraph) shall be included in all copies or substantial+ portions of the Software.++ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE+ SOFTWARE.+ </copyright>++ <interface name="wl_display" version="1">+ <description summary="core global object">+ The core global object. This is a special singleton object. It+ is used for internal Wayland protocol features.+ </description>++ <request name="sync">+ <description summary="asynchronous roundtrip">+ The sync request asks the server to emit the 'done' event+ on the returned wl_callback object. Since requests are+ handled in-order and events are delivered in-order, this can+ be used as a barrier to ensure all previous requests and the+ resulting events have been handled.++ The object returned by this request will be destroyed by the+ compositor after the callback is fired and as such the client must not+ attempt to use it after that point.++ The callback_data passed in the callback is the event serial.+ </description>+ <arg name="callback" type="new_id" interface="wl_callback"+ summary="callback object for the sync request"/>+ </request>++ <request name="get_registry">+ <description summary="get global registry object">+ This request creates a registry object that allows the client+ to list and bind the global objects available from the+ compositor.++ It should be noted that the server side resources consumed in+ response to a get_registry request can only be released when the+ client disconnects, not when the client side proxy is destroyed.+ Therefore, clients should invoke get_registry as infrequently as+ possible to avoid wasting memory.+ </description>+ <arg name="registry" type="new_id" interface="wl_registry"+ summary="global registry object"/>+ </request>++ <event name="error">+ <description summary="fatal error event">+ The error event is sent out when a fatal (non-recoverable)+ error has occurred. The object_id argument is the object+ where the error occurred, most often in response to a request+ to that object. The code identifies the error and is defined+ by the object interface. As such, each interface defines its+ own set of error codes. The message is a brief description+ of the error, for (debugging) convenience.+ </description>+ <arg name="object_id" type="object" summary="object where the error occurred"/>+ <arg name="code" type="uint" summary="error code"/>+ <arg name="message" type="string" summary="error description"/>+ </event>++ <enum name="error">+ <description summary="global error values">+ These errors are global and can be emitted in response to any+ server request.+ </description>+ <entry name="invalid_object" value="0"+ summary="server couldn't find object"/>+ <entry name="invalid_method" value="1"+ summary="method doesn't exist on the specified interface or malformed request"/>+ <entry name="no_memory" value="2"+ summary="server is out of memory"/>+ <entry name="implementation" value="3"+ summary="implementation error in compositor"/>+ </enum>++ <event name="delete_id">+ <description summary="acknowledge object ID deletion">+ This event is used internally by the object ID management+ logic. When a client deletes an object that it had created,+ the server will send this event to acknowledge that it has+ seen the delete request. When the client receives this event,+ it will know that it can safely reuse the object ID.+ </description>+ <arg name="id" type="uint" summary="deleted object ID"/>+ </event>+ </interface>++ <interface name="wl_registry" version="1">+ <description summary="global registry object">+ The singleton global registry object. The server has a number of+ global objects that are available to all clients. These objects+ typically represent an actual object in the server (for example,+ an input device) or they are singleton objects that provide+ extension functionality.++ When a client creates a registry object, the registry object+ will emit a global event for each global currently in the+ registry. Globals come and go as a result of device or+ monitor hotplugs, reconfiguration or other events, and the+ registry will send out global and global_remove events to+ keep the client up to date with the changes. To mark the end+ of the initial burst of events, the client can use the+ wl_display.sync request immediately after calling+ wl_display.get_registry.++ A client can bind to a global object by using the bind+ request. This creates a client-side handle that lets the object+ emit events to the client and lets the client invoke requests on+ the object.+ </description>++ <request name="bind">+ <description summary="bind an object to the display">+ Binds a new, client-created object to the server using the+ specified name as the identifier.+ </description>+ <arg name="name" type="uint" summary="unique numeric name of the object"/>+ <arg name="id" type="new_id" summary="bounded object"/>+ </request>++ <event name="global">+ <description summary="announce global object">+ Notify the client of global objects.++ The event notifies the client that a global object with+ the given name is now available, and it implements the+ given version of the given interface.+ </description>+ <arg name="name" type="uint" summary="numeric name of the global object"/>+ <arg name="interface" type="string" summary="interface implemented by the object"/>+ <arg name="version" type="uint" summary="interface version"/>+ </event>++ <event name="global_remove">+ <description summary="announce removal of global object">+ Notify the client of removed global objects.++ This event notifies the client that the global identified+ by name is no longer available. If the client bound to+ the global using the bind request, the client should now+ destroy that object.++ The object remains valid and requests to the object will be+ ignored until the client destroys it, to avoid races between+ the global going away and a client sending a request to it.+ </description>+ <arg name="name" type="uint" summary="numeric name of the global object"/>+ </event>+ </interface>++ <interface name="wl_callback" version="1">+ <description summary="callback object">+ Clients can handle the 'done' event to get notified when+ the related request is done.++ Note, because wl_callback objects are created from multiple independent+ factory interfaces, the wl_callback interface is frozen at version 1.+ </description>++ <event name="done" type="destructor">+ <description summary="done event">+ Notify the client when the related request is done.+ </description>+ <arg name="callback_data" type="uint" summary="request-specific data for the callback"/>+ </event>+ </interface>++ <interface name="wl_compositor" version="6">+ <description summary="the compositor singleton">+ A compositor. This object is a singleton global. The+ compositor is in charge of combining the contents of multiple+ surfaces into one displayable output.+ </description>++ <request name="create_surface">+ <description summary="create new surface">+ Ask the compositor to create a new surface.+ </description>+ <arg name="id" type="new_id" interface="wl_surface" summary="the new surface"/>+ </request>++ <request name="create_region">+ <description summary="create new region">+ Ask the compositor to create a new region.+ </description>+ <arg name="id" type="new_id" interface="wl_region" summary="the new region"/>+ </request>+ </interface>++ <interface name="wl_shm_pool" version="1">+ <description summary="a shared memory pool">+ The wl_shm_pool object encapsulates a piece of memory shared+ between the compositor and client. Through the wl_shm_pool+ object, the client can allocate shared memory wl_buffer objects.+ All objects created through the same pool share the same+ underlying mapped memory. Reusing the mapped memory avoids the+ setup/teardown overhead and is useful when interactively resizing+ a surface or for many small buffers.+ </description>++ <request name="create_buffer">+ <description summary="create a buffer from the pool">+ Create a wl_buffer object from the pool.++ The buffer is created offset bytes into the pool and has+ width and height as specified. The stride argument specifies+ the number of bytes from the beginning of one row to the beginning+ of the next. The format is the pixel format of the buffer and+ must be one of those advertised through the wl_shm.format event.++ A buffer will keep a reference to the pool it was created from+ so it is valid to destroy the pool immediately after creating+ a buffer from it.+ </description>+ <arg name="id" type="new_id" interface="wl_buffer" summary="buffer to create"/>+ <arg name="offset" type="int" summary="buffer byte offset within the pool"/>+ <arg name="width" type="int" summary="buffer width, in pixels"/>+ <arg name="height" type="int" summary="buffer height, in pixels"/>+ <arg name="stride" type="int" summary="number of bytes from the beginning of one row to the beginning of the next row"/>+ <arg name="format" type="uint" enum="wl_shm.format" summary="buffer pixel format"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy the pool">+ Destroy the shared memory pool.++ The mmapped memory will be released when all+ buffers that have been created from this pool+ are gone.+ </description>+ </request>++ <request name="resize">+ <description summary="change the size of the pool mapping">+ This request will cause the server to remap the backing memory+ for the pool from the file descriptor passed when the pool was+ created, but using the new size. This request can only be+ used to make the pool bigger.++ This request only changes the amount of bytes that are mmapped+ by the server and does not touch the file corresponding to the+ file descriptor passed at creation time. It is the client's+ responsibility to ensure that the file is at least as big as+ the new pool size.+ </description>+ <arg name="size" type="int" summary="new size of the pool, in bytes"/>+ </request>+ </interface>++ <interface name="wl_shm" version="1">+ <description summary="shared memory support">+ A singleton global object that provides support for shared+ memory.++ Clients can create wl_shm_pool objects using the create_pool+ request.++ On binding the wl_shm object one or more format events+ are emitted to inform clients about the valid pixel formats+ that can be used for buffers.+ </description>++ <enum name="error">+ <description summary="wl_shm error values">+ These errors can be emitted in response to wl_shm requests.+ </description>+ <entry name="invalid_format" value="0" summary="buffer format is not known"/>+ <entry name="invalid_stride" value="1" summary="invalid size or stride during pool or buffer creation"/>+ <entry name="invalid_fd" value="2" summary="mmapping the file descriptor failed"/>+ </enum>++ <enum name="format">+ <description summary="pixel formats">+ This describes the memory layout of an individual pixel.++ All renderers should support argb8888 and xrgb8888 but any other+ formats are optional and may not be supported by the particular+ renderer in use.++ The drm format codes match the macros defined in drm_fourcc.h, except+ argb8888 and xrgb8888. The formats actually supported by the compositor+ will be reported by the format event.++ For all wl_shm formats and unless specified in another protocol+ extension, pre-multiplied alpha is used for pixel values.+ </description>+ <!-- Note to protocol writers: don't update this list manually, instead+ run the automated script that keeps it in sync with drm_fourcc.h. -->+ <entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>+ <entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>+ <entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>+ <entry name="rgb332" value="0x38424752" summary="8-bit RGB format, [7:0] R:G:B 3:3:2"/>+ <entry name="bgr233" value="0x38524742" summary="8-bit BGR format, [7:0] B:G:R 2:3:3"/>+ <entry name="xrgb4444" value="0x32315258" summary="16-bit xRGB format, [15:0] x:R:G:B 4:4:4:4 little endian"/>+ <entry name="xbgr4444" value="0x32314258" summary="16-bit xBGR format, [15:0] x:B:G:R 4:4:4:4 little endian"/>+ <entry name="rgbx4444" value="0x32315852" summary="16-bit RGBx format, [15:0] R:G:B:x 4:4:4:4 little endian"/>+ <entry name="bgrx4444" value="0x32315842" summary="16-bit BGRx format, [15:0] B:G:R:x 4:4:4:4 little endian"/>+ <entry name="argb4444" value="0x32315241" summary="16-bit ARGB format, [15:0] A:R:G:B 4:4:4:4 little endian"/>+ <entry name="abgr4444" value="0x32314241" summary="16-bit ABGR format, [15:0] A:B:G:R 4:4:4:4 little endian"/>+ <entry name="rgba4444" value="0x32314152" summary="16-bit RBGA format, [15:0] R:G:B:A 4:4:4:4 little endian"/>+ <entry name="bgra4444" value="0x32314142" summary="16-bit BGRA format, [15:0] B:G:R:A 4:4:4:4 little endian"/>+ <entry name="xrgb1555" value="0x35315258" summary="16-bit xRGB format, [15:0] x:R:G:B 1:5:5:5 little endian"/>+ <entry name="xbgr1555" value="0x35314258" summary="16-bit xBGR 1555 format, [15:0] x:B:G:R 1:5:5:5 little endian"/>+ <entry name="rgbx5551" value="0x35315852" summary="16-bit RGBx 5551 format, [15:0] R:G:B:x 5:5:5:1 little endian"/>+ <entry name="bgrx5551" value="0x35315842" summary="16-bit BGRx 5551 format, [15:0] B:G:R:x 5:5:5:1 little endian"/>+ <entry name="argb1555" value="0x35315241" summary="16-bit ARGB 1555 format, [15:0] A:R:G:B 1:5:5:5 little endian"/>+ <entry name="abgr1555" value="0x35314241" summary="16-bit ABGR 1555 format, [15:0] A:B:G:R 1:5:5:5 little endian"/>+ <entry name="rgba5551" value="0x35314152" summary="16-bit RGBA 5551 format, [15:0] R:G:B:A 5:5:5:1 little endian"/>+ <entry name="bgra5551" value="0x35314142" summary="16-bit BGRA 5551 format, [15:0] B:G:R:A 5:5:5:1 little endian"/>+ <entry name="rgb565" value="0x36314752" summary="16-bit RGB 565 format, [15:0] R:G:B 5:6:5 little endian"/>+ <entry name="bgr565" value="0x36314742" summary="16-bit BGR 565 format, [15:0] B:G:R 5:6:5 little endian"/>+ <entry name="rgb888" value="0x34324752" summary="24-bit RGB format, [23:0] R:G:B little endian"/>+ <entry name="bgr888" value="0x34324742" summary="24-bit BGR format, [23:0] B:G:R little endian"/>+ <entry name="xbgr8888" value="0x34324258" summary="32-bit xBGR format, [31:0] x:B:G:R 8:8:8:8 little endian"/>+ <entry name="rgbx8888" value="0x34325852" summary="32-bit RGBx format, [31:0] R:G:B:x 8:8:8:8 little endian"/>+ <entry name="bgrx8888" value="0x34325842" summary="32-bit BGRx format, [31:0] B:G:R:x 8:8:8:8 little endian"/>+ <entry name="abgr8888" value="0x34324241" summary="32-bit ABGR format, [31:0] A:B:G:R 8:8:8:8 little endian"/>+ <entry name="rgba8888" value="0x34324152" summary="32-bit RGBA format, [31:0] R:G:B:A 8:8:8:8 little endian"/>+ <entry name="bgra8888" value="0x34324142" summary="32-bit BGRA format, [31:0] B:G:R:A 8:8:8:8 little endian"/>+ <entry name="xrgb2101010" value="0x30335258" summary="32-bit xRGB format, [31:0] x:R:G:B 2:10:10:10 little endian"/>+ <entry name="xbgr2101010" value="0x30334258" summary="32-bit xBGR format, [31:0] x:B:G:R 2:10:10:10 little endian"/>+ <entry name="rgbx1010102" value="0x30335852" summary="32-bit RGBx format, [31:0] R:G:B:x 10:10:10:2 little endian"/>+ <entry name="bgrx1010102" value="0x30335842" summary="32-bit BGRx format, [31:0] B:G:R:x 10:10:10:2 little endian"/>+ <entry name="argb2101010" value="0x30335241" summary="32-bit ARGB format, [31:0] A:R:G:B 2:10:10:10 little endian"/>+ <entry name="abgr2101010" value="0x30334241" summary="32-bit ABGR format, [31:0] A:B:G:R 2:10:10:10 little endian"/>+ <entry name="rgba1010102" value="0x30334152" summary="32-bit RGBA format, [31:0] R:G:B:A 10:10:10:2 little endian"/>+ <entry name="bgra1010102" value="0x30334142" summary="32-bit BGRA format, [31:0] B:G:R:A 10:10:10:2 little endian"/>+ <entry name="yuyv" value="0x56595559" summary="packed YCbCr format, [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian"/>+ <entry name="yvyu" value="0x55595659" summary="packed YCbCr format, [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian"/>+ <entry name="uyvy" value="0x59565955" summary="packed YCbCr format, [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian"/>+ <entry name="vyuy" value="0x59555956" summary="packed YCbCr format, [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian"/>+ <entry name="ayuv" value="0x56555941" summary="packed AYCbCr format, [31:0] A:Y:Cb:Cr 8:8:8:8 little endian"/>+ <entry name="nv12" value="0x3231564e" summary="2 plane YCbCr Cr:Cb format, 2x2 subsampled Cr:Cb plane"/>+ <entry name="nv21" value="0x3132564e" summary="2 plane YCbCr Cb:Cr format, 2x2 subsampled Cb:Cr plane"/>+ <entry name="nv16" value="0x3631564e" summary="2 plane YCbCr Cr:Cb format, 2x1 subsampled Cr:Cb plane"/>+ <entry name="nv61" value="0x3136564e" summary="2 plane YCbCr Cb:Cr format, 2x1 subsampled Cb:Cr plane"/>+ <entry name="yuv410" value="0x39565559" summary="3 plane YCbCr format, 4x4 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu410" value="0x39555659" summary="3 plane YCbCr format, 4x4 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv411" value="0x31315559" summary="3 plane YCbCr format, 4x1 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu411" value="0x31315659" summary="3 plane YCbCr format, 4x1 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv420" value="0x32315559" summary="3 plane YCbCr format, 2x2 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu420" value="0x32315659" summary="3 plane YCbCr format, 2x2 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv422" value="0x36315559" summary="3 plane YCbCr format, 2x1 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu422" value="0x36315659" summary="3 plane YCbCr format, 2x1 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv444" value="0x34325559" summary="3 plane YCbCr format, non-subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu444" value="0x34325659" summary="3 plane YCbCr format, non-subsampled Cr (1) and Cb (2) planes"/>+ <entry name="r8" value="0x20203852" summary="[7:0] R"/>+ <entry name="r16" value="0x20363152" summary="[15:0] R little endian"/>+ <entry name="rg88" value="0x38384752" summary="[15:0] R:G 8:8 little endian"/>+ <entry name="gr88" value="0x38385247" summary="[15:0] G:R 8:8 little endian"/>+ <entry name="rg1616" value="0x32334752" summary="[31:0] R:G 16:16 little endian"/>+ <entry name="gr1616" value="0x32335247" summary="[31:0] G:R 16:16 little endian"/>+ <entry name="xrgb16161616f" value="0x48345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>+ <entry name="xbgr16161616f" value="0x48344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>+ <entry name="argb16161616f" value="0x48345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>+ <entry name="abgr16161616f" value="0x48344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>+ <entry name="xyuv8888" value="0x56555958" summary="[31:0] X:Y:Cb:Cr 8:8:8:8 little endian"/>+ <entry name="vuy888" value="0x34325556" summary="[23:0] Cr:Cb:Y 8:8:8 little endian"/>+ <entry name="vuy101010" value="0x30335556" summary="Y followed by U then V, 10:10:10. Non-linear modifier only"/>+ <entry name="y210" value="0x30313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 10:6:10:6:10:6:10:6 little endian per 2 Y pixels"/>+ <entry name="y212" value="0x32313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 12:4:12:4:12:4:12:4 little endian per 2 Y pixels"/>+ <entry name="y216" value="0x36313259" summary="[63:0] Cr0:Y1:Cb0:Y0 16:16:16:16 little endian per 2 Y pixels"/>+ <entry name="y410" value="0x30313459" summary="[31:0] A:Cr:Y:Cb 2:10:10:10 little endian"/>+ <entry name="y412" value="0x32313459" summary="[63:0] A:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>+ <entry name="y416" value="0x36313459" summary="[63:0] A:Cr:Y:Cb 16:16:16:16 little endian"/>+ <entry name="xvyu2101010" value="0x30335658" summary="[31:0] X:Cr:Y:Cb 2:10:10:10 little endian"/>+ <entry name="xvyu12_16161616" value="0x36335658" summary="[63:0] X:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>+ <entry name="xvyu16161616" value="0x38345658" summary="[63:0] X:Cr:Y:Cb 16:16:16:16 little endian"/>+ <entry name="y0l0" value="0x304c3059" summary="[63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>+ <entry name="x0l0" value="0x304c3058" summary="[63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>+ <entry name="y0l2" value="0x324c3059" summary="[63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian"/>+ <entry name="x0l2" value="0x324c3058" summary="[63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian"/>+ <entry name="yuv420_8bit" value="0x38305559"/>+ <entry name="yuv420_10bit" value="0x30315559"/>+ <entry name="xrgb8888_a8" value="0x38415258"/>+ <entry name="xbgr8888_a8" value="0x38414258"/>+ <entry name="rgbx8888_a8" value="0x38415852"/>+ <entry name="bgrx8888_a8" value="0x38415842"/>+ <entry name="rgb888_a8" value="0x38413852"/>+ <entry name="bgr888_a8" value="0x38413842"/>+ <entry name="rgb565_a8" value="0x38413552"/>+ <entry name="bgr565_a8" value="0x38413542"/>+ <entry name="nv24" value="0x3432564e" summary="non-subsampled Cr:Cb plane"/>+ <entry name="nv42" value="0x3234564e" summary="non-subsampled Cb:Cr plane"/>+ <entry name="p210" value="0x30313250" summary="2x1 subsampled Cr:Cb plane, 10 bit per channel"/>+ <entry name="p010" value="0x30313050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel"/>+ <entry name="p012" value="0x32313050" summary="2x2 subsampled Cr:Cb plane 12 bits per channel"/>+ <entry name="p016" value="0x36313050" summary="2x2 subsampled Cr:Cb plane 16 bits per channel"/>+ <entry name="axbxgxrx106106106106" value="0x30314241" summary="[63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian"/>+ <entry name="nv15" value="0x3531564e" summary="2x2 subsampled Cr:Cb plane"/>+ <entry name="q410" value="0x30313451"/>+ <entry name="q401" value="0x31303451"/>+ <entry name="xrgb16161616" value="0x38345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>+ <entry name="xbgr16161616" value="0x38344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>+ <entry name="argb16161616" value="0x38345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>+ <entry name="abgr16161616" value="0x38344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>+ </enum>++ <request name="create_pool">+ <description summary="create a shm pool">+ Create a new wl_shm_pool object.++ The pool can be used to create shared memory based buffer+ objects. The server will mmap size bytes of the passed file+ descriptor, to use as backing memory for the pool.+ </description>+ <arg name="id" type="new_id" interface="wl_shm_pool" summary="pool to create"/>+ <arg name="fd" type="fd" summary="file descriptor for the pool"/>+ <arg name="size" type="int" summary="pool size, in bytes"/>+ </request>++ <event name="format">+ <description summary="pixel format description">+ Informs the client about a valid pixel format that+ can be used for buffers. Known formats include+ argb8888 and xrgb8888.+ </description>+ <arg name="format" type="uint" enum="format" summary="buffer pixel format"/>+ </event>+ </interface>++ <interface name="wl_buffer" version="1">+ <description summary="content for a wl_surface">+ A buffer provides the content for a wl_surface. Buffers are+ created through factory interfaces such as wl_shm, wp_linux_buffer_params+ (from the linux-dmabuf protocol extension) or similar. It has a width and+ a height and can be attached to a wl_surface, but the mechanism by which a+ client provides and updates the contents is defined by the buffer factory+ interface.++ If the buffer uses a format that has an alpha channel, the alpha channel+ is assumed to be premultiplied in the color channels unless otherwise+ specified.++ Note, because wl_buffer objects are created from multiple independent+ factory interfaces, the wl_buffer interface is frozen at version 1.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy a buffer">+ Destroy a buffer. If and how you need to release the backing+ storage is defined by the buffer factory interface.++ For possible side-effects to a surface, see wl_surface.attach.+ </description>+ </request>++ <event name="release">+ <description summary="compositor releases buffer">+ Sent when this wl_buffer is no longer used by the compositor.+ The client is now free to reuse or destroy this buffer and its+ backing storage.++ If a client receives a release event before the frame callback+ requested in the same wl_surface.commit that attaches this+ wl_buffer to a surface, then the client is immediately free to+ reuse the buffer and its backing storage, and does not need a+ second buffer for the next surface content update. Typically+ this is possible, when the compositor maintains a copy of the+ wl_surface contents, e.g. as a GL texture. This is an important+ optimization for GL(ES) compositors with wl_shm clients.+ </description>+ </event>+ </interface>++ <interface name="wl_data_offer" version="3">+ <description summary="offer to transfer data">+ A wl_data_offer represents a piece of data offered for transfer+ by another client (the source client). It is used by the+ copy-and-paste and drag-and-drop mechanisms. The offer+ describes the different mime types that the data can be+ converted to and provides the mechanism for transferring the+ data directly from the source client.+ </description>++ <enum name="error">+ <entry name="invalid_finish" value="0"+ summary="finish request was called untimely"/>+ <entry name="invalid_action_mask" value="1"+ summary="action mask contains invalid values"/>+ <entry name="invalid_action" value="2"+ summary="action argument has an invalid value"/>+ <entry name="invalid_offer" value="3"+ summary="offer doesn't accept this request"/>+ </enum>++ <request name="accept">+ <description summary="accept one of the offered mime types">+ Indicate that the client can accept the given mime type, or+ NULL for not accepted.++ For objects of version 2 or older, this request is used by the+ client to give feedback whether the client can receive the given+ mime type, or NULL if none is accepted; the feedback does not+ determine whether the drag-and-drop operation succeeds or not.++ For objects of version 3 or newer, this request determines the+ final result of the drag-and-drop operation. If the end result+ is that no mime types were accepted, the drag-and-drop operation+ will be cancelled and the corresponding drag source will receive+ wl_data_source.cancelled. Clients may still use this event in+ conjunction with wl_data_source.action for feedback.+ </description>+ <arg name="serial" type="uint" summary="serial number of the accept request"/>+ <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the client"/>+ </request>++ <request name="receive">+ <description summary="request that the data is transferred">+ To transfer the offered data, the client issues this request+ and indicates the mime type it wants to receive. The transfer+ happens through the passed file descriptor (typically created+ with the pipe system call). The source client writes the data+ in the mime type representation requested and then closes the+ file descriptor.++ The receiving client reads from the read end of the pipe until+ EOF and then closes its end, at which point the transfer is+ complete.++ This request may happen multiple times for different mime types,+ both before and after wl_data_device.drop. Drag-and-drop destination+ clients may preemptively fetch data or examine it more closely to+ determine acceptance.+ </description>+ <arg name="mime_type" type="string" summary="mime type desired by receiver"/>+ <arg name="fd" type="fd" summary="file descriptor for data transfer"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy data offer">+ Destroy the data offer.+ </description>+ </request>++ <event name="offer">+ <description summary="advertise offered mime type">+ Sent immediately after creating the wl_data_offer object. One+ event per offered mime type.+ </description>+ <arg name="mime_type" type="string" summary="offered mime type"/>+ </event>++ <!-- Version 3 additions -->++ <request name="finish" since="3">+ <description summary="the offer will no longer be used">+ Notifies the compositor that the drag destination successfully+ finished the drag-and-drop operation.++ Upon receiving this request, the compositor will emit+ wl_data_source.dnd_finished on the drag source client.++ It is a client error to perform other requests than+ wl_data_offer.destroy after this one. It is also an error to perform+ this request after a NULL mime type has been set in+ wl_data_offer.accept or no action was received through+ wl_data_offer.action.++ If wl_data_offer.finish request is received for a non drag and drop+ operation, the invalid_finish protocol error is raised.+ </description>+ </request>++ <request name="set_actions" since="3">+ <description summary="set the available/preferred drag-and-drop actions">+ Sets the actions that the destination side client supports for+ this operation. This request may trigger the emission of+ wl_data_source.action and wl_data_offer.action events if the compositor+ needs to change the selected action.++ This request can be called multiple times throughout the+ drag-and-drop operation, typically in response to wl_data_device.enter+ or wl_data_device.motion events.++ This request determines the final result of the drag-and-drop+ operation. If the end result is that no action is accepted,+ the drag source will receive wl_data_source.cancelled.++ The dnd_actions argument must contain only values expressed in the+ wl_data_device_manager.dnd_actions enum, and the preferred_action+ argument must only contain one of those values set, otherwise it+ will result in a protocol error.++ While managing an "ask" action, the destination drag-and-drop client+ may perform further wl_data_offer.receive requests, and is expected+ to perform one last wl_data_offer.set_actions request with a preferred+ action other than "ask" (and optionally wl_data_offer.accept) before+ requesting wl_data_offer.finish, in order to convey the action selected+ by the user. If the preferred action is not in the+ wl_data_offer.source_actions mask, an error will be raised.++ If the "ask" action is dismissed (e.g. user cancellation), the client+ is expected to perform wl_data_offer.destroy right away.++ This request can only be made on drag-and-drop offers, a protocol error+ will be raised otherwise.+ </description>+ <arg name="dnd_actions" type="uint" summary="actions supported by the destination client"+ enum="wl_data_device_manager.dnd_action"/>+ <arg name="preferred_action" type="uint" summary="action preferred by the destination client"+ enum="wl_data_device_manager.dnd_action"/>+ </request>++ <event name="source_actions" since="3">+ <description summary="notify the source-side available actions">+ This event indicates the actions offered by the data source. It+ will be sent immediately after creating the wl_data_offer object,+ or anytime the source side changes its offered actions through+ wl_data_source.set_actions.+ </description>+ <arg name="source_actions" type="uint" summary="actions offered by the data source"+ enum="wl_data_device_manager.dnd_action"/>+ </event>++ <event name="action" since="3">+ <description summary="notify the selected action">+ This event indicates the action selected by the compositor after+ matching the source/destination side actions. Only one action (or+ none) will be offered here.++ This event can be emitted multiple times during the drag-and-drop+ operation in response to destination side action changes through+ wl_data_offer.set_actions.++ This event will no longer be emitted after wl_data_device.drop+ happened on the drag-and-drop destination, the client must+ honor the last action received, or the last preferred one set+ through wl_data_offer.set_actions when handling an "ask" action.++ Compositors may also change the selected action on the fly, mainly+ in response to keyboard modifier changes during the drag-and-drop+ operation.++ The most recent action received is always the valid one. Prior to+ receiving wl_data_device.drop, the chosen action may change (e.g.+ due to keyboard modifiers being pressed). At the time of receiving+ wl_data_device.drop the drag-and-drop destination must honor the+ last action received.++ Action changes may still happen after wl_data_device.drop,+ especially on "ask" actions, where the drag-and-drop destination+ may choose another action afterwards. Action changes happening+ at this stage are always the result of inter-client negotiation, the+ compositor shall no longer be able to induce a different action.++ Upon "ask" actions, it is expected that the drag-and-drop destination+ may potentially choose a different action and/or mime type,+ based on wl_data_offer.source_actions and finally chosen by the+ user (e.g. popping up a menu with the available options). The+ final wl_data_offer.set_actions and wl_data_offer.accept requests+ must happen before the call to wl_data_offer.finish.+ </description>+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"+ enum="wl_data_device_manager.dnd_action"/>+ </event>+ </interface>++ <interface name="wl_data_source" version="3">+ <description summary="offer to transfer data">+ The wl_data_source object is the source side of a wl_data_offer.+ It is created by the source client in a data transfer and+ provides a way to describe the offered data and a way to respond+ to requests to transfer the data.+ </description>++ <enum name="error">+ <entry name="invalid_action_mask" value="0"+ summary="action mask contains invalid values"/>+ <entry name="invalid_source" value="1"+ summary="source doesn't accept this request"/>+ </enum>++ <request name="offer">+ <description summary="add an offered mime type">+ This request adds a mime type to the set of mime types+ advertised to targets. Can be called several times to offer+ multiple types.+ </description>+ <arg name="mime_type" type="string" summary="mime type offered by the data source"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy the data source">+ Destroy the data source.+ </description>+ </request>++ <event name="target">+ <description summary="a target accepts an offered mime type">+ Sent when a target accepts pointer_focus or motion events. If+ a target does not accept any of the offered types, type is NULL.++ Used for feedback during drag-and-drop.+ </description>+ <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the target"/>+ </event>++ <event name="send">+ <description summary="send the data">+ Request for data from the client. Send the data as the+ specified mime type over the passed file descriptor, then+ close it.+ </description>+ <arg name="mime_type" type="string" summary="mime type for the data"/>+ <arg name="fd" type="fd" summary="file descriptor for the data"/>+ </event>++ <event name="cancelled">+ <description summary="selection was cancelled">+ This data source is no longer valid. There are several reasons why+ this could happen:++ - The data source has been replaced by another data source.+ - The drag-and-drop operation was performed, but the drop destination+ did not accept any of the mime types offered through+ wl_data_source.target.+ - The drag-and-drop operation was performed, but the drop destination+ did not select any of the actions present in the mask offered through+ wl_data_source.action.+ - The drag-and-drop operation was performed but didn't happen over a+ surface.+ - The compositor cancelled the drag-and-drop operation (e.g. compositor+ dependent timeouts to avoid stale drag-and-drop transfers).++ The client should clean up and destroy this data source.++ For objects of version 2 or older, wl_data_source.cancelled will+ only be emitted if the data source was replaced by another data+ source.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="set_actions" since="3">+ <description summary="set the available drag-and-drop actions">+ Sets the actions that the source side client supports for this+ operation. This request may trigger wl_data_source.action and+ wl_data_offer.action events if the compositor needs to change the+ selected action.++ The dnd_actions argument must contain only values expressed in the+ wl_data_device_manager.dnd_actions enum, otherwise it will result+ in a protocol error.++ This request must be made once only, and can only be made on sources+ used in drag-and-drop, so it must be performed before+ wl_data_device.start_drag. Attempting to use the source other than+ for drag-and-drop will raise a protocol error.+ </description>+ <arg name="dnd_actions" type="uint" summary="actions supported by the data source"+ enum="wl_data_device_manager.dnd_action"/>+ </request>++ <event name="dnd_drop_performed" since="3">+ <description summary="the drag-and-drop operation physically finished">+ The user performed the drop action. This event does not indicate+ acceptance, wl_data_source.cancelled may still be emitted afterwards+ if the drop destination does not accept any mime type.++ However, this event might however not be received if the compositor+ cancelled the drag-and-drop operation before this event could happen.++ Note that the data_source may still be used in the future and should+ not be destroyed here.+ </description>+ </event>++ <event name="dnd_finished" since="3">+ <description summary="the drag-and-drop operation concluded">+ The drop destination finished interoperating with this data+ source, so the client is now free to destroy this data source and+ free all associated data.++ If the action used to perform the operation was "move", the+ source can now delete the transferred data.+ </description>+ </event>++ <event name="action" since="3">+ <description summary="notify the selected action">+ This event indicates the action selected by the compositor after+ matching the source/destination side actions. Only one action (or+ none) will be offered here.++ This event can be emitted multiple times during the drag-and-drop+ operation, mainly in response to destination side changes through+ wl_data_offer.set_actions, and as the data device enters/leaves+ surfaces.++ It is only possible to receive this event after+ wl_data_source.dnd_drop_performed if the drag-and-drop operation+ ended in an "ask" action, in which case the final wl_data_source.action+ event will happen immediately before wl_data_source.dnd_finished.++ Compositors may also change the selected action on the fly, mainly+ in response to keyboard modifier changes during the drag-and-drop+ operation.++ The most recent action received is always the valid one. The chosen+ action may change alongside negotiation (e.g. an "ask" action can turn+ into a "move" operation), so the effects of the final action must+ always be applied in wl_data_offer.dnd_finished.++ Clients can trigger cursor surface changes from this point, so+ they reflect the current action.+ </description>+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"+ enum="wl_data_device_manager.dnd_action"/>+ </event>+ </interface>++ <interface name="wl_data_device" version="3">+ <description summary="data transfer device">+ There is one wl_data_device per seat which can be obtained+ from the global wl_data_device_manager singleton.++ A wl_data_device provides access to inter-client data transfer+ mechanisms such as copy-and-paste and drag-and-drop.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="start_drag">+ <description summary="start drag-and-drop operation">+ This request asks the compositor to start a drag-and-drop+ operation on behalf of the client.++ The source argument is the data source that provides the data+ for the eventual data transfer. If source is NULL, enter, leave+ and motion events are sent only to the client that initiated the+ drag and the client is expected to handle the data passing+ internally. If source is destroyed, the drag-and-drop session will be+ cancelled.++ The origin surface is the surface where the drag originates and+ the client must have an active implicit grab that matches the+ serial.++ The icon surface is an optional (can be NULL) surface that+ provides an icon to be moved around with the cursor. Initially,+ the top-left corner of the icon surface is placed at the cursor+ hotspot, but subsequent wl_surface.attach request can move the+ relative position. Attach requests must be confirmed with+ wl_surface.commit as usual. The icon surface is given the role of+ a drag-and-drop icon. If the icon surface already has another role,+ it raises a protocol error.++ The input region is ignored for wl_surfaces with the role of a+ drag-and-drop icon.+ </description>+ <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the eventual transfer"/>+ <arg name="origin" type="object" interface="wl_surface" summary="surface where the drag originates"/>+ <arg name="icon" type="object" interface="wl_surface" allow-null="true" summary="drag-and-drop icon surface"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the origin"/>+ </request>++ <request name="set_selection">+ <description summary="copy data to the selection">+ This request asks the compositor to set the selection+ to the data from the source on behalf of the client.++ To unset the selection, set the source to NULL.+ </description>+ <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the selection"/>+ <arg name="serial" type="uint" summary="serial number of the event that triggered this request"/>+ </request>++ <event name="data_offer">+ <description summary="introduce a new wl_data_offer">+ The data_offer event introduces a new wl_data_offer object,+ which will subsequently be used in either the+ data_device.enter event (for drag-and-drop) or the+ data_device.selection event (for selections). Immediately+ following the data_device.data_offer event, the new data_offer+ object will send out data_offer.offer events to describe the+ mime types it offers.+ </description>+ <arg name="id" type="new_id" interface="wl_data_offer" summary="the new data_offer object"/>+ </event>++ <event name="enter">+ <description summary="initiate drag-and-drop session">+ This event is sent when an active drag-and-drop pointer enters+ a surface owned by the client. The position of the pointer at+ enter time is provided by the x and y arguments, in surface-local+ coordinates.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="client surface entered"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"+ summary="source data_offer object"/>+ </event>++ <event name="leave">+ <description summary="end drag-and-drop session">+ This event is sent when the drag-and-drop pointer leaves the+ surface and the session ends. The client must destroy the+ wl_data_offer introduced at enter time at this point.+ </description>+ </event>++ <event name="motion">+ <description summary="drag-and-drop session motion">+ This event is sent when the drag-and-drop pointer moves within+ the currently focused surface. The new position of the pointer+ is provided by the x and y arguments, in surface-local+ coordinates.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="drop">+ <description summary="end drag-and-drop session successfully">+ The event is sent when a drag-and-drop operation is ended+ because the implicit grab is removed.++ The drag-and-drop destination is expected to honor the last action+ received through wl_data_offer.action, if the resulting action is+ "copy" or "move", the destination can still perform+ wl_data_offer.receive requests, and is expected to end all+ transfers with a wl_data_offer.finish request.++ If the resulting action is "ask", the action will not be considered+ final. The drag-and-drop destination is expected to perform one last+ wl_data_offer.set_actions request, or wl_data_offer.destroy in order+ to cancel the operation.+ </description>+ </event>++ <event name="selection">+ <description summary="advertise new selection">+ The selection event is sent out to notify the client of a new+ wl_data_offer for the selection for this device. The+ data_device.data_offer and the data_offer.offer events are+ sent out immediately before this event to introduce the data+ offer object. The selection event is sent to a client+ immediately before receiving keyboard focus and when a new+ selection is set while the client has keyboard focus. The+ data_offer is valid until a new data_offer or NULL is received+ or until the client loses keyboard focus. Switching surface with+ keyboard focus within the same client doesn't mean a new selection+ will be sent. The client must destroy the previous selection+ data_offer, if any, upon receiving this event.+ </description>+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"+ summary="selection data_offer object"/>+ </event>++ <!-- Version 2 additions -->++ <request name="release" type="destructor" since="2">+ <description summary="destroy data device">+ This request destroys the data device.+ </description>+ </request>+ </interface>++ <interface name="wl_data_device_manager" version="3">+ <description summary="data transfer interface">+ The wl_data_device_manager is a singleton global object that+ provides access to inter-client data transfer mechanisms such as+ copy-and-paste and drag-and-drop. These mechanisms are tied to+ a wl_seat and this interface lets a client get a wl_data_device+ corresponding to a wl_seat.++ Depending on the version bound, the objects created from the bound+ wl_data_device_manager object will have different requirements for+ functioning properly. See wl_data_source.set_actions,+ wl_data_offer.accept and wl_data_offer.finish for details.+ </description>++ <request name="create_data_source">+ <description summary="create a new data source">+ Create a new data source.+ </description>+ <arg name="id" type="new_id" interface="wl_data_source" summary="data source to create"/>+ </request>++ <request name="get_data_device">+ <description summary="create a new data device">+ Create a new data device for a given seat.+ </description>+ <arg name="id" type="new_id" interface="wl_data_device" summary="data device to create"/>+ <arg name="seat" type="object" interface="wl_seat" summary="seat associated with the data device"/>+ </request>++ <!-- Version 3 additions -->++ <enum name="dnd_action" bitfield="true" since="3">+ <description summary="drag and drop actions">+ This is a bitmask of the available/preferred actions in a+ drag-and-drop operation.++ In the compositor, the selected action is a result of matching the+ actions offered by the source and destination sides. "action" events+ with a "none" action will be sent to both source and destination if+ there is no match. All further checks will effectively happen on+ (source actions ∩ destination actions).++ In addition, compositors may also pick different actions in+ reaction to key modifiers being pressed. One common design that+ is used in major toolkits (and the behavior recommended for+ compositors) is:++ - If no modifiers are pressed, the first match (in bit order)+ will be used.+ - Pressing Shift selects "move", if enabled in the mask.+ - Pressing Control selects "copy", if enabled in the mask.++ Behavior beyond that is considered implementation-dependent.+ Compositors may for example bind other modifiers (like Alt/Meta)+ or drags initiated with other buttons than BTN_LEFT to specific+ actions (e.g. "ask").+ </description>+ <entry name="none" value="0" summary="no action"/>+ <entry name="copy" value="1" summary="copy action"/>+ <entry name="move" value="2" summary="move action"/>+ <entry name="ask" value="4" summary="ask action"/>+ </enum>+ </interface>++ <interface name="wl_shell" version="1">+ <description summary="create desktop-style surfaces">+ This interface is implemented by servers that provide+ desktop-style user interfaces.++ It allows clients to associate a wl_shell_surface with+ a basic surface.++ Note! This protocol is deprecated and not intended for production use.+ For desktop-style user interfaces, use xdg_shell. Compositors and clients+ should not implement this interface.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="get_shell_surface">+ <description summary="create a shell surface from a surface">+ Create a shell surface for an existing surface. This gives+ the wl_surface the role of a shell surface. If the wl_surface+ already has another role, it raises a protocol error.++ Only one shell surface can be associated with a given surface.+ </description>+ <arg name="id" type="new_id" interface="wl_shell_surface" summary="shell surface to create"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface to be given the shell surface role"/>+ </request>+ </interface>++ <interface name="wl_shell_surface" version="1">+ <description summary="desktop-style metadata interface">+ An interface that may be implemented by a wl_surface, for+ implementations that provide a desktop-style user interface.++ It provides requests to treat surfaces like toplevel, fullscreen+ or popup windows, move, resize or maximize them, associate+ metadata like title and class, etc.++ On the server side the object is automatically destroyed when+ the related wl_surface is destroyed. On the client side,+ wl_shell_surface_destroy() must be called before destroying+ the wl_surface object.+ </description>++ <request name="pong">+ <description summary="respond to a ping event">+ A client must respond to a ping event with a pong request or+ the client may be deemed unresponsive.+ </description>+ <arg name="serial" type="uint" summary="serial number of the ping event"/>+ </request>++ <request name="move">+ <description summary="start an interactive move">+ Start a pointer-driven move of the surface.++ This request must be used in response to a button press event.+ The server may ignore move requests depending on the state of+ the surface (e.g. fullscreen or maximized).+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ </request>++ <enum name="resize" bitfield="true">+ <description summary="edge values for resizing">+ These values are used to indicate which edge of a surface+ is being dragged in a resize operation. The server may+ use this information to adapt its behavior, e.g. choose+ an appropriate cursor image.+ </description>+ <entry name="none" value="0" summary="no edge"/>+ <entry name="top" value="1" summary="top edge"/>+ <entry name="bottom" value="2" summary="bottom edge"/>+ <entry name="left" value="4" summary="left edge"/>+ <entry name="top_left" value="5" summary="top and left edges"/>+ <entry name="bottom_left" value="6" summary="bottom and left edges"/>+ <entry name="right" value="8" summary="right edge"/>+ <entry name="top_right" value="9" summary="top and right edges"/>+ <entry name="bottom_right" value="10" summary="bottom and right edges"/>+ </enum>++ <request name="resize">+ <description summary="start an interactive resize">+ Start a pointer-driven resizing of the surface.++ This request must be used in response to a button press event.+ The server may ignore resize requests depending on the state of+ the surface (e.g. fullscreen or maximized).+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ <arg name="edges" type="uint" enum="resize" summary="which edge or corner is being dragged"/>+ </request>++ <request name="set_toplevel">+ <description summary="make the surface a toplevel surface">+ Map the surface as a toplevel surface.++ A toplevel surface is not fullscreen, maximized or transient.+ </description>+ </request>++ <enum name="transient" bitfield="true">+ <description summary="details of transient behaviour">+ These flags specify details of the expected behaviour+ of transient surfaces. Used in the set_transient request.+ </description>+ <entry name="inactive" value="0x1" summary="do not set keyboard focus"/>+ </enum>++ <request name="set_transient">+ <description summary="make the surface a transient surface">+ Map the surface relative to an existing surface.++ The x and y arguments specify the location of the upper left+ corner of the surface relative to the upper left corner of the+ parent surface, in surface-local coordinates.++ The flags argument controls details of the transient behaviour.+ </description>+ <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>+ </request>++ <enum name="fullscreen_method">+ <description summary="different method to set the surface fullscreen">+ Hints to indicate to the compositor how to deal with a conflict+ between the dimensions of the surface and the dimensions of the+ output. The compositor is free to ignore this parameter.+ </description>+ <entry name="default" value="0" summary="no preference, apply default policy"/>+ <entry name="scale" value="1" summary="scale, preserve the surface's aspect ratio and center on output"/>+ <entry name="driver" value="2" summary="switch output mode to the smallest mode that can fit the surface, add black borders to compensate size mismatch"/>+ <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>+ </enum>++ <request name="set_fullscreen">+ <description summary="make the surface a fullscreen surface">+ Map the surface as a fullscreen surface.++ If an output parameter is given then the surface will be made+ fullscreen on that output. If the client does not specify the+ output then the compositor will apply its policy - usually+ choosing the output on which the surface has the biggest surface+ area.++ The client may specify a method to resolve a size conflict+ between the output size and the surface size - this is provided+ through the method parameter.++ The framerate parameter is used only when the method is set+ to "driver", to indicate the preferred framerate. A value of 0+ indicates that the client does not care about framerate. The+ framerate is specified in mHz, that is framerate of 60000 is 60Hz.++ A method of "scale" or "driver" implies a scaling operation of+ the surface, either via a direct scaling operation or a change of+ the output mode. This will override any kind of output scaling, so+ that mapping a surface with a buffer size equal to the mode can+ fill the screen independent of buffer_scale.++ A method of "fill" means we don't scale up the buffer, however+ any output scale is applied. This means that you may run into+ an edge case where the application maps a buffer with the same+ size of the output mode but buffer_scale 1 (thus making a+ surface larger than the output). In this case it is allowed to+ downscale the results to fit the screen.++ The compositor must reply to this request with a configure event+ with the dimensions for the output on which the surface will+ be made fullscreen.+ </description>+ <arg name="method" type="uint" enum="fullscreen_method" summary="method for resolving size conflict"/>+ <arg name="framerate" type="uint" summary="framerate in mHz"/>+ <arg name="output" type="object" interface="wl_output" allow-null="true"+ summary="output on which the surface is to be fullscreen"/>+ </request>++ <request name="set_popup">+ <description summary="make the surface a popup surface">+ Map the surface as a popup.++ A popup surface is a transient surface with an added pointer+ grab.++ An existing implicit grab will be changed to owner-events mode,+ and the popup grab will continue after the implicit grab ends+ (i.e. releasing the mouse button does not cause the popup to+ be unmapped).++ The popup grab continues until the window is destroyed or a+ mouse button is pressed in any other client's window. A click+ in any of the client's surfaces is reported as normal, however,+ clicks in other clients' surfaces will be discarded and trigger+ the callback.++ The x and y arguments specify the location of the upper left+ corner of the surface relative to the upper left corner of the+ parent surface, in surface-local coordinates.+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>+ </request>++ <request name="set_maximized">+ <description summary="make the surface a maximized surface">+ Map the surface as a maximized surface.++ If an output parameter is given then the surface will be+ maximized on that output. If the client does not specify the+ output then the compositor will apply its policy - usually+ choosing the output on which the surface has the biggest surface+ area.++ The compositor will reply with a configure event telling+ the expected new surface size. The operation is completed+ on the next buffer attach to this surface.++ A maximized surface typically fills the entire output it is+ bound to, except for desktop elements such as panels. This is+ the main difference between a maximized shell surface and a+ fullscreen shell surface.++ The details depend on the compositor implementation.+ </description>+ <arg name="output" type="object" interface="wl_output" allow-null="true"+ summary="output on which the surface is to be maximized"/>+ </request>++ <request name="set_title">+ <description summary="set surface title">+ Set a short title for the surface.++ This string may be used to identify the surface in a task bar,+ window list, or other user interface elements provided by the+ compositor.++ The string must be encoded in UTF-8.+ </description>+ <arg name="title" type="string" summary="surface title"/>+ </request>++ <request name="set_class">+ <description summary="set surface class">+ Set a class for the surface.++ The surface class identifies the general class of applications+ to which the surface belongs. A common convention is to use the+ file name (or the full path if it is a non-standard location) of+ the application's .desktop file as the class.+ </description>+ <arg name="class_" type="string" summary="surface class"/>+ </request>++ <event name="ping">+ <description summary="ping client">+ Ping a client to check if it is receiving events and sending+ requests. A client is expected to reply with a pong request.+ </description>+ <arg name="serial" type="uint" summary="serial number of the ping"/>+ </event>++ <event name="configure">+ <description summary="suggest resize">+ The configure event asks the client to resize its surface.++ The size is a hint, in the sense that the client is free to+ ignore it if it doesn't resize, pick a smaller size (to+ satisfy aspect ratio or resize in steps of NxM pixels).++ The edges parameter provides a hint about how the surface+ was resized. The client may use this information to decide+ how to adjust its content to the new size (e.g. a scrolling+ area might adjust its content position to leave the viewable+ content unmoved).++ The client is free to dismiss all but the last configure+ event it received.++ The width and height arguments specify the size of the window+ in surface-local coordinates.+ </description>+ <arg name="edges" type="uint" enum="resize" summary="how the surface was resized"/>+ <arg name="width" type="int" summary="new width of the surface"/>+ <arg name="height" type="int" summary="new height of the surface"/>+ </event>++ <event name="popup_done">+ <description summary="popup interaction is done">+ The popup_done event is sent out when a popup grab is broken,+ that is, when the user clicks a surface that doesn't belong+ to the client owning the popup surface.+ </description>+ </event>+ </interface>++ <interface name="wl_surface" version="6">+ <description summary="an onscreen surface">+ A surface is a rectangular area that may be displayed on zero+ or more outputs, and shown any number of times at the compositor's+ discretion. They can present wl_buffers, receive user input, and+ define a local coordinate system.++ The size of a surface (and relative positions on it) is described+ in surface-local coordinates, which may differ from the buffer+ coordinates of the pixel content, in case a buffer_transform+ or a buffer_scale is used.++ A surface without a "role" is fairly useless: a compositor does+ not know where, when or how to present it. The role is the+ purpose of a wl_surface. Examples of roles are a cursor for a+ pointer (as set by wl_pointer.set_cursor), a drag icon+ (wl_data_device.start_drag), a sub-surface+ (wl_subcompositor.get_subsurface), and a window as defined by a+ shell protocol (e.g. wl_shell.get_shell_surface).++ A surface can have only one role at a time. Initially a+ wl_surface does not have a role. Once a wl_surface is given a+ role, it is set permanently for the whole lifetime of the+ wl_surface object. Giving the current role again is allowed,+ unless explicitly forbidden by the relevant interface+ specification.++ Surface roles are given by requests in other interfaces such as+ wl_pointer.set_cursor. The request should explicitly mention+ that this request gives a role to a wl_surface. Often, this+ request also creates a new protocol object that represents the+ role and adds additional functionality to wl_surface. When a+ client wants to destroy a wl_surface, they must destroy this role+ object before the wl_surface, otherwise a defunct_role_object error is+ sent.++ Destroying the role object does not remove the role from the+ wl_surface, but it may stop the wl_surface from "playing the role".+ For instance, if a wl_subsurface object is destroyed, the wl_surface+ it was created for will be unmapped and forget its position and+ z-order. It is allowed to create a wl_subsurface for the same+ wl_surface again, but it is not allowed to use the wl_surface as+ a cursor (cursor is a different role than sub-surface, and role+ switching is not allowed).+ </description>++ <enum name="error">+ <description summary="wl_surface error values">+ These errors can be emitted in response to wl_surface requests.+ </description>+ <entry name="invalid_scale" value="0" summary="buffer scale value is invalid"/>+ <entry name="invalid_transform" value="1" summary="buffer transform value is invalid"/>+ <entry name="invalid_size" value="2" summary="buffer size is invalid"/>+ <entry name="invalid_offset" value="3" summary="buffer offset is invalid"/>+ <entry name="defunct_role_object" value="4"+ summary="surface was destroyed before its role object"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="delete surface">+ Deletes the surface and invalidates its object ID.+ </description>+ </request>++ <request name="attach">+ <description summary="set the surface contents">+ Set a buffer as the content of this surface.++ The new size of the surface is calculated based on the buffer+ size transformed by the inverse buffer_transform and the+ inverse buffer_scale. This means that at commit time the supplied+ buffer size must be an integer multiple of the buffer_scale. If+ that's not the case, an invalid_size error is sent.++ The x and y arguments specify the location of the new pending+ buffer's upper left corner, relative to the current buffer's upper+ left corner, in surface-local coordinates. In other words, the+ x and y, combined with the new surface size define in which+ directions the surface's size changes. Setting anything other than 0+ as x and y arguments is discouraged, and should instead be replaced+ with using the separate wl_surface.offset request.++ When the bound wl_surface version is 5 or higher, passing any+ non-zero x or y is a protocol violation, and will result in an+ 'invalid_offset' error being raised. The x and y arguments are ignored+ and do not change the pending state. To achieve equivalent semantics,+ use wl_surface.offset.++ Surface contents are double-buffered state, see wl_surface.commit.++ The initial surface contents are void; there is no content.+ wl_surface.attach assigns the given wl_buffer as the pending+ wl_buffer. wl_surface.commit makes the pending wl_buffer the new+ surface contents, and the size of the surface becomes the size+ calculated from the wl_buffer, as described above. After commit,+ there is no pending buffer until the next attach.++ Committing a pending wl_buffer allows the compositor to read the+ pixels in the wl_buffer. The compositor may access the pixels at+ any time after the wl_surface.commit request. When the compositor+ will not access the pixels anymore, it will send the+ wl_buffer.release event. Only after receiving wl_buffer.release,+ the client may reuse the wl_buffer. A wl_buffer that has been+ attached and then replaced by another attach instead of committed+ will not receive a release event, and is not used by the+ compositor.++ If a pending wl_buffer has been committed to more than one wl_surface,+ the delivery of wl_buffer.release events becomes undefined. A well+ behaved client should not rely on wl_buffer.release events in this+ case. Alternatively, a client could create multiple wl_buffer objects+ from the same backing storage or use wp_linux_buffer_release.++ Destroying the wl_buffer after wl_buffer.release does not change+ the surface contents. Destroying the wl_buffer before wl_buffer.release+ is allowed as long as the underlying buffer storage isn't re-used (this+ can happen e.g. on client process termination). However, if the client+ destroys the wl_buffer before receiving the wl_buffer.release event and+ mutates the underlying buffer storage, the surface contents become+ undefined immediately.++ If wl_surface.attach is sent with a NULL wl_buffer, the+ following wl_surface.commit will remove the surface content.+ </description>+ <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"+ summary="buffer of surface contents"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ </request>++ <request name="damage">+ <description summary="mark part of the surface damaged">+ This request is used to describe the regions where the pending+ buffer is different from the current surface contents, and where+ the surface therefore needs to be repainted. The compositor+ ignores the parts of the damage that fall outside of the surface.++ Damage is double-buffered state, see wl_surface.commit.++ The damage rectangle is specified in surface-local coordinates,+ where x and y specify the upper left corner of the damage rectangle.++ The initial value for pending damage is empty: no damage.+ wl_surface.damage adds pending damage: the new pending damage+ is the union of old pending damage and the given rectangle.++ wl_surface.commit assigns pending damage as the current damage,+ and clears pending damage. The server will clear the current+ damage as it repaints the surface.++ Note! New clients should not use this request. Instead damage can be+ posted with wl_surface.damage_buffer which uses buffer coordinates+ instead of surface coordinates.+ </description>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="width" type="int" summary="width of damage rectangle"/>+ <arg name="height" type="int" summary="height of damage rectangle"/>+ </request>++ <request name="frame">+ <description summary="request a frame throttling hint">+ Request a notification when it is a good time to start drawing a new+ frame, by creating a frame callback. This is useful for throttling+ redrawing operations, and driving animations.++ When a client is animating on a wl_surface, it can use the 'frame'+ request to get notified when it is a good time to draw and commit the+ next frame of animation. If the client commits an update earlier than+ that, it is likely that some updates will not make it to the display,+ and the client is wasting resources by drawing too often.++ The frame request will take effect on the next wl_surface.commit.+ The notification will only be posted for one frame unless+ requested again. For a wl_surface, the notifications are posted in+ the order the frame requests were committed.++ The server must send the notifications so that a client+ will not send excessive updates, while still allowing+ the highest possible update rate for clients that wait for the reply+ before drawing again. The server should give some time for the client+ to draw and commit after sending the frame callback events to let it+ hit the next output refresh.++ A server should avoid signaling the frame callbacks if the+ surface is not visible in any way, e.g. the surface is off-screen,+ or completely obscured by other opaque surfaces.++ The object returned by this request will be destroyed by the+ compositor after the callback is fired and as such the client must not+ attempt to use it after that point.++ The callback_data passed in the callback is the current time, in+ milliseconds, with an undefined base.+ </description>+ <arg name="callback" type="new_id" interface="wl_callback" summary="callback object for the frame request"/>+ </request>++ <request name="set_opaque_region">+ <description summary="set opaque region">+ This request sets the region of the surface that contains+ opaque content.++ The opaque region is an optimization hint for the compositor+ that lets it optimize the redrawing of content behind opaque+ regions. Setting an opaque region is not required for correct+ behaviour, but marking transparent content as opaque will result+ in repaint artifacts.++ The opaque region is specified in surface-local coordinates.++ The compositor ignores the parts of the opaque region that fall+ outside of the surface.++ Opaque region is double-buffered state, see wl_surface.commit.++ wl_surface.set_opaque_region changes the pending opaque region.+ wl_surface.commit copies the pending region to the current region.+ Otherwise, the pending and current regions are never changed.++ The initial value for an opaque region is empty. Setting the pending+ opaque region has copy semantics, and the wl_region object can be+ destroyed immediately. A NULL wl_region causes the pending opaque+ region to be set to empty.+ </description>+ <arg name="region" type="object" interface="wl_region" allow-null="true"+ summary="opaque region of the surface"/>+ </request>++ <request name="set_input_region">+ <description summary="set input region">+ This request sets the region of the surface that can receive+ pointer and touch events.++ Input events happening outside of this region will try the next+ surface in the server surface stack. The compositor ignores the+ parts of the input region that fall outside of the surface.++ The input region is specified in surface-local coordinates.++ Input region is double-buffered state, see wl_surface.commit.++ wl_surface.set_input_region changes the pending input region.+ wl_surface.commit copies the pending region to the current region.+ Otherwise the pending and current regions are never changed,+ except cursor and icon surfaces are special cases, see+ wl_pointer.set_cursor and wl_data_device.start_drag.++ The initial value for an input region is infinite. That means the+ whole surface will accept input. Setting the pending input region+ has copy semantics, and the wl_region object can be destroyed+ immediately. A NULL wl_region causes the input region to be set+ to infinite.+ </description>+ <arg name="region" type="object" interface="wl_region" allow-null="true"+ summary="input region of the surface"/>+ </request>++ <request name="commit">+ <description summary="commit pending surface state">+ Surface state (input, opaque, and damage regions, attached buffers,+ etc.) is double-buffered. Protocol requests modify the pending state,+ as opposed to the current state in use by the compositor. A commit+ request atomically applies all pending state, replacing the current+ state. After commit, the new pending state is as documented for each+ related request.++ On commit, a pending wl_buffer is applied first, and all other state+ second. This means that all coordinates in double-buffered state are+ relative to the new wl_buffer coming into use, except for+ wl_surface.attach itself. If there is no pending wl_buffer, the+ coordinates are relative to the current surface contents.++ All requests that need a commit to become effective are documented+ to affect double-buffered state.++ Other interfaces may add further double-buffered surface state.+ </description>+ </request>++ <event name="enter">+ <description summary="surface enters an output">+ This is emitted whenever a surface's creation, movement, or resizing+ results in some part of it being within the scanout region of an+ output.++ Note that a surface may be overlapping with zero or more outputs.+ </description>+ <arg name="output" type="object" interface="wl_output" summary="output entered by the surface"/>+ </event>++ <event name="leave">+ <description summary="surface leaves an output">+ This is emitted whenever a surface's creation, movement, or resizing+ results in it no longer having any part of it within the scanout region+ of an output.++ Clients should not use the number of outputs the surface is on for frame+ throttling purposes. The surface might be hidden even if no leave event+ has been sent, and the compositor might expect new surface content+ updates even if no enter event has been sent. The frame event should be+ used instead.+ </description>+ <arg name="output" type="object" interface="wl_output" summary="output left by the surface"/>+ </event>++ <!-- Version 2 additions -->++ <request name="set_buffer_transform" since="2">+ <description summary="sets the buffer transformation">+ This request sets an optional transformation on how the compositor+ interprets the contents of the buffer attached to the surface. The+ accepted values for the transform parameter are the values for+ wl_output.transform.++ Buffer transform is double-buffered state, see wl_surface.commit.++ A newly created surface has its buffer transformation set to normal.++ wl_surface.set_buffer_transform changes the pending buffer+ transformation. wl_surface.commit copies the pending buffer+ transformation to the current one. Otherwise, the pending and current+ values are never changed.++ The purpose of this request is to allow clients to render content+ according to the output transform, thus permitting the compositor to+ use certain optimizations even if the display is rotated. Using+ hardware overlays and scanning out a client buffer for fullscreen+ surfaces are examples of such optimizations. Those optimizations are+ highly dependent on the compositor implementation, so the use of this+ request should be considered on a case-by-case basis.++ Note that if the transform value includes 90 or 270 degree rotation,+ the width of the buffer will become the surface height and the height+ of the buffer will become the surface width.++ If transform is not one of the values from the+ wl_output.transform enum the invalid_transform protocol error+ is raised.+ </description>+ <arg name="transform" type="int" enum="wl_output.transform"+ summary="transform for interpreting buffer contents"/>+ </request>++ <!-- Version 3 additions -->++ <request name="set_buffer_scale" since="3">+ <description summary="sets the buffer scaling factor">+ This request sets an optional scaling factor on how the compositor+ interprets the contents of the buffer attached to the window.++ Buffer scale is double-buffered state, see wl_surface.commit.++ A newly created surface has its buffer scale set to 1.++ wl_surface.set_buffer_scale changes the pending buffer scale.+ wl_surface.commit copies the pending buffer scale to the current one.+ Otherwise, the pending and current values are never changed.++ The purpose of this request is to allow clients to supply higher+ resolution buffer data for use on high resolution outputs. It is+ intended that you pick the same buffer scale as the scale of the+ output that the surface is displayed on. This means the compositor+ can avoid scaling when rendering the surface on that output.++ Note that if the scale is larger than 1, then you have to attach+ a buffer that is larger (by a factor of scale in each dimension)+ than the desired surface size.++ If scale is not positive the invalid_scale protocol error is+ raised.+ </description>+ <arg name="scale" type="int"+ summary="positive scale for interpreting buffer contents"/>+ </request>++ <!-- Version 4 additions -->+ <request name="damage_buffer" since="4">+ <description summary="mark part of the surface damaged using buffer coordinates">+ This request is used to describe the regions where the pending+ buffer is different from the current surface contents, and where+ the surface therefore needs to be repainted. The compositor+ ignores the parts of the damage that fall outside of the surface.++ Damage is double-buffered state, see wl_surface.commit.++ The damage rectangle is specified in buffer coordinates,+ where x and y specify the upper left corner of the damage rectangle.++ The initial value for pending damage is empty: no damage.+ wl_surface.damage_buffer adds pending damage: the new pending+ damage is the union of old pending damage and the given rectangle.++ wl_surface.commit assigns pending damage as the current damage,+ and clears pending damage. The server will clear the current+ damage as it repaints the surface.++ This request differs from wl_surface.damage in only one way - it+ takes damage in buffer coordinates instead of surface-local+ coordinates. While this generally is more intuitive than surface+ coordinates, it is especially desirable when using wp_viewport+ or when a drawing library (like EGL) is unaware of buffer scale+ and buffer transform.++ Note: Because buffer transformation changes and damage requests may+ be interleaved in the protocol stream, it is impossible to determine+ the actual mapping between surface and buffer damage until+ wl_surface.commit time. Therefore, compositors wishing to take both+ kinds of damage into account will have to accumulate damage from the+ two requests separately and only transform from one to the other+ after receiving the wl_surface.commit.+ </description>+ <arg name="x" type="int" summary="buffer-local x coordinate"/>+ <arg name="y" type="int" summary="buffer-local y coordinate"/>+ <arg name="width" type="int" summary="width of damage rectangle"/>+ <arg name="height" type="int" summary="height of damage rectangle"/>+ </request>++ <!-- Version 5 additions -->++ <request name="offset" since="5">+ <description summary="set the surface contents offset">+ The x and y arguments specify the location of the new pending+ buffer's upper left corner, relative to the current buffer's upper+ left corner, in surface-local coordinates. In other words, the+ x and y, combined with the new surface size define in which+ directions the surface's size changes.++ Surface location offset is double-buffered state, see+ wl_surface.commit.++ This request is semantically equivalent to and the replaces the x and y+ arguments in the wl_surface.attach request in wl_surface versions prior+ to 5. See wl_surface.attach for details.+ </description>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ </request>++ <!-- Version 6 additions -->++ <event name="preferred_buffer_scale" since="6">+ <description summary="preferred buffer scale for the surface">+ This event indicates the preferred buffer scale for this surface. It is+ sent whenever the compositor's preference changes.++ It is intended that scaling aware clients use this event to scale their+ content and use wl_surface.set_buffer_scale to indicate the scale they+ have rendered with. This allows clients to supply a higher detail+ buffer.+ </description>+ <arg name="factor" type="int" summary="preferred scaling factor"/>+ </event>++ <event name="preferred_buffer_transform" since="6">+ <description summary="preferred buffer transform for the surface">+ This event indicates the preferred buffer transform for this surface.+ It is sent whenever the compositor's preference changes.++ It is intended that transform aware clients use this event to apply the+ transform to their content and use wl_surface.set_buffer_transform to+ indicate the transform they have rendered with.+ </description>+ <arg name="transform" type="uint" enum="wl_output.transform"+ summary="preferred transform"/>+ </event>+ </interface>++ <interface name="wl_seat" version="9">+ <description summary="group of input devices">+ A seat is a group of keyboards, pointer and touch devices. This+ object is published as a global during start up, or when such a+ device is hot plugged. A seat typically has a pointer and+ maintains a keyboard focus and a pointer focus.+ </description>++ <enum name="capability" bitfield="true">+ <description summary="seat capability bitmask">+ This is a bitmask of capabilities this seat has; if a member is+ set, then it is present on the seat.+ </description>+ <entry name="pointer" value="1" summary="the seat has pointer devices"/>+ <entry name="keyboard" value="2" summary="the seat has one or more keyboards"/>+ <entry name="touch" value="4" summary="the seat has touch devices"/>+ </enum>++ <enum name="error">+ <description summary="wl_seat error values">+ These errors can be emitted in response to wl_seat requests.+ </description>+ <entry name="missing_capability" value="0"+ summary="get_pointer, get_keyboard or get_touch called on seat without the matching capability"/>+ </enum>++ <event name="capabilities">+ <description summary="seat capabilities changed">+ This is emitted whenever a seat gains or loses the pointer,+ keyboard or touch capabilities. The argument is a capability+ enum containing the complete set of capabilities this seat has.++ When the pointer capability is added, a client may create a+ wl_pointer object using the wl_seat.get_pointer request. This object+ will receive pointer events until the capability is removed in the+ future.++ When the pointer capability is removed, a client should destroy the+ wl_pointer objects associated with the seat where the capability was+ removed, using the wl_pointer.release request. No further pointer+ events will be received on these objects.++ In some compositors, if a seat regains the pointer capability and a+ client has a previously obtained wl_pointer object of version 4 or+ less, that object may start sending pointer events again. This+ behavior is considered a misinterpretation of the intended behavior+ and must not be relied upon by the client. wl_pointer objects of+ version 5 or later must not send events if created before the most+ recent event notifying the client of an added pointer capability.++ The above behavior also applies to wl_keyboard and wl_touch with the+ keyboard and touch capabilities, respectively.+ </description>+ <arg name="capabilities" type="uint" enum="capability" summary="capabilities of the seat"/>+ </event>++ <request name="get_pointer">+ <description summary="return pointer object">+ The ID provided will be initialized to the wl_pointer interface+ for this seat.++ This request only takes effect if the seat has the pointer+ capability, or has had the pointer capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the pointer capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_pointer" summary="seat pointer"/>+ </request>++ <request name="get_keyboard">+ <description summary="return keyboard object">+ The ID provided will be initialized to the wl_keyboard interface+ for this seat.++ This request only takes effect if the seat has the keyboard+ capability, or has had the keyboard capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the keyboard capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_keyboard" summary="seat keyboard"/>+ </request>++ <request name="get_touch">+ <description summary="return touch object">+ The ID provided will be initialized to the wl_touch interface+ for this seat.++ This request only takes effect if the seat has the touch+ capability, or has had the touch capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the touch capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_touch" summary="seat touch interface"/>+ </request>++ <!-- Version 2 additions -->++ <event name="name" since="2">+ <description summary="unique identifier for this seat">+ In a multi-seat configuration the seat name can be used by clients to+ help identify which physical devices the seat represents.++ The seat name is a UTF-8 string with no convention defined for its+ contents. Each name is unique among all wl_seat globals. The name is+ only guaranteed to be unique for the current compositor instance.++ The same seat names are used for all clients. Thus, the name can be+ shared across processes to refer to a specific wl_seat global.++ The name event is sent after binding to the seat global. This event is+ only sent once per seat object, and the name does not change over the+ lifetime of the wl_seat global.++ Compositors may re-use the same seat name if the wl_seat global is+ destroyed and re-created later.+ </description>+ <arg name="name" type="string" summary="seat identifier"/>+ </event>++ <!-- Version 5 additions -->++ <request name="release" type="destructor" since="5">+ <description summary="release the seat object">+ Using this request a client can tell the server that it is not going to+ use the seat object anymore.+ </description>+ </request>++ </interface>++ <interface name="wl_pointer" version="9">+ <description summary="pointer input device">+ The wl_pointer interface represents one or more input devices,+ such as mice, which control the pointer location and pointer_focus+ of a seat.++ The wl_pointer interface generates motion, enter and leave+ events for the surfaces that the pointer is located over,+ and button and axis events for button presses, button releases+ and scrolling.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="set_cursor">+ <description summary="set the pointer surface">+ Set the pointer surface, i.e., the surface that contains the+ pointer image (cursor). This request gives the surface the role+ of a cursor. If the surface already has another role, it raises+ a protocol error.++ The cursor actually changes only if the pointer+ focus for this device is one of the requesting client's surfaces+ or the surface parameter is the current pointer surface. If+ there was a previous surface set with this request it is+ replaced. If surface is NULL, the pointer image is hidden.++ The parameters hotspot_x and hotspot_y define the position of+ the pointer surface relative to the pointer location. Its+ top-left corner is always at (x, y) - (hotspot_x, hotspot_y),+ where (x, y) are the coordinates of the pointer location, in+ surface-local coordinates.++ On surface.attach requests to the pointer surface, hotspot_x+ and hotspot_y are decremented by the x and y parameters+ passed to the request. Attach must be confirmed by+ wl_surface.commit as usual.++ The hotspot can also be updated by passing the currently set+ pointer surface to this request with new values for hotspot_x+ and hotspot_y.++ The input region is ignored for wl_surfaces with the role of+ a cursor. When the use as a cursor ends, the wl_surface is+ unmapped.++ The serial parameter must match the latest wl_pointer.enter+ serial number sent to the client. Otherwise the request will be+ ignored.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" allow-null="true"+ summary="pointer surface"/>+ <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>+ <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>+ </request>++ <event name="enter">+ <description summary="enter event">+ Notification that this seat's pointer is focused on a certain+ surface.++ When a seat's focus enters a surface, the pointer image+ is undefined and a client should respond to this event by setting+ an appropriate pointer image with the set_cursor request.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface entered by the pointer"/>+ <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="leave">+ <description summary="leave event">+ Notification that this seat's pointer is no longer focused on+ a certain surface.++ The leave notification is sent before the enter notification+ for the new focus.+ </description>+ <arg name="serial" type="uint" summary="serial number of the leave event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface left by the pointer"/>+ </event>++ <event name="motion">+ <description summary="pointer motion event">+ Notification of pointer location change. The arguments+ surface_x and surface_y are the location relative to the+ focused surface.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <enum name="button_state">+ <description summary="physical button state">+ Describes the physical state of a button that produced the button+ event.+ </description>+ <entry name="released" value="0" summary="the button is not pressed"/>+ <entry name="pressed" value="1" summary="the button is pressed"/>+ </enum>++ <event name="button">+ <description summary="pointer button event">+ Mouse button click and release notifications.++ The location of the click is given by the last motion or+ enter event.+ The time argument is a timestamp with millisecond+ granularity, with an undefined base.++ The button is a button code as defined in the Linux kernel's+ linux/input-event-codes.h header file, e.g. BTN_LEFT.++ Any 16-bit button code value is reserved for future additions to the+ kernel's event code list. All other button codes above 0xFFFF are+ currently undefined but may be used in future versions of this+ protocol.+ </description>+ <arg name="serial" type="uint" summary="serial number of the button event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="button" type="uint" summary="button that produced the event"/>+ <arg name="state" type="uint" enum="button_state" summary="physical state of the button"/>+ </event>++ <enum name="axis">+ <description summary="axis types">+ Describes the axis types of scroll events.+ </description>+ <entry name="vertical_scroll" value="0" summary="vertical axis"/>+ <entry name="horizontal_scroll" value="1" summary="horizontal axis"/>+ </enum>++ <event name="axis">+ <description summary="axis event">+ Scroll and other axis notifications.++ For scroll events (vertical and horizontal scroll axes), the+ value parameter is the length of a vector along the specified+ axis in a coordinate space identical to those of motion events,+ representing a relative movement along the specified axis.++ For devices that support movements non-parallel to axes multiple+ axis events will be emitted.++ When applicable, for example for touch pads, the server can+ choose to emit scroll events where the motion vector is+ equivalent to a motion event vector.++ When applicable, a client can transform its content relative to the+ scroll distance.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="value" type="fixed" summary="length of vector in surface-local coordinate space"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the pointer object">+ Using this request a client can tell the server that it is not going to+ use the pointer object anymore.++ This request destroys the pointer proxy object, so clients must not call+ wl_pointer_destroy() after using this request.+ </description>+ </request>++ <!-- Version 5 additions -->++ <event name="frame" since="5">+ <description summary="end of a pointer event sequence">+ Indicates the end of a set of events that logically belong together.+ A client is expected to accumulate the data in all events within the+ frame before proceeding.++ All wl_pointer events before a wl_pointer.frame event belong+ logically together. For example, in a diagonal scroll motion the+ compositor will send an optional wl_pointer.axis_source event, two+ wl_pointer.axis events (horizontal and vertical) and finally a+ wl_pointer.frame event. The client may use this information to+ calculate a diagonal vector for scrolling.++ When multiple wl_pointer.axis events occur within the same frame,+ the motion vector is the combined motion of all events.+ When a wl_pointer.axis and a wl_pointer.axis_stop event occur within+ the same frame, this indicates that axis movement in one axis has+ stopped but continues in the other axis.+ When multiple wl_pointer.axis_stop events occur within the same+ frame, this indicates that these axes stopped in the same instance.++ A wl_pointer.frame event is sent for every logical event group,+ even if the group only contains a single wl_pointer event.+ Specifically, a client may get a sequence: motion, frame, button,+ frame, axis, frame, axis_stop, frame.++ The wl_pointer.enter and wl_pointer.leave events are logical events+ generated by the compositor and not the hardware. These events are+ also grouped by a wl_pointer.frame. When a pointer moves from one+ surface to another, a compositor should group the+ wl_pointer.leave event within the same wl_pointer.frame.+ However, a client must not rely on wl_pointer.leave and+ wl_pointer.enter being in the same wl_pointer.frame.+ Compositor-specific policies may require the wl_pointer.leave and+ wl_pointer.enter event being split across multiple wl_pointer.frame+ groups.+ </description>+ </event>++ <enum name="axis_source">+ <description summary="axis source types">+ Describes the source types for axis events. This indicates to the+ client how an axis event was physically generated; a client may+ adjust the user interface accordingly. For example, scroll events+ from a "finger" source may be in a smooth coordinate space with+ kinetic scrolling whereas a "wheel" source may be in discrete steps+ of a number of lines.++ The "continuous" axis source is a device generating events in a+ continuous coordinate space, but using something other than a+ finger. One example for this source is button-based scrolling where+ the vertical motion of a device is converted to scroll events while+ a button is held down.++ The "wheel tilt" axis source indicates that the actual device is a+ wheel but the scroll event is not caused by a rotation but a+ (usually sideways) tilt of the wheel.+ </description>+ <entry name="wheel" value="0" summary="a physical wheel rotation" />+ <entry name="finger" value="1" summary="finger on a touch surface" />+ <entry name="continuous" value="2" summary="continuous coordinate space"/>+ <entry name="wheel_tilt" value="3" summary="a physical wheel tilt" since="6"/>+ </enum>++ <event name="axis_source" since="5">+ <description summary="axis source event">+ Source information for scroll and other axes.++ This event does not occur on its own. It is sent before a+ wl_pointer.frame event and carries the source information for+ all events within that frame.++ The source specifies how this event was generated. If the source is+ wl_pointer.axis_source.finger, a wl_pointer.axis_stop event will be+ sent when the user lifts the finger off the device.++ If the source is wl_pointer.axis_source.wheel,+ wl_pointer.axis_source.wheel_tilt or+ wl_pointer.axis_source.continuous, a wl_pointer.axis_stop event may+ or may not be sent. Whether a compositor sends an axis_stop event+ for these sources is hardware-specific and implementation-dependent;+ clients must not rely on receiving an axis_stop event for these+ scroll sources and should treat scroll sequences from these scroll+ sources as unterminated by default.++ This event is optional. If the source is unknown for a particular+ axis event sequence, no event is sent.+ Only one wl_pointer.axis_source event is permitted per frame.++ The order of wl_pointer.axis_discrete and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis_source" type="uint" enum="axis_source" summary="source of the axis event"/>+ </event>++ <event name="axis_stop" since="5">+ <description summary="axis stop event">+ Stop notification for scroll and other axes.++ For some wl_pointer.axis_source types, a wl_pointer.axis_stop event+ is sent to notify a client that the axis sequence has terminated.+ This enables the client to implement kinetic scrolling.+ See the wl_pointer.axis_source documentation for information on when+ this event may be generated.++ Any wl_pointer.axis events with the same axis_source after this+ event should be considered as the start of a new axis motion.++ The timestamp is to be interpreted identical to the timestamp in the+ wl_pointer.axis event. The timestamp value may be the same as a+ preceding wl_pointer.axis event.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="axis" type="uint" enum="axis" summary="the axis stopped with this event"/>+ </event>++ <event name="axis_discrete" since="5">+ <description summary="axis click event">+ Discrete step information for scroll and other axes.++ This event carries the axis value of the wl_pointer.axis event in+ discrete steps (e.g. mouse wheel clicks).++ This event is deprecated with wl_pointer version 8 - this event is not+ sent to clients supporting version 8 or later.++ This event does not occur on its own, it is coupled with a+ wl_pointer.axis event that represents this axis value on a+ continuous scale. The protocol guarantees that each axis_discrete+ event is always followed by exactly one axis event with the same+ axis number within the same wl_pointer.frame. Note that the protocol+ allows for other events to occur between the axis_discrete and+ its coupled axis event, including other axis_discrete or axis+ events. A wl_pointer.frame must not contain more than one axis_discrete+ event per axis type.++ This event is optional; continuous scrolling devices+ like two-finger scrolling on touchpads do not have discrete+ steps and do not generate this event.++ The discrete value carries the directional information. e.g. a value+ of -2 is two steps towards the negative direction of this axis.++ The axis number is identical to the axis number in the associated+ axis event.++ The order of wl_pointer.axis_discrete and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="discrete" type="int" summary="number of steps"/>+ </event>++ <event name="axis_value120" since="8">+ <description summary="axis high-resolution scroll event">+ Discrete high-resolution scroll information.++ This event carries high-resolution wheel scroll information,+ with each multiple of 120 representing one logical scroll step+ (a wheel detent). For example, an axis_value120 of 30 is one quarter of+ a logical scroll step in the positive direction, a value120 of+ -240 are two logical scroll steps in the negative direction within the+ same hardware event.+ Clients that rely on discrete scrolling should accumulate the+ value120 to multiples of 120 before processing the event.++ The value120 must not be zero.++ This event replaces the wl_pointer.axis_discrete event in clients+ supporting wl_pointer version 8 or later.++ Where a wl_pointer.axis_source event occurs in the same+ wl_pointer.frame, the axis source applies to this event.++ The order of wl_pointer.axis_value120 and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="value120" type="int" summary="scroll distance as fraction of 120"/>+ </event>++ <!-- Version 9 additions -->++ <enum name="axis_relative_direction">+ <description summary="axis relative direction">+ This specifies the direction of the physical motion that caused a+ wl_pointer.axis event, relative to the wl_pointer.axis direction.+ </description>+ <entry name="identical" value="0"+ summary="physical motion matches axis direction"/>+ <entry name="inverted" value="1"+ summary="physical motion is the inverse of the axis direction"/>+ </enum>++ <event name="axis_relative_direction" since="9">+ <description summary="axis relative physical direction event">+ Relative directional information of the entity causing the axis+ motion.++ For a wl_pointer.axis event, the wl_pointer.axis_relative_direction+ event specifies the movement direction of the entity causing the+ wl_pointer.axis event. For example:+ - if a user's fingers on a touchpad move down and this+ causes a wl_pointer.axis vertical_scroll down event, the physical+ direction is 'identical'+ - if a user's fingers on a touchpad move down and this causes a+ wl_pointer.axis vertical_scroll up scroll up event ('natural+ scrolling'), the physical direction is 'inverted'.++ A client may use this information to adjust scroll motion of+ components. Specifically, enabling natural scrolling causes the+ content to change direction compared to traditional scrolling.+ Some widgets like volume control sliders should usually match the+ physical direction regardless of whether natural scrolling is+ active. This event enables clients to match the scroll direction of+ a widget to the physical direction.++ This event does not occur on its own, it is coupled with a+ wl_pointer.axis event that represents this axis value.+ The protocol guarantees that each axis_relative_direction event is+ always followed by exactly one axis event with the same+ axis number within the same wl_pointer.frame. Note that the protocol+ allows for other events to occur between the axis_relative_direction+ and its coupled axis event.++ The axis number is identical to the axis number in the associated+ axis event.++ The order of wl_pointer.axis_relative_direction,+ wl_pointer.axis_discrete and wl_pointer.axis_source is not+ guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="direction" type="uint" enum="axis_relative_direction"+ summary="physical direction relative to axis motion"/>+ </event>+ </interface>++ <interface name="wl_keyboard" version="9">+ <description summary="keyboard input device">+ The wl_keyboard interface represents one or more keyboards+ associated with a seat.+ </description>++ <enum name="keymap_format">+ <description summary="keyboard mapping format">+ This specifies the format of the keymap provided to the+ client with the wl_keyboard.keymap event.+ </description>+ <entry name="no_keymap" value="0"+ summary="no keymap; client must understand how to interpret the raw keycode"/>+ <entry name="xkb_v1" value="1"+ summary="libxkbcommon compatible, null-terminated string; to determine the xkb keycode, clients must add 8 to the key event keycode"/>+ </enum>++ <event name="keymap">+ <description summary="keyboard mapping">+ This event provides a file descriptor to the client which can be+ memory-mapped in read-only mode to provide a keyboard mapping+ description.++ From version 7 onwards, the fd must be mapped with MAP_PRIVATE by+ the recipient, as MAP_SHARED may fail.+ </description>+ <arg name="format" type="uint" enum="keymap_format" summary="keymap format"/>+ <arg name="fd" type="fd" summary="keymap file descriptor"/>+ <arg name="size" type="uint" summary="keymap size, in bytes"/>+ </event>++ <event name="enter">+ <description summary="enter event">+ Notification that this seat's keyboard focus is on a certain+ surface.++ The compositor must send the wl_keyboard.modifiers event after this+ event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface gaining keyboard focus"/>+ <arg name="keys" type="array" summary="the currently pressed keys"/>+ </event>++ <event name="leave">+ <description summary="leave event">+ Notification that this seat's keyboard focus is no longer on+ a certain surface.++ The leave notification is sent before the enter notification+ for the new focus.++ After this event client must assume that all keys, including modifiers,+ are lifted and also it must stop key repeating if there's some going on.+ </description>+ <arg name="serial" type="uint" summary="serial number of the leave event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface that lost keyboard focus"/>+ </event>++ <enum name="key_state">+ <description summary="physical key state">+ Describes the physical state of a key that produced the key event.+ </description>+ <entry name="released" value="0" summary="key is not pressed"/>+ <entry name="pressed" value="1" summary="key is pressed"/>+ </enum>++ <event name="key">+ <description summary="key event">+ A key was pressed or released.+ The time argument is a timestamp with millisecond+ granularity, with an undefined base.++ The key is a platform-specific key code that can be interpreted+ by feeding it to the keyboard mapping (see the keymap event).++ If this event produces a change in modifiers, then the resulting+ wl_keyboard.modifiers event must be sent after this event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the key event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="key" type="uint" summary="key that produced the event"/>+ <arg name="state" type="uint" enum="key_state" summary="physical state of the key"/>+ </event>++ <event name="modifiers">+ <description summary="modifier and group state">+ Notifies clients that the modifier and/or group state has+ changed, and it should update its local state.+ </description>+ <arg name="serial" type="uint" summary="serial number of the modifiers event"/>+ <arg name="mods_depressed" type="uint" summary="depressed modifiers"/>+ <arg name="mods_latched" type="uint" summary="latched modifiers"/>+ <arg name="mods_locked" type="uint" summary="locked modifiers"/>+ <arg name="group" type="uint" summary="keyboard layout"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the keyboard object"/>+ </request>++ <!-- Version 4 additions -->++ <event name="repeat_info" since="4">+ <description summary="repeat rate and delay">+ Informs the client about the keyboard's repeat rate and delay.++ This event is sent as soon as the wl_keyboard object has been created,+ and is guaranteed to be received by the client before any key press+ event.++ Negative values for either rate or delay are illegal. A rate of zero+ will disable any repeating (regardless of the value of delay).++ This event can be sent later on as well with a new value if necessary,+ so clients should continue listening for the event past the creation+ of wl_keyboard.+ </description>+ <arg name="rate" type="int"+ summary="the rate of repeating keys in characters per second"/>+ <arg name="delay" type="int"+ summary="delay in milliseconds since key down until repeating starts"/>+ </event>+ </interface>++ <interface name="wl_touch" version="9">+ <description summary="touchscreen input device">+ The wl_touch interface represents a touchscreen+ associated with a seat.++ Touch interactions can consist of one or more contacts.+ For each contact, a series of events is generated, starting+ with a down event, followed by zero or more motion events,+ and ending with an up event. Events relating to the same+ contact point can be identified by the ID of the sequence.+ </description>++ <event name="down">+ <description summary="touch down event and beginning of a touch sequence">+ A new touch point has appeared on the surface. This touch point is+ assigned a unique ID. Future events from this touch point reference+ this ID. The ID ceases to be valid after a touch up event and may be+ reused in the future.+ </description>+ <arg name="serial" type="uint" summary="serial number of the touch down event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface touched"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="up">+ <description summary="end of a touch event sequence">+ The touch point has disappeared. No further events will be sent for+ this touch point and the touch point's ID is released and may be+ reused in a future touch down event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the touch up event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ </event>++ <event name="motion">+ <description summary="update of touch point coordinates">+ A touch point has changed coordinates.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="frame">+ <description summary="end of touch frame event">+ Indicates the end of a set of events that logically belong together.+ A client is expected to accumulate the data in all events within the+ frame before proceeding.++ A wl_touch.frame terminates at least one event but otherwise no+ guarantee is provided about the set of events within a frame. A client+ must assume that any state not updated in a frame is unchanged from the+ previously known state.+ </description>+ </event>++ <event name="cancel">+ <description summary="touch session cancelled">+ Sent if the compositor decides the touch stream is a global+ gesture. No further events are sent to the clients from that+ particular gesture. Touch cancellation applies to all touch points+ currently active on this client's surface. The client is+ responsible for finalizing the touch points, future touch points on+ this surface may reuse the touch point ID.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the touch object"/>+ </request>++ <!-- Version 6 additions -->++ <event name="shape" since="6">+ <description summary="update shape of touch point">+ Sent when a touchpoint has changed its shape.++ This event does not occur on its own. It is sent before a+ wl_touch.frame event and carries the new shape information for+ any previously reported, or new touch points of that frame.++ Other events describing the touch point such as wl_touch.down,+ wl_touch.motion or wl_touch.orientation may be sent within the+ same wl_touch.frame. A client should treat these events as a single+ logical touch point update. The order of wl_touch.shape,+ wl_touch.orientation and wl_touch.motion is not guaranteed.+ A wl_touch.down event is guaranteed to occur before the first+ wl_touch.shape event for this touch ID but both events may occur within+ the same wl_touch.frame.++ A touchpoint shape is approximated by an ellipse through the major and+ minor axis length. The major axis length describes the longer diameter+ of the ellipse, while the minor axis length describes the shorter+ diameter. Major and minor are orthogonal and both are specified in+ surface-local coordinates. The center of the ellipse is always at the+ touchpoint location as reported by wl_touch.down or wl_touch.move.++ This event is only sent by the compositor if the touch device supports+ shape reports. The client has to make reasonable assumptions about the+ shape if it did not receive this event.+ </description>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="major" type="fixed" summary="length of the major axis in surface-local coordinates"/>+ <arg name="minor" type="fixed" summary="length of the minor axis in surface-local coordinates"/>+ </event>++ <event name="orientation" since="6">+ <description summary="update orientation of touch point">+ Sent when a touchpoint has changed its orientation.++ This event does not occur on its own. It is sent before a+ wl_touch.frame event and carries the new shape information for+ any previously reported, or new touch points of that frame.++ Other events describing the touch point such as wl_touch.down,+ wl_touch.motion or wl_touch.shape may be sent within the+ same wl_touch.frame. A client should treat these events as a single+ logical touch point update. The order of wl_touch.shape,+ wl_touch.orientation and wl_touch.motion is not guaranteed.+ A wl_touch.down event is guaranteed to occur before the first+ wl_touch.orientation event for this touch ID but both events may occur+ within the same wl_touch.frame.++ The orientation describes the clockwise angle of a touchpoint's major+ axis to the positive surface y-axis and is normalized to the -180 to+ +180 degree range. The granularity of orientation depends on the touch+ device, some devices only support binary rotation values between 0 and+ 90 degrees.++ This event is only sent by the compositor if the touch device supports+ orientation reports.+ </description>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="orientation" type="fixed" summary="angle between major axis and positive surface y-axis in degrees"/>+ </event>+ </interface>++ <interface name="wl_output" version="4">+ <description summary="compositor output region">+ An output describes part of the compositor geometry. The+ compositor works in the 'compositor coordinate system' and an+ output corresponds to a rectangular area in that space that is+ actually visible. This typically corresponds to a monitor that+ displays part of the compositor space. This object is published+ as global during start up, or when a monitor is hotplugged.+ </description>++ <enum name="subpixel">+ <description summary="subpixel geometry information">+ This enumeration describes how the physical+ pixels on an output are laid out.+ </description>+ <entry name="unknown" value="0" summary="unknown geometry"/>+ <entry name="none" value="1" summary="no geometry"/>+ <entry name="horizontal_rgb" value="2" summary="horizontal RGB"/>+ <entry name="horizontal_bgr" value="3" summary="horizontal BGR"/>+ <entry name="vertical_rgb" value="4" summary="vertical RGB"/>+ <entry name="vertical_bgr" value="5" summary="vertical BGR"/>+ </enum>++ <enum name="transform">+ <description summary="transform from framebuffer to output">+ This describes the transform that a compositor will apply to a+ surface to compensate for the rotation or mirroring of an+ output device.++ The flipped values correspond to an initial flip around a+ vertical axis followed by rotation.++ The purpose is mainly to allow clients to render accordingly and+ tell the compositor, so that for fullscreen surfaces, the+ compositor will still be able to scan out directly from client+ surfaces.+ </description>+ <entry name="normal" value="0" summary="no transform"/>+ <entry name="90" value="1" summary="90 degrees counter-clockwise"/>+ <entry name="180" value="2" summary="180 degrees counter-clockwise"/>+ <entry name="270" value="3" summary="270 degrees counter-clockwise"/>+ <entry name="flipped" value="4" summary="180 degree flip around a vertical axis"/>+ <entry name="flipped_90" value="5" summary="flip and rotate 90 degrees counter-clockwise"/>+ <entry name="flipped_180" value="6" summary="flip and rotate 180 degrees counter-clockwise"/>+ <entry name="flipped_270" value="7" summary="flip and rotate 270 degrees counter-clockwise"/>+ </enum>++ <event name="geometry">+ <description summary="properties of the output">+ The geometry event describes geometric properties of the output.+ The event is sent when binding to the output object and whenever+ any of the properties change.++ The physical size can be set to zero if it doesn't make sense for this+ output (e.g. for projectors or virtual outputs).++ The geometry event will be followed by a done event (starting from+ version 2).++ Note: wl_output only advertises partial information about the output+ position and identification. Some compositors, for instance those not+ implementing a desktop-style output layout or those exposing virtual+ outputs, might fake this information. Instead of using x and y, clients+ should use xdg_output.logical_position. Instead of using make and model,+ clients should use name and description.+ </description>+ <arg name="x" type="int"+ summary="x position within the global compositor space"/>+ <arg name="y" type="int"+ summary="y position within the global compositor space"/>+ <arg name="physical_width" type="int"+ summary="width in millimeters of the output"/>+ <arg name="physical_height" type="int"+ summary="height in millimeters of the output"/>+ <arg name="subpixel" type="int" enum="subpixel"+ summary="subpixel orientation of the output"/>+ <arg name="make" type="string"+ summary="textual description of the manufacturer"/>+ <arg name="model" type="string"+ summary="textual description of the model"/>+ <arg name="transform" type="int" enum="transform"+ summary="transform that maps framebuffer to output"/>+ </event>++ <enum name="mode" bitfield="true">+ <description summary="mode information">+ These flags describe properties of an output mode.+ They are used in the flags bitfield of the mode event.+ </description>+ <entry name="current" value="0x1"+ summary="indicates this is the current mode"/>+ <entry name="preferred" value="0x2"+ summary="indicates this is the preferred mode"/>+ </enum>++ <event name="mode">+ <description summary="advertise available modes for the output">+ The mode event describes an available mode for the output.++ The event is sent when binding to the output object and there+ will always be one mode, the current mode. The event is sent+ again if an output changes mode, for the mode that is now+ current. In other words, the current mode is always the last+ mode that was received with the current flag set.++ Non-current modes are deprecated. A compositor can decide to only+ advertise the current mode and never send other modes. Clients+ should not rely on non-current modes.++ The size of a mode is given in physical hardware units of+ the output device. This is not necessarily the same as+ the output size in the global compositor space. For instance,+ the output may be scaled, as described in wl_output.scale,+ or transformed, as described in wl_output.transform. Clients+ willing to retrieve the output size in the global compositor+ space should use xdg_output.logical_size instead.++ The vertical refresh rate can be set to zero if it doesn't make+ sense for this output (e.g. for virtual outputs).++ The mode event will be followed by a done event (starting from+ version 2).++ Clients should not use the refresh rate to schedule frames. Instead,+ they should use the wl_surface.frame event or the presentation-time+ protocol.++ Note: this information is not always meaningful for all outputs. Some+ compositors, such as those exposing virtual outputs, might fake the+ refresh rate or the size.+ </description>+ <arg name="flags" type="uint" enum="mode" summary="bitfield of mode flags"/>+ <arg name="width" type="int" summary="width of the mode in hardware units"/>+ <arg name="height" type="int" summary="height of the mode in hardware units"/>+ <arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>+ </event>++ <!-- Version 2 additions -->++ <event name="done" since="2">+ <description summary="sent all information about output">+ This event is sent after all other properties have been+ sent after binding to the output object and after any+ other property changes done after that. This allows+ changes to the output properties to be seen as+ atomic, even if they happen via multiple events.+ </description>+ </event>++ <event name="scale" since="2">+ <description summary="output scaling properties">+ This event contains scaling geometry information+ that is not in the geometry event. It may be sent after+ binding the output object or if the output scale changes+ later. If it is not sent, the client should assume a+ scale of 1.++ A scale larger than 1 means that the compositor will+ automatically scale surface buffers by this amount+ when rendering. This is used for very high resolution+ displays where applications rendering at the native+ resolution would be too small to be legible.++ It is intended that scaling aware clients track the+ current output of a surface, and if it is on a scaled+ output it should use wl_surface.set_buffer_scale with+ the scale of the output. That way the compositor can+ avoid scaling the surface, and the client can supply+ a higher detail image.++ The scale event will be followed by a done event.+ </description>+ <arg name="factor" type="int" summary="scaling factor of output"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the output object">+ Using this request a client can tell the server that it is not going to+ use the output object anymore.+ </description>+ </request>++ <!-- Version 4 additions -->++ <event name="name" since="4">+ <description summary="name of this output">+ Many compositors will assign user-friendly names to their outputs, show+ them to the user, allow the user to refer to an output, etc. The client+ may wish to know this name as well to offer the user similar behaviors.++ The name is a UTF-8 string with no convention defined for its contents.+ Each name is unique among all wl_output globals. The name is only+ guaranteed to be unique for the compositor instance.++ The same output name is used for all clients for a given wl_output+ global. Thus, the name can be shared across processes to refer to a+ specific wl_output global.++ The name is not guaranteed to be persistent across sessions, thus cannot+ be used to reliably identify an output in e.g. configuration files.++ Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do+ not assume that the name is a reflection of an underlying DRM connector,+ X11 connection, etc.++ The name event is sent after binding the output object. This event is+ only sent once per output object, and the name does not change over the+ lifetime of the wl_output global.++ Compositors may re-use the same output name if the wl_output global is+ destroyed and re-created later. Compositors should avoid re-using the+ same name if possible.++ The name event will be followed by a done event.+ </description>+ <arg name="name" type="string" summary="output name"/>+ </event>++ <event name="description" since="4">+ <description summary="human-readable description of this output">+ Many compositors can produce human-readable descriptions of their+ outputs. The client may wish to know this description as well, e.g. for+ output selection purposes.++ The description is a UTF-8 string with no convention defined for its+ contents. The description is not guaranteed to be unique among all+ wl_output globals. Examples might include 'Foocorp 11" Display' or+ 'Virtual X11 output via :1'.++ The description event is sent after binding the output object and+ whenever the description changes. The description is optional, and may+ not be sent at all.++ The description event will be followed by a done event.+ </description>+ <arg name="description" type="string" summary="output description"/>+ </event>+ </interface>++ <interface name="wl_region" version="1">+ <description summary="region interface">+ A region object describes an area.++ Region objects are used to describe the opaque and input+ regions of a surface.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy region">+ Destroy the region. This will invalidate the object ID.+ </description>+ </request>++ <request name="add">+ <description summary="add rectangle to region">+ Add the specified rectangle to the region.+ </description>+ <arg name="x" type="int" summary="region-local x coordinate"/>+ <arg name="y" type="int" summary="region-local y coordinate"/>+ <arg name="width" type="int" summary="rectangle width"/>+ <arg name="height" type="int" summary="rectangle height"/>+ </request>++ <request name="subtract">+ <description summary="subtract rectangle from region">+ Subtract the specified rectangle from the region.+ </description>+ <arg name="x" type="int" summary="region-local x coordinate"/>+ <arg name="y" type="int" summary="region-local y coordinate"/>+ <arg name="width" type="int" summary="rectangle width"/>+ <arg name="height" type="int" summary="rectangle height"/>+ </request>+ </interface>++ <interface name="wl_subcompositor" version="1">+ <description summary="sub-surface compositing">+ The global interface exposing sub-surface compositing capabilities.+ A wl_surface, that has sub-surfaces associated, is called the+ parent surface. Sub-surfaces can be arbitrarily nested and create+ a tree of sub-surfaces.++ The root surface in a tree of sub-surfaces is the main+ surface. The main surface cannot be a sub-surface, because+ sub-surfaces must always have a parent.++ A main surface with its sub-surfaces forms a (compound) window.+ For window management purposes, this set of wl_surface objects is+ to be considered as a single window, and it should also behave as+ such.++ The aim of sub-surfaces is to offload some of the compositing work+ within a window from clients to the compositor. A prime example is+ a video player with decorations and video in separate wl_surface+ objects. This should allow the compositor to pass YUV video buffer+ processing to dedicated overlay hardware when possible.+ </description>++ <request name="destroy" type="destructor">+ <description summary="unbind from the subcompositor interface">+ Informs the server that the client will not be using this+ protocol object anymore. This does not affect any other+ objects, wl_subsurface objects included.+ </description>+ </request>++ <enum name="error">+ <entry name="bad_surface" value="0"+ summary="the to-be sub-surface is invalid"/>+ <entry name="bad_parent" value="1"+ summary="the to-be sub-surface parent is invalid"/>+ </enum>++ <request name="get_subsurface">+ <description summary="give a surface the role sub-surface">+ Create a sub-surface interface for the given surface, and+ associate it with the given parent surface. This turns a+ plain wl_surface into a sub-surface.++ The to-be sub-surface must not already have another role, and it+ must not have an existing wl_subsurface object. Otherwise the+ bad_surface protocol error is raised.++ Adding sub-surfaces to a parent is a double-buffered operation on the+ parent (see wl_surface.commit). The effect of adding a sub-surface+ becomes visible on the next time the state of the parent surface is+ applied.++ The parent surface must not be one of the child surface's descendants,+ and the parent must be different from the child surface, otherwise the+ bad_parent protocol error is raised.++ This request modifies the behaviour of wl_surface.commit request on+ the sub-surface, see the documentation on wl_subsurface interface.+ </description>+ <arg name="id" type="new_id" interface="wl_subsurface"+ summary="the new sub-surface object ID"/>+ <arg name="surface" type="object" interface="wl_surface"+ summary="the surface to be turned into a sub-surface"/>+ <arg name="parent" type="object" interface="wl_surface"+ summary="the parent surface"/>+ </request>+ </interface>++ <interface name="wl_subsurface" version="1">+ <description summary="sub-surface interface to a wl_surface">+ An additional interface to a wl_surface object, which has been+ made a sub-surface. A sub-surface has one parent surface. A+ sub-surface's size and position are not limited to that of the parent.+ Particularly, a sub-surface is not automatically clipped to its+ parent's area.++ A sub-surface becomes mapped, when a non-NULL wl_buffer is applied+ and the parent surface is mapped. The order of which one happens+ first is irrelevant. A sub-surface is hidden if the parent becomes+ hidden, or if a NULL wl_buffer is applied. These rules apply+ recursively through the tree of surfaces.++ The behaviour of a wl_surface.commit request on a sub-surface+ depends on the sub-surface's mode. The possible modes are+ synchronized and desynchronized, see methods+ wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized+ mode caches the wl_surface state to be applied when the parent's+ state gets applied, and desynchronized mode applies the pending+ wl_surface state directly. A sub-surface is initially in the+ synchronized mode.++ Sub-surfaces also have another kind of state, which is managed by+ wl_subsurface requests, as opposed to wl_surface requests. This+ state includes the sub-surface position relative to the parent+ surface (wl_subsurface.set_position), and the stacking order of+ the parent and its sub-surfaces (wl_subsurface.place_above and+ .place_below). This state is applied when the parent surface's+ wl_surface state is applied, regardless of the sub-surface's mode.+ As the exception, set_sync and set_desync are effective immediately.++ The main surface can be thought to be always in desynchronized mode,+ since it does not have a parent in the sub-surfaces sense.++ Even if a sub-surface is in desynchronized mode, it will behave as+ in synchronized mode, if its parent surface behaves as in+ synchronized mode. This rule is applied recursively throughout the+ tree of surfaces. This means, that one can set a sub-surface into+ synchronized mode, and then assume that all its child and grand-child+ sub-surfaces are synchronized, too, without explicitly setting them.++ Destroying a sub-surface takes effect immediately. If you need to+ synchronize the removal of a sub-surface to the parent surface update,+ unmap the sub-surface first by attaching a NULL wl_buffer, update parent,+ and then destroy the sub-surface.++ If the parent wl_surface object is destroyed, the sub-surface is+ unmapped.+ </description>++ <request name="destroy" type="destructor">+ <description summary="remove sub-surface interface">+ The sub-surface interface is removed from the wl_surface object+ that was turned into a sub-surface with a+ wl_subcompositor.get_subsurface request. The wl_surface's association+ to the parent is deleted. The wl_surface is unmapped immediately.+ </description>+ </request>++ <enum name="error">+ <entry name="bad_surface" value="0"+ summary="wl_surface is not a sibling or the parent"/>+ </enum>++ <request name="set_position">+ <description summary="reposition the sub-surface">+ This schedules a sub-surface position change.+ The sub-surface will be moved so that its origin (top left+ corner pixel) will be at the location x, y of the parent surface+ coordinate system. The coordinates are not restricted to the parent+ surface area. Negative values are allowed.++ The scheduled coordinates will take effect whenever the state of the+ parent surface is applied. When this happens depends on whether the+ parent surface is in synchronized mode or not. See+ wl_subsurface.set_sync and wl_subsurface.set_desync for details.++ If more than one set_position request is invoked by the client before+ the commit of the parent surface, the position of a new request always+ replaces the scheduled position from any previous request.++ The initial position is 0, 0.+ </description>+ <arg name="x" type="int" summary="x coordinate in the parent surface"/>+ <arg name="y" type="int" summary="y coordinate in the parent surface"/>+ </request>++ <request name="place_above">+ <description summary="restack the sub-surface">+ This sub-surface is taken from the stack, and put back just+ above the reference surface, changing the z-order of the sub-surfaces.+ The reference surface must be one of the sibling surfaces, or the+ parent surface. Using any other surface, including this sub-surface,+ will cause a protocol error.++ The z-order is double-buffered. Requests are handled in order and+ applied immediately to a pending state. The final pending state is+ copied to the active state the next time the state of the parent+ surface is applied. When this happens depends on whether the parent+ surface is in synchronized mode or not. See wl_subsurface.set_sync and+ wl_subsurface.set_desync for details.++ A new sub-surface is initially added as the top-most in the stack+ of its siblings and parent.+ </description>+ <arg name="sibling" type="object" interface="wl_surface"+ summary="the reference surface"/>+ </request>++ <request name="place_below">+ <description summary="restack the sub-surface">+ The sub-surface is placed just below the reference surface.+ See wl_subsurface.place_above.+ </description>+ <arg name="sibling" type="object" interface="wl_surface"+ summary="the reference surface"/>+ </request>++ <request name="set_sync">+ <description summary="set sub-surface to synchronized mode">+ Change the commit behaviour of the sub-surface to synchronized+ mode, also described as the parent dependent mode.++ In synchronized mode, wl_surface.commit on a sub-surface will+ accumulate the committed state in a cache, but the state will+ not be applied and hence will not change the compositor output.+ The cached state is applied to the sub-surface immediately after+ the parent surface's state is applied. This ensures atomic+ updates of the parent and all its synchronized sub-surfaces.+ Applying the cached state will invalidate the cache, so further+ parent surface commits do not (re-)apply old state.++ See wl_subsurface for the recursive effect of this mode.+ </description>+ </request>++ <request name="set_desync">+ <description summary="set sub-surface to desynchronized mode">+ Change the commit behaviour of the sub-surface to desynchronized+ mode, also described as independent or freely running mode.++ In desynchronized mode, wl_surface.commit on a sub-surface will+ apply the pending state directly, without caching, as happens+ normally with a wl_surface. Calling wl_surface.commit on the+ parent surface has no effect on the sub-surface's wl_surface+ state. This mode allows a sub-surface to be updated on its own.++ If cached state exists when wl_surface.commit is called in+ desynchronized mode, the pending state is added to the cached+ state, and applied as a whole. This invalidates the cache.++ Note: even if a sub-surface is set to desynchronized, a parent+ sub-surface may override it to behave as synchronized. For details,+ see wl_subsurface.++ If a surface's parent surface behaves as desynchronized, then+ the cached state is applied on set_desync.+ </description>+ </request>+ </interface>++</protocol>
+ examples/hello-world/protocols/xdg-shell.xml view
@@ -0,0 +1,1282 @@+<?xml version="1.0" encoding="UTF-8"?>+<protocol name="xdg_shell">++ <copyright>+ Copyright © 2008-2013 Kristian Høgsberg+ Copyright © 2013 Rafael Antognolli+ Copyright © 2013 Jasper St. Pierre+ Copyright © 2010-2013 Intel Corporation+ Copyright © 2015-2017 Samsung Electronics Co., Ltd+ Copyright © 2015-2017 Red Hat Inc.++ Permission is hereby granted, free of charge, to any person obtaining a+ copy of this software and associated documentation files (the "Software"),+ to deal in the Software without restriction, including without limitation+ the rights to use, copy, modify, merge, publish, distribute, sublicense,+ and/or sell copies of the Software, and to permit persons to whom the+ Software is furnished to do so, subject to the following conditions:++ The above copyright notice and this permission notice (including the next+ paragraph) shall be included in all copies or substantial portions of the+ Software.++ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER+ DEALINGS IN THE SOFTWARE.+ </copyright>++ <interface name="xdg_wm_base" version="4">+ <description summary="create desktop-style surfaces">+ The xdg_wm_base interface is exposed as a global object enabling clients+ to turn their wl_surfaces into windows in a desktop environment. It+ defines the basic functionality needed for clients and the compositor to+ create windows that can be dragged, resized, maximized, etc, as well as+ creating transient windows such as popup menus.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ <entry name="defunct_surfaces" value="1"+ summary="xdg_wm_base was destroyed before children"/>+ <entry name="not_the_topmost_popup" value="2"+ summary="the client tried to map or destroy a non-topmost popup"/>+ <entry name="invalid_popup_parent" value="3"+ summary="the client specified an invalid popup parent surface"/>+ <entry name="invalid_surface_state" value="4"+ summary="the client provided an invalid surface state"/>+ <entry name="invalid_positioner" value="5"+ summary="the client provided an invalid positioner"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="destroy xdg_wm_base">+ Destroy this xdg_wm_base object.++ Destroying a bound xdg_wm_base object while there are surfaces+ still alive created by this xdg_wm_base object instance is illegal+ and will result in a protocol error.+ </description>+ </request>++ <request name="create_positioner">+ <description summary="create a positioner object">+ Create a positioner object. A positioner object is used to position+ surfaces relative to some parent surface. See the interface description+ and xdg_surface.get_popup for details.+ </description>+ <arg name="id" type="new_id" interface="xdg_positioner"/>+ </request>++ <request name="get_xdg_surface">+ <description summary="create a shell surface from a surface">+ This creates an xdg_surface for the given surface. While xdg_surface+ itself is not a role, the corresponding surface may only be assigned+ a role extending xdg_surface, such as xdg_toplevel or xdg_popup. It is+ illegal to create an xdg_surface for a wl_surface which already has an+ assigned role and this will result in a protocol error.++ This creates an xdg_surface for the given surface. An xdg_surface is+ used as basis to define a role to a given surface, such as xdg_toplevel+ or xdg_popup. It also manages functionality shared between xdg_surface+ based surface roles.++ See the documentation of xdg_surface for more details about what an+ xdg_surface is and how it is used.+ </description>+ <arg name="id" type="new_id" interface="xdg_surface"/>+ <arg name="surface" type="object" interface="wl_surface"/>+ </request>++ <request name="pong">+ <description summary="respond to a ping event">+ A client must respond to a ping event with a pong request or+ the client may be deemed unresponsive. See xdg_wm_base.ping.+ </description>+ <arg name="serial" type="uint" summary="serial of the ping event"/>+ </request>++ <event name="ping">+ <description summary="check if the client is alive">+ The ping event asks the client if it's still alive. Pass the+ serial specified in the event back to the compositor by sending+ a "pong" request back with the specified serial. See xdg_wm_base.pong.++ Compositors can use this to determine if the client is still+ alive. It's unspecified what will happen if the client doesn't+ respond to the ping request, or in what timeframe. Clients should+ try to respond in a reasonable amount of time.++ A compositor is free to ping in any way it wants, but a client must+ always respond to any xdg_wm_base object it created.+ </description>+ <arg name="serial" type="uint" summary="pass this to the pong request"/>+ </event>+ </interface>++ <interface name="xdg_positioner" version="4">+ <description summary="child surface positioner">+ The xdg_positioner provides a collection of rules for the placement of a+ child surface relative to a parent surface. Rules can be defined to ensure+ the child surface remains within the visible area's borders, and to+ specify how the child surface changes its position, such as sliding along+ an axis, or flipping around a rectangle. These positioner-created rules are+ constrained by the requirement that a child surface must intersect with or+ be at least partially adjacent to its parent surface.++ See the various requests for details about possible rules.++ At the time of the request, the compositor makes a copy of the rules+ specified by the xdg_positioner. Thus, after the request is complete the+ xdg_positioner object can be destroyed or reused; further changes to the+ object will have no effect on previous usages.++ For an xdg_positioner object to be considered complete, it must have a+ non-zero size set by set_size, and a non-zero anchor rectangle set by+ set_anchor_rect. Passing an incomplete xdg_positioner object when+ positioning a surface raises an error.+ </description>++ <enum name="error">+ <entry name="invalid_input" value="0" summary="invalid input provided"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="destroy the xdg_positioner object">+ Notify the compositor that the xdg_positioner will no longer be used.+ </description>+ </request>++ <request name="set_size">+ <description summary="set the size of the to-be positioned rectangle">+ Set the size of the surface that is to be positioned with the positioner+ object. The size is in surface-local coordinates and corresponds to the+ window geometry. See xdg_surface.set_window_geometry.++ If a zero or negative size is set the invalid_input error is raised.+ </description>+ <arg name="width" type="int" summary="width of positioned rectangle"/>+ <arg name="height" type="int" summary="height of positioned rectangle"/>+ </request>++ <request name="set_anchor_rect">+ <description summary="set the anchor rectangle within the parent surface">+ Specify the anchor rectangle within the parent surface that the child+ surface will be placed relative to. The rectangle is relative to the+ window geometry as defined by xdg_surface.set_window_geometry of the+ parent surface.++ When the xdg_positioner object is used to position a child surface, the+ anchor rectangle may not extend outside the window geometry of the+ positioned child's parent surface.++ If a negative size is set the invalid_input error is raised.+ </description>+ <arg name="x" type="int" summary="x position of anchor rectangle"/>+ <arg name="y" type="int" summary="y position of anchor rectangle"/>+ <arg name="width" type="int" summary="width of anchor rectangle"/>+ <arg name="height" type="int" summary="height of anchor rectangle"/>+ </request>++ <enum name="anchor">+ <entry name="none" value="0"/>+ <entry name="top" value="1"/>+ <entry name="bottom" value="2"/>+ <entry name="left" value="3"/>+ <entry name="right" value="4"/>+ <entry name="top_left" value="5"/>+ <entry name="bottom_left" value="6"/>+ <entry name="top_right" value="7"/>+ <entry name="bottom_right" value="8"/>+ </enum>++ <request name="set_anchor">+ <description summary="set anchor rectangle anchor">+ Defines the anchor point for the anchor rectangle. The specified anchor+ is used derive an anchor point that the child surface will be+ positioned relative to. If a corner anchor is set (e.g. 'top_left' or+ 'bottom_right'), the anchor point will be at the specified corner;+ otherwise, the derived anchor point will be centered on the specified+ edge, or in the center of the anchor rectangle if no edge is specified.+ </description>+ <arg name="anchor" type="uint" enum="anchor"+ summary="anchor"/>+ </request>++ <enum name="gravity">+ <entry name="none" value="0"/>+ <entry name="top" value="1"/>+ <entry name="bottom" value="2"/>+ <entry name="left" value="3"/>+ <entry name="right" value="4"/>+ <entry name="top_left" value="5"/>+ <entry name="bottom_left" value="6"/>+ <entry name="top_right" value="7"/>+ <entry name="bottom_right" value="8"/>+ </enum>++ <request name="set_gravity">+ <description summary="set child surface gravity">+ Defines in what direction a surface should be positioned, relative to+ the anchor point of the parent surface. If a corner gravity is+ specified (e.g. 'bottom_right' or 'top_left'), then the child surface+ will be placed towards the specified gravity; otherwise, the child+ surface will be centered over the anchor point on any axis that had no+ gravity specified.+ </description>+ <arg name="gravity" type="uint" enum="gravity"+ summary="gravity direction"/>+ </request>++ <enum name="constraint_adjustment" bitfield="true">+ <description summary="constraint adjustments">+ The constraint adjustment value define ways the compositor will adjust+ the position of the surface, if the unadjusted position would result+ in the surface being partly constrained.++ Whether a surface is considered 'constrained' is left to the compositor+ to determine. For example, the surface may be partly outside the+ compositor's defined 'work area', thus necessitating the child surface's+ position be adjusted until it is entirely inside the work area.++ The adjustments can be combined, according to a defined precedence: 1)+ Flip, 2) Slide, 3) Resize.+ </description>+ <entry name="none" value="0">+ <description summary="don't move the child surface when constrained">+ Don't alter the surface position even if it is constrained on some+ axis, for example partially outside the edge of an output.+ </description>+ </entry>+ <entry name="slide_x" value="1">+ <description summary="move along the x axis until unconstrained">+ Slide the surface along the x axis until it is no longer constrained.++ First try to slide towards the direction of the gravity on the x axis+ until either the edge in the opposite direction of the gravity is+ unconstrained or the edge in the direction of the gravity is+ constrained.++ Then try to slide towards the opposite direction of the gravity on the+ x axis until either the edge in the direction of the gravity is+ unconstrained or the edge in the opposite direction of the gravity is+ constrained.+ </description>+ </entry>+ <entry name="slide_y" value="2">+ <description summary="move along the y axis until unconstrained">+ Slide the surface along the y axis until it is no longer constrained.++ First try to slide towards the direction of the gravity on the y axis+ until either the edge in the opposite direction of the gravity is+ unconstrained or the edge in the direction of the gravity is+ constrained.++ Then try to slide towards the opposite direction of the gravity on the+ y axis until either the edge in the direction of the gravity is+ unconstrained or the edge in the opposite direction of the gravity is+ constrained.+ </description>+ </entry>+ <entry name="flip_x" value="4">+ <description summary="invert the anchor and gravity on the x axis">+ Invert the anchor and gravity on the x axis if the surface is+ constrained on the x axis. For example, if the left edge of the+ surface is constrained, the gravity is 'left' and the anchor is+ 'left', change the gravity to 'right' and the anchor to 'right'.++ If the adjusted position also ends up being constrained, the resulting+ position of the flip_x adjustment will be the one before the+ adjustment.+ </description>+ </entry>+ <entry name="flip_y" value="8">+ <description summary="invert the anchor and gravity on the y axis">+ Invert the anchor and gravity on the y axis if the surface is+ constrained on the y axis. For example, if the bottom edge of the+ surface is constrained, the gravity is 'bottom' and the anchor is+ 'bottom', change the gravity to 'top' and the anchor to 'top'.++ The adjusted position is calculated given the original anchor+ rectangle and offset, but with the new flipped anchor and gravity+ values.++ If the adjusted position also ends up being constrained, the resulting+ position of the flip_y adjustment will be the one before the+ adjustment.+ </description>+ </entry>+ <entry name="resize_x" value="16">+ <description summary="horizontally resize the surface">+ Resize the surface horizontally so that it is completely+ unconstrained.+ </description>+ </entry>+ <entry name="resize_y" value="32">+ <description summary="vertically resize the surface">+ Resize the surface vertically so that it is completely unconstrained.+ </description>+ </entry>+ </enum>++ <request name="set_constraint_adjustment">+ <description summary="set the adjustment to be done when constrained">+ Specify how the window should be positioned if the originally intended+ position caused the surface to be constrained, meaning at least+ partially outside positioning boundaries set by the compositor. The+ adjustment is set by constructing a bitmask describing the adjustment to+ be made when the surface is constrained on that axis.++ If no bit for one axis is set, the compositor will assume that the child+ surface should not change its position on that axis when constrained.++ If more than one bit for one axis is set, the order of how adjustments+ are applied is specified in the corresponding adjustment descriptions.++ The default adjustment is none.+ </description>+ <arg name="constraint_adjustment" type="uint"+ summary="bit mask of constraint adjustments"/>+ </request>++ <request name="set_offset">+ <description summary="set surface position offset">+ Specify the surface position offset relative to the position of the+ anchor on the anchor rectangle and the anchor on the surface. For+ example if the anchor of the anchor rectangle is at (x, y), the surface+ has the gravity bottom|right, and the offset is (ox, oy), the calculated+ surface position will be (x + ox, y + oy). The offset position of the+ surface is the one used for constraint testing. See+ set_constraint_adjustment.++ An example use case is placing a popup menu on top of a user interface+ element, while aligning the user interface element of the parent surface+ with some user interface element placed somewhere in the popup surface.+ </description>+ <arg name="x" type="int" summary="surface position x offset"/>+ <arg name="y" type="int" summary="surface position y offset"/>+ </request>++ <!-- Version 3 additions -->++ <request name="set_reactive" since="3">+ <description summary="continuously reconstrain the surface">+ When set reactive, the surface is reconstrained if the conditions used+ for constraining changed, e.g. the parent window moved.++ If the conditions changed and the popup was reconstrained, an+ xdg_popup.configure event is sent with updated geometry, followed by an+ xdg_surface.configure event.+ </description>+ </request>++ <request name="set_parent_size" since="3">+ <description summary="">+ Set the parent window geometry the compositor should use when+ positioning the popup. The compositor may use this information to+ determine the future state the popup should be constrained using. If+ this doesn't match the dimension of the parent the popup is eventually+ positioned against, the behavior is undefined.++ The arguments are given in the surface-local coordinate space.+ </description>+ <arg name="parent_width" type="int"+ summary="future window geometry width of parent"/>+ <arg name="parent_height" type="int"+ summary="future window geometry height of parent"/>+ </request>++ <request name="set_parent_configure" since="3">+ <description summary="set parent configure this is a response to">+ Set the serial of an xdg_surface.configure event this positioner will be+ used in response to. The compositor may use this information together+ with set_parent_size to determine what future state the popup should be+ constrained using.+ </description>+ <arg name="serial" type="uint"+ summary="serial of parent configure event"/>+ </request>+ </interface>++ <interface name="xdg_surface" version="4">+ <description summary="desktop user interface surface base interface">+ An interface that may be implemented by a wl_surface, for+ implementations that provide a desktop-style user interface.++ It provides a base set of functionality required to construct user+ interface elements requiring management by the compositor, such as+ toplevel windows, menus, etc. The types of functionality are split into+ xdg_surface roles.++ Creating an xdg_surface does not set the role for a wl_surface. In order+ to map an xdg_surface, the client must create a role-specific object+ using, e.g., get_toplevel, get_popup. The wl_surface for any given+ xdg_surface can have at most one role, and may not be assigned any role+ not based on xdg_surface.++ A role must be assigned before any other requests are made to the+ xdg_surface object.++ The client must call wl_surface.commit on the corresponding wl_surface+ for the xdg_surface state to take effect.++ Creating an xdg_surface from a wl_surface which has a buffer attached or+ committed is a client error, and any attempts by a client to attach or+ manipulate a buffer prior to the first xdg_surface.configure call must+ also be treated as errors.++ After creating a role-specific object and setting it up, the client must+ perform an initial commit without any buffer attached. The compositor+ will reply with an xdg_surface.configure event. The client must+ acknowledge it and is then allowed to attach a buffer to map the surface.++ Mapping an xdg_surface-based role surface is defined as making it+ possible for the surface to be shown by the compositor. Note that+ a mapped surface is not guaranteed to be visible once it is mapped.++ For an xdg_surface to be mapped by the compositor, the following+ conditions must be met:+ (1) the client has assigned an xdg_surface-based role to the surface+ (2) the client has set and committed the xdg_surface state and the+ role-dependent state to the surface+ (3) the client has committed a buffer to the surface++ A newly-unmapped surface is considered to have met condition (1) out+ of the 3 required conditions for mapping a surface if its role surface+ has not been destroyed, i.e. the client must perform the initial commit+ again before attaching a buffer.+ </description>++ <enum name="error">+ <entry name="not_constructed" value="1"/>+ <entry name="already_constructed" value="2"/>+ <entry name="unconfigured_buffer" value="3"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="destroy the xdg_surface">+ Destroy the xdg_surface object. An xdg_surface must only be destroyed+ after its role object has been destroyed.+ </description>+ </request>++ <request name="get_toplevel">+ <description summary="assign the xdg_toplevel surface role">+ This creates an xdg_toplevel object for the given xdg_surface and gives+ the associated wl_surface the xdg_toplevel role.++ See the documentation of xdg_toplevel for more details about what an+ xdg_toplevel is and how it is used.+ </description>+ <arg name="id" type="new_id" interface="xdg_toplevel"/>+ </request>++ <request name="get_popup">+ <description summary="assign the xdg_popup surface role">+ This creates an xdg_popup object for the given xdg_surface and gives+ the associated wl_surface the xdg_popup role.++ If null is passed as a parent, a parent surface must be specified using+ some other protocol, before committing the initial state.++ See the documentation of xdg_popup for more details about what an+ xdg_popup is and how it is used.+ </description>+ <arg name="id" type="new_id" interface="xdg_popup"/>+ <arg name="parent" type="object" interface="xdg_surface" allow-null="true"/>+ <arg name="positioner" type="object" interface="xdg_positioner"/>+ </request>++ <request name="set_window_geometry">+ <description summary="set the new window geometry">+ The window geometry of a surface is its "visible bounds" from the+ user's perspective. Client-side decorations often have invisible+ portions like drop-shadows which should be ignored for the+ purposes of aligning, placing and constraining windows.++ The window geometry is double buffered, and will be applied at the+ time wl_surface.commit of the corresponding wl_surface is called.++ When maintaining a position, the compositor should treat the (x, y)+ coordinate of the window geometry as the top left corner of the window.+ A client changing the (x, y) window geometry coordinate should in+ general not alter the position of the window.++ Once the window geometry of the surface is set, it is not possible to+ unset it, and it will remain the same until set_window_geometry is+ called again, even if a new subsurface or buffer is attached.++ If never set, the value is the full bounds of the surface,+ including any subsurfaces. This updates dynamically on every+ commit. This unset is meant for extremely simple clients.++ The arguments are given in the surface-local coordinate space of+ the wl_surface associated with this xdg_surface.++ The width and height must be greater than zero. Setting an invalid size+ will raise an error. When applied, the effective window geometry will be+ the set window geometry clamped to the bounding rectangle of the+ combined geometry of the surface of the xdg_surface and the associated+ subsurfaces.+ </description>+ <arg name="x" type="int"/>+ <arg name="y" type="int"/>+ <arg name="width" type="int"/>+ <arg name="height" type="int"/>+ </request>++ <request name="ack_configure">+ <description summary="ack a configure event">+ When a configure event is received, if a client commits the+ surface in response to the configure event, then the client+ must make an ack_configure request sometime before the commit+ request, passing along the serial of the configure event.++ For instance, for toplevel surfaces the compositor might use this+ information to move a surface to the top left only when the client has+ drawn itself for the maximized or fullscreen state.++ If the client receives multiple configure events before it+ can respond to one, it only has to ack the last configure event.++ A client is not required to commit immediately after sending+ an ack_configure request - it may even ack_configure several times+ before its next surface commit.++ A client may send multiple ack_configure requests before committing, but+ only the last request sent before a commit indicates which configure+ event the client really is responding to.+ </description>+ <arg name="serial" type="uint" summary="the serial from the configure event"/>+ </request>++ <event name="configure">+ <description summary="suggest a surface change">+ The configure event marks the end of a configure sequence. A configure+ sequence is a set of one or more events configuring the state of the+ xdg_surface, including the final xdg_surface.configure event.++ Where applicable, xdg_surface surface roles will during a configure+ sequence extend this event as a latched state sent as events before the+ xdg_surface.configure event. Such events should be considered to make up+ a set of atomically applied configuration states, where the+ xdg_surface.configure commits the accumulated state.++ Clients should arrange their surface for the new states, and then send+ an ack_configure request with the serial sent in this configure event at+ some point before committing the new surface.++ If the client receives multiple configure events before it can respond+ to one, it is free to discard all but the last event it received.+ </description>+ <arg name="serial" type="uint" summary="serial of the configure event"/>+ </event>++ </interface>++ <interface name="xdg_toplevel" version="4">+ <description summary="toplevel surface">+ This interface defines an xdg_surface role which allows a surface to,+ among other things, set window-like properties such as maximize,+ fullscreen, and minimize, set application-specific metadata like title and+ id, and well as trigger user interactive operations such as interactive+ resize and move.++ Unmapping an xdg_toplevel means that the surface cannot be shown+ by the compositor until it is explicitly mapped again.+ All active operations (e.g., move, resize) are canceled and all+ attributes (e.g. title, state, stacking, ...) are discarded for+ an xdg_toplevel surface when it is unmapped. The xdg_toplevel returns to+ the state it had right after xdg_surface.get_toplevel. The client+ can re-map the toplevel by perfoming a commit without any buffer+ attached, waiting for a configure event and handling it as usual (see+ xdg_surface description).++ Attaching a null buffer to a toplevel unmaps the surface.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy the xdg_toplevel">+ This request destroys the role surface and unmaps the surface;+ see "Unmapping" behavior in interface section for details.+ </description>+ </request>++ <enum name="error">+ <entry name="invalid_resize_edge" value="0" summary="provided value is+ not a valid variant of the resize_edge enum"/>+ </enum>++ <request name="set_parent">+ <description summary="set the parent of this surface">+ Set the "parent" of this surface. This surface should be stacked+ above the parent surface and all other ancestor surfaces.++ Parent windows should be set on dialogs, toolboxes, or other+ "auxiliary" surfaces, so that the parent is raised when the dialog+ is raised.++ Setting a null parent for a child window removes any parent-child+ relationship for the child. Setting a null parent for a window which+ currently has no parent is a no-op.++ If the parent is unmapped then its children are managed as+ though the parent of the now-unmapped parent has become the+ parent of this surface. If no parent exists for the now-unmapped+ parent then the children are managed as though they have no+ parent surface.+ </description>+ <arg name="parent" type="object" interface="xdg_toplevel" allow-null="true"/>+ </request>++ <request name="set_title">+ <description summary="set surface title">+ Set a short title for the surface.++ This string may be used to identify the surface in a task bar,+ window list, or other user interface elements provided by the+ compositor.++ The string must be encoded in UTF-8.+ </description>+ <arg name="title" type="string"/>+ </request>++ <request name="set_app_id">+ <description summary="set application ID">+ Set an application identifier for the surface.++ The app ID identifies the general class of applications to which+ the surface belongs. The compositor can use this to group multiple+ surfaces together, or to determine how to launch a new application.++ For D-Bus activatable applications, the app ID is used as the D-Bus+ service name.++ The compositor shell will try to group application surfaces together+ by their app ID. As a best practice, it is suggested to select app+ ID's that match the basename of the application's .desktop file.+ For example, "org.freedesktop.FooViewer" where the .desktop file is+ "org.freedesktop.FooViewer.desktop".++ Like other properties, a set_app_id request can be sent after the+ xdg_toplevel has been mapped to update the property.++ See the desktop-entry specification [0] for more details on+ application identifiers and how they relate to well-known D-Bus+ names and .desktop files.++ [0] http://standards.freedesktop.org/desktop-entry-spec/+ </description>+ <arg name="app_id" type="string"/>+ </request>++ <request name="show_window_menu">+ <description summary="show the window menu">+ Clients implementing client-side decorations might want to show+ a context menu when right-clicking on the decorations, giving the+ user a menu that they can use to maximize or minimize the window.++ This request asks the compositor to pop up such a window menu at+ the given position, relative to the local surface coordinates of+ the parent surface. There are no guarantees as to what menu items+ the window menu contains.++ This request must be used in response to some sort of user action+ like a button press, key press, or touch down event.+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>+ <arg name="serial" type="uint" summary="the serial of the user event"/>+ <arg name="x" type="int" summary="the x position to pop up the window menu at"/>+ <arg name="y" type="int" summary="the y position to pop up the window menu at"/>+ </request>++ <request name="move">+ <description summary="start an interactive move">+ Start an interactive, user-driven move of the surface.++ This request must be used in response to some sort of user action+ like a button press, key press, or touch down event. The passed+ serial is used to determine the type of interactive move (touch,+ pointer, etc).++ The server may ignore move requests depending on the state of+ the surface (e.g. fullscreen or maximized), or if the passed serial+ is no longer valid.++ If triggered, the surface will lose the focus of the device+ (wl_pointer, wl_touch, etc) used for the move. It is up to the+ compositor to visually indicate that the move is taking place, such as+ updating a pointer cursor, during the move. There is no guarantee+ that the device focus will return when the move is completed.+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>+ <arg name="serial" type="uint" summary="the serial of the user event"/>+ </request>++ <enum name="resize_edge">+ <description summary="edge values for resizing">+ These values are used to indicate which edge of a surface+ is being dragged in a resize operation.+ </description>+ <entry name="none" value="0"/>+ <entry name="top" value="1"/>+ <entry name="bottom" value="2"/>+ <entry name="left" value="4"/>+ <entry name="top_left" value="5"/>+ <entry name="bottom_left" value="6"/>+ <entry name="right" value="8"/>+ <entry name="top_right" value="9"/>+ <entry name="bottom_right" value="10"/>+ </enum>++ <request name="resize">+ <description summary="start an interactive resize">+ Start a user-driven, interactive resize of the surface.++ This request must be used in response to some sort of user action+ like a button press, key press, or touch down event. The passed+ serial is used to determine the type of interactive resize (touch,+ pointer, etc).++ The server may ignore resize requests depending on the state of+ the surface (e.g. fullscreen or maximized).++ If triggered, the client will receive configure events with the+ "resize" state enum value and the expected sizes. See the "resize"+ enum value for more details about what is required. The client+ must also acknowledge configure events using "ack_configure". After+ the resize is completed, the client will receive another "configure"+ event without the resize state.++ If triggered, the surface also will lose the focus of the device+ (wl_pointer, wl_touch, etc) used for the resize. It is up to the+ compositor to visually indicate that the resize is taking place,+ such as updating a pointer cursor, during the resize. There is no+ guarantee that the device focus will return when the resize is+ completed.++ The edges parameter specifies how the surface should be resized, and+ is one of the values of the resize_edge enum. Values not matching+ a variant of the enum will cause a protocol error. The compositor+ may use this information to update the surface position for example+ when dragging the top left corner. The compositor may also use+ this information to adapt its behavior, e.g. choose an appropriate+ cursor image.+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>+ <arg name="serial" type="uint" summary="the serial of the user event"/>+ <arg name="edges" type="uint" enum="resize_edge" summary="which edge or corner is being dragged"/>+ </request>++ <enum name="state">+ <description summary="types of state on the surface">+ The different state values used on the surface. This is designed for+ state values like maximized, fullscreen. It is paired with the+ configure event to ensure that both the client and the compositor+ setting the state can be synchronized.++ States set in this way are double-buffered. They will get applied on+ the next commit.+ </description>+ <entry name="maximized" value="1" summary="the surface is maximized">+ <description summary="the surface is maximized">+ The surface is maximized. The window geometry specified in the configure+ event must be obeyed by the client.++ The client should draw without shadow or other+ decoration outside of the window geometry.+ </description>+ </entry>+ <entry name="fullscreen" value="2" summary="the surface is fullscreen">+ <description summary="the surface is fullscreen">+ The surface is fullscreen. The window geometry specified in the+ configure event is a maximum; the client cannot resize beyond it. For+ a surface to cover the whole fullscreened area, the geometry+ dimensions must be obeyed by the client. For more details, see+ xdg_toplevel.set_fullscreen.+ </description>+ </entry>+ <entry name="resizing" value="3" summary="the surface is being resized">+ <description summary="the surface is being resized">+ The surface is being resized. The window geometry specified in the+ configure event is a maximum; the client cannot resize beyond it.+ Clients that have aspect ratio or cell sizing configuration can use+ a smaller size, however.+ </description>+ </entry>+ <entry name="activated" value="4" summary="the surface is now activated">+ <description summary="the surface is now activated">+ Client window decorations should be painted as if the window is+ active. Do not assume this means that the window actually has+ keyboard or pointer focus.+ </description>+ </entry>+ <entry name="tiled_left" value="5" since="2">+ <description summary="the surface’s left edge is tiled">+ The window is currently in a tiled layout and the left edge is+ considered to be adjacent to another part of the tiling grid.+ </description>+ </entry>+ <entry name="tiled_right" value="6" since="2">+ <description summary="the surface’s right edge is tiled">+ The window is currently in a tiled layout and the right edge is+ considered to be adjacent to another part of the tiling grid.+ </description>+ </entry>+ <entry name="tiled_top" value="7" since="2">+ <description summary="the surface’s top edge is tiled">+ The window is currently in a tiled layout and the top edge is+ considered to be adjacent to another part of the tiling grid.+ </description>+ </entry>+ <entry name="tiled_bottom" value="8" since="2">+ <description summary="the surface’s bottom edge is tiled">+ The window is currently in a tiled layout and the bottom edge is+ considered to be adjacent to another part of the tiling grid.+ </description>+ </entry>+ </enum>++ <request name="set_max_size">+ <description summary="set the maximum size">+ Set a maximum size for the window.++ The client can specify a maximum size so that the compositor does+ not try to configure the window beyond this size.++ The width and height arguments are in window geometry coordinates.+ See xdg_surface.set_window_geometry.++ Values set in this way are double-buffered. They will get applied+ on the next commit.++ The compositor can use this information to allow or disallow+ different states like maximize or fullscreen and draw accurate+ animations.++ Similarly, a tiling window manager may use this information to+ place and resize client windows in a more effective way.++ The client should not rely on the compositor to obey the maximum+ size. The compositor may decide to ignore the values set by the+ client and request a larger size.++ If never set, or a value of zero in the request, means that the+ client has no expected maximum size in the given dimension.+ As a result, a client wishing to reset the maximum size+ to an unspecified state can use zero for width and height in the+ request.++ Requesting a maximum size to be smaller than the minimum size of+ a surface is illegal and will result in a protocol error.++ The width and height must be greater than or equal to zero. Using+ strictly negative values for width and height will result in a+ protocol error.+ </description>+ <arg name="width" type="int"/>+ <arg name="height" type="int"/>+ </request>++ <request name="set_min_size">+ <description summary="set the minimum size">+ Set a minimum size for the window.++ The client can specify a minimum size so that the compositor does+ not try to configure the window below this size.++ The width and height arguments are in window geometry coordinates.+ See xdg_surface.set_window_geometry.++ Values set in this way are double-buffered. They will get applied+ on the next commit.++ The compositor can use this information to allow or disallow+ different states like maximize or fullscreen and draw accurate+ animations.++ Similarly, a tiling window manager may use this information to+ place and resize client windows in a more effective way.++ The client should not rely on the compositor to obey the minimum+ size. The compositor may decide to ignore the values set by the+ client and request a smaller size.++ If never set, or a value of zero in the request, means that the+ client has no expected minimum size in the given dimension.+ As a result, a client wishing to reset the minimum size+ to an unspecified state can use zero for width and height in the+ request.++ Requesting a minimum size to be larger than the maximum size of+ a surface is illegal and will result in a protocol error.++ The width and height must be greater than or equal to zero. Using+ strictly negative values for width and height will result in a+ protocol error.+ </description>+ <arg name="width" type="int"/>+ <arg name="height" type="int"/>+ </request>++ <request name="set_maximized">+ <description summary="maximize the window">+ Maximize the surface.++ After requesting that the surface should be maximized, the compositor+ will respond by emitting a configure event. Whether this configure+ actually sets the window maximized is subject to compositor policies.+ The client must then update its content, drawing in the configured+ state. The client must also acknowledge the configure when committing+ the new content (see ack_configure).++ It is up to the compositor to decide how and where to maximize the+ surface, for example which output and what region of the screen should+ be used.++ If the surface was already maximized, the compositor will still emit+ a configure event with the "maximized" state.++ If the surface is in a fullscreen state, this request has no direct+ effect. It may alter the state the surface is returned to when+ unmaximized unless overridden by the compositor.+ </description>+ </request>++ <request name="unset_maximized">+ <description summary="unmaximize the window">+ Unmaximize the surface.++ After requesting that the surface should be unmaximized, the compositor+ will respond by emitting a configure event. Whether this actually+ un-maximizes the window is subject to compositor policies.+ If available and applicable, the compositor will include the window+ geometry dimensions the window had prior to being maximized in the+ configure event. The client must then update its content, drawing it in+ the configured state. The client must also acknowledge the configure+ when committing the new content (see ack_configure).++ It is up to the compositor to position the surface after it was+ unmaximized; usually the position the surface had before maximizing, if+ applicable.++ If the surface was already not maximized, the compositor will still+ emit a configure event without the "maximized" state.++ If the surface is in a fullscreen state, this request has no direct+ effect. It may alter the state the surface is returned to when+ unmaximized unless overridden by the compositor.+ </description>+ </request>++ <request name="set_fullscreen">+ <description summary="set the window as fullscreen on an output">+ Make the surface fullscreen.++ After requesting that the surface should be fullscreened, the+ compositor will respond by emitting a configure event. Whether the+ client is actually put into a fullscreen state is subject to compositor+ policies. The client must also acknowledge the configure when+ committing the new content (see ack_configure).++ The output passed by the request indicates the client's preference as+ to which display it should be set fullscreen on. If this value is NULL,+ it's up to the compositor to choose which display will be used to map+ this surface.++ If the surface doesn't cover the whole output, the compositor will+ position the surface in the center of the output and compensate with+ with border fill covering the rest of the output. The content of the+ border fill is undefined, but should be assumed to be in some way that+ attempts to blend into the surrounding area (e.g. solid black).++ If the fullscreened surface is not opaque, the compositor must make+ sure that other screen content not part of the same surface tree (made+ up of subsurfaces, popups or similarly coupled surfaces) are not+ visible below the fullscreened surface.+ </description>+ <arg name="output" type="object" interface="wl_output" allow-null="true"/>+ </request>++ <request name="unset_fullscreen">+ <description summary="unset the window as fullscreen">+ Make the surface no longer fullscreen.++ After requesting that the surface should be unfullscreened, the+ compositor will respond by emitting a configure event.+ Whether this actually removes the fullscreen state of the client is+ subject to compositor policies.++ Making a surface unfullscreen sets states for the surface based on the following:+ * the state(s) it may have had before becoming fullscreen+ * any state(s) decided by the compositor+ * any state(s) requested by the client while the surface was fullscreen++ The compositor may include the previous window geometry dimensions in+ the configure event, if applicable.++ The client must also acknowledge the configure when committing the new+ content (see ack_configure).+ </description>+ </request>++ <request name="set_minimized">+ <description summary="set the window as minimized">+ Request that the compositor minimize your surface. There is no+ way to know if the surface is currently minimized, nor is there+ any way to unset minimization on this surface.++ If you are looking to throttle redrawing when minimized, please+ instead use the wl_surface.frame event for this, as this will+ also work with live previews on windows in Alt-Tab, Expose or+ similar compositor features.+ </description>+ </request>++ <event name="configure">+ <description summary="suggest a surface change">+ This configure event asks the client to resize its toplevel surface or+ to change its state. The configured state should not be applied+ immediately. See xdg_surface.configure for details.++ The width and height arguments specify a hint to the window+ about how its surface should be resized in window geometry+ coordinates. See set_window_geometry.++ If the width or height arguments are zero, it means the client+ should decide its own window dimension. This may happen when the+ compositor needs to configure the state of the surface but doesn't+ have any information about any previous or expected dimension.++ The states listed in the event specify how the width/height+ arguments should be interpreted, and possibly how it should be+ drawn.++ Clients must send an ack_configure in response to this event. See+ xdg_surface.configure and xdg_surface.ack_configure for details.+ </description>+ <arg name="width" type="int"/>+ <arg name="height" type="int"/>+ <arg name="states" type="array"/>+ </event>++ <event name="close">+ <description summary="surface wants to be closed">+ The close event is sent by the compositor when the user+ wants the surface to be closed. This should be equivalent to+ the user clicking the close button in client-side decorations,+ if your application has any.++ This is only a request that the user intends to close the+ window. The client may choose to ignore this request, or show+ a dialog to ask the user to save their data, etc.+ </description>+ </event>++ <!-- Version 4 additions -->++ <event name="configure_bounds" since="4">+ <description summary="recommended window geometry bounds">+ The configure_bounds event may be sent prior to a xdg_toplevel.configure+ event to communicate the bounds a window geometry size is recommended+ to constrain to.++ The passed width and height are in surface coordinate space. If width+ and height are 0, it means bounds is unknown and equivalent to as if no+ configure_bounds event was ever sent for this surface.++ The bounds can for example correspond to the size of a monitor excluding+ any panels or other shell components, so that a surface isn't created in+ a way that it cannot fit.++ The bounds may change at any point, and in such a case, a new+ xdg_toplevel.configure_bounds will be sent, followed by+ xdg_toplevel.configure and xdg_surface.configure.+ </description>+ <arg name="width" type="int"/>+ <arg name="height" type="int"/>+ </event>+ </interface>++ <interface name="xdg_popup" version="4">+ <description summary="short-lived, popup surfaces for menus">+ A popup surface is a short-lived, temporary surface. It can be used to+ implement for example menus, popovers, tooltips and other similar user+ interface concepts.++ A popup can be made to take an explicit grab. See xdg_popup.grab for+ details.++ When the popup is dismissed, a popup_done event will be sent out, and at+ the same time the surface will be unmapped. See the xdg_popup.popup_done+ event for details.++ Explicitly destroying the xdg_popup object will also dismiss the popup and+ unmap the surface. Clients that want to dismiss the popup when another+ surface of their own is clicked should dismiss the popup using the destroy+ request.++ A newly created xdg_popup will be stacked on top of all previously created+ xdg_popup surfaces associated with the same xdg_toplevel.++ The parent of an xdg_popup must be mapped (see the xdg_surface+ description) before the xdg_popup itself.++ The client must call wl_surface.commit on the corresponding wl_surface+ for the xdg_popup state to take effect.+ </description>++ <enum name="error">+ <entry name="invalid_grab" value="0"+ summary="tried to grab after being mapped"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="remove xdg_popup interface">+ This destroys the popup. Explicitly destroying the xdg_popup+ object will also dismiss the popup, and unmap the surface.++ If this xdg_popup is not the "topmost" popup, a protocol error+ will be sent.+ </description>+ </request>++ <request name="grab">+ <description summary="make the popup take an explicit grab">+ This request makes the created popup take an explicit grab. An explicit+ grab will be dismissed when the user dismisses the popup, or when the+ client destroys the xdg_popup. This can be done by the user clicking+ outside the surface, using the keyboard, or even locking the screen+ through closing the lid or a timeout.++ If the compositor denies the grab, the popup will be immediately+ dismissed.++ This request must be used in response to some sort of user action like a+ button press, key press, or touch down event. The serial number of the+ event should be passed as 'serial'.++ The parent of a grabbing popup must either be an xdg_toplevel surface or+ another xdg_popup with an explicit grab. If the parent is another+ xdg_popup it means that the popups are nested, with this popup now being+ the topmost popup.++ Nested popups must be destroyed in the reverse order they were created+ in, e.g. the only popup you are allowed to destroy at all times is the+ topmost one.++ When compositors choose to dismiss a popup, they may dismiss every+ nested grabbing popup as well. When a compositor dismisses popups, it+ will follow the same dismissing order as required from the client.++ The parent of a grabbing popup must either be another xdg_popup with an+ active explicit grab, or an xdg_popup or xdg_toplevel, if there are no+ explicit grabs already taken.++ If the topmost grabbing popup is destroyed, the grab will be returned to+ the parent of the popup, if that parent previously had an explicit grab.++ If the parent is a grabbing popup which has already been dismissed, this+ popup will be immediately dismissed. If the parent is a popup that did+ not take an explicit grab, an error will be raised.++ During a popup grab, the client owning the grab will receive pointer+ and touch events for all their surfaces as normal (similar to an+ "owner-events" grab in X11 parlance), while the top most grabbing popup+ will always have keyboard focus.+ </description>+ <arg name="seat" type="object" interface="wl_seat"+ summary="the wl_seat of the user event"/>+ <arg name="serial" type="uint" summary="the serial of the user event"/>+ </request>++ <event name="configure">+ <description summary="configure the popup surface">+ This event asks the popup surface to configure itself given the+ configuration. The configured state should not be applied immediately.+ See xdg_surface.configure for details.++ The x and y arguments represent the position the popup was placed at+ given the xdg_positioner rule, relative to the upper left corner of the+ window geometry of the parent surface.++ For version 2 or older, the configure event for an xdg_popup is only+ ever sent once for the initial configuration. Starting with version 3,+ it may be sent again if the popup is setup with an xdg_positioner with+ set_reactive requested, or in response to xdg_popup.reposition requests.+ </description>+ <arg name="x" type="int"+ summary="x position relative to parent surface window geometry"/>+ <arg name="y" type="int"+ summary="y position relative to parent surface window geometry"/>+ <arg name="width" type="int" summary="window geometry width"/>+ <arg name="height" type="int" summary="window geometry height"/>+ </event>++ <event name="popup_done">+ <description summary="popup interaction is done">+ The popup_done event is sent out when a popup is dismissed by the+ compositor. The client should destroy the xdg_popup object at this+ point.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="reposition" since="3">+ <description summary="recalculate the popup's location">+ Reposition an already-mapped popup. The popup will be placed given the+ details in the passed xdg_positioner object, and a+ xdg_popup.repositioned followed by xdg_popup.configure and+ xdg_surface.configure will be emitted in response. Any parameters set+ by the previous positioner will be discarded.++ The passed token will be sent in the corresponding+ xdg_popup.repositioned event. The new popup position will not take+ effect until the corresponding configure event is acknowledged by the+ client. See xdg_popup.repositioned for details. The token itself is+ opaque, and has no other special meaning.++ If multiple reposition requests are sent, the compositor may skip all+ but the last one.++ If the popup is repositioned in response to a configure event for its+ parent, the client should send an xdg_positioner.set_parent_configure+ and possibly an xdg_positioner.set_parent_size request to allow the+ compositor to properly constrain the popup.++ If the popup is repositioned together with a parent that is being+ resized, but not in response to a configure event, the client should+ send an xdg_positioner.set_parent_size request.+ </description>+ <arg name="positioner" type="object" interface="xdg_positioner"/>+ <arg name="token" type="uint" summary="reposition request token"/>+ </request>++ <event name="repositioned" since="3">+ <description summary="signal the completion of a repositioned request">+ The repositioned event is sent as part of a popup configuration+ sequence, together with xdg_popup.configure and lastly+ xdg_surface.configure to notify the completion of a reposition request.++ The repositioned event is to notify about the completion of a+ xdg_popup.reposition request. The token argument is the token passed+ in the xdg_popup.reposition request.++ Immediately after this event is emitted, xdg_popup.configure and+ xdg_surface.configure will be sent with the updated size and position,+ as well as a new configure serial.++ The client should optionally update the content of the popup, but must+ acknowledge the new popup configuration for the new position to take+ effect. See xdg_surface.ack_configure for details.+ </description>+ <arg name="token" type="uint" summary="reposition request token"/>+ </event>++ </interface>+</protocol>
+ examples/simple-client/README.md view
@@ -0,0 +1,65 @@+About+=====++A simple Wayland client. It can be used to test the `simple-server`++Building+========++Use `hws -c hs-wayland-scanner.cfg` to generate the Wayland bindings:++``` shell+cd examples/simple-client+/path/to/hws -c hs-wayland-scanner.cfg+```++Alternatively run:++``` shell+/path/to/hws -p ./ protocols/wayland.xml+```++Now you can build it with `cabal`:++``` shell+cabal [run|build|install]+```++Running+=======++Run with:++``` shell+# change the socket name with the one printed by simple-server+WAYLAND_DISPLAY="wayland-0" /path/to/simple-client+```++or, if there is only one server running:++``` shell+/path/to/simple-client+```++Anyway the client will connect to any server and print the list of+available interfaces++If the connection is successful the client will print something like:++``` shell+Connected!+[CLIENT] Global: wl_compositor (name=1)+[CLIENT] bound compositor+```++wait two seconds and exit.++Documentation+=============++This example exposes a library also to show the documentation+generated by `hws`. To produce the documentation run:++``` shell+cabal haddock+```
+ examples/simple-client/hs-wayland-scanner.cfg view
@@ -0,0 +1,8 @@+HwsConfig+ { genPrefix = "./"+ , hsNameSpace = "Graphics"+ , protoRole = Client+ , protocols = ["protocols/wayland.xml"]+ , cbitsPrefix = "cbits"+ , srcPrefix = "src"+ }
+ examples/simple-client/protocols/wayland.xml view
@@ -0,0 +1,3151 @@+<?xml version="1.0" encoding="UTF-8"?>+<protocol name="wayland">++ <copyright>+ Copyright © 2008-2011 Kristian Høgsberg+ Copyright © 2010-2011 Intel Corporation+ Copyright © 2012-2013 Collabora, Ltd.++ Permission is hereby granted, free of charge, to any person+ obtaining a copy of this software and associated documentation files+ (the "Software"), to deal in the Software without restriction,+ including without limitation the rights to use, copy, modify, merge,+ publish, distribute, sublicense, and/or sell copies of the Software,+ and to permit persons to whom the Software is furnished to do so,+ subject to the following conditions:++ The above copyright notice and this permission notice (including the+ next paragraph) shall be included in all copies or substantial+ portions of the Software.++ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE+ SOFTWARE.+ </copyright>++ <interface name="wl_display" version="1">+ <description summary="core global object">+ The core global object. This is a special singleton object. It+ is used for internal Wayland protocol features.+ </description>++ <request name="sync">+ <description summary="asynchronous roundtrip">+ The sync request asks the server to emit the 'done' event+ on the returned wl_callback object. Since requests are+ handled in-order and events are delivered in-order, this can+ be used as a barrier to ensure all previous requests and the+ resulting events have been handled.++ The object returned by this request will be destroyed by the+ compositor after the callback is fired and as such the client must not+ attempt to use it after that point.++ The callback_data passed in the callback is the event serial.+ </description>+ <arg name="callback" type="new_id" interface="wl_callback"+ summary="callback object for the sync request"/>+ </request>++ <request name="get_registry">+ <description summary="get global registry object">+ This request creates a registry object that allows the client+ to list and bind the global objects available from the+ compositor.++ It should be noted that the server side resources consumed in+ response to a get_registry request can only be released when the+ client disconnects, not when the client side proxy is destroyed.+ Therefore, clients should invoke get_registry as infrequently as+ possible to avoid wasting memory.+ </description>+ <arg name="registry" type="new_id" interface="wl_registry"+ summary="global registry object"/>+ </request>++ <event name="error">+ <description summary="fatal error event">+ The error event is sent out when a fatal (non-recoverable)+ error has occurred. The object_id argument is the object+ where the error occurred, most often in response to a request+ to that object. The code identifies the error and is defined+ by the object interface. As such, each interface defines its+ own set of error codes. The message is a brief description+ of the error, for (debugging) convenience.+ </description>+ <arg name="object_id" type="object" summary="object where the error occurred"/>+ <arg name="code" type="uint" summary="error code"/>+ <arg name="message" type="string" summary="error description"/>+ </event>++ <enum name="error">+ <description summary="global error values">+ These errors are global and can be emitted in response to any+ server request.+ </description>+ <entry name="invalid_object" value="0"+ summary="server couldn't find object"/>+ <entry name="invalid_method" value="1"+ summary="method doesn't exist on the specified interface or malformed request"/>+ <entry name="no_memory" value="2"+ summary="server is out of memory"/>+ <entry name="implementation" value="3"+ summary="implementation error in compositor"/>+ </enum>++ <event name="delete_id">+ <description summary="acknowledge object ID deletion">+ This event is used internally by the object ID management+ logic. When a client deletes an object that it had created,+ the server will send this event to acknowledge that it has+ seen the delete request. When the client receives this event,+ it will know that it can safely reuse the object ID.+ </description>+ <arg name="id" type="uint" summary="deleted object ID"/>+ </event>+ </interface>++ <interface name="wl_registry" version="1">+ <description summary="global registry object">+ The singleton global registry object. The server has a number of+ global objects that are available to all clients. These objects+ typically represent an actual object in the server (for example,+ an input device) or they are singleton objects that provide+ extension functionality.++ When a client creates a registry object, the registry object+ will emit a global event for each global currently in the+ registry. Globals come and go as a result of device or+ monitor hotplugs, reconfiguration or other events, and the+ registry will send out global and global_remove events to+ keep the client up to date with the changes. To mark the end+ of the initial burst of events, the client can use the+ wl_display.sync request immediately after calling+ wl_display.get_registry.++ A client can bind to a global object by using the bind+ request. This creates a client-side handle that lets the object+ emit events to the client and lets the client invoke requests on+ the object.+ </description>++ <request name="bind">+ <description summary="bind an object to the display">+ Binds a new, client-created object to the server using the+ specified name as the identifier.+ </description>+ <arg name="name" type="uint" summary="unique numeric name of the object"/>+ <arg name="id" type="new_id" summary="bounded object"/>+ </request>++ <event name="global">+ <description summary="announce global object">+ Notify the client of global objects.++ The event notifies the client that a global object with+ the given name is now available, and it implements the+ given version of the given interface.+ </description>+ <arg name="name" type="uint" summary="numeric name of the global object"/>+ <arg name="interface" type="string" summary="interface implemented by the object"/>+ <arg name="version" type="uint" summary="interface version"/>+ </event>++ <event name="global_remove">+ <description summary="announce removal of global object">+ Notify the client of removed global objects.++ This event notifies the client that the global identified+ by name is no longer available. If the client bound to+ the global using the bind request, the client should now+ destroy that object.++ The object remains valid and requests to the object will be+ ignored until the client destroys it, to avoid races between+ the global going away and a client sending a request to it.+ </description>+ <arg name="name" type="uint" summary="numeric name of the global object"/>+ </event>+ </interface>++ <interface name="wl_callback" version="1">+ <description summary="callback object">+ Clients can handle the 'done' event to get notified when+ the related request is done.++ Note, because wl_callback objects are created from multiple independent+ factory interfaces, the wl_callback interface is frozen at version 1.+ </description>++ <event name="done" type="destructor">+ <description summary="done event">+ Notify the client when the related request is done.+ </description>+ <arg name="callback_data" type="uint" summary="request-specific data for the callback"/>+ </event>+ </interface>++ <interface name="wl_compositor" version="6">+ <description summary="the compositor singleton">+ A compositor. This object is a singleton global. The+ compositor is in charge of combining the contents of multiple+ surfaces into one displayable output.+ </description>++ <request name="create_surface">+ <description summary="create new surface">+ Ask the compositor to create a new surface.+ </description>+ <arg name="id" type="new_id" interface="wl_surface" summary="the new surface"/>+ </request>++ <request name="create_region">+ <description summary="create new region">+ Ask the compositor to create a new region.+ </description>+ <arg name="id" type="new_id" interface="wl_region" summary="the new region"/>+ </request>+ </interface>++ <interface name="wl_shm_pool" version="1">+ <description summary="a shared memory pool">+ The wl_shm_pool object encapsulates a piece of memory shared+ between the compositor and client. Through the wl_shm_pool+ object, the client can allocate shared memory wl_buffer objects.+ All objects created through the same pool share the same+ underlying mapped memory. Reusing the mapped memory avoids the+ setup/teardown overhead and is useful when interactively resizing+ a surface or for many small buffers.+ </description>++ <request name="create_buffer">+ <description summary="create a buffer from the pool">+ Create a wl_buffer object from the pool.++ The buffer is created offset bytes into the pool and has+ width and height as specified. The stride argument specifies+ the number of bytes from the beginning of one row to the beginning+ of the next. The format is the pixel format of the buffer and+ must be one of those advertised through the wl_shm.format event.++ A buffer will keep a reference to the pool it was created from+ so it is valid to destroy the pool immediately after creating+ a buffer from it.+ </description>+ <arg name="id" type="new_id" interface="wl_buffer" summary="buffer to create"/>+ <arg name="offset" type="int" summary="buffer byte offset within the pool"/>+ <arg name="width" type="int" summary="buffer width, in pixels"/>+ <arg name="height" type="int" summary="buffer height, in pixels"/>+ <arg name="stride" type="int" summary="number of bytes from the beginning of one row to the beginning of the next row"/>+ <arg name="format" type="uint" enum="wl_shm.format" summary="buffer pixel format"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy the pool">+ Destroy the shared memory pool.++ The mmapped memory will be released when all+ buffers that have been created from this pool+ are gone.+ </description>+ </request>++ <request name="resize">+ <description summary="change the size of the pool mapping">+ This request will cause the server to remap the backing memory+ for the pool from the file descriptor passed when the pool was+ created, but using the new size. This request can only be+ used to make the pool bigger.++ This request only changes the amount of bytes that are mmapped+ by the server and does not touch the file corresponding to the+ file descriptor passed at creation time. It is the client's+ responsibility to ensure that the file is at least as big as+ the new pool size.+ </description>+ <arg name="size" type="int" summary="new size of the pool, in bytes"/>+ </request>+ </interface>++ <interface name="wl_shm" version="1">+ <description summary="shared memory support">+ A singleton global object that provides support for shared+ memory.++ Clients can create wl_shm_pool objects using the create_pool+ request.++ On binding the wl_shm object one or more format events+ are emitted to inform clients about the valid pixel formats+ that can be used for buffers.+ </description>++ <enum name="error">+ <description summary="wl_shm error values">+ These errors can be emitted in response to wl_shm requests.+ </description>+ <entry name="invalid_format" value="0" summary="buffer format is not known"/>+ <entry name="invalid_stride" value="1" summary="invalid size or stride during pool or buffer creation"/>+ <entry name="invalid_fd" value="2" summary="mmapping the file descriptor failed"/>+ </enum>++ <enum name="format">+ <description summary="pixel formats">+ This describes the memory layout of an individual pixel.++ All renderers should support argb8888 and xrgb8888 but any other+ formats are optional and may not be supported by the particular+ renderer in use.++ The drm format codes match the macros defined in drm_fourcc.h, except+ argb8888 and xrgb8888. The formats actually supported by the compositor+ will be reported by the format event.++ For all wl_shm formats and unless specified in another protocol+ extension, pre-multiplied alpha is used for pixel values.+ </description>+ <!-- Note to protocol writers: don't update this list manually, instead+ run the automated script that keeps it in sync with drm_fourcc.h. -->+ <entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>+ <entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>+ <entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>+ <entry name="rgb332" value="0x38424752" summary="8-bit RGB format, [7:0] R:G:B 3:3:2"/>+ <entry name="bgr233" value="0x38524742" summary="8-bit BGR format, [7:0] B:G:R 2:3:3"/>+ <entry name="xrgb4444" value="0x32315258" summary="16-bit xRGB format, [15:0] x:R:G:B 4:4:4:4 little endian"/>+ <entry name="xbgr4444" value="0x32314258" summary="16-bit xBGR format, [15:0] x:B:G:R 4:4:4:4 little endian"/>+ <entry name="rgbx4444" value="0x32315852" summary="16-bit RGBx format, [15:0] R:G:B:x 4:4:4:4 little endian"/>+ <entry name="bgrx4444" value="0x32315842" summary="16-bit BGRx format, [15:0] B:G:R:x 4:4:4:4 little endian"/>+ <entry name="argb4444" value="0x32315241" summary="16-bit ARGB format, [15:0] A:R:G:B 4:4:4:4 little endian"/>+ <entry name="abgr4444" value="0x32314241" summary="16-bit ABGR format, [15:0] A:B:G:R 4:4:4:4 little endian"/>+ <entry name="rgba4444" value="0x32314152" summary="16-bit RBGA format, [15:0] R:G:B:A 4:4:4:4 little endian"/>+ <entry name="bgra4444" value="0x32314142" summary="16-bit BGRA format, [15:0] B:G:R:A 4:4:4:4 little endian"/>+ <entry name="xrgb1555" value="0x35315258" summary="16-bit xRGB format, [15:0] x:R:G:B 1:5:5:5 little endian"/>+ <entry name="xbgr1555" value="0x35314258" summary="16-bit xBGR 1555 format, [15:0] x:B:G:R 1:5:5:5 little endian"/>+ <entry name="rgbx5551" value="0x35315852" summary="16-bit RGBx 5551 format, [15:0] R:G:B:x 5:5:5:1 little endian"/>+ <entry name="bgrx5551" value="0x35315842" summary="16-bit BGRx 5551 format, [15:0] B:G:R:x 5:5:5:1 little endian"/>+ <entry name="argb1555" value="0x35315241" summary="16-bit ARGB 1555 format, [15:0] A:R:G:B 1:5:5:5 little endian"/>+ <entry name="abgr1555" value="0x35314241" summary="16-bit ABGR 1555 format, [15:0] A:B:G:R 1:5:5:5 little endian"/>+ <entry name="rgba5551" value="0x35314152" summary="16-bit RGBA 5551 format, [15:0] R:G:B:A 5:5:5:1 little endian"/>+ <entry name="bgra5551" value="0x35314142" summary="16-bit BGRA 5551 format, [15:0] B:G:R:A 5:5:5:1 little endian"/>+ <entry name="rgb565" value="0x36314752" summary="16-bit RGB 565 format, [15:0] R:G:B 5:6:5 little endian"/>+ <entry name="bgr565" value="0x36314742" summary="16-bit BGR 565 format, [15:0] B:G:R 5:6:5 little endian"/>+ <entry name="rgb888" value="0x34324752" summary="24-bit RGB format, [23:0] R:G:B little endian"/>+ <entry name="bgr888" value="0x34324742" summary="24-bit BGR format, [23:0] B:G:R little endian"/>+ <entry name="xbgr8888" value="0x34324258" summary="32-bit xBGR format, [31:0] x:B:G:R 8:8:8:8 little endian"/>+ <entry name="rgbx8888" value="0x34325852" summary="32-bit RGBx format, [31:0] R:G:B:x 8:8:8:8 little endian"/>+ <entry name="bgrx8888" value="0x34325842" summary="32-bit BGRx format, [31:0] B:G:R:x 8:8:8:8 little endian"/>+ <entry name="abgr8888" value="0x34324241" summary="32-bit ABGR format, [31:0] A:B:G:R 8:8:8:8 little endian"/>+ <entry name="rgba8888" value="0x34324152" summary="32-bit RGBA format, [31:0] R:G:B:A 8:8:8:8 little endian"/>+ <entry name="bgra8888" value="0x34324142" summary="32-bit BGRA format, [31:0] B:G:R:A 8:8:8:8 little endian"/>+ <entry name="xrgb2101010" value="0x30335258" summary="32-bit xRGB format, [31:0] x:R:G:B 2:10:10:10 little endian"/>+ <entry name="xbgr2101010" value="0x30334258" summary="32-bit xBGR format, [31:0] x:B:G:R 2:10:10:10 little endian"/>+ <entry name="rgbx1010102" value="0x30335852" summary="32-bit RGBx format, [31:0] R:G:B:x 10:10:10:2 little endian"/>+ <entry name="bgrx1010102" value="0x30335842" summary="32-bit BGRx format, [31:0] B:G:R:x 10:10:10:2 little endian"/>+ <entry name="argb2101010" value="0x30335241" summary="32-bit ARGB format, [31:0] A:R:G:B 2:10:10:10 little endian"/>+ <entry name="abgr2101010" value="0x30334241" summary="32-bit ABGR format, [31:0] A:B:G:R 2:10:10:10 little endian"/>+ <entry name="rgba1010102" value="0x30334152" summary="32-bit RGBA format, [31:0] R:G:B:A 10:10:10:2 little endian"/>+ <entry name="bgra1010102" value="0x30334142" summary="32-bit BGRA format, [31:0] B:G:R:A 10:10:10:2 little endian"/>+ <entry name="yuyv" value="0x56595559" summary="packed YCbCr format, [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian"/>+ <entry name="yvyu" value="0x55595659" summary="packed YCbCr format, [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian"/>+ <entry name="uyvy" value="0x59565955" summary="packed YCbCr format, [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian"/>+ <entry name="vyuy" value="0x59555956" summary="packed YCbCr format, [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian"/>+ <entry name="ayuv" value="0x56555941" summary="packed AYCbCr format, [31:0] A:Y:Cb:Cr 8:8:8:8 little endian"/>+ <entry name="nv12" value="0x3231564e" summary="2 plane YCbCr Cr:Cb format, 2x2 subsampled Cr:Cb plane"/>+ <entry name="nv21" value="0x3132564e" summary="2 plane YCbCr Cb:Cr format, 2x2 subsampled Cb:Cr plane"/>+ <entry name="nv16" value="0x3631564e" summary="2 plane YCbCr Cr:Cb format, 2x1 subsampled Cr:Cb plane"/>+ <entry name="nv61" value="0x3136564e" summary="2 plane YCbCr Cb:Cr format, 2x1 subsampled Cb:Cr plane"/>+ <entry name="yuv410" value="0x39565559" summary="3 plane YCbCr format, 4x4 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu410" value="0x39555659" summary="3 plane YCbCr format, 4x4 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv411" value="0x31315559" summary="3 plane YCbCr format, 4x1 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu411" value="0x31315659" summary="3 plane YCbCr format, 4x1 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv420" value="0x32315559" summary="3 plane YCbCr format, 2x2 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu420" value="0x32315659" summary="3 plane YCbCr format, 2x2 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv422" value="0x36315559" summary="3 plane YCbCr format, 2x1 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu422" value="0x36315659" summary="3 plane YCbCr format, 2x1 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv444" value="0x34325559" summary="3 plane YCbCr format, non-subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu444" value="0x34325659" summary="3 plane YCbCr format, non-subsampled Cr (1) and Cb (2) planes"/>+ <entry name="r8" value="0x20203852" summary="[7:0] R"/>+ <entry name="r16" value="0x20363152" summary="[15:0] R little endian"/>+ <entry name="rg88" value="0x38384752" summary="[15:0] R:G 8:8 little endian"/>+ <entry name="gr88" value="0x38385247" summary="[15:0] G:R 8:8 little endian"/>+ <entry name="rg1616" value="0x32334752" summary="[31:0] R:G 16:16 little endian"/>+ <entry name="gr1616" value="0x32335247" summary="[31:0] G:R 16:16 little endian"/>+ <entry name="xrgb16161616f" value="0x48345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>+ <entry name="xbgr16161616f" value="0x48344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>+ <entry name="argb16161616f" value="0x48345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>+ <entry name="abgr16161616f" value="0x48344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>+ <entry name="xyuv8888" value="0x56555958" summary="[31:0] X:Y:Cb:Cr 8:8:8:8 little endian"/>+ <entry name="vuy888" value="0x34325556" summary="[23:0] Cr:Cb:Y 8:8:8 little endian"/>+ <entry name="vuy101010" value="0x30335556" summary="Y followed by U then V, 10:10:10. Non-linear modifier only"/>+ <entry name="y210" value="0x30313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 10:6:10:6:10:6:10:6 little endian per 2 Y pixels"/>+ <entry name="y212" value="0x32313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 12:4:12:4:12:4:12:4 little endian per 2 Y pixels"/>+ <entry name="y216" value="0x36313259" summary="[63:0] Cr0:Y1:Cb0:Y0 16:16:16:16 little endian per 2 Y pixels"/>+ <entry name="y410" value="0x30313459" summary="[31:0] A:Cr:Y:Cb 2:10:10:10 little endian"/>+ <entry name="y412" value="0x32313459" summary="[63:0] A:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>+ <entry name="y416" value="0x36313459" summary="[63:0] A:Cr:Y:Cb 16:16:16:16 little endian"/>+ <entry name="xvyu2101010" value="0x30335658" summary="[31:0] X:Cr:Y:Cb 2:10:10:10 little endian"/>+ <entry name="xvyu12_16161616" value="0x36335658" summary="[63:0] X:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>+ <entry name="xvyu16161616" value="0x38345658" summary="[63:0] X:Cr:Y:Cb 16:16:16:16 little endian"/>+ <entry name="y0l0" value="0x304c3059" summary="[63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>+ <entry name="x0l0" value="0x304c3058" summary="[63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>+ <entry name="y0l2" value="0x324c3059" summary="[63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian"/>+ <entry name="x0l2" value="0x324c3058" summary="[63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian"/>+ <entry name="yuv420_8bit" value="0x38305559"/>+ <entry name="yuv420_10bit" value="0x30315559"/>+ <entry name="xrgb8888_a8" value="0x38415258"/>+ <entry name="xbgr8888_a8" value="0x38414258"/>+ <entry name="rgbx8888_a8" value="0x38415852"/>+ <entry name="bgrx8888_a8" value="0x38415842"/>+ <entry name="rgb888_a8" value="0x38413852"/>+ <entry name="bgr888_a8" value="0x38413842"/>+ <entry name="rgb565_a8" value="0x38413552"/>+ <entry name="bgr565_a8" value="0x38413542"/>+ <entry name="nv24" value="0x3432564e" summary="non-subsampled Cr:Cb plane"/>+ <entry name="nv42" value="0x3234564e" summary="non-subsampled Cb:Cr plane"/>+ <entry name="p210" value="0x30313250" summary="2x1 subsampled Cr:Cb plane, 10 bit per channel"/>+ <entry name="p010" value="0x30313050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel"/>+ <entry name="p012" value="0x32313050" summary="2x2 subsampled Cr:Cb plane 12 bits per channel"/>+ <entry name="p016" value="0x36313050" summary="2x2 subsampled Cr:Cb plane 16 bits per channel"/>+ <entry name="axbxgxrx106106106106" value="0x30314241" summary="[63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian"/>+ <entry name="nv15" value="0x3531564e" summary="2x2 subsampled Cr:Cb plane"/>+ <entry name="q410" value="0x30313451"/>+ <entry name="q401" value="0x31303451"/>+ <entry name="xrgb16161616" value="0x38345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>+ <entry name="xbgr16161616" value="0x38344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>+ <entry name="argb16161616" value="0x38345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>+ <entry name="abgr16161616" value="0x38344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>+ </enum>++ <request name="create_pool">+ <description summary="create a shm pool">+ Create a new wl_shm_pool object.++ The pool can be used to create shared memory based buffer+ objects. The server will mmap size bytes of the passed file+ descriptor, to use as backing memory for the pool.+ </description>+ <arg name="id" type="new_id" interface="wl_shm_pool" summary="pool to create"/>+ <arg name="fd" type="fd" summary="file descriptor for the pool"/>+ <arg name="size" type="int" summary="pool size, in bytes"/>+ </request>++ <event name="format">+ <description summary="pixel format description">+ Informs the client about a valid pixel format that+ can be used for buffers. Known formats include+ argb8888 and xrgb8888.+ </description>+ <arg name="format" type="uint" enum="format" summary="buffer pixel format"/>+ </event>+ </interface>++ <interface name="wl_buffer" version="1">+ <description summary="content for a wl_surface">+ A buffer provides the content for a wl_surface. Buffers are+ created through factory interfaces such as wl_shm, wp_linux_buffer_params+ (from the linux-dmabuf protocol extension) or similar. It has a width and+ a height and can be attached to a wl_surface, but the mechanism by which a+ client provides and updates the contents is defined by the buffer factory+ interface.++ If the buffer uses a format that has an alpha channel, the alpha channel+ is assumed to be premultiplied in the color channels unless otherwise+ specified.++ Note, because wl_buffer objects are created from multiple independent+ factory interfaces, the wl_buffer interface is frozen at version 1.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy a buffer">+ Destroy a buffer. If and how you need to release the backing+ storage is defined by the buffer factory interface.++ For possible side-effects to a surface, see wl_surface.attach.+ </description>+ </request>++ <event name="release">+ <description summary="compositor releases buffer">+ Sent when this wl_buffer is no longer used by the compositor.+ The client is now free to reuse or destroy this buffer and its+ backing storage.++ If a client receives a release event before the frame callback+ requested in the same wl_surface.commit that attaches this+ wl_buffer to a surface, then the client is immediately free to+ reuse the buffer and its backing storage, and does not need a+ second buffer for the next surface content update. Typically+ this is possible, when the compositor maintains a copy of the+ wl_surface contents, e.g. as a GL texture. This is an important+ optimization for GL(ES) compositors with wl_shm clients.+ </description>+ </event>+ </interface>++ <interface name="wl_data_offer" version="3">+ <description summary="offer to transfer data">+ A wl_data_offer represents a piece of data offered for transfer+ by another client (the source client). It is used by the+ copy-and-paste and drag-and-drop mechanisms. The offer+ describes the different mime types that the data can be+ converted to and provides the mechanism for transferring the+ data directly from the source client.+ </description>++ <enum name="error">+ <entry name="invalid_finish" value="0"+ summary="finish request was called untimely"/>+ <entry name="invalid_action_mask" value="1"+ summary="action mask contains invalid values"/>+ <entry name="invalid_action" value="2"+ summary="action argument has an invalid value"/>+ <entry name="invalid_offer" value="3"+ summary="offer doesn't accept this request"/>+ </enum>++ <request name="accept">+ <description summary="accept one of the offered mime types">+ Indicate that the client can accept the given mime type, or+ NULL for not accepted.++ For objects of version 2 or older, this request is used by the+ client to give feedback whether the client can receive the given+ mime type, or NULL if none is accepted; the feedback does not+ determine whether the drag-and-drop operation succeeds or not.++ For objects of version 3 or newer, this request determines the+ final result of the drag-and-drop operation. If the end result+ is that no mime types were accepted, the drag-and-drop operation+ will be cancelled and the corresponding drag source will receive+ wl_data_source.cancelled. Clients may still use this event in+ conjunction with wl_data_source.action for feedback.+ </description>+ <arg name="serial" type="uint" summary="serial number of the accept request"/>+ <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the client"/>+ </request>++ <request name="receive">+ <description summary="request that the data is transferred">+ To transfer the offered data, the client issues this request+ and indicates the mime type it wants to receive. The transfer+ happens through the passed file descriptor (typically created+ with the pipe system call). The source client writes the data+ in the mime type representation requested and then closes the+ file descriptor.++ The receiving client reads from the read end of the pipe until+ EOF and then closes its end, at which point the transfer is+ complete.++ This request may happen multiple times for different mime types,+ both before and after wl_data_device.drop. Drag-and-drop destination+ clients may preemptively fetch data or examine it more closely to+ determine acceptance.+ </description>+ <arg name="mime_type" type="string" summary="mime type desired by receiver"/>+ <arg name="fd" type="fd" summary="file descriptor for data transfer"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy data offer">+ Destroy the data offer.+ </description>+ </request>++ <event name="offer">+ <description summary="advertise offered mime type">+ Sent immediately after creating the wl_data_offer object. One+ event per offered mime type.+ </description>+ <arg name="mime_type" type="string" summary="offered mime type"/>+ </event>++ <!-- Version 3 additions -->++ <request name="finish" since="3">+ <description summary="the offer will no longer be used">+ Notifies the compositor that the drag destination successfully+ finished the drag-and-drop operation.++ Upon receiving this request, the compositor will emit+ wl_data_source.dnd_finished on the drag source client.++ It is a client error to perform other requests than+ wl_data_offer.destroy after this one. It is also an error to perform+ this request after a NULL mime type has been set in+ wl_data_offer.accept or no action was received through+ wl_data_offer.action.++ If wl_data_offer.finish request is received for a non drag and drop+ operation, the invalid_finish protocol error is raised.+ </description>+ </request>++ <request name="set_actions" since="3">+ <description summary="set the available/preferred drag-and-drop actions">+ Sets the actions that the destination side client supports for+ this operation. This request may trigger the emission of+ wl_data_source.action and wl_data_offer.action events if the compositor+ needs to change the selected action.++ This request can be called multiple times throughout the+ drag-and-drop operation, typically in response to wl_data_device.enter+ or wl_data_device.motion events.++ This request determines the final result of the drag-and-drop+ operation. If the end result is that no action is accepted,+ the drag source will receive wl_data_source.cancelled.++ The dnd_actions argument must contain only values expressed in the+ wl_data_device_manager.dnd_actions enum, and the preferred_action+ argument must only contain one of those values set, otherwise it+ will result in a protocol error.++ While managing an "ask" action, the destination drag-and-drop client+ may perform further wl_data_offer.receive requests, and is expected+ to perform one last wl_data_offer.set_actions request with a preferred+ action other than "ask" (and optionally wl_data_offer.accept) before+ requesting wl_data_offer.finish, in order to convey the action selected+ by the user. If the preferred action is not in the+ wl_data_offer.source_actions mask, an error will be raised.++ If the "ask" action is dismissed (e.g. user cancellation), the client+ is expected to perform wl_data_offer.destroy right away.++ This request can only be made on drag-and-drop offers, a protocol error+ will be raised otherwise.+ </description>+ <arg name="dnd_actions" type="uint" summary="actions supported by the destination client"+ enum="wl_data_device_manager.dnd_action"/>+ <arg name="preferred_action" type="uint" summary="action preferred by the destination client"+ enum="wl_data_device_manager.dnd_action"/>+ </request>++ <event name="source_actions" since="3">+ <description summary="notify the source-side available actions">+ This event indicates the actions offered by the data source. It+ will be sent immediately after creating the wl_data_offer object,+ or anytime the source side changes its offered actions through+ wl_data_source.set_actions.+ </description>+ <arg name="source_actions" type="uint" summary="actions offered by the data source"+ enum="wl_data_device_manager.dnd_action"/>+ </event>++ <event name="action" since="3">+ <description summary="notify the selected action">+ This event indicates the action selected by the compositor after+ matching the source/destination side actions. Only one action (or+ none) will be offered here.++ This event can be emitted multiple times during the drag-and-drop+ operation in response to destination side action changes through+ wl_data_offer.set_actions.++ This event will no longer be emitted after wl_data_device.drop+ happened on the drag-and-drop destination, the client must+ honor the last action received, or the last preferred one set+ through wl_data_offer.set_actions when handling an "ask" action.++ Compositors may also change the selected action on the fly, mainly+ in response to keyboard modifier changes during the drag-and-drop+ operation.++ The most recent action received is always the valid one. Prior to+ receiving wl_data_device.drop, the chosen action may change (e.g.+ due to keyboard modifiers being pressed). At the time of receiving+ wl_data_device.drop the drag-and-drop destination must honor the+ last action received.++ Action changes may still happen after wl_data_device.drop,+ especially on "ask" actions, where the drag-and-drop destination+ may choose another action afterwards. Action changes happening+ at this stage are always the result of inter-client negotiation, the+ compositor shall no longer be able to induce a different action.++ Upon "ask" actions, it is expected that the drag-and-drop destination+ may potentially choose a different action and/or mime type,+ based on wl_data_offer.source_actions and finally chosen by the+ user (e.g. popping up a menu with the available options). The+ final wl_data_offer.set_actions and wl_data_offer.accept requests+ must happen before the call to wl_data_offer.finish.+ </description>+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"+ enum="wl_data_device_manager.dnd_action"/>+ </event>+ </interface>++ <interface name="wl_data_source" version="3">+ <description summary="offer to transfer data">+ The wl_data_source object is the source side of a wl_data_offer.+ It is created by the source client in a data transfer and+ provides a way to describe the offered data and a way to respond+ to requests to transfer the data.+ </description>++ <enum name="error">+ <entry name="invalid_action_mask" value="0"+ summary="action mask contains invalid values"/>+ <entry name="invalid_source" value="1"+ summary="source doesn't accept this request"/>+ </enum>++ <request name="offer">+ <description summary="add an offered mime type">+ This request adds a mime type to the set of mime types+ advertised to targets. Can be called several times to offer+ multiple types.+ </description>+ <arg name="mime_type" type="string" summary="mime type offered by the data source"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy the data source">+ Destroy the data source.+ </description>+ </request>++ <event name="target">+ <description summary="a target accepts an offered mime type">+ Sent when a target accepts pointer_focus or motion events. If+ a target does not accept any of the offered types, type is NULL.++ Used for feedback during drag-and-drop.+ </description>+ <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the target"/>+ </event>++ <event name="send">+ <description summary="send the data">+ Request for data from the client. Send the data as the+ specified mime type over the passed file descriptor, then+ close it.+ </description>+ <arg name="mime_type" type="string" summary="mime type for the data"/>+ <arg name="fd" type="fd" summary="file descriptor for the data"/>+ </event>++ <event name="cancelled">+ <description summary="selection was cancelled">+ This data source is no longer valid. There are several reasons why+ this could happen:++ - The data source has been replaced by another data source.+ - The drag-and-drop operation was performed, but the drop destination+ did not accept any of the mime types offered through+ wl_data_source.target.+ - The drag-and-drop operation was performed, but the drop destination+ did not select any of the actions present in the mask offered through+ wl_data_source.action.+ - The drag-and-drop operation was performed but didn't happen over a+ surface.+ - The compositor cancelled the drag-and-drop operation (e.g. compositor+ dependent timeouts to avoid stale drag-and-drop transfers).++ The client should clean up and destroy this data source.++ For objects of version 2 or older, wl_data_source.cancelled will+ only be emitted if the data source was replaced by another data+ source.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="set_actions" since="3">+ <description summary="set the available drag-and-drop actions">+ Sets the actions that the source side client supports for this+ operation. This request may trigger wl_data_source.action and+ wl_data_offer.action events if the compositor needs to change the+ selected action.++ The dnd_actions argument must contain only values expressed in the+ wl_data_device_manager.dnd_actions enum, otherwise it will result+ in a protocol error.++ This request must be made once only, and can only be made on sources+ used in drag-and-drop, so it must be performed before+ wl_data_device.start_drag. Attempting to use the source other than+ for drag-and-drop will raise a protocol error.+ </description>+ <arg name="dnd_actions" type="uint" summary="actions supported by the data source"+ enum="wl_data_device_manager.dnd_action"/>+ </request>++ <event name="dnd_drop_performed" since="3">+ <description summary="the drag-and-drop operation physically finished">+ The user performed the drop action. This event does not indicate+ acceptance, wl_data_source.cancelled may still be emitted afterwards+ if the drop destination does not accept any mime type.++ However, this event might however not be received if the compositor+ cancelled the drag-and-drop operation before this event could happen.++ Note that the data_source may still be used in the future and should+ not be destroyed here.+ </description>+ </event>++ <event name="dnd_finished" since="3">+ <description summary="the drag-and-drop operation concluded">+ The drop destination finished interoperating with this data+ source, so the client is now free to destroy this data source and+ free all associated data.++ If the action used to perform the operation was "move", the+ source can now delete the transferred data.+ </description>+ </event>++ <event name="action" since="3">+ <description summary="notify the selected action">+ This event indicates the action selected by the compositor after+ matching the source/destination side actions. Only one action (or+ none) will be offered here.++ This event can be emitted multiple times during the drag-and-drop+ operation, mainly in response to destination side changes through+ wl_data_offer.set_actions, and as the data device enters/leaves+ surfaces.++ It is only possible to receive this event after+ wl_data_source.dnd_drop_performed if the drag-and-drop operation+ ended in an "ask" action, in which case the final wl_data_source.action+ event will happen immediately before wl_data_source.dnd_finished.++ Compositors may also change the selected action on the fly, mainly+ in response to keyboard modifier changes during the drag-and-drop+ operation.++ The most recent action received is always the valid one. The chosen+ action may change alongside negotiation (e.g. an "ask" action can turn+ into a "move" operation), so the effects of the final action must+ always be applied in wl_data_offer.dnd_finished.++ Clients can trigger cursor surface changes from this point, so+ they reflect the current action.+ </description>+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"+ enum="wl_data_device_manager.dnd_action"/>+ </event>+ </interface>++ <interface name="wl_data_device" version="3">+ <description summary="data transfer device">+ There is one wl_data_device per seat which can be obtained+ from the global wl_data_device_manager singleton.++ A wl_data_device provides access to inter-client data transfer+ mechanisms such as copy-and-paste and drag-and-drop.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="start_drag">+ <description summary="start drag-and-drop operation">+ This request asks the compositor to start a drag-and-drop+ operation on behalf of the client.++ The source argument is the data source that provides the data+ for the eventual data transfer. If source is NULL, enter, leave+ and motion events are sent only to the client that initiated the+ drag and the client is expected to handle the data passing+ internally. If source is destroyed, the drag-and-drop session will be+ cancelled.++ The origin surface is the surface where the drag originates and+ the client must have an active implicit grab that matches the+ serial.++ The icon surface is an optional (can be NULL) surface that+ provides an icon to be moved around with the cursor. Initially,+ the top-left corner of the icon surface is placed at the cursor+ hotspot, but subsequent wl_surface.attach request can move the+ relative position. Attach requests must be confirmed with+ wl_surface.commit as usual. The icon surface is given the role of+ a drag-and-drop icon. If the icon surface already has another role,+ it raises a protocol error.++ The input region is ignored for wl_surfaces with the role of a+ drag-and-drop icon.+ </description>+ <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the eventual transfer"/>+ <arg name="origin" type="object" interface="wl_surface" summary="surface where the drag originates"/>+ <arg name="icon" type="object" interface="wl_surface" allow-null="true" summary="drag-and-drop icon surface"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the origin"/>+ </request>++ <request name="set_selection">+ <description summary="copy data to the selection">+ This request asks the compositor to set the selection+ to the data from the source on behalf of the client.++ To unset the selection, set the source to NULL.+ </description>+ <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the selection"/>+ <arg name="serial" type="uint" summary="serial number of the event that triggered this request"/>+ </request>++ <event name="data_offer">+ <description summary="introduce a new wl_data_offer">+ The data_offer event introduces a new wl_data_offer object,+ which will subsequently be used in either the+ data_device.enter event (for drag-and-drop) or the+ data_device.selection event (for selections). Immediately+ following the data_device.data_offer event, the new data_offer+ object will send out data_offer.offer events to describe the+ mime types it offers.+ </description>+ <arg name="id" type="new_id" interface="wl_data_offer" summary="the new data_offer object"/>+ </event>++ <event name="enter">+ <description summary="initiate drag-and-drop session">+ This event is sent when an active drag-and-drop pointer enters+ a surface owned by the client. The position of the pointer at+ enter time is provided by the x and y arguments, in surface-local+ coordinates.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="client surface entered"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"+ summary="source data_offer object"/>+ </event>++ <event name="leave">+ <description summary="end drag-and-drop session">+ This event is sent when the drag-and-drop pointer leaves the+ surface and the session ends. The client must destroy the+ wl_data_offer introduced at enter time at this point.+ </description>+ </event>++ <event name="motion">+ <description summary="drag-and-drop session motion">+ This event is sent when the drag-and-drop pointer moves within+ the currently focused surface. The new position of the pointer+ is provided by the x and y arguments, in surface-local+ coordinates.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="drop">+ <description summary="end drag-and-drop session successfully">+ The event is sent when a drag-and-drop operation is ended+ because the implicit grab is removed.++ The drag-and-drop destination is expected to honor the last action+ received through wl_data_offer.action, if the resulting action is+ "copy" or "move", the destination can still perform+ wl_data_offer.receive requests, and is expected to end all+ transfers with a wl_data_offer.finish request.++ If the resulting action is "ask", the action will not be considered+ final. The drag-and-drop destination is expected to perform one last+ wl_data_offer.set_actions request, or wl_data_offer.destroy in order+ to cancel the operation.+ </description>+ </event>++ <event name="selection">+ <description summary="advertise new selection">+ The selection event is sent out to notify the client of a new+ wl_data_offer for the selection for this device. The+ data_device.data_offer and the data_offer.offer events are+ sent out immediately before this event to introduce the data+ offer object. The selection event is sent to a client+ immediately before receiving keyboard focus and when a new+ selection is set while the client has keyboard focus. The+ data_offer is valid until a new data_offer or NULL is received+ or until the client loses keyboard focus. Switching surface with+ keyboard focus within the same client doesn't mean a new selection+ will be sent. The client must destroy the previous selection+ data_offer, if any, upon receiving this event.+ </description>+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"+ summary="selection data_offer object"/>+ </event>++ <!-- Version 2 additions -->++ <request name="release" type="destructor" since="2">+ <description summary="destroy data device">+ This request destroys the data device.+ </description>+ </request>+ </interface>++ <interface name="wl_data_device_manager" version="3">+ <description summary="data transfer interface">+ The wl_data_device_manager is a singleton global object that+ provides access to inter-client data transfer mechanisms such as+ copy-and-paste and drag-and-drop. These mechanisms are tied to+ a wl_seat and this interface lets a client get a wl_data_device+ corresponding to a wl_seat.++ Depending on the version bound, the objects created from the bound+ wl_data_device_manager object will have different requirements for+ functioning properly. See wl_data_source.set_actions,+ wl_data_offer.accept and wl_data_offer.finish for details.+ </description>++ <request name="create_data_source">+ <description summary="create a new data source">+ Create a new data source.+ </description>+ <arg name="id" type="new_id" interface="wl_data_source" summary="data source to create"/>+ </request>++ <request name="get_data_device">+ <description summary="create a new data device">+ Create a new data device for a given seat.+ </description>+ <arg name="id" type="new_id" interface="wl_data_device" summary="data device to create"/>+ <arg name="seat" type="object" interface="wl_seat" summary="seat associated with the data device"/>+ </request>++ <!-- Version 3 additions -->++ <enum name="dnd_action" bitfield="true" since="3">+ <description summary="drag and drop actions">+ This is a bitmask of the available/preferred actions in a+ drag-and-drop operation.++ In the compositor, the selected action is a result of matching the+ actions offered by the source and destination sides. "action" events+ with a "none" action will be sent to both source and destination if+ there is no match. All further checks will effectively happen on+ (source actions ∩ destination actions).++ In addition, compositors may also pick different actions in+ reaction to key modifiers being pressed. One common design that+ is used in major toolkits (and the behavior recommended for+ compositors) is:++ - If no modifiers are pressed, the first match (in bit order)+ will be used.+ - Pressing Shift selects "move", if enabled in the mask.+ - Pressing Control selects "copy", if enabled in the mask.++ Behavior beyond that is considered implementation-dependent.+ Compositors may for example bind other modifiers (like Alt/Meta)+ or drags initiated with other buttons than BTN_LEFT to specific+ actions (e.g. "ask").+ </description>+ <entry name="none" value="0" summary="no action"/>+ <entry name="copy" value="1" summary="copy action"/>+ <entry name="move" value="2" summary="move action"/>+ <entry name="ask" value="4" summary="ask action"/>+ </enum>+ </interface>++ <interface name="wl_shell" version="1">+ <description summary="create desktop-style surfaces">+ This interface is implemented by servers that provide+ desktop-style user interfaces.++ It allows clients to associate a wl_shell_surface with+ a basic surface.++ Note! This protocol is deprecated and not intended for production use.+ For desktop-style user interfaces, use xdg_shell. Compositors and clients+ should not implement this interface.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="get_shell_surface">+ <description summary="create a shell surface from a surface">+ Create a shell surface for an existing surface. This gives+ the wl_surface the role of a shell surface. If the wl_surface+ already has another role, it raises a protocol error.++ Only one shell surface can be associated with a given surface.+ </description>+ <arg name="id" type="new_id" interface="wl_shell_surface" summary="shell surface to create"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface to be given the shell surface role"/>+ </request>+ </interface>++ <interface name="wl_shell_surface" version="1">+ <description summary="desktop-style metadata interface">+ An interface that may be implemented by a wl_surface, for+ implementations that provide a desktop-style user interface.++ It provides requests to treat surfaces like toplevel, fullscreen+ or popup windows, move, resize or maximize them, associate+ metadata like title and class, etc.++ On the server side the object is automatically destroyed when+ the related wl_surface is destroyed. On the client side,+ wl_shell_surface_destroy() must be called before destroying+ the wl_surface object.+ </description>++ <request name="pong">+ <description summary="respond to a ping event">+ A client must respond to a ping event with a pong request or+ the client may be deemed unresponsive.+ </description>+ <arg name="serial" type="uint" summary="serial number of the ping event"/>+ </request>++ <request name="move">+ <description summary="start an interactive move">+ Start a pointer-driven move of the surface.++ This request must be used in response to a button press event.+ The server may ignore move requests depending on the state of+ the surface (e.g. fullscreen or maximized).+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ </request>++ <enum name="resize" bitfield="true">+ <description summary="edge values for resizing">+ These values are used to indicate which edge of a surface+ is being dragged in a resize operation. The server may+ use this information to adapt its behavior, e.g. choose+ an appropriate cursor image.+ </description>+ <entry name="none" value="0" summary="no edge"/>+ <entry name="top" value="1" summary="top edge"/>+ <entry name="bottom" value="2" summary="bottom edge"/>+ <entry name="left" value="4" summary="left edge"/>+ <entry name="top_left" value="5" summary="top and left edges"/>+ <entry name="bottom_left" value="6" summary="bottom and left edges"/>+ <entry name="right" value="8" summary="right edge"/>+ <entry name="top_right" value="9" summary="top and right edges"/>+ <entry name="bottom_right" value="10" summary="bottom and right edges"/>+ </enum>++ <request name="resize">+ <description summary="start an interactive resize">+ Start a pointer-driven resizing of the surface.++ This request must be used in response to a button press event.+ The server may ignore resize requests depending on the state of+ the surface (e.g. fullscreen or maximized).+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ <arg name="edges" type="uint" enum="resize" summary="which edge or corner is being dragged"/>+ </request>++ <request name="set_toplevel">+ <description summary="make the surface a toplevel surface">+ Map the surface as a toplevel surface.++ A toplevel surface is not fullscreen, maximized or transient.+ </description>+ </request>++ <enum name="transient" bitfield="true">+ <description summary="details of transient behaviour">+ These flags specify details of the expected behaviour+ of transient surfaces. Used in the set_transient request.+ </description>+ <entry name="inactive" value="0x1" summary="do not set keyboard focus"/>+ </enum>++ <request name="set_transient">+ <description summary="make the surface a transient surface">+ Map the surface relative to an existing surface.++ The x and y arguments specify the location of the upper left+ corner of the surface relative to the upper left corner of the+ parent surface, in surface-local coordinates.++ The flags argument controls details of the transient behaviour.+ </description>+ <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>+ </request>++ <enum name="fullscreen_method">+ <description summary="different method to set the surface fullscreen">+ Hints to indicate to the compositor how to deal with a conflict+ between the dimensions of the surface and the dimensions of the+ output. The compositor is free to ignore this parameter.+ </description>+ <entry name="default" value="0" summary="no preference, apply default policy"/>+ <entry name="scale" value="1" summary="scale, preserve the surface's aspect ratio and center on output"/>+ <entry name="driver" value="2" summary="switch output mode to the smallest mode that can fit the surface, add black borders to compensate size mismatch"/>+ <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>+ </enum>++ <request name="set_fullscreen">+ <description summary="make the surface a fullscreen surface">+ Map the surface as a fullscreen surface.++ If an output parameter is given then the surface will be made+ fullscreen on that output. If the client does not specify the+ output then the compositor will apply its policy - usually+ choosing the output on which the surface has the biggest surface+ area.++ The client may specify a method to resolve a size conflict+ between the output size and the surface size - this is provided+ through the method parameter.++ The framerate parameter is used only when the method is set+ to "driver", to indicate the preferred framerate. A value of 0+ indicates that the client does not care about framerate. The+ framerate is specified in mHz, that is framerate of 60000 is 60Hz.++ A method of "scale" or "driver" implies a scaling operation of+ the surface, either via a direct scaling operation or a change of+ the output mode. This will override any kind of output scaling, so+ that mapping a surface with a buffer size equal to the mode can+ fill the screen independent of buffer_scale.++ A method of "fill" means we don't scale up the buffer, however+ any output scale is applied. This means that you may run into+ an edge case where the application maps a buffer with the same+ size of the output mode but buffer_scale 1 (thus making a+ surface larger than the output). In this case it is allowed to+ downscale the results to fit the screen.++ The compositor must reply to this request with a configure event+ with the dimensions for the output on which the surface will+ be made fullscreen.+ </description>+ <arg name="method" type="uint" enum="fullscreen_method" summary="method for resolving size conflict"/>+ <arg name="framerate" type="uint" summary="framerate in mHz"/>+ <arg name="output" type="object" interface="wl_output" allow-null="true"+ summary="output on which the surface is to be fullscreen"/>+ </request>++ <request name="set_popup">+ <description summary="make the surface a popup surface">+ Map the surface as a popup.++ A popup surface is a transient surface with an added pointer+ grab.++ An existing implicit grab will be changed to owner-events mode,+ and the popup grab will continue after the implicit grab ends+ (i.e. releasing the mouse button does not cause the popup to+ be unmapped).++ The popup grab continues until the window is destroyed or a+ mouse button is pressed in any other client's window. A click+ in any of the client's surfaces is reported as normal, however,+ clicks in other clients' surfaces will be discarded and trigger+ the callback.++ The x and y arguments specify the location of the upper left+ corner of the surface relative to the upper left corner of the+ parent surface, in surface-local coordinates.+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>+ </request>++ <request name="set_maximized">+ <description summary="make the surface a maximized surface">+ Map the surface as a maximized surface.++ If an output parameter is given then the surface will be+ maximized on that output. If the client does not specify the+ output then the compositor will apply its policy - usually+ choosing the output on which the surface has the biggest surface+ area.++ The compositor will reply with a configure event telling+ the expected new surface size. The operation is completed+ on the next buffer attach to this surface.++ A maximized surface typically fills the entire output it is+ bound to, except for desktop elements such as panels. This is+ the main difference between a maximized shell surface and a+ fullscreen shell surface.++ The details depend on the compositor implementation.+ </description>+ <arg name="output" type="object" interface="wl_output" allow-null="true"+ summary="output on which the surface is to be maximized"/>+ </request>++ <request name="set_title">+ <description summary="set surface title">+ Set a short title for the surface.++ This string may be used to identify the surface in a task bar,+ window list, or other user interface elements provided by the+ compositor.++ The string must be encoded in UTF-8.+ </description>+ <arg name="title" type="string" summary="surface title"/>+ </request>++ <request name="set_class">+ <description summary="set surface class">+ Set a class for the surface.++ The surface class identifies the general class of applications+ to which the surface belongs. A common convention is to use the+ file name (or the full path if it is a non-standard location) of+ the application's .desktop file as the class.+ </description>+ <arg name="class_" type="string" summary="surface class"/>+ </request>++ <event name="ping">+ <description summary="ping client">+ Ping a client to check if it is receiving events and sending+ requests. A client is expected to reply with a pong request.+ </description>+ <arg name="serial" type="uint" summary="serial number of the ping"/>+ </event>++ <event name="configure">+ <description summary="suggest resize">+ The configure event asks the client to resize its surface.++ The size is a hint, in the sense that the client is free to+ ignore it if it doesn't resize, pick a smaller size (to+ satisfy aspect ratio or resize in steps of NxM pixels).++ The edges parameter provides a hint about how the surface+ was resized. The client may use this information to decide+ how to adjust its content to the new size (e.g. a scrolling+ area might adjust its content position to leave the viewable+ content unmoved).++ The client is free to dismiss all but the last configure+ event it received.++ The width and height arguments specify the size of the window+ in surface-local coordinates.+ </description>+ <arg name="edges" type="uint" enum="resize" summary="how the surface was resized"/>+ <arg name="width" type="int" summary="new width of the surface"/>+ <arg name="height" type="int" summary="new height of the surface"/>+ </event>++ <event name="popup_done">+ <description summary="popup interaction is done">+ The popup_done event is sent out when a popup grab is broken,+ that is, when the user clicks a surface that doesn't belong+ to the client owning the popup surface.+ </description>+ </event>+ </interface>++ <interface name="wl_surface" version="6">+ <description summary="an onscreen surface">+ A surface is a rectangular area that may be displayed on zero+ or more outputs, and shown any number of times at the compositor's+ discretion. They can present wl_buffers, receive user input, and+ define a local coordinate system.++ The size of a surface (and relative positions on it) is described+ in surface-local coordinates, which may differ from the buffer+ coordinates of the pixel content, in case a buffer_transform+ or a buffer_scale is used.++ A surface without a "role" is fairly useless: a compositor does+ not know where, when or how to present it. The role is the+ purpose of a wl_surface. Examples of roles are a cursor for a+ pointer (as set by wl_pointer.set_cursor), a drag icon+ (wl_data_device.start_drag), a sub-surface+ (wl_subcompositor.get_subsurface), and a window as defined by a+ shell protocol (e.g. wl_shell.get_shell_surface).++ A surface can have only one role at a time. Initially a+ wl_surface does not have a role. Once a wl_surface is given a+ role, it is set permanently for the whole lifetime of the+ wl_surface object. Giving the current role again is allowed,+ unless explicitly forbidden by the relevant interface+ specification.++ Surface roles are given by requests in other interfaces such as+ wl_pointer.set_cursor. The request should explicitly mention+ that this request gives a role to a wl_surface. Often, this+ request also creates a new protocol object that represents the+ role and adds additional functionality to wl_surface. When a+ client wants to destroy a wl_surface, they must destroy this role+ object before the wl_surface, otherwise a defunct_role_object error is+ sent.++ Destroying the role object does not remove the role from the+ wl_surface, but it may stop the wl_surface from "playing the role".+ For instance, if a wl_subsurface object is destroyed, the wl_surface+ it was created for will be unmapped and forget its position and+ z-order. It is allowed to create a wl_subsurface for the same+ wl_surface again, but it is not allowed to use the wl_surface as+ a cursor (cursor is a different role than sub-surface, and role+ switching is not allowed).+ </description>++ <enum name="error">+ <description summary="wl_surface error values">+ These errors can be emitted in response to wl_surface requests.+ </description>+ <entry name="invalid_scale" value="0" summary="buffer scale value is invalid"/>+ <entry name="invalid_transform" value="1" summary="buffer transform value is invalid"/>+ <entry name="invalid_size" value="2" summary="buffer size is invalid"/>+ <entry name="invalid_offset" value="3" summary="buffer offset is invalid"/>+ <entry name="defunct_role_object" value="4"+ summary="surface was destroyed before its role object"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="delete surface">+ Deletes the surface and invalidates its object ID.+ </description>+ </request>++ <request name="attach">+ <description summary="set the surface contents">+ Set a buffer as the content of this surface.++ The new size of the surface is calculated based on the buffer+ size transformed by the inverse buffer_transform and the+ inverse buffer_scale. This means that at commit time the supplied+ buffer size must be an integer multiple of the buffer_scale. If+ that's not the case, an invalid_size error is sent.++ The x and y arguments specify the location of the new pending+ buffer's upper left corner, relative to the current buffer's upper+ left corner, in surface-local coordinates. In other words, the+ x and y, combined with the new surface size define in which+ directions the surface's size changes. Setting anything other than 0+ as x and y arguments is discouraged, and should instead be replaced+ with using the separate wl_surface.offset request.++ When the bound wl_surface version is 5 or higher, passing any+ non-zero x or y is a protocol violation, and will result in an+ 'invalid_offset' error being raised. The x and y arguments are ignored+ and do not change the pending state. To achieve equivalent semantics,+ use wl_surface.offset.++ Surface contents are double-buffered state, see wl_surface.commit.++ The initial surface contents are void; there is no content.+ wl_surface.attach assigns the given wl_buffer as the pending+ wl_buffer. wl_surface.commit makes the pending wl_buffer the new+ surface contents, and the size of the surface becomes the size+ calculated from the wl_buffer, as described above. After commit,+ there is no pending buffer until the next attach.++ Committing a pending wl_buffer allows the compositor to read the+ pixels in the wl_buffer. The compositor may access the pixels at+ any time after the wl_surface.commit request. When the compositor+ will not access the pixels anymore, it will send the+ wl_buffer.release event. Only after receiving wl_buffer.release,+ the client may reuse the wl_buffer. A wl_buffer that has been+ attached and then replaced by another attach instead of committed+ will not receive a release event, and is not used by the+ compositor.++ If a pending wl_buffer has been committed to more than one wl_surface,+ the delivery of wl_buffer.release events becomes undefined. A well+ behaved client should not rely on wl_buffer.release events in this+ case. Alternatively, a client could create multiple wl_buffer objects+ from the same backing storage or use wp_linux_buffer_release.++ Destroying the wl_buffer after wl_buffer.release does not change+ the surface contents. Destroying the wl_buffer before wl_buffer.release+ is allowed as long as the underlying buffer storage isn't re-used (this+ can happen e.g. on client process termination). However, if the client+ destroys the wl_buffer before receiving the wl_buffer.release event and+ mutates the underlying buffer storage, the surface contents become+ undefined immediately.++ If wl_surface.attach is sent with a NULL wl_buffer, the+ following wl_surface.commit will remove the surface content.+ </description>+ <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"+ summary="buffer of surface contents"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ </request>++ <request name="damage">+ <description summary="mark part of the surface damaged">+ This request is used to describe the regions where the pending+ buffer is different from the current surface contents, and where+ the surface therefore needs to be repainted. The compositor+ ignores the parts of the damage that fall outside of the surface.++ Damage is double-buffered state, see wl_surface.commit.++ The damage rectangle is specified in surface-local coordinates,+ where x and y specify the upper left corner of the damage rectangle.++ The initial value for pending damage is empty: no damage.+ wl_surface.damage adds pending damage: the new pending damage+ is the union of old pending damage and the given rectangle.++ wl_surface.commit assigns pending damage as the current damage,+ and clears pending damage. The server will clear the current+ damage as it repaints the surface.++ Note! New clients should not use this request. Instead damage can be+ posted with wl_surface.damage_buffer which uses buffer coordinates+ instead of surface coordinates.+ </description>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="width" type="int" summary="width of damage rectangle"/>+ <arg name="height" type="int" summary="height of damage rectangle"/>+ </request>++ <request name="frame">+ <description summary="request a frame throttling hint">+ Request a notification when it is a good time to start drawing a new+ frame, by creating a frame callback. This is useful for throttling+ redrawing operations, and driving animations.++ When a client is animating on a wl_surface, it can use the 'frame'+ request to get notified when it is a good time to draw and commit the+ next frame of animation. If the client commits an update earlier than+ that, it is likely that some updates will not make it to the display,+ and the client is wasting resources by drawing too often.++ The frame request will take effect on the next wl_surface.commit.+ The notification will only be posted for one frame unless+ requested again. For a wl_surface, the notifications are posted in+ the order the frame requests were committed.++ The server must send the notifications so that a client+ will not send excessive updates, while still allowing+ the highest possible update rate for clients that wait for the reply+ before drawing again. The server should give some time for the client+ to draw and commit after sending the frame callback events to let it+ hit the next output refresh.++ A server should avoid signaling the frame callbacks if the+ surface is not visible in any way, e.g. the surface is off-screen,+ or completely obscured by other opaque surfaces.++ The object returned by this request will be destroyed by the+ compositor after the callback is fired and as such the client must not+ attempt to use it after that point.++ The callback_data passed in the callback is the current time, in+ milliseconds, with an undefined base.+ </description>+ <arg name="callback" type="new_id" interface="wl_callback" summary="callback object for the frame request"/>+ </request>++ <request name="set_opaque_region">+ <description summary="set opaque region">+ This request sets the region of the surface that contains+ opaque content.++ The opaque region is an optimization hint for the compositor+ that lets it optimize the redrawing of content behind opaque+ regions. Setting an opaque region is not required for correct+ behaviour, but marking transparent content as opaque will result+ in repaint artifacts.++ The opaque region is specified in surface-local coordinates.++ The compositor ignores the parts of the opaque region that fall+ outside of the surface.++ Opaque region is double-buffered state, see wl_surface.commit.++ wl_surface.set_opaque_region changes the pending opaque region.+ wl_surface.commit copies the pending region to the current region.+ Otherwise, the pending and current regions are never changed.++ The initial value for an opaque region is empty. Setting the pending+ opaque region has copy semantics, and the wl_region object can be+ destroyed immediately. A NULL wl_region causes the pending opaque+ region to be set to empty.+ </description>+ <arg name="region" type="object" interface="wl_region" allow-null="true"+ summary="opaque region of the surface"/>+ </request>++ <request name="set_input_region">+ <description summary="set input region">+ This request sets the region of the surface that can receive+ pointer and touch events.++ Input events happening outside of this region will try the next+ surface in the server surface stack. The compositor ignores the+ parts of the input region that fall outside of the surface.++ The input region is specified in surface-local coordinates.++ Input region is double-buffered state, see wl_surface.commit.++ wl_surface.set_input_region changes the pending input region.+ wl_surface.commit copies the pending region to the current region.+ Otherwise the pending and current regions are never changed,+ except cursor and icon surfaces are special cases, see+ wl_pointer.set_cursor and wl_data_device.start_drag.++ The initial value for an input region is infinite. That means the+ whole surface will accept input. Setting the pending input region+ has copy semantics, and the wl_region object can be destroyed+ immediately. A NULL wl_region causes the input region to be set+ to infinite.+ </description>+ <arg name="region" type="object" interface="wl_region" allow-null="true"+ summary="input region of the surface"/>+ </request>++ <request name="commit">+ <description summary="commit pending surface state">+ Surface state (input, opaque, and damage regions, attached buffers,+ etc.) is double-buffered. Protocol requests modify the pending state,+ as opposed to the current state in use by the compositor. A commit+ request atomically applies all pending state, replacing the current+ state. After commit, the new pending state is as documented for each+ related request.++ On commit, a pending wl_buffer is applied first, and all other state+ second. This means that all coordinates in double-buffered state are+ relative to the new wl_buffer coming into use, except for+ wl_surface.attach itself. If there is no pending wl_buffer, the+ coordinates are relative to the current surface contents.++ All requests that need a commit to become effective are documented+ to affect double-buffered state.++ Other interfaces may add further double-buffered surface state.+ </description>+ </request>++ <event name="enter">+ <description summary="surface enters an output">+ This is emitted whenever a surface's creation, movement, or resizing+ results in some part of it being within the scanout region of an+ output.++ Note that a surface may be overlapping with zero or more outputs.+ </description>+ <arg name="output" type="object" interface="wl_output" summary="output entered by the surface"/>+ </event>++ <event name="leave">+ <description summary="surface leaves an output">+ This is emitted whenever a surface's creation, movement, or resizing+ results in it no longer having any part of it within the scanout region+ of an output.++ Clients should not use the number of outputs the surface is on for frame+ throttling purposes. The surface might be hidden even if no leave event+ has been sent, and the compositor might expect new surface content+ updates even if no enter event has been sent. The frame event should be+ used instead.+ </description>+ <arg name="output" type="object" interface="wl_output" summary="output left by the surface"/>+ </event>++ <!-- Version 2 additions -->++ <request name="set_buffer_transform" since="2">+ <description summary="sets the buffer transformation">+ This request sets an optional transformation on how the compositor+ interprets the contents of the buffer attached to the surface. The+ accepted values for the transform parameter are the values for+ wl_output.transform.++ Buffer transform is double-buffered state, see wl_surface.commit.++ A newly created surface has its buffer transformation set to normal.++ wl_surface.set_buffer_transform changes the pending buffer+ transformation. wl_surface.commit copies the pending buffer+ transformation to the current one. Otherwise, the pending and current+ values are never changed.++ The purpose of this request is to allow clients to render content+ according to the output transform, thus permitting the compositor to+ use certain optimizations even if the display is rotated. Using+ hardware overlays and scanning out a client buffer for fullscreen+ surfaces are examples of such optimizations. Those optimizations are+ highly dependent on the compositor implementation, so the use of this+ request should be considered on a case-by-case basis.++ Note that if the transform value includes 90 or 270 degree rotation,+ the width of the buffer will become the surface height and the height+ of the buffer will become the surface width.++ If transform is not one of the values from the+ wl_output.transform enum the invalid_transform protocol error+ is raised.+ </description>+ <arg name="transform" type="int" enum="wl_output.transform"+ summary="transform for interpreting buffer contents"/>+ </request>++ <!-- Version 3 additions -->++ <request name="set_buffer_scale" since="3">+ <description summary="sets the buffer scaling factor">+ This request sets an optional scaling factor on how the compositor+ interprets the contents of the buffer attached to the window.++ Buffer scale is double-buffered state, see wl_surface.commit.++ A newly created surface has its buffer scale set to 1.++ wl_surface.set_buffer_scale changes the pending buffer scale.+ wl_surface.commit copies the pending buffer scale to the current one.+ Otherwise, the pending and current values are never changed.++ The purpose of this request is to allow clients to supply higher+ resolution buffer data for use on high resolution outputs. It is+ intended that you pick the same buffer scale as the scale of the+ output that the surface is displayed on. This means the compositor+ can avoid scaling when rendering the surface on that output.++ Note that if the scale is larger than 1, then you have to attach+ a buffer that is larger (by a factor of scale in each dimension)+ than the desired surface size.++ If scale is not positive the invalid_scale protocol error is+ raised.+ </description>+ <arg name="scale" type="int"+ summary="positive scale for interpreting buffer contents"/>+ </request>++ <!-- Version 4 additions -->+ <request name="damage_buffer" since="4">+ <description summary="mark part of the surface damaged using buffer coordinates">+ This request is used to describe the regions where the pending+ buffer is different from the current surface contents, and where+ the surface therefore needs to be repainted. The compositor+ ignores the parts of the damage that fall outside of the surface.++ Damage is double-buffered state, see wl_surface.commit.++ The damage rectangle is specified in buffer coordinates,+ where x and y specify the upper left corner of the damage rectangle.++ The initial value for pending damage is empty: no damage.+ wl_surface.damage_buffer adds pending damage: the new pending+ damage is the union of old pending damage and the given rectangle.++ wl_surface.commit assigns pending damage as the current damage,+ and clears pending damage. The server will clear the current+ damage as it repaints the surface.++ This request differs from wl_surface.damage in only one way - it+ takes damage in buffer coordinates instead of surface-local+ coordinates. While this generally is more intuitive than surface+ coordinates, it is especially desirable when using wp_viewport+ or when a drawing library (like EGL) is unaware of buffer scale+ and buffer transform.++ Note: Because buffer transformation changes and damage requests may+ be interleaved in the protocol stream, it is impossible to determine+ the actual mapping between surface and buffer damage until+ wl_surface.commit time. Therefore, compositors wishing to take both+ kinds of damage into account will have to accumulate damage from the+ two requests separately and only transform from one to the other+ after receiving the wl_surface.commit.+ </description>+ <arg name="x" type="int" summary="buffer-local x coordinate"/>+ <arg name="y" type="int" summary="buffer-local y coordinate"/>+ <arg name="width" type="int" summary="width of damage rectangle"/>+ <arg name="height" type="int" summary="height of damage rectangle"/>+ </request>++ <!-- Version 5 additions -->++ <request name="offset" since="5">+ <description summary="set the surface contents offset">+ The x and y arguments specify the location of the new pending+ buffer's upper left corner, relative to the current buffer's upper+ left corner, in surface-local coordinates. In other words, the+ x and y, combined with the new surface size define in which+ directions the surface's size changes.++ Surface location offset is double-buffered state, see+ wl_surface.commit.++ This request is semantically equivalent to and the replaces the x and y+ arguments in the wl_surface.attach request in wl_surface versions prior+ to 5. See wl_surface.attach for details.+ </description>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ </request>++ <!-- Version 6 additions -->++ <event name="preferred_buffer_scale" since="6">+ <description summary="preferred buffer scale for the surface">+ This event indicates the preferred buffer scale for this surface. It is+ sent whenever the compositor's preference changes.++ It is intended that scaling aware clients use this event to scale their+ content and use wl_surface.set_buffer_scale to indicate the scale they+ have rendered with. This allows clients to supply a higher detail+ buffer.+ </description>+ <arg name="factor" type="int" summary="preferred scaling factor"/>+ </event>++ <event name="preferred_buffer_transform" since="6">+ <description summary="preferred buffer transform for the surface">+ This event indicates the preferred buffer transform for this surface.+ It is sent whenever the compositor's preference changes.++ It is intended that transform aware clients use this event to apply the+ transform to their content and use wl_surface.set_buffer_transform to+ indicate the transform they have rendered with.+ </description>+ <arg name="transform" type="uint" enum="wl_output.transform"+ summary="preferred transform"/>+ </event>+ </interface>++ <interface name="wl_seat" version="9">+ <description summary="group of input devices">+ A seat is a group of keyboards, pointer and touch devices. This+ object is published as a global during start up, or when such a+ device is hot plugged. A seat typically has a pointer and+ maintains a keyboard focus and a pointer focus.+ </description>++ <enum name="capability" bitfield="true">+ <description summary="seat capability bitmask">+ This is a bitmask of capabilities this seat has; if a member is+ set, then it is present on the seat.+ </description>+ <entry name="pointer" value="1" summary="the seat has pointer devices"/>+ <entry name="keyboard" value="2" summary="the seat has one or more keyboards"/>+ <entry name="touch" value="4" summary="the seat has touch devices"/>+ </enum>++ <enum name="error">+ <description summary="wl_seat error values">+ These errors can be emitted in response to wl_seat requests.+ </description>+ <entry name="missing_capability" value="0"+ summary="get_pointer, get_keyboard or get_touch called on seat without the matching capability"/>+ </enum>++ <event name="capabilities">+ <description summary="seat capabilities changed">+ This is emitted whenever a seat gains or loses the pointer,+ keyboard or touch capabilities. The argument is a capability+ enum containing the complete set of capabilities this seat has.++ When the pointer capability is added, a client may create a+ wl_pointer object using the wl_seat.get_pointer request. This object+ will receive pointer events until the capability is removed in the+ future.++ When the pointer capability is removed, a client should destroy the+ wl_pointer objects associated with the seat where the capability was+ removed, using the wl_pointer.release request. No further pointer+ events will be received on these objects.++ In some compositors, if a seat regains the pointer capability and a+ client has a previously obtained wl_pointer object of version 4 or+ less, that object may start sending pointer events again. This+ behavior is considered a misinterpretation of the intended behavior+ and must not be relied upon by the client. wl_pointer objects of+ version 5 or later must not send events if created before the most+ recent event notifying the client of an added pointer capability.++ The above behavior also applies to wl_keyboard and wl_touch with the+ keyboard and touch capabilities, respectively.+ </description>+ <arg name="capabilities" type="uint" enum="capability" summary="capabilities of the seat"/>+ </event>++ <request name="get_pointer">+ <description summary="return pointer object">+ The ID provided will be initialized to the wl_pointer interface+ for this seat.++ This request only takes effect if the seat has the pointer+ capability, or has had the pointer capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the pointer capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_pointer" summary="seat pointer"/>+ </request>++ <request name="get_keyboard">+ <description summary="return keyboard object">+ The ID provided will be initialized to the wl_keyboard interface+ for this seat.++ This request only takes effect if the seat has the keyboard+ capability, or has had the keyboard capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the keyboard capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_keyboard" summary="seat keyboard"/>+ </request>++ <request name="get_touch">+ <description summary="return touch object">+ The ID provided will be initialized to the wl_touch interface+ for this seat.++ This request only takes effect if the seat has the touch+ capability, or has had the touch capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the touch capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_touch" summary="seat touch interface"/>+ </request>++ <!-- Version 2 additions -->++ <event name="name" since="2">+ <description summary="unique identifier for this seat">+ In a multi-seat configuration the seat name can be used by clients to+ help identify which physical devices the seat represents.++ The seat name is a UTF-8 string with no convention defined for its+ contents. Each name is unique among all wl_seat globals. The name is+ only guaranteed to be unique for the current compositor instance.++ The same seat names are used for all clients. Thus, the name can be+ shared across processes to refer to a specific wl_seat global.++ The name event is sent after binding to the seat global. This event is+ only sent once per seat object, and the name does not change over the+ lifetime of the wl_seat global.++ Compositors may re-use the same seat name if the wl_seat global is+ destroyed and re-created later.+ </description>+ <arg name="name" type="string" summary="seat identifier"/>+ </event>++ <!-- Version 5 additions -->++ <request name="release" type="destructor" since="5">+ <description summary="release the seat object">+ Using this request a client can tell the server that it is not going to+ use the seat object anymore.+ </description>+ </request>++ </interface>++ <interface name="wl_pointer" version="9">+ <description summary="pointer input device">+ The wl_pointer interface represents one or more input devices,+ such as mice, which control the pointer location and pointer_focus+ of a seat.++ The wl_pointer interface generates motion, enter and leave+ events for the surfaces that the pointer is located over,+ and button and axis events for button presses, button releases+ and scrolling.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="set_cursor">+ <description summary="set the pointer surface">+ Set the pointer surface, i.e., the surface that contains the+ pointer image (cursor). This request gives the surface the role+ of a cursor. If the surface already has another role, it raises+ a protocol error.++ The cursor actually changes only if the pointer+ focus for this device is one of the requesting client's surfaces+ or the surface parameter is the current pointer surface. If+ there was a previous surface set with this request it is+ replaced. If surface is NULL, the pointer image is hidden.++ The parameters hotspot_x and hotspot_y define the position of+ the pointer surface relative to the pointer location. Its+ top-left corner is always at (x, y) - (hotspot_x, hotspot_y),+ where (x, y) are the coordinates of the pointer location, in+ surface-local coordinates.++ On surface.attach requests to the pointer surface, hotspot_x+ and hotspot_y are decremented by the x and y parameters+ passed to the request. Attach must be confirmed by+ wl_surface.commit as usual.++ The hotspot can also be updated by passing the currently set+ pointer surface to this request with new values for hotspot_x+ and hotspot_y.++ The input region is ignored for wl_surfaces with the role of+ a cursor. When the use as a cursor ends, the wl_surface is+ unmapped.++ The serial parameter must match the latest wl_pointer.enter+ serial number sent to the client. Otherwise the request will be+ ignored.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" allow-null="true"+ summary="pointer surface"/>+ <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>+ <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>+ </request>++ <event name="enter">+ <description summary="enter event">+ Notification that this seat's pointer is focused on a certain+ surface.++ When a seat's focus enters a surface, the pointer image+ is undefined and a client should respond to this event by setting+ an appropriate pointer image with the set_cursor request.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface entered by the pointer"/>+ <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="leave">+ <description summary="leave event">+ Notification that this seat's pointer is no longer focused on+ a certain surface.++ The leave notification is sent before the enter notification+ for the new focus.+ </description>+ <arg name="serial" type="uint" summary="serial number of the leave event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface left by the pointer"/>+ </event>++ <event name="motion">+ <description summary="pointer motion event">+ Notification of pointer location change. The arguments+ surface_x and surface_y are the location relative to the+ focused surface.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <enum name="button_state">+ <description summary="physical button state">+ Describes the physical state of a button that produced the button+ event.+ </description>+ <entry name="released" value="0" summary="the button is not pressed"/>+ <entry name="pressed" value="1" summary="the button is pressed"/>+ </enum>++ <event name="button">+ <description summary="pointer button event">+ Mouse button click and release notifications.++ The location of the click is given by the last motion or+ enter event.+ The time argument is a timestamp with millisecond+ granularity, with an undefined base.++ The button is a button code as defined in the Linux kernel's+ linux/input-event-codes.h header file, e.g. BTN_LEFT.++ Any 16-bit button code value is reserved for future additions to the+ kernel's event code list. All other button codes above 0xFFFF are+ currently undefined but may be used in future versions of this+ protocol.+ </description>+ <arg name="serial" type="uint" summary="serial number of the button event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="button" type="uint" summary="button that produced the event"/>+ <arg name="state" type="uint" enum="button_state" summary="physical state of the button"/>+ </event>++ <enum name="axis">+ <description summary="axis types">+ Describes the axis types of scroll events.+ </description>+ <entry name="vertical_scroll" value="0" summary="vertical axis"/>+ <entry name="horizontal_scroll" value="1" summary="horizontal axis"/>+ </enum>++ <event name="axis">+ <description summary="axis event">+ Scroll and other axis notifications.++ For scroll events (vertical and horizontal scroll axes), the+ value parameter is the length of a vector along the specified+ axis in a coordinate space identical to those of motion events,+ representing a relative movement along the specified axis.++ For devices that support movements non-parallel to axes multiple+ axis events will be emitted.++ When applicable, for example for touch pads, the server can+ choose to emit scroll events where the motion vector is+ equivalent to a motion event vector.++ When applicable, a client can transform its content relative to the+ scroll distance.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="value" type="fixed" summary="length of vector in surface-local coordinate space"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the pointer object">+ Using this request a client can tell the server that it is not going to+ use the pointer object anymore.++ This request destroys the pointer proxy object, so clients must not call+ wl_pointer_destroy() after using this request.+ </description>+ </request>++ <!-- Version 5 additions -->++ <event name="frame" since="5">+ <description summary="end of a pointer event sequence">+ Indicates the end of a set of events that logically belong together.+ A client is expected to accumulate the data in all events within the+ frame before proceeding.++ All wl_pointer events before a wl_pointer.frame event belong+ logically together. For example, in a diagonal scroll motion the+ compositor will send an optional wl_pointer.axis_source event, two+ wl_pointer.axis events (horizontal and vertical) and finally a+ wl_pointer.frame event. The client may use this information to+ calculate a diagonal vector for scrolling.++ When multiple wl_pointer.axis events occur within the same frame,+ the motion vector is the combined motion of all events.+ When a wl_pointer.axis and a wl_pointer.axis_stop event occur within+ the same frame, this indicates that axis movement in one axis has+ stopped but continues in the other axis.+ When multiple wl_pointer.axis_stop events occur within the same+ frame, this indicates that these axes stopped in the same instance.++ A wl_pointer.frame event is sent for every logical event group,+ even if the group only contains a single wl_pointer event.+ Specifically, a client may get a sequence: motion, frame, button,+ frame, axis, frame, axis_stop, frame.++ The wl_pointer.enter and wl_pointer.leave events are logical events+ generated by the compositor and not the hardware. These events are+ also grouped by a wl_pointer.frame. When a pointer moves from one+ surface to another, a compositor should group the+ wl_pointer.leave event within the same wl_pointer.frame.+ However, a client must not rely on wl_pointer.leave and+ wl_pointer.enter being in the same wl_pointer.frame.+ Compositor-specific policies may require the wl_pointer.leave and+ wl_pointer.enter event being split across multiple wl_pointer.frame+ groups.+ </description>+ </event>++ <enum name="axis_source">+ <description summary="axis source types">+ Describes the source types for axis events. This indicates to the+ client how an axis event was physically generated; a client may+ adjust the user interface accordingly. For example, scroll events+ from a "finger" source may be in a smooth coordinate space with+ kinetic scrolling whereas a "wheel" source may be in discrete steps+ of a number of lines.++ The "continuous" axis source is a device generating events in a+ continuous coordinate space, but using something other than a+ finger. One example for this source is button-based scrolling where+ the vertical motion of a device is converted to scroll events while+ a button is held down.++ The "wheel tilt" axis source indicates that the actual device is a+ wheel but the scroll event is not caused by a rotation but a+ (usually sideways) tilt of the wheel.+ </description>+ <entry name="wheel" value="0" summary="a physical wheel rotation" />+ <entry name="finger" value="1" summary="finger on a touch surface" />+ <entry name="continuous" value="2" summary="continuous coordinate space"/>+ <entry name="wheel_tilt" value="3" summary="a physical wheel tilt" since="6"/>+ </enum>++ <event name="axis_source" since="5">+ <description summary="axis source event">+ Source information for scroll and other axes.++ This event does not occur on its own. It is sent before a+ wl_pointer.frame event and carries the source information for+ all events within that frame.++ The source specifies how this event was generated. If the source is+ wl_pointer.axis_source.finger, a wl_pointer.axis_stop event will be+ sent when the user lifts the finger off the device.++ If the source is wl_pointer.axis_source.wheel,+ wl_pointer.axis_source.wheel_tilt or+ wl_pointer.axis_source.continuous, a wl_pointer.axis_stop event may+ or may not be sent. Whether a compositor sends an axis_stop event+ for these sources is hardware-specific and implementation-dependent;+ clients must not rely on receiving an axis_stop event for these+ scroll sources and should treat scroll sequences from these scroll+ sources as unterminated by default.++ This event is optional. If the source is unknown for a particular+ axis event sequence, no event is sent.+ Only one wl_pointer.axis_source event is permitted per frame.++ The order of wl_pointer.axis_discrete and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis_source" type="uint" enum="axis_source" summary="source of the axis event"/>+ </event>++ <event name="axis_stop" since="5">+ <description summary="axis stop event">+ Stop notification for scroll and other axes.++ For some wl_pointer.axis_source types, a wl_pointer.axis_stop event+ is sent to notify a client that the axis sequence has terminated.+ This enables the client to implement kinetic scrolling.+ See the wl_pointer.axis_source documentation for information on when+ this event may be generated.++ Any wl_pointer.axis events with the same axis_source after this+ event should be considered as the start of a new axis motion.++ The timestamp is to be interpreted identical to the timestamp in the+ wl_pointer.axis event. The timestamp value may be the same as a+ preceding wl_pointer.axis event.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="axis" type="uint" enum="axis" summary="the axis stopped with this event"/>+ </event>++ <event name="axis_discrete" since="5">+ <description summary="axis click event">+ Discrete step information for scroll and other axes.++ This event carries the axis value of the wl_pointer.axis event in+ discrete steps (e.g. mouse wheel clicks).++ This event is deprecated with wl_pointer version 8 - this event is not+ sent to clients supporting version 8 or later.++ This event does not occur on its own, it is coupled with a+ wl_pointer.axis event that represents this axis value on a+ continuous scale. The protocol guarantees that each axis_discrete+ event is always followed by exactly one axis event with the same+ axis number within the same wl_pointer.frame. Note that the protocol+ allows for other events to occur between the axis_discrete and+ its coupled axis event, including other axis_discrete or axis+ events. A wl_pointer.frame must not contain more than one axis_discrete+ event per axis type.++ This event is optional; continuous scrolling devices+ like two-finger scrolling on touchpads do not have discrete+ steps and do not generate this event.++ The discrete value carries the directional information. e.g. a value+ of -2 is two steps towards the negative direction of this axis.++ The axis number is identical to the axis number in the associated+ axis event.++ The order of wl_pointer.axis_discrete and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="discrete" type="int" summary="number of steps"/>+ </event>++ <event name="axis_value120" since="8">+ <description summary="axis high-resolution scroll event">+ Discrete high-resolution scroll information.++ This event carries high-resolution wheel scroll information,+ with each multiple of 120 representing one logical scroll step+ (a wheel detent). For example, an axis_value120 of 30 is one quarter of+ a logical scroll step in the positive direction, a value120 of+ -240 are two logical scroll steps in the negative direction within the+ same hardware event.+ Clients that rely on discrete scrolling should accumulate the+ value120 to multiples of 120 before processing the event.++ The value120 must not be zero.++ This event replaces the wl_pointer.axis_discrete event in clients+ supporting wl_pointer version 8 or later.++ Where a wl_pointer.axis_source event occurs in the same+ wl_pointer.frame, the axis source applies to this event.++ The order of wl_pointer.axis_value120 and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="value120" type="int" summary="scroll distance as fraction of 120"/>+ </event>++ <!-- Version 9 additions -->++ <enum name="axis_relative_direction">+ <description summary="axis relative direction">+ This specifies the direction of the physical motion that caused a+ wl_pointer.axis event, relative to the wl_pointer.axis direction.+ </description>+ <entry name="identical" value="0"+ summary="physical motion matches axis direction"/>+ <entry name="inverted" value="1"+ summary="physical motion is the inverse of the axis direction"/>+ </enum>++ <event name="axis_relative_direction" since="9">+ <description summary="axis relative physical direction event">+ Relative directional information of the entity causing the axis+ motion.++ For a wl_pointer.axis event, the wl_pointer.axis_relative_direction+ event specifies the movement direction of the entity causing the+ wl_pointer.axis event. For example:+ - if a user's fingers on a touchpad move down and this+ causes a wl_pointer.axis vertical_scroll down event, the physical+ direction is 'identical'+ - if a user's fingers on a touchpad move down and this causes a+ wl_pointer.axis vertical_scroll up scroll up event ('natural+ scrolling'), the physical direction is 'inverted'.++ A client may use this information to adjust scroll motion of+ components. Specifically, enabling natural scrolling causes the+ content to change direction compared to traditional scrolling.+ Some widgets like volume control sliders should usually match the+ physical direction regardless of whether natural scrolling is+ active. This event enables clients to match the scroll direction of+ a widget to the physical direction.++ This event does not occur on its own, it is coupled with a+ wl_pointer.axis event that represents this axis value.+ The protocol guarantees that each axis_relative_direction event is+ always followed by exactly one axis event with the same+ axis number within the same wl_pointer.frame. Note that the protocol+ allows for other events to occur between the axis_relative_direction+ and its coupled axis event.++ The axis number is identical to the axis number in the associated+ axis event.++ The order of wl_pointer.axis_relative_direction,+ wl_pointer.axis_discrete and wl_pointer.axis_source is not+ guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="direction" type="uint" enum="axis_relative_direction"+ summary="physical direction relative to axis motion"/>+ </event>+ </interface>++ <interface name="wl_keyboard" version="9">+ <description summary="keyboard input device">+ The wl_keyboard interface represents one or more keyboards+ associated with a seat.+ </description>++ <enum name="keymap_format">+ <description summary="keyboard mapping format">+ This specifies the format of the keymap provided to the+ client with the wl_keyboard.keymap event.+ </description>+ <entry name="no_keymap" value="0"+ summary="no keymap; client must understand how to interpret the raw keycode"/>+ <entry name="xkb_v1" value="1"+ summary="libxkbcommon compatible, null-terminated string; to determine the xkb keycode, clients must add 8 to the key event keycode"/>+ </enum>++ <event name="keymap">+ <description summary="keyboard mapping">+ This event provides a file descriptor to the client which can be+ memory-mapped in read-only mode to provide a keyboard mapping+ description.++ From version 7 onwards, the fd must be mapped with MAP_PRIVATE by+ the recipient, as MAP_SHARED may fail.+ </description>+ <arg name="format" type="uint" enum="keymap_format" summary="keymap format"/>+ <arg name="fd" type="fd" summary="keymap file descriptor"/>+ <arg name="size" type="uint" summary="keymap size, in bytes"/>+ </event>++ <event name="enter">+ <description summary="enter event">+ Notification that this seat's keyboard focus is on a certain+ surface.++ The compositor must send the wl_keyboard.modifiers event after this+ event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface gaining keyboard focus"/>+ <arg name="keys" type="array" summary="the currently pressed keys"/>+ </event>++ <event name="leave">+ <description summary="leave event">+ Notification that this seat's keyboard focus is no longer on+ a certain surface.++ The leave notification is sent before the enter notification+ for the new focus.++ After this event client must assume that all keys, including modifiers,+ are lifted and also it must stop key repeating if there's some going on.+ </description>+ <arg name="serial" type="uint" summary="serial number of the leave event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface that lost keyboard focus"/>+ </event>++ <enum name="key_state">+ <description summary="physical key state">+ Describes the physical state of a key that produced the key event.+ </description>+ <entry name="released" value="0" summary="key is not pressed"/>+ <entry name="pressed" value="1" summary="key is pressed"/>+ </enum>++ <event name="key">+ <description summary="key event">+ A key was pressed or released.+ The time argument is a timestamp with millisecond+ granularity, with an undefined base.++ The key is a platform-specific key code that can be interpreted+ by feeding it to the keyboard mapping (see the keymap event).++ If this event produces a change in modifiers, then the resulting+ wl_keyboard.modifiers event must be sent after this event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the key event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="key" type="uint" summary="key that produced the event"/>+ <arg name="state" type="uint" enum="key_state" summary="physical state of the key"/>+ </event>++ <event name="modifiers">+ <description summary="modifier and group state">+ Notifies clients that the modifier and/or group state has+ changed, and it should update its local state.+ </description>+ <arg name="serial" type="uint" summary="serial number of the modifiers event"/>+ <arg name="mods_depressed" type="uint" summary="depressed modifiers"/>+ <arg name="mods_latched" type="uint" summary="latched modifiers"/>+ <arg name="mods_locked" type="uint" summary="locked modifiers"/>+ <arg name="group" type="uint" summary="keyboard layout"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the keyboard object"/>+ </request>++ <!-- Version 4 additions -->++ <event name="repeat_info" since="4">+ <description summary="repeat rate and delay">+ Informs the client about the keyboard's repeat rate and delay.++ This event is sent as soon as the wl_keyboard object has been created,+ and is guaranteed to be received by the client before any key press+ event.++ Negative values for either rate or delay are illegal. A rate of zero+ will disable any repeating (regardless of the value of delay).++ This event can be sent later on as well with a new value if necessary,+ so clients should continue listening for the event past the creation+ of wl_keyboard.+ </description>+ <arg name="rate" type="int"+ summary="the rate of repeating keys in characters per second"/>+ <arg name="delay" type="int"+ summary="delay in milliseconds since key down until repeating starts"/>+ </event>+ </interface>++ <interface name="wl_touch" version="9">+ <description summary="touchscreen input device">+ The wl_touch interface represents a touchscreen+ associated with a seat.++ Touch interactions can consist of one or more contacts.+ For each contact, a series of events is generated, starting+ with a down event, followed by zero or more motion events,+ and ending with an up event. Events relating to the same+ contact point can be identified by the ID of the sequence.+ </description>++ <event name="down">+ <description summary="touch down event and beginning of a touch sequence">+ A new touch point has appeared on the surface. This touch point is+ assigned a unique ID. Future events from this touch point reference+ this ID. The ID ceases to be valid after a touch up event and may be+ reused in the future.+ </description>+ <arg name="serial" type="uint" summary="serial number of the touch down event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface touched"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="up">+ <description summary="end of a touch event sequence">+ The touch point has disappeared. No further events will be sent for+ this touch point and the touch point's ID is released and may be+ reused in a future touch down event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the touch up event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ </event>++ <event name="motion">+ <description summary="update of touch point coordinates">+ A touch point has changed coordinates.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="frame">+ <description summary="end of touch frame event">+ Indicates the end of a set of events that logically belong together.+ A client is expected to accumulate the data in all events within the+ frame before proceeding.++ A wl_touch.frame terminates at least one event but otherwise no+ guarantee is provided about the set of events within a frame. A client+ must assume that any state not updated in a frame is unchanged from the+ previously known state.+ </description>+ </event>++ <event name="cancel">+ <description summary="touch session cancelled">+ Sent if the compositor decides the touch stream is a global+ gesture. No further events are sent to the clients from that+ particular gesture. Touch cancellation applies to all touch points+ currently active on this client's surface. The client is+ responsible for finalizing the touch points, future touch points on+ this surface may reuse the touch point ID.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the touch object"/>+ </request>++ <!-- Version 6 additions -->++ <event name="shape" since="6">+ <description summary="update shape of touch point">+ Sent when a touchpoint has changed its shape.++ This event does not occur on its own. It is sent before a+ wl_touch.frame event and carries the new shape information for+ any previously reported, or new touch points of that frame.++ Other events describing the touch point such as wl_touch.down,+ wl_touch.motion or wl_touch.orientation may be sent within the+ same wl_touch.frame. A client should treat these events as a single+ logical touch point update. The order of wl_touch.shape,+ wl_touch.orientation and wl_touch.motion is not guaranteed.+ A wl_touch.down event is guaranteed to occur before the first+ wl_touch.shape event for this touch ID but both events may occur within+ the same wl_touch.frame.++ A touchpoint shape is approximated by an ellipse through the major and+ minor axis length. The major axis length describes the longer diameter+ of the ellipse, while the minor axis length describes the shorter+ diameter. Major and minor are orthogonal and both are specified in+ surface-local coordinates. The center of the ellipse is always at the+ touchpoint location as reported by wl_touch.down or wl_touch.move.++ This event is only sent by the compositor if the touch device supports+ shape reports. The client has to make reasonable assumptions about the+ shape if it did not receive this event.+ </description>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="major" type="fixed" summary="length of the major axis in surface-local coordinates"/>+ <arg name="minor" type="fixed" summary="length of the minor axis in surface-local coordinates"/>+ </event>++ <event name="orientation" since="6">+ <description summary="update orientation of touch point">+ Sent when a touchpoint has changed its orientation.++ This event does not occur on its own. It is sent before a+ wl_touch.frame event and carries the new shape information for+ any previously reported, or new touch points of that frame.++ Other events describing the touch point such as wl_touch.down,+ wl_touch.motion or wl_touch.shape may be sent within the+ same wl_touch.frame. A client should treat these events as a single+ logical touch point update. The order of wl_touch.shape,+ wl_touch.orientation and wl_touch.motion is not guaranteed.+ A wl_touch.down event is guaranteed to occur before the first+ wl_touch.orientation event for this touch ID but both events may occur+ within the same wl_touch.frame.++ The orientation describes the clockwise angle of a touchpoint's major+ axis to the positive surface y-axis and is normalized to the -180 to+ +180 degree range. The granularity of orientation depends on the touch+ device, some devices only support binary rotation values between 0 and+ 90 degrees.++ This event is only sent by the compositor if the touch device supports+ orientation reports.+ </description>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="orientation" type="fixed" summary="angle between major axis and positive surface y-axis in degrees"/>+ </event>+ </interface>++ <interface name="wl_output" version="4">+ <description summary="compositor output region">+ An output describes part of the compositor geometry. The+ compositor works in the 'compositor coordinate system' and an+ output corresponds to a rectangular area in that space that is+ actually visible. This typically corresponds to a monitor that+ displays part of the compositor space. This object is published+ as global during start up, or when a monitor is hotplugged.+ </description>++ <enum name="subpixel">+ <description summary="subpixel geometry information">+ This enumeration describes how the physical+ pixels on an output are laid out.+ </description>+ <entry name="unknown" value="0" summary="unknown geometry"/>+ <entry name="none" value="1" summary="no geometry"/>+ <entry name="horizontal_rgb" value="2" summary="horizontal RGB"/>+ <entry name="horizontal_bgr" value="3" summary="horizontal BGR"/>+ <entry name="vertical_rgb" value="4" summary="vertical RGB"/>+ <entry name="vertical_bgr" value="5" summary="vertical BGR"/>+ </enum>++ <enum name="transform">+ <description summary="transform from framebuffer to output">+ This describes the transform that a compositor will apply to a+ surface to compensate for the rotation or mirroring of an+ output device.++ The flipped values correspond to an initial flip around a+ vertical axis followed by rotation.++ The purpose is mainly to allow clients to render accordingly and+ tell the compositor, so that for fullscreen surfaces, the+ compositor will still be able to scan out directly from client+ surfaces.+ </description>+ <entry name="normal" value="0" summary="no transform"/>+ <entry name="90" value="1" summary="90 degrees counter-clockwise"/>+ <entry name="180" value="2" summary="180 degrees counter-clockwise"/>+ <entry name="270" value="3" summary="270 degrees counter-clockwise"/>+ <entry name="flipped" value="4" summary="180 degree flip around a vertical axis"/>+ <entry name="flipped_90" value="5" summary="flip and rotate 90 degrees counter-clockwise"/>+ <entry name="flipped_180" value="6" summary="flip and rotate 180 degrees counter-clockwise"/>+ <entry name="flipped_270" value="7" summary="flip and rotate 270 degrees counter-clockwise"/>+ </enum>++ <event name="geometry">+ <description summary="properties of the output">+ The geometry event describes geometric properties of the output.+ The event is sent when binding to the output object and whenever+ any of the properties change.++ The physical size can be set to zero if it doesn't make sense for this+ output (e.g. for projectors or virtual outputs).++ The geometry event will be followed by a done event (starting from+ version 2).++ Note: wl_output only advertises partial information about the output+ position and identification. Some compositors, for instance those not+ implementing a desktop-style output layout or those exposing virtual+ outputs, might fake this information. Instead of using x and y, clients+ should use xdg_output.logical_position. Instead of using make and model,+ clients should use name and description.+ </description>+ <arg name="x" type="int"+ summary="x position within the global compositor space"/>+ <arg name="y" type="int"+ summary="y position within the global compositor space"/>+ <arg name="physical_width" type="int"+ summary="width in millimeters of the output"/>+ <arg name="physical_height" type="int"+ summary="height in millimeters of the output"/>+ <arg name="subpixel" type="int" enum="subpixel"+ summary="subpixel orientation of the output"/>+ <arg name="make" type="string"+ summary="textual description of the manufacturer"/>+ <arg name="model" type="string"+ summary="textual description of the model"/>+ <arg name="transform" type="int" enum="transform"+ summary="transform that maps framebuffer to output"/>+ </event>++ <enum name="mode" bitfield="true">+ <description summary="mode information">+ These flags describe properties of an output mode.+ They are used in the flags bitfield of the mode event.+ </description>+ <entry name="current" value="0x1"+ summary="indicates this is the current mode"/>+ <entry name="preferred" value="0x2"+ summary="indicates this is the preferred mode"/>+ </enum>++ <event name="mode">+ <description summary="advertise available modes for the output">+ The mode event describes an available mode for the output.++ The event is sent when binding to the output object and there+ will always be one mode, the current mode. The event is sent+ again if an output changes mode, for the mode that is now+ current. In other words, the current mode is always the last+ mode that was received with the current flag set.++ Non-current modes are deprecated. A compositor can decide to only+ advertise the current mode and never send other modes. Clients+ should not rely on non-current modes.++ The size of a mode is given in physical hardware units of+ the output device. This is not necessarily the same as+ the output size in the global compositor space. For instance,+ the output may be scaled, as described in wl_output.scale,+ or transformed, as described in wl_output.transform. Clients+ willing to retrieve the output size in the global compositor+ space should use xdg_output.logical_size instead.++ The vertical refresh rate can be set to zero if it doesn't make+ sense for this output (e.g. for virtual outputs).++ The mode event will be followed by a done event (starting from+ version 2).++ Clients should not use the refresh rate to schedule frames. Instead,+ they should use the wl_surface.frame event or the presentation-time+ protocol.++ Note: this information is not always meaningful for all outputs. Some+ compositors, such as those exposing virtual outputs, might fake the+ refresh rate or the size.+ </description>+ <arg name="flags" type="uint" enum="mode" summary="bitfield of mode flags"/>+ <arg name="width" type="int" summary="width of the mode in hardware units"/>+ <arg name="height" type="int" summary="height of the mode in hardware units"/>+ <arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>+ </event>++ <!-- Version 2 additions -->++ <event name="done" since="2">+ <description summary="sent all information about output">+ This event is sent after all other properties have been+ sent after binding to the output object and after any+ other property changes done after that. This allows+ changes to the output properties to be seen as+ atomic, even if they happen via multiple events.+ </description>+ </event>++ <event name="scale" since="2">+ <description summary="output scaling properties">+ This event contains scaling geometry information+ that is not in the geometry event. It may be sent after+ binding the output object or if the output scale changes+ later. If it is not sent, the client should assume a+ scale of 1.++ A scale larger than 1 means that the compositor will+ automatically scale surface buffers by this amount+ when rendering. This is used for very high resolution+ displays where applications rendering at the native+ resolution would be too small to be legible.++ It is intended that scaling aware clients track the+ current output of a surface, and if it is on a scaled+ output it should use wl_surface.set_buffer_scale with+ the scale of the output. That way the compositor can+ avoid scaling the surface, and the client can supply+ a higher detail image.++ The scale event will be followed by a done event.+ </description>+ <arg name="factor" type="int" summary="scaling factor of output"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the output object">+ Using this request a client can tell the server that it is not going to+ use the output object anymore.+ </description>+ </request>++ <!-- Version 4 additions -->++ <event name="name" since="4">+ <description summary="name of this output">+ Many compositors will assign user-friendly names to their outputs, show+ them to the user, allow the user to refer to an output, etc. The client+ may wish to know this name as well to offer the user similar behaviors.++ The name is a UTF-8 string with no convention defined for its contents.+ Each name is unique among all wl_output globals. The name is only+ guaranteed to be unique for the compositor instance.++ The same output name is used for all clients for a given wl_output+ global. Thus, the name can be shared across processes to refer to a+ specific wl_output global.++ The name is not guaranteed to be persistent across sessions, thus cannot+ be used to reliably identify an output in e.g. configuration files.++ Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do+ not assume that the name is a reflection of an underlying DRM connector,+ X11 connection, etc.++ The name event is sent after binding the output object. This event is+ only sent once per output object, and the name does not change over the+ lifetime of the wl_output global.++ Compositors may re-use the same output name if the wl_output global is+ destroyed and re-created later. Compositors should avoid re-using the+ same name if possible.++ The name event will be followed by a done event.+ </description>+ <arg name="name" type="string" summary="output name"/>+ </event>++ <event name="description" since="4">+ <description summary="human-readable description of this output">+ Many compositors can produce human-readable descriptions of their+ outputs. The client may wish to know this description as well, e.g. for+ output selection purposes.++ The description is a UTF-8 string with no convention defined for its+ contents. The description is not guaranteed to be unique among all+ wl_output globals. Examples might include 'Foocorp 11" Display' or+ 'Virtual X11 output via :1'.++ The description event is sent after binding the output object and+ whenever the description changes. The description is optional, and may+ not be sent at all.++ The description event will be followed by a done event.+ </description>+ <arg name="description" type="string" summary="output description"/>+ </event>+ </interface>++ <interface name="wl_region" version="1">+ <description summary="region interface">+ A region object describes an area.++ Region objects are used to describe the opaque and input+ regions of a surface.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy region">+ Destroy the region. This will invalidate the object ID.+ </description>+ </request>++ <request name="add">+ <description summary="add rectangle to region">+ Add the specified rectangle to the region.+ </description>+ <arg name="x" type="int" summary="region-local x coordinate"/>+ <arg name="y" type="int" summary="region-local y coordinate"/>+ <arg name="width" type="int" summary="rectangle width"/>+ <arg name="height" type="int" summary="rectangle height"/>+ </request>++ <request name="subtract">+ <description summary="subtract rectangle from region">+ Subtract the specified rectangle from the region.+ </description>+ <arg name="x" type="int" summary="region-local x coordinate"/>+ <arg name="y" type="int" summary="region-local y coordinate"/>+ <arg name="width" type="int" summary="rectangle width"/>+ <arg name="height" type="int" summary="rectangle height"/>+ </request>+ </interface>++ <interface name="wl_subcompositor" version="1">+ <description summary="sub-surface compositing">+ The global interface exposing sub-surface compositing capabilities.+ A wl_surface, that has sub-surfaces associated, is called the+ parent surface. Sub-surfaces can be arbitrarily nested and create+ a tree of sub-surfaces.++ The root surface in a tree of sub-surfaces is the main+ surface. The main surface cannot be a sub-surface, because+ sub-surfaces must always have a parent.++ A main surface with its sub-surfaces forms a (compound) window.+ For window management purposes, this set of wl_surface objects is+ to be considered as a single window, and it should also behave as+ such.++ The aim of sub-surfaces is to offload some of the compositing work+ within a window from clients to the compositor. A prime example is+ a video player with decorations and video in separate wl_surface+ objects. This should allow the compositor to pass YUV video buffer+ processing to dedicated overlay hardware when possible.+ </description>++ <request name="destroy" type="destructor">+ <description summary="unbind from the subcompositor interface">+ Informs the server that the client will not be using this+ protocol object anymore. This does not affect any other+ objects, wl_subsurface objects included.+ </description>+ </request>++ <enum name="error">+ <entry name="bad_surface" value="0"+ summary="the to-be sub-surface is invalid"/>+ <entry name="bad_parent" value="1"+ summary="the to-be sub-surface parent is invalid"/>+ </enum>++ <request name="get_subsurface">+ <description summary="give a surface the role sub-surface">+ Create a sub-surface interface for the given surface, and+ associate it with the given parent surface. This turns a+ plain wl_surface into a sub-surface.++ The to-be sub-surface must not already have another role, and it+ must not have an existing wl_subsurface object. Otherwise the+ bad_surface protocol error is raised.++ Adding sub-surfaces to a parent is a double-buffered operation on the+ parent (see wl_surface.commit). The effect of adding a sub-surface+ becomes visible on the next time the state of the parent surface is+ applied.++ The parent surface must not be one of the child surface's descendants,+ and the parent must be different from the child surface, otherwise the+ bad_parent protocol error is raised.++ This request modifies the behaviour of wl_surface.commit request on+ the sub-surface, see the documentation on wl_subsurface interface.+ </description>+ <arg name="id" type="new_id" interface="wl_subsurface"+ summary="the new sub-surface object ID"/>+ <arg name="surface" type="object" interface="wl_surface"+ summary="the surface to be turned into a sub-surface"/>+ <arg name="parent" type="object" interface="wl_surface"+ summary="the parent surface"/>+ </request>+ </interface>++ <interface name="wl_subsurface" version="1">+ <description summary="sub-surface interface to a wl_surface">+ An additional interface to a wl_surface object, which has been+ made a sub-surface. A sub-surface has one parent surface. A+ sub-surface's size and position are not limited to that of the parent.+ Particularly, a sub-surface is not automatically clipped to its+ parent's area.++ A sub-surface becomes mapped, when a non-NULL wl_buffer is applied+ and the parent surface is mapped. The order of which one happens+ first is irrelevant. A sub-surface is hidden if the parent becomes+ hidden, or if a NULL wl_buffer is applied. These rules apply+ recursively through the tree of surfaces.++ The behaviour of a wl_surface.commit request on a sub-surface+ depends on the sub-surface's mode. The possible modes are+ synchronized and desynchronized, see methods+ wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized+ mode caches the wl_surface state to be applied when the parent's+ state gets applied, and desynchronized mode applies the pending+ wl_surface state directly. A sub-surface is initially in the+ synchronized mode.++ Sub-surfaces also have another kind of state, which is managed by+ wl_subsurface requests, as opposed to wl_surface requests. This+ state includes the sub-surface position relative to the parent+ surface (wl_subsurface.set_position), and the stacking order of+ the parent and its sub-surfaces (wl_subsurface.place_above and+ .place_below). This state is applied when the parent surface's+ wl_surface state is applied, regardless of the sub-surface's mode.+ As the exception, set_sync and set_desync are effective immediately.++ The main surface can be thought to be always in desynchronized mode,+ since it does not have a parent in the sub-surfaces sense.++ Even if a sub-surface is in desynchronized mode, it will behave as+ in synchronized mode, if its parent surface behaves as in+ synchronized mode. This rule is applied recursively throughout the+ tree of surfaces. This means, that one can set a sub-surface into+ synchronized mode, and then assume that all its child and grand-child+ sub-surfaces are synchronized, too, without explicitly setting them.++ Destroying a sub-surface takes effect immediately. If you need to+ synchronize the removal of a sub-surface to the parent surface update,+ unmap the sub-surface first by attaching a NULL wl_buffer, update parent,+ and then destroy the sub-surface.++ If the parent wl_surface object is destroyed, the sub-surface is+ unmapped.+ </description>++ <request name="destroy" type="destructor">+ <description summary="remove sub-surface interface">+ The sub-surface interface is removed from the wl_surface object+ that was turned into a sub-surface with a+ wl_subcompositor.get_subsurface request. The wl_surface's association+ to the parent is deleted. The wl_surface is unmapped immediately.+ </description>+ </request>++ <enum name="error">+ <entry name="bad_surface" value="0"+ summary="wl_surface is not a sibling or the parent"/>+ </enum>++ <request name="set_position">+ <description summary="reposition the sub-surface">+ This schedules a sub-surface position change.+ The sub-surface will be moved so that its origin (top left+ corner pixel) will be at the location x, y of the parent surface+ coordinate system. The coordinates are not restricted to the parent+ surface area. Negative values are allowed.++ The scheduled coordinates will take effect whenever the state of the+ parent surface is applied. When this happens depends on whether the+ parent surface is in synchronized mode or not. See+ wl_subsurface.set_sync and wl_subsurface.set_desync for details.++ If more than one set_position request is invoked by the client before+ the commit of the parent surface, the position of a new request always+ replaces the scheduled position from any previous request.++ The initial position is 0, 0.+ </description>+ <arg name="x" type="int" summary="x coordinate in the parent surface"/>+ <arg name="y" type="int" summary="y coordinate in the parent surface"/>+ </request>++ <request name="place_above">+ <description summary="restack the sub-surface">+ This sub-surface is taken from the stack, and put back just+ above the reference surface, changing the z-order of the sub-surfaces.+ The reference surface must be one of the sibling surfaces, or the+ parent surface. Using any other surface, including this sub-surface,+ will cause a protocol error.++ The z-order is double-buffered. Requests are handled in order and+ applied immediately to a pending state. The final pending state is+ copied to the active state the next time the state of the parent+ surface is applied. When this happens depends on whether the parent+ surface is in synchronized mode or not. See wl_subsurface.set_sync and+ wl_subsurface.set_desync for details.++ A new sub-surface is initially added as the top-most in the stack+ of its siblings and parent.+ </description>+ <arg name="sibling" type="object" interface="wl_surface"+ summary="the reference surface"/>+ </request>++ <request name="place_below">+ <description summary="restack the sub-surface">+ The sub-surface is placed just below the reference surface.+ See wl_subsurface.place_above.+ </description>+ <arg name="sibling" type="object" interface="wl_surface"+ summary="the reference surface"/>+ </request>++ <request name="set_sync">+ <description summary="set sub-surface to synchronized mode">+ Change the commit behaviour of the sub-surface to synchronized+ mode, also described as the parent dependent mode.++ In synchronized mode, wl_surface.commit on a sub-surface will+ accumulate the committed state in a cache, but the state will+ not be applied and hence will not change the compositor output.+ The cached state is applied to the sub-surface immediately after+ the parent surface's state is applied. This ensures atomic+ updates of the parent and all its synchronized sub-surfaces.+ Applying the cached state will invalidate the cache, so further+ parent surface commits do not (re-)apply old state.++ See wl_subsurface for the recursive effect of this mode.+ </description>+ </request>++ <request name="set_desync">+ <description summary="set sub-surface to desynchronized mode">+ Change the commit behaviour of the sub-surface to desynchronized+ mode, also described as independent or freely running mode.++ In desynchronized mode, wl_surface.commit on a sub-surface will+ apply the pending state directly, without caching, as happens+ normally with a wl_surface. Calling wl_surface.commit on the+ parent surface has no effect on the sub-surface's wl_surface+ state. This mode allows a sub-surface to be updated on its own.++ If cached state exists when wl_surface.commit is called in+ desynchronized mode, the pending state is added to the cached+ state, and applied as a whole. This invalidates the cache.++ Note: even if a sub-surface is set to desynchronized, a parent+ sub-surface may override it to behave as synchronized. For details,+ see wl_subsurface.++ If a surface's parent surface behaves as desynchronized, then+ the cached state is applied on set_desync.+ </description>+ </request>+ </interface>++</protocol>
+ examples/simple-client/simple-client.cabal view
@@ -0,0 +1,42 @@+cabal-version: 3.0+name: simple-client+version: 0.1+author: Andrea Rossato+maintainer: andrea.rossato@unitn.it+homepage: https://codeberg.org/andrea_rossato/hs-wayland-scanner+synopsis: a simple wayland client+description: a simple wayland client++category: System+license: BSD-3-Clause+extra-source-files: README.md+build-type: Simple++library+ hs-source-dirs: ./src+ exposed-modules: Graphics.Wayland.Protocol.Wayland+ Graphics.Wayland.Client.Protocol.Wayland+ Graphics.Wayland.Client.Core+ include-dirs: ./cbits+ c-sources: ./cbits/wayland-client-protocols.c+ build-depends: base+ pkgconfig-depends: wayland-server+ ghc-options: -O -Wall+ ghc-prof-options: -auto-all+ default-language: Haskell2010+ default-extensions: ForeignFunctionInterface++executable simple-client+ main-is: simple-client.hs+ hs-source-dirs: ., ./src+ other-modules: Graphics.Wayland.Protocol.Wayland+ Graphics.Wayland.Client.Protocol.Wayland+ Graphics.Wayland.Client.Core+ include-dirs: ./cbits+ c-sources: ./cbits/wayland-client-protocols.c+ build-depends: base+ pkgconfig-depends: wayland-client+ ghc-options: -O -Wall+ ghc-prof-options: -auto-all+ default-language: Haskell2010+ default-extensions: ForeignFunctionInterface
+ examples/simple-client/simple-client.hs view
@@ -0,0 +1,60 @@+module Main where++import Control.Concurrent+import Control.Monad+import Foreign hiding ( void )+import Foreign.C.String+import System.Exit++import Graphics.Wayland.Client.Core+import Graphics.Wayland.Client.Protocol.Wayland++-- Global registry callback+globalCb :: WlRegistryGlobalCb+globalCb _ registry name interface version = do+ iface <- peekCString interface+ putStrLn ("[CLIENT] Global: " ++ iface ++ " (name=" ++ show name ++ ")")+ when (iface == "wl_compositor") $ do+ comp <- wl_registry_bind+ registry+ name+ wl_compositor_interface+ version++ putStrLn "[CLIENT] bound compositor"++ -- Call create_surface+ void $ wl_compositor_create_surface (castPtr comp)++main :: IO ()+main = do+ -- 1. Connect+ display <- wl_display_connect nullPtr+ when (display == nullPtr) $ do+ putStrLn "Failed to connect to Wayland."+ exitFailure+ putStrLn "Connected!"++ -- 2. Get the registry+ registry <- wl_display_get_registry display++ -- 3. Add the global listener+ cb <- mkWlRegistryGlobalCb globalCb+ let listener = WlRegistryListener+ { wlRegistryGlobal = cb+ , wlRegistryGlobalRemove = nullFunPtr+ }++ alloca $ \ptr -> do+ poke ptr listener+ void $ wl_registry_add_listener registry ptr nullPtr++ void $ wl_display_roundtrip display+ void $ wl_display_flush display++ -- give the server some time to elaborate+ threadDelay 2000000++ -- 4. Cleanup and exit+ wl_display_disconnect display+ exitSuccess
+ examples/simple-server/README.md view
@@ -0,0 +1,65 @@+About+=====++A simple Wayland server, to be used together with `simple-client`++Building+========++Use `hws -c hs-wayland-scanner.cfg` to generate the Wayland bindings:++``` shell+cd examples/simple-server+/path/to/hws -c hs-wayland-scanner.cfg+```++Alternatively run:++``` shell+/path/to/hws -p ./ -r Server protocols/wayland.xml+```++Now you can build it with `cabal`:++``` shell+cabal [run|build|install]+```++Running+=======++Run with:++``` shell+/path/to/simple-server+```++The server will print the socket name used for waiting for connections:++``` shell+[SERVER] Wayland server running...+[SERVER] Socket: wayland-0+```++You can use the socket name to connect `simple-client` with:++``` shell+WAYLAND_DISPLAY="wayland-0" /path/to/simple-client+```++When the client connects you should see something like:++``` shell+[SERVER] Client bound to wl_compositor+[SERVER] create_surface called, new id = 0x0000000000000005+```++Documentation+=============++This example exposes a library also to show the documentation+generated by `hws`. To produce the documentation run:++``` shell+cabal haddock+```
+ examples/simple-server/hs-wayland-scanner.cfg view
@@ -0,0 +1,8 @@+HwsConfig+ { genPrefix = "./"+ , hsNameSpace = "Graphics"+ , protoRole = Server+ , protocols = ["protocols/wayland.xml"]+ , cbitsPrefix = "cbits"+ , srcPrefix = "src"+ }
+ examples/simple-server/protocols/wayland.xml view
@@ -0,0 +1,3151 @@+<?xml version="1.0" encoding="UTF-8"?>+<protocol name="wayland">++ <copyright>+ Copyright © 2008-2011 Kristian Høgsberg+ Copyright © 2010-2011 Intel Corporation+ Copyright © 2012-2013 Collabora, Ltd.++ Permission is hereby granted, free of charge, to any person+ obtaining a copy of this software and associated documentation files+ (the "Software"), to deal in the Software without restriction,+ including without limitation the rights to use, copy, modify, merge,+ publish, distribute, sublicense, and/or sell copies of the Software,+ and to permit persons to whom the Software is furnished to do so,+ subject to the following conditions:++ The above copyright notice and this permission notice (including the+ next paragraph) shall be included in all copies or substantial+ portions of the Software.++ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE+ SOFTWARE.+ </copyright>++ <interface name="wl_display" version="1">+ <description summary="core global object">+ The core global object. This is a special singleton object. It+ is used for internal Wayland protocol features.+ </description>++ <request name="sync">+ <description summary="asynchronous roundtrip">+ The sync request asks the server to emit the 'done' event+ on the returned wl_callback object. Since requests are+ handled in-order and events are delivered in-order, this can+ be used as a barrier to ensure all previous requests and the+ resulting events have been handled.++ The object returned by this request will be destroyed by the+ compositor after the callback is fired and as such the client must not+ attempt to use it after that point.++ The callback_data passed in the callback is the event serial.+ </description>+ <arg name="callback" type="new_id" interface="wl_callback"+ summary="callback object for the sync request"/>+ </request>++ <request name="get_registry">+ <description summary="get global registry object">+ This request creates a registry object that allows the client+ to list and bind the global objects available from the+ compositor.++ It should be noted that the server side resources consumed in+ response to a get_registry request can only be released when the+ client disconnects, not when the client side proxy is destroyed.+ Therefore, clients should invoke get_registry as infrequently as+ possible to avoid wasting memory.+ </description>+ <arg name="registry" type="new_id" interface="wl_registry"+ summary="global registry object"/>+ </request>++ <event name="error">+ <description summary="fatal error event">+ The error event is sent out when a fatal (non-recoverable)+ error has occurred. The object_id argument is the object+ where the error occurred, most often in response to a request+ to that object. The code identifies the error and is defined+ by the object interface. As such, each interface defines its+ own set of error codes. The message is a brief description+ of the error, for (debugging) convenience.+ </description>+ <arg name="object_id" type="object" summary="object where the error occurred"/>+ <arg name="code" type="uint" summary="error code"/>+ <arg name="message" type="string" summary="error description"/>+ </event>++ <enum name="error">+ <description summary="global error values">+ These errors are global and can be emitted in response to any+ server request.+ </description>+ <entry name="invalid_object" value="0"+ summary="server couldn't find object"/>+ <entry name="invalid_method" value="1"+ summary="method doesn't exist on the specified interface or malformed request"/>+ <entry name="no_memory" value="2"+ summary="server is out of memory"/>+ <entry name="implementation" value="3"+ summary="implementation error in compositor"/>+ </enum>++ <event name="delete_id">+ <description summary="acknowledge object ID deletion">+ This event is used internally by the object ID management+ logic. When a client deletes an object that it had created,+ the server will send this event to acknowledge that it has+ seen the delete request. When the client receives this event,+ it will know that it can safely reuse the object ID.+ </description>+ <arg name="id" type="uint" summary="deleted object ID"/>+ </event>+ </interface>++ <interface name="wl_registry" version="1">+ <description summary="global registry object">+ The singleton global registry object. The server has a number of+ global objects that are available to all clients. These objects+ typically represent an actual object in the server (for example,+ an input device) or they are singleton objects that provide+ extension functionality.++ When a client creates a registry object, the registry object+ will emit a global event for each global currently in the+ registry. Globals come and go as a result of device or+ monitor hotplugs, reconfiguration or other events, and the+ registry will send out global and global_remove events to+ keep the client up to date with the changes. To mark the end+ of the initial burst of events, the client can use the+ wl_display.sync request immediately after calling+ wl_display.get_registry.++ A client can bind to a global object by using the bind+ request. This creates a client-side handle that lets the object+ emit events to the client and lets the client invoke requests on+ the object.+ </description>++ <request name="bind">+ <description summary="bind an object to the display">+ Binds a new, client-created object to the server using the+ specified name as the identifier.+ </description>+ <arg name="name" type="uint" summary="unique numeric name of the object"/>+ <arg name="id" type="new_id" summary="bounded object"/>+ </request>++ <event name="global">+ <description summary="announce global object">+ Notify the client of global objects.++ The event notifies the client that a global object with+ the given name is now available, and it implements the+ given version of the given interface.+ </description>+ <arg name="name" type="uint" summary="numeric name of the global object"/>+ <arg name="interface" type="string" summary="interface implemented by the object"/>+ <arg name="version" type="uint" summary="interface version"/>+ </event>++ <event name="global_remove">+ <description summary="announce removal of global object">+ Notify the client of removed global objects.++ This event notifies the client that the global identified+ by name is no longer available. If the client bound to+ the global using the bind request, the client should now+ destroy that object.++ The object remains valid and requests to the object will be+ ignored until the client destroys it, to avoid races between+ the global going away and a client sending a request to it.+ </description>+ <arg name="name" type="uint" summary="numeric name of the global object"/>+ </event>+ </interface>++ <interface name="wl_callback" version="1">+ <description summary="callback object">+ Clients can handle the 'done' event to get notified when+ the related request is done.++ Note, because wl_callback objects are created from multiple independent+ factory interfaces, the wl_callback interface is frozen at version 1.+ </description>++ <event name="done" type="destructor">+ <description summary="done event">+ Notify the client when the related request is done.+ </description>+ <arg name="callback_data" type="uint" summary="request-specific data for the callback"/>+ </event>+ </interface>++ <interface name="wl_compositor" version="6">+ <description summary="the compositor singleton">+ A compositor. This object is a singleton global. The+ compositor is in charge of combining the contents of multiple+ surfaces into one displayable output.+ </description>++ <request name="create_surface">+ <description summary="create new surface">+ Ask the compositor to create a new surface.+ </description>+ <arg name="id" type="new_id" interface="wl_surface" summary="the new surface"/>+ </request>++ <request name="create_region">+ <description summary="create new region">+ Ask the compositor to create a new region.+ </description>+ <arg name="id" type="new_id" interface="wl_region" summary="the new region"/>+ </request>+ </interface>++ <interface name="wl_shm_pool" version="1">+ <description summary="a shared memory pool">+ The wl_shm_pool object encapsulates a piece of memory shared+ between the compositor and client. Through the wl_shm_pool+ object, the client can allocate shared memory wl_buffer objects.+ All objects created through the same pool share the same+ underlying mapped memory. Reusing the mapped memory avoids the+ setup/teardown overhead and is useful when interactively resizing+ a surface or for many small buffers.+ </description>++ <request name="create_buffer">+ <description summary="create a buffer from the pool">+ Create a wl_buffer object from the pool.++ The buffer is created offset bytes into the pool and has+ width and height as specified. The stride argument specifies+ the number of bytes from the beginning of one row to the beginning+ of the next. The format is the pixel format of the buffer and+ must be one of those advertised through the wl_shm.format event.++ A buffer will keep a reference to the pool it was created from+ so it is valid to destroy the pool immediately after creating+ a buffer from it.+ </description>+ <arg name="id" type="new_id" interface="wl_buffer" summary="buffer to create"/>+ <arg name="offset" type="int" summary="buffer byte offset within the pool"/>+ <arg name="width" type="int" summary="buffer width, in pixels"/>+ <arg name="height" type="int" summary="buffer height, in pixels"/>+ <arg name="stride" type="int" summary="number of bytes from the beginning of one row to the beginning of the next row"/>+ <arg name="format" type="uint" enum="wl_shm.format" summary="buffer pixel format"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy the pool">+ Destroy the shared memory pool.++ The mmapped memory will be released when all+ buffers that have been created from this pool+ are gone.+ </description>+ </request>++ <request name="resize">+ <description summary="change the size of the pool mapping">+ This request will cause the server to remap the backing memory+ for the pool from the file descriptor passed when the pool was+ created, but using the new size. This request can only be+ used to make the pool bigger.++ This request only changes the amount of bytes that are mmapped+ by the server and does not touch the file corresponding to the+ file descriptor passed at creation time. It is the client's+ responsibility to ensure that the file is at least as big as+ the new pool size.+ </description>+ <arg name="size" type="int" summary="new size of the pool, in bytes"/>+ </request>+ </interface>++ <interface name="wl_shm" version="1">+ <description summary="shared memory support">+ A singleton global object that provides support for shared+ memory.++ Clients can create wl_shm_pool objects using the create_pool+ request.++ On binding the wl_shm object one or more format events+ are emitted to inform clients about the valid pixel formats+ that can be used for buffers.+ </description>++ <enum name="error">+ <description summary="wl_shm error values">+ These errors can be emitted in response to wl_shm requests.+ </description>+ <entry name="invalid_format" value="0" summary="buffer format is not known"/>+ <entry name="invalid_stride" value="1" summary="invalid size or stride during pool or buffer creation"/>+ <entry name="invalid_fd" value="2" summary="mmapping the file descriptor failed"/>+ </enum>++ <enum name="format">+ <description summary="pixel formats">+ This describes the memory layout of an individual pixel.++ All renderers should support argb8888 and xrgb8888 but any other+ formats are optional and may not be supported by the particular+ renderer in use.++ The drm format codes match the macros defined in drm_fourcc.h, except+ argb8888 and xrgb8888. The formats actually supported by the compositor+ will be reported by the format event.++ For all wl_shm formats and unless specified in another protocol+ extension, pre-multiplied alpha is used for pixel values.+ </description>+ <!-- Note to protocol writers: don't update this list manually, instead+ run the automated script that keeps it in sync with drm_fourcc.h. -->+ <entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>+ <entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>+ <entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>+ <entry name="rgb332" value="0x38424752" summary="8-bit RGB format, [7:0] R:G:B 3:3:2"/>+ <entry name="bgr233" value="0x38524742" summary="8-bit BGR format, [7:0] B:G:R 2:3:3"/>+ <entry name="xrgb4444" value="0x32315258" summary="16-bit xRGB format, [15:0] x:R:G:B 4:4:4:4 little endian"/>+ <entry name="xbgr4444" value="0x32314258" summary="16-bit xBGR format, [15:0] x:B:G:R 4:4:4:4 little endian"/>+ <entry name="rgbx4444" value="0x32315852" summary="16-bit RGBx format, [15:0] R:G:B:x 4:4:4:4 little endian"/>+ <entry name="bgrx4444" value="0x32315842" summary="16-bit BGRx format, [15:0] B:G:R:x 4:4:4:4 little endian"/>+ <entry name="argb4444" value="0x32315241" summary="16-bit ARGB format, [15:0] A:R:G:B 4:4:4:4 little endian"/>+ <entry name="abgr4444" value="0x32314241" summary="16-bit ABGR format, [15:0] A:B:G:R 4:4:4:4 little endian"/>+ <entry name="rgba4444" value="0x32314152" summary="16-bit RBGA format, [15:0] R:G:B:A 4:4:4:4 little endian"/>+ <entry name="bgra4444" value="0x32314142" summary="16-bit BGRA format, [15:0] B:G:R:A 4:4:4:4 little endian"/>+ <entry name="xrgb1555" value="0x35315258" summary="16-bit xRGB format, [15:0] x:R:G:B 1:5:5:5 little endian"/>+ <entry name="xbgr1555" value="0x35314258" summary="16-bit xBGR 1555 format, [15:0] x:B:G:R 1:5:5:5 little endian"/>+ <entry name="rgbx5551" value="0x35315852" summary="16-bit RGBx 5551 format, [15:0] R:G:B:x 5:5:5:1 little endian"/>+ <entry name="bgrx5551" value="0x35315842" summary="16-bit BGRx 5551 format, [15:0] B:G:R:x 5:5:5:1 little endian"/>+ <entry name="argb1555" value="0x35315241" summary="16-bit ARGB 1555 format, [15:0] A:R:G:B 1:5:5:5 little endian"/>+ <entry name="abgr1555" value="0x35314241" summary="16-bit ABGR 1555 format, [15:0] A:B:G:R 1:5:5:5 little endian"/>+ <entry name="rgba5551" value="0x35314152" summary="16-bit RGBA 5551 format, [15:0] R:G:B:A 5:5:5:1 little endian"/>+ <entry name="bgra5551" value="0x35314142" summary="16-bit BGRA 5551 format, [15:0] B:G:R:A 5:5:5:1 little endian"/>+ <entry name="rgb565" value="0x36314752" summary="16-bit RGB 565 format, [15:0] R:G:B 5:6:5 little endian"/>+ <entry name="bgr565" value="0x36314742" summary="16-bit BGR 565 format, [15:0] B:G:R 5:6:5 little endian"/>+ <entry name="rgb888" value="0x34324752" summary="24-bit RGB format, [23:0] R:G:B little endian"/>+ <entry name="bgr888" value="0x34324742" summary="24-bit BGR format, [23:0] B:G:R little endian"/>+ <entry name="xbgr8888" value="0x34324258" summary="32-bit xBGR format, [31:0] x:B:G:R 8:8:8:8 little endian"/>+ <entry name="rgbx8888" value="0x34325852" summary="32-bit RGBx format, [31:0] R:G:B:x 8:8:8:8 little endian"/>+ <entry name="bgrx8888" value="0x34325842" summary="32-bit BGRx format, [31:0] B:G:R:x 8:8:8:8 little endian"/>+ <entry name="abgr8888" value="0x34324241" summary="32-bit ABGR format, [31:0] A:B:G:R 8:8:8:8 little endian"/>+ <entry name="rgba8888" value="0x34324152" summary="32-bit RGBA format, [31:0] R:G:B:A 8:8:8:8 little endian"/>+ <entry name="bgra8888" value="0x34324142" summary="32-bit BGRA format, [31:0] B:G:R:A 8:8:8:8 little endian"/>+ <entry name="xrgb2101010" value="0x30335258" summary="32-bit xRGB format, [31:0] x:R:G:B 2:10:10:10 little endian"/>+ <entry name="xbgr2101010" value="0x30334258" summary="32-bit xBGR format, [31:0] x:B:G:R 2:10:10:10 little endian"/>+ <entry name="rgbx1010102" value="0x30335852" summary="32-bit RGBx format, [31:0] R:G:B:x 10:10:10:2 little endian"/>+ <entry name="bgrx1010102" value="0x30335842" summary="32-bit BGRx format, [31:0] B:G:R:x 10:10:10:2 little endian"/>+ <entry name="argb2101010" value="0x30335241" summary="32-bit ARGB format, [31:0] A:R:G:B 2:10:10:10 little endian"/>+ <entry name="abgr2101010" value="0x30334241" summary="32-bit ABGR format, [31:0] A:B:G:R 2:10:10:10 little endian"/>+ <entry name="rgba1010102" value="0x30334152" summary="32-bit RGBA format, [31:0] R:G:B:A 10:10:10:2 little endian"/>+ <entry name="bgra1010102" value="0x30334142" summary="32-bit BGRA format, [31:0] B:G:R:A 10:10:10:2 little endian"/>+ <entry name="yuyv" value="0x56595559" summary="packed YCbCr format, [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian"/>+ <entry name="yvyu" value="0x55595659" summary="packed YCbCr format, [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian"/>+ <entry name="uyvy" value="0x59565955" summary="packed YCbCr format, [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian"/>+ <entry name="vyuy" value="0x59555956" summary="packed YCbCr format, [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian"/>+ <entry name="ayuv" value="0x56555941" summary="packed AYCbCr format, [31:0] A:Y:Cb:Cr 8:8:8:8 little endian"/>+ <entry name="nv12" value="0x3231564e" summary="2 plane YCbCr Cr:Cb format, 2x2 subsampled Cr:Cb plane"/>+ <entry name="nv21" value="0x3132564e" summary="2 plane YCbCr Cb:Cr format, 2x2 subsampled Cb:Cr plane"/>+ <entry name="nv16" value="0x3631564e" summary="2 plane YCbCr Cr:Cb format, 2x1 subsampled Cr:Cb plane"/>+ <entry name="nv61" value="0x3136564e" summary="2 plane YCbCr Cb:Cr format, 2x1 subsampled Cb:Cr plane"/>+ <entry name="yuv410" value="0x39565559" summary="3 plane YCbCr format, 4x4 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu410" value="0x39555659" summary="3 plane YCbCr format, 4x4 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv411" value="0x31315559" summary="3 plane YCbCr format, 4x1 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu411" value="0x31315659" summary="3 plane YCbCr format, 4x1 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv420" value="0x32315559" summary="3 plane YCbCr format, 2x2 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu420" value="0x32315659" summary="3 plane YCbCr format, 2x2 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv422" value="0x36315559" summary="3 plane YCbCr format, 2x1 subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu422" value="0x36315659" summary="3 plane YCbCr format, 2x1 subsampled Cr (1) and Cb (2) planes"/>+ <entry name="yuv444" value="0x34325559" summary="3 plane YCbCr format, non-subsampled Cb (1) and Cr (2) planes"/>+ <entry name="yvu444" value="0x34325659" summary="3 plane YCbCr format, non-subsampled Cr (1) and Cb (2) planes"/>+ <entry name="r8" value="0x20203852" summary="[7:0] R"/>+ <entry name="r16" value="0x20363152" summary="[15:0] R little endian"/>+ <entry name="rg88" value="0x38384752" summary="[15:0] R:G 8:8 little endian"/>+ <entry name="gr88" value="0x38385247" summary="[15:0] G:R 8:8 little endian"/>+ <entry name="rg1616" value="0x32334752" summary="[31:0] R:G 16:16 little endian"/>+ <entry name="gr1616" value="0x32335247" summary="[31:0] G:R 16:16 little endian"/>+ <entry name="xrgb16161616f" value="0x48345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>+ <entry name="xbgr16161616f" value="0x48344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>+ <entry name="argb16161616f" value="0x48345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>+ <entry name="abgr16161616f" value="0x48344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>+ <entry name="xyuv8888" value="0x56555958" summary="[31:0] X:Y:Cb:Cr 8:8:8:8 little endian"/>+ <entry name="vuy888" value="0x34325556" summary="[23:0] Cr:Cb:Y 8:8:8 little endian"/>+ <entry name="vuy101010" value="0x30335556" summary="Y followed by U then V, 10:10:10. Non-linear modifier only"/>+ <entry name="y210" value="0x30313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 10:6:10:6:10:6:10:6 little endian per 2 Y pixels"/>+ <entry name="y212" value="0x32313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 12:4:12:4:12:4:12:4 little endian per 2 Y pixels"/>+ <entry name="y216" value="0x36313259" summary="[63:0] Cr0:Y1:Cb0:Y0 16:16:16:16 little endian per 2 Y pixels"/>+ <entry name="y410" value="0x30313459" summary="[31:0] A:Cr:Y:Cb 2:10:10:10 little endian"/>+ <entry name="y412" value="0x32313459" summary="[63:0] A:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>+ <entry name="y416" value="0x36313459" summary="[63:0] A:Cr:Y:Cb 16:16:16:16 little endian"/>+ <entry name="xvyu2101010" value="0x30335658" summary="[31:0] X:Cr:Y:Cb 2:10:10:10 little endian"/>+ <entry name="xvyu12_16161616" value="0x36335658" summary="[63:0] X:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>+ <entry name="xvyu16161616" value="0x38345658" summary="[63:0] X:Cr:Y:Cb 16:16:16:16 little endian"/>+ <entry name="y0l0" value="0x304c3059" summary="[63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>+ <entry name="x0l0" value="0x304c3058" summary="[63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0 1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>+ <entry name="y0l2" value="0x324c3059" summary="[63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian"/>+ <entry name="x0l2" value="0x324c3058" summary="[63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little endian"/>+ <entry name="yuv420_8bit" value="0x38305559"/>+ <entry name="yuv420_10bit" value="0x30315559"/>+ <entry name="xrgb8888_a8" value="0x38415258"/>+ <entry name="xbgr8888_a8" value="0x38414258"/>+ <entry name="rgbx8888_a8" value="0x38415852"/>+ <entry name="bgrx8888_a8" value="0x38415842"/>+ <entry name="rgb888_a8" value="0x38413852"/>+ <entry name="bgr888_a8" value="0x38413842"/>+ <entry name="rgb565_a8" value="0x38413552"/>+ <entry name="bgr565_a8" value="0x38413542"/>+ <entry name="nv24" value="0x3432564e" summary="non-subsampled Cr:Cb plane"/>+ <entry name="nv42" value="0x3234564e" summary="non-subsampled Cb:Cr plane"/>+ <entry name="p210" value="0x30313250" summary="2x1 subsampled Cr:Cb plane, 10 bit per channel"/>+ <entry name="p010" value="0x30313050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel"/>+ <entry name="p012" value="0x32313050" summary="2x2 subsampled Cr:Cb plane 12 bits per channel"/>+ <entry name="p016" value="0x36313050" summary="2x2 subsampled Cr:Cb plane 16 bits per channel"/>+ <entry name="axbxgxrx106106106106" value="0x30314241" summary="[63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian"/>+ <entry name="nv15" value="0x3531564e" summary="2x2 subsampled Cr:Cb plane"/>+ <entry name="q410" value="0x30313451"/>+ <entry name="q401" value="0x31303451"/>+ <entry name="xrgb16161616" value="0x38345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>+ <entry name="xbgr16161616" value="0x38344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>+ <entry name="argb16161616" value="0x38345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>+ <entry name="abgr16161616" value="0x38344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>+ </enum>++ <request name="create_pool">+ <description summary="create a shm pool">+ Create a new wl_shm_pool object.++ The pool can be used to create shared memory based buffer+ objects. The server will mmap size bytes of the passed file+ descriptor, to use as backing memory for the pool.+ </description>+ <arg name="id" type="new_id" interface="wl_shm_pool" summary="pool to create"/>+ <arg name="fd" type="fd" summary="file descriptor for the pool"/>+ <arg name="size" type="int" summary="pool size, in bytes"/>+ </request>++ <event name="format">+ <description summary="pixel format description">+ Informs the client about a valid pixel format that+ can be used for buffers. Known formats include+ argb8888 and xrgb8888.+ </description>+ <arg name="format" type="uint" enum="format" summary="buffer pixel format"/>+ </event>+ </interface>++ <interface name="wl_buffer" version="1">+ <description summary="content for a wl_surface">+ A buffer provides the content for a wl_surface. Buffers are+ created through factory interfaces such as wl_shm, wp_linux_buffer_params+ (from the linux-dmabuf protocol extension) or similar. It has a width and+ a height and can be attached to a wl_surface, but the mechanism by which a+ client provides and updates the contents is defined by the buffer factory+ interface.++ If the buffer uses a format that has an alpha channel, the alpha channel+ is assumed to be premultiplied in the color channels unless otherwise+ specified.++ Note, because wl_buffer objects are created from multiple independent+ factory interfaces, the wl_buffer interface is frozen at version 1.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy a buffer">+ Destroy a buffer. If and how you need to release the backing+ storage is defined by the buffer factory interface.++ For possible side-effects to a surface, see wl_surface.attach.+ </description>+ </request>++ <event name="release">+ <description summary="compositor releases buffer">+ Sent when this wl_buffer is no longer used by the compositor.+ The client is now free to reuse or destroy this buffer and its+ backing storage.++ If a client receives a release event before the frame callback+ requested in the same wl_surface.commit that attaches this+ wl_buffer to a surface, then the client is immediately free to+ reuse the buffer and its backing storage, and does not need a+ second buffer for the next surface content update. Typically+ this is possible, when the compositor maintains a copy of the+ wl_surface contents, e.g. as a GL texture. This is an important+ optimization for GL(ES) compositors with wl_shm clients.+ </description>+ </event>+ </interface>++ <interface name="wl_data_offer" version="3">+ <description summary="offer to transfer data">+ A wl_data_offer represents a piece of data offered for transfer+ by another client (the source client). It is used by the+ copy-and-paste and drag-and-drop mechanisms. The offer+ describes the different mime types that the data can be+ converted to and provides the mechanism for transferring the+ data directly from the source client.+ </description>++ <enum name="error">+ <entry name="invalid_finish" value="0"+ summary="finish request was called untimely"/>+ <entry name="invalid_action_mask" value="1"+ summary="action mask contains invalid values"/>+ <entry name="invalid_action" value="2"+ summary="action argument has an invalid value"/>+ <entry name="invalid_offer" value="3"+ summary="offer doesn't accept this request"/>+ </enum>++ <request name="accept">+ <description summary="accept one of the offered mime types">+ Indicate that the client can accept the given mime type, or+ NULL for not accepted.++ For objects of version 2 or older, this request is used by the+ client to give feedback whether the client can receive the given+ mime type, or NULL if none is accepted; the feedback does not+ determine whether the drag-and-drop operation succeeds or not.++ For objects of version 3 or newer, this request determines the+ final result of the drag-and-drop operation. If the end result+ is that no mime types were accepted, the drag-and-drop operation+ will be cancelled and the corresponding drag source will receive+ wl_data_source.cancelled. Clients may still use this event in+ conjunction with wl_data_source.action for feedback.+ </description>+ <arg name="serial" type="uint" summary="serial number of the accept request"/>+ <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the client"/>+ </request>++ <request name="receive">+ <description summary="request that the data is transferred">+ To transfer the offered data, the client issues this request+ and indicates the mime type it wants to receive. The transfer+ happens through the passed file descriptor (typically created+ with the pipe system call). The source client writes the data+ in the mime type representation requested and then closes the+ file descriptor.++ The receiving client reads from the read end of the pipe until+ EOF and then closes its end, at which point the transfer is+ complete.++ This request may happen multiple times for different mime types,+ both before and after wl_data_device.drop. Drag-and-drop destination+ clients may preemptively fetch data or examine it more closely to+ determine acceptance.+ </description>+ <arg name="mime_type" type="string" summary="mime type desired by receiver"/>+ <arg name="fd" type="fd" summary="file descriptor for data transfer"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy data offer">+ Destroy the data offer.+ </description>+ </request>++ <event name="offer">+ <description summary="advertise offered mime type">+ Sent immediately after creating the wl_data_offer object. One+ event per offered mime type.+ </description>+ <arg name="mime_type" type="string" summary="offered mime type"/>+ </event>++ <!-- Version 3 additions -->++ <request name="finish" since="3">+ <description summary="the offer will no longer be used">+ Notifies the compositor that the drag destination successfully+ finished the drag-and-drop operation.++ Upon receiving this request, the compositor will emit+ wl_data_source.dnd_finished on the drag source client.++ It is a client error to perform other requests than+ wl_data_offer.destroy after this one. It is also an error to perform+ this request after a NULL mime type has been set in+ wl_data_offer.accept or no action was received through+ wl_data_offer.action.++ If wl_data_offer.finish request is received for a non drag and drop+ operation, the invalid_finish protocol error is raised.+ </description>+ </request>++ <request name="set_actions" since="3">+ <description summary="set the available/preferred drag-and-drop actions">+ Sets the actions that the destination side client supports for+ this operation. This request may trigger the emission of+ wl_data_source.action and wl_data_offer.action events if the compositor+ needs to change the selected action.++ This request can be called multiple times throughout the+ drag-and-drop operation, typically in response to wl_data_device.enter+ or wl_data_device.motion events.++ This request determines the final result of the drag-and-drop+ operation. If the end result is that no action is accepted,+ the drag source will receive wl_data_source.cancelled.++ The dnd_actions argument must contain only values expressed in the+ wl_data_device_manager.dnd_actions enum, and the preferred_action+ argument must only contain one of those values set, otherwise it+ will result in a protocol error.++ While managing an "ask" action, the destination drag-and-drop client+ may perform further wl_data_offer.receive requests, and is expected+ to perform one last wl_data_offer.set_actions request with a preferred+ action other than "ask" (and optionally wl_data_offer.accept) before+ requesting wl_data_offer.finish, in order to convey the action selected+ by the user. If the preferred action is not in the+ wl_data_offer.source_actions mask, an error will be raised.++ If the "ask" action is dismissed (e.g. user cancellation), the client+ is expected to perform wl_data_offer.destroy right away.++ This request can only be made on drag-and-drop offers, a protocol error+ will be raised otherwise.+ </description>+ <arg name="dnd_actions" type="uint" summary="actions supported by the destination client"+ enum="wl_data_device_manager.dnd_action"/>+ <arg name="preferred_action" type="uint" summary="action preferred by the destination client"+ enum="wl_data_device_manager.dnd_action"/>+ </request>++ <event name="source_actions" since="3">+ <description summary="notify the source-side available actions">+ This event indicates the actions offered by the data source. It+ will be sent immediately after creating the wl_data_offer object,+ or anytime the source side changes its offered actions through+ wl_data_source.set_actions.+ </description>+ <arg name="source_actions" type="uint" summary="actions offered by the data source"+ enum="wl_data_device_manager.dnd_action"/>+ </event>++ <event name="action" since="3">+ <description summary="notify the selected action">+ This event indicates the action selected by the compositor after+ matching the source/destination side actions. Only one action (or+ none) will be offered here.++ This event can be emitted multiple times during the drag-and-drop+ operation in response to destination side action changes through+ wl_data_offer.set_actions.++ This event will no longer be emitted after wl_data_device.drop+ happened on the drag-and-drop destination, the client must+ honor the last action received, or the last preferred one set+ through wl_data_offer.set_actions when handling an "ask" action.++ Compositors may also change the selected action on the fly, mainly+ in response to keyboard modifier changes during the drag-and-drop+ operation.++ The most recent action received is always the valid one. Prior to+ receiving wl_data_device.drop, the chosen action may change (e.g.+ due to keyboard modifiers being pressed). At the time of receiving+ wl_data_device.drop the drag-and-drop destination must honor the+ last action received.++ Action changes may still happen after wl_data_device.drop,+ especially on "ask" actions, where the drag-and-drop destination+ may choose another action afterwards. Action changes happening+ at this stage are always the result of inter-client negotiation, the+ compositor shall no longer be able to induce a different action.++ Upon "ask" actions, it is expected that the drag-and-drop destination+ may potentially choose a different action and/or mime type,+ based on wl_data_offer.source_actions and finally chosen by the+ user (e.g. popping up a menu with the available options). The+ final wl_data_offer.set_actions and wl_data_offer.accept requests+ must happen before the call to wl_data_offer.finish.+ </description>+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"+ enum="wl_data_device_manager.dnd_action"/>+ </event>+ </interface>++ <interface name="wl_data_source" version="3">+ <description summary="offer to transfer data">+ The wl_data_source object is the source side of a wl_data_offer.+ It is created by the source client in a data transfer and+ provides a way to describe the offered data and a way to respond+ to requests to transfer the data.+ </description>++ <enum name="error">+ <entry name="invalid_action_mask" value="0"+ summary="action mask contains invalid values"/>+ <entry name="invalid_source" value="1"+ summary="source doesn't accept this request"/>+ </enum>++ <request name="offer">+ <description summary="add an offered mime type">+ This request adds a mime type to the set of mime types+ advertised to targets. Can be called several times to offer+ multiple types.+ </description>+ <arg name="mime_type" type="string" summary="mime type offered by the data source"/>+ </request>++ <request name="destroy" type="destructor">+ <description summary="destroy the data source">+ Destroy the data source.+ </description>+ </request>++ <event name="target">+ <description summary="a target accepts an offered mime type">+ Sent when a target accepts pointer_focus or motion events. If+ a target does not accept any of the offered types, type is NULL.++ Used for feedback during drag-and-drop.+ </description>+ <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the target"/>+ </event>++ <event name="send">+ <description summary="send the data">+ Request for data from the client. Send the data as the+ specified mime type over the passed file descriptor, then+ close it.+ </description>+ <arg name="mime_type" type="string" summary="mime type for the data"/>+ <arg name="fd" type="fd" summary="file descriptor for the data"/>+ </event>++ <event name="cancelled">+ <description summary="selection was cancelled">+ This data source is no longer valid. There are several reasons why+ this could happen:++ - The data source has been replaced by another data source.+ - The drag-and-drop operation was performed, but the drop destination+ did not accept any of the mime types offered through+ wl_data_source.target.+ - The drag-and-drop operation was performed, but the drop destination+ did not select any of the actions present in the mask offered through+ wl_data_source.action.+ - The drag-and-drop operation was performed but didn't happen over a+ surface.+ - The compositor cancelled the drag-and-drop operation (e.g. compositor+ dependent timeouts to avoid stale drag-and-drop transfers).++ The client should clean up and destroy this data source.++ For objects of version 2 or older, wl_data_source.cancelled will+ only be emitted if the data source was replaced by another data+ source.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="set_actions" since="3">+ <description summary="set the available drag-and-drop actions">+ Sets the actions that the source side client supports for this+ operation. This request may trigger wl_data_source.action and+ wl_data_offer.action events if the compositor needs to change the+ selected action.++ The dnd_actions argument must contain only values expressed in the+ wl_data_device_manager.dnd_actions enum, otherwise it will result+ in a protocol error.++ This request must be made once only, and can only be made on sources+ used in drag-and-drop, so it must be performed before+ wl_data_device.start_drag. Attempting to use the source other than+ for drag-and-drop will raise a protocol error.+ </description>+ <arg name="dnd_actions" type="uint" summary="actions supported by the data source"+ enum="wl_data_device_manager.dnd_action"/>+ </request>++ <event name="dnd_drop_performed" since="3">+ <description summary="the drag-and-drop operation physically finished">+ The user performed the drop action. This event does not indicate+ acceptance, wl_data_source.cancelled may still be emitted afterwards+ if the drop destination does not accept any mime type.++ However, this event might however not be received if the compositor+ cancelled the drag-and-drop operation before this event could happen.++ Note that the data_source may still be used in the future and should+ not be destroyed here.+ </description>+ </event>++ <event name="dnd_finished" since="3">+ <description summary="the drag-and-drop operation concluded">+ The drop destination finished interoperating with this data+ source, so the client is now free to destroy this data source and+ free all associated data.++ If the action used to perform the operation was "move", the+ source can now delete the transferred data.+ </description>+ </event>++ <event name="action" since="3">+ <description summary="notify the selected action">+ This event indicates the action selected by the compositor after+ matching the source/destination side actions. Only one action (or+ none) will be offered here.++ This event can be emitted multiple times during the drag-and-drop+ operation, mainly in response to destination side changes through+ wl_data_offer.set_actions, and as the data device enters/leaves+ surfaces.++ It is only possible to receive this event after+ wl_data_source.dnd_drop_performed if the drag-and-drop operation+ ended in an "ask" action, in which case the final wl_data_source.action+ event will happen immediately before wl_data_source.dnd_finished.++ Compositors may also change the selected action on the fly, mainly+ in response to keyboard modifier changes during the drag-and-drop+ operation.++ The most recent action received is always the valid one. The chosen+ action may change alongside negotiation (e.g. an "ask" action can turn+ into a "move" operation), so the effects of the final action must+ always be applied in wl_data_offer.dnd_finished.++ Clients can trigger cursor surface changes from this point, so+ they reflect the current action.+ </description>+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"+ enum="wl_data_device_manager.dnd_action"/>+ </event>+ </interface>++ <interface name="wl_data_device" version="3">+ <description summary="data transfer device">+ There is one wl_data_device per seat which can be obtained+ from the global wl_data_device_manager singleton.++ A wl_data_device provides access to inter-client data transfer+ mechanisms such as copy-and-paste and drag-and-drop.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="start_drag">+ <description summary="start drag-and-drop operation">+ This request asks the compositor to start a drag-and-drop+ operation on behalf of the client.++ The source argument is the data source that provides the data+ for the eventual data transfer. If source is NULL, enter, leave+ and motion events are sent only to the client that initiated the+ drag and the client is expected to handle the data passing+ internally. If source is destroyed, the drag-and-drop session will be+ cancelled.++ The origin surface is the surface where the drag originates and+ the client must have an active implicit grab that matches the+ serial.++ The icon surface is an optional (can be NULL) surface that+ provides an icon to be moved around with the cursor. Initially,+ the top-left corner of the icon surface is placed at the cursor+ hotspot, but subsequent wl_surface.attach request can move the+ relative position. Attach requests must be confirmed with+ wl_surface.commit as usual. The icon surface is given the role of+ a drag-and-drop icon. If the icon surface already has another role,+ it raises a protocol error.++ The input region is ignored for wl_surfaces with the role of a+ drag-and-drop icon.+ </description>+ <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the eventual transfer"/>+ <arg name="origin" type="object" interface="wl_surface" summary="surface where the drag originates"/>+ <arg name="icon" type="object" interface="wl_surface" allow-null="true" summary="drag-and-drop icon surface"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the origin"/>+ </request>++ <request name="set_selection">+ <description summary="copy data to the selection">+ This request asks the compositor to set the selection+ to the data from the source on behalf of the client.++ To unset the selection, set the source to NULL.+ </description>+ <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the selection"/>+ <arg name="serial" type="uint" summary="serial number of the event that triggered this request"/>+ </request>++ <event name="data_offer">+ <description summary="introduce a new wl_data_offer">+ The data_offer event introduces a new wl_data_offer object,+ which will subsequently be used in either the+ data_device.enter event (for drag-and-drop) or the+ data_device.selection event (for selections). Immediately+ following the data_device.data_offer event, the new data_offer+ object will send out data_offer.offer events to describe the+ mime types it offers.+ </description>+ <arg name="id" type="new_id" interface="wl_data_offer" summary="the new data_offer object"/>+ </event>++ <event name="enter">+ <description summary="initiate drag-and-drop session">+ This event is sent when an active drag-and-drop pointer enters+ a surface owned by the client. The position of the pointer at+ enter time is provided by the x and y arguments, in surface-local+ coordinates.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="client surface entered"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"+ summary="source data_offer object"/>+ </event>++ <event name="leave">+ <description summary="end drag-and-drop session">+ This event is sent when the drag-and-drop pointer leaves the+ surface and the session ends. The client must destroy the+ wl_data_offer introduced at enter time at this point.+ </description>+ </event>++ <event name="motion">+ <description summary="drag-and-drop session motion">+ This event is sent when the drag-and-drop pointer moves within+ the currently focused surface. The new position of the pointer+ is provided by the x and y arguments, in surface-local+ coordinates.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="drop">+ <description summary="end drag-and-drop session successfully">+ The event is sent when a drag-and-drop operation is ended+ because the implicit grab is removed.++ The drag-and-drop destination is expected to honor the last action+ received through wl_data_offer.action, if the resulting action is+ "copy" or "move", the destination can still perform+ wl_data_offer.receive requests, and is expected to end all+ transfers with a wl_data_offer.finish request.++ If the resulting action is "ask", the action will not be considered+ final. The drag-and-drop destination is expected to perform one last+ wl_data_offer.set_actions request, or wl_data_offer.destroy in order+ to cancel the operation.+ </description>+ </event>++ <event name="selection">+ <description summary="advertise new selection">+ The selection event is sent out to notify the client of a new+ wl_data_offer for the selection for this device. The+ data_device.data_offer and the data_offer.offer events are+ sent out immediately before this event to introduce the data+ offer object. The selection event is sent to a client+ immediately before receiving keyboard focus and when a new+ selection is set while the client has keyboard focus. The+ data_offer is valid until a new data_offer or NULL is received+ or until the client loses keyboard focus. Switching surface with+ keyboard focus within the same client doesn't mean a new selection+ will be sent. The client must destroy the previous selection+ data_offer, if any, upon receiving this event.+ </description>+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"+ summary="selection data_offer object"/>+ </event>++ <!-- Version 2 additions -->++ <request name="release" type="destructor" since="2">+ <description summary="destroy data device">+ This request destroys the data device.+ </description>+ </request>+ </interface>++ <interface name="wl_data_device_manager" version="3">+ <description summary="data transfer interface">+ The wl_data_device_manager is a singleton global object that+ provides access to inter-client data transfer mechanisms such as+ copy-and-paste and drag-and-drop. These mechanisms are tied to+ a wl_seat and this interface lets a client get a wl_data_device+ corresponding to a wl_seat.++ Depending on the version bound, the objects created from the bound+ wl_data_device_manager object will have different requirements for+ functioning properly. See wl_data_source.set_actions,+ wl_data_offer.accept and wl_data_offer.finish for details.+ </description>++ <request name="create_data_source">+ <description summary="create a new data source">+ Create a new data source.+ </description>+ <arg name="id" type="new_id" interface="wl_data_source" summary="data source to create"/>+ </request>++ <request name="get_data_device">+ <description summary="create a new data device">+ Create a new data device for a given seat.+ </description>+ <arg name="id" type="new_id" interface="wl_data_device" summary="data device to create"/>+ <arg name="seat" type="object" interface="wl_seat" summary="seat associated with the data device"/>+ </request>++ <!-- Version 3 additions -->++ <enum name="dnd_action" bitfield="true" since="3">+ <description summary="drag and drop actions">+ This is a bitmask of the available/preferred actions in a+ drag-and-drop operation.++ In the compositor, the selected action is a result of matching the+ actions offered by the source and destination sides. "action" events+ with a "none" action will be sent to both source and destination if+ there is no match. All further checks will effectively happen on+ (source actions ∩ destination actions).++ In addition, compositors may also pick different actions in+ reaction to key modifiers being pressed. One common design that+ is used in major toolkits (and the behavior recommended for+ compositors) is:++ - If no modifiers are pressed, the first match (in bit order)+ will be used.+ - Pressing Shift selects "move", if enabled in the mask.+ - Pressing Control selects "copy", if enabled in the mask.++ Behavior beyond that is considered implementation-dependent.+ Compositors may for example bind other modifiers (like Alt/Meta)+ or drags initiated with other buttons than BTN_LEFT to specific+ actions (e.g. "ask").+ </description>+ <entry name="none" value="0" summary="no action"/>+ <entry name="copy" value="1" summary="copy action"/>+ <entry name="move" value="2" summary="move action"/>+ <entry name="ask" value="4" summary="ask action"/>+ </enum>+ </interface>++ <interface name="wl_shell" version="1">+ <description summary="create desktop-style surfaces">+ This interface is implemented by servers that provide+ desktop-style user interfaces.++ It allows clients to associate a wl_shell_surface with+ a basic surface.++ Note! This protocol is deprecated and not intended for production use.+ For desktop-style user interfaces, use xdg_shell. Compositors and clients+ should not implement this interface.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="get_shell_surface">+ <description summary="create a shell surface from a surface">+ Create a shell surface for an existing surface. This gives+ the wl_surface the role of a shell surface. If the wl_surface+ already has another role, it raises a protocol error.++ Only one shell surface can be associated with a given surface.+ </description>+ <arg name="id" type="new_id" interface="wl_shell_surface" summary="shell surface to create"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface to be given the shell surface role"/>+ </request>+ </interface>++ <interface name="wl_shell_surface" version="1">+ <description summary="desktop-style metadata interface">+ An interface that may be implemented by a wl_surface, for+ implementations that provide a desktop-style user interface.++ It provides requests to treat surfaces like toplevel, fullscreen+ or popup windows, move, resize or maximize them, associate+ metadata like title and class, etc.++ On the server side the object is automatically destroyed when+ the related wl_surface is destroyed. On the client side,+ wl_shell_surface_destroy() must be called before destroying+ the wl_surface object.+ </description>++ <request name="pong">+ <description summary="respond to a ping event">+ A client must respond to a ping event with a pong request or+ the client may be deemed unresponsive.+ </description>+ <arg name="serial" type="uint" summary="serial number of the ping event"/>+ </request>++ <request name="move">+ <description summary="start an interactive move">+ Start a pointer-driven move of the surface.++ This request must be used in response to a button press event.+ The server may ignore move requests depending on the state of+ the surface (e.g. fullscreen or maximized).+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ </request>++ <enum name="resize" bitfield="true">+ <description summary="edge values for resizing">+ These values are used to indicate which edge of a surface+ is being dragged in a resize operation. The server may+ use this information to adapt its behavior, e.g. choose+ an appropriate cursor image.+ </description>+ <entry name="none" value="0" summary="no edge"/>+ <entry name="top" value="1" summary="top edge"/>+ <entry name="bottom" value="2" summary="bottom edge"/>+ <entry name="left" value="4" summary="left edge"/>+ <entry name="top_left" value="5" summary="top and left edges"/>+ <entry name="bottom_left" value="6" summary="bottom and left edges"/>+ <entry name="right" value="8" summary="right edge"/>+ <entry name="top_right" value="9" summary="top and right edges"/>+ <entry name="bottom_right" value="10" summary="bottom and right edges"/>+ </enum>++ <request name="resize">+ <description summary="start an interactive resize">+ Start a pointer-driven resizing of the surface.++ This request must be used in response to a button press event.+ The server may ignore resize requests depending on the state of+ the surface (e.g. fullscreen or maximized).+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ <arg name="edges" type="uint" enum="resize" summary="which edge or corner is being dragged"/>+ </request>++ <request name="set_toplevel">+ <description summary="make the surface a toplevel surface">+ Map the surface as a toplevel surface.++ A toplevel surface is not fullscreen, maximized or transient.+ </description>+ </request>++ <enum name="transient" bitfield="true">+ <description summary="details of transient behaviour">+ These flags specify details of the expected behaviour+ of transient surfaces. Used in the set_transient request.+ </description>+ <entry name="inactive" value="0x1" summary="do not set keyboard focus"/>+ </enum>++ <request name="set_transient">+ <description summary="make the surface a transient surface">+ Map the surface relative to an existing surface.++ The x and y arguments specify the location of the upper left+ corner of the surface relative to the upper left corner of the+ parent surface, in surface-local coordinates.++ The flags argument controls details of the transient behaviour.+ </description>+ <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>+ </request>++ <enum name="fullscreen_method">+ <description summary="different method to set the surface fullscreen">+ Hints to indicate to the compositor how to deal with a conflict+ between the dimensions of the surface and the dimensions of the+ output. The compositor is free to ignore this parameter.+ </description>+ <entry name="default" value="0" summary="no preference, apply default policy"/>+ <entry name="scale" value="1" summary="scale, preserve the surface's aspect ratio and center on output"/>+ <entry name="driver" value="2" summary="switch output mode to the smallest mode that can fit the surface, add black borders to compensate size mismatch"/>+ <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>+ </enum>++ <request name="set_fullscreen">+ <description summary="make the surface a fullscreen surface">+ Map the surface as a fullscreen surface.++ If an output parameter is given then the surface will be made+ fullscreen on that output. If the client does not specify the+ output then the compositor will apply its policy - usually+ choosing the output on which the surface has the biggest surface+ area.++ The client may specify a method to resolve a size conflict+ between the output size and the surface size - this is provided+ through the method parameter.++ The framerate parameter is used only when the method is set+ to "driver", to indicate the preferred framerate. A value of 0+ indicates that the client does not care about framerate. The+ framerate is specified in mHz, that is framerate of 60000 is 60Hz.++ A method of "scale" or "driver" implies a scaling operation of+ the surface, either via a direct scaling operation or a change of+ the output mode. This will override any kind of output scaling, so+ that mapping a surface with a buffer size equal to the mode can+ fill the screen independent of buffer_scale.++ A method of "fill" means we don't scale up the buffer, however+ any output scale is applied. This means that you may run into+ an edge case where the application maps a buffer with the same+ size of the output mode but buffer_scale 1 (thus making a+ surface larger than the output). In this case it is allowed to+ downscale the results to fit the screen.++ The compositor must reply to this request with a configure event+ with the dimensions for the output on which the surface will+ be made fullscreen.+ </description>+ <arg name="method" type="uint" enum="fullscreen_method" summary="method for resolving size conflict"/>+ <arg name="framerate" type="uint" summary="framerate in mHz"/>+ <arg name="output" type="object" interface="wl_output" allow-null="true"+ summary="output on which the surface is to be fullscreen"/>+ </request>++ <request name="set_popup">+ <description summary="make the surface a popup surface">+ Map the surface as a popup.++ A popup surface is a transient surface with an added pointer+ grab.++ An existing implicit grab will be changed to owner-events mode,+ and the popup grab will continue after the implicit grab ends+ (i.e. releasing the mouse button does not cause the popup to+ be unmapped).++ The popup grab continues until the window is destroyed or a+ mouse button is pressed in any other client's window. A click+ in any of the client's surfaces is reported as normal, however,+ clicks in other clients' surfaces will be discarded and trigger+ the callback.++ The x and y arguments specify the location of the upper left+ corner of the surface relative to the upper left corner of the+ parent surface, in surface-local coordinates.+ </description>+ <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>+ <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>+ <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>+ </request>++ <request name="set_maximized">+ <description summary="make the surface a maximized surface">+ Map the surface as a maximized surface.++ If an output parameter is given then the surface will be+ maximized on that output. If the client does not specify the+ output then the compositor will apply its policy - usually+ choosing the output on which the surface has the biggest surface+ area.++ The compositor will reply with a configure event telling+ the expected new surface size. The operation is completed+ on the next buffer attach to this surface.++ A maximized surface typically fills the entire output it is+ bound to, except for desktop elements such as panels. This is+ the main difference between a maximized shell surface and a+ fullscreen shell surface.++ The details depend on the compositor implementation.+ </description>+ <arg name="output" type="object" interface="wl_output" allow-null="true"+ summary="output on which the surface is to be maximized"/>+ </request>++ <request name="set_title">+ <description summary="set surface title">+ Set a short title for the surface.++ This string may be used to identify the surface in a task bar,+ window list, or other user interface elements provided by the+ compositor.++ The string must be encoded in UTF-8.+ </description>+ <arg name="title" type="string" summary="surface title"/>+ </request>++ <request name="set_class">+ <description summary="set surface class">+ Set a class for the surface.++ The surface class identifies the general class of applications+ to which the surface belongs. A common convention is to use the+ file name (or the full path if it is a non-standard location) of+ the application's .desktop file as the class.+ </description>+ <arg name="class_" type="string" summary="surface class"/>+ </request>++ <event name="ping">+ <description summary="ping client">+ Ping a client to check if it is receiving events and sending+ requests. A client is expected to reply with a pong request.+ </description>+ <arg name="serial" type="uint" summary="serial number of the ping"/>+ </event>++ <event name="configure">+ <description summary="suggest resize">+ The configure event asks the client to resize its surface.++ The size is a hint, in the sense that the client is free to+ ignore it if it doesn't resize, pick a smaller size (to+ satisfy aspect ratio or resize in steps of NxM pixels).++ The edges parameter provides a hint about how the surface+ was resized. The client may use this information to decide+ how to adjust its content to the new size (e.g. a scrolling+ area might adjust its content position to leave the viewable+ content unmoved).++ The client is free to dismiss all but the last configure+ event it received.++ The width and height arguments specify the size of the window+ in surface-local coordinates.+ </description>+ <arg name="edges" type="uint" enum="resize" summary="how the surface was resized"/>+ <arg name="width" type="int" summary="new width of the surface"/>+ <arg name="height" type="int" summary="new height of the surface"/>+ </event>++ <event name="popup_done">+ <description summary="popup interaction is done">+ The popup_done event is sent out when a popup grab is broken,+ that is, when the user clicks a surface that doesn't belong+ to the client owning the popup surface.+ </description>+ </event>+ </interface>++ <interface name="wl_surface" version="6">+ <description summary="an onscreen surface">+ A surface is a rectangular area that may be displayed on zero+ or more outputs, and shown any number of times at the compositor's+ discretion. They can present wl_buffers, receive user input, and+ define a local coordinate system.++ The size of a surface (and relative positions on it) is described+ in surface-local coordinates, which may differ from the buffer+ coordinates of the pixel content, in case a buffer_transform+ or a buffer_scale is used.++ A surface without a "role" is fairly useless: a compositor does+ not know where, when or how to present it. The role is the+ purpose of a wl_surface. Examples of roles are a cursor for a+ pointer (as set by wl_pointer.set_cursor), a drag icon+ (wl_data_device.start_drag), a sub-surface+ (wl_subcompositor.get_subsurface), and a window as defined by a+ shell protocol (e.g. wl_shell.get_shell_surface).++ A surface can have only one role at a time. Initially a+ wl_surface does not have a role. Once a wl_surface is given a+ role, it is set permanently for the whole lifetime of the+ wl_surface object. Giving the current role again is allowed,+ unless explicitly forbidden by the relevant interface+ specification.++ Surface roles are given by requests in other interfaces such as+ wl_pointer.set_cursor. The request should explicitly mention+ that this request gives a role to a wl_surface. Often, this+ request also creates a new protocol object that represents the+ role and adds additional functionality to wl_surface. When a+ client wants to destroy a wl_surface, they must destroy this role+ object before the wl_surface, otherwise a defunct_role_object error is+ sent.++ Destroying the role object does not remove the role from the+ wl_surface, but it may stop the wl_surface from "playing the role".+ For instance, if a wl_subsurface object is destroyed, the wl_surface+ it was created for will be unmapped and forget its position and+ z-order. It is allowed to create a wl_subsurface for the same+ wl_surface again, but it is not allowed to use the wl_surface as+ a cursor (cursor is a different role than sub-surface, and role+ switching is not allowed).+ </description>++ <enum name="error">+ <description summary="wl_surface error values">+ These errors can be emitted in response to wl_surface requests.+ </description>+ <entry name="invalid_scale" value="0" summary="buffer scale value is invalid"/>+ <entry name="invalid_transform" value="1" summary="buffer transform value is invalid"/>+ <entry name="invalid_size" value="2" summary="buffer size is invalid"/>+ <entry name="invalid_offset" value="3" summary="buffer offset is invalid"/>+ <entry name="defunct_role_object" value="4"+ summary="surface was destroyed before its role object"/>+ </enum>++ <request name="destroy" type="destructor">+ <description summary="delete surface">+ Deletes the surface and invalidates its object ID.+ </description>+ </request>++ <request name="attach">+ <description summary="set the surface contents">+ Set a buffer as the content of this surface.++ The new size of the surface is calculated based on the buffer+ size transformed by the inverse buffer_transform and the+ inverse buffer_scale. This means that at commit time the supplied+ buffer size must be an integer multiple of the buffer_scale. If+ that's not the case, an invalid_size error is sent.++ The x and y arguments specify the location of the new pending+ buffer's upper left corner, relative to the current buffer's upper+ left corner, in surface-local coordinates. In other words, the+ x and y, combined with the new surface size define in which+ directions the surface's size changes. Setting anything other than 0+ as x and y arguments is discouraged, and should instead be replaced+ with using the separate wl_surface.offset request.++ When the bound wl_surface version is 5 or higher, passing any+ non-zero x or y is a protocol violation, and will result in an+ 'invalid_offset' error being raised. The x and y arguments are ignored+ and do not change the pending state. To achieve equivalent semantics,+ use wl_surface.offset.++ Surface contents are double-buffered state, see wl_surface.commit.++ The initial surface contents are void; there is no content.+ wl_surface.attach assigns the given wl_buffer as the pending+ wl_buffer. wl_surface.commit makes the pending wl_buffer the new+ surface contents, and the size of the surface becomes the size+ calculated from the wl_buffer, as described above. After commit,+ there is no pending buffer until the next attach.++ Committing a pending wl_buffer allows the compositor to read the+ pixels in the wl_buffer. The compositor may access the pixels at+ any time after the wl_surface.commit request. When the compositor+ will not access the pixels anymore, it will send the+ wl_buffer.release event. Only after receiving wl_buffer.release,+ the client may reuse the wl_buffer. A wl_buffer that has been+ attached and then replaced by another attach instead of committed+ will not receive a release event, and is not used by the+ compositor.++ If a pending wl_buffer has been committed to more than one wl_surface,+ the delivery of wl_buffer.release events becomes undefined. A well+ behaved client should not rely on wl_buffer.release events in this+ case. Alternatively, a client could create multiple wl_buffer objects+ from the same backing storage or use wp_linux_buffer_release.++ Destroying the wl_buffer after wl_buffer.release does not change+ the surface contents. Destroying the wl_buffer before wl_buffer.release+ is allowed as long as the underlying buffer storage isn't re-used (this+ can happen e.g. on client process termination). However, if the client+ destroys the wl_buffer before receiving the wl_buffer.release event and+ mutates the underlying buffer storage, the surface contents become+ undefined immediately.++ If wl_surface.attach is sent with a NULL wl_buffer, the+ following wl_surface.commit will remove the surface content.+ </description>+ <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"+ summary="buffer of surface contents"/>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ </request>++ <request name="damage">+ <description summary="mark part of the surface damaged">+ This request is used to describe the regions where the pending+ buffer is different from the current surface contents, and where+ the surface therefore needs to be repainted. The compositor+ ignores the parts of the damage that fall outside of the surface.++ Damage is double-buffered state, see wl_surface.commit.++ The damage rectangle is specified in surface-local coordinates,+ where x and y specify the upper left corner of the damage rectangle.++ The initial value for pending damage is empty: no damage.+ wl_surface.damage adds pending damage: the new pending damage+ is the union of old pending damage and the given rectangle.++ wl_surface.commit assigns pending damage as the current damage,+ and clears pending damage. The server will clear the current+ damage as it repaints the surface.++ Note! New clients should not use this request. Instead damage can be+ posted with wl_surface.damage_buffer which uses buffer coordinates+ instead of surface coordinates.+ </description>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ <arg name="width" type="int" summary="width of damage rectangle"/>+ <arg name="height" type="int" summary="height of damage rectangle"/>+ </request>++ <request name="frame">+ <description summary="request a frame throttling hint">+ Request a notification when it is a good time to start drawing a new+ frame, by creating a frame callback. This is useful for throttling+ redrawing operations, and driving animations.++ When a client is animating on a wl_surface, it can use the 'frame'+ request to get notified when it is a good time to draw and commit the+ next frame of animation. If the client commits an update earlier than+ that, it is likely that some updates will not make it to the display,+ and the client is wasting resources by drawing too often.++ The frame request will take effect on the next wl_surface.commit.+ The notification will only be posted for one frame unless+ requested again. For a wl_surface, the notifications are posted in+ the order the frame requests were committed.++ The server must send the notifications so that a client+ will not send excessive updates, while still allowing+ the highest possible update rate for clients that wait for the reply+ before drawing again. The server should give some time for the client+ to draw and commit after sending the frame callback events to let it+ hit the next output refresh.++ A server should avoid signaling the frame callbacks if the+ surface is not visible in any way, e.g. the surface is off-screen,+ or completely obscured by other opaque surfaces.++ The object returned by this request will be destroyed by the+ compositor after the callback is fired and as such the client must not+ attempt to use it after that point.++ The callback_data passed in the callback is the current time, in+ milliseconds, with an undefined base.+ </description>+ <arg name="callback" type="new_id" interface="wl_callback" summary="callback object for the frame request"/>+ </request>++ <request name="set_opaque_region">+ <description summary="set opaque region">+ This request sets the region of the surface that contains+ opaque content.++ The opaque region is an optimization hint for the compositor+ that lets it optimize the redrawing of content behind opaque+ regions. Setting an opaque region is not required for correct+ behaviour, but marking transparent content as opaque will result+ in repaint artifacts.++ The opaque region is specified in surface-local coordinates.++ The compositor ignores the parts of the opaque region that fall+ outside of the surface.++ Opaque region is double-buffered state, see wl_surface.commit.++ wl_surface.set_opaque_region changes the pending opaque region.+ wl_surface.commit copies the pending region to the current region.+ Otherwise, the pending and current regions are never changed.++ The initial value for an opaque region is empty. Setting the pending+ opaque region has copy semantics, and the wl_region object can be+ destroyed immediately. A NULL wl_region causes the pending opaque+ region to be set to empty.+ </description>+ <arg name="region" type="object" interface="wl_region" allow-null="true"+ summary="opaque region of the surface"/>+ </request>++ <request name="set_input_region">+ <description summary="set input region">+ This request sets the region of the surface that can receive+ pointer and touch events.++ Input events happening outside of this region will try the next+ surface in the server surface stack. The compositor ignores the+ parts of the input region that fall outside of the surface.++ The input region is specified in surface-local coordinates.++ Input region is double-buffered state, see wl_surface.commit.++ wl_surface.set_input_region changes the pending input region.+ wl_surface.commit copies the pending region to the current region.+ Otherwise the pending and current regions are never changed,+ except cursor and icon surfaces are special cases, see+ wl_pointer.set_cursor and wl_data_device.start_drag.++ The initial value for an input region is infinite. That means the+ whole surface will accept input. Setting the pending input region+ has copy semantics, and the wl_region object can be destroyed+ immediately. A NULL wl_region causes the input region to be set+ to infinite.+ </description>+ <arg name="region" type="object" interface="wl_region" allow-null="true"+ summary="input region of the surface"/>+ </request>++ <request name="commit">+ <description summary="commit pending surface state">+ Surface state (input, opaque, and damage regions, attached buffers,+ etc.) is double-buffered. Protocol requests modify the pending state,+ as opposed to the current state in use by the compositor. A commit+ request atomically applies all pending state, replacing the current+ state. After commit, the new pending state is as documented for each+ related request.++ On commit, a pending wl_buffer is applied first, and all other state+ second. This means that all coordinates in double-buffered state are+ relative to the new wl_buffer coming into use, except for+ wl_surface.attach itself. If there is no pending wl_buffer, the+ coordinates are relative to the current surface contents.++ All requests that need a commit to become effective are documented+ to affect double-buffered state.++ Other interfaces may add further double-buffered surface state.+ </description>+ </request>++ <event name="enter">+ <description summary="surface enters an output">+ This is emitted whenever a surface's creation, movement, or resizing+ results in some part of it being within the scanout region of an+ output.++ Note that a surface may be overlapping with zero or more outputs.+ </description>+ <arg name="output" type="object" interface="wl_output" summary="output entered by the surface"/>+ </event>++ <event name="leave">+ <description summary="surface leaves an output">+ This is emitted whenever a surface's creation, movement, or resizing+ results in it no longer having any part of it within the scanout region+ of an output.++ Clients should not use the number of outputs the surface is on for frame+ throttling purposes. The surface might be hidden even if no leave event+ has been sent, and the compositor might expect new surface content+ updates even if no enter event has been sent. The frame event should be+ used instead.+ </description>+ <arg name="output" type="object" interface="wl_output" summary="output left by the surface"/>+ </event>++ <!-- Version 2 additions -->++ <request name="set_buffer_transform" since="2">+ <description summary="sets the buffer transformation">+ This request sets an optional transformation on how the compositor+ interprets the contents of the buffer attached to the surface. The+ accepted values for the transform parameter are the values for+ wl_output.transform.++ Buffer transform is double-buffered state, see wl_surface.commit.++ A newly created surface has its buffer transformation set to normal.++ wl_surface.set_buffer_transform changes the pending buffer+ transformation. wl_surface.commit copies the pending buffer+ transformation to the current one. Otherwise, the pending and current+ values are never changed.++ The purpose of this request is to allow clients to render content+ according to the output transform, thus permitting the compositor to+ use certain optimizations even if the display is rotated. Using+ hardware overlays and scanning out a client buffer for fullscreen+ surfaces are examples of such optimizations. Those optimizations are+ highly dependent on the compositor implementation, so the use of this+ request should be considered on a case-by-case basis.++ Note that if the transform value includes 90 or 270 degree rotation,+ the width of the buffer will become the surface height and the height+ of the buffer will become the surface width.++ If transform is not one of the values from the+ wl_output.transform enum the invalid_transform protocol error+ is raised.+ </description>+ <arg name="transform" type="int" enum="wl_output.transform"+ summary="transform for interpreting buffer contents"/>+ </request>++ <!-- Version 3 additions -->++ <request name="set_buffer_scale" since="3">+ <description summary="sets the buffer scaling factor">+ This request sets an optional scaling factor on how the compositor+ interprets the contents of the buffer attached to the window.++ Buffer scale is double-buffered state, see wl_surface.commit.++ A newly created surface has its buffer scale set to 1.++ wl_surface.set_buffer_scale changes the pending buffer scale.+ wl_surface.commit copies the pending buffer scale to the current one.+ Otherwise, the pending and current values are never changed.++ The purpose of this request is to allow clients to supply higher+ resolution buffer data for use on high resolution outputs. It is+ intended that you pick the same buffer scale as the scale of the+ output that the surface is displayed on. This means the compositor+ can avoid scaling when rendering the surface on that output.++ Note that if the scale is larger than 1, then you have to attach+ a buffer that is larger (by a factor of scale in each dimension)+ than the desired surface size.++ If scale is not positive the invalid_scale protocol error is+ raised.+ </description>+ <arg name="scale" type="int"+ summary="positive scale for interpreting buffer contents"/>+ </request>++ <!-- Version 4 additions -->+ <request name="damage_buffer" since="4">+ <description summary="mark part of the surface damaged using buffer coordinates">+ This request is used to describe the regions where the pending+ buffer is different from the current surface contents, and where+ the surface therefore needs to be repainted. The compositor+ ignores the parts of the damage that fall outside of the surface.++ Damage is double-buffered state, see wl_surface.commit.++ The damage rectangle is specified in buffer coordinates,+ where x and y specify the upper left corner of the damage rectangle.++ The initial value for pending damage is empty: no damage.+ wl_surface.damage_buffer adds pending damage: the new pending+ damage is the union of old pending damage and the given rectangle.++ wl_surface.commit assigns pending damage as the current damage,+ and clears pending damage. The server will clear the current+ damage as it repaints the surface.++ This request differs from wl_surface.damage in only one way - it+ takes damage in buffer coordinates instead of surface-local+ coordinates. While this generally is more intuitive than surface+ coordinates, it is especially desirable when using wp_viewport+ or when a drawing library (like EGL) is unaware of buffer scale+ and buffer transform.++ Note: Because buffer transformation changes and damage requests may+ be interleaved in the protocol stream, it is impossible to determine+ the actual mapping between surface and buffer damage until+ wl_surface.commit time. Therefore, compositors wishing to take both+ kinds of damage into account will have to accumulate damage from the+ two requests separately and only transform from one to the other+ after receiving the wl_surface.commit.+ </description>+ <arg name="x" type="int" summary="buffer-local x coordinate"/>+ <arg name="y" type="int" summary="buffer-local y coordinate"/>+ <arg name="width" type="int" summary="width of damage rectangle"/>+ <arg name="height" type="int" summary="height of damage rectangle"/>+ </request>++ <!-- Version 5 additions -->++ <request name="offset" since="5">+ <description summary="set the surface contents offset">+ The x and y arguments specify the location of the new pending+ buffer's upper left corner, relative to the current buffer's upper+ left corner, in surface-local coordinates. In other words, the+ x and y, combined with the new surface size define in which+ directions the surface's size changes.++ Surface location offset is double-buffered state, see+ wl_surface.commit.++ This request is semantically equivalent to and the replaces the x and y+ arguments in the wl_surface.attach request in wl_surface versions prior+ to 5. See wl_surface.attach for details.+ </description>+ <arg name="x" type="int" summary="surface-local x coordinate"/>+ <arg name="y" type="int" summary="surface-local y coordinate"/>+ </request>++ <!-- Version 6 additions -->++ <event name="preferred_buffer_scale" since="6">+ <description summary="preferred buffer scale for the surface">+ This event indicates the preferred buffer scale for this surface. It is+ sent whenever the compositor's preference changes.++ It is intended that scaling aware clients use this event to scale their+ content and use wl_surface.set_buffer_scale to indicate the scale they+ have rendered with. This allows clients to supply a higher detail+ buffer.+ </description>+ <arg name="factor" type="int" summary="preferred scaling factor"/>+ </event>++ <event name="preferred_buffer_transform" since="6">+ <description summary="preferred buffer transform for the surface">+ This event indicates the preferred buffer transform for this surface.+ It is sent whenever the compositor's preference changes.++ It is intended that transform aware clients use this event to apply the+ transform to their content and use wl_surface.set_buffer_transform to+ indicate the transform they have rendered with.+ </description>+ <arg name="transform" type="uint" enum="wl_output.transform"+ summary="preferred transform"/>+ </event>+ </interface>++ <interface name="wl_seat" version="9">+ <description summary="group of input devices">+ A seat is a group of keyboards, pointer and touch devices. This+ object is published as a global during start up, or when such a+ device is hot plugged. A seat typically has a pointer and+ maintains a keyboard focus and a pointer focus.+ </description>++ <enum name="capability" bitfield="true">+ <description summary="seat capability bitmask">+ This is a bitmask of capabilities this seat has; if a member is+ set, then it is present on the seat.+ </description>+ <entry name="pointer" value="1" summary="the seat has pointer devices"/>+ <entry name="keyboard" value="2" summary="the seat has one or more keyboards"/>+ <entry name="touch" value="4" summary="the seat has touch devices"/>+ </enum>++ <enum name="error">+ <description summary="wl_seat error values">+ These errors can be emitted in response to wl_seat requests.+ </description>+ <entry name="missing_capability" value="0"+ summary="get_pointer, get_keyboard or get_touch called on seat without the matching capability"/>+ </enum>++ <event name="capabilities">+ <description summary="seat capabilities changed">+ This is emitted whenever a seat gains or loses the pointer,+ keyboard or touch capabilities. The argument is a capability+ enum containing the complete set of capabilities this seat has.++ When the pointer capability is added, a client may create a+ wl_pointer object using the wl_seat.get_pointer request. This object+ will receive pointer events until the capability is removed in the+ future.++ When the pointer capability is removed, a client should destroy the+ wl_pointer objects associated with the seat where the capability was+ removed, using the wl_pointer.release request. No further pointer+ events will be received on these objects.++ In some compositors, if a seat regains the pointer capability and a+ client has a previously obtained wl_pointer object of version 4 or+ less, that object may start sending pointer events again. This+ behavior is considered a misinterpretation of the intended behavior+ and must not be relied upon by the client. wl_pointer objects of+ version 5 or later must not send events if created before the most+ recent event notifying the client of an added pointer capability.++ The above behavior also applies to wl_keyboard and wl_touch with the+ keyboard and touch capabilities, respectively.+ </description>+ <arg name="capabilities" type="uint" enum="capability" summary="capabilities of the seat"/>+ </event>++ <request name="get_pointer">+ <description summary="return pointer object">+ The ID provided will be initialized to the wl_pointer interface+ for this seat.++ This request only takes effect if the seat has the pointer+ capability, or has had the pointer capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the pointer capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_pointer" summary="seat pointer"/>+ </request>++ <request name="get_keyboard">+ <description summary="return keyboard object">+ The ID provided will be initialized to the wl_keyboard interface+ for this seat.++ This request only takes effect if the seat has the keyboard+ capability, or has had the keyboard capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the keyboard capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_keyboard" summary="seat keyboard"/>+ </request>++ <request name="get_touch">+ <description summary="return touch object">+ The ID provided will be initialized to the wl_touch interface+ for this seat.++ This request only takes effect if the seat has the touch+ capability, or has had the touch capability in the past.+ It is a protocol violation to issue this request on a seat that has+ never had the touch capability. The missing_capability error will+ be sent in this case.+ </description>+ <arg name="id" type="new_id" interface="wl_touch" summary="seat touch interface"/>+ </request>++ <!-- Version 2 additions -->++ <event name="name" since="2">+ <description summary="unique identifier for this seat">+ In a multi-seat configuration the seat name can be used by clients to+ help identify which physical devices the seat represents.++ The seat name is a UTF-8 string with no convention defined for its+ contents. Each name is unique among all wl_seat globals. The name is+ only guaranteed to be unique for the current compositor instance.++ The same seat names are used for all clients. Thus, the name can be+ shared across processes to refer to a specific wl_seat global.++ The name event is sent after binding to the seat global. This event is+ only sent once per seat object, and the name does not change over the+ lifetime of the wl_seat global.++ Compositors may re-use the same seat name if the wl_seat global is+ destroyed and re-created later.+ </description>+ <arg name="name" type="string" summary="seat identifier"/>+ </event>++ <!-- Version 5 additions -->++ <request name="release" type="destructor" since="5">+ <description summary="release the seat object">+ Using this request a client can tell the server that it is not going to+ use the seat object anymore.+ </description>+ </request>++ </interface>++ <interface name="wl_pointer" version="9">+ <description summary="pointer input device">+ The wl_pointer interface represents one or more input devices,+ such as mice, which control the pointer location and pointer_focus+ of a seat.++ The wl_pointer interface generates motion, enter and leave+ events for the surfaces that the pointer is located over,+ and button and axis events for button presses, button releases+ and scrolling.+ </description>++ <enum name="error">+ <entry name="role" value="0" summary="given wl_surface has another role"/>+ </enum>++ <request name="set_cursor">+ <description summary="set the pointer surface">+ Set the pointer surface, i.e., the surface that contains the+ pointer image (cursor). This request gives the surface the role+ of a cursor. If the surface already has another role, it raises+ a protocol error.++ The cursor actually changes only if the pointer+ focus for this device is one of the requesting client's surfaces+ or the surface parameter is the current pointer surface. If+ there was a previous surface set with this request it is+ replaced. If surface is NULL, the pointer image is hidden.++ The parameters hotspot_x and hotspot_y define the position of+ the pointer surface relative to the pointer location. Its+ top-left corner is always at (x, y) - (hotspot_x, hotspot_y),+ where (x, y) are the coordinates of the pointer location, in+ surface-local coordinates.++ On surface.attach requests to the pointer surface, hotspot_x+ and hotspot_y are decremented by the x and y parameters+ passed to the request. Attach must be confirmed by+ wl_surface.commit as usual.++ The hotspot can also be updated by passing the currently set+ pointer surface to this request with new values for hotspot_x+ and hotspot_y.++ The input region is ignored for wl_surfaces with the role of+ a cursor. When the use as a cursor ends, the wl_surface is+ unmapped.++ The serial parameter must match the latest wl_pointer.enter+ serial number sent to the client. Otherwise the request will be+ ignored.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" allow-null="true"+ summary="pointer surface"/>+ <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>+ <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>+ </request>++ <event name="enter">+ <description summary="enter event">+ Notification that this seat's pointer is focused on a certain+ surface.++ When a seat's focus enters a surface, the pointer image+ is undefined and a client should respond to this event by setting+ an appropriate pointer image with the set_cursor request.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface entered by the pointer"/>+ <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="leave">+ <description summary="leave event">+ Notification that this seat's pointer is no longer focused on+ a certain surface.++ The leave notification is sent before the enter notification+ for the new focus.+ </description>+ <arg name="serial" type="uint" summary="serial number of the leave event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface left by the pointer"/>+ </event>++ <event name="motion">+ <description summary="pointer motion event">+ Notification of pointer location change. The arguments+ surface_x and surface_y are the location relative to the+ focused surface.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <enum name="button_state">+ <description summary="physical button state">+ Describes the physical state of a button that produced the button+ event.+ </description>+ <entry name="released" value="0" summary="the button is not pressed"/>+ <entry name="pressed" value="1" summary="the button is pressed"/>+ </enum>++ <event name="button">+ <description summary="pointer button event">+ Mouse button click and release notifications.++ The location of the click is given by the last motion or+ enter event.+ The time argument is a timestamp with millisecond+ granularity, with an undefined base.++ The button is a button code as defined in the Linux kernel's+ linux/input-event-codes.h header file, e.g. BTN_LEFT.++ Any 16-bit button code value is reserved for future additions to the+ kernel's event code list. All other button codes above 0xFFFF are+ currently undefined but may be used in future versions of this+ protocol.+ </description>+ <arg name="serial" type="uint" summary="serial number of the button event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="button" type="uint" summary="button that produced the event"/>+ <arg name="state" type="uint" enum="button_state" summary="physical state of the button"/>+ </event>++ <enum name="axis">+ <description summary="axis types">+ Describes the axis types of scroll events.+ </description>+ <entry name="vertical_scroll" value="0" summary="vertical axis"/>+ <entry name="horizontal_scroll" value="1" summary="horizontal axis"/>+ </enum>++ <event name="axis">+ <description summary="axis event">+ Scroll and other axis notifications.++ For scroll events (vertical and horizontal scroll axes), the+ value parameter is the length of a vector along the specified+ axis in a coordinate space identical to those of motion events,+ representing a relative movement along the specified axis.++ For devices that support movements non-parallel to axes multiple+ axis events will be emitted.++ When applicable, for example for touch pads, the server can+ choose to emit scroll events where the motion vector is+ equivalent to a motion event vector.++ When applicable, a client can transform its content relative to the+ scroll distance.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="value" type="fixed" summary="length of vector in surface-local coordinate space"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the pointer object">+ Using this request a client can tell the server that it is not going to+ use the pointer object anymore.++ This request destroys the pointer proxy object, so clients must not call+ wl_pointer_destroy() after using this request.+ </description>+ </request>++ <!-- Version 5 additions -->++ <event name="frame" since="5">+ <description summary="end of a pointer event sequence">+ Indicates the end of a set of events that logically belong together.+ A client is expected to accumulate the data in all events within the+ frame before proceeding.++ All wl_pointer events before a wl_pointer.frame event belong+ logically together. For example, in a diagonal scroll motion the+ compositor will send an optional wl_pointer.axis_source event, two+ wl_pointer.axis events (horizontal and vertical) and finally a+ wl_pointer.frame event. The client may use this information to+ calculate a diagonal vector for scrolling.++ When multiple wl_pointer.axis events occur within the same frame,+ the motion vector is the combined motion of all events.+ When a wl_pointer.axis and a wl_pointer.axis_stop event occur within+ the same frame, this indicates that axis movement in one axis has+ stopped but continues in the other axis.+ When multiple wl_pointer.axis_stop events occur within the same+ frame, this indicates that these axes stopped in the same instance.++ A wl_pointer.frame event is sent for every logical event group,+ even if the group only contains a single wl_pointer event.+ Specifically, a client may get a sequence: motion, frame, button,+ frame, axis, frame, axis_stop, frame.++ The wl_pointer.enter and wl_pointer.leave events are logical events+ generated by the compositor and not the hardware. These events are+ also grouped by a wl_pointer.frame. When a pointer moves from one+ surface to another, a compositor should group the+ wl_pointer.leave event within the same wl_pointer.frame.+ However, a client must not rely on wl_pointer.leave and+ wl_pointer.enter being in the same wl_pointer.frame.+ Compositor-specific policies may require the wl_pointer.leave and+ wl_pointer.enter event being split across multiple wl_pointer.frame+ groups.+ </description>+ </event>++ <enum name="axis_source">+ <description summary="axis source types">+ Describes the source types for axis events. This indicates to the+ client how an axis event was physically generated; a client may+ adjust the user interface accordingly. For example, scroll events+ from a "finger" source may be in a smooth coordinate space with+ kinetic scrolling whereas a "wheel" source may be in discrete steps+ of a number of lines.++ The "continuous" axis source is a device generating events in a+ continuous coordinate space, but using something other than a+ finger. One example for this source is button-based scrolling where+ the vertical motion of a device is converted to scroll events while+ a button is held down.++ The "wheel tilt" axis source indicates that the actual device is a+ wheel but the scroll event is not caused by a rotation but a+ (usually sideways) tilt of the wheel.+ </description>+ <entry name="wheel" value="0" summary="a physical wheel rotation" />+ <entry name="finger" value="1" summary="finger on a touch surface" />+ <entry name="continuous" value="2" summary="continuous coordinate space"/>+ <entry name="wheel_tilt" value="3" summary="a physical wheel tilt" since="6"/>+ </enum>++ <event name="axis_source" since="5">+ <description summary="axis source event">+ Source information for scroll and other axes.++ This event does not occur on its own. It is sent before a+ wl_pointer.frame event and carries the source information for+ all events within that frame.++ The source specifies how this event was generated. If the source is+ wl_pointer.axis_source.finger, a wl_pointer.axis_stop event will be+ sent when the user lifts the finger off the device.++ If the source is wl_pointer.axis_source.wheel,+ wl_pointer.axis_source.wheel_tilt or+ wl_pointer.axis_source.continuous, a wl_pointer.axis_stop event may+ or may not be sent. Whether a compositor sends an axis_stop event+ for these sources is hardware-specific and implementation-dependent;+ clients must not rely on receiving an axis_stop event for these+ scroll sources and should treat scroll sequences from these scroll+ sources as unterminated by default.++ This event is optional. If the source is unknown for a particular+ axis event sequence, no event is sent.+ Only one wl_pointer.axis_source event is permitted per frame.++ The order of wl_pointer.axis_discrete and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis_source" type="uint" enum="axis_source" summary="source of the axis event"/>+ </event>++ <event name="axis_stop" since="5">+ <description summary="axis stop event">+ Stop notification for scroll and other axes.++ For some wl_pointer.axis_source types, a wl_pointer.axis_stop event+ is sent to notify a client that the axis sequence has terminated.+ This enables the client to implement kinetic scrolling.+ See the wl_pointer.axis_source documentation for information on when+ this event may be generated.++ Any wl_pointer.axis events with the same axis_source after this+ event should be considered as the start of a new axis motion.++ The timestamp is to be interpreted identical to the timestamp in the+ wl_pointer.axis event. The timestamp value may be the same as a+ preceding wl_pointer.axis event.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="axis" type="uint" enum="axis" summary="the axis stopped with this event"/>+ </event>++ <event name="axis_discrete" since="5">+ <description summary="axis click event">+ Discrete step information for scroll and other axes.++ This event carries the axis value of the wl_pointer.axis event in+ discrete steps (e.g. mouse wheel clicks).++ This event is deprecated with wl_pointer version 8 - this event is not+ sent to clients supporting version 8 or later.++ This event does not occur on its own, it is coupled with a+ wl_pointer.axis event that represents this axis value on a+ continuous scale. The protocol guarantees that each axis_discrete+ event is always followed by exactly one axis event with the same+ axis number within the same wl_pointer.frame. Note that the protocol+ allows for other events to occur between the axis_discrete and+ its coupled axis event, including other axis_discrete or axis+ events. A wl_pointer.frame must not contain more than one axis_discrete+ event per axis type.++ This event is optional; continuous scrolling devices+ like two-finger scrolling on touchpads do not have discrete+ steps and do not generate this event.++ The discrete value carries the directional information. e.g. a value+ of -2 is two steps towards the negative direction of this axis.++ The axis number is identical to the axis number in the associated+ axis event.++ The order of wl_pointer.axis_discrete and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="discrete" type="int" summary="number of steps"/>+ </event>++ <event name="axis_value120" since="8">+ <description summary="axis high-resolution scroll event">+ Discrete high-resolution scroll information.++ This event carries high-resolution wheel scroll information,+ with each multiple of 120 representing one logical scroll step+ (a wheel detent). For example, an axis_value120 of 30 is one quarter of+ a logical scroll step in the positive direction, a value120 of+ -240 are two logical scroll steps in the negative direction within the+ same hardware event.+ Clients that rely on discrete scrolling should accumulate the+ value120 to multiples of 120 before processing the event.++ The value120 must not be zero.++ This event replaces the wl_pointer.axis_discrete event in clients+ supporting wl_pointer version 8 or later.++ Where a wl_pointer.axis_source event occurs in the same+ wl_pointer.frame, the axis source applies to this event.++ The order of wl_pointer.axis_value120 and wl_pointer.axis_source is+ not guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="value120" type="int" summary="scroll distance as fraction of 120"/>+ </event>++ <!-- Version 9 additions -->++ <enum name="axis_relative_direction">+ <description summary="axis relative direction">+ This specifies the direction of the physical motion that caused a+ wl_pointer.axis event, relative to the wl_pointer.axis direction.+ </description>+ <entry name="identical" value="0"+ summary="physical motion matches axis direction"/>+ <entry name="inverted" value="1"+ summary="physical motion is the inverse of the axis direction"/>+ </enum>++ <event name="axis_relative_direction" since="9">+ <description summary="axis relative physical direction event">+ Relative directional information of the entity causing the axis+ motion.++ For a wl_pointer.axis event, the wl_pointer.axis_relative_direction+ event specifies the movement direction of the entity causing the+ wl_pointer.axis event. For example:+ - if a user's fingers on a touchpad move down and this+ causes a wl_pointer.axis vertical_scroll down event, the physical+ direction is 'identical'+ - if a user's fingers on a touchpad move down and this causes a+ wl_pointer.axis vertical_scroll up scroll up event ('natural+ scrolling'), the physical direction is 'inverted'.++ A client may use this information to adjust scroll motion of+ components. Specifically, enabling natural scrolling causes the+ content to change direction compared to traditional scrolling.+ Some widgets like volume control sliders should usually match the+ physical direction regardless of whether natural scrolling is+ active. This event enables clients to match the scroll direction of+ a widget to the physical direction.++ This event does not occur on its own, it is coupled with a+ wl_pointer.axis event that represents this axis value.+ The protocol guarantees that each axis_relative_direction event is+ always followed by exactly one axis event with the same+ axis number within the same wl_pointer.frame. Note that the protocol+ allows for other events to occur between the axis_relative_direction+ and its coupled axis event.++ The axis number is identical to the axis number in the associated+ axis event.++ The order of wl_pointer.axis_relative_direction,+ wl_pointer.axis_discrete and wl_pointer.axis_source is not+ guaranteed.+ </description>+ <arg name="axis" type="uint" enum="axis" summary="axis type"/>+ <arg name="direction" type="uint" enum="axis_relative_direction"+ summary="physical direction relative to axis motion"/>+ </event>+ </interface>++ <interface name="wl_keyboard" version="9">+ <description summary="keyboard input device">+ The wl_keyboard interface represents one or more keyboards+ associated with a seat.+ </description>++ <enum name="keymap_format">+ <description summary="keyboard mapping format">+ This specifies the format of the keymap provided to the+ client with the wl_keyboard.keymap event.+ </description>+ <entry name="no_keymap" value="0"+ summary="no keymap; client must understand how to interpret the raw keycode"/>+ <entry name="xkb_v1" value="1"+ summary="libxkbcommon compatible, null-terminated string; to determine the xkb keycode, clients must add 8 to the key event keycode"/>+ </enum>++ <event name="keymap">+ <description summary="keyboard mapping">+ This event provides a file descriptor to the client which can be+ memory-mapped in read-only mode to provide a keyboard mapping+ description.++ From version 7 onwards, the fd must be mapped with MAP_PRIVATE by+ the recipient, as MAP_SHARED may fail.+ </description>+ <arg name="format" type="uint" enum="keymap_format" summary="keymap format"/>+ <arg name="fd" type="fd" summary="keymap file descriptor"/>+ <arg name="size" type="uint" summary="keymap size, in bytes"/>+ </event>++ <event name="enter">+ <description summary="enter event">+ Notification that this seat's keyboard focus is on a certain+ surface.++ The compositor must send the wl_keyboard.modifiers event after this+ event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the enter event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface gaining keyboard focus"/>+ <arg name="keys" type="array" summary="the currently pressed keys"/>+ </event>++ <event name="leave">+ <description summary="leave event">+ Notification that this seat's keyboard focus is no longer on+ a certain surface.++ The leave notification is sent before the enter notification+ for the new focus.++ After this event client must assume that all keys, including modifiers,+ are lifted and also it must stop key repeating if there's some going on.+ </description>+ <arg name="serial" type="uint" summary="serial number of the leave event"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface that lost keyboard focus"/>+ </event>++ <enum name="key_state">+ <description summary="physical key state">+ Describes the physical state of a key that produced the key event.+ </description>+ <entry name="released" value="0" summary="key is not pressed"/>+ <entry name="pressed" value="1" summary="key is pressed"/>+ </enum>++ <event name="key">+ <description summary="key event">+ A key was pressed or released.+ The time argument is a timestamp with millisecond+ granularity, with an undefined base.++ The key is a platform-specific key code that can be interpreted+ by feeding it to the keyboard mapping (see the keymap event).++ If this event produces a change in modifiers, then the resulting+ wl_keyboard.modifiers event must be sent after this event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the key event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="key" type="uint" summary="key that produced the event"/>+ <arg name="state" type="uint" enum="key_state" summary="physical state of the key"/>+ </event>++ <event name="modifiers">+ <description summary="modifier and group state">+ Notifies clients that the modifier and/or group state has+ changed, and it should update its local state.+ </description>+ <arg name="serial" type="uint" summary="serial number of the modifiers event"/>+ <arg name="mods_depressed" type="uint" summary="depressed modifiers"/>+ <arg name="mods_latched" type="uint" summary="latched modifiers"/>+ <arg name="mods_locked" type="uint" summary="locked modifiers"/>+ <arg name="group" type="uint" summary="keyboard layout"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the keyboard object"/>+ </request>++ <!-- Version 4 additions -->++ <event name="repeat_info" since="4">+ <description summary="repeat rate and delay">+ Informs the client about the keyboard's repeat rate and delay.++ This event is sent as soon as the wl_keyboard object has been created,+ and is guaranteed to be received by the client before any key press+ event.++ Negative values for either rate or delay are illegal. A rate of zero+ will disable any repeating (regardless of the value of delay).++ This event can be sent later on as well with a new value if necessary,+ so clients should continue listening for the event past the creation+ of wl_keyboard.+ </description>+ <arg name="rate" type="int"+ summary="the rate of repeating keys in characters per second"/>+ <arg name="delay" type="int"+ summary="delay in milliseconds since key down until repeating starts"/>+ </event>+ </interface>++ <interface name="wl_touch" version="9">+ <description summary="touchscreen input device">+ The wl_touch interface represents a touchscreen+ associated with a seat.++ Touch interactions can consist of one or more contacts.+ For each contact, a series of events is generated, starting+ with a down event, followed by zero or more motion events,+ and ending with an up event. Events relating to the same+ contact point can be identified by the ID of the sequence.+ </description>++ <event name="down">+ <description summary="touch down event and beginning of a touch sequence">+ A new touch point has appeared on the surface. This touch point is+ assigned a unique ID. Future events from this touch point reference+ this ID. The ID ceases to be valid after a touch up event and may be+ reused in the future.+ </description>+ <arg name="serial" type="uint" summary="serial number of the touch down event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="surface" type="object" interface="wl_surface" summary="surface touched"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="up">+ <description summary="end of a touch event sequence">+ The touch point has disappeared. No further events will be sent for+ this touch point and the touch point's ID is released and may be+ reused in a future touch down event.+ </description>+ <arg name="serial" type="uint" summary="serial number of the touch up event"/>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ </event>++ <event name="motion">+ <description summary="update of touch point coordinates">+ A touch point has changed coordinates.+ </description>+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>+ </event>++ <event name="frame">+ <description summary="end of touch frame event">+ Indicates the end of a set of events that logically belong together.+ A client is expected to accumulate the data in all events within the+ frame before proceeding.++ A wl_touch.frame terminates at least one event but otherwise no+ guarantee is provided about the set of events within a frame. A client+ must assume that any state not updated in a frame is unchanged from the+ previously known state.+ </description>+ </event>++ <event name="cancel">+ <description summary="touch session cancelled">+ Sent if the compositor decides the touch stream is a global+ gesture. No further events are sent to the clients from that+ particular gesture. Touch cancellation applies to all touch points+ currently active on this client's surface. The client is+ responsible for finalizing the touch points, future touch points on+ this surface may reuse the touch point ID.+ </description>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the touch object"/>+ </request>++ <!-- Version 6 additions -->++ <event name="shape" since="6">+ <description summary="update shape of touch point">+ Sent when a touchpoint has changed its shape.++ This event does not occur on its own. It is sent before a+ wl_touch.frame event and carries the new shape information for+ any previously reported, or new touch points of that frame.++ Other events describing the touch point such as wl_touch.down,+ wl_touch.motion or wl_touch.orientation may be sent within the+ same wl_touch.frame. A client should treat these events as a single+ logical touch point update. The order of wl_touch.shape,+ wl_touch.orientation and wl_touch.motion is not guaranteed.+ A wl_touch.down event is guaranteed to occur before the first+ wl_touch.shape event for this touch ID but both events may occur within+ the same wl_touch.frame.++ A touchpoint shape is approximated by an ellipse through the major and+ minor axis length. The major axis length describes the longer diameter+ of the ellipse, while the minor axis length describes the shorter+ diameter. Major and minor are orthogonal and both are specified in+ surface-local coordinates. The center of the ellipse is always at the+ touchpoint location as reported by wl_touch.down or wl_touch.move.++ This event is only sent by the compositor if the touch device supports+ shape reports. The client has to make reasonable assumptions about the+ shape if it did not receive this event.+ </description>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="major" type="fixed" summary="length of the major axis in surface-local coordinates"/>+ <arg name="minor" type="fixed" summary="length of the minor axis in surface-local coordinates"/>+ </event>++ <event name="orientation" since="6">+ <description summary="update orientation of touch point">+ Sent when a touchpoint has changed its orientation.++ This event does not occur on its own. It is sent before a+ wl_touch.frame event and carries the new shape information for+ any previously reported, or new touch points of that frame.++ Other events describing the touch point such as wl_touch.down,+ wl_touch.motion or wl_touch.shape may be sent within the+ same wl_touch.frame. A client should treat these events as a single+ logical touch point update. The order of wl_touch.shape,+ wl_touch.orientation and wl_touch.motion is not guaranteed.+ A wl_touch.down event is guaranteed to occur before the first+ wl_touch.orientation event for this touch ID but both events may occur+ within the same wl_touch.frame.++ The orientation describes the clockwise angle of a touchpoint's major+ axis to the positive surface y-axis and is normalized to the -180 to+ +180 degree range. The granularity of orientation depends on the touch+ device, some devices only support binary rotation values between 0 and+ 90 degrees.++ This event is only sent by the compositor if the touch device supports+ orientation reports.+ </description>+ <arg name="id" type="int" summary="the unique ID of this touch point"/>+ <arg name="orientation" type="fixed" summary="angle between major axis and positive surface y-axis in degrees"/>+ </event>+ </interface>++ <interface name="wl_output" version="4">+ <description summary="compositor output region">+ An output describes part of the compositor geometry. The+ compositor works in the 'compositor coordinate system' and an+ output corresponds to a rectangular area in that space that is+ actually visible. This typically corresponds to a monitor that+ displays part of the compositor space. This object is published+ as global during start up, or when a monitor is hotplugged.+ </description>++ <enum name="subpixel">+ <description summary="subpixel geometry information">+ This enumeration describes how the physical+ pixels on an output are laid out.+ </description>+ <entry name="unknown" value="0" summary="unknown geometry"/>+ <entry name="none" value="1" summary="no geometry"/>+ <entry name="horizontal_rgb" value="2" summary="horizontal RGB"/>+ <entry name="horizontal_bgr" value="3" summary="horizontal BGR"/>+ <entry name="vertical_rgb" value="4" summary="vertical RGB"/>+ <entry name="vertical_bgr" value="5" summary="vertical BGR"/>+ </enum>++ <enum name="transform">+ <description summary="transform from framebuffer to output">+ This describes the transform that a compositor will apply to a+ surface to compensate for the rotation or mirroring of an+ output device.++ The flipped values correspond to an initial flip around a+ vertical axis followed by rotation.++ The purpose is mainly to allow clients to render accordingly and+ tell the compositor, so that for fullscreen surfaces, the+ compositor will still be able to scan out directly from client+ surfaces.+ </description>+ <entry name="normal" value="0" summary="no transform"/>+ <entry name="90" value="1" summary="90 degrees counter-clockwise"/>+ <entry name="180" value="2" summary="180 degrees counter-clockwise"/>+ <entry name="270" value="3" summary="270 degrees counter-clockwise"/>+ <entry name="flipped" value="4" summary="180 degree flip around a vertical axis"/>+ <entry name="flipped_90" value="5" summary="flip and rotate 90 degrees counter-clockwise"/>+ <entry name="flipped_180" value="6" summary="flip and rotate 180 degrees counter-clockwise"/>+ <entry name="flipped_270" value="7" summary="flip and rotate 270 degrees counter-clockwise"/>+ </enum>++ <event name="geometry">+ <description summary="properties of the output">+ The geometry event describes geometric properties of the output.+ The event is sent when binding to the output object and whenever+ any of the properties change.++ The physical size can be set to zero if it doesn't make sense for this+ output (e.g. for projectors or virtual outputs).++ The geometry event will be followed by a done event (starting from+ version 2).++ Note: wl_output only advertises partial information about the output+ position and identification. Some compositors, for instance those not+ implementing a desktop-style output layout or those exposing virtual+ outputs, might fake this information. Instead of using x and y, clients+ should use xdg_output.logical_position. Instead of using make and model,+ clients should use name and description.+ </description>+ <arg name="x" type="int"+ summary="x position within the global compositor space"/>+ <arg name="y" type="int"+ summary="y position within the global compositor space"/>+ <arg name="physical_width" type="int"+ summary="width in millimeters of the output"/>+ <arg name="physical_height" type="int"+ summary="height in millimeters of the output"/>+ <arg name="subpixel" type="int" enum="subpixel"+ summary="subpixel orientation of the output"/>+ <arg name="make" type="string"+ summary="textual description of the manufacturer"/>+ <arg name="model" type="string"+ summary="textual description of the model"/>+ <arg name="transform" type="int" enum="transform"+ summary="transform that maps framebuffer to output"/>+ </event>++ <enum name="mode" bitfield="true">+ <description summary="mode information">+ These flags describe properties of an output mode.+ They are used in the flags bitfield of the mode event.+ </description>+ <entry name="current" value="0x1"+ summary="indicates this is the current mode"/>+ <entry name="preferred" value="0x2"+ summary="indicates this is the preferred mode"/>+ </enum>++ <event name="mode">+ <description summary="advertise available modes for the output">+ The mode event describes an available mode for the output.++ The event is sent when binding to the output object and there+ will always be one mode, the current mode. The event is sent+ again if an output changes mode, for the mode that is now+ current. In other words, the current mode is always the last+ mode that was received with the current flag set.++ Non-current modes are deprecated. A compositor can decide to only+ advertise the current mode and never send other modes. Clients+ should not rely on non-current modes.++ The size of a mode is given in physical hardware units of+ the output device. This is not necessarily the same as+ the output size in the global compositor space. For instance,+ the output may be scaled, as described in wl_output.scale,+ or transformed, as described in wl_output.transform. Clients+ willing to retrieve the output size in the global compositor+ space should use xdg_output.logical_size instead.++ The vertical refresh rate can be set to zero if it doesn't make+ sense for this output (e.g. for virtual outputs).++ The mode event will be followed by a done event (starting from+ version 2).++ Clients should not use the refresh rate to schedule frames. Instead,+ they should use the wl_surface.frame event or the presentation-time+ protocol.++ Note: this information is not always meaningful for all outputs. Some+ compositors, such as those exposing virtual outputs, might fake the+ refresh rate or the size.+ </description>+ <arg name="flags" type="uint" enum="mode" summary="bitfield of mode flags"/>+ <arg name="width" type="int" summary="width of the mode in hardware units"/>+ <arg name="height" type="int" summary="height of the mode in hardware units"/>+ <arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>+ </event>++ <!-- Version 2 additions -->++ <event name="done" since="2">+ <description summary="sent all information about output">+ This event is sent after all other properties have been+ sent after binding to the output object and after any+ other property changes done after that. This allows+ changes to the output properties to be seen as+ atomic, even if they happen via multiple events.+ </description>+ </event>++ <event name="scale" since="2">+ <description summary="output scaling properties">+ This event contains scaling geometry information+ that is not in the geometry event. It may be sent after+ binding the output object or if the output scale changes+ later. If it is not sent, the client should assume a+ scale of 1.++ A scale larger than 1 means that the compositor will+ automatically scale surface buffers by this amount+ when rendering. This is used for very high resolution+ displays where applications rendering at the native+ resolution would be too small to be legible.++ It is intended that scaling aware clients track the+ current output of a surface, and if it is on a scaled+ output it should use wl_surface.set_buffer_scale with+ the scale of the output. That way the compositor can+ avoid scaling the surface, and the client can supply+ a higher detail image.++ The scale event will be followed by a done event.+ </description>+ <arg name="factor" type="int" summary="scaling factor of output"/>+ </event>++ <!-- Version 3 additions -->++ <request name="release" type="destructor" since="3">+ <description summary="release the output object">+ Using this request a client can tell the server that it is not going to+ use the output object anymore.+ </description>+ </request>++ <!-- Version 4 additions -->++ <event name="name" since="4">+ <description summary="name of this output">+ Many compositors will assign user-friendly names to their outputs, show+ them to the user, allow the user to refer to an output, etc. The client+ may wish to know this name as well to offer the user similar behaviors.++ The name is a UTF-8 string with no convention defined for its contents.+ Each name is unique among all wl_output globals. The name is only+ guaranteed to be unique for the compositor instance.++ The same output name is used for all clients for a given wl_output+ global. Thus, the name can be shared across processes to refer to a+ specific wl_output global.++ The name is not guaranteed to be persistent across sessions, thus cannot+ be used to reliably identify an output in e.g. configuration files.++ Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do+ not assume that the name is a reflection of an underlying DRM connector,+ X11 connection, etc.++ The name event is sent after binding the output object. This event is+ only sent once per output object, and the name does not change over the+ lifetime of the wl_output global.++ Compositors may re-use the same output name if the wl_output global is+ destroyed and re-created later. Compositors should avoid re-using the+ same name if possible.++ The name event will be followed by a done event.+ </description>+ <arg name="name" type="string" summary="output name"/>+ </event>++ <event name="description" since="4">+ <description summary="human-readable description of this output">+ Many compositors can produce human-readable descriptions of their+ outputs. The client may wish to know this description as well, e.g. for+ output selection purposes.++ The description is a UTF-8 string with no convention defined for its+ contents. The description is not guaranteed to be unique among all+ wl_output globals. Examples might include 'Foocorp 11" Display' or+ 'Virtual X11 output via :1'.++ The description event is sent after binding the output object and+ whenever the description changes. The description is optional, and may+ not be sent at all.++ The description event will be followed by a done event.+ </description>+ <arg name="description" type="string" summary="output description"/>+ </event>+ </interface>++ <interface name="wl_region" version="1">+ <description summary="region interface">+ A region object describes an area.++ Region objects are used to describe the opaque and input+ regions of a surface.+ </description>++ <request name="destroy" type="destructor">+ <description summary="destroy region">+ Destroy the region. This will invalidate the object ID.+ </description>+ </request>++ <request name="add">+ <description summary="add rectangle to region">+ Add the specified rectangle to the region.+ </description>+ <arg name="x" type="int" summary="region-local x coordinate"/>+ <arg name="y" type="int" summary="region-local y coordinate"/>+ <arg name="width" type="int" summary="rectangle width"/>+ <arg name="height" type="int" summary="rectangle height"/>+ </request>++ <request name="subtract">+ <description summary="subtract rectangle from region">+ Subtract the specified rectangle from the region.+ </description>+ <arg name="x" type="int" summary="region-local x coordinate"/>+ <arg name="y" type="int" summary="region-local y coordinate"/>+ <arg name="width" type="int" summary="rectangle width"/>+ <arg name="height" type="int" summary="rectangle height"/>+ </request>+ </interface>++ <interface name="wl_subcompositor" version="1">+ <description summary="sub-surface compositing">+ The global interface exposing sub-surface compositing capabilities.+ A wl_surface, that has sub-surfaces associated, is called the+ parent surface. Sub-surfaces can be arbitrarily nested and create+ a tree of sub-surfaces.++ The root surface in a tree of sub-surfaces is the main+ surface. The main surface cannot be a sub-surface, because+ sub-surfaces must always have a parent.++ A main surface with its sub-surfaces forms a (compound) window.+ For window management purposes, this set of wl_surface objects is+ to be considered as a single window, and it should also behave as+ such.++ The aim of sub-surfaces is to offload some of the compositing work+ within a window from clients to the compositor. A prime example is+ a video player with decorations and video in separate wl_surface+ objects. This should allow the compositor to pass YUV video buffer+ processing to dedicated overlay hardware when possible.+ </description>++ <request name="destroy" type="destructor">+ <description summary="unbind from the subcompositor interface">+ Informs the server that the client will not be using this+ protocol object anymore. This does not affect any other+ objects, wl_subsurface objects included.+ </description>+ </request>++ <enum name="error">+ <entry name="bad_surface" value="0"+ summary="the to-be sub-surface is invalid"/>+ <entry name="bad_parent" value="1"+ summary="the to-be sub-surface parent is invalid"/>+ </enum>++ <request name="get_subsurface">+ <description summary="give a surface the role sub-surface">+ Create a sub-surface interface for the given surface, and+ associate it with the given parent surface. This turns a+ plain wl_surface into a sub-surface.++ The to-be sub-surface must not already have another role, and it+ must not have an existing wl_subsurface object. Otherwise the+ bad_surface protocol error is raised.++ Adding sub-surfaces to a parent is a double-buffered operation on the+ parent (see wl_surface.commit). The effect of adding a sub-surface+ becomes visible on the next time the state of the parent surface is+ applied.++ The parent surface must not be one of the child surface's descendants,+ and the parent must be different from the child surface, otherwise the+ bad_parent protocol error is raised.++ This request modifies the behaviour of wl_surface.commit request on+ the sub-surface, see the documentation on wl_subsurface interface.+ </description>+ <arg name="id" type="new_id" interface="wl_subsurface"+ summary="the new sub-surface object ID"/>+ <arg name="surface" type="object" interface="wl_surface"+ summary="the surface to be turned into a sub-surface"/>+ <arg name="parent" type="object" interface="wl_surface"+ summary="the parent surface"/>+ </request>+ </interface>++ <interface name="wl_subsurface" version="1">+ <description summary="sub-surface interface to a wl_surface">+ An additional interface to a wl_surface object, which has been+ made a sub-surface. A sub-surface has one parent surface. A+ sub-surface's size and position are not limited to that of the parent.+ Particularly, a sub-surface is not automatically clipped to its+ parent's area.++ A sub-surface becomes mapped, when a non-NULL wl_buffer is applied+ and the parent surface is mapped. The order of which one happens+ first is irrelevant. A sub-surface is hidden if the parent becomes+ hidden, or if a NULL wl_buffer is applied. These rules apply+ recursively through the tree of surfaces.++ The behaviour of a wl_surface.commit request on a sub-surface+ depends on the sub-surface's mode. The possible modes are+ synchronized and desynchronized, see methods+ wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized+ mode caches the wl_surface state to be applied when the parent's+ state gets applied, and desynchronized mode applies the pending+ wl_surface state directly. A sub-surface is initially in the+ synchronized mode.++ Sub-surfaces also have another kind of state, which is managed by+ wl_subsurface requests, as opposed to wl_surface requests. This+ state includes the sub-surface position relative to the parent+ surface (wl_subsurface.set_position), and the stacking order of+ the parent and its sub-surfaces (wl_subsurface.place_above and+ .place_below). This state is applied when the parent surface's+ wl_surface state is applied, regardless of the sub-surface's mode.+ As the exception, set_sync and set_desync are effective immediately.++ The main surface can be thought to be always in desynchronized mode,+ since it does not have a parent in the sub-surfaces sense.++ Even if a sub-surface is in desynchronized mode, it will behave as+ in synchronized mode, if its parent surface behaves as in+ synchronized mode. This rule is applied recursively throughout the+ tree of surfaces. This means, that one can set a sub-surface into+ synchronized mode, and then assume that all its child and grand-child+ sub-surfaces are synchronized, too, without explicitly setting them.++ Destroying a sub-surface takes effect immediately. If you need to+ synchronize the removal of a sub-surface to the parent surface update,+ unmap the sub-surface first by attaching a NULL wl_buffer, update parent,+ and then destroy the sub-surface.++ If the parent wl_surface object is destroyed, the sub-surface is+ unmapped.+ </description>++ <request name="destroy" type="destructor">+ <description summary="remove sub-surface interface">+ The sub-surface interface is removed from the wl_surface object+ that was turned into a sub-surface with a+ wl_subcompositor.get_subsurface request. The wl_surface's association+ to the parent is deleted. The wl_surface is unmapped immediately.+ </description>+ </request>++ <enum name="error">+ <entry name="bad_surface" value="0"+ summary="wl_surface is not a sibling or the parent"/>+ </enum>++ <request name="set_position">+ <description summary="reposition the sub-surface">+ This schedules a sub-surface position change.+ The sub-surface will be moved so that its origin (top left+ corner pixel) will be at the location x, y of the parent surface+ coordinate system. The coordinates are not restricted to the parent+ surface area. Negative values are allowed.++ The scheduled coordinates will take effect whenever the state of the+ parent surface is applied. When this happens depends on whether the+ parent surface is in synchronized mode or not. See+ wl_subsurface.set_sync and wl_subsurface.set_desync for details.++ If more than one set_position request is invoked by the client before+ the commit of the parent surface, the position of a new request always+ replaces the scheduled position from any previous request.++ The initial position is 0, 0.+ </description>+ <arg name="x" type="int" summary="x coordinate in the parent surface"/>+ <arg name="y" type="int" summary="y coordinate in the parent surface"/>+ </request>++ <request name="place_above">+ <description summary="restack the sub-surface">+ This sub-surface is taken from the stack, and put back just+ above the reference surface, changing the z-order of the sub-surfaces.+ The reference surface must be one of the sibling surfaces, or the+ parent surface. Using any other surface, including this sub-surface,+ will cause a protocol error.++ The z-order is double-buffered. Requests are handled in order and+ applied immediately to a pending state. The final pending state is+ copied to the active state the next time the state of the parent+ surface is applied. When this happens depends on whether the parent+ surface is in synchronized mode or not. See wl_subsurface.set_sync and+ wl_subsurface.set_desync for details.++ A new sub-surface is initially added as the top-most in the stack+ of its siblings and parent.+ </description>+ <arg name="sibling" type="object" interface="wl_surface"+ summary="the reference surface"/>+ </request>++ <request name="place_below">+ <description summary="restack the sub-surface">+ The sub-surface is placed just below the reference surface.+ See wl_subsurface.place_above.+ </description>+ <arg name="sibling" type="object" interface="wl_surface"+ summary="the reference surface"/>+ </request>++ <request name="set_sync">+ <description summary="set sub-surface to synchronized mode">+ Change the commit behaviour of the sub-surface to synchronized+ mode, also described as the parent dependent mode.++ In synchronized mode, wl_surface.commit on a sub-surface will+ accumulate the committed state in a cache, but the state will+ not be applied and hence will not change the compositor output.+ The cached state is applied to the sub-surface immediately after+ the parent surface's state is applied. This ensures atomic+ updates of the parent and all its synchronized sub-surfaces.+ Applying the cached state will invalidate the cache, so further+ parent surface commits do not (re-)apply old state.++ See wl_subsurface for the recursive effect of this mode.+ </description>+ </request>++ <request name="set_desync">+ <description summary="set sub-surface to desynchronized mode">+ Change the commit behaviour of the sub-surface to desynchronized+ mode, also described as independent or freely running mode.++ In desynchronized mode, wl_surface.commit on a sub-surface will+ apply the pending state directly, without caching, as happens+ normally with a wl_surface. Calling wl_surface.commit on the+ parent surface has no effect on the sub-surface's wl_surface+ state. This mode allows a sub-surface to be updated on its own.++ If cached state exists when wl_surface.commit is called in+ desynchronized mode, the pending state is added to the cached+ state, and applied as a whole. This invalidates the cache.++ Note: even if a sub-surface is set to desynchronized, a parent+ sub-surface may override it to behave as synchronized. For details,+ see wl_subsurface.++ If a surface's parent surface behaves as desynchronized, then+ the cached state is applied on set_desync.+ </description>+ </request>+ </interface>++</protocol>
+ examples/simple-server/simple-server.cabal view
@@ -0,0 +1,42 @@+cabal-version: 3.0+name: simple-server+version: 0.1+author: Andrea Rossato+maintainer: andrea.rossato@unitn.it+homepage: https://codeberg.org/andrea_rossato/hs-wayland-scanner+synopsis: a simple wayland client+description: a simple wayland client++category: System+license: BSD-3-Clause+extra-source-files: README.md+build-type: Simple++library+ hs-source-dirs: ./src+ exposed-modules: Graphics.Wayland.Protocol.Wayland+ Graphics.Wayland.Server.Protocol.Wayland+ Graphics.Wayland.Server.Core+ include-dirs: ./cbits+ c-sources: ./cbits/wayland-server-protocols.c+ build-depends: base+ pkgconfig-depends: wayland-server+ ghc-options: -O -Wall+ ghc-prof-options: -auto-all+ default-language: Haskell2010+ default-extensions: ForeignFunctionInterface++executable simple-server+ main-is: simple-server.hs+ hs-source-dirs: ., ./src+ other-modules: Graphics.Wayland.Protocol.Wayland+ Graphics.Wayland.Server.Protocol.Wayland+ Graphics.Wayland.Server.Core+ include-dirs: ./cbits+ c-sources: ./cbits/wayland-server-protocols.c+ build-depends: base+ pkgconfig-depends: wayland-server+ ghc-options: -O -Wall+ ghc-prof-options: -auto-all+ default-language: Haskell2010+ default-extensions: ForeignFunctionInterface
+ examples/simple-server/simple-server.hs view
@@ -0,0 +1,63 @@+module Main where++import Control.Monad+import Foreign hiding ( void )+import Foreign.C++import Graphics.Wayland.Server.Core+import Graphics.Wayland.Server.Protocol.Wayland++-- Request callback: wl_compositor_create_surface+createSurface :: WlCompositorCreateSurfaceCb+createSurface _client _resource newId =+ putStrLn ("[SERVER] create_surface called, new id = " ++ show newId)++-- Interface struct+compositorInterface :: IO WlCompositorInterface+compositorInterface = do+ cs <- mkWlCompositorCreateSurfaceCb createSurface+ return WlCompositorInterface+ { wlCompositorCreateSurface = cs+ , wlCompositorCreateRegion = nullFunPtr+ }++-- Global bind callback+bindImpl :: WlGlobalBindFuncCb+bindImpl client _ _ newId = do+ putStrLn "[SERVER] Client bound to wl_compositor"++ resource <- wl_resource_create+ client+ wl_compositor_interface+ 1+ newId++ alloca $ \ptr -> do+ poke ptr =<< compositorInterface+ wl_resource_set_implementation+ resource+ (castPtr ptr) -- pointer to compositorInterface+ nullPtr+ nullFunPtr++main :: IO ()+main = do+ -- create the display+ display <- wl_display_create++ bindCb <- mkWlGlobalBindFuncCb bindImpl++ void $ wl_global_create+ display+ wl_compositor_interface+ 1+ nullPtr+ bindCb++ namePtr <- wl_display_add_socket_auto display+ name <- peekCString namePtr++ putStrLn "[SERVER] Wayland server running..."+ putStrLn $ "[SERVER] Socket: " ++ name+ + wl_display_run display
+ hs-wayland-scanner.cabal view
@@ -0,0 +1,71 @@+cabal-version: 3.0+name: hs-wayland-scanner+version: 0.1.0+homepage: https://codeberg.org/andrea_rossato/hs-wayland-scanner+synopsis: Haskell implementation of the Wayland Message Definition Language+description: hs-wayland-scanner is an implementation of the Wayland+ Message Definition Language. It will produce low-level+ Haskell bindings for Wayland protocols.++category: System+license: BSD-3-Clause+license-file: LICENSE+author: Andrea Rossato+maintainer: andrea.rossato@unitn.it+extra-source-files: README.md+ LICENSE+ examples/**/*.cabal+ examples/**/*.cfg+ examples/**/*.hs+ examples/**/*.md+ examples/hello-world/protocols/*.xml+ examples/simple-client/protocols/*.xml+ examples/simple-server/protocols/*.xml+build-type: Simple++source-repository head+ type: git+ location: https://codeberg.org/andrea_rossato/hs-wayland-scanner++library+ hs-source-dirs: ./src+ exposed-modules: Graphics.Wayland.Scanner+ Graphics.Wayland.Scanner.Generate+ Graphics.Wayland.Scanner.Parse+ Graphics.Wayland.Scanner.Render+ Graphics.Wayland.Scanner.RenderC+ Graphics.Wayland.Scanner.Solve+ Graphics.Wayland.Scanner.Text+ Graphics.Wayland.Scanner.Types+ build-depends: base >= 4.10 && < 4.30,+ text >= 2.0 && < 2.5,+ bytestring >= 0.5 && < 0.20,+ containers >= 0.7 && < 0.10,+ directory >= 1.2 && < 1.6,+ filepath >= 1.2 && < 1.6,+ process >= 1.6 && < 1.7,+ xml >= 1.3 && < 1.4+ ghc-options: -Wall+ default-language: Haskell2010++executable hws+ main-is: Graphics/Wayland/Scanner/Main.hs+ hs-source-dirs: ./src+ other-modules: Graphics.Wayland.Scanner+ Graphics.Wayland.Scanner.Generate+ Graphics.Wayland.Scanner.Parse+ Graphics.Wayland.Scanner.Render+ Graphics.Wayland.Scanner.RenderC+ Graphics.Wayland.Scanner.Solve+ Graphics.Wayland.Scanner.Text+ Graphics.Wayland.Scanner.Types+ build-depends: base >= 4.10 && < 4.30,+ text >= 2.0 && < 2.5,+ bytestring >= 0.5 && < 0.20,+ containers >= 0.7 && < 0.10,+ directory >= 1.2 && < 1.6,+ filepath >= 1.2 && < 1.6,+ process >= 1.6 && < 1.7,+ xml >= 1.3 && < 1.4+ ghc-options: -Wall -main-is Graphics.Wayland.Scanner.Main+ default-language: Haskell2010
+ src/Graphics/Wayland/Scanner.hs view
@@ -0,0 +1,30 @@+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module re-export the library.+--+------------------------------------------------------------------------+module Graphics.Wayland.Scanner+ ( module Graphics.Wayland.Scanner.Generate+ , module Graphics.Wayland.Scanner.Parse+ , module Graphics.Wayland.Scanner.Render+ , module Graphics.Wayland.Scanner.RenderC+ , module Graphics.Wayland.Scanner.Solve+ , module Graphics.Wayland.Scanner.Text+ , module Graphics.Wayland.Scanner.Types+ ) where++import Graphics.Wayland.Scanner.Generate+import Graphics.Wayland.Scanner.Parse+import Graphics.Wayland.Scanner.Render+import Graphics.Wayland.Scanner.RenderC+import Graphics.Wayland.Scanner.Solve+import Graphics.Wayland.Scanner.Text+import Graphics.Wayland.Scanner.Types
+ src/Graphics/Wayland/Scanner/Generate.hs view
@@ -0,0 +1,102 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Generate+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports some functions for generating Haskell and C+-- code.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Generate where++import Control.Monad+import Data.Char+import qualified Data.Text as T+import Data.Text (Text)+import qualified Data.Text.IO as T+import Text.XML.Light+import System.Directory+import System.FilePath+import System.Process++import Graphics.Wayland.Scanner.Parse+import Graphics.Wayland.Scanner.Render+import Graphics.Wayland.Scanner.RenderC+import Graphics.Wayland.Scanner.Solve+import Graphics.Wayland.Scanner.Text+import Graphics.Wayland.Scanner.Types++-- | File generation+generate' :: HwsConfig -> [Text] -> IO ()+generate' cfg = void . generate cfg++-- | Returns the list of generated Haskell modules+generate :: HwsConfig -> [Text] -> IO [Text]+generate cfg@(HwsConfig prefix nameSpace role _ cbits _) xmlSources = do+ let parseDoc i =+ case parseXMLDoc i of+ Nothing -> error ("invalid XML: " ++ show i)+ Just res -> res+ roleName = if role == Server then "server" else "client"+ docs = map parseDoc xmlSources+ parsedProtos = map parseProtocol docs+ ifaceMap = buildIfaceMap parsedProtos+ solvedProtos = map (solveProtocol ifaceMap) parsedProtos+ include p = T.pack $+ "#include \"" ++ T.unpack (solvedProtoName p) ++ "-" ++ roleName ++ "-protocol.c\"\n" +++ "#include \"" ++ T.unpack (solvedProtoName p) ++ "-" ++ roleName ++ ".c\""+ generateDirs cfg+ generateModuleCore cfg+ mapM_ (generateModule cfg) solvedProtos+ zipWithM_ (generateCbits cfg) (protocols cfg) solvedProtos+ mapM_ (generateFFIWrapper cfg) solvedProtos+ T.writeFile (prefix </> cbits </> "wayland-" ++ roleName ++ "-protocols.c") $+ T.unlines $ autogenWrapperComment : map include solvedProtos+ let generated p = T.intercalate "." $ map toHsType [T.pack nameSpace, "Wayland", T.pack roleName, "Protocol", solvedProtoName p]+ defModules p = T.intercalate "." $ map toHsType [T.pack nameSpace, "Wayland.Protocol", solvedProtoName p]+ coreModule = T.intercalate "." $ map toHsType [T.pack nameSpace, "Wayland", T.pack roleName, "Core"]+ modules p = [generated p, defModules p]+ return $ coreModule : concatMap modules solvedProtos++generateDirs :: HwsConfig -> IO ()+generateDirs (HwsConfig prefix nameSpace role _ cbits src) = do+ let dir = T.unpack $ T.replace "." "/" $ T.pack nameSpace+ createDirectoryIfMissing True $ prefix </> src </> dir </> "Wayland" </> show role </> "Protocol"+ createDirectoryIfMissing True $ prefix </> src </> dir </> "Wayland/Protocol"+ createDirectoryIfMissing True $ prefix </> cbits++generateModule :: HwsConfig -> SolvedProtocol -> IO ()+generateModule cfg@(HwsConfig prefix nameSpace role _ _ src) proto = do+ let dir = T.unpack $ T.replace "." "/" $ T.pack nameSpace+ hsCode = renderProtocol role proto+ roleName = show role+ protoFile = src </> dir </> "Wayland" </> roleName </> "Protocol" </> T.unpack (toHsType $ solvedProtoName proto)+ enumsFile = src </> dir </> "Wayland" </> "Protocol" </> T.unpack (toHsType $ solvedProtoName proto)+ T.writeFile (prefix </> protoFile ++ ".hsc") $ T.unlines $ moduleHeader cfg proto ++ map snd hsCode+ T.writeFile (prefix </> enumsFile ++ ".hsc") $ T.unlines $ moduleEnumHeader cfg proto ++ map fst hsCode++generateModuleCore :: HwsConfig -> IO ()+generateModuleCore cfg@(HwsConfig prefix nameSpace role _ _ src) = do+ let dir = T.unpack $ T.replace "." "/" $ T.pack nameSpace+ T.writeFile (prefix </> src </> dir </> "Wayland" </> show role </> "Core.hs") $ T.unlines $ moduleCore cfg++generateCbits :: HwsConfig -> FilePath -> SolvedProtocol -> IO ()+generateCbits (HwsConfig prefix _ role _ cbits _) infile proto = do+ let roleName = map toLower $ show role+ hFileOpts = [roleName ++ "-header", infile, prefix </> cbits </> T.unpack (solvedProtoName proto) ++ "-" ++ roleName ++ "-protocol.h"]+ cFileOpts = ["private-code", infile, prefix </> cbits </> T.unpack (solvedProtoName proto) ++ "-" ++ roleName ++ "-protocol.c"]+ mapM_ (callProcess "wayland-scanner") [hFileOpts,cFileOpts]++generateFFIWrapper :: HwsConfig -> SolvedProtocol -> IO ()+generateFFIWrapper (HwsConfig prefix _ role _ cbits _) (SolvedProtocol name _ ifaces _ _) = do+ let roleName = map toLower $ show role+ gen (Interface iface _ _ evs reqs _ _) =+ renderCWrapper role iface (if role == Server then evs else reqs) <>+ if null evs || role == Server then "" else renderCListener iface+ file = autogenComment <> "#include <" <> name <> "-" <> T.pack roleName <> "-protocol.h>\n" <> T.unlines (map gen ifaces)+ T.writeFile (prefix </> cbits </> T.unpack name ++ "-" ++ roleName ++ ".c") file
+ src/Graphics/Wayland/Scanner/Main.hs view
@@ -0,0 +1,90 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Main+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- An implementation of the Wayland Message Definition Language+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Main where++import Control.Monad+import Data.List+import qualified Data.Text.IO as T+import System.Environment+import System.Exit++import Graphics.Wayland.Scanner++main :: IO ()+main = do+ as <- getArgs+ when (null as) $ putStrLn usage >> exitFailure+ cfg <- decodeArgs defaultConfig as+ res <- mapM T.readFile (protocols cfg) >>= generate cfg+ putStrLn $ "Protocol Haskell bindings written in " ++ genPrefix cfg+ putStrLn "Generated modules:"+ mapM_ T.putStrLn res+ exitSuccess++defaultConfig :: HwsConfig+defaultConfig = HwsConfig+ { genPrefix = "generated"+ , hsNameSpace = "Graphics"+ , protoRole = Client+ , protocols = []+ , cbitsPrefix = "cbits"+ , srcPrefix = "src"+ }++decodeArgs :: HwsConfig -> [String] -> IO HwsConfig+decodeArgs c [] = return c+decodeArgs c (arg:args) =+ case arg of+ "-h" -> putStrLn longUsage >> exitSuccess+ "-p" | s : args' <- args+ -> decodeArgs c {genPrefix = s} args'+ "-n" | s : args' <- args+ -> decodeArgs c {hsNameSpace = s} args'+ "-r" | "Client" : args' <- args+ -> decodeArgs c {protoRole = Client} args'+ "-r" | "client" : args' <- args+ -> decodeArgs c {protoRole = Client} args'+ "-r" | "Server" : args' <- args+ -> decodeArgs c {protoRole = Server} args'+ "-r" | "server" : args' <- args+ -> decodeArgs c {protoRole = Server} args'+ "-c" | s : _ <- args+ -> read <$> readFile s+ "--cbits" | s : args' <- args+ -> decodeArgs c {cbitsPrefix = s} args'+ "--src" | s : args' <- args+ -> decodeArgs c {srcPrefix = s} args'+ _ | arg `hasExt` ".xml"+ -> decodeArgs c {protocols = arg : protocols c} args+ | otherwise -> putStrLn ("Unknow arg: " ++ arg ++ "\n" ++ usage) >> exitFailure++hasExt :: FilePath -> String -> Bool+hasExt f e = e `isSuffixOf` f++usage :: String+usage = "Usage: hws [-h] [-p PATH] [-n STRING] [-r [Client|Server]] [-c PATH] [--cbits PATH] [--src PATH] [PROTOCOLS]"++longUsage :: String+longUsage = "Usage: hws [OPTIONS] [PROTOCOLS]\n\nOptions:\n" ++ details+ where+ details = "\+ \-h Print help\n\+ \-p PATH Root directory for generated files (Default: \"./generated\")\n\+ \-n STRING Namespace for generated modules (Default: \"Graphics\")\n\+ \-r ROLE Generate Client or Server protocols (Default: \"Client\")\n\+ \-c PATH Path to a configuration file\n\+ \--cbits PATH Sub-directory for generated C files (Default: \"cbits\")\n\+ \--src PATH Sub-directory for generated Haskell files (Default: \"src\")\n\+ \[PROTOCOLS] The Wayland XML files to be processed\n\+ \"
+ src/Graphics/Wayland/Scanner/Parse.hs view
@@ -0,0 +1,88 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Parse+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports some functions for parsing the xml into the+-- AST.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Parse where++import qualified Data.Text as T+import Data.Text (Text)+import Text.XML.Light++import Graphics.Wayland.Scanner.Types++-- | Look up an attribute by name, returning empty Text if absent.+attr :: String -> Element -> Text+attr name = maybe T.empty T.pack . findAttr (unqual name)++-- | Find direct children with the given tag name.+children :: String -> Element -> [Element]+children name = findChildren (unqual name)++parseWlTypeArg :: Element -> Arg+parseWlTypeArg el =+ let t = attr "type" el+ d = parseDesc el+ en = attr "enum" el+ an = attr "allow-null" el+ obj = case findAttr (unqual "interface") el of+ Nothing -> Untyped d+ Just x -> Typed d (T.pack x)+ in case t of+ "object" -> ArgObject obj $ an /= "false"+ "new_id" -> ArgNewId obj+ "array" -> ArgArray d+ "uint" -> ArgValue d $ TUint $ if T.null en then Nothing else Just en+ "int" -> ArgValue d $ TInt $ if T.null en then Nothing else Just en+ "string" -> ArgValue d $ TString $ an == "true"+ _ -> ArgValue d $ parseWlTypeValue t++parseWlTypeValue :: Text -> WlType+parseWlTypeValue "fixed" = TFixed+parseWlTypeValue "fd" = TFd+parseWlTypeValue t = error $ "wayland type not supported: " ++ show t++parseEnum :: Element -> EnumDecl+parseEnum el =+ let name = attr "name" el+ bitfield = attr "bitfield" el+ entry e = EnumEntry (attr "name" e) (parseDesc e)+ in EnumDecl name (parseDesc el) (bitfield == "true") $ map entry (children "entry" el)++parseMes :: Element -> Message+parseMes el =+ let name = attr "name" el+ since = if T.null (attr "since" el) then "1" else attr "since" el+ argTypes = map parseWlTypeArg $ children "arg" el+ in Message name (parseDesc el) argTypes (read $ T.unpack since)++parseIface :: Name -> Element -> Interface+parseIface n el =+ let version = attr "version" el+ iface = attr "name" el+ events = map parseMes $ children "event" el+ reqs = map parseMes $ children "request" el+ enums = map parseEnum $ children "enum" el+ in Interface iface n (parseDesc el) events reqs enums (read $ T.unpack version)++parseDesc :: Element -> Text+parseDesc el =+ let summary = attr "summary" el+ descText = T.pack . concatMap strContent $ children "description" el+ normalize = T.unlines . map (T.unwords . T.words) . T.splitOn "\n\n"+ in if T.null descText then summary else normalize descText++parseProtocol :: Element -> Protocol+parseProtocol el =+ let name = attr "name" el+ ifaces = map (parseIface name) $ children "interface" el+ in Protocol name (parseDesc el) ifaces
+ src/Graphics/Wayland/Scanner/Render.hs view
@@ -0,0 +1,210 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Render+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports some functions for rendering the AST into+-- Haskell.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Render where++import qualified Data.Map as Map+import qualified Data.Set as Set+import qualified Data.Text as T+import Data.Text (Text)++import Graphics.Wayland.Scanner.Text+import Graphics.Wayland.Scanner.Types++-- | Name is the interface where the Arg is occuring+renderArg :: Name -> Arg -> Text+renderArg iface arg =+ case arg of+ (ArgNewId (Untyped _) ) -> "Ptr WlInterface -> Word32 -> Word32" -- A special case: new_id without interface+ (ArgNewId (Typed d t) ) -> "Ptr " <> toHsType t <> " " <> formatArgComment d+ (ArgObject (Typed d t) b) -> "Ptr " <> toHsType t <> " " <> formatArgComment (d <> maybeNull b)+ (ArgObject (Untyped d) b) -> "Ptr () " <> formatArgComment (d <> " Opaque pointer: cast with 'castPtr'") <> maybeNull b+ (ArgValue d (TInt e) ) -> maybe "Int32" formatEnum e <> " " <> formatArgComment d+ (ArgValue d (TUint e) ) -> maybe "Word32" formatEnum e <> " " <> formatArgComment d+ (ArgValue d TFixed ) -> "Int32 " <> formatArgComment d+ (ArgValue d (TString b)) -> "CString " <> formatArgComment (d <> maybeNull b)+ (ArgValue d TFd ) -> "CInt " <> formatArgComment d+ (ArgArray d ) -> "Ptr WlArray " <> formatArgComment d+ where+ maybeNull b = if b then " __Maybe @NULL@__" else ""+ formatEnum e =+ case T.splitOn "." e of+ [x,y] -> T.toUpper $ x <> "_" <> y+ _ -> T.toUpper $ iface <> "_" <> e++-- | Name is the iface name+renderReturn :: Name -> Maybe ObjectType -> Text+renderReturn _ Nothing = "IO ()"+renderReturn n (Just (Typed d t)) =+ "IO (" <> renderArg n (ArgNewId $ Typed "" t) <> ") " <> formatArgComment d+renderReturn _ (Just (Untyped _)) =+ "Ptr WlInterface " <> formatArgComment "Interface descriptor (e.g. 'wl_compositor_interface')" <>+ "\n -> Word32 " <> formatArgComment "Version to bind" <>+ "\n -> IO (Ptr ()) " <> formatArgComment "Opaque pointer to the bound object; cast with 'castPtr'"++-- | Generate request bidings+renderRequest :: RoleRender -> Name -> [Text]+renderRequest (RoleRender r _ smsgs reqSep _ _ _ defArg) iface =+ formatHaddockSubSec (toHsType iface <> " Requests") : map gen smsgs+ where+ gen (Message name desc args since) =+ let (ret, args') = if r == Server then (Nothing, args) else splitArgs args+ cName = iface <> reqSep <> name+ hsArgs = defArg : map (renderArg iface) args'+ comment = formatTopLevelComment $ desc <> "\n__Since version " <> (T.pack $ show since) <> "__"+ typeSig = formatArgs $ hsArgs ++ [renderReturn iface ret]+ in T.unlines+ [ comment+ , "foreign import ccall \"ffi_" <> cName <> "\""+ , " " <> cName <> " :: "+ , " " <> typeSig+ ]++-- | Generate storable instances for listeners+renderStorable :: RoleRender -> Name -> [Text]+renderStorable (RoleRender _ [] _ _ _ _ _ _) _ = []+renderStorable (RoleRender _ rmsgs _ _ suffix structSuffix _ _) iface =+ let hsIface = toHsType iface+ structName = hsIface <> structSuffix+ pokeLines =+ [ " (#poke struct " <> iface <> suffix <> ", " <>+ name <> ") ptr (" <> toHsFcn (iface <> "_" <> name) <> " l)"+ | (Message name _ _ _) <- rmsgs+ ]+ in [ "-- | Storable instance for the " <> iface <> " interface"+ , "instance Storable " <> structName <> " where"+ , " sizeOf _ = #size struct " <> iface <> suffix+ , " alignment _ = #alignment struct " <> iface <> suffix+ , ""+ , " poke ptr l = do"+ ] ++ pokeLines +++ [ ""+ , " peek _ = error \"peek not implemented\""+ ]++-- | Render 'enum' values+renderEntry :: Name -> EnumEntry -> Text+renderEntry ename (EnumEntry entry desc) =+ let name = T.toUpper $ ename <> "_" <> entry+ in T.unlines+ [ formatTopLevelComment desc+ , "pattern " <> name <> " :: " <> T.toUpper ename+ , "pattern " <> name <> " = #const " <> name+ ]++-- | Render 'enum'+renderEnum :: EnumMap -> Name -> EnumDecl -> Text+renderEnum enumMap iface (EnumDecl name desc bf enums) =+ let ename = T.toUpper $ iface <> "_" <> name+ check et =+ case Set.toList et of+ [] -> ("Word32", Nothing)+ [EInt] -> ("Int32" , Nothing)+ [EUint] -> ("Word32", Nothing)+ (_:_) -> ("Int32" , Just $ "__Note: enum " <> ename <> " used as both int and uint; using Int32__")+ (etype, warning) =+ case Map.lookup (iface <> "." <> name) enumMap of+ Just et -> check et+ Nothing -> ("Word32", Nothing)+ in T.unlines $+ [ formatTopLevelComment+ (desc <> maybe "" id warning <>+ if bf+ then "\n__Bitmask__: values of this enum are bitflags and may be combined using bitwise OR."+ else "")+ , "type " <> ename <> " = " <> etype+ ] ++ map (renderEntry ename) enums++-- | Render wrappers for callbacks+renderCallback :: RoleRender -> Name -> [Text]+renderCallback (RoleRender _ [] _ _ _ _ _ _) _ = []+renderCallback (RoleRender _ rmsgs _ _ _ _ defArgs _) iface = map gen rmsgs+ where+ gen (Message name desc args since) =+ let hsName = toHsType (iface <> "_" <> name) <> "Cb"+ comment = formatTopLevelComment $ desc <> "\n__Since version " <> (T.pack $ show since) <> "__"+ args' = formatArgs $ defArgs ++ map (renderArg iface) args ++ ["IO ()"]+ typeSig = T.unwords ["type", hsName, "=\n ", args']+ wrapper = T.unwords+ [ "foreign import ccall \"wrapper\""+ , "mk" <> hsName+ , "::"+ , hsName+ , "-> IO (FunPtr " <> hsName <> ")"+ ]+ in T.unlines [comment, typeSig, wrapper]++-- | Render the listener+renderListener :: RoleRender -> Name -> [Text]+renderListener (RoleRender _ [] _ _ _ _ _ _) _ = []+renderListener (RoleRender _ rmsgs _ _ _ structSuffix _ _) iface =+ let hsIface = toHsType iface+ fieldName n = iface <> "_" <> n+ structName = hsIface <> structSuffix+ fields =+ [ toHsFcn (fieldName n) <> " :: FunPtr " <> toHsType (fieldName n) <>+ "Cb -- ^ See '" <> toHsType (fieldName n) <> "Cb'"+ | (Message n _ _ _) <- rmsgs]+ fieldsTxt =+ case fields of+ [] -> []+ (f:fs) -> " { " <> f : map (" , " <>) fs ++ [" }"]+ in [ formatHaddockSubSec (toHsType iface <> " Events")+ , "data " <> structName <> " = " <> structName+ ] ++ fieldsTxt++-- | Render an 'Interface': produce the 'enum's and the generated+-- file.+renderInterface :: Role -> EnumMap -> Interface -> (Text,Text)+renderInterface r enumMap i@(Interface iface _ desc evs _ enums _) =+ let callbacks = renderCallback (roleRender r i) iface+ listener = renderListener (roleRender r i) iface+ rendEnums = T.unlines $ map (renderEnum enumMap iface) enums+ storable = renderStorable (roleRender r i) iface+ requests = if r == Server && iface == "wl_display"+ then []+ else renderRequest (roleRender r i) iface+ ifacePtr = [ "foreign import ccall \"&" <> iface <> "_interface\""+ , " " <> iface <> "_interface :: Ptr WlInterface"+ ]+ addListen = if null evs || r == Server+ then []+ else+ [ "foreign import ccall \"ffi_" <> iface <> "_add_listener\""+ , " " <> iface <> "_add_listener :: Ptr " <> toHsType iface <>+ " -> Ptr " <> toHsType iface <> "Listener -> Ptr () -> IO CInt"+ ]++ in (,) rendEnums $ T.unlines $+ [ formatHaddockSec $ toHsType iface+ , formatTopLevelComment desc+ , if iface `elem` ["wl_display", "wl_registry"]+ then "" else "data " <> toHsType iface+ ] ++ listener ++ storable ++ callbacks ++ requests ++ ifacePtr ++ addListen++-- | Render a 'SolvedProtocol'.+renderProtocol :: Role -> SolvedProtocol -> [(Text, Text)]+renderProtocol r (SolvedProtocol _ _ ifaces _ enumMap) = map (renderInterface r enumMap) ifaces++roleRender :: Role -> Interface -> RoleRender+roleRender Client (Interface iface _ _ evs reqs _ _) =+ RoleRender Client evs reqs "_" "_listener" "Listener"+ [ "Ptr () -- ^ user data"+ , "Ptr " <> toHsType iface <> " -- ^ The interface '" <> toHsType iface <> "'"+ ] $ "Ptr " <> toHsType iface <> formatArgComment ("The pointer to the interface '" <> toHsType iface <> "'.")+roleRender Server (Interface _ _ _ evs reqs _ _) =+ RoleRender Server reqs evs "_send_" "_interface" "Interface"+ [ "Ptr WlClient"+ , "Ptr WlResource"+ ] "Ptr WlResource"
+ src/Graphics/Wayland/Scanner/RenderC.hs view
@@ -0,0 +1,81 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.RenderC+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports some functions for rendering the AST into C.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.RenderC where++import qualified Data.Text as T+import Data.Text (Text)++import Graphics.Wayland.Scanner.Text+import Graphics.Wayland.Scanner.Types++renderCArg :: Role -> Arg -> Text -> Text+renderCArg r a an+ | (ArgNewId (Untyped _) ) <- a = error "new_id cannot be a function argument"+ | (ArgNewId (Typed _ t) ) <- a = if r == Server then "struct wl_resource *" <> an else "struct " <> t <> " *" <> an+ | (ArgObject (Untyped _) _) <- a = "struct wl_proxy *" <> an+ | (ArgObject (Typed _ t) _) <- a = if r == Server then "struct wl_resource *" <> an else "struct " <> t <> " *" <> an+ | (ArgValue _ (TInt _) ) <- a = "int32_t " <> an+ | (ArgValue _ (TUint _) ) <- a = "uint32_t " <> an+ | (ArgValue _ TFixed ) <- a = "int32_t " <> an+ | (ArgValue _ (TString _)) <- a = "const char *" <> an+ | (ArgValue _ TFd ) <- a = "int32_t " <> an+ | (ArgArray _ ) <- a = "struct wl_array *" <> an++renderCReturn :: Role -> Maybe ObjectType -> Text+renderCReturn _ (Just (Untyped _)) = "void * "+renderCReturn r (Just t) = renderCArg r (ArgNewId t) ""+renderCReturn _ Nothing = "void"++-- | Generate request c wrappers+renderCWrapper :: Role -> Name -> [Message] -> Text+renderCWrapper Server "wl_display" _ = ""+renderCWrapper r iface reqs = unlines' $ map gen reqs+ where+ gen (Message name _ args _) =+ let cName = iface <> (if r == Server then "_send_" else "_") <> name+ (ret, args') = if r == Server then (Nothing, args) else+ case splitArgs args of+ -- a new_id without interface: add wl_interface and version+ (Just (Untyped d), as) ->+ ( Just (Untyped d)+ , as +++ [ ArgObject (Typed d "wl_interface") False+ , ArgValue "" (TUint Nothing)+ ]+ )+ (mt, as) -> (mt, as)+ idents = map (T.pack . return) ['a'..'z']+ defArg = if r == Client+ then "struct " <> iface <> " *" <> iface+ else "struct wl_resource *resource_"+ cArgs = T.intercalate ", " $ defArg : zipWith (renderCArg r) args' idents+ cArgs' = T.intercalate ", " $ take (length args') idents+ cArgs'' = if T.null cArgs' then "" else ", " <> cArgs'+ in T.unlines+ [ renderCReturn r ret <> " ffi_" <> cName <> "(" <> cArgs <> ")"+ , "{"+ , " return " <> cName <> "(" <> (if r == Server then "resource_" else iface) <> cArgs'' <> ");"+ , "}"+ ]++renderCListener :: Name -> Text+renderCListener cName =+ T.unlines+ [ "int ffi_" <> cName <> "_add_listener(struct " <> cName <> " *" <>+ cName <> ", const struct " <> cName <>"_listener *listener, void *data)"+ , "{"+ , " " <> cName <> "_add_listener(" <> cName <> ", listener, data);"+ , "}"+ ]+
+ src/Graphics/Wayland/Scanner/Solve.hs view
@@ -0,0 +1,66 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Solve+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports functions to solve `Protocol` dependencies and+-- `enum` types.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Solve where++import Data.List+import Data.Map (Map)+import qualified Data.Map as Map+import Data.Maybe+import qualified Data.Set as Set+import qualified Data.Text as T++import Graphics.Wayland.Scanner.Types++type IfaceMap = Map Name Interface++buildIfaceMap :: [Protocol] -> IfaceMap+buildIfaceMap protos =+ Map.fromList+ [ (ifaceName i, i)+ | p <- protos+ , i <- interfaces p+ ]++-- | Solve 'Protocol' dependencies and 'enum' types.+solveProtocol :: IfaceMap -> Protocol -> SolvedProtocol+solveProtocol ifaceMap (Protocol name desc ifaces) =+ let getArg (ArgObject (Typed _ n) _) = Just n+ getArg (ArgNewId (Typed _ n) ) = Just n+ getArg _ = Nothing+ getDeps (Message _ _ as _) = mapMaybe getArg as+ collectArgs (Interface _ _ _ evs reqs _ _) =+ concatMap getDeps evs ++ concatMap getDeps reqs+ args = nub $ concatMap collectArgs ifaces+ checkArg iface =+ case Map.lookup iface ifaceMap of+ Just i -> if ifaceProtocol i /= name then Just $ ifaceProtocol i else Nothing+ Nothing -> error $ "Unsolved external dependency: unknown interface '" <>+ T.unpack iface <> "' (protocol '" <> T.unpack name <> "')"+ in SolvedProtocol name desc ifaces+ (nub $ mapMaybe checkArg args)+ (Map.unionsWith Set.union $ map collectEnumTypes ifaces)++collectEnumTypes :: Interface -> EnumMap+collectEnumTypes (Interface name _ _ evs reqs _ _) =+ let nsEnum e =+ case T.splitOn "." e of+ [_,_] -> e+ _ -> name <> "." <> e+ getArgEnum (ArgValue _ (TInt (Just e))) = Just (nsEnum e, Set.singleton EInt )+ getArgEnum (ArgValue _ (TUint (Just e))) = Just (nsEnum e, Set.singleton EUint)+ getArgEnum _ = Nothing+ getEnum (Message _ _ as _) = mapMaybe getArgEnum as+ collectedEnums = nub $ concatMap getEnum evs ++ concatMap getEnum reqs+ in Map.fromListWith Set.union collectedEnums
+ src/Graphics/Wayland/Scanner/Text.hs view
@@ -0,0 +1,285 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Text+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports some functions for 'Text' manipulation and some+-- templates.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Text where++import Data.Char+import Data.Text (Text)+import qualified Data.Text as T++import Graphics.Wayland.Scanner.Types++capitalize :: Text -> Text+capitalize t =+ case T.uncons t of+ Nothing -> t+ Just (c, rest) -> T.cons (toUpper c) rest++lowerFirst :: Text -> Text+lowerFirst t =+ case T.uncons t of+ Nothing -> t+ Just (c, rest) -> T.cons (toLower c) rest++toCamel :: Text -> Text+toCamel t =+ let parts = T.splitOn "_" t+ in case parts of+ [] -> t+ (x:xs) -> x <> T.concat (map capitalize xs)++toHsType :: Text -> Text+toHsType = capitalize . toCamel++toHsFcn :: Text -> Text+toHsFcn = lowerFirst . toCamel++wordWrap :: Int -> Text -> Text+wordWrap maxLen = unlines' . concatMap (wrapLine maxLen) . T.lines++wrapLine :: Int -> Text -> [Text]+wrapLine maxLen line = go (T.words line) T.empty []+ where+ go [] cur acc = map haddockIdent $ reverse $ flush cur acc+ go (w:ws) cur acc+ | T.null cur = go ws w acc+ | T.length cur + 1 + T.length w <= maxLen+ = go ws (cur <> " " <> w) acc+ | otherwise = go ws w (cur : acc)+ flush cur acc = if T.null cur then acc else cur : acc++haddockIdent :: Text -> Text+haddockIdent = T.unwords . map go . T.words+ where+ go w+ | "__" `T.isInfixOf` w = w+ | "_" `T.isInfixOf` w = "@" <> w <> "@"+ | otherwise = w++formatHaddockSec :: Text -> Text+formatHaddockSec t =+ unlines'+ [ "-- * " <> t+ , "--"+ , "-- $" <> T.replace " " "_" t+ ]++formatHaddockSubSec :: Text -> Text+formatHaddockSubSec t =+ unlines'+ [ "-- ** " <> t+ , "--"+ , "-- $" <> T.replace " " "_" t+ ]++formatArgs :: [Text] -> Text+formatArgs [] = ""+formatArgs as = T.intercalate "\n -> " as++formatArgComment :: Text -> Text+formatArgComment "" = ""+formatArgComment c = "-- ^ " <> haddockIdent c++formatTopLevelComment :: Text -> Text+formatTopLevelComment "" = ""+formatTopLevelComment c =+ unlines'+ [ "{- |"+ , T.intercalate "\n\n" $ map (wordWrap 80) $ T.lines c+ , "-}"+ ]++formatHaddockHeader :: Name -> Text -> Text+formatHaddockHeader name desc =+ unlines'+ [ "{- |"+ , "Module : " <> name+ , "Copyright : Public Domain (generated by hs-wayland-scanner)"+ , "License : Public Domain (generated by hs-wayland-scanner)"+ , ""+ , "Maintainer : <https://codeberg.org/andrea_rossato/hs-wayland-scanner>"+ , "Stability : stable"+ , "Portability : portable"+ , ""+ , T.intercalate "\n\n" $ map (wordWrap 80) $ T.lines desc+ , "-}"+ ]++moduleHeader :: HwsConfig -> SolvedProtocol -> [Text]+moduleHeader (HwsConfig _ nameSpace role _ _ _) (SolvedProtocol name desc _ deps _) =+ [ "{-# LANGUAGE ForeignFunctionInterface #-}"+ , "{-# OPTIONS_GHC -Wno-unused-imports #-}"+ , formatHaddockHeader modName desc+ , "module " <> modName <> " where"+ , ""+ , if name /= "wayland" then "import "<> T.pack nameSpace <> "." <> "Wayland.Protocol.Wayland" else ""+ , "import "<> T.pack nameSpace <> "." <> "Wayland." <> modRole <> ".Core"+ , "import "<> T.pack nameSpace <> "." <> "Wayland.Protocol." <> toHsType name+ , ""+ , "import Foreign"+ , "import Foreign.C.String"+ , "import Foreign.C.Types"+ , imports+ , "#include \"" <> name <> "-" <> T.toLower modRole <> "-protocol.h\"\n"+ ]+ where+ modName = T.pack nameSpace <> ".Wayland." <> modRole <> ".Protocol." <> toHsType name+ modRole = T.pack $ show role+ modImp d = "import " <> T.pack nameSpace <> ".Wayland." <> modRole <> ".Protocol." <> toHsType d+ imports = T.unlines $ map modImp deps++moduleEnumHeader :: HwsConfig -> SolvedProtocol -> [Text]+moduleEnumHeader (HwsConfig _ nameSpace role _ _ _) p =+ [ "{-# LANGUAGE ForeignFunctionInterface #-}"+ , "{-# LANGUAGE PatternSynonyms #-}"+ , formatHaddockHeader modName "Data types and 'enum' shared by the client and server protocols."+ , "module " <> modName <> " where"+ , ""+ , "import Foreign"+ , "#include \"" <> solvedProtoName p <> "-" <> T.toLower modRole <> "-protocol.h\"\n"+ ] +++ if solvedProtoName p /= "wayland" then [] else+ [ "data WlArray"+ , "data WlRegistry"+ , "data WlDisplay"+ , "data WlInterface"+ ]+ where+ modName = T.pack nameSpace <> ".Wayland.Protocol." <> toHsType (solvedProtoName p)+ modRole = T.pack $ show role++-- | The core modules implement wayland-server-core and+-- wayland-client-core.+moduleCore :: HwsConfig -> [Text]+moduleCore c@(HwsConfig _ _ Client _ _ _) = moduleClientCore c+moduleCore c@(HwsConfig _ _ Server _ _ _) = moduleServerCore c++moduleClientCore :: HwsConfig -> [Text]+moduleClientCore (HwsConfig _ nameSpace role _ _ _) =+ [ formatHaddockHeader modName "An implementation of the wayland-client-core library"+ , "module " <> modName <> ".Core where\n"+ , "import Foreign"+ , "import Foreign.C.String"+ , "import Foreign.C.Types\n"+ , "import "<> T.pack nameSpace <> ".Wayland.Protocol.Wayland\n"+ , "data WlEventQueue"+ , ""+ , "-- Core connection"+ , "foreign import ccall \"wl_display_connect\""+ , " wl_display_connect :: CString -> IO (Ptr WlDisplay)"+ , ""+ , "foreign import ccall \"wl_display_disconnect\""+ , " wl_display_disconnect :: Ptr WlDisplay -> IO ()"+ , ""+ , "foreign import ccall \"wl_display_get_fd\""+ , " wl_display_get_fd :: Ptr WlDisplay -> IO CInt"+ , ""+ , "foreign import ccall \"wl_display_roundtrip\""+ , " wl_display_roundtrip :: Ptr WlDisplay -> IO CInt"+ , ""+ , "-- Buffer management"+ , "foreign import ccall \"wl_display_flush\""+ , " wl_display_flush :: Ptr WlDisplay -> IO CInt"+ , ""+ , "-- Processes incoming events. Blocks until events are read."+ , "foreign import ccall \"wl_display_dispatch\""+ , " wl_display_dispatch :: Ptr WlDisplay -> IO CInt"+ ]+ where+ modName = T.pack nameSpace <> ".Wayland." <> T.pack (show role)++moduleServerCore :: HwsConfig -> [Text]+moduleServerCore (HwsConfig _ nameSpace role _ _ _) =+ [ formatHaddockHeader modName "An implementation of the wayland-server-core library"+ , "module " <> modName <> ".Core where\n"+ , "import Foreign"+ , "import Foreign.C.String"+ , "import Foreign.C.Types\n"+ , "import "<> T.pack nameSpace <> ".Wayland.Protocol.Wayland\n"+ , "data WlClient"+ , "data WlResource"+ , "data WlGlobal"+ , ""+ , "foreign import ccall \"wl_display_create\""+ , " wl_display_create :: IO (Ptr WlDisplay)"+ , ""+ , "foreign import ccall \"wl_display_destroy\""+ , " wl_display_destroy :: Ptr WlDisplay -> IO ()"+ , ""+ , "foreign import ccall \"wl_display_run\""+ , " wl_display_run :: Ptr WlDisplay -> IO ()"+ , ""+ , "foreign import ccall \"wl_display_add_socket_fd\""+ , " wl_display_add_socket_fd :: Ptr WlDisplay -> CInt -> IO CInt"+ , ""+ , "foreign import ccall \"wl_display_add_socket_auto\""+ , " wl_display_add_socket_auto :: Ptr WlDisplay -> IO CString"+ , ""+ , "type WlGlobalBindFuncCb = Ptr WlClient -> Ptr () -> Word32 -> Word32 -> IO ()"+ , ""+ , "foreign import ccall \"wl_global_create\""+ , " wl_global_create"+ , " :: Ptr WlDisplay"+ , " -> Ptr WlInterface"+ , " -> CInt"+ , " -> Ptr ()"+ , " -> FunPtr WlGlobalBindFuncCb"+ , " -> IO (Ptr WlGlobal)"+ , ""+ , "foreign import ccall \"wrapper\""+ , " mkWlGlobalBindFuncCb :: WlGlobalBindFuncCb -> IO (FunPtr WlGlobalBindFuncCb)"+ , ""+ , "foreign import ccall \"wl_resource_create\""+ , " wl_resource_create"+ , " :: Ptr WlClient"+ , " -> Ptr WlInterface"+ , " -> CInt"+ , " -> Word32"+ , " -> IO (Ptr WlResource)"+ , ""+ , "foreign import ccall \"wl_resource_destroy\""+ , " wl_resource_destroy :: Ptr WlResource -> IO ()"+ , ""+ , "type WlResourceDestroyFunc = Ptr WlResource -> IO ()"+ , ""+ , "foreign import ccall \"wl_resource_set_implementation\""+ , " wl_resource_set_implementation"+ , " :: Ptr WlResource"+ , " -> Ptr () -- ^ interface struct (opaque pointer): cast with 'castPtr'"+ , " -> Ptr () -- ^ user data"+ , " -> FunPtr WlResourceDestroyFunc -- ^ destroy callback"+ , " -> IO ()"+ , ""+ , "foreign import ccall \"wrapper\""+ , " mkWlResourceDestroyFunc :: WlResourceDestroyFunc -> IO (FunPtr WlResourceDestroyFunc)"+ , ""+ , "foreign import ccall \"wl_resource_post_event\""+ , " wl_resource_post_event :: Ptr WlResource -> Word32 -> IO ()"+ ]+ where+ modName = T.pack nameSpace <> ".Wayland." <> T.pack (show role)++autogenComment :: Text+autogenComment =+ "/* Auto-generated by hs-wayland-scanner.\n" <>+ "Do not manually edit unless you know what you are doing. */\n\n"++autogenWrapperComment :: Text+autogenWrapperComment =+ "/* Auto-generated by hs-wayland-scanner.\n" <>+ "Aggregates Wayland protocol sources and FFI wrappers.\n" <>+ "Do not compile individual protocol .c files separately. */\n\n"++unlines' :: [Text] -> Text+unlines' = T.intercalate "\n"
+ src/Graphics/Wayland/Scanner/Types.hs view
@@ -0,0 +1,136 @@+{-# LANGUAGE OverloadedStrings #-}+------------------------------------------------------------------------+-- |+-- Module : Graphics.Wayland.Scanner.Types+-- Copyright : (c) Andrea Rossato 2026+-- License : BSD3-style (see LICENSE)+--+-- Maintainer : andrea.rossato@unitn.it+-- Stability : stable+-- Portability : portable+--+-- This module exports the AST of the Wayland Message Definition+-- Language.+------------------------------------------------------------------------+module Graphics.Wayland.Scanner.Types where++import Data.Map (Map)+import Data.Set (Set)+import Data.Text (Text)++data HwsConfig = HwsConfig+ { genPrefix :: String+ , hsNameSpace :: String+ , protoRole :: Role+ , protocols :: [FilePath]+ , cbitsPrefix :: FilePath+ , srcPrefix :: FilePath+ } deriving (Show, Read)++data Role = Client | Server deriving (Show, Read, Eq)++type Name = Text++data Protocol = Protocol+ { protoName :: Name+ , protoDesc :: Text+ , interfaces :: [Interface]+ } deriving Show++data Interface = Interface+ { ifaceName :: Name+ , ifaceProtocol :: Name+ , ifaceDesc :: Name+ , ifaceEvents :: [Message]+ , ifaceReqs :: [Message]+ , ifaceEnums :: [EnumDecl]+ , ifaceVersion :: Int+ } deriving Show++data Message = Message+ { msgName :: Name+ , msgDesc :: Text+ , msgArgs :: [Arg]+ , msgSince :: Int+ } deriving Show++data ObjectType+ = Typed Text Name+ | Untyped Text+ deriving (Eq, Show)++data Arg+ = ArgNewId ObjectType+ | ArgObject ObjectType Bool -- Bool is for allow-null+ | ArgValue Text WlType+ | ArgArray Text+ deriving (Eq, Show)++data WlType+ = TInt (Maybe Name) -- possible enum+ | TUint (Maybe Name) -- possible enum+ | TString Bool -- Bool is for allow-null+ | TFixed+ | TFd+ deriving (Eq, Show)++data EnumDecl = EnumDecl+ { enumName :: Name+ , enumDesc :: Text+ , enumBitfield :: Bool+ , enumValues :: [EnumEntry]+ } deriving Show++data EnumEntry = EnumEntry+ { entryName :: Name+ , entryDesc :: Text+ } deriving Show++data EType = EInt | EUint deriving (Eq, Ord, Show)++type EnumMap = Map Name (Set EType)++data SolvedProtocol = SolvedProtocol+ { solvedProtoName :: Name+ , solvedProtoDesc :: Text+ , solvedInterfaces :: [Interface]+ , solvedDependencies :: [Name]+ , solvedEnums :: EnumMap+ } deriving Show++-- | In the Wayland Message Definition Language events are messages+-- sent by the server to the client, while requests are messages sent+-- by the client to the server. From the server|client perspective,+-- and the Haskell implementation, the distinction is between received+-- messaged (managed through callbacks implemented via foreign+-- wrappers) and messages to be sent (implemented via foreign+-- functions). So, events are received messages for a client and sent+-- messages for the server, and vice versa. 'RoleRender' is to encode+-- this distinction when rendering the 'SolvedProtocol'.+data RoleRender = RoleRender+ { rrRole :: Role+ , rrReceiveMsgs :: [Message] -- received messages: Client = events / Server requests+ , rrSendMsgs :: [Message] -- messages to send: Client = requests / Server events+ , rrRequestNameSep :: Text -- "_" / "_send_"+ , rrStructSuf :: Text -- "_listener" / "_interface"+ , rrStructTypeSuf :: Text -- "Listener" / "Interface"+ , rrDefaultCBArgs :: [Text] -- Callback default args+ , rrDefaultSmsgArg :: Text -- Default arg for function sending msgs+ }++-- | A "new_id" is a return type in requests. We retrieve it if needed+-- and remove it from the argument list.+splitArgs :: [Arg] -> (Maybe ObjectType, [Arg])+splitArgs args =+ case [t | ArgNewId t <- args] of+ [] -> (Nothing, args)+ [t] -> (Just t, filter (not . isNewId) args)+ _ -> error "multiple new_id arguments (unexpected in Wayland)"++isNewId :: Arg -> Bool+isNewId (ArgNewId _) = True+isNewId _ = False++notValue :: Arg -> Bool+notValue (ArgValue _ _) = False+notValue _ = True