Jim Gettys <[EMAIL PROTECTED]> wrote: > So far, Andrew is the only one to actually say he's at all interested > in seeing completion of RandR's depth switching. > [...] > So unless people crawl out of the woodwork to say I'm wrong, I plan to > remove/hide the depth switching part of RandR so that we can go mainline > with what we have running today, without exposing us to the danger parts > of the design were broken due to lack of implementation experience.
I thought about responding earlier with some ideas about how PseudoColor emulation on a DirectColor display might not be too hard to implement, but stopped when I came to a problem that can't easily be resolved in the server or Xlib. The problem is that if the programmer assumed that displays would always be 8-bit PseudoColor, then there's a pretty good chance that the program does too -- that it simply uses the default Visual, and *assumes* it is an 8-bit PseudoColor Visual. I know the old "quake" game did that. But there's no good way for the server or Xlib to know that when some applications ask for the default Visual, they really want a PseudoColor Visual. I think the best way to handle this would be to put the PseudoColor emulation code into something like Xnest -- a server which merely passes the requests on to a real X server after translating the colors. The legacy applications would run on the Xnest-like display, while modern applications talk directly to the real X server. Alternatives: Implement a separate version of Xlib which does the Pseudocolor translation, and then force legacy applications to use this version by setting the LD_PRELOAD environment variable. Or implement it in the normal Xlib, but only activate the code translation for a specific screen, or only when a special environment variable is set. Neither of these sounds ideal, though, because there's an above-average chance that the legacy application isn't running on the same workstation as the XFree86 server. (Legacy software often runs on legacy hardware.) Library-based solutions wouldn't help in that situation. Maintaining color tables should be fairly simple. When a shared (read-only) color is allocated, no existing windows will need to be updated since the new color presumably hasn't been used yet. When a private (read/write) color cell is altered, any windows which use that Colormap should be sent an Expose event, so they can be redrawn with the new color. So leave depth changes out of RandR. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
