On Fri, Nov 08, 2002 at 05:38:07 -0800, Keith Packard wrote: > I've implemented rotation and reflection support in the core XFree86 > server; it was less invasive than I'd feared and seems to work just fine. > > For most devices, it does it's work by substituting a whole new rendering > mechanism based on the shadow frame buffer when the screen is rotated or > reflected. Right now, this means that video and DRI won't work right if > the screen is rotated; they'll hit the regular frame buffer and mangle > things badly. It also permits drivers to support rotation themselves as > the siliconmotion hardware seems capable of. > > It's possible to provide video support in this rotated world; I've > implemented that for the Mach64 chipset in Tiny-X (mostly because I could), > we could do that for the regular XFree86 servers too with some additional > work. On the other hand, DRI probably won't ever work on a rotated > screen; you'd have to transmit the rotation information to the application > and let them convert transformation matrices and clip lists. That'd be a > real adventure. > > I haven't yet committed the changes to CVS as I'm curious of two things: > > 1) It hooks into some seemingly silly places -- it needs two > initialization steps, one right before acceleration is pushed > on top of fb and another right before the software cursor > is pushed on top of the acceleration. The first is done > by sticking a call inside xf86SetBackingStore, the > second by placing a call inside xf86GetPointerScreenFuncs. > > Those two functions happen to need to be called at precisely the > same moment as the RandR hooks, but are obviously not exactly > semantically intended for this purpose. > > The alternative is to require every driver to add calls to RandR, > which I'll do if people think it's the right think to do. The driver is meant to be in control of everything, so I'd opt for the last option here.
> 2) Permitting rotation incurs an additional layer along several > paths inside the X server -- the usual rendering paths all > need to get redirected when the system switches from hardware to > software rendering, so the screen functions CreateGC, PaintWindow* > and the like all get wrapped by the layer module. > > This new layer is implemented by the 'layer' and 'shadow' modules, > both of which must be loaded when the server starts for rotation > to ever be possible. > > It seems reasonable, therefore, that this dynamic rotation > mechanism should be selectable. Should I add an option to > enable or disable this? Should it be disabled by default? Disabled by default. Alan. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
