Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: Garrett D'Amore <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 12/22/2005 15:44:08
Content-Type: text/plain; charset=US-ASCII
> >>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.
> I can use a hook if necessary. But if you can enhance vcons, that
> might be better/more reusable.
I'd just call the old show_screen() from wscons_emulops if vcons_init()
finds something non-NULL
> 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. :-)
True. Currently we're handling this rather awkwardly or not at all.
There's no real virtualization of /graphics/.
> Of course, if there is a flag that prevents redrawing, that would be
> OK too.
We'll probably need a few more flags.
> >>* 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.
My oversight, it definitely should care and abort creation of the screen
in this case.
> >>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.
> >> =20
> >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.
> > =20
> Yeah, although initially I'll probably want to keep the command
> interface as simple as possible. This project is on a fairly short
No need to have everything at once - just don't make it impossible or
> I will do the hardware cursor, for sure. The mono-color expansion
> might be useful.
It saves some PCI bandwidth and on CPUs with alignment restrictions it
saves you from the pain of working around unaligned character boundaries
- not such a big issue with 32bit colour but very useful in lower
> Certainly I'm going to want YUV expansion, but that is because our
> application will be able to use it. (Think streaming video.)
Might be useful for other drivers as well, at least the voodoo3 (
voodoofb isn't in the official source tree yet ) supports all kinds of
colour space transformations using the blitter - source and destination
can be vastly differnent in depth, format, geometry and even size.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
-----END PGP SIGNATURE-----