Date: Fri, 14 May 1999 10:54:06 -0400 (EDT) From: Brian Feldman <green@unixhelp.org> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Kelly Yancey <kbyanc@alcnet.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: modex support (again) Message-ID: <Pine.BSF.4.10.9905141052240.50439-100000@janus.syracuse.net> 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:
> 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)
>
Kazu finishing his fb(4) would be quite nice, if he has the time.
> - port GGI to FreeBSD.
Huh? It works for me... GGI is just the API/wrapper, and it allows output to
(most useful now) X and XF86DGA (many, many more of course,, and a FreeBSD fb(4)
would be cool.).
>
> 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
>
Brian Feldman _ __ ___ ____ ___ ___ ___
green@unixhelp.org _ __ ___ | _ ) __| \
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.10.9905141052240.50439-100000>