From: Russell King <hidden> Date: 2002-12-20 21:22:56
On Fri, Dec 20, 2002 at 06:10:17PM +0000, James Simmons wrote:
quoted
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
On Fri, Dec 20, 2002 at 06:10:17PM +0000, James Simmons wrote:
quoted
quoted
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
From: David S. Miller <hidden> Date: 2002-12-23 20:34:39
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?
On Mon, 2002-12-23 at 01:18, Geert Uytterhoeven wrote:
quoted
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