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 <gl...@gclements.plus.com> _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg