Date: Wed, 05 Aug 1998 17:11:35 -0400 From: Kelly Yancey <kbyanc@freedomnet.com> To: freebsd-hackers@FreeBSD.ORG Subject: syscons update Message-ID: <35C8CA87.3DD72E40@freedomnet.com>
next in thread | raw e-mail | index | archive | help
I have written an update to the freebsd syscons driver and vidcontrol
program to allow for 4 new VGA text modes: 90x25, 90x30, 90x50, 90x60.
Yes, 90 columns wide. I had written an assembly program years ago that
ran under DOS that switched to 90 columns wide...it works fine on every
VGA and SVGA adapter I have ever run across. Basically, it just toggles
the VGA adapter from using 9 pixel wide characters to 8 pixel wide
characters and then adjusts the horizontal counts accordingly. I'm
wrapping up the code for that so I can submit it to the team to include
in future FreeBSD releases.
But that's not why I'm posting (that was just the self gratifaction
segment :) )...the syscons code is hideous. Talk about one overworked
driver. Now it handles screen output, keyboard input, and text-mode
mouse functions. It also appears that there is some sort of intent to
add basic graphics functions to the syscons driver.
I had some ideas, which I wanted to run by everyone else and see what
you all think. I realize that most are probably to radical to be
practical since I imagine vidcontrol and kbdcontrol aren't the only
programs that interact with the syscons driver itimately.
* Division of functionality: right now, moused watches the mouse
device and notifies the console driver of any changes which in turn
notifies sysmouse. Why doesn't moused interact directly with sysmouse...
isolating all the mouse functionality to sysmouse. Then, if the user
wants a mouse cursor in text mode, the console driver is welcome to
interact with sysmouse like every other program does. What am I missing?
And more importantly, it seems to me that the code should at least be
split up, if not the functionality. Why not separate source files
containing the display, keyboard, and mouse related routines in the
syscons driver? Just because it is one driver, doesn't mean it has to be
a single source file. I think that would go a long way toward improving
the code readability.
* Continuing on the idea of dividing the work...improve the graphics
support: currently things are sort of strange: X supposedly a userland
program has to ship with video drivers. Why isn't this in the OS? Not
only would it make X's job easier...but it would allow other user
programs to easily use graphics without having to be written for X (like
games). The way I see this working is by having video adapter drivers
like we have sound card drivers or network card drivers.
Basic vidmono, vidcga, videga, vidvga drivers could be extracted from
the currently syscons code. The console driver then just interacts with
the video adapter driver. Also a bonus: you could have more than one
video card in a system with different video drivers loaded, which are
all managed by the syscons driver. Wahla...multiple physical and virtual
console support native to the OS (it's not just for X anymore). However,
a basic set of ioctl functions should be defined for video adapter
drivers for certain functions. For example: an ioctl to determine what
video modes are available and another to select the video mode. ioctl
values could be defined for many graphics acceleration features. User
programs could then interface with the syscons driver to do graphics on
the current console (virtual or physical), if the video driver for that
console supports hardware acceleration for a function, the syscons
driver could call that, otherwise it can piece it together from other
functions if possible.
So, the way I envision things:
hardware: keyboard mouse video ...
| | |
| sysmouse vga0 (or other video driver)
| | |
`------console-----'
/|\
/ | \
user land programs
That goal of all of this rearranging would be to encourage development
for the FreeBSD system mainly in the area of graphics programming. At
the moment is seems that Linux is getting a lot more attention in that
area (for better for for worse). I've been using BSD derivatives
(FreeBSD and BSDi) for several years now and think, personally, it wipes
the floor with linux. It is a shame to see it get many of the new
inovations first now just because of it's recent popularity.
I realize that what I'm suggesting is a major overhaul of one of the
oldest and most fundimental aspects of FreeBSD, or Unix in general. But
it is a driver that dates back to teletype terminals and it showing it's
dating. It seems to me that there is at least some interest in
modernizing the console interface (else, why add the text mouse
support), so why just play catch up when we could leap ahead? I would
love to see video adapters fully supported by the OS just like
everything else is. Who knows, maybe one day the console driver will
actually support just the text modes available on my SuperVGA card, not
to mention graphics and 3D acceleration.
My rantings. :) I am interested to know what other people think. I'de
be even more interested in knowing if the FreeBSD core team would allow
be to begin work on this master plan :) I'de be glad to get it
started...but I know my own limitations...there is no way I'de be able
to write all the SuperVGA video drivers myself. I could at least write
drivers including all of the current functionality plus CGA, EGA, and
VGA graphics (text modes, mouse, etc.) I guess I'm just looking for
opinions and support. Your input is welcome,
Thanks for listening,
Kelly Yancey
~kbyanc@freedomnet.com~
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35C8CA87.3DD72E40>