Menu
▾
▴
linux-fbdev-devel
|
From: Russell K. <rm...@ar...> - 2002-12-19 23:15:28
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@in...> - 2002-12-20 18:11:25
|
> 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? |
|
From: Russell K. <rm...@ar...> - 2002-12-20 21:32:11
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Geert U. <ge...@li...> - 2002-12-23 09:20:23
|
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 -- ge...@li...
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. M. <da...@re...> - 2002-12-23 20:42:48
|
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? |
|
From: Geert U. <ge...@li...> - 2002-12-23 21:20:11
|
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 -- ge...@li...
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
|
Thanks for helping keep SourceForge clean.
X