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.

First off, the radeon parts have multi-head capability.

Secondly, for reasons I don't want to go into, I want to be able to have
virtual screens at the application layer, where the screens will
probably be bitmapped.  (We are going to be using an embedded graphics
library rather than X windows.)

Third, I want the ability to run these virtual screens at arbitrary
logical and physical resolutions, where they may not be the same.  (E.g.
use panning or upscaling as appropriate.  Radeon hardware can do this. 
For console screens we would not allow this, but it makes sense for
graphics screen where the mouse can be used for panning.)

Fourth, I want to render directly from application layer into
framebuffer memory, for performance.

Fifth, I want to be able to configure the multi-head so that it is
either "cloning" the view (two views on the same desktop), merged
(imagine a double wide display), or totally independent.  This
configuration can be established at start of day and not change until a
reboot.

Sixth, I want to be able to use 2D acceleration where possible.

Finally, support for X11 is nice, but not a requirement.

Here's how I plan to achieve this:

* multiple head configuration established at start of day.   If the
heads are determined to be independent, then I will register two
separate "instances" of the wsscreen.

* 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.

* the show_screen (or is it switch_screen?) routine works simply by
changing the CRTC registers to point to the right location in
framebuffer memory (plus work for resolution changes and panning)

* 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.)

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.  (Barring other considerations like TCP port setup,
etc.)  This is *very* different from the current X11 way of doing things
where it just "gloms" onto the entire video card, and "owns" it it until
it tells the driver to switch back to text mode (whereupon the driver
redraws into framebuffer using a character grid stored in main memory.) 
In this design, there is no "redrawing", or anything like that.  And all
the details of the hardware are abstracted behind ioctls, so the
userland code can be made ignorant of them.

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.

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.)

I'm sure there are details that I've omitted.

Thanks in advance for any comments or suggestions.

    -- Garrett

Michael Lorenz wrote:

>Hello,
>
>since the code to support virtual consoles in several drivers ( namely
>pnozz, cgsix, machfb and ffb ) is virtually identical I came up with the
>attached abstraction. It will work with any wsdisplay driver, code
>changes are necessary but usually trivial.
>
>So far it does:
>- virtual consoles, provides a function to redraw screen content when
>  necessary ( like, when X exits or an fb device closes )
>- character read and write ioctl()s when options WSDISPLAY_CHARFUNCS is
>  given ( for wsmoused )
>It doesn't support scrollback yet, but that should be easy to add.
>
>The patch contains the virtual console implementation ( vcons.c and
>wsdisplay_vcons.h, put them into dev/wscons/ ) and it adapts the cgsix,
>pnozz and macppc's ofb drivers to use it. Changes in kernel config files
>aren't necessary unless you want to run wsmoused.
>
>The code has been tested on sparc ( with pnozz ), sparc64 ( with cgsix
>and ffb but my ffb is way out of sync so I didn't include it here ) and
>macppc ( with ofb, due to some peculiarities it needed a bigger
>overhaul. I'll probably hack it a bit more to add colour support as well
>)
>
>It could easily work with vga as well but I'm not sure a merge is
>desireable here - if I remember correctly vga keeps scrollback buffers
>and such in display memory which this implementation doesn't support -
>it always keeps character and attribute buffers in main memory.
>
>So, any comments before I clean it up?
>
>have fun
>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