From: Martin Schulze (joey@infodrom.org)
Date: Tue Oct 15 2002 - 11:30:48 CEST
Hi James,
we would like to ask for your opinion on whether we should use
FB_TYPE_PACKED_PIXELS or FB_TYPE_PLANES for the framebuffer, since you
are listed as framebuffer maintainer. But let me explain the problem
in detail first.
During this years' Oldenburg Developers Meeting we started to develop
a framebuffer driver for an unsupported monochrome graphics card which
is found in older DECstation machines: PMAG-AA.
This card has an interesting layout. It's got 2MB of video ram,
organized in colums * lines. Each line is 2048 byte large, and
adjacent lines are stored next to each other. So vram[0] refers to
the first byte in line one and vram[2048] refers to the first byte in
line two. Together this makes it 2048 columns and 1024 lines.
The graphic card uses a resolution of 1280x1024 and uses one byte per
pixel, even though it's a monochrome card. All 7 most significant
bits are discarded, or in other words, only the least significant bit
is used.
We can currently not unanimously decide whether the framebuffer type
should be set to FB_TYPE_PACKED_PIXELS or FB_TYPE_PLANES. I would
prefer FB_TYPE_PACKED_PIXELS since all adjacent pixels in one scanline
are stored adjacently in the video ram, even though 7 bits are
discarded between them. Also, FB_TYPE_PACKED_PIXELS is what XFb
supports and there is a -fbbpp <n> argument which makes me think that
it should be possible to tell XFb to ignore 7 bits between two pixels.
What type do you believe we should use for this driver?
For completeness I'm attaching the entire driver. It contains some
additional patches that need to be submitted separately. In order to
do this, I wonder if you would like to receive framebuffer relevant
bits exclusively or if I should submit them to you and Ralf Baechle
(MIPS kernel tree maintainer) concurrently.
Kind regards,
Joey
-- Given enough thrust pigs will fly, but it's not necessarily a good idea.
This archive was generated by hypermail 2.1.4 : Tue Oct 15 2002 - 11:37:13 CEST