Date: Mon, 17 May 1999 16:29:40 -0400 (EDT) From: Kelly Yancey <kbyanc@alcnet.com> To: Soren Schmidt <sos@freebsd.dk> Cc: des@flood.ping.uio.no, yokota@zodiac.mech.utsunomiya-u.ac.jp, freebsd-hackers@FreeBSD.ORG Subject: Re: modex support (again) Message-ID: <Pine.BSF.4.05.9905171617380.24408-100000@kronos.alcnet.com> In-Reply-To: <199905172003.WAA25955@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 May 1999, Soren Schmidt wrote: > It seems Kelly Yancey wrote: > > I think you just nailed the problem here. It requires a prohibitive > > amount of effort to support modex video modes given the return. What I am > > thinking about is removing the 320x240 mode (since it is impossibly > > difficult to deal with)...no one is using it now so no one would be > > affected. I would also like to add a comment into one of the source files > > indicating why we have chosen not to support unchained VGA modes (ie. > > "modex" modes) so that we can prevent this question from arising again in > > the future. > > On a slightly related note, I am currently in the process of developing > > patches to add more useful "tweaked" modes to the video driver: > > graphics 720x480, 16 colors (90x30 8x16 character cells) > > graphics 256x256, 256 colors (32x32 8x8 character cells) > > graphics 296x220, 256 colors (37x27 8x8 character cells) > > text 90x25, 90x30, 90x43, 90x50, 90x60 > > > > The patches will also update vidcontrol to allow selecting any of the > > modes. > > Excuse me, but those modes are even more wierd than modex, either we stick > to the std modes, or we'll bloat the driver beyond repair, what I'm > stricktly against. All those wacky modes should be set from a module > or some such, they have NOTHING to do in the kernel pr default. > > This isn't Linux guys... (sorry couldn't help that one)... I admit that they are less common than say 320x240 mode x...but they are linear and don't require any hacking to support from applications which would use graphics modes (unlike the unchained "modex" modes). I absolutely agree that we should keep the kernel as lean as possible. And I would *love* to put the modes into a module (that was my original plan)...but to do that, I need get_mode_param to be extern'ed from vga_isa.c so that the module can access the BIOS mode table (or else re-implement the code in vga_isa.c to access the mode table). All I am looking for is the OK to make that routine extern in my patches and I'll make a module. My biggest concern is that get_mode_param is obviously considered an internal API and thus subject to change...change which would then break my KLD. :( With a module, I would suggest moving the implemention of the 320x240 modex mode there also (or else remove it altogether...but with a module, removing it would be unnessicary). And with a module, there would be no harm in implementing the other 6 modex modes (320x400, 320x480, 360x200, 360x240, 360x400, 360x480). If I can get past the get_mode_param hangup, then there would be no reason no to implement 2 KLD's: one for the tweaked video modes and one for the 90-column text modes. Thanks! Kelly ~kbyanc@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ 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.BSF.4.05.9905171617380.24408-100000>