Michael Lorenz wrote:

>Hello,
>
>  
>
>>The radeon framebuffer driver that I'm working on will be able to
>>benefit from this (vons), I think.  However, I wanted to send out a
>>description of what I'm doing, so folks can critique it.
>>    
>>
>
>  
>
>>Third, I want the ability to run these virtual screens at arbitrary
>>logical and physical resolutions, where they may not be the same. 
>>    
>>
>
>Hmm, then you'll need a callback in show_screen() ( or hook it instead
>of just overwriting ) to notify your driver when a screen became visible
>before redrawing it. And a flag indicating wether a screen needs to be
>redrawn when becoming visible. I'll add these things, others may need
>them as well.
>  
>
I can use a hook if necessary.  But if you can enhance vcons, that might
be better/more reusable.

Another consideration is the handling of graphics mode.  My read is that
most of the current code out there seems to assume that virtual displays
are only used with text mode.  (So, for example, the unconditional call
to restore_screen on a VT switch, which redraws text.  For a graphics
screen, redrawing text would be a bad idea. :-)

Of course, if there is a flag that prevents redrawing, that would be OK too.

>  
>
>>Fourth, I want to render directly from application layer into
>>framebuffer memory, for performance.
>>    
>>
>
>Easy to do, every screen has its own struct rasops_info, there's
>absolutely no reason why they should point at the same VRAM area ( or at
>a VRAM area at all ) or have the same dimensions, depth and so on.
>  
>
Yep, that looked to be the case to me.

>  
>
>>* alloc_screen() carves up framebuffer memory on demand.  This means
>>the number of virtual consoles is limited by how much framebuffer
>>memory you have (and the resolution of those consoles).  I'm only
>>planning on supporting 32bpp for now.
>>    
>>
>
>Sure, just have it return ENOMEM when you run out of VRAM. I'll check if
>my code handles that in a halfway sane way.
>  
>
Not yet it doesn't -- it doesn't check the return value from the driver
at all.

>>* if the mode is not text mode, then I will support additional device
>>specific ioctls to set physical display resolution, panning offsets,
>>etc.
>>
>>* I will also provide ioctls for 2D acceleration (draw a line, etc.)
>>    
>>
>
>Just keep them generic enough so I can support them on mach64, cgsix and
>so on. Maybe have a bunch of flags indicating hardware capabilities.
>  
>
Will do.  I want to do this anyway, because I might e.g. write drivers
for other LCD panels (e.g. Alchemy Au1200 panel), or for SiliconMotion
devices, or even custom graphics hardware we might have designed at a
later date.

This is the big win for me.  I don't have to teach the userland code all
the details about how to program CRTCs, etc. for each and every kind of
display chip.  Instead, I just have some enumeration routine to get
number of displays, attributes for each (maximum resolution, depth,
etc.)  And I will have either a bit flag or some other kind of query
interface to determine acceleration support.

>  
>
>>The end result will *not* be compatible with any current X11 driver. 
>>However, one could write a driver and probably even make it "safe" to
>>run unprivileged.
>>    
>>
>
>This would be a nice addition to XFree's wsfb driver. And handling
>acceleration in kernel would allow to queue blitter commands and use
>interrupts to run them asynchronously. Maybe there should be a simple
>packet format describing them ( like a command, plane mask, ROP,
>coordinates, other data, so it would easily be usable for X ) and an
>ioctl that simply takes a pointer to a buffer full of them, enqueues
>them and maybe sets completion flags.
>  
>
Yeah, although initially I'll probably want to keep the command
interface as simple as possible.  This project is on a fairly short fuse.

>  
>
>>My first implementation of this will not include much acceleration,
>>other than basic line, fill, blit, and maybe some stuff like YUV
>>decode.  3D acceleration will not be included in my code.
>>    
>>
>
>Well, wscons only uses screen-to-screen blits, rectangle fills and
>probably mono-to-colour expansion to draw characters ( pnozz, machfb and
>cgsix do that, most others use only the first two as far as I know )
>Adding support for a hardware cursor would be useful ( wsfb from
>-current xsrc would use it for instance )
>  
>
I will do the hardware cursor, for sure.  The mono-color expansion might
be useful.  Certainly I'm going to want YUV expansion, but that is
because our application will be able to use it.  (Think streaming video.)

>  
>
>>I'd like the architecture to be good enough that folks would be happy
>>to have other drivers built using the same ioctls.  (Imagine e.g. a
>>silicon motion driver, or drivers for embedded LCD panels.)
>>    
>>
>
>This would certainly make a few things easier. Writing an XFree driver
>isn't really hard but something like this would definitely reduce
>duplicate work ( like writing acceleration code once for wsdisplay, then
>again for XFree and then take care that they don't stomp over each other
>)
>The XFree folks won't like this approach and there will be a few who
>complain about graphics-in-kernel but the code is already there and has
>to be there in quite a few cases, this would only add a way to use it
>from userland.
>  
>
And, ultimately, I'm not trying really hard to service XFree.  Having an
X server run on top of this would be nice, but it isn't strictly
needed.  For our application, X11 is much too heavy weight, so we want
to KISS.  We are going to use C/PEG (see Swell Software's site) for our
application, and the main thing is that I don't want to have to teach
C/PEG all the intriciate details about switching consoles, etc.

In fact, C/PEG is so light, that it would be hard to support multiple
displays in userland.  It is much easier to have resolution, virtual
displays, etc. all managed in the kernel driver.

    -- Garrett

>just two more cents
>Michael
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134