On Fri, Mar 28, 2008 at 5:39 PM, Thomas Vaughan <[EMAIL PROTECTED]> wrote: > On Fri, Mar 28, 2008 at 9:57 AM, Alex Deucher <[EMAIL PROTECTED]> > wrote: > > > > On Fri, Mar 28, 2008 at 9:32 AM, Thomas Vaughan <[EMAIL PROTECTED]> > > wrote: > > > > > > Just to be clear---in case anyone might be confused by my sloppy > > > wording---I rotated clockwise each of the two 1600x1200 LCD panels > > > attached to my docking station. Then I used 'Option "Rotate" > > > "Left"' on each of them. With side-by-side monitors, each in > > > portrait orientation (instead of the usual landscape orientation), > > > my virtual desktop size was then 2400x1600. > > > > accelerated rotation uses textures to rotate the desktop, so the max > > size would be 2048x2048. > > But for rotation of a monitor, one doesn't want to rotate the whole > desktop. One wishes only to rotate for each monitor the portion of the > display that appears on that monitor. In my case, it would seem that I > need two textures, each 1600x1200. >
that would be true if it worked that way :) The way randr 1.2 works is that a single large surface is allocated for the entire desktop and each crtc scans out of a portion of that desktop. For rotation the we use a rotated buffer of the same size. > > Option "AccelMethod" "EXA" > > Thanks! > > > > > On second thought, I'm afraid this won't help as the 3D engine > > > > probably only supports textures up to 2048x2048. > > > > > > Well, that would matter (hopefully) only if I actually wanted to use > > > textures bigger than 2048x2048. Perhaps it would affect me if I > > > wanted to use a big texture for the whole virtual desktop. > > > > When using accelerated rotation with EXA, textures are used so the > > limit applies here. > > Again, I'm not seeing why EXA would need a single texture for the entire > virtual desktop. It would seem to need a texture for each 1600x1200 > monitor. In order to work properly with the DRI, FB layer, XAA, etc. we implemented xrandr using a single large surface. It's not optimal, but with exa and ttm, we'll be able to move to a better implementation eventually. Alex _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
