Date: Fri, 14 May 1999 09:45:23 -0400 (EDT) From: Kelly Yancey <kbyanc@alcnet.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: modex support (again) Message-ID: <Pine.BSF.4.05.9905140930300.52692-100000@kronos.alcnet.com> In-Reply-To: <xzpwvyb3juj.fsf@localhost.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 May 1999, Dag-Erling Smorgrav wrote: > Kelly Yancey <kbyanc@alcnet.com> writes: > > Hmm. I sent this message a few days ago and it has been silently ignored. > > Should I consider that an OK to extern the get_mode_param function in > > vga_isa.c? Or should I take that as a mass "go ahead, we're not going to > > commit the code anyway?" :( > > Hmm, well, I don't like to say "go ahead, we're not going to commit > the code anyway", but I can't see the use of adding Mode X support - I > feel that the gain in functionality is too small to justify the added > complexity. You'll need to add bits to the video_info structure to > describe the encoding. AFAIK, the current model can only describe > linear and plane-per-channel encodings accurately, whereas Mode X uses > a weird interlaced encoding. The designers of the VGA chipset ought to > be taken out and shot. You'll need to hack everything that hooks into > syscons but doesn't explicitly set the video mode to check for Mode X > so they won't shoot themselves in the foot trying to address it as a > linear mode. > > To summarize, it seems like a lot of trouble just to get 40 additional > scanlines and square pixels on obsolete hardware - anything that > doesn't support 'options VESA' was already obsolete five years ago. > It's not going to make FreeBSD a better desktop OS (desktop users use > X, not syscons) and its' not going to make FreeBSD a better server OS > (no, a prettier splash screen does not make your server faster). Shot definately :) You have a lot of good points. What really confuses me, I guess, is that support for 320x240 modex is already in there. I've poked around with it a bit when adding the other modes and noticed that it doesn't do anything but set the mode. I guess we are already in the boat of having a problem with people being able to shoot themselves in the foot :( My guess as to the logic is that if you set the mode to 320x240, you better expect to the interlacing. What I don't get is how the memory is presented to apps using the driver. The best I could think of would be to present it a 256k linear frame buffer with the pixels in order (ie writes to consecutive pixels would result in the driver switching planes), and while that would present a consistent interface, it would be *really* slow (if it is even possible). The next best thing would be to present it a 256k linear frame buffer but with each plane 64k after the previous. Applications would have to be aware of the layout (ie. know that modex modes aren't linear) because writes to consecutive memory addresses would result in changing every 4th pixel. This is the method I would assume must already be in place for the existing 320x240 mode, but I can't find it. Which means that at the moment 320x240 is useless? Really, I was thinking that this would be a "neat" thing to add. I could have some higher resolution video modes without needing VESA (and VM86). But you make a good point in that anyone who wants graphics uses X. I guess I was thinking that maybe the additional modes would be of use should FreeBSD ever really get an equivalent to libsvga. Anyway, as you point out, then the modes are really only of use to splash screens (which is a minor feature in and of itself). So the question becomes, is there any interest in adding 6 mode "tweaked" modes (in addition to the existing 320x240) or should we reduce complexity and remove the 320x240 mode because surely nothing can be using it (you can only write to every 4th pixel right now). > > OBTW, Mode Q has square pixels and linear addressing. I won't mind > adding support for Mode Q :) Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 resolution? Kelly Yancey ~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.9905140930300.52692-100000>