--Signature_Thu__22_Dec_2005_15_44_08_-0500_GTcmFOiNvPaCuTYc
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

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

No need to have everything at once - just don't make it impossible or
unnecessarily complicated.

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

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

have fun
Michael

--Signature_Thu__22_Dec_2005_15_44_08_-0500_GTcmFOiNvPaCuTYc
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQ6sQGcpnzkX8Yg2nAQLCUAgApzjRuSgCMSzhpfHFJMVhPv2YdxDGTNEG
npTcHYelpfq3Z0mOKRSMnTZVrZH8nmeLwWeDdjRPMQIaOgameDjo+wrDTaysptpB
jrw7GsVW41yUbH5RNeVLMGOEOLw5ubkr70MTkHifLRbQ1Y/YXiOoanllMBm6BTAi
scZyL1nIc8I3hXp4MSxmLaK1TKOU/0eCATnZUXKLewv/L+d9uZO8k9vieJZ18f7Z
9XtTRSeuPmlMEXNbSXvxTx3AsfdylxAWk6rtzD5Lat5IQLeV5qWQUYHEsdvlIQoX
wZiEJtwhw8n1tekW0nuR8lZeAR8MERMa94+tEgf03jRio1SMB4fU6g==
=Flg9
-----END PGP SIGNATURE-----

--Signature_Thu__22_Dec_2005_15_44_08_-0500_GTcmFOiNvPaCuTYc--