The Resize and Rotate extension allows the root window to change size and rotation while the server is running and to switch the hardware among various depths. A preliminary implementation of this extension is included with current XFree86 bits, but only the kdrive-based X servers have ever implemented the necessary server-side pieces (for rotation and resize, but not for depth switching).
Jim Gettys has been busily working on the device-independent and library portions of the Resize and Rotate extension for the last month and has completed it, and we're both hoping to get a chance to plug the necessary hooks into the regular XFree86 server to support resize immediately. A question has arisen recently and we're hoping for some outside comments, given the passage of time and somewhat unanticipated advances in modern toolkits. The current RandR spec takes advantage of the ability for X to advertise multiple visuals on each screen to try and switch the depth of the screen. This is done by having the server advertise all possible visuals and depths in the server at startup time and then having RandR switch which visuals are "accelerated" and which were presumably emulated in software. The idea was to make sure that existing application would still be usable while the screen depth was switched -- emulating the desired visual with the hardware would leave those "legacy" applications running in an emulated visual while the "smart" applications reconfigured themselves to use one of the currently accelerated visuals. This is the one part of RandR which doesn't currently have a sample implementation, and the the part of RandR which will require the most extensive modifications within the X server. Given that there is no sample implementation of this capability, and that at least Jim and I aren't going to manage to produce one in the immediate future, the question is should we eliminate this part of the RandR specification so that the extension as a whole can demonstrate a complete sample implementation and become a useful standard part of XFree86? Eliminating this feature from RandR would mean that applications migrating from one X screen to another would need to be able to adapt to the available visuals, rather than anticipating that whatever visual currently in use would be available in the target server. As both Gtk+ 2 and Qt provide very abstract rendering interfaces for applications, (and GTK 2.2 supports moving between screens even between dissimilar X servers) this is not a burden for migrating applications written to either of these two toolkits, reducing the urgency of this part of the extension. The burden would fall solely on legacy toolkit applications which want to add migration capabilities (and the number of legacy toolkit applications continue to decline). The other limitation would be that there would be no good way to share typical PC hardware between pseudo color and true color applications. Emulating pseuedo color operations on true color screens remains impractical. Environments left with legacy pseudo-color dependent apps would continue to run X servers in pseudo color mode without access to reasonable true color visuals. We could still perform this emulation in the server, but RandR provided the means to switch acceleration modes so that a large pseudo color app could get reasonable performance while wrecking the display of any simultaneously displayed true color apps. However, without some interest in the community for this feature along with a reasonable commitment to helping with the implementation, it seems more important to get the subset of the specification known to work deployed widely rather than wait an indeterminant time for this final piece of the original design to be completed. Please comment if you have an opinion. Keith Packard XFree86 Core Team Cambridge Research Lab, HPLabs, HP Jim Gettys Cambridge Research Lab, HPLabs, HP _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
