Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: Garrett D'Amore <firstname.lastname@example.org>
From: Michael Lorenz <email@example.com>
Date: 12/22/2005 06:54:30
Content-Type: text/plain; charset=US-ASCII
> 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.=20
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.
> 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.
> * 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.
> * 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)
Yeah, callback and flag for redrawing.
> * if the mode is not text mode, then I will support additional device
> specific ioctls to set physical display resolution, panning offsets,
> * 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.
> The end result will *not* be compatible with any current X11 driver.=20
> 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.
> 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'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
just two more cents
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
-----END PGP SIGNATURE-----