Date: Tue, 18 May 1999 01:37:53 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Kelly Yancey <kbyanc@alcnet.com>, freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: modex support (again) Message-ID: <199905171637.BAA01434@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "14 May 1999 16:05:02 %2B0200." <xzpso8z3fxt.fsf@localhost.ping.uio.no> References: <Pine.BSF.4.05.9905140930300.52692-100000@kronos.alcnet.com> <xzpso8z3fxt.fsf@localhost.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for not participating in your earlier discussion, I have been
kept busy by my work ;-<
The current VGA driver code won't do much in the graphics mode. It
simply switches to a graphics mode when requested, but it has no code
to actually write anything to the video buffer in the graphics mode.
(Well, there is a exception, really. Syscons can use the VESA 800x600
mode as the raster text mode... But, the video driver is still drawing
nothing in this case as well; it is syscons which knows this mode and
is writing.)
In that sense, the support for 320x240 mode-X is minimal too. The
driver can set up this mode, but has no knowledge or code to write to
it. It is entirely up to the userland program to update the video
buffer. (And it is true that there is very little use to this mode at
the moment as we haven't seen anybody using it...)
I think the basic video driver should just provide the interface to
change the video mode and the access to the video buffer; it shouldn't
have feature-rich, do-everything API to draw fancy graphics (it may
provide such simple functions as "clear screen", though). Such useful
but complicated drawing functions should be left to GGI, libvgl or
similar libraries.
As for frame buffer access, I am currently working on video driver and
syscons udpate and try to provide the linear frame buffer access mode.
The current snapshot just uses the VESA 2.0 function to set up the
linear frame buffer. If the video card supports VESA 1.2 or earlier
or doesn't support VESA at all, the linear frame buffer won't be
available. The current implementation doesn't simulate the linear
frame buffer for these cards; your program needs to "switch" banks to
access the entire range of the frame buffer.
The frame buffer, linear or windowed, can be `mmap()'ed by the user
program so long as it has sufficient privilege to access a vty.
Please have a look at
http://www.freebsd.org/~yokota/syscons-update.17May.tar.gz
It's not finished yet, but may give you some ideas.
Kazu
>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.
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?199905171637.BAA01434>