Date: 14 May 1999 16:05:02 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: Kelly Yancey <kbyanc@alcnet.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: modex support (again) Message-ID: <xzpso8z3fxt.fsf@localhost.ping.uio.no> In-Reply-To: Kelly Yancey's message of "Fri, 14 May 1999 09:45:23 -0400 (EDT)" References: <Pine.BSF.4.05.9905140930300.52692-100000@kronos.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kelly Yancey <kbyanc@alcnet.com> writes: > 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). Yes, it's possible, but it requires a page fault on *every* write to video memory. YA case of 'possible, but not practical'. (this technique has been used to simulate a linear frame buffer when using paged modes, but I haven't yet succeeded in convincing Kazu to implement it in the VESA driver and I don't have the time or know-how to do it myself) > 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? Yes, if it's there at all you have to switch banks "manually". > 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). The VESA code is very small, and you want VM86 anyway (amongst other things, for reliable memory detection) > 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. We already have that (libvgl), though it's in deperate need of maintenance. > 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. > > 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) 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) - port GGI to FreeBSD. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no 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?xzpso8z3fxt.fsf>