On Jun 13, 2004, at 2:23 PM, Blaz Antonic wrote:

> Hello,
>
> First of all, please make sure you CC your replies to me since i'm not
> on this mailing list; thank you :)
>
> I have a couple of questions regarding graphics under console/X on
> NetBSD, i suppose this list is the best place to post such questions at
> (no other list comes any closer to subject at hand).
>
> Short intro: i'm about to finish a certain framebuffer driver for Vax
> port. Hardware supports some acceleration (tested functions listed
> below), the speed-up over CPU handling graphics is immense so i plan to
> employ acceleration in console operation (wscons). Due to my total lack
> of experience in writing X servers i won't be doing that though but i
> want to leave the door open for anybody else who might be interested in
> that.
>
> Supported and tested HW accel functions:
> - block copy (of rasterops)
> - block set (of rasterops)
> - plane extraction (selected 1 bit plane out of 8 planes is extracted)
> - plane expansion (monochrome to 8 plane)
> - text rendering (both opaque and transparent)
> - block copy with mask (of rasterops)
> - clipping rectangle
>
> Supported but untested:
> - all other rasterops (they should all work though, i just haven't
> gotten around to verifying that yet)
>
> Now, my questions are:
>
> 1: console operation (wscons) doesn't seem to require much 
> functionality
> except for block copy/set and font rendering. Is this assumption 
> correct
> ? As in, are there any functions that more advanced wscons driver might
> have that could come in handy ?

I assume it uses stippling for font rendering.

> 2: X server can attach to wscons framebuffer and use it as dumb
> framebuffer; however i'd like to provide a mechanism for X server to be
> able to use HW acceleration too. HW accel mechanism is FIFO-oriented,
> meaning X server would only have to send commands to the kernel and
> kernel would then queue them into FIFO. Dumb framebuffer X server uses
> *mmap() to access the framebuffer, what is the best way to implement 
> the
> command passing mechanism (for HW accel commands to be passed from X
> server to kernel) ? Some sort of a queue or made-up non-standard (=
> made-up) ioctl() calls for each HW accel command type ?

Look at xsrc/xfree/xc/programs/Xserver/hw/netbsd/dec/sfb as an example
how a smart frame buffer is used in the Xserver.

> 3: which of the above-listed HW accel functions would actually be of 
> use
> to X server ? For example, is there any practical use for clipping
> rectangle function (other than setting bounding box around visible
> framebuffer memory) ? It seems like a sad excuse for failure to
> calculate rasterop target dimensions correctly before perforimng the
> rasterop. The plane extraction/expansion functions, what use are they ?
> They can make a fancy monochrome image out of color one or serve as
> alternative font rendering mechanism but do they have any practical use
> ?

Yes.  The LCG was designed to accelerate X operations.

> 4: has anybody here actually written an X server for NetBSD which
> doesn't use the framebuffer in "dumb" mode ? If so, how did you go 
> about
> writing it ? Starting from scratch or by altering a "dumb fb" X server,
> accelerating the X server functions that you could and leaving the rest
> to the CPU ?

See the sfb above...

> 5: what is the maximum size (in bytes) of any X font bitmap set ? I'm
> asking about number of glyphs * size per glyph limit. In theory fonts
> could be as big as one makes them but in reality i suppose there must 
> be
> some limit set for both size of glyph and number of glyphs.
>
> 6: how many fonts (typefaces) can usually be displayed on X server
> screen simultaneously ? Again i suppose in theory there could be any
> number of different font types displayed (up to the number of pixels on
> the screen :-)) but i suppose there is some artificial limit to that
> too.

Not really.

> I am planning to store font bitmaps in off-screen framebuffer memory;
> there is plenty of space to accomodate any wscons font (new bitmaps 
> will
> be loaded on font change) but with multiple huge font bitmaps under X
> which can be displayed simultaneously that space could run out quickly
> so i'm wondering whether this mechanism will work under X too or should
> i be considering some alternatives.

Does LCG actually have that problem?  Can't the fonts be anywhere in
virtually addressable memory?

You should treat that as a font cache.  Keep the fonts in the server
and swap them in as needed.  You should be able to DMA them in quickly.

Also, since you always have a fixed depth, console messages can always
be printed regardless of whether an X server is running
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this 
message.