--pgp-sign-Multipart_Wed_Nov_16_08:58:51_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "m" == Michael  <macallan18@earthlink.net> writes:
>>>>> "mh" == Martin Husemann <martin@duskware.de> writes:

     m> wsdisplay was never meant to be a framebuffer device,

In that case, it would be nice if the ``text'' mode framebuffer were
smart enough to drop into ddb while X is running.

    mh> I'm not sure I follow this logic.  Wsdisplay is a kernel
    mh> concept to get console output. It works for that just fine.

yes, but in other arguments whenever anyone brings up Linux /dev/fb0 a
chorus of old NetBSD developers chime in, ``we already have wscons.''
so, aside from factoring reasons for combining framebuffer and text,
wscons has been used repeatedly to block other people who want to work
on framebuffer.

    mh> we had one primary consumer of the missing interface - X

no, that's wrong.  Radek is writing a program that uses the
framebuffer directly.  Pavel mentioned taking screen shots.  and
someone else asked about mplayer.  so there's three, just in the last
month.  Who knows how many are lurking in pkgsrc.

    mh> We could do that. Microsoft moved GDI inside the windows
    mh> kernel, a long time ago.

You're right---MS is a good warning post, and it's possible to imagine
all kinds of acceleration and antialiased freetype stuff creeping into
the kernel.  but I think characterizing what's going on here, asking
that the ``sane framebuffer architecture'' on sparc64 be standardized
onto all architectures, as equivalent to kernel GDI, is total FUD.
What's suggested is nothing but what vendor Unixes do, what we hold up
as an example whenever complaining about XFree86, and what people have
routinely claimed that wscons already does compared to Linux /dev/fb
until someone like Radek goes through a lot of review to convince that
it doesn't.

And there's more.  Why is switching between ``virtual consoles'' a
machine-dependent feature, so that new ports have to wait years before
someone goes back and adds it?  Why isn't there a way. as there is on
Linux, to run a machine-independent unaccelerated ``Xframebuffer''
server on any port that has a software-rendered wscons console?  Why
is it impossible to run a software-rendered console on i386 (something
Linux has done, I think _by default_, for years)?  What's with all
that special MD keyboard goo?  (and, ddb broken in X)

Also, what happened to the idea of VAX-style multiple heads on one box
with separate keyboards and separate users sitting at each?  For that
goal, and also to most easily accomodate platforms that can run the X
server through 'startx' without anything setuid-root, it seems like
the X server should map everything through the tty.  no wskbd,
wsmouse, wsdisplay, fb, ffb, none of that---_just_ the tty, so the X
server can benefit from the associations between screens and keyboards
that wscons is already making rather than having to rewrite these
bindings in a gigantic XF86Config file that shouldn't even exist, and
so login's changing the permissions on the tty will control who is
able to take over your screen or sniff your keyboard with an X server.

Or, to accomodate Pavel's idea of taking screenshots with dd, it could
instead be analagous to rsd0a vs sd0a, like

ttyE0     fb0      wskbd0   wsmouse0
ttyE1     fb1      wskbd1   wsmouse1
ttyE2     fb2      wskbd2   wsmouse2

meaning, if I press ctrl-alt-F2, login, run startx, then the X server
should open fb2, wskbd2, wsmouse2, and they should all work.  a little
harder to change the permissions, but we already have sound card
stuff, and maybe that's a much easier API?  Either the single device
or clusters of devices would argue somewhat for combining the MI
/dev/fb0 functionality that we don't have with the existing wscons
rather than making it a separate piece.

--pgp-sign-Multipart_Wed_Nov_16_08:58:51_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iQCVAwUAQ3s7JonCBbTaW/4dAQKBfQP/RaKyr4Kh0w3CGQHNsQp9UysiwFnEw9Ry
wJk9iFXNGmJFg6LXnXihTolz0+pEW0MiJd9mEfSqMlA78R4Vq0iuibWDVlt99vDI
EUKM6lbPM+9fAKrnPmzuHl7B2hqGloYvjAkVKCD97NU8kqcqj9um22Z8j8Th3jcY
fsfMrjE0fDQ=
=R0gV
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Nov_16_08:58:51_2005-1--