Date: Thu, 6 Aug 1998 10:55:35 -0400 (EDT) From: Kelly Yancey <kbyanc@freedomnet.com> To: Mike Smith <mike@smith.net.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: syscons update Message-ID: <Pine.BSD/.3.91.980806103451.262A-100000@freedomnet.com> In-Reply-To: <199808052303.QAA01549@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Aug 1998, Mike Smith wrote: > > 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? That would be great. It's really a shame though...especially when getting into all the VESA text modes too...that it isn't more modular. > > > 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. I was thinking that, in order to not disturb the current syscons driver, maybe start on a new separate video driver. Something where the new video driver interfaces to a card-specific driver providing generic interface ioctl calls for user programs to use. That will make sure we don't get in the way of the syscons development or break any code that uses the current syscons driver. Then down the road, we could modify syscons to go through the video driver for any screen updating. Also, what would be really exciting is a FreeBSD X server that made calls to the video driver (rather than having the adapter-specific routines in the X server). Talk about division of labor...I would think that would make code cleaner all around. > > > * 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. Good point. Perhaps their should be a standard video/mouse API (probably should be something for sound too) the way there is a disk access layer and networking layer. Computers have come a long way, baby. :) > > > 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. No, you're right. I guess better support for modular drivers is needed before that could happen. But as far as the video drivers are concerned...at first it would seem like reinventing the wheel since all the support currently in the X servers would have to be put in the OS (where it should have been to begin with, in my opinion). But the short-term advantage is that other programs for FreeBSD could easily use the video adapter's graphics capabilities...especially games :). The long-term, perhaps pipe-dream, advantage would be that the X group could focus on X things, not platform things. Like I mentioned above, someone could strip all the hardware-specific code from an X server and replace it with calls to the video driver (kind of like how it uses sysmouse now), then any other platforms that implemented similar OS-level video control could use the same server. In theory, at least, the X group wouldn't have to worry about the hardware specifics anymore...the OS developers would. > > > 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. > > -- Yeah, one step at a time I suppose...got my head stuck in the clouds :) BTW, I've submitted the 90-column support patches (one for the syscons driver, one for the vidcontrol program to use the new modes) to the FreeBSD team...I'll keep my fingers crossed. I've also posted the patches on a web page: http://www.posi.net/software/public/patch-90col/ Thanks for your feedback, 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?Pine.BSD/.3.91.980806103451.262A-100000>