Keith Packard writes: > Around 10 o'clock on Jan 13, Egbert Eich wrote: > > > To make RandR rotation work one needs layer support. I have a > > sample implementaion (it takes two lines per driver) however > > this is too experimental to bee added to 4.3 I'm afraid. > > I have done a more complete investigation in September and decided that the > changes needed were significantly more extensive than could be reasonably > accomplished in the timeframe available. > > As resize presents the largest application visible effect from the > extension, and also significant value for existing users, I thought > providing just resize was of enough benefit that it should be included > even if the rotate portion wasn't possible in the current timeframe.
What about rotation? I have added rotation using layer support and it didn't seem to be difficult. I have not spent any thoughts on setups which suport more than a single depth in hardware. They will most likely not work as they presently require cfb code which may not work well with shadow and layer. However this shouldn't be a problem: the driver just doesn't initialize layer if it sets up such a mode. > > Another factor in my thoughts was the work Mark is doing related to 5.0 > driver interfaces; early discussions lead me to believe that rotation in > that environment would be significantly easier and more functional, so it > seemed to me that making significant changes in the 4.x architecture to > support a feature of marginal current utility made less sense than perhaps > waiting for a different driver architecture which would make the task > easier. I neither found the modifications I made difficult nor significant. I fact I was able to add layer support without having to modify any other code. I just made some changes to the ramdac code to allow for HW cursor rotation. This however isn't really necessary as one just needed to disable the HW cursor when rotation is on. > > With the release of tablet PCs that essentially require rotation for their > intended use, I may have to reevaluate this position. I was hoping that > the video chips in use for those devices would support hardware rotation > as some PDA chipsets do, but it doesn't appear to the be case. > > The acer and toshiba tablets use the silicon motion chip which provides > accelerated rotated blts, but not actual rotated frame buffer support. The > accelerated rotated blts are used to make a shadow frame buffer > implementation significantly faster, and I would want any XFree86 RandR > rotation support to take advantage of this. But, I feel that it's far too > late in the 4.3 release process to even consider work of this nature. > I don't know how many chipsets do support rotated blits. However a pure SW implementation would be better than nothing. The delayed framebuffer updates in your shadow code help a lot to give the rotated version a snappy look and feel. It feels by far snappier than what we currently have. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
