├── .build.yml ├── .editorconfig ├── Makefile ├── README.md ├── check.sh ├── unstable ├── wlr-data-control-unstable-v1.xml ├── wlr-export-dmabuf-unstable-v1.xml ├── wlr-foreign-toplevel-management-unstable-v1.xml ├── wlr-gamma-control-unstable-v1.xml ├── wlr-input-inhibitor-unstable-v1.xml ├── wlr-layer-shell-unstable-v1.xml ├── wlr-output-management-unstable-v1.xml ├── wlr-output-power-management-unstable-v1.xml ├── wlr-screencopy-unstable-v1.xml └── wlr-virtual-pointer-unstable-v1.xml └── wlr-protocols.pc.in /.build.yml: -------------------------------------------------------------------------------- 1 | image: archlinux 2 | packages: 3 | - wayland 4 | sources: 5 | - https://github.com/swaywm/wlr-protocols 6 | tasks: 7 | - protocols: | 8 | cd wlr-protocols 9 | ./check.sh 10 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | end_of_line = lf 5 | insert_final_newline = true 6 | charset = utf-8 7 | indent_style = tab 8 | indent_size = 4 9 | trim_trailing_whitespace = true 10 | 11 | [*.xml] 12 | indent_style = space 13 | indent_size = 2 14 | tab_width = 8 15 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | PREFIX=/usr 2 | DATADIR=$${datarootdir} 3 | DATAROOTDIR=$${prefix}/share 4 | 5 | unstable_protocols = \ 6 | unstable/wlr-export-dmabuf-unstable-v1.xml \ 7 | unstable/wlr-gamma-control-unstable-v1.xml \ 8 | unstable/wlr-input-inhibitor-unstable-v1.xml \ 9 | unstable/wlr-layer-shell-unstable-v1.xml \ 10 | unstable/wlr-output-power-management-v1.xml \ 11 | unstable/wlr-screencopy-unstable-v1.xml 12 | 13 | check: 14 | ./check.sh 15 | 16 | clean: 17 | rm -f wlr-protocols.pc 18 | 19 | wlr-protocols.pc: wlr-protocols.pc.in 20 | sed \ 21 | -e 's:@prefix@:$(PREFIX):g' \ 22 | -e 's:@datadir@:$(DATADIR):g' \ 23 | -e 's:@datarootdir@:$(DATAROOTDIR):g' \ 24 | <$< >$@ 25 | 26 | install-unstable: $(unstable_protocols) 27 | mkdir -p $(DESTDIR)$(PREFIX)/share/wlr-protocols/unstable 28 | for protocol in $^ ; \ 29 | do \ 30 | install -Dm644 $$protocol \ 31 | $(DESTDIR)$(PREFIX)/share/wlr-protocols/$$protocol ; \ 32 | done 33 | 34 | install-pc: wlr-protocols.pc 35 | mkdir -p $(DESTDIR)$(PREFIX)/share/pkgconfig/ 36 | install -Dm644 wlr-protocols.pc \ 37 | $(DESTDIR)$(PREFIX)/share/pkgconfig/wlr-protocols.pc 38 | 39 | install: install-unstable install-pc 40 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # wlr-protocols 2 | 3 | Wayland protocols designed for use in wlroots (and other compositors). 4 | 5 | > ### ⚠️ Migrated to gitlab.freedesktop.org 6 | > 7 | > This project [has moved to gitlab.freedesktop.org](https://gitlab.freedesktop.org/wlroots/wlr-protocols). 8 | 9 | ## Submitting changes to existing protocols 10 | 11 | Please submit a pull request on GitHub. 12 | 13 | ## Submitting new protocols 14 | 15 | New protocols should not be submitted to wlr-protocols. Instead, submit them to 16 | [wayland-protocols]. 17 | 18 | [wayland-protocols]: https://gitlab.freedesktop.org/wayland/wayland-protocols 19 | -------------------------------------------------------------------------------- /check.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh -eux 2 | 3 | for f in $(echo unstable/*.xml) 4 | do 5 | wayland-scanner -s client-header "$f" /dev/null 6 | wayland-scanner -s server-header "$f" /dev/null 7 | wayland-scanner -s public-code "$f" /dev/null 8 | wayland-scanner -s private-code "$f" /dev/null 9 | done 10 | -------------------------------------------------------------------------------- /unstable/wlr-data-control-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2018 Simon Ser 5 | Copyright © 2019 Ivan Molodetskikh 6 | 7 | Permission to use, copy, modify, distribute, and sell this 8 | software and its documentation for any purpose is hereby granted 9 | without fee, provided that the above copyright notice appear in 10 | all copies and that both that copyright notice and this permission 11 | notice appear in supporting documentation, and that the name of 12 | the copyright holders not be used in advertising or publicity 13 | pertaining to distribution of the software without specific, 14 | written prior permission. The copyright holders make no 15 | representations about the suitability of this software for any 16 | purpose. It is provided "as is" without express or implied 17 | warranty. 18 | 19 | THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 20 | SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND 21 | FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY 22 | SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 23 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 24 | AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 25 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 26 | THIS SOFTWARE. 27 | 28 | 29 | 30 | This protocol allows a privileged client to control data devices. In 31 | particular, the client will be able to manage the current selection and take 32 | the role of a clipboard manager. 33 | 34 | Warning! The protocol described in this file is experimental and 35 | backward incompatible changes may be made. Backward compatible changes 36 | may be added together with the corresponding interface version bump. 37 | Backward incompatible changes are done by bumping the version number in 38 | the protocol and interface names and resetting the interface version. 39 | Once the protocol is to be declared stable, the 'z' prefix and the 40 | version number in the protocol and interface names are removed and the 41 | interface version number is reset. 42 | 43 | 44 | 45 | 46 | This interface is a manager that allows creating per-seat data device 47 | controls. 48 | 49 | 50 | 51 | 52 | Create a new data source. 53 | 54 | 56 | 57 | 58 | 59 | 60 | Create a data device that can be used to manage a seat's selection. 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | All objects created by the manager will still remain valid, until their 69 | appropriate destroy request has been called. 70 | 71 | 72 | 73 | 74 | 75 | 76 | This interface allows a client to manage a seat's selection. 77 | 78 | When the seat is destroyed, this object becomes inert. 79 | 80 | 81 | 82 | 83 | This request asks the compositor to set the selection to the data from 84 | the source on behalf of the client. 85 | 86 | The given source may not be used in any further set_selection or 87 | set_primary_selection requests. Attempting to use a previously used 88 | source is a protocol error. 89 | 90 | To unset the selection, set the source to NULL. 91 | 92 | 94 | 95 | 96 | 97 | 98 | Destroys the data device object. 99 | 100 | 101 | 102 | 103 | 104 | The data_offer event introduces a new wlr_data_control_offer object, 105 | which will subsequently be used in either the 106 | wlr_data_control_device.selection event (for the regular clipboard 107 | selections) or the wlr_data_control_device.primary_selection event (for 108 | the primary clipboard selections). Immediately following the 109 | wlr_data_control_device.data_offer event, the new data_offer object 110 | will send out wlr_data_control_offer.offer events to describe the MIME 111 | types it offers. 112 | 113 | 114 | 115 | 116 | 117 | 118 | The selection event is sent out to notify the client of a new 119 | wlr_data_control_offer for the selection for this device. The 120 | wlr_data_control_device.data_offer and the wlr_data_control_offer.offer 121 | events are sent out immediately before this event to introduce the data 122 | offer object. The selection event is sent to a client when a new 123 | selection is set. The wlr_data_control_offer is valid until a new 124 | wlr_data_control_offer or NULL is received. The client must destroy the 125 | previous selection wlr_data_control_offer, if any, upon receiving this 126 | event. 127 | 128 | The first selection event is sent upon binding the 129 | wlr_data_control_device object. 130 | 131 | 133 | 134 | 135 | 136 | 137 | This data control object is no longer valid and should be destroyed by 138 | the client. 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | The primary_selection event is sent out to notify the client of a new 147 | wlr_data_control_offer for the primary selection for this device. The 148 | wlr_data_control_device.data_offer and the wlr_data_control_offer.offer 149 | events are sent out immediately before this event to introduce the data 150 | offer object. The primary_selection event is sent to a client when a 151 | new primary selection is set. The wlr_data_control_offer is valid until 152 | a new wlr_data_control_offer or NULL is received. The client must 153 | destroy the previous primary selection wlr_data_control_offer, if any, 154 | upon receiving this event. 155 | 156 | If the compositor supports primary selection, the first 157 | primary_selection event is sent upon binding the 158 | wlr_data_control_device object. 159 | 160 | 162 | 163 | 164 | 165 | 166 | This request asks the compositor to set the primary selection to the 167 | data from the source on behalf of the client. 168 | 169 | The given source may not be used in any further set_selection or 170 | set_primary_selection requests. Attempting to use a previously used 171 | source is a protocol error. 172 | 173 | To unset the primary selection, set the source to NULL. 174 | 175 | The compositor will ignore this request if it does not support primary 176 | selection. 177 | 178 | 180 | 181 | 182 | 183 | 185 | 186 | 187 | 188 | 189 | 190 | The wlr_data_control_source object is the source side of a 191 | wlr_data_control_offer. It is created by the source client in a data 192 | transfer and provides a way to describe the offered data and a way to 193 | respond to requests to transfer the data. 194 | 195 | 196 | 197 | 199 | 200 | 201 | 202 | 203 | This request adds a MIME type to the set of MIME types advertised to 204 | targets. Can be called several times to offer multiple types. 205 | 206 | Calling this after wlr_data_control_device.set_selection is a protocol 207 | error. 208 | 209 | 211 | 212 | 213 | 214 | 215 | Destroys the data source object. 216 | 217 | 218 | 219 | 220 | 221 | Request for data from the client. Send the data as the specified MIME 222 | type over the passed file descriptor, then close it. 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | This data source is no longer valid. The data source has been replaced 231 | by another data source. 232 | 233 | The client should clean up and destroy this data source. 234 | 235 | 236 | 237 | 238 | 239 | 240 | A wlr_data_control_offer represents a piece of data offered for transfer 241 | by another client (the source client). The offer describes the different 242 | MIME types that the data can be converted to and provides the mechanism 243 | for transferring the data directly from the source client. 244 | 245 | 246 | 247 | 248 | To transfer the offered data, the client issues this request and 249 | indicates the MIME type it wants to receive. The transfer happens 250 | through the passed file descriptor (typically created with the pipe 251 | system call). The source client writes the data in the MIME type 252 | representation requested and then closes the file descriptor. 253 | 254 | The receiving client reads from the read end of the pipe until EOF and 255 | then closes its end, at which point the transfer is complete. 256 | 257 | This request may happen multiple times for different MIME types. 258 | 259 | 261 | 262 | 263 | 264 | 265 | 266 | Destroys the data offer object. 267 | 268 | 269 | 270 | 271 | 272 | Sent immediately after creating the wlr_data_control_offer object. 273 | One event per offered MIME type. 274 | 275 | 276 | 277 | 278 | 279 | -------------------------------------------------------------------------------- /unstable/wlr-export-dmabuf-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2018 Rostislav Pehlivanov 5 | 6 | Permission is hereby granted, free of charge, to any person obtaining a 7 | copy of this software and associated documentation files (the "Software"), 8 | to deal in the Software without restriction, including without limitation 9 | the rights to use, copy, modify, merge, publish, distribute, sublicense, 10 | and/or sell copies of the Software, and to permit persons to whom the 11 | Software is furnished to do so, subject to the following conditions: 12 | 13 | The above copyright notice and this permission notice (including the next 14 | paragraph) shall be included in all copies or substantial portions of the 15 | Software. 16 | 17 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 18 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 19 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 20 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 21 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 22 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 23 | DEALINGS IN THE SOFTWARE. 24 | 25 | 26 | 27 | An interface to capture surfaces in an efficient way by exporting DMA-BUFs. 28 | 29 | Warning! The protocol described in this file is experimental and 30 | backward incompatible changes may be made. Backward compatible changes 31 | may be added together with the corresponding interface version bump. 32 | Backward incompatible changes are done by bumping the version number in 33 | the protocol and interface names and resetting the interface version. 34 | Once the protocol is to be declared stable, the 'z' prefix and the 35 | version number in the protocol and interface names are removed and the 36 | interface version number is reset. 37 | 38 | 39 | 40 | 41 | This object is a manager with which to start capturing from sources. 42 | 43 | 44 | 45 | 46 | Capture the next frame of an entire output. 47 | 48 | 49 | 51 | 52 | 53 | 54 | 55 | 56 | All objects created by the manager will still remain valid, until their 57 | appropriate destroy request has been called. 58 | 59 | 60 | 61 | 62 | 63 | 64 | This object represents a single DMA-BUF frame. 65 | 66 | If the capture is successful, the compositor will first send a "frame" 67 | event, followed by one or several "object". When the frame is available 68 | for readout, the "ready" event is sent. 69 | 70 | If the capture failed, the "cancel" event is sent. This can happen anytime 71 | before the "ready" event. 72 | 73 | Once either a "ready" or a "cancel" event is received, the client should 74 | destroy the frame. Once an "object" event is received, the client is 75 | responsible for closing the associated file descriptor. 76 | 77 | All frames are read-only and may not be written into or altered. 78 | 79 | 80 | 81 | 82 | Special flags that should be respected by the client. 83 | 84 | 86 | 87 | 88 | 89 | 90 | Main event supplying the client with information about the frame. If the 91 | capture didn't fail, this event is always emitted first before any other 92 | events. 93 | 94 | This event is followed by a number of "object" as specified by the 95 | "num_objects" argument. 96 | 97 | 99 | 101 | 103 | 105 | 108 | 110 | 112 | 114 | 116 | 118 | 119 | 120 | 121 | 122 | Event which serves to supply the client with the file descriptors 123 | containing the data for each object. 124 | 125 | After receiving this event, the client must always close the file 126 | descriptor as soon as they're done with it and even if the frame fails. 127 | 128 | 130 | 132 | 134 | 136 | 138 | 140 | 141 | 142 | 143 | 144 | This event is sent as soon as the frame is presented, indicating it is 145 | available for reading. This event includes the time at which 146 | presentation happened at. 147 | 148 | The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples, 149 | each component being an unsigned 32-bit value. Whole seconds are in 150 | tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo, 151 | and the additional fractional part in tv_nsec as nanoseconds. Hence, 152 | for valid timestamps tv_nsec must be in [0, 999999999]. The seconds part 153 | may have an arbitrary offset at start. 154 | 155 | After receiving this event, the client should destroy this object. 156 | 157 | 159 | 161 | 163 | 164 | 165 | 166 | 167 | Indicates reason for cancelling the frame. 168 | 169 | 171 | 173 | 175 | 176 | 177 | 178 | 179 | If the capture failed or if the frame is no longer valid after the 180 | "frame" event has been emitted, this event will be used to inform the 181 | client to scrap the frame. 182 | 183 | If the failure is temporary, the client may capture again the same 184 | source. If the failure is permanent, any further attempts to capture the 185 | same source will fail again. 186 | 187 | After receiving this event, the client should destroy this object. 188 | 189 | 191 | 192 | 193 | 194 | 195 | Unreferences the frame. This request must be called as soon as its no 196 | longer used. 197 | 198 | It can be called at any time by the client. The client will still have 199 | to close any FDs it has been given. 200 | 201 | 202 | 203 | 204 | -------------------------------------------------------------------------------- /unstable/wlr-foreign-toplevel-management-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2018 Ilia Bozhinov 5 | 6 | Permission to use, copy, modify, distribute, and sell this 7 | software and its documentation for any purpose is hereby granted 8 | without fee, provided that the above copyright notice appear in 9 | all copies and that both that copyright notice and this permission 10 | notice appear in supporting documentation, and that the name of 11 | the copyright holders not be used in advertising or publicity 12 | pertaining to distribution of the software without specific, 13 | written prior permission. The copyright holders make no 14 | representations about the suitability of this software for any 15 | purpose. It is provided "as is" without express or implied 16 | warranty. 17 | 18 | THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 19 | SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND 20 | FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY 21 | SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 22 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 23 | AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 24 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 25 | THIS SOFTWARE. 26 | 27 | 28 | 29 | 30 | The purpose of this protocol is to enable the creation of taskbars 31 | and docks by providing them with a list of opened applications and 32 | letting them request certain actions on them, like maximizing, etc. 33 | 34 | After a client binds the zwlr_foreign_toplevel_manager_v1, each opened 35 | toplevel window will be sent via the toplevel event 36 | 37 | 38 | 39 | 40 | This event is emitted whenever a new toplevel window is created. It 41 | is emitted for all toplevels, regardless of the app that has created 42 | them. 43 | 44 | All initial details of the toplevel(title, app_id, states, etc.) will 45 | be sent immediately after this event via the corresponding events in 46 | zwlr_foreign_toplevel_handle_v1. 47 | 48 | 49 | 50 | 51 | 52 | 53 | Indicates the client no longer wishes to receive events for new toplevels. 54 | However the compositor may emit further toplevel_created events, until 55 | the finished event is emitted. 56 | 57 | The client must not send any more requests after this one. 58 | 59 | 60 | 61 | 62 | 63 | This event indicates that the compositor is done sending events to the 64 | zwlr_foreign_toplevel_manager_v1. The server will destroy the object 65 | immediately after sending this request, so it will become invalid and 66 | the client should free any resources associated with it. 67 | 68 | 69 | 70 | 71 | 72 | 73 | A zwlr_foreign_toplevel_handle_v1 object represents an opened toplevel 74 | window. Each app may have multiple opened toplevels. 75 | 76 | Each toplevel has a list of outputs it is visible on, conveyed to the 77 | client with the output_enter and output_leave events. 78 | 79 | 80 | 81 | 82 | This event is emitted whenever the title of the toplevel changes. 83 | 84 | 85 | 86 | 87 | 88 | 89 | This event is emitted whenever the app-id of the toplevel changes. 90 | 91 | 92 | 93 | 94 | 95 | 96 | This event is emitted whenever the toplevel becomes visible on 97 | the given output. A toplevel may be visible on multiple outputs. 98 | 99 | 100 | 101 | 102 | 103 | 104 | This event is emitted whenever the toplevel stops being visible on 105 | the given output. It is guaranteed that an entered-output event 106 | with the same output has been emitted before this event. 107 | 108 | 109 | 110 | 111 | 112 | 113 | Requests that the toplevel be maximized. If the maximized state actually 114 | changes, this will be indicated by the state event. 115 | 116 | 117 | 118 | 119 | 120 | Requests that the toplevel be unmaximized. If the maximized state actually 121 | changes, this will be indicated by the state event. 122 | 123 | 124 | 125 | 126 | 127 | Requests that the toplevel be minimized. If the minimized state actually 128 | changes, this will be indicated by the state event. 129 | 130 | 131 | 132 | 133 | 134 | Requests that the toplevel be unminimized. If the minimized state actually 135 | changes, this will be indicated by the state event. 136 | 137 | 138 | 139 | 140 | 141 | Request that this toplevel be activated on the given seat. 142 | There is no guarantee the toplevel will be actually activated. 143 | 144 | 145 | 146 | 147 | 148 | 149 | The different states that a toplevel can have. These have the same meaning 150 | as the states with the same names defined in xdg-toplevel 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | This event is emitted immediately after the zlw_foreign_toplevel_handle_v1 162 | is created and each time the toplevel state changes, either because of a 163 | compositor action or because of a request in this protocol. 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | This event is sent after all changes in the toplevel state have been 172 | sent. 173 | 174 | This allows changes to the zwlr_foreign_toplevel_handle_v1 properties 175 | to be seen as atomic, even if they happen via multiple events. 176 | 177 | 178 | 179 | 180 | 181 | Send a request to the toplevel to close itself. The compositor would 182 | typically use a shell-specific method to carry out this request, for 183 | example by sending the xdg_toplevel.close event. However, this gives 184 | no guarantees the toplevel will actually be destroyed. If and when 185 | this happens, the zwlr_foreign_toplevel_handle_v1.closed event will 186 | be emitted. 187 | 188 | 189 | 190 | 191 | 192 | The rectangle of the surface specified in this request corresponds to 193 | the place where the app using this protocol represents the given toplevel. 194 | It can be used by the compositor as a hint for some operations, e.g 195 | minimizing. The client is however not required to set this, in which 196 | case the compositor is free to decide some default value. 197 | 198 | If the client specifies more than one rectangle, only the last one is 199 | considered. 200 | 201 | The dimensions are given in surface-local coordinates. 202 | Setting width=height=0 removes the already-set rectangle. 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 215 | 216 | 217 | 218 | 219 | This event means the toplevel has been destroyed. It is guaranteed there 220 | won't be any more events for this zwlr_foreign_toplevel_handle_v1. The 221 | toplevel itself becomes inert so any requests will be ignored except the 222 | destroy request. 223 | 224 | 225 | 226 | 227 | 228 | Destroys the zwlr_foreign_toplevel_handle_v1 object. 229 | 230 | This request should be called either when the client does not want to 231 | use the toplevel anymore or after the closed event to finalize the 232 | destruction of the object. 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | Requests that the toplevel be fullscreened on the given output. If the 241 | fullscreen state and/or the outputs the toplevel is visible on actually 242 | change, this will be indicated by the state and output_enter/leave 243 | events. 244 | 245 | The output parameter is only a hint to the compositor. Also, if output 246 | is NULL, the compositor should decide which output the toplevel will be 247 | fullscreened on, if at all. 248 | 249 | 250 | 251 | 252 | 253 | 254 | Requests that the toplevel be unfullscreened. If the fullscreen state 255 | actually changes, this will be indicated by the state event. 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | This event is emitted whenever the parent of the toplevel changes. 264 | 265 | No event is emitted when the parent handle is destroyed by the client. 266 | 267 | 268 | 269 | 270 | 271 | -------------------------------------------------------------------------------- /unstable/wlr-gamma-control-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2015 Giulio camuffo 5 | Copyright © 2018 Simon Ser 6 | 7 | Permission to use, copy, modify, distribute, and sell this 8 | software and its documentation for any purpose is hereby granted 9 | without fee, provided that the above copyright notice appear in 10 | all copies and that both that copyright notice and this permission 11 | notice appear in supporting documentation, and that the name of 12 | the copyright holders not be used in advertising or publicity 13 | pertaining to distribution of the software without specific, 14 | written prior permission. The copyright holders make no 15 | representations about the suitability of this software for any 16 | purpose. It is provided "as is" without express or implied 17 | warranty. 18 | 19 | THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 20 | SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND 21 | FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY 22 | SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 23 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 24 | AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 25 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 26 | THIS SOFTWARE. 27 | 28 | 29 | 30 | This protocol allows a privileged client to set the gamma tables for 31 | outputs. 32 | 33 | Warning! The protocol described in this file is experimental and 34 | backward incompatible changes may be made. Backward compatible changes 35 | may be added together with the corresponding interface version bump. 36 | Backward incompatible changes are done by bumping the version number in 37 | the protocol and interface names and resetting the interface version. 38 | Once the protocol is to be declared stable, the 'z' prefix and the 39 | version number in the protocol and interface names are removed and the 40 | interface version number is reset. 41 | 42 | 43 | 44 | 45 | This interface is a manager that allows creating per-output gamma 46 | controls. 47 | 48 | 49 | 50 | 51 | Create a gamma control that can be used to adjust gamma tables for the 52 | provided output. 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | All objects created by the manager will still remain valid, until their 61 | appropriate destroy request has been called. 62 | 63 | 64 | 65 | 66 | 67 | 68 | This interface allows a client to adjust gamma tables for a particular 69 | output. 70 | 71 | The client will receive the gamma size, and will then be able to set gamma 72 | tables. At any time the compositor can send a failed event indicating that 73 | this object is no longer valid. 74 | 75 | There can only be at most one gamma control object per output, which 76 | has exclusive access to this particular output. When the gamma control 77 | object is destroyed, the gamma table is restored to its original value. 78 | 79 | 80 | 81 | 82 | Advertise the size of each gamma ramp. 83 | 84 | This event is sent immediately when the gamma control object is created. 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | Set the gamma table. The file descriptor can be memory-mapped to provide 96 | the raw gamma table, which contains successive gamma ramps for the red, 97 | green and blue channels. Each gamma ramp is an array of 16-byte unsigned 98 | integers which has the same length as the gamma size. 99 | 100 | The file descriptor data must have the same length as three times the 101 | gamma size. 102 | 103 | 104 | 105 | 106 | 107 | 108 | This event indicates that the gamma control is no longer valid. This 109 | can happen for a number of reasons, including: 110 | - The output doesn't support gamma tables 111 | - Setting the gamma tables failed 112 | - Another client already has exclusive gamma control for this output 113 | - The compositor has transferred gamma control to another client 114 | 115 | Upon receiving this event, the client should destroy this object. 116 | 117 | 118 | 119 | 120 | 121 | Destroys the gamma control object. If the object is still valid, this 122 | restores the original gamma tables. 123 | 124 | 125 | 126 | 127 | -------------------------------------------------------------------------------- /unstable/wlr-input-inhibitor-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2018 Drew DeVault 5 | 6 | Permission to use, copy, modify, distribute, and sell this 7 | software and its documentation for any purpose is hereby granted 8 | without fee, provided that the above copyright notice appear in 9 | all copies and that both that copyright notice and this permission 10 | notice appear in supporting documentation, and that the name of 11 | the copyright holders not be used in advertising or publicity 12 | pertaining to distribution of the software without specific, 13 | written prior permission. The copyright holders make no 14 | representations about the suitability of this software for any 15 | purpose. It is provided "as is" without express or implied 16 | warranty. 17 | 18 | THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 19 | SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND 20 | FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY 21 | SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 22 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 23 | AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 24 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 25 | THIS SOFTWARE. 26 | 27 | 28 | 29 | 30 | Clients can use this interface to prevent input events from being sent to 31 | any surfaces but its own, which is useful for example in lock screen 32 | software. It is assumed that access to this interface will be locked down 33 | to whitelisted clients by the compositor. 34 | 35 | 36 | 37 | 38 | Activates the input inhibitor. As long as the inhibitor is active, the 39 | compositor will not send input events to other clients. 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | While this resource exists, input to clients other than the owner of the 52 | inhibitor resource will not receive input events. Any client which 53 | previously had focus will receive a leave event and will not be given 54 | focus again. The client that owns this resource will receive all input 55 | events normally. The compositor will also disable all of its own input 56 | processing (such as keyboard shortcuts) while the inhibitor is active. 57 | 58 | The compositor may continue to send input events to selected clients, 59 | such as an on-screen keyboard (via the input-method protocol). 60 | 61 | 62 | 63 | 64 | Destroy the inhibitor and allow other clients to receive input. 65 | 66 | 67 | 68 | 69 | -------------------------------------------------------------------------------- /unstable/wlr-layer-shell-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2017 Drew DeVault 5 | 6 | Permission to use, copy, modify, distribute, and sell this 7 | software and its documentation for any purpose is hereby granted 8 | without fee, provided that the above copyright notice appear in 9 | all copies and that both that copyright notice and this permission 10 | notice appear in supporting documentation, and that the name of 11 | the copyright holders not be used in advertising or publicity 12 | pertaining to distribution of the software without specific, 13 | written prior permission. The copyright holders make no 14 | representations about the suitability of this software for any 15 | purpose. It is provided "as is" without express or implied 16 | warranty. 17 | 18 | THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 19 | SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND 20 | FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY 21 | SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 22 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 23 | AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 24 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 25 | THIS SOFTWARE. 26 | 27 | 28 | 29 | 30 | Clients can use this interface to assign the surface_layer role to 31 | wl_surfaces. Such surfaces are assigned to a "layer" of the output and 32 | rendered with a defined z-depth respective to each other. They may also be 33 | anchored to the edges and corners of a screen and specify input handling 34 | semantics. This interface should be suitable for the implementation of 35 | many desktop shell components, and a broad number of other applications 36 | that interact with the desktop. 37 | 38 | 39 | 40 | 41 | Create a layer surface for an existing surface. This assigns the role of 42 | layer_surface, or raises a protocol error if another role is already 43 | assigned. 44 | 45 | Creating a layer surface from a wl_surface which has a buffer attached 46 | or committed is a client error, and any attempts by a client to attach 47 | or manipulate a buffer prior to the first layer_surface.configure call 48 | must also be treated as errors. 49 | 50 | After creating a layer_surface object and setting it up, the client 51 | must perform an initial commit without any buffer attached. 52 | The compositor will reply with a layer_surface.configure event. 53 | The client must acknowledge it and is then allowed to attach a buffer 54 | to map the surface. 55 | 56 | You may pass NULL for output to allow the compositor to decide which 57 | output to use. Generally this will be the one that the user most 58 | recently interacted with. 59 | 60 | Clients can specify a namespace that defines the purpose of the layer 61 | surface. 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | These values indicate which layers a surface can be rendered in. They 79 | are ordered by z depth, bottom-most first. Traditional shell surfaces 80 | will typically be rendered between the bottom and top layers. 81 | Fullscreen shell surfaces are typically rendered at the top layer. 82 | Multiple surfaces can share a single layer, and ordering within a 83 | single layer is undefined. 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | This request indicates that the client will not use the layer_shell 97 | object any more. Objects that have been created through this instance 98 | are not affected. 99 | 100 | 101 | 102 | 103 | 104 | 105 | An interface that may be implemented by a wl_surface, for surfaces that 106 | are designed to be rendered as a layer of a stacked desktop-like 107 | environment. 108 | 109 | Layer surface state (layer, size, anchor, exclusive zone, 110 | margin, interactivity) is double-buffered, and will be applied at the 111 | time wl_surface.commit of the corresponding wl_surface is called. 112 | 113 | Attaching a null buffer to a layer surface unmaps it. 114 | 115 | Unmapping a layer_surface means that the surface cannot be shown by the 116 | compositor until it is explicitly mapped again. The layer_surface 117 | returns to the state it had right after layer_shell.get_layer_surface. 118 | The client can re-map the surface by performing a commit without any 119 | buffer attached, waiting for a configure event and handling it as usual. 120 | 121 | 122 | 123 | 124 | Sets the size of the surface in surface-local coordinates. The 125 | compositor will display the surface centered with respect to its 126 | anchors. 127 | 128 | If you pass 0 for either value, the compositor will assign it and 129 | inform you of the assignment in the configure event. You must set your 130 | anchor to opposite edges in the dimensions you omit; not doing so is a 131 | protocol error. Both values are 0 by default. 132 | 133 | Size is double-buffered, see wl_surface.commit. 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | Requests that the compositor anchor the surface to the specified edges 142 | and corners. If two orthogonal edges are specified (e.g. 'top' and 143 | 'left'), then the anchor point will be the intersection of the edges 144 | (e.g. the top left corner of the output); otherwise the anchor point 145 | will be centered on that edge, or in the center if none is specified. 146 | 147 | Anchor is double-buffered, see wl_surface.commit. 148 | 149 | 150 | 151 | 152 | 153 | 154 | Requests that the compositor avoids occluding an area with other 155 | surfaces. The compositor's use of this information is 156 | implementation-dependent - do not assume that this region will not 157 | actually be occluded. 158 | 159 | A positive value is only meaningful if the surface is anchored to one 160 | edge or an edge and both perpendicular edges. If the surface is not 161 | anchored, anchored to only two perpendicular edges (a corner), anchored 162 | to only two parallel edges or anchored to all edges, a positive value 163 | will be treated the same as zero. 164 | 165 | A positive zone is the distance from the edge in surface-local 166 | coordinates to consider exclusive. 167 | 168 | Surfaces that do not wish to have an exclusive zone may instead specify 169 | how they should interact with surfaces that do. If set to zero, the 170 | surface indicates that it would like to be moved to avoid occluding 171 | surfaces with a positive exclusive zone. If set to -1, the surface 172 | indicates that it would not like to be moved to accommodate for other 173 | surfaces, and the compositor should extend it all the way to the edges 174 | it is anchored to. 175 | 176 | For example, a panel might set its exclusive zone to 10, so that 177 | maximized shell surfaces are not shown on top of it. A notification 178 | might set its exclusive zone to 0, so that it is moved to avoid 179 | occluding the panel, but shell surfaces are shown underneath it. A 180 | wallpaper or lock screen might set their exclusive zone to -1, so that 181 | they stretch below or over the panel. 182 | 183 | The default value is 0. 184 | 185 | Exclusive zone is double-buffered, see wl_surface.commit. 186 | 187 | 188 | 189 | 190 | 191 | 192 | Requests that the surface be placed some distance away from the anchor 193 | point on the output, in surface-local coordinates. Setting this value 194 | for edges you are not anchored to has no effect. 195 | 196 | The exclusive zone includes the margin. 197 | 198 | Margin is double-buffered, see wl_surface.commit. 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | Types of keyboard interaction possible for layer shell surfaces. The 209 | rationale for this is twofold: (1) some applications are not interested 210 | in keyboard events and not allowing them to be focused can improve the 211 | desktop experience; (2) some applications will want to take exclusive 212 | keyboard focus. 213 | 214 | 215 | 216 | 217 | This value indicates that this surface is not interested in keyboard 218 | events and the compositor should never assign it the keyboard focus. 219 | 220 | This is the default value, set for newly created layer shell surfaces. 221 | 222 | This is useful for e.g. desktop widgets that display information or 223 | only have interaction with non-keyboard input devices. 224 | 225 | 226 | 227 | 228 | Request exclusive keyboard focus if this surface is above the shell surface layer. 229 | 230 | For the top and overlay layers, the seat will always give 231 | exclusive keyboard focus to the top-most layer which has keyboard 232 | interactivity set to exclusive. If this layer contains multiple 233 | surfaces with keyboard interactivity set to exclusive, the compositor 234 | determines the one receiving keyboard events in an implementation- 235 | defined manner. In this case, no guarantee is made when this surface 236 | will receive keyboard focus (if ever). 237 | 238 | For the bottom and background layers, the compositor is allowed to use 239 | normal focus semantics. 240 | 241 | This setting is mainly intended for applications that need to ensure 242 | they receive all keyboard events, such as a lock screen or a password 243 | prompt. 244 | 245 | 246 | 247 | 248 | This requests the compositor to allow this surface to be focused and 249 | unfocused by the user in an implementation-defined manner. The user 250 | should be able to unfocus this surface even regardless of the layer 251 | it is on. 252 | 253 | Typically, the compositor will want to use its normal mechanism to 254 | manage keyboard focus between layer shell surfaces with this setting 255 | and regular toplevels on the desktop layer (e.g. click to focus). 256 | Nevertheless, it is possible for a compositor to require a special 257 | interaction to focus or unfocus layer shell surfaces (e.g. requiring 258 | a click even if focus follows the mouse normally, or providing a 259 | keybinding to switch focus between layers). 260 | 261 | This setting is mainly intended for desktop shell components (e.g. 262 | panels) that allow keyboard interaction. Using this option can allow 263 | implementing a desktop shell that can be fully usable without the 264 | mouse. 265 | 266 | 267 | 268 | 269 | 270 | 271 | Set how keyboard events are delivered to this surface. By default, 272 | layer shell surfaces do not receive keyboard events; this request can 273 | be used to change this. 274 | 275 | This setting is inherited by child surfaces set by the get_popup 276 | request. 277 | 278 | Layer surfaces receive pointer, touch, and tablet events normally. If 279 | you do not want to receive them, set the input region on your surface 280 | to an empty region. 281 | 282 | Keyboard interactivity is double-buffered, see wl_surface.commit. 283 | 284 | 285 | 286 | 287 | 288 | 289 | This assigns an xdg_popup's parent to this layer_surface. This popup 290 | should have been created via xdg_surface::get_popup with the parent set 291 | to NULL, and this request must be invoked before committing the popup's 292 | initial state. 293 | 294 | See the documentation of xdg_popup for more details about what an 295 | xdg_popup is and how it is used. 296 | 297 | 298 | 299 | 300 | 301 | 302 | When a configure event is received, if a client commits the 303 | surface in response to the configure event, then the client 304 | must make an ack_configure request sometime before the commit 305 | request, passing along the serial of the configure event. 306 | 307 | If the client receives multiple configure events before it 308 | can respond to one, it only has to ack the last configure event. 309 | 310 | A client is not required to commit immediately after sending 311 | an ack_configure request - it may even ack_configure several times 312 | before its next surface commit. 313 | 314 | A client may send multiple ack_configure requests before committing, but 315 | only the last request sent before a commit indicates which configure 316 | event the client really is responding to. 317 | 318 | 319 | 320 | 321 | 322 | 323 | This request destroys the layer surface. 324 | 325 | 326 | 327 | 328 | 329 | The configure event asks the client to resize its surface. 330 | 331 | Clients should arrange their surface for the new states, and then send 332 | an ack_configure request with the serial sent in this configure event at 333 | some point before committing the new surface. 334 | 335 | The client is free to dismiss all but the last configure event it 336 | received. 337 | 338 | The width and height arguments specify the size of the window in 339 | surface-local coordinates. 340 | 341 | The size is a hint, in the sense that the client is free to ignore it if 342 | it doesn't resize, pick a smaller size (to satisfy aspect ratio or 343 | resize in steps of NxM pixels). If the client picks a smaller size and 344 | is anchored to two opposite anchors (e.g. 'top' and 'bottom'), the 345 | surface will be centered on this axis. 346 | 347 | If the width or height arguments are zero, it means the client should 348 | decide its own window dimension. 349 | 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | The closed event is sent by the compositor when the surface will no 358 | longer be shown. The output may have been destroyed or the user may 359 | have asked for it to be removed. Further changes to the surface will be 360 | ignored. The client should destroy the resource after receiving this 361 | event, and create a new surface if they so choose. 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | Change the layer that the surface is rendered on. 384 | 385 | Layer is double-buffered, see wl_surface.commit. 386 | 387 | 388 | 389 | 390 | 391 | -------------------------------------------------------------------------------- /unstable/wlr-output-management-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2019 Purism SPC 5 | 6 | Permission to use, copy, modify, distribute, and sell this 7 | software and its documentation for any purpose is hereby granted 8 | without fee, provided that the above copyright notice appear in 9 | all copies and that both that copyright notice and this permission 10 | notice appear in supporting documentation, and that the name of 11 | the copyright holders not be used in advertising or publicity 12 | pertaining to distribution of the software without specific, 13 | written prior permission. The copyright holders make no 14 | representations about the suitability of this software for any 15 | purpose. It is provided "as is" without express or implied 16 | warranty. 17 | 18 | THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 19 | SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND 20 | FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY 21 | SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 22 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 23 | AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 24 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 25 | THIS SOFTWARE. 26 | 27 | 28 | 29 | This protocol exposes interfaces to obtain and modify output device 30 | configuration. 31 | 32 | Warning! The protocol described in this file is experimental and 33 | backward incompatible changes may be made. Backward compatible changes 34 | may be added together with the corresponding interface version bump. 35 | Backward incompatible changes are done by bumping the version number in 36 | the protocol and interface names and resetting the interface version. 37 | Once the protocol is to be declared stable, the 'z' prefix and the 38 | version number in the protocol and interface names are removed and the 39 | interface version number is reset. 40 | 41 | 42 | 43 | 44 | This interface is a manager that allows reading and writing the current 45 | output device configuration. 46 | 47 | Output devices that display pixels (e.g. a physical monitor or a virtual 48 | output in a window) are represented as heads. Heads cannot be created nor 49 | destroyed by the client, but they can be enabled or disabled and their 50 | properties can be changed. Each head may have one or more available modes. 51 | 52 | Whenever a head appears (e.g. a monitor is plugged in), it will be 53 | advertised via the head event. Immediately after the output manager is 54 | bound, all current heads are advertised. 55 | 56 | Whenever a head's properties change, the relevant wlr_output_head events 57 | will be sent. Not all head properties will be sent: only properties that 58 | have changed need to. 59 | 60 | Whenever a head disappears (e.g. a monitor is unplugged), a 61 | wlr_output_head.finished event will be sent. 62 | 63 | After one or more heads appear, change or disappear, the done event will 64 | be sent. It carries a serial which can be used in a create_configuration 65 | request to update heads properties. 66 | 67 | The information obtained from this protocol should only be used for output 68 | configuration purposes. This protocol is not designed to be a generic 69 | output property advertisement protocol for regular clients. Instead, 70 | protocols such as xdg-output should be used. 71 | 72 | 73 | 74 | 75 | This event introduces a new head. This happens whenever a new head 76 | appears (e.g. a monitor is plugged in) or after the output manager is 77 | bound. 78 | 79 | 80 | 81 | 82 | 83 | 84 | This event is sent after all information has been sent after binding to 85 | the output manager object and after any subsequent changes. This applies 86 | to child head and mode objects as well. In other words, this event is 87 | sent whenever a head or mode is created or destroyed and whenever one of 88 | their properties has been changed. Not all state is re-sent each time 89 | the current configuration changes: only the actual changes are sent. 90 | 91 | This allows changes to the output configuration to be seen as atomic, 92 | even if they happen via multiple events. 93 | 94 | A serial is sent to be used in a future create_configuration request. 95 | 96 | 97 | 98 | 99 | 100 | 101 | Create a new output configuration object. This allows to update head 102 | properties. 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | Indicates the client no longer wishes to receive events for output 111 | configuration changes. However the compositor may emit further events, 112 | until the finished event is emitted. 113 | 114 | The client must not send any more requests after this one. 115 | 116 | 117 | 118 | 119 | 120 | This event indicates that the compositor is done sending manager events. 121 | The compositor will destroy the object immediately after sending this 122 | event, so it will become invalid and the client should release any 123 | resources associated with it. 124 | 125 | 126 | 127 | 128 | 129 | 130 | A head is an output device. The difference between a wl_output object and 131 | a head is that heads are advertised even if they are turned off. A head 132 | object only advertises properties and cannot be used directly to change 133 | them. 134 | 135 | A head has some read-only properties: modes, name, description and 136 | physical_size. These cannot be changed by clients. 137 | 138 | Other properties can be updated via a wlr_output_configuration object. 139 | 140 | Properties sent via this interface are applied atomically via the 141 | wlr_output_manager.done event. No guarantees are made regarding the order 142 | in which properties are sent. 143 | 144 | 145 | 146 | 147 | This event describes the head name. 148 | 149 | The naming convention is compositor defined, but limited to alphanumeric 150 | characters and dashes (-). Each name is unique among all wlr_output_head 151 | objects, but if a wlr_output_head object is destroyed the same name may 152 | be reused later. The names will also remain consistent across sessions 153 | with the same hardware and software configuration. 154 | 155 | Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do 156 | not assume that the name is a reflection of an underlying DRM 157 | connector, X11 connection, etc. 158 | 159 | If the compositor implements the xdg-output protocol and this head is 160 | enabled, the xdg_output.name event must report the same name. 161 | 162 | The name event is sent after a wlr_output_head object is created. This 163 | event is only sent once per object, and the name does not change over 164 | the lifetime of the wlr_output_head object. 165 | 166 | 167 | 168 | 169 | 170 | 171 | This event describes a human-readable description of the head. 172 | 173 | The description is a UTF-8 string with no convention defined for its 174 | contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11 175 | output via :1'. However, do not assume that the name is a reflection of 176 | the make, model, serial of the underlying DRM connector or the display 177 | name of the underlying X11 connection, etc. 178 | 179 | If the compositor implements xdg-output and this head is enabled, 180 | the xdg_output.description must report the same description. 181 | 182 | The description event is sent after a wlr_output_head object is created. 183 | This event is only sent once per object, and the description does not 184 | change over the lifetime of the wlr_output_head object. 185 | 186 | 187 | 188 | 189 | 190 | 191 | This event describes the physical size of the head. This event is only 192 | sent if the head has a physical size (e.g. is not a projector or a 193 | virtual device). 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | This event introduces a mode for this head. It is sent once per 202 | supported mode. 203 | 204 | 205 | 206 | 207 | 208 | 209 | This event describes whether the head is enabled. A disabled head is not 210 | mapped to a region of the global compositor space. 211 | 212 | When a head is disabled, some properties (current_mode, position, 213 | transform and scale) are irrelevant. 214 | 215 | 216 | 217 | 218 | 219 | 220 | This event describes the mode currently in use for this head. It is only 221 | sent if the output is enabled. 222 | 223 | 224 | 225 | 226 | 227 | 228 | This events describes the position of the head in the global compositor 229 | space. It is only sent if the output is enabled. 230 | 231 | 233 | 235 | 236 | 237 | 238 | 239 | This event describes the transformation currently applied to the head. 240 | It is only sent if the output is enabled. 241 | 242 | 243 | 244 | 245 | 246 | 247 | This events describes the scale of the head in the global compositor 248 | space. It is only sent if the output is enabled. 249 | 250 | 251 | 252 | 253 | 254 | 255 | The compositor will destroy the object immediately after sending this 256 | event, so it will become invalid and the client should release any 257 | resources associated with it. 258 | 259 | 260 | 261 | 262 | 263 | 264 | This event describes the manufacturer of the head. 265 | 266 | This must report the same make as the wl_output interface does in its 267 | geometry event. 268 | 269 | Together with the model and serial_number events the purpose is to 270 | allow clients to recognize heads from previous sessions and for example 271 | load head-specific configurations back. 272 | 273 | It is not guaranteed this event will be ever sent. A reason for that 274 | can be that the compositor does not have information about the make of 275 | the head or the definition of a make is not sensible in the current 276 | setup, for example in a virtual session. Clients can still try to 277 | identify the head by available information from other events but should 278 | be aware that there is an increased risk of false positives. 279 | 280 | It is not recommended to display the make string in UI to users. For 281 | that the string provided by the description event should be preferred. 282 | 283 | 284 | 285 | 286 | 287 | 288 | This event describes the model of the head. 289 | 290 | This must report the same model as the wl_output interface does in its 291 | geometry event. 292 | 293 | Together with the make and serial_number events the purpose is to 294 | allow clients to recognize heads from previous sessions and for example 295 | load head-specific configurations back. 296 | 297 | It is not guaranteed this event will be ever sent. A reason for that 298 | can be that the compositor does not have information about the model of 299 | the head or the definition of a model is not sensible in the current 300 | setup, for example in a virtual session. Clients can still try to 301 | identify the head by available information from other events but should 302 | be aware that there is an increased risk of false positives. 303 | 304 | It is not recommended to display the model string in UI to users. For 305 | that the string provided by the description event should be preferred. 306 | 307 | 308 | 309 | 310 | 311 | 312 | This event describes the serial number of the head. 313 | 314 | Together with the make and model events the purpose is to allow clients 315 | to recognize heads from previous sessions and for example load head- 316 | specific configurations back. 317 | 318 | It is not guaranteed this event will be ever sent. A reason for that 319 | can be that the compositor does not have information about the serial 320 | number of the head or the definition of a serial number is not sensible 321 | in the current setup. Clients can still try to identify the head by 322 | available information from other events but should be aware that there 323 | is an increased risk of false positives. 324 | 325 | It is not recommended to display the serial_number string in UI to 326 | users. For that the string provided by the description event should be 327 | preferred. 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | This object describes an output mode. 336 | 337 | Some heads don't support output modes, in which case modes won't be 338 | advertised. 339 | 340 | Properties sent via this interface are applied atomically via the 341 | wlr_output_manager.done event. No guarantees are made regarding the order 342 | in which properties are sent. 343 | 344 | 345 | 346 | 347 | This event describes the mode size. The size is given in physical 348 | hardware units of the output device. This is not necessarily the same as 349 | the output size in the global compositor space. For instance, the output 350 | may be scaled or transformed. 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | This event describes the mode's fixed vertical refresh rate. It is only 359 | sent if the mode has a fixed refresh rate. 360 | 361 | 362 | 363 | 364 | 365 | 366 | This event advertises this mode as preferred. 367 | 368 | 369 | 370 | 371 | 372 | The compositor will destroy the object immediately after sending this 373 | event, so it will become invalid and the client should release any 374 | resources associated with it. 375 | 376 | 377 | 378 | 379 | 380 | 381 | This object is used by the client to describe a full output configuration. 382 | 383 | First, the client needs to setup the output configuration. Each head can 384 | be either enabled (and configured) or disabled. It is a protocol error to 385 | send two enable_head or disable_head requests with the same head. It is a 386 | protocol error to omit a head in a configuration. 387 | 388 | Then, the client can apply or test the configuration. The compositor will 389 | then reply with a succeeded, failed or cancelled event. Finally the client 390 | should destroy the configuration object. 391 | 392 | 393 | 394 | 396 | 398 | 400 | 401 | 402 | 403 | 404 | Enable a head. This request creates a head configuration object that can 405 | be used to change the head's properties. 406 | 407 | 409 | 411 | 412 | 413 | 414 | 415 | Disable a head. 416 | 417 | 419 | 420 | 421 | 422 | 423 | Apply the new output configuration. 424 | 425 | In case the configuration is successfully applied, there is no guarantee 426 | that the new output state matches completely the requested 427 | configuration. For instance, a compositor might round the scale if it 428 | doesn't support fractional scaling. 429 | 430 | After this request has been sent, the compositor must respond with an 431 | succeeded, failed or cancelled event. Sending a request that isn't the 432 | destructor is a protocol error. 433 | 434 | 435 | 436 | 437 | 438 | Test the new output configuration. The configuration won't be applied, 439 | but will only be validated. 440 | 441 | Even if the compositor succeeds to test a configuration, applying it may 442 | fail. 443 | 444 | After this request has been sent, the compositor must respond with an 445 | succeeded, failed or cancelled event. Sending a request that isn't the 446 | destructor is a protocol error. 447 | 448 | 449 | 450 | 451 | 452 | Sent after the compositor has successfully applied the changes or 453 | tested them. 454 | 455 | Upon receiving this event, the client should destroy this object. 456 | 457 | If the current configuration has changed, events to describe the changes 458 | will be sent followed by a wlr_output_manager.done event. 459 | 460 | 461 | 462 | 463 | 464 | Sent if the compositor rejects the changes or failed to apply them. The 465 | compositor should revert any changes made by the apply request that 466 | triggered this event. 467 | 468 | Upon receiving this event, the client should destroy this object. 469 | 470 | 471 | 472 | 473 | 474 | Sent if the compositor cancels the configuration because the state of an 475 | output changed and the client has outdated information (e.g. after an 476 | output has been hotplugged). 477 | 478 | The client can create a new configuration with a newer serial and try 479 | again. 480 | 481 | Upon receiving this event, the client should destroy this object. 482 | 483 | 484 | 485 | 486 | 487 | Using this request a client can tell the compositor that it is not going 488 | to use the configuration object anymore. Any changes to the outputs 489 | that have not been applied will be discarded. 490 | 491 | This request also destroys wlr_output_configuration_head objects created 492 | via this object. 493 | 494 | 495 | 496 | 497 | 498 | 499 | This object is used by the client to update a single head's configuration. 500 | 501 | It is a protocol error to set the same property twice. 502 | 503 | 504 | 505 | 506 | 507 | 508 | 509 | 510 | 511 | 512 | 513 | 514 | This request sets the head's mode. 515 | 516 | 517 | 518 | 519 | 520 | 521 | This request assigns a custom mode to the head. The size is given in 522 | physical hardware units of the output device. If set to zero, the 523 | refresh rate is unspecified. 524 | 525 | It is a protocol error to set both a mode and a custom mode. 526 | 527 | 528 | 529 | 530 | 531 | 532 | 533 | 534 | This request sets the head's position in the global compositor space. 535 | 536 | 537 | 538 | 539 | 540 | 541 | 542 | This request sets the head's transform. 543 | 544 | 545 | 546 | 547 | 548 | 549 | This request sets the head's scale. 550 | 551 | 552 | 553 | 554 | 555 | -------------------------------------------------------------------------------- /unstable/wlr-output-power-management-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2019 Purism SPC 5 | 6 | Permission is hereby granted, free of charge, to any person obtaining a 7 | copy of this software and associated documentation files (the "Software"), 8 | to deal in the Software without restriction, including without limitation 9 | the rights to use, copy, modify, merge, publish, distribute, sublicense, 10 | and/or sell copies of the Software, and to permit persons to whom the 11 | Software is furnished to do so, subject to the following conditions: 12 | 13 | The above copyright notice and this permission notice (including the next 14 | paragraph) shall be included in all copies or substantial portions of the 15 | Software. 16 | 17 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 18 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 19 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 20 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 21 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 22 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 23 | DEALINGS IN THE SOFTWARE. 24 | 25 | 26 | 27 | This protocol allows clients to control power management modes 28 | of outputs that are currently part of the compositor space. The 29 | intent is to allow special clients like desktop shells to power 30 | down outputs when the system is idle. 31 | 32 | To modify outputs not currently part of the compositor space see 33 | wlr-output-management. 34 | 35 | Warning! The protocol described in this file is experimental and 36 | backward incompatible changes may be made. Backward compatible changes 37 | may be added together with the corresponding interface version bump. 38 | Backward incompatible changes are done by bumping the version number in 39 | the protocol and interface names and resetting the interface version. 40 | Once the protocol is to be declared stable, the 'z' prefix and the 41 | version number in the protocol and interface names are removed and the 42 | interface version number is reset. 43 | 44 | 45 | 46 | 47 | This interface is a manager that allows creating per-output power 48 | management mode controls. 49 | 50 | 51 | 52 | 53 | Create an output power management mode control that can be used to 54 | adjust the power management mode for a given output. 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | All objects created by the manager will still remain valid, until their 63 | appropriate destroy request has been called. 64 | 65 | 66 | 67 | 68 | 69 | 70 | This object offers requests to set the power management mode of 71 | an output. 72 | 73 | 74 | 75 | 77 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | Set an output's power save mode to the given mode. The mode change 88 | is effective immediately. If the output does not support the given 89 | mode a failed event is sent. 90 | 91 | 92 | 93 | 94 | 95 | 96 | Report the power management mode change of an output. 97 | 98 | The mode event is sent after an output changed its power 99 | management mode. The reason can be a client using set_mode or the 100 | compositor deciding to change an output's mode. 101 | This event is also sent immediately when the object is created 102 | so the client is informed about the current power management mode. 103 | 104 | 106 | 107 | 108 | 109 | 110 | This event indicates that the output power management mode control 111 | is no longer valid. This can happen for a number of reasons, 112 | including: 113 | - The output doesn't support power management 114 | - Another client already has exclusive power management mode control 115 | for this output 116 | - The output disappeared 117 | 118 | Upon receiving this event, the client should destroy this object. 119 | 120 | 121 | 122 | 123 | 124 | Destroys the output power management mode control object. 125 | 126 | 127 | 128 | 129 | -------------------------------------------------------------------------------- /unstable/wlr-screencopy-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2018 Simon Ser 5 | Copyright © 2019 Andri Yngvason 6 | 7 | Permission is hereby granted, free of charge, to any person obtaining a 8 | copy of this software and associated documentation files (the "Software"), 9 | to deal in the Software without restriction, including without limitation 10 | the rights to use, copy, modify, merge, publish, distribute, sublicense, 11 | and/or sell copies of the Software, and to permit persons to whom the 12 | Software is furnished to do so, subject to the following conditions: 13 | 14 | The above copyright notice and this permission notice (including the next 15 | paragraph) shall be included in all copies or substantial portions of the 16 | Software. 17 | 18 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 19 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 20 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 21 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 22 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 23 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 24 | DEALINGS IN THE SOFTWARE. 25 | 26 | 27 | 28 | This protocol allows clients to ask the compositor to copy part of the 29 | screen content to a client buffer. 30 | 31 | Warning! The protocol described in this file is experimental and 32 | backward incompatible changes may be made. Backward compatible changes 33 | may be added together with the corresponding interface version bump. 34 | Backward incompatible changes are done by bumping the version number in 35 | the protocol and interface names and resetting the interface version. 36 | Once the protocol is to be declared stable, the 'z' prefix and the 37 | version number in the protocol and interface names are removed and the 38 | interface version number is reset. 39 | 40 | 41 | 42 | 43 | This object is a manager which offers requests to start capturing from a 44 | source. 45 | 46 | 47 | 48 | 49 | Capture the next frame of an entire output. 50 | 51 | 52 | 54 | 55 | 56 | 57 | 58 | 59 | Capture the next frame of an output's region. 60 | 61 | The region is given in output logical coordinates, see 62 | xdg_output.logical_size. The region will be clipped to the output's 63 | extents. 64 | 65 | 66 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | All objects created by the manager will still remain valid, until their 78 | appropriate destroy request has been called. 79 | 80 | 81 | 82 | 83 | 84 | 85 | This object represents a single frame. 86 | 87 | When created, a series of buffer events will be sent, each representing a 88 | supported buffer type. The "buffer_done" event is sent afterwards to 89 | indicate that all supported buffer types have been enumerated. The client 90 | will then be able to send a "copy" request. If the capture is successful, 91 | the compositor will send a "flags" followed by a "ready" event. 92 | 93 | For objects version 2 or lower, wl_shm buffers are always supported, ie. 94 | the "buffer" event is guaranteed to be sent. 95 | 96 | If the capture failed, the "failed" event is sent. This can happen anytime 97 | before the "ready" event. 98 | 99 | Once either a "ready" or a "failed" event is received, the client should 100 | destroy the frame. 101 | 102 | 103 | 104 | 105 | Provides information about wl_shm buffer parameters that need to be 106 | used for this frame. This event is sent once after the frame is created 107 | if wl_shm buffers are supported. 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | Copy the frame to the supplied buffer. The buffer must have a the 118 | correct size, see zwlr_screencopy_frame_v1.buffer and 119 | zwlr_screencopy_frame_v1.linux_dmabuf. The buffer needs to have a 120 | supported format. 121 | 122 | If the frame is successfully copied, a "flags" and a "ready" events are 123 | sent. Otherwise, a "failed" event is sent. 124 | 125 | 126 | 127 | 128 | 129 | 131 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | Provides flags about the frame. This event is sent once before the 142 | "ready" event. 143 | 144 | 145 | 146 | 147 | 148 | 149 | Called as soon as the frame is copied, indicating it is available 150 | for reading. This event includes the time at which presentation happened 151 | at. 152 | 153 | The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples, 154 | each component being an unsigned 32-bit value. Whole seconds are in 155 | tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo, 156 | and the additional fractional part in tv_nsec as nanoseconds. Hence, 157 | for valid timestamps tv_nsec must be in [0, 999999999]. The seconds part 158 | may have an arbitrary offset at start. 159 | 160 | After receiving this event, the client should destroy the object. 161 | 162 | 164 | 166 | 168 | 169 | 170 | 171 | 172 | This event indicates that the attempted frame copy has failed. 173 | 174 | After receiving this event, the client should destroy the object. 175 | 176 | 177 | 178 | 179 | 180 | Destroys the frame. This request can be sent at any time by the client. 181 | 182 | 183 | 184 | 185 | 186 | 187 | Same as copy, except it waits until there is damage to copy. 188 | 189 | 190 | 191 | 192 | 193 | 194 | This event is sent right before the ready event when copy_with_damage is 195 | requested. It may be generated multiple times for each copy_with_damage 196 | request. 197 | 198 | The arguments describe a box around an area that has changed since the 199 | last copy request that was derived from the current screencopy manager 200 | instance. 201 | 202 | The union of all regions received between the call to copy_with_damage 203 | and a ready event is the total damage since the prior ready event. 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | Provides information about linux-dmabuf buffer parameters that need to 215 | be used for this frame. This event is sent once after the frame is 216 | created if linux-dmabuf buffers are supported. 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | This event is sent once after all buffer events have been sent. 226 | 227 | The client should proceed to create a buffer of one of the supported 228 | types, and send a "copy" request. 229 | 230 | 231 | 232 | 233 | -------------------------------------------------------------------------------- /unstable/wlr-virtual-pointer-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Copyright © 2019 Josef Gajdusek 5 | 6 | Permission is hereby granted, free of charge, to any person obtaining a 7 | copy of this software and associated documentation files (the "Software"), 8 | to deal in the Software without restriction, including without limitation 9 | the rights to use, copy, modify, merge, publish, distribute, sublicense, 10 | and/or sell copies of the Software, and to permit persons to whom the 11 | Software is furnished to do so, subject to the following conditions: 12 | 13 | The above copyright notice and this permission notice (including the next 14 | paragraph) shall be included in all copies or substantial portions of the 15 | Software. 16 | 17 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 18 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 19 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 20 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 21 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 22 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 23 | DEALINGS IN THE SOFTWARE. 24 | 25 | 26 | 27 | 28 | This protocol allows clients to emulate a physical pointer device. The 29 | requests are mostly mirror opposites of those specified in wl_pointer. 30 | 31 | 32 | 33 | 35 | 37 | 38 | 39 | 40 | 41 | The pointer has moved by a relative amount to the previous request. 42 | 43 | Values are in the global compositor space. 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | The pointer has moved in an absolute coordinate frame. 53 | 54 | Value of x can range from 0 to x_extent, value of y can range from 0 55 | to y_extent. 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | A button was pressed or released. 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | Scroll and other axis requests. 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | Indicates the set of events that logically belong together. 85 | 86 | 87 | 88 | 89 | 90 | Source information for scroll and other axis. 91 | 92 | 93 | 94 | 95 | 96 | 97 | Stop notification for scroll and other axes. 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | Discrete step information for scroll and other axes. 106 | 107 | This event allows the client to extend data normally sent using the axis 108 | event with discrete value. 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | This object allows clients to create individual virtual pointer objects. 124 | 125 | 126 | 127 | 128 | Creates a new virtual pointer. The optional seat is a suggestion to the 129 | compositor. 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | Creates a new virtual pointer. The seat and the output arguments are 143 | optional. If the seat argument is set, the compositor should assign the 144 | input device to the requested seat. If the output argument is set, the 145 | compositor should map the input device to the requested output. 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | -------------------------------------------------------------------------------- /wlr-protocols.pc.in: -------------------------------------------------------------------------------- 1 | prefix=@prefix@ 2 | datarootdir=@datarootdir@ 3 | pkgdatadir=${pc_sysrootdir}@datadir@/wlr-protocols 4 | 5 | Name: wlroots Wayland protocols 6 | Description: Wayland protocol files 7 | Version: 1.0 8 | --------------------------------------------------------------------------------