* Type confusion in fbcon
@ 2002-12-19 23:14 ` Russell King
0 siblings, 0 replies; 8+ messages in thread
From: Russell King @ 2002-12-19 23:14 UTC (permalink / raw
To: Linux Kernel List, linux-fbdev-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Type confusion in fbcon
@ 2002-12-19 23:14 ` Russell King
0 siblings, 0 replies; 8+ messages in thread
From: Russell King @ 2002-12-19 23:14 UTC (permalink / raw
To: Linux Kernel List, linux-fbdev-devel
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Type confusion in fbcon
2002-12-19 23:14 ` Russell King
@ 2002-12-20 18:10 ` James Simmons
-1 siblings, 0 replies; 8+ messages in thread
From: James Simmons @ 2002-12-20 18:10 UTC (permalink / raw
To: Russell King; +Cc: Linux Kernel List, linux-fbdev-devel
> 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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Type confusion in fbcon
@ 2002-12-20 18:10 ` James Simmons
0 siblings, 0 replies; 8+ messages in thread
From: James Simmons @ 2002-12-20 18:10 UTC (permalink / raw
To: Russell King; +Cc: Linux Kernel List, linux-fbdev-devel
> 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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Type confusion in fbcon
2002-12-20 18:10 ` James Simmons
(?)
@ 2002-12-20 21:30 ` Russell King
2002-12-23 9:18 ` Geert Uytterhoeven
-1 siblings, 1 reply; 8+ messages in thread
From: Russell King @ 2002-12-20 21:30 UTC (permalink / raw
To: James Simmons; +Cc: Linux Kernel List, linux-fbdev-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Type confusion in fbcon
2002-12-20 21:30 ` Russell King
@ 2002-12-23 9:18 ` Geert Uytterhoeven
2002-12-23 21:11 ` David S. Miller
0 siblings, 1 reply; 8+ messages in thread
From: Geert Uytterhoeven @ 2002-12-23 9:18 UTC (permalink / raw
To: Russell King
Cc: James Simmons, Linux Kernel List,
Linux Frame Buffer Device Development
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Type confusion in fbcon
2002-12-23 9:18 ` Geert Uytterhoeven
@ 2002-12-23 21:11 ` David S. Miller
2002-12-23 21:17 ` Geert Uytterhoeven
0 siblings, 1 reply; 8+ messages in thread
From: David S. Miller @ 2002-12-23 21:11 UTC (permalink / raw
To: Geert Uytterhoeven
Cc: Russell King, James Simmons, Linux Kernel List,
Linux Frame Buffer Device Development
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Type confusion in fbcon
2002-12-23 21:11 ` David S. Miller
@ 2002-12-23 21:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 8+ messages in thread
From: Geert Uytterhoeven @ 2002-12-23 21:17 UTC (permalink / raw
To: David S. Miller
Cc: Russell King, James Simmons, Linux Kernel List,
Linux Frame Buffer Device Development
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-12-23 21:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-19 23:14 Type confusion in fbcon Russell King
2002-12-19 23:14 ` Russell King
2002-12-20 18:10 ` [Linux-fbdev-devel] " James Simmons
2002-12-20 18:10 ` James Simmons
2002-12-20 21:30 ` Russell King
2002-12-23 9:18 ` Geert Uytterhoeven
2002-12-23 21:11 ` David S. Miller
2002-12-23 21:17 ` Geert Uytterhoeven
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.