To: Andrew Doran <firstname.lastname@example.org>
From: Michael <email@example.com>
Date: 03/22/2005 21:10:14
-----BEGIN PGP SIGNED MESSAGE-----
>> Hmm, but maybe generic raspos handler requires only "bit per pixel,"
>> doesn't it? "The actually significant number of bits" is provided
>> by info of each color in other members, I think.
> I was thinking of the TC mfb, which is mono but uses byte addressing.
> Only the lowest bit is significant (so depth of 1 and bpp of 8). Are
> there other devices like that?
Yes. Various HP framebuffers found in hp300 machines, like the CatsEye
- - depth 6, bpp 8 ( or more? I'm not too sure... ). Tomcat uses depth 1
bpp 8 if I remember correctly.
>> I think such device specific features could be determined by
> It may not be possible to drive certain types of display with the
> usual code (as is the case with the PixelStamp, no direct FB access).
> Rather than teaching the X server about each of the black sheep, why
> not have a flag passed down by the kernel?
This looks awfully like exposing a bunch of functions to userland and
let the driver decide which ones to accelerate by hardware... before we
know it we have half a GDI in the kernel. On the other hand - we
already do, there's just no abstraction layer to make it accessible
These could be:
- - copy a buffer of pixel data into a rectangle in the framebuffer,
maybe with optional 1bit->screen depth expansion
- - screen-to-screen copy
- - fill a rectangle
All these are either trivial or already implemented by either rasops or
An API for hardware cursors is already in place, just not implemented
by most drivers ( including mine... )
Most accelerated wsdisplay drivers have generic bitblt() and rectfill()
functions, some also do colour expansion in hardware - at least mine
>>> - a flag to indicate whether or not colormap changes are accepted?
>>> Not entirely necessary, but nice to have.
>> Can't we check it by a return value of WSDISPLAYIO_GETCMAP or
> I agree with your suggestion here.
Seems the most sensible thing to do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----