On Monday 03 March 2003 10:37 pm, Danny Tholen wrote: > Loki's Kohan runs only in 1024x768, but I hate using my desktop in that > resolution (low refresh, small fonts). Switching during session would be > nice. And certainly easier compared to starting a new xserver.
Hmm... some of you will probably rate this offtopic, but if you don't drop seeds you'll never get trees... Sun have this really cool feature for their SunRay and similar workstations which allows you to log in to any random terminal with a card; when you pull out your card your session is either suspended or shovelled into /dev/null; when you plug in elsewhere it comes back up again. To do this, the apps must be able to cope with different kinds of screens (resolution and colour depth at least) and changing those on the fly. But as you've exemplified here, not all apps will co-operate. One possible solution is to use XNest, and run the offending app in a `screen size' that it likes, but XNest (even a `rootless XNest!') isn't quite what I have in mind. Xv also provides a useful facility, a not-quite-bitbucket X server, but this is also not what I'm seeking. Think `screen' for X. What I want is an interface layer which sits between the apps and the real X server (or perhaps between the WM and the real server would be better), and in normal circumstances does nothing, uses little or no resources (e.g., calls are vectored straight through to the real server untouched). If you pulled the card from your screen, logged out, or whatever (maybe the ssh tunnel fails), the interface layer would take charge and either SIGSTOP the processes attached through it, route the outbound traffic to /dev/null and fake the inbound traffic, route the traffic to an Xv-like or some combination of the above. When you plugged in again, logged in again, rebuilt your VPN or whatever, you would be able to attach (even at a different screen rez or depth) your existing session and do a refresh. Apps which didn't indicate an ability to handle an environment different to the one they started in would be emulated (e.g. scaled to fit on a smaller or larger screen, run through an XNest-like emulator for differing screen depths. I'm not sure that this would work at all well for OpenGL apps, but OTOH they should in theory be able cope with scaling issues (a change in the surface they're rendering to) much more seamlessly than an app which knows so much more about X directly. The ability to invoke virtual magic on a per-app basis would be very nice (e.g. scale Tower Topler window contents 2x2 or 3x3 on this 2000x1600 screen so I can actually see what's happening, crush down the huge linuxconf intro panel so I can see it all on an 800x600 screen). RandR-type resizing/redepthing would be handled in pretty much the same way as a detach/reattach-at-different-rez. You could `broadcast' an X app or screen with this technology to a bunch of disparate machines for teaching or meeting-style apps, and have most of the depth/size and similar tradeoffs handled the same way that they would be for any other app appearing on each server's desktop. Fitting 2D apps into a proper 3D desktop would be relatively trivial with this technology, you'd just `reattach' the app to an OpenGL surface. Now... is there anything around which does all/most of this already? Any of the 3D WM's, for example, that virtualise a lot of stuff without much of a performance hit? Cheers; Leon
