Wayland hot-replace server?

[Bill Spitzak]

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?