Date: Fri, 14 May 1999 10:53:02 -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.9905141021150.64191-100000@kronos.alcnet.com> In-Reply-To: <xzpso8z3fxt.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: > We already have that (libvgl), though it's in deperate need of > maintenance. That what I meant by "equivalent" ;) > > > 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). > > I vote for the latter. I'm starting to think that this is the Right Thing also. But then again, where is the line? I think removing the interlaced mode x modes might make sense...but why have any video modes outside of X? Just because we can? Does anything use libvgl? > > > > 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? > > No, actually it has 1536 more pixels :) Mode Q is so named because the > frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) > Yeah, I've seen the DOS port of snes9x use that. I don't think it has truely square pixels though since the screen has a 4:3 aspect ratio and the resolution is 1:1...the pixels should look slightly wider than they are tall. But it is linear :) The question is...is it worth including? I just did a quick search on the net and found the register programming information for this one (256x256x256) and another interesting linear mode (296x220x256) which has almost square pixels and a slightly higher resolution. Finally, would there be any interest in 720x480x16 color VGA mode. I have some old code which does this fine and have seen several other references to it in my search for mode Q. This goes along with the question of where the line is before a video mode becomes useless. And if the verdict is that the extra video modes (so long as they are planar) are useful, then how about some tweaked text modes? We have support for a number of different rows, but I have some old patches (which need updating) for extending the number of text mode columns from 80 to 90. BTW, the extra advantage of 90 column text modes is that syscons mouse pointer doesn't suffer from the weird character cell wrapping which causes the mouse pointer to stretch by 1 pixel when it cross character cell boundaries (since each character cell in 90 column mode is 8 pixels wide not 9). > If you have time and talent to spare and want to work on the console > code, I have two suggestions for useful additions: > > - modify syscons so userland software can mmap the frame buffer, and > whatever other modifications are necessary to make it possible for > userland software to use graphics without needing write access to > /dev/kmem (currently, the only way to mmap the frame buffer is to > map in the correct address range from /dev/kmem) > I would like to do this. But unfortunately, I am currently mostly lacking the talent :) However, I just received The Design and Implementation of 4.4 BSD so as soon as I feel I really understand how mmap'ing is implemented, I might take a whack at it. > - port GGI to FreeBSD. I thought this had been discussed and shot down? 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.9905141021150.64191-100000>