Bug in vga16fb?

Bug in vga16fb?

[Ondrej Zajicek]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Hello

I tried vga16fb driver in 320x200x4 nonstd mode (on i386 - little endian). In
this mode framebuffer reports PACKED PIXELS type. Drawing through framebuffer
is OK, but console is broken - it looks like that even and odd columns are
exchanged.

Framebuffer structure of this mode is that even pixel is in high nibble and
odd pixel is in low nibble.

It looks like vga16fb use cfbimgblt.c/slow_imageblit in this mode for
image-blit and this function in CFB4 writes even pixel in low nibble and
odd pixel in high nibble.

What is correct framebuffer structure for CFB4 mode?

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Bug in vga16fb?

[Petr Vandrovec]

Ondrej Zajicek wrote:
> Hello
> 
> I tried vga16fb driver in 320x200x4 nonstd mode (on i386 - little endian). In
> this mode framebuffer reports PACKED PIXELS type. Drawing through framebuffer
> is OK, but console is broken - it looks like that even and odd columns are
> exchanged.
> 
> Framebuffer structure of this mode is that even pixel is in high nibble and
> odd pixel is in low nibble.
> 
> It looks like vga16fb use cfbimgblt.c/slow_imageblit in this mode for
> image-blit and this function in CFB4 writes even pixel in low nibble and
> odd pixel in high nibble.
> 
> What is correct framebuffer structure for CFB4 mode?

Unfortunately there is no standard, as CFB4 itself is quite non-standard VGA 
mode.  Some videocards first output low nibble, followed by high, and some do 
otherwise.  I've experimented with this back in 2000, and I've found that Matrox 
Millennium does exactly opposite than some ATI Mach64 card I had in another box 
at that time.

So your only option is providing two CFB4 modes.  Unfortunately I have no idea 
how to autodetect what your hardware actually does without adding camera to the 
system...
							Petr Vandrovec



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Bug in vga16fb?

[Ondrej Zajicek]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

On Thu, Apr 06, 2006 at 12:48:48AM +0200, Petr Vandrovec wrote:
> Ondrej Zajicek wrote:
> >Hello
> >
> >I tried vga16fb driver in 320x200x4 nonstd mode (on i386 - little endian). 
> >In
> >this mode framebuffer reports PACKED PIXELS type. Drawing through 
> >framebuffer
> >is OK, but console is broken - it looks like that even and odd columns are
> >exchanged.
> >
> >Framebuffer structure of this mode is that even pixel is in high nibble and
> >odd pixel is in low nibble.
> >
> >It looks like vga16fb use cfbimgblt.c/slow_imageblit in this mode for
> >image-blit and this function in CFB4 writes even pixel in low nibble and
> >odd pixel in high nibble.
> >
> >What is correct framebuffer structure for CFB4 mode?
> 
> Unfortunately there is no standard, as CFB4 itself is quite non-standard 
> VGA mode.  Some videocards first output low nibble, followed by high, and 
> some do otherwise.  I've experimented with this back in 2000, and I've 
> found that Matrox Millennium does exactly opposite than some ATI Mach64 
> card I had in another box at that time.
> 
> So your only option is providing two CFB4 modes.  Unfortunately I have no 
> idea how to autodetect what your hardware actually does without adding 
> camera to the system...

Even if we find some possibility to autodetect what hardware does (or in
case of another, non-VGA hardware using CFB4 mode) there would be
problem that driver cannot say it to userspace (or generic kernel
functions like cfb_imageblit). Maybe there should be some flag in
type_aux specifying whether given packed pixel mode is LSB-first or
MSB-first (relevant only for bpp % 8 != 0) ?

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Bug in vga16fb?

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> On Thu, Apr 06, 2006 at 12:48:48AM +0200, Petr Vandrovec wrote:
>> Ondrej Zajicek wrote:
> 
> Even if we find some possibility to autodetect what hardware does (or in
> case of another, non-VGA hardware using CFB4 mode) there would be
> problem that driver cannot say it to userspace (or generic kernel
> functions like cfb_imageblit). Maybe there should be some flag in
> type_aux specifying whether given packed pixel mode is LSB-first or
> MSB-first (relevant only for bpp % 8 != 0) ?
> 

var->{red|green|blue|transp}.msb_right

This field is currently ignored by fbcon, but you can use this field to
inform userspace what you want.

And once a driver uses this flag, we can probably alter the drawing
functions to not ignore this flag.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Bug in vga16fb?

[Ondrej Zajicek]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

On Thu, Apr 06, 2006 at 09:56:42PM +0800, Antonino A. Daplas wrote:
> Ondrej Zajicek wrote:
> > On Thu, Apr 06, 2006 at 12:48:48AM +0200, Petr Vandrovec wrote:
> >> Ondrej Zajicek wrote:
> > 
> > Even if we find some possibility to autodetect what hardware does (or in
> > case of another, non-VGA hardware using CFB4 mode) there would be
> > problem that driver cannot say it to userspace (or generic kernel
> > functions like cfb_imageblit). Maybe there should be some flag in
> > type_aux specifying whether given packed pixel mode is LSB-first or
> > MSB-first (relevant only for bpp % 8 != 0) ?
> > 
> 
> var->{red|green|blue|transp}.msb_right

I think that this bit says something different - ordering of bits inside
one color component. This is OK for all VGA (MSB bit of color index is
left), i hope.

Problem is in ordering of pixels inside a byte, which is completely
orthogonal to bitplane.msb_right-ness.

But maybe i misunderstood of meaning of 
var->{red|green|blue|transp}.msb_right ...


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Bug in vga16fb?

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> On Thu, Apr 06, 2006 at 09:56:42PM +0800, Antonino A. Daplas wrote:
>> Ondrej Zajicek wrote:
>>> On Thu, Apr 06, 2006 at 12:48:48AM +0200, Petr Vandrovec wrote:
>>>> Ondrej Zajicek wrote:
>>> Even if we find some possibility to autodetect what hardware does (or in
>>> case of another, non-VGA hardware using CFB4 mode) there would be
>>> problem that driver cannot say it to userspace (or generic kernel
>>> functions like cfb_imageblit). Maybe there should be some flag in
>>> type_aux specifying whether given packed pixel mode is LSB-first or
>>> MSB-first (relevant only for bpp % 8 != 0) ?
>>>
>> var->{red|green|blue|transp}.msb_right
> 
> I think that this bit says something different - ordering of bits inside
> one color component. This is OK for all VGA (MSB bit of color index is
> left), i hope.
> 
> Problem is in ordering of pixels inside a byte, which is completely
> orthogonal to bitplane.msb_right-ness.
> 
> But maybe i misunderstood of meaning of 
> var->{red|green|blue|transp}.msb_right ...
> 
> 

I know, but since it is completely unused, you can use that to tell userspace
what the format is.  Or if you want something less specific, use var->nonstd.
Or if you want to standardize, add another FB_VISUAL_* entry.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642