Subject: A couple of questions about console/X graphics
To: None <tech-x11@NetBSD.org>
From: Blaz Antonic <blaz.antonic@siol.net>
List: tech-x11
Date: 06/13/2004 14:23:30
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 ?

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 ?

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
?

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 ?

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.

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.

Blaz Antonic