Subject: Re: framebuffer access
To: None <port-sparc64@netbsd.org>
From: Miles Nordin <carton@Ivy.NET>
List: port-sparc64
Date: 11/16/2005 16:46:23
--pgp-sign-Multipart_Wed_Nov_16_16:46:22_2005-1
Content-Type: text/plain; charset=US-ASCII
>>>>> "m" == Michael <macallan18@earthlink.net> writes:
m> telling the driver that a panic happened so it can do
m> a forced switch.
yeah, I was not imagining any switching involved. I was imagining
rather wscons would adapt to whatever mode XF86 had configured.
m> - the Xserver never switches video modes so nobody needs to
m> force anything back,
yeah, it would be nice if XFree86 could work that way. I understand
XFree86 needs direct access to the chip for acceleration or whatever,
but couldn't the mode-switching part be:
1. ripped out or disabled and
a. replaced with a VESA modeswitcher
b. replaced with non-XFree86 chip-specific modeswitchers like
machfb
On an architecture with software-rendered characters, I don't see why
XFree86 has to mandatorily change the video mode---isn't it done this
way just a PeeCeeism where XFree86 expected the ``old'' mode would be
a text-only mode?
2. isolated into a separate userland tool that configures video
timings/sizes/bit depths. this tool is:
* graphics chip specific
* runs separately before the X server is invoked
* reconfigures text consoles as well as X
That is the same almost as XFree86 is now, except split into two
binaries instead of one.
#2 is what Solaris actually does. You _can_ change the modes. There
are many-optioned board-specific tools like m64config and ffbconfig
that can set things like gamma profile as well as size/color
depth/refresh rate. You have to stop Xsun, run the tool, restart
Xsun.
With #2, I guess whether XFree86 remains one piece or is split into
two separately-invokeable front ends isn't so much the big deal as
adding a call back into wscons after a mode change and inform it of
the new screen geometry and color plane order and whatever. wscons
doesn't need to know how to change or read modes so long as XFree86
keeps its idea of the mode current.
--pgp-sign-Multipart_Wed_Nov_16_16:46:22_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
iQCVAwUAQ3uor4nCBbTaW/4dAQLy9gP/QjDa4NkkMvcfkaMr1wqWRBU2U+ybXEeX
JNgrsOL10wAjT6Mj5KJY0Vvf78YPRazdxupKDuV9t7vmXV/f2d74QYGI7hS5QKtY
yAeiy56BF2IzuxWpaqHt6rEqeweOut9G2GHt4g2xpJG4rmubJb/bKVtiw7hmM00a
4T0WWU7vTsA=
=se/O
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Wed_Nov_16_16:46:22_2005-1--