Remove the wl_visual interface

The visual interface was meant to be a generic mechanism for
specifying the content of a buffer.  It goes back to before we had the
buffer factory interfaces (like wl_drm and wl_shm) and we wanted to
keep it open-ended enough that yuv, png or even svg buffer or so would
be possible.

Now that we have the buffer abstraction, we can add different buffer
types by introducing new interfaces that create buffers.  It only
makes sense to leave it to those interfaces to specify the contents of
the buffers.

For wl_shm, this means that we now just specify the pixel format using
an enum.  For EGL buffers, the exact pixel formats are controlled by
the implementation (part of wl_drm and similar), and from the client
point of view, everything is controlled using EGLConfigs.
This commit is contained in:
Kristian Høgsberg 2011-08-30 21:26:19 -04:00
parent f9c8a691b2
commit c640571c00
5 changed files with 50 additions and 88 deletions

View file

@ -93,32 +93,27 @@
<request name="create_surface">
<arg name="id" type="new_id" interface="wl_surface"/>
</request>
<enum name="visual">
<entry name="argb32" value="0"/>
<entry name="premultiplied_argb32" value="1"/>
<entry name="xrgb32" value="2"/>
</enum>
<event name="token_visual">
<arg name="name" type="uint"/>
<arg name="token" type="uint"/>
</event>
</interface>
<!-- Shared memory support -->
<interface name="wl_shm" version="1">
<enum name="error">
<entry name="invalid_visual" value="0"/>
<entry name="invalid_format" value="0"/>
<entry name="invalid_stride" value="1"/>
<entry name="invalid_fd" value="2"/>
</enum>
<enum name="format">
<entry name="argb32" value="0"/>
<entry name="premultiplied_argb32" value="1"/>
<entry name="xrgb32" value="2"/>
</enum>
<!-- Transfer a shm buffer to the server. The allocated buffer
would include at least stride * height bytes starting at the
beginning of fd. The file descriptor is transferred over the
socket using AF_UNIX magical features. width, height, stride
and visual describe the respective properties of the pixel
and format describe the respective properties of the pixel
data contained in the buffer. -->
<request name="create_buffer">
<arg name="id" type="new_id" interface="wl_buffer"/>
@ -126,8 +121,12 @@
<arg name="width" type="int"/>
<arg name="height" type="int"/>
<arg name="stride" type="uint"/>
<arg name="visual" type="object" interface="wl_visual"/>
<arg name="format" type="uint"/>
</request>
<event name="format">
<arg name="format" type="uint"/>
</event>
</interface>
@ -547,10 +546,4 @@
</event>
</interface>
<!-- A visual is the pixel format. The different visuals are
currently only identified by the order they are advertised by
the 'global' events. We need something better. -->
<interface name="wl_visual" version="1"/>
</protocol>