Current support and roadmap for discrete graphics card hot switching

[Glynn Clements]

William Tracy wrote:

> > I think a user logout->login, which at least in Ubuntu corresponds to a gdm
> > restart nowadays, is a much
> > leaner option than a cold reboot of the system. You only lose the opened
> > windows,
> > but all services like connection to internet, etc, are kept alive, so it's
> > better than a reboot.
> 
> Just thinking out loud here: If desktop session management were good
> enough, even open windows could be "persisted".
> 
> Even better would be if there were a mechanism to transparently
> disconnect an app from one X session, wait for X to restart, and then
> attach it to the new session. Probably doable at the toolkit level,
> but that doesn't help with all the zillions of apps written against
> legacy toolkits.
> 
> Random idea: There are already several special-purpose X servers that
> run on top of Xorg supporting special magic like hardware compositing.
> What if there were a server that could dynamically dispatch to/from
> different Xorg instances? It would notice when Xorg dies, and stop
> sending it events. When a new Xorg launches, it would send a series of
> "new window" commands, and attach all of its clients to those windows.
> 
> Right now I'm assuming that both cards would support equivalent
> resolutions and color depths. If not, then never mind. :-P

The problem is that, in order to operate without explicit support from
application code, both cards would need to support equivalent
*everything*.

A solution which relies upon the toolkit to do everything will only
work for applications where ... the toolkit does everything, i.e. 
those whose interaction with X is limited to creating stock widgets
using parameters which don't depend upon any hardware-dependent
parameters.

If the application queries the bit depth, or the pixel format, or the
maximum size of a texture, or the maximum depth of the matrix stack,
or any of a zillion other hardware-related parameters, you need to
either:

1. add a mechanism to indicate that the parameter has changed, and
ensure that applications allow for such changes, or

2. expose an interface which either the toolkit or the X server can
emulate in its entirety atop a dumb framebuffer, and eat the
(potentially huge) performance hit when it has to do so.

-- 
Glynn Clements <glynn at gclements.plus.com>