Extent frame event to be surface dependent
[profile/ivi/wayland.git] / protocol / wayland.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2 <protocol name="wayland">
3
4   <!-- The core global object. This is a special singleton object.
5        It is used for internal wayland protocol features. -->
6   <interface name="display" version="1">
7     <!-- sync is an just an echo, which will reply with a sync event.
8          Since requests are handled in-order, this can be used as a
9          barrier to ensure all previous requests have ben handled.
10          The key argument can be used to correlate between multiple
11          sync invocations. -->
12     <request name="sync">
13       <arg name="key" type="uint"/>
14     </request>
15
16     <!-- Request notification when the next frame is displayed.
17          Useful for throttling redrawing operations, and driving
18          animations.  The notification will only be posted for one
19          frame unless requested again. -->
20     <request name="frame">
21       <arg name="surface" type="object" interface="surface"/>
22       <arg name="key" type="uint"/>
23     </request>
24
25     <!-- A request addressed a non-existent object id. This is
26          tyipcally a fatal error. -->
27     <event name="invalid_object">
28       <arg name="object_id" type="uint"/>
29     </event>
30
31     <!-- A request tried to invoke an opcode out of range.  This is
32          typically a fatal error. -->
33     <event name="invalid_method">
34       <arg name="object_id" type="uint"/>
35       <arg name="opcode" type="uint"/>
36     </event>
37
38     <!-- A request has failed due to an out of memory error. -->
39     <event name="no_memory"/>
40
41     <!-- Notify the client of global objects. These are objects that
42          are created by the server. Globals are published on the
43          initial client connection sequence, upon device hotplugs,
44          device disconnects, reconfiguration or other events.  The
45          server will always announce an object before the object sends
46          out events. -->
47     <event name="global">
48       <arg name="id" type="new_id" interface="object"/>
49       <arg name="name" type="string"/>
50       <arg name="version" type="uint"/>
51     </event>
52
53     <!-- Internal, deprecated, and will be changed.  This is an object
54          IDs range that is used by the client to allocate object IDs
55          in "new_id" type arguments.  The server sends range
56          allocations to the client before the next range is about to
57          be depleted. -->
58     <event name="range">
59       <arg name="base" type="uint"/>
60     </event>
61
62     <!-- A reply to the frame or sync request.  The key is the one
63          used in the request.  time is in millisecond units, and
64          denotes the time when the frame was posted on the
65          display. time can be used to estimaate frame rate, determine
66          how much to advance animations and compensate for jitter. -->
67     <event name="key">
68       <arg name="key" type="uint"/>
69       <arg name="time" type="uint"/>
70     </event>
71   </interface>
72
73
74   <!-- A compositor. This object is a global.  The compositor is in
75        charge of combining the contents of multiple surfaces into one
76        displayable output. -->
77   <interface name="compositor" version="1">
78     <!-- Factory request for a surface objects. A surface is akin to a
79          window. -->
80     <request name="create_surface">
81       <arg name="id" type="new_id" interface="surface"/>
82     </request>
83   </interface>
84
85
86   <!-- Shared memory support -->
87   <interface name="shm" version="1">
88     <!-- Transfer a shm buffer to the server.  The allocated buffer
89          would include at least stride * height bytes starting at the
90          beginning of fd.  The file descriptor is transferred over the
91          socket using AF_UNIX magical features. width, height, stride
92          and visual describe the respective properties of the pixel
93          data contained in the buffer. -->
94     <request name="create_buffer">
95       <arg name="id" type="new_id" interface="buffer"/>
96       <arg name="fd" type="fd"/>
97       <arg name="width" type="int"/>
98       <arg name="height" type="int"/>
99       <arg name="stride" type="uint"/>
100       <arg name="visual" type="object" interface="visual"/>
101     </request>
102   </interface>
103
104
105   <!-- A pixel buffer. Created using the drm, shm or similar objects.
106        It has a size, visual and contents, but not a location on the
107        screen -->
108   <interface name="buffer" version="1">
109     <!-- Abandon a buffer.  This will invalidate the object id. -->
110     <request name="destroy" type="destructor"/>
111   </interface>
112
113   <interface name="shell" version="1">
114     <request name="move">
115       <arg name="surface" type="object" interface="surface"/>
116       <arg name="input_device" type="object" interface="input_device"/>
117       <arg name="time" type="uint"/>
118     </request>
119
120     <enum name="resize">
121       <entry name="none" value="0"/>
122       <entry name="top" value="1"/>
123       <entry name="bottom" value="2"/>
124       <entry name="left" value="4"/>
125       <entry name="top_left" value="5"/>
126       <entry name="bottom_left" value="6"/>
127       <entry name="right" value="8"/>
128       <entry name="top_right" value="9"/>
129       <entry name="bottom_right" value="10"/>
130     </enum>
131
132     <request name="resize">
133       <arg name="surface" type="object" interface="surface"/>
134       <arg name="input_device" type="object" interface="input_device"/>
135       <arg name="time" type="uint"/>
136       <!-- edges is an enum, need to get the values in here -->
137       <arg name="edges" type="uint"/>
138     </request>
139
140     <request name="create_drag">
141       <arg name="id" type="new_id" interface="drag"/>
142     </request>
143
144     <request name="create_selection">
145       <arg name="id" type="new_id" interface="selection"/>
146     </request>
147
148     <!-- The configure event asks the client to resize its surface.
149          The size is a hint, in the sense that the client is free to
150          ignore it if it doesn't resize, pick a smaller size (to
151          satisfy aspect ration or resize in steps of NxM pixels).  The
152          client is free to dismiss all but the last configure event it
153          received. -->
154     <event name="configure">
155       <arg name="time" type="uint"/>
156       <arg name="edges" type="uint"/>
157       <arg name="surface" type="object" interface="surface"/>
158       <arg name="width" type="int"/>
159       <arg name="height" type="int"/>
160     </event>
161   </interface>
162
163   <interface name="selection" version="1">
164     <!-- Add an offered mime type.  Can be called several times to
165          offer multiple types, but must be called before 'activate'. -->
166     <request name="offer">
167       <arg name="type" type="string"/>
168     </request>
169
170     <!-- Can the selection be activated for multiple devices? -->
171     <request name="activate">
172       <arg name="input_device" type="object" interface="input_device"/>
173       <arg name="time" type="uint"/>
174     </request>
175
176     <!-- Destroy the selection. -->
177     <request name="destroy" type="destructor"/>
178
179     <!-- Another client pasted the selection, send the mime-type over
180          the passed fd. -->
181     <event name="send">
182       <arg name="mime_type" type="string"/>
183       <arg name="fd" type="fd"/>
184     </event>
185
186     <!-- Another selection became active. -->
187     <event name="cancelled"/>
188   </interface>
189
190   <interface name="selection_offer" version="1">
191     <!-- Called to receive the selection data as the specified type.
192          Sends the pipe fd to the compositor, which forwards it to the
193          source in the 'send' event -->
194     <request name="receive">
195       <arg name="mime_type" type="string"/>
196       <arg name="fd" type="fd"/>
197     </request>
198
199     <!-- Sent before the keyboard_focus event to announce the types
200          offered.  One event per offered mime type.  A mime type of
201          NULL means the selection offer is going away.  -->
202     <event name="offer">
203       <arg name="type" type="string"/>
204     </event>
205
206     <event name="keyboard_focus">
207       <arg name="input_device" type="object" interface="input_device"/>
208     </event>
209   </interface>
210
211   <interface name="drag" version="1">
212     <!-- Add an offered mime type.  Can be called several times to
213          offer multiple types, but must be called before 'activate'. -->
214     <request name="offer">
215       <arg name="type" type="string"/>
216     </request>
217
218     <request name="activate">
219       <arg name="surface" type="object" interface="surface"/>
220       <arg name="input_device" type="object" interface="input_device"/>
221       <arg name="time" type="uint"/>
222     </request>
223
224     <!-- Destroy the drag and cancel the session. -->
225     <request name="destroy" type="destructor"/>
226
227     <!-- Sent when a target accepts pointer_focus or motion events.
228          If a target does not accept any of the offered types, type is
229          NULL -->
230     <event name="target">
231       <arg name="mime_type" type="string"/>
232     </event>
233
234     <!-- Sent when the drag is finished.  The final mime type is that
235          of the last target event.  If that was NULL, no drag target
236          was valid when the drag finished, fd is undefined and the
237          source should not send data.  The event is also sent in case
238          a drag source tries to activate a drag after the grab was
239          released, in which case mime_type will also be NULL. -->
240     <event name="finish">
241       <arg name="fd" type="fd"/>
242     </event>
243
244     <event name="reject"/>
245   </interface>
246
247
248   <interface name="drag_offer" version="1">
249     <!-- Call to accept the offer of the given type -->
250     <request name="accept">
251       <arg name="time" type="uint"/>
252       <arg name="type" type="string"/>
253     </request>
254
255     <!-- Called to initiate the drag finish sequence.  Sends the pipe
256          fd to the compositor, which forwards it to the source in the
257          'finish' event -->
258     <request name="receive">
259       <arg name="fd" type="fd"/>
260     </request>
261
262     <!-- Called to reject a drop  -->
263     <request name="reject"/>
264
265     <!-- Sent before the pointer_focus event to announce the types
266          offered.  One event per offered mime type. -->
267     <event name="offer">
268       <arg name="type" type="string"/>
269     </event>
270
271     <!-- Similar to device::pointer_focus.  Sent to potential target
272          surfaces to offer drag data.  If the device leaves the
273          window, the drag stops or the originator cancels the drag,
274          this event is sent with the NULL surface, at which point the
275          drag object may no longer be valid. -->
276     <event name="pointer_focus">
277       <arg name="time" type="uint"/>
278       <arg name="surface" type="object" interface="surface"/>
279       <arg name="x" type="int"/>
280       <arg name="y" type="int"/>
281       <arg name="surface_x" type="int"/>
282       <arg name="surface_y" type="int"/>
283     </event>
284
285     <!-- Similar to device::motion.  Sent to potential target surfaces
286          as the drag pointer moves around in the surface. -->
287     <event name="motion">
288       <arg name="time" type="uint"/>
289       <arg name="x" type="int"/>
290       <arg name="y" type="int"/>
291       <arg name="surface_x" type="int"/>
292       <arg name="surface_y" type="int"/>
293     </event>
294
295     <!-- Sent to indicate that the drag is finishing.  The last
296          motion/pointer_focus event gives the location of the drop.
297          Target must respond with the 'receive' request, which sends
298          an fd to the source for writing the drag data. -->
299     <event name="drop"/>
300   </interface>
301
302
303   <!-- A surface. This is an image that is displayed on the screen.
304        It has a location, size and pixel contents. Similar to a window. -->
305   <interface name="surface" version="1">
306     <!-- Deletes the surface and invalidates its object id. -->
307     <request name="destroy" type="destructor"/>
308
309     <!-- Copy the contents of a buffer into this surface. The x and y
310          arguments specify the location of the new buffers upper left
311          corner, relative to the old buffers upper left corner. -->
312     <request name="attach">
313       <arg name="buffer" type="object" interface="buffer"/>
314       <arg name="x" type="int"/>
315       <arg name="y" type="int"/>
316     </request>
317
318     <!-- Make the surface visible as a toplevel window. -->
319     <request name="map_toplevel"/>
320
321     <!-- Map the surface relative to an existing surface. The x and y
322          arguments specify the locations of the upper left corner of
323          the surface relative to the upper left corner of the parent
324          surface.  The flags argument controls overflow/clipping
325          behaviour when the surface would intersect a screen edge,
326          panel or such.  And possibly whether the offset only
327          determines the initial position or if the surface is locked
328          to that relative position during moves. -->
329     <request name="map_transient">
330       <arg name="parent" type="object" interface="surface"/>
331       <arg name="x" type="int"/>
332       <arg name="y" type="int"/>
333       <arg name="flags" type="uint"/>
334     </request>
335
336     <!-- Map the surface as a fullscreen surface.  There are a number
337          of options here: on which output? if the surface size doesn't
338          match the output size, do we scale, change resolution, or add
339          black borders? is that something the client controls?  what
340          about transient surfaces, do they float on top of the
341          fullscreen? what if there's already a fullscreen surface on
342          the output, maybe you can only go fullscreen if you're
343          active?  -->
344     <request name="map_fullscreen"/>
345
346     <!-- Notify the server that the attached buffer's contents have
347          changed, and request a redraw. The arguments allow you to
348          damage only a part of the surface, but the server may ignore
349          it and redraw the entire contents of the surface.  To
350          describe a more complicated area of damage, use this request
351          several times. -->
352     <request name="damage">
353       <arg name="x" type="int"/>
354       <arg name="y" type="int"/>
355       <arg name="width" type="int"/>
356       <arg name="height" type="int"/>
357     </request>
358   </interface>
359
360
361   <!-- A group of keyboards and pointer devices (mice, for
362        example). This object is published as a global during start up,
363        or when such a device is hot plugged.  A input_device group
364        typically has a pointer and maintains a keyboard_focus and a
365        pointer_focus.  -->
366   <interface name="input_device" version="1">
367     <!-- Set the pointer's image.  This request only takes effect if
368          the pointer focus for this device is one of the requesting
369          clients surfaces.  -->
370     <request name="attach">
371       <arg name="time" type="uint"/>
372       <arg name="buffer" type="object" interface="buffer"/>
373       <arg name="hotspot_x" type="int"/>
374       <arg name="hotspot_y" type="int"/>
375     </request>
376
377     <!-- Notification of pointer location change.
378          x,y are the absolute location on the screen.
379          surface_[xy] are the location relative to the focused surface. -->
380     <event name="motion">
381       <arg name="time" type="uint"/>
382       <arg name="x" type="int"/>
383       <arg name="y" type="int"/>
384       <arg name="surface_x" type="int"/>
385       <arg name="surface_y" type="int"/>
386     </event>
387
388     <!-- Mouse button click and release notifications.  The location
389          of the click is given by the last motion or pointer_focus
390          event. -->
391     <event name="button">
392       <arg name="time" type="uint"/>
393       <arg name="button" type="uint"/>
394       <arg name="state" type="uint"/>
395     </event>
396
397     <!-- Keyboard press. -->
398     <event name="key">
399       <arg name="time" type="uint"/>
400       <arg name="key" type="uint"/>
401       <arg name="state" type="uint"/>
402     </event>
403
404     <!-- Notification that this input device's pointer is focused on
405          certain surface. When an input_device enters a surface, the
406          pointer image is undefined and a client should respond to
407          this event by setting an apropriate pointer image. -->
408     <event name="pointer_focus">
409       <arg name="time" type="uint"/>
410       <arg name="surface" type="object" interface="surface"/>
411       <arg name="x" type="int"/>
412       <arg name="y" type="int"/>
413       <arg name="surface_x" type="int"/>
414       <arg name="surface_y" type="int"/>
415     </event>
416
417     <event name="keyboard_focus">
418       <arg name="time" type="uint"/>
419       <arg name="surface" type="object" interface="surface"/>
420       <arg name="keys" type="array"/>
421     </event>
422   </interface>
423
424
425   <!-- An output describes part of the compositor geometry.  The
426        compositor work in the 'compositor coordinate system' and an
427        output corresponds to rectangular area in that space that is
428        actually visible.  This typically corresponds to a monitor that
429        displays part of the compositor space.  This object is
430        published as global during start up, or when a screen is hot
431        plugged.  -->
432   <interface name="output" version="1">
433     <!-- Notification about the screen size. -->
434     <event name="geometry">
435       <arg name="x" type="int"/>
436       <arg name="y" type="int"/>
437       <arg name="width" type="int"/>
438       <arg name="height" type="int"/>
439     </event>
440   </interface>
441
442
443   <!-- A visual is the pixel format.  The different visuals are
444        currently only identified by the order they are advertised by
445        the 'global' events.  We need something better.  -->
446   <interface name="visual" version="1"/>
447
448 </protocol>