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 |