Date: Wed, 05 Aug 1998 16:03:18 -0700 From: Mike Smith <mike@smith.net.au> To: Kelly Yancey <kbyanc@freedomnet.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: syscons update Message-ID: <199808052303.QAA01549@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 05 Aug 1998 17:11:35 EDT." <35C8CA87.3DD72E40@freedomnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
What is most amazing is that just in the last 24 hours we've been discussing what you're basically talking about here... > 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. Neat. How would you like to help work on adding support for the VESA text modes too? > 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. The functionality is actually already there, although you might have missed it. 8) > 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. Actually, what you go on to propose is what everyone has agreed has been needed for a long time now. Syscons desperately needs someone with time and energy to break it down into modules. > * 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? It's quite hard for a device driver to open and read from another device. What currently happens is actually just a workaround for this; instead of creating a pipe and writing mouse events to it, moused sends ioctls to the console device. The console device then turns this stuff around to make it easy for other consumers to use. > 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. One of the problems with that is namespace pollution. Your proposal below implies that you're looking at a relatively tidy separation between the modules, so that's OK. > * 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? Because the drivers are maintained by the X people, so there's one set of drivers maintained by one group that covers a large number of operating systems. As opposed to forcing them to deal with a plethora of different interfaces with different operating systems, and forcing each operating system group to duplicate the work of the others. In addition, video drivers bulk *large*. You don't want these in the kernel. > 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, Forget writing the bitmap drivers. If you were simply to take syscons, and start talking to Soren (sos@freebsd.org) about modularising it, you should find a task that's both worthwhile and achievable. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.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?199808052303.QAA01549>