[Xpert]Rotated display under Linux?
Hi, Does anybody know of an implementation of X which can run a GNOME or KDE desktop in portrait mode, i.e. rotated 90 degrees under Linux? Specifically, I'm looking for it to work with an Intel 810e adapter chipset, but would be interested to hear of any rotation/transform X developments... Since I'm new to X development, any tips on where to start with rotation under X would naturally be handy! :-) Cheers, Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
On Thu, 6 Dec 2001, Mark Swan wrote: > Hi, > > Does anybody know of an implementation of X which can run a GNOME or KDE > desktop in portrait mode, i.e. rotated 90 degrees under Linux? > Specifically, I'm looking for it to work with an Intel 810e adapter chipset, > but would be interested to hear of any rotation/transform X developments... > Many drivers have Rotate options. Eg, from the "nv" driver man page: Option "Rotate" "CW" Option "Rotate" "CCW" Rotate the display clockwise or counterclockwise. This mode is unaccelerated. Default: no rotation. Last I checked, the i810 didn't support this, however. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
In article <[EMAIL PROTECTED]> Mark wrote: > Many drivers have Rotate options. Eg, from the "nv" driver man >page: > > Option "Rotate" "CW" > > Option "Rotate" "CCW" > Rotate the display clockwise or counterclockwise. > This mode is unaccelerated. Default: no rotation. Coincidentally, I just tried this last night with my TNT2 and XFree86 4.1.0. It didn't work well at all. The hardware cursor seemed pretty badly confused and there were weird dead areas on the screen containing garbage and portions of the root weren't visible no matter how I panned around. Dragging windows caused all sorts of corruption and glitching. -Jeremy. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
On Thu, 6 Dec 2001, Jeremy Sugerman wrote: > In article > <[EMAIL PROTECTED]> Mark wrote: > > Many drivers have Rotate options. Eg, from the "nv" driver man > >page: > > > > Option "Rotate" "CW" > > > > Option "Rotate" "CCW" > > Rotate the display clockwise or counterclockwise. > > This mode is unaccelerated. Default: no rotation. > > Coincidentally, I just tried this last night with my TNT2 and XFree86 4.1.0. > It didn't work well at all. The hardware cursor seemed pretty badly > confused and there were weird dead areas on the screen containing garbage > and portions of the root weren't visible no matter how I panned around. > Dragging windows caused all sorts of corruption and glitching. > Ugh, I haven't tried this stuff in a long time. It looks like somebody broke all of this stuff. I doubt the problems are specific to the "nv" driver. I'll look into it. Sound like nobody has been using it though, since this is the first time I've heard a complaint about it not working. Mark. PS. There is no hardware cursor in that mode. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
> > > Option "Rotate" "CW" > > > Option "Rotate" "CCW" > > > >Ugh, I haven't tried this stuff in a long time. It looks like >somebody broke all of this stuff. I doubt the problems are specific How come this is handled so strangely? My "daily bread" is a series of embedded systems with inbuilt gravity sensor that rotate the onscreen display dynamically (realtime) when the user rotates the housing. We don't use the chipset rotation features. We keep the chipset believing it is working with (say) a 640x480 display, and the application layer believes it is working with a 480x640 display. The GDI layer does the rotation and translation of coordinates, maintaining use of hardware acceleration features where available (including hardware cursor...). Sounds like the current X code uses a single piece of generic rotation code and bumps every chipset down to an unaccelerated mode using that rotation code. -- Lewin A.R.W. Edwards Embedded Engineer, Digi-Frame Inc. Work: http://www.digi-frame.com/ Tel (914) 937-4090 9am-6:30pm M-F ET Personal: http://www.larwe.com/ http://www.zws.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
On Thu, 2001-12-06 at 22:59, Mark Vojkovich wrote: > On Thu, 6 Dec 2001, Jeremy Sugerman wrote: > > > In article > > <[EMAIL PROTECTED]> Mark wrote: > > > Many drivers have Rotate options. Eg, from the "nv" driver man > > >page: > > > > > > Option "Rotate" "CW" > > > > > > Option "Rotate" "CCW" > > > Rotate the display clockwise or counterclockwise. > > > This mode is unaccelerated. Default: no rotation. > > > > Coincidentally, I just tried this last night with my TNT2 and XFree86 4.1.0. > > It didn't work well at all. The hardware cursor seemed pretty badly > > confused and there were weird dead areas on the screen containing garbage > > and portions of the root weren't visible no matter how I panned around. > > Dragging windows caused all sorts of corruption and glitching. > > > >Ugh, I haven't tried this stuff in a long time. It looks like > somebody broke all of this stuff. I doubt the problems are specific > to the "nv" driver. I'll look into it. Look at the fbdev driver for current, working rotation code. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
On Thu, 6 Dec 2001, Lewin A.R.W. Edwards wrote: > > > > > Option "Rotate" "CW" > > > > Option "Rotate" "CCW" > > > > > > >Ugh, I haven't tried this stuff in a long time. It looks like > >somebody broke all of this stuff. I doubt the problems are specific > > How come this is handled so strangely? My "daily bread" is a series of > embedded systems with inbuilt gravity sensor that rotate the onscreen > display dynamically (realtime) when the user rotates the housing. > > We don't use the chipset rotation features. We keep the chipset believing > it is working with (say) a 640x480 display, and the application layer > believes it is working with a 480x640 display. The GDI layer does the > rotation and translation of coordinates, maintaining use of hardware > acceleration features where available (including hardware cursor...). > > Sounds like the current X code uses a single piece of generic rotation code > and bumps every chipset down to an unaccelerated mode using that rotation code. That's because rotating X-rendering correctly is an ominous task. X11 is a pixel-perfect specification. Just rotating the coordinates on lines and polygons won't render them correctly. None of this stuff has been written and I don't know who has the time to do such a thing. Rendering to an intermediate buffer and blitting with rotation from there was the only easy solution. We do have code to render everything in horizontal spans, and one could adapt that to render vertical spans instead. That would be a quick way to get things working without the intermediate buffer, but the span paths are not known for its performance. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
On Thu, 6 Dec 2001, Mark Vojkovich wrote: > > > Many drivers have Rotate options. Eg, from the "nv" driver man > > >page: > > > > > > Option "Rotate" "CW" > > > > > > Option "Rotate" "CCW" > > > Rotate the display clockwise or counterclockwise. > > > This mode is unaccelerated. Default: no rotation. > > > > Coincidentally, I just tried this last night with my TNT2 and XFree86 4.1.0. > > It didn't work well at all. The hardware cursor seemed pretty badly > > confused and there were weird dead areas on the screen containing garbage > > and portions of the root weren't visible no matter how I panned around. > > Dragging windows caused all sorts of corruption and glitching. > > > >Ugh, I haven't tried this stuff in a long time. It looks like > somebody broke all of this stuff. I doubt the problems are specific > to the "nv" driver. I'll look into it. Sound like nobody has been > using it though, since this is the first time I've heard a complaint > about it not working. > It's fixed in CVS now. Must have broken a long time ago from the looks of it. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
Hi Mark, > > We don't use the chipset rotation features. We keep the chipset believing > > it is working with (say) a 640x480 display, and the application layer > > believes it is working with a 480x640 display. The GDI layer does the > > rotation and translation of coordinates, maintaining use of hardware > > acceleration features where available (including hardware cursor...). > >That's because rotating X-rendering correctly is an ominous task. >X11 is a pixel-perfect specification. Just rotating the coordinates >on lines and polygons won't render them correctly. None of this Can you explain this further? At the moment I have a system - running X actually - where I am emulating my older proprietary systems inside a frame buffer. Eventually I would have gotten around to looking at X's rotation possibilities anyway; I knew of it theoretically but have never tried to use it. Bear in mind that I know nothing about the internals of how things are represented in X. But the first part I don't understand is why rotating the coordinates of lines and polygons will not yield a correct result. A rectangle 100x25 pixels in size, 100 pixels right of the origin and 50 pixels below it, is described completely regardless of the geometry of the screen (assuming a Windows-convention origin, not an OS/2 PM-convention origin, of course :) My understanding of how it would work is that it would abstract the rotation at the same level I abstract it - i.e. the client app would be unaware of the rotation and would only be aware of the fact that the screen's pixel dimensions are a bit strange. As far as the client is concerned there is no rotation; the dimensions and sign-directions of the display surface exactly match that of the physical display output. The client renders at (say) 480x640; the user sees 480x640. The fact that there is a rotation operation is purely a hardware issue related to the order in which the display controller DMAs pixels out of RAM; it's just an issue of internal frame storage. Where am I going wrong in my understanding? And is this a question of rigorous standards compliance, or one of basic functional failure that will be obvious to the user? (Oh, and in case this is not clear: I'm not at all being argumentative or implying that any XFree code is bad, I'm just trying to see why it is impossible to implement an efficiency improvement). OT-PS: Pity you guys (NVidia) wouldn't sell us LCD controllers when we asked ;) but I'm very interested to try your PDA-chip with integral MIPS micro... ;) (or was that Neomagic? Darn N-names :) If there's a Linux port and an X server, I'm a happy monkey. -- Lewin A.R.W. Edwards Embedded Engineer, Digi-Frame Inc. Work: http://www.digi-frame.com/ Tel (914) 937-4090 9am-6:30pm M-F ET Personal: http://www.larwe.com/ http://www.zws.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
On Thu, 6 Dec 2001, Lewin A.R.W. Edwards wrote: > Hi Mark, > > > > We don't use the chipset rotation features. We keep the chipset believing > > > it is working with (say) a 640x480 display, and the application layer > > > believes it is working with a 480x640 display. The GDI layer does the > > > rotation and translation of coordinates, maintaining use of hardware > > > acceleration features where available (including hardware cursor...). > > > >That's because rotating X-rendering correctly is an ominous task. > >X11 is a pixel-perfect specification. Just rotating the coordinates > >on lines and polygons won't render them correctly. None of this > > Can you explain this further? At the moment I have a system - running X > actually - where I am emulating my older proprietary systems inside a frame > buffer. Eventually I would have gotten around to looking at X's rotation > possibilities anyway; I knew of it theoretically but have never tried to > use it. > > Bear in mind that I know nothing about the internals of how things are > represented in X. But the first part I don't understand is why rotating the > coordinates of lines and polygons will not yield a correct result. A > rectangle 100x25 pixels in size, 100 pixels right of the origin and 50 > pixels below it, is described completely regardless of the geometry of the > screen (assuming a Windows-convention origin, not an OS/2 PM-convention > origin, of course :) The biasing rules for lines and polygon edges are octant-specific. You won't get the same results for the same reason that Bresenham's algorithm won't draw a line from point A to B on the same points as a line from B to A without some octant-specific fixups. > > My understanding of how it would work is that it would abstract the > rotation at the same level I abstract it - i.e. the client app would be > unaware of the rotation and would only be aware of the fact that the > screen's pixel dimensions are a bit strange. As far as the client is > concerned there is no rotation; the dimensions and sign-directions of the > display surface exactly match that of the physical display output. The > client renders at (say) 480x640; the user sees 480x640. The fact that there > is a rotation operation is purely a hardware issue related to the order in > which the display controller DMAs pixels out of RAM; it's just an issue of > internal frame storage. That's the way it works now, except the copies from the shadow buffer to the real framebuffer are done with the CPU due to the general lack of user-space DMA capabilties on the operating systems we support. > > Where am I going wrong in my understanding? And is this a question of > rigorous standards compliance, or one of basic functional failure that will > be obvious to the user? (Oh, and in case this is not clear: I'm not at all > being argumentative or implying that any XFree code is bad, I'm just trying > to see why it is impossible to implement an efficiency improvement). Perhaps I misunderstand what you were asking about. You've described the way it currently works. I described why doing without a shadow buffer has not been done. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
