Type confusion in fbcon

Type confusion in fbcon

[Russell King]

I'm in the midst of porting sa1100fb over to the new fb API, and I stumbled
across an apparant confusion over the type of fb_info->pseudo_palette.

Some code appears to think its an unsigned long, others think its u32.
This doesn't make much difference when sizeof(unsigned long) == sizeof(u32)
but this isn't always the case (eg, 64-bit architectures).

I'll get back to bashing the sa1100fb driver to work out why fbcon is
producing a _completely_ blank display, despite characters being written
to it.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html



-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/

Re: [Linux-fbdev-devel] Type confusion in fbcon

[James Simmons]

> I'm in the midst of porting sa1100fb over to the new fb API, and I stumbled
> across an apparant confusion over the type of fb_info->pseudo_palette.
> 
> Some code appears to think its an unsigned long, others think its u32.
> This doesn't make much difference when sizeof(unsigned long) == sizeof(u32)
> but this isn't always the case (eg, 64-bit architectures).

It show be u32 instead of unsinged long in color_imageblit. Thanks. Fixed.
 
> I'll get back to bashing the sa1100fb driver to work out why fbcon is
> producing a _completely_ blank display, despite characters being written
> to it.

Did you figure out what was wrong?

Re: [Linux-fbdev-devel] Type confusion in fbcon

[Russell King]

On Fri, Dec 20, 2002 at 06:10:17PM +0000, James Simmons wrote:
> > I'll get back to bashing the sa1100fb driver to work out why fbcon is
> > producing a _completely_ blank display, despite characters being written
> > to it.
> 
> Did you figure out what was wrong?

Firstly, setting fix.line_length to zero (which the old API didn't care
about) caused one set of problems.

Secondly, the sa1100fb set_par function doesn't set the var RGB elements -
that's left to the check_var function.  Originally, we effectively did
a fb_set_var which took care of that for us.  Now we explicitly call
our check_var implementation prior to registering the framebuffer
driver with the fbcon core.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [Linux-fbdev-devel] Type confusion in fbcon

[Geert Uytterhoeven]

On Fri, 20 Dec 2002, Russell King wrote:
> On Fri, Dec 20, 2002 at 06:10:17PM +0000, James Simmons wrote:
> > > I'll get back to bashing the sa1100fb driver to work out why fbcon is
> > > producing a _completely_ blank display, despite characters being written
> > > to it.
> > 
> > Did you figure out what was wrong?
> 
> Firstly, setting fix.line_length to zero (which the old API didn't care
> about) caused one set of problems.

That's because originally there was no fix.line_length field, and the line
length was derived from var.xres_virtual and var.bits_per_pixel.

With some hardware, the line length must be a multiple of 32 or 64 bits, and we
needed a way to specify that, so fix.line_length was introduced. If it was
zero, user code should fallback to the old behavior.

Anyway, I think it's good to make fix.line_length mandatory with the new fbdev
API.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Type confusion in fbcon

[David S. Miller]

On Mon, 2002-12-23 at 01:18, Geert Uytterhoeven wrote:
> That's because originally there was no fix.line_length field, and the line
> length was derived from var.xres_virtual and var.bits_per_pixel.
> 
> With some hardware, the line length must be a multiple of 32 or 64 bits, and we
> needed a way to specify that, so fix.line_length was introduced. If it was
> zero, user code should fallback to the old behavior.

And with some cards, the line length is constant.  Ie. to get to
"X, Y + 1" for a given "X, Y" you add a constant to your current
frame buffer pointer.

That is what fix.line_length is for right?

Re: [Linux-fbdev-devel] Type confusion in fbcon

[Geert Uytterhoeven]

On 23 Dec 2002, David S. Miller wrote:
> On Mon, 2002-12-23 at 01:18, Geert Uytterhoeven wrote:
> > That's because originally there was no fix.line_length field, and the line
> > length was derived from var.xres_virtual and var.bits_per_pixel.
> > 
> > With some hardware, the line length must be a multiple of 32 or 64 bits, and we
> > needed a way to specify that, so fix.line_length was introduced. If it was
> > zero, user code should fallback to the old behavior.
> 
> And with some cards, the line length is constant.  Ie. to get to
> "X, Y + 1" for a given "X, Y" you add a constant to your current
> frame buffer pointer.
> 
> That is what fix.line_length is for right?

Yep.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds