[PATCH] Framebuffer Layer - Radeonfb, kernel 2.6.5

[PATCH] Framebuffer Layer - Radeonfb, kernel 2.6.5

[Douglas Mayle]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

I've written two small modifications, one to the frame buffer code, and
one to the radeonfb driver.

In fbmem.c, I've added an error message for people who specify a video=
line with an invalid device name to help users save on troubleshooting
time.

In radeonfb_monitor.c the bpp attribute is completely ignored, and 8 is
hardcoded in as a default.  I've changed the code to read the default
bpp from the default mode.  (Most users will never notice the
difference, but I changed the default mode, and was baffled as to why
the color depth didn't change.)

[-- Attachment #2: attach.patch --]
[-- Type: text/x-patch, Size: 1499 bytes --]

--- linux-2.6.5/drivers/video/fbmem.c	2004-04-30 15:02:10.000000000 +0200
+++ patch/drivers/video/fbmem.c	2004-04-30 15:09:03.560390512 +0200
@@ -1470,6 +1470,18 @@
 	 * If we get here no fb was specified.
 	 * We consider the argument to be a global video mode option.
 	 */
+
+	if (strchr(options, ':') != NULL) {
+		/*
+		 * If a colon is in the string, then the user entered
+		 * the wrong name for the fb device.  We'll inform them
+		 * of this.
+		 */
+		int fbnamelen = strchr(options, ':') - options;
+		options[fbnamelen] = '\0';
+		printk ("Requested framebuffer device '%s' not found\n", options);
+		options[fbnamelen] = ':';
+	}
 	global_mode_option = options;
 	return 0;
 }
--- linux-2.6.5/drivers/video/aty/radeon_monitor.c	2004-04-30 15:02:10.000000000 +0200
+++ patch/drivers/video/aty/radeon_monitor.c	2004-04-30 15:09:03.559390664 +0200
@@ -854,12 +854,15 @@
 	 */
 	if (!has_default_mode || mode_option) {
 		struct fb_videomode default_mode;
+		unsigned int default_bpp = 8;
 		if (has_default_mode)
 			radeon_var_to_videomode(&default_mode, &rinfo->info->var);
-		else
+		else {
 			radeon_var_to_videomode(&default_mode, &radeonfb_default_var);
+ 			default_bpp = radeonfb_default_var.bits_per_pixel;
+		}
 		if (fb_find_mode(&rinfo->info->var, rinfo->info, mode_option,
-				 rinfo->mon1_modedb, rinfo->mon1_dbsize, &default_mode, 8) == 0)
+				 rinfo->mon1_modedb, rinfo->mon1_dbsize, &default_mode, default_bpp) == 0)
 			rinfo->info->var = radeonfb_default_var;
 	}
 

Re: [PATCH] Framebuffer Layer - Radeonfb, kernel 2.6.5

[Timothy Miller]

One bug I've noticed with the 2.4 radeonfb driver is this:

If you specify a resolution different from what EDID reports, what you 
get on screen is the resolution reported by EDID physically, but 
virtually the resolution requested.  That is, if I ask for 1280x1024, 
but EDID says 1024x768, I see the upper left 1024x768 of the 1280x1024 
screen that the console is being displayed on.



Douglas Mayle wrote:
> I've written two small modifications, one to the frame buffer code, and
> one to the radeonfb driver.
> 
> In fbmem.c, I've added an error message for people who specify a video=
> line with an invalid device name to help users save on troubleshooting
> time.
> 
> In radeonfb_monitor.c the bpp attribute is completely ignored, and 8 is
> hardcoded in as a default.  I've changed the code to read the default
> bpp from the default mode.  (Most users will never notice the
> difference, but I changed the default mode, and was baffled as to why
> the color depth didn't change.)
> 
> 
> ------------------------------------------------------------------------
> 
> --- linux-2.6.5/drivers/video/fbmem.c	2004-04-30 15:02:10.000000000 +0200
> +++ patch/drivers/video/fbmem.c	2004-04-30 15:09:03.560390512 +0200
> @@ -1470,6 +1470,18 @@
>  	 * If we get here no fb was specified.
>  	 * We consider the argument to be a global video mode option.
>  	 */
> +
> +	if (strchr(options, ':') != NULL) {
> +		/*
> +		 * If a colon is in the string, then the user entered
> +		 * the wrong name for the fb device.  We'll inform them
> +		 * of this.
> +		 */
> +		int fbnamelen = strchr(options, ':') - options;
> +		options[fbnamelen] = '\0';
> +		printk ("Requested framebuffer device '%s' not found\n", options);
> +		options[fbnamelen] = ':';
> +	}
>  	global_mode_option = options;
>  	return 0;
>  }
> --- linux-2.6.5/drivers/video/aty/radeon_monitor.c	2004-04-30 15:02:10.000000000 +0200
> +++ patch/drivers/video/aty/radeon_monitor.c	2004-04-30 15:09:03.559390664 +0200
> @@ -854,12 +854,15 @@
>  	 */
>  	if (!has_default_mode || mode_option) {
>  		struct fb_videomode default_mode;
> +		unsigned int default_bpp = 8;
>  		if (has_default_mode)
>  			radeon_var_to_videomode(&default_mode, &rinfo->info->var);
> -		else
> +		else {
>  			radeon_var_to_videomode(&default_mode, &radeonfb_default_var);
> + 			default_bpp = radeonfb_default_var.bits_per_pixel;
> +		}
>  		if (fb_find_mode(&rinfo->info->var, rinfo->info, mode_option,
> -				 rinfo->mon1_modedb, rinfo->mon1_dbsize, &default_mode, 8) == 0)
> +				 rinfo->mon1_modedb, rinfo->mon1_dbsize, &default_mode, default_bpp) == 0)
>  			rinfo->info->var = radeonfb_default_var;
>  	}
>  

Re: [PATCH] Framebuffer Layer - Radeonfb, kernel 2.6.5

[Douglas Mayle]

> If you specify a resolution different from what EDID reports, what you 
> get on screen is the resolution reported by EDID physically, but 
> virtually the resolution requested.  That is, if I ask for 1280x1024, 
> but EDID says 1024x768, I see the upper left 1024x768 of the 1280x1024 
> screen that the console is being displayed on.

I'm not sure I'd call that a bug.  You've set the resolution
specifically, and the driver does it's best to give you what you've
requested.

Re: [PATCH] Framebuffer Layer - Radeonfb, kernel 2.6.5

[Timothy Miller]

Douglas Mayle wrote:
>>If you specify a resolution different from what EDID reports, what you 
>>get on screen is the resolution reported by EDID physically, but 
>>virtually the resolution requested.  That is, if I ask for 1280x1024, 
>>but EDID says 1024x768, I see the upper left 1024x768 of the 1280x1024 
>>screen that the console is being displayed on.
> 
> 
> I'm not sure I'd call that a bug.  You've set the resolution
> specifically, and the driver does it's best to give you what you've
> requested.


It does not give me what I requested.  I requested 1280x1024.  I get a 
broken 1024x768.

I know that when EDID reports only 1280x1024, everything works fine, but 
for whatever reason, my LCD monitor reports 1024x768 first, and that's 
what it uses.

I did some searching, and I'm not the only person who reports this 
problem.  I found a patch for it online.  I'll see if I can't dig that 
up for you.