Wayland hot-replace server?

[Samuel Rødal]

On 03/09/2011 08:48 PM, ext Bill Spitzak wrote:
>
>
> Samuel Rødal wrote:
>> On 03/06/2011 08:41 PM, ext Bill Spitzak wrote:
>>> I think the original poster's idea is exactly what is needed:
>>>
>>> I the compositor crashes or exits, the clients will detect this. It is
>>> then the client's job to find a new compositor and recreate their
>>> state on the new one. Most toolkits store quite enough redundant
>>> information that they should be able to do this, I would suspect the
>>> biggest trick will be to completely forget any ids from the previous
>>> compositor.
>>
>> Most OpenGL applications are written expecting that GPU resources do not
>> suddenly disappear, so I don't know how feasible this would be for an
>> application that uses raw OpenGL. If the application is written against
>> Qt (the toolkit I'm familiar with), it would probably be possible to
>> handle it, unless the application uses Qt's OpenGL abstraction classes,
>> which are basically just thin wrappers above OpenGL functionality
>> (QGLFramebufferObject, QGLShaderProgram, etc).
>
> Under Wayland the compositor is not running the OpenGL that a client
> uses. The client is running their own instance to draw into the images
> that are sent to the compositor. Imagine the client was linked with the
> Mesa library and running on a system that otherwise had zero
> implementation of OpenGL. All clients are work something like that.
>
> Hardware acceleration is done by the OpenGL library figuring out what
> hardware is available to draw the images and using it. Kind of like how
> programs could use floating point coprocessors without talking to a
> "floating point server".
>
> So no resources disappear.
>
> Right? Or am I misunderstanding how Wayland is intended to work?

The Mesa library has a software implementation of OpenGL, but I don't 
think it supports dynamically switching between the software and 
hardware implementations at runtime?

--
Samuel