It seems Kelly Yancey wrote: > > 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.
Hmm, I see no problem in publicising get_mode_param, the only thing is that it might change over time, but thats another matter... -Søren To Unsubscribe: send mail to [email protected] with "unsubscribe freebsd-hackers" in the body of the message
