mono, gray and index configs

mono, gray and index configs

[Jon Smirl]

When filling in a fb_var_screeninfo how do I ask for mono, gray and
index configs? Is is always request length red and green/blue length =
zero to indicate a mono, gray or index config? Then grayscale is used
to differentiate gray/mono from indexed?

Are there any more tricks to asking for a config? One trick I see is
if bpp is set to a value where the hardware only supports one format
at that bpp, ignore rbgt and set the config.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Antonino A. Daplas]

Jon Smirl wrote:
> When filling in a fb_var_screeninfo how do I ask for mono, gray and
> index configs? Is is always request length red and green/blue length =
> zero to indicate a mono, gray or index config? Then grayscale is used
> to differentiate gray/mono from indexed?

For pseudocolor (indexed), just indicate all offsets = 0 and all
lengths equal to each other.

For monochrome, usually set bits_per_pixel = 1. (This is however not always
true, as it's possible to have 2-color display with bits_per_pixel > 1).
It's also possible to have mono01, mono10, 1-bit pseudocolor, 1-bit truecolor.
For 1-bit truecolor, you can only use a primary color for the "foreground".
So only one of the rgba will have a length = 1, the rest are zero. For
monochrome/1-bit pseudocolor, it's similar to setting for pseudocolor except
that all the lengths = 1 and offsets = 0.  Currently, we have no way to
specifically request for mono01, mono10, or 1-bit pseudocolor. Just check
for fix->visual afterwards.  

For grayscale, you use whatever format you want but you have to set
var->grayscale to nonzero. (Grayscale just means that r=g=b, for those
drivers that want to emulate grayscale).

For directcolor (indexed) vs truecolor, there is currently no way
to specify which visual you want.  You also have to check for fix->visual
afterwards.

One of the reason I also want this sysfs attribute is because in at
least 1 driver (i810fb), it's possible to choose between truecolor and
directcolor but it uses a hack by checking for the var->nonstd flag.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Wed, 10 Aug 2005, Jon Smirl wrote:
> Are there any more tricks to asking for a config? One trick I see is
> if bpp is set to a value where the hardware only supports one format
> at that bpp, ignore rbgt and set the config.

Ignoring is not allowed, but rounding up is.

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Thu, 11 Aug 2005, Antonino A. Daplas wrote:
> that all the lengths = 1 and offsets = 0.  Currently, we have no way to
> specifically request for mono01, mono10, or 1-bit pseudocolor. Just check
> for fix->visual afterwards.  

For mono01 or mono10, if the visual is pseudocolor, just set the colormap to
black/white or white/black.

> For directcolor (indexed) vs truecolor, there is currently no way
> to specify which visual you want.  You also have to check for fix->visual
> afterwards.
> 
> One of the reason I also want this sysfs attribute is because in at
> least 1 driver (i810fb), it's possible to choose between truecolor and
> directcolor but it uses a hack by checking for the var->nonstd flag.

So the driver should use directcolor instead of truecolor if the hardware
supports it. The application can always set a linear colormap if it needs
truecolor.

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Antonino Daplas]

On 8/11/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, 11 Aug 2005, Antonino A. Daplas wrote:
> > that all the lengths = 1 and offsets = 0.  Currently, we have no way to
> > specifically request for mono01, mono10, or 1-bit pseudocolor. Just check
> > for fix->visual afterwards.
> 
> For mono01 or mono10, if the visual is pseudocolor, just set the colormap to
> black/white or white/black.


I don't know. If I can change the colormap, I would  advertise this as
1-bit pseudocolor, not monochrome.  Otherwise, why differentiate
between mono01 and mono10 if I can control what color is 0 and what
color is 1.  I think the closest definition of monochrome is 1-bit
static pseudocolor.  And we just have mono01 and mono10 to advertise
how hardware treats 0/1 (background/foreground or reverse).

I have a few things that are still not clear to me.  If I understand
it correctly, monochrome means 2 colors regardless of the bit depth. 
So it's possible, for example, to have 8-bit monochrome that has only
two colors, ie 0x00 and 0xff.   If this was 8-bit static pseudocolor,
then it has 256 different colors.

(Depending on how correct I am with the interpretation, there might be
some bugs in fbdev on how it determines the color depth. No one is
complaining yet though, so greater than 1-bit monochrome is probably
rare if not nonexistent.)

> 
> > For directcolor (indexed) vs truecolor, there is currently no way
> > to specify which visual you want.  You also have to check for fix->visual
> > afterwards.
> >
> > One of the reason I also want this sysfs attribute is because in at
> > least 1 driver (i810fb), it's possible to choose between truecolor and
> > directcolor but it uses a hack by checking for the var->nonstd flag.
> 
> So the driver should use directcolor instead of truecolor if the hardware
> supports it. The application can always set a linear colormap if it needs
> truecolor.


A few years ago, I discovered that there are several fbdev apps that
make ssumptions which are not necessarily correct.  For example, if
bits_per_pixel > 8, the app assumes the format is truecolor. So the
app produces wrong colors if fbdev is in directcolor mode (because it
failed to set the cmap).

So, it is useful to have the capability to choose between truecolor
and directcolor when dealing with those apps without rebooting or
recompiling.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Thu, 11 Aug 2005, Antonino Daplas wrote:
> On 8/11/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, 11 Aug 2005, Antonino A. Daplas wrote:
> > > that all the lengths = 1 and offsets = 0.  Currently, we have no way to
> > > specifically request for mono01, mono10, or 1-bit pseudocolor. Just check
> > > for fix->visual afterwards.
> > 
> > For mono01 or mono10, if the visual is pseudocolor, just set the colormap to
> > black/white or white/black.
> 
> I don't know. If I can change the colormap, I would  advertise this as
> 1-bit pseudocolor, not monochrome.  Otherwise, why differentiate
> between mono01 and mono10 if I can control what color is 0 and what
> color is 1.  I think the closest definition of monochrome is 1-bit
> static pseudocolor.  And we just have mono01 and mono10 to advertise
> how hardware treats 0/1 (background/foreground or reverse).

Yes, for advertisement, that's true (cfr. amifb with bpp = 1, which is
pseudocolor).

But when the app needs monochrome, it can ask for 1 bpp. If it returns a mono
visual, fine. If it returns a pseudocolor visual, set the colormap to
black/white.

> I have a few things that are still not clear to me.  If I understand
> it correctly, monochrome means 2 colors regardless of the bit depth. 

Monochrome means 2 colors, which are black and white (or white and black). If
the colors are different, it's (static) pseudocolor.

In fact monochrome is a special case of static pseudocolor.

> So it's possible, for example, to have 8-bit monochrome that has only
> two colors, ie 0x00 and 0xff.   If this was 8-bit static pseudocolor,

Yes, cfr. old HP9000/300 graphics hardware.

> then it has 256 different colors.

Yes.

> (Depending on how correct I am with the interpretation, there might be
> some bugs in fbdev on how it determines the color depth. No one is
> complaining yet though, so greater than 1-bit monochrome is probably
> rare if not nonexistent.)

There definitely are bugs w.r.t. this, especially in the 2.4 logo code ;-)

> > > For directcolor (indexed) vs truecolor, there is currently no way
> > > to specify which visual you want.  You also have to check for fix->visual
> > > afterwards.
> > >
> > > One of the reason I also want this sysfs attribute is because in at
> > > least 1 driver (i810fb), it's possible to choose between truecolor and
> > > directcolor but it uses a hack by checking for the var->nonstd flag.
> > 
> > So the driver should use directcolor instead of truecolor if the hardware
> > supports it. The application can always set a linear colormap if it needs
> > truecolor.
> 
> A few years ago, I discovered that there are several fbdev apps that
> make ssumptions which are not necessarily correct.  For example, if
> bits_per_pixel > 8, the app assumes the format is truecolor. So the
> app produces wrong colors if fbdev is in directcolor mode (because it
> failed to set the cmap).

That's true. Many apps handle only a very limited subset of all capabilities,
and fail miserably if the assumptions they make are not valid.

> So, it is useful to have the capability to choose between truecolor
> and directcolor when dealing with those apps without rebooting or
> recompiling.

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Antonino A. Daplas]

Geert Uytterhoeven wrote:
> On Thu, 11 Aug 2005, Antonino Daplas wrote:
>> On 8/11/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Thu, 11 Aug 2005, Antonino A. Daplas wrote:
>>>> that all the lengths = 1 and offsets = 0.  Currently, we have no way to
>>>> specifically request for mono01, mono10, or 1-bit pseudocolor. Just check
>>>> for fix->visual afterwards.
>>> For mono01 or mono10, if the visual is pseudocolor, just set the colormap to
>>> black/white or white/black.
>> I don't know. If I can change the colormap, I would  advertise this as
>> 1-bit pseudocolor, not monochrome.  Otherwise, why differentiate
>> between mono01 and mono10 if I can control what color is 0 and what
>> color is 1.  I think the closest definition of monochrome is 1-bit
>> static pseudocolor.  And we just have mono01 and mono10 to advertise
>> how hardware treats 0/1 (background/foreground or reverse).
> 
> Yes, for advertisement, that's true (cfr. amifb with bpp = 1, which is
> pseudocolor).
> 

Ok.

> But when the app needs monochrome, it can ask for 1 bpp. If it returns a mono
> visual, fine. If it returns a pseudocolor visual, set the colormap to
> black/white.
> 
>> I have a few things that are still not clear to me.  If I understand
>> it correctly, monochrome means 2 colors regardless of the bit depth. 
> 
> Monochrome means 2 colors, which are black and white (or white and black). If
> the colors are different, it's (static) pseudocolor.
> 
> In fact monochrome is a special case of static pseudocolor.

Ok.

> 
>> So it's possible, for example, to have 8-bit monochrome that has only
>> two colors, ie 0x00 and 0xff.   If this was 8-bit static pseudocolor,
> 
> Yes, cfr. old HP9000/300 graphics hardware.
> 

Hmm.  Yes, there's a bug in fbdev then with regards to this hardware.

>> then it has 256 different colors.
> 
> Yes.
> 
>> (Depending on how correct I am with the interpretation, there might be
>> some bugs in fbdev on how it determines the color depth. No one is
>> complaining yet though, so greater than 1-bit monochrome is probably
>> rare if not nonexistent.)
> 
> There definitely are bugs w.r.t. this, especially in the 2.4 logo code ;-)
> 

Yes, I would agree.  Do you know of any outstanding bugs on color handling
in 2.6 code, especially for hardware with bitdepths < 8? I would like to
fix them.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Jon Smirl]

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

Here's a new version that actually lets me set all possible scanout
configs on radeonfb. I can even set I4 but I don't think the code is
correct for it yet everywhere in radeonfb. The core code in the patch
should be ok. My further changes should be restricted to the radeonfb
code. For example, I haven't added the logic to radeonfb to "round up"
to the next config.

You get two new sysfs attributes:
configs - optional, but really nice to have, list of all configs
supported by the driver
config - current config the hardware is set to.

example syntax...
[root@jonsmirl fb0]# cat configs
I4
I8
A1R5G5B5
R5G6B5
R8G8B8
A8R8G8B8
A4R4G4B4
A8I8
A2R10G10B10

Offsets are computed from the field widths. So if a card sets BGR vs
RGB and you cat its config you will see RGB or BGR in the config
string. M is used for a grayscale field.

So give the patch a try and start expanding it to handle other cards.

-- 
Jon Smirl
jonsmirl@gmail.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: snap.diff --]
[-- Type: text/x-diff; name="snap.diff", Size: 18091 bytes --]

diff --git a/drivers/video/aty/radeon_accel.c b/drivers/video/aty/radeon_accel.c
--- a/drivers/video/aty/radeon_accel.c
+++ b/drivers/video/aty/radeon_accel.c
@@ -48,7 +48,7 @@ static void radeonfb_prim_fillrect(struc
 		rinfo->dp_gui_master_cntl  /* contains, like GMC_DST_32BPP */
                 | GMC_BRUSH_SOLID_COLOR
                 | ROP3_P);
-	if (radeon_get_dstbpp(rinfo->depth) != DST_8BPP)
+	if ((rinfo->format == PIX_WIDTH_I4) || (rinfo->format == PIX_WIDTH_I8) || (rinfo->format == PIX_WIDTH_A8I8))
 		OUTREG(DP_BRUSH_FRGD_CLR, rinfo->pseudo_palette[region->color]);
 	else
 		OUTREG(DP_BRUSH_FRGD_CLR, region->color);
@@ -252,8 +252,6 @@ void radeonfb_engine_reset(struct radeon
 
 void radeonfb_engine_init (struct radeonfb_info *rinfo)
 {
-	unsigned long temp;
-
 	/* disable 3D engine */
 	OUTREG(RB3D_CNTL, 0);
 
@@ -287,8 +285,7 @@ void radeonfb_engine_init (struct radeon
 	OUTREG(DEFAULT_SC_BOTTOM_RIGHT, (DEFAULT_SC_RIGHT_MAX |
 					 DEFAULT_SC_BOTTOM_MAX));
 
-	temp = radeon_get_dstbpp(rinfo->depth);
-	rinfo->dp_gui_master_cntl = ((temp << 8) | GMC_CLR_CMP_CNTL_DIS);
+	rinfo->dp_gui_master_cntl = ((rinfo->format << 8) | GMC_CLR_CMP_CNTL_DIS);
 
 	radeon_fifo_wait (1);
 	OUTREG(DP_GUI_MASTER_CNTL, (rinfo->dp_gui_master_cntl |
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -722,99 +722,124 @@ static int radeonfb_check_var (struct fb
 {
 	struct radeonfb_info *rinfo = info->par;
         struct fb_var_screeninfo v;
-        int nom, den;
+        int nom = 0, den = 0;
 	unsigned int pitch;
 
 	if (radeon_match_mode(rinfo, &v, var))
 		return -EINVAL;
 
+	v.red.offset = v.green.offset = v.blue.offset = 0;
+	v.red.length = v.blue.length = 0;
+	v.transp.offset = v.transp.length = 0;
+
         switch (v.bits_per_pixel) {
-		case 0 ... 8:
-			v.bits_per_pixel = 8;
+	case 4:
+		nom = 1;
+		den = 2;
+		v.red.length = v.green.length = v.blue.length = 4;
+		rinfo->format = PIX_WIDTH_I4;
+		break;
+	case 8:
+		nom = den = 1;
+		v.red.length = v.green.length = v.blue.length = 8;
+		rinfo->format = PIX_WIDTH_I8;
+		break;
+	case 16:
+		nom = 2;
+		den = 1;
+		switch (v.green.length) {
+		case 4:
+			v.transp.offset = 12;
+			v.red.offset = 8;
+			v.green.offset = v.red.length = v.blue.length = v.transp.length = 4;
+			rinfo->format = PIX_WIDTH_A4R4B4G4;
 			break;
-		case 9 ... 16:
-			v.bits_per_pixel = 16;
+		case 5:
+			v.red.offset = 10;
+			v.green.offset = 5;
+			v.transp.offset = 15;
+			v.red.length = v.blue.length = 5;
+			v.transp.length = 1;
+			rinfo->format = PIX_WIDTH_A1R5G5B5;
 			break;
-		case 17 ... 24:
-#if 0 /* Doesn't seem to work */
-			v.bits_per_pixel = 24;
+		case 6:
+			v.red.offset = 11;
+			v.green.offset = 5;
+			v.red.length = 5;
+			v.blue.length = 5;
+			rinfo->format = PIX_WIDTH_R5G6B5;
 			break;
-#endif			
-			return -EINVAL;
-		case 25 ... 32:
-			v.bits_per_pixel = 32;
+		case 0:
+		case 8:
+			v.transp.offset = 8;
+			v.red.length = v.green.length = v.blue.length = 8;
+			v.transp.length = 8;
+			rinfo->format = PIX_WIDTH_A8I8;
 			break;
 		default:
-			return -EINVAL;
-	}
-
-	switch (var_to_depth(&v)) {
-                case 8:
-                        nom = den = 1;
-                        v.red.offset = v.green.offset = v.blue.offset = 0;
-                        v.red.length = v.green.length = v.blue.length = 8;
-                        v.transp.offset = v.transp.length = 0;
-                        break;
-		case 15:
-			nom = 2;
-			den = 1;
-			v.red.offset = 10;
-			v.green.offset = 5;
-			v.blue.offset = 0;
-			v.red.length = v.green.length = v.blue.length = 5;
-			v.transp.offset = v.transp.length = 0;
+			goto err;
+		}
+		break;
+	case 24:
+		nom = 3;
+		den = 1;
+		v.red.offset = 16;
+		v.green.offset = 8;
+		v.blue.offset = 0;
+		v.red.length = v.blue.length = v.green.length = 8;
+		rinfo->format = PIX_WIDTH_R8B8G8;
+		break;
+	case 32:
+		nom = 4;
+		den = 1;
+		switch (v.green.length) {
+		case 10:
+			v.red.offset = 20;
+			v.green.offset = 10;
+			v.transp.offset = 30;
+			v.blue.length = v.red.length = 10;
+			v.transp.length = 2;
+			rinfo->format = PIX_WIDTH_A2R10G10B10;
 			break;
-                case 16:
-                        nom = 2;
-                        den = 1;
-                        v.red.offset = 11;
-                        v.green.offset = 5;
-                        v.blue.offset = 0;
-                        v.red.length = 5;
-                        v.green.length = 6;
-                        v.blue.length = 5;
-                        v.transp.offset = v.transp.length = 0;
-                        break;                          
-                case 24:
-                        nom = 4;
-                        den = 1;
-                        v.red.offset = 16;
-                        v.green.offset = 8;
-                        v.blue.offset = 0;
-                        v.red.length = v.blue.length = v.green.length = 8;
-                        v.transp.offset = v.transp.length = 0;
-                        break;
-                case 32:
-                        nom = 4;
-                        den = 1;
-                        v.red.offset = 16;
-                        v.green.offset = 8;
-                        v.blue.offset = 0;
-                        v.red.length = v.blue.length = v.green.length = 8;
-                        v.transp.offset = 24;
-                        v.transp.length = 8;
-                        break;
-                default:
-                        printk ("radeonfb: mode %dx%dx%d rejected, color depth invalid\n",
-                                var->xres, var->yres, var->bits_per_pixel);
-                        return -EINVAL;
-        }
+		case 0:
+		case 8:
+			v.red.offset = 16;
+			v.green.offset = 8;
+			v.transp.offset = 24;
+			v.blue.length = v.red.length = 8;
+			v.transp.length = 8;
+			rinfo->format = PIX_WIDTH_A8R8G8B8;
+			break;
+		default:
+			goto err;
+		}
+		break;
+	default:
+err:
+		printk ("radeonfb: mode %dx%dx%d rejected, color depth invalid\n",
+			var->xres, var->yres, var->bits_per_pixel);
+		return -EINVAL;
+	}
 
 	if (v.yres_virtual < v.yres)
 		v.yres_virtual = v.yres;
 	if (v.xres_virtual < v.xres)
 		v.xres_virtual = v.xres;
-                
 
 	/* XXX I'm adjusting xres_virtual to the pitch, that may help XFree
 	 * with some panels, though I don't quite like this solution
 	 */
-  	if (rinfo->info->flags & FBINFO_HWACCEL_DISABLED) {
+	if (rinfo->info->flags & FBINFO_HWACCEL_DISABLED) {
 		v.xres_virtual = v.xres_virtual & ~7ul;
 	} else {
-		pitch = ((v.xres_virtual * ((v.bits_per_pixel + 1) / 8) + 0x3f)
- 				& ~(0x3f)) >> 6;
-		v.xres_virtual = (pitch << 6) / ((v.bits_per_pixel + 1) / 8);
+		if (v.bits_per_pixel < 8) {
+			pitch = ((v.xres_virtual * (v.bits_per_pixel / 2) + 0x3f) & ~(0x3f)) >> 6;
+			v.xres_virtual = (pitch << 6) * 2;
+		} else {
+			pitch = ((v.xres_virtual * ((v.bits_per_pixel + 1) / 8) + 0x3f)
+				& ~(0x3f)) >> 6;
+			v.xres_virtual = (pitch << 6) / ((v.bits_per_pixel + 1) / 8);
+		}
 	}
 
 	if (((v.xres_virtual * v.yres_virtual * nom) / den) > rinfo->mapped_vram)
@@ -824,21 +849,20 @@ static int radeonfb_check_var (struct fb
 		v.xres = v.xres_virtual;
 
 	if (v.xoffset < 0)
-                v.xoffset = 0;
-        if (v.yoffset < 0)
-                v.yoffset = 0;
-         
-        if (v.xoffset > v.xres_virtual - v.xres)
-                v.xoffset = v.xres_virtual - v.xres - 1;
-                        
-        if (v.yoffset > v.yres_virtual - v.yres)
-                v.yoffset = v.yres_virtual - v.yres - 1;
-         
-        v.red.msb_right = v.green.msb_right = v.blue.msb_right =
-                          v.transp.offset = v.transp.length =
-                          v.transp.msb_right = 0;
-	
-        memcpy(var, &v, sizeof(v));
+		v.xoffset = 0;
+	if (v.yoffset < 0)
+		v.yoffset = 0;
+
+	if (v.xoffset > v.xres_virtual - v.xres)
+		v.xoffset = v.xres_virtual - v.xres - 1;
+
+	if (v.yoffset > v.yres_virtual - v.yres)
+		v.yoffset = v.yres_virtual - v.yres - 1;
+
+	v.red.msb_right = v.green.msb_right = v.blue.msb_right =
+			  v.transp.msb_right = 0;
+
+	memcpy(var, &v, sizeof(v));
 
         return 0;
 }
@@ -1554,7 +1578,7 @@ static int radeonfb_set_par(struct fb_in
 	int nopllcalc = 0;
 	int hsync_start, hsync_fudge, bytpp, hsync_wid, vsync_wid;
 	int primary_mon = PRIMARY_MONITOR(rinfo);
-	int depth = var_to_depth(mode);
+	int depth = mode->bits_per_pixel;
 	int use_rmx = 0;
 
 	newmode = kmalloc(sizeof(struct radeon_regs), GFP_KERNEL);
@@ -1630,7 +1654,7 @@ static int radeonfb_set_par(struct fb_in
 
 	cSync = mode->sync & FB_SYNC_COMP_HIGH_ACT ? (1 << 4) : 0;
 
-	format = radeon_get_dstbpp(depth);
+	format = rinfo->format;
 	bytpp = mode->bits_per_pixel >> 3;
 
 	if ((primary_mon == MT_DFP) || (primary_mon == MT_LCD))
@@ -1676,11 +1700,19 @@ static int radeonfb_set_par(struct fb_in
 
 	if (!(info->flags & FBINFO_HWACCEL_DISABLED)) {
 		/* We first calculate the engine pitch */
-		rinfo->pitch = ((mode->xres_virtual * ((mode->bits_per_pixel + 1) / 8) + 0x3f)
+		if (mode->bits_per_pixel < 8) {
+			rinfo->pitch = ((mode->xres_virtual / 2 + 0x3f)
  				& ~(0x3f)) >> 6;
 
-		/* Then, re-multiply it to get the CRTC pitch */
-		newmode->crtc_pitch = (rinfo->pitch << 3) / ((mode->bits_per_pixel + 1) / 8);
+			/* Then, re-multiply it to get the CRTC pitch */
+			newmode->crtc_pitch = (rinfo->pitch << 3) * 2;
+		} else {
+			rinfo->pitch = ((mode->xres_virtual * ((mode->bits_per_pixel + 1) / 8) + 0x3f)
+ 				& ~(0x3f)) >> 6;
+
+			/* Then, re-multiply it to get the CRTC pitch */
+			newmode->crtc_pitch = (rinfo->pitch << 3) / ((mode->bits_per_pixel + 1) / 8);
+		}
 	} else
 		newmode->crtc_pitch = (mode->xres_virtual >> 3);
 
@@ -1859,6 +1891,10 @@ static int radeonfb_set_par(struct fb_in
 	return 0;
 }
 
+char *radeonfb_getconfigs(struct fb_info *info)
+{
+	return "I4\nI8\nA1R5G5B5\nR5G6B5\nR8G8B8\nA8R8G8B8\nA4R4G4B4\nA8I8\nA2R10G10B10\n";
+}
 
 static struct fb_ops radeonfb_ops = {
 	.owner			= THIS_MODULE,
@@ -1873,6 +1909,7 @@ static struct fb_ops radeonfb_ops = {
 	.fb_fillrect		= radeonfb_fillrect,
 	.fb_copyarea		= radeonfb_copyarea,
 	.fb_imageblit		= radeonfb_imageblit,
+	.fb_get_configs		= radeonfb_getconfigs,
 };
 
 
diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
--- a/drivers/video/aty/radeonfb.h
+++ b/drivers/video/aty/radeonfb.h
@@ -328,6 +328,7 @@ struct radeonfb_info {
 	u32			dp_gui_master_cntl;
 
 	struct pll_info		pll;
+	unsigned int		format; /* format of the scanout buffer */
 
 	int			mtrr_hdl;
 
@@ -511,29 +512,6 @@ static inline int round_div(int num, int
         return (num + (den / 2)) / den;
 }
 
-static inline int var_to_depth(const struct fb_var_screeninfo *var)
-{
-	if (var->bits_per_pixel != 16)
-		return var->bits_per_pixel;
-	return (var->green.length == 5) ? 15 : 16;
-}
-
-static inline u32 radeon_get_dstbpp(u16 depth)
-{
-	switch (depth) {
-       	case 8:
-       		return DST_8BPP;
-       	case 15:
-       		return DST_15BPP;
-       	case 16:
-       		return DST_16BPP;
-       	case 32:
-       		return DST_32BPP;
-       	default:
-       		return 0;
-	}
-}
-
 /*
  * 2D Engine helper routines
  */
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -15,6 +15,7 @@
  * are converted to use it a sysfsification will open OOPSable races.
  */
 
+#include <linux/ctype.h>
 #include <linux/kernel.h>
 #include <linux/fb.h>
 #include <linux/console.h>
@@ -190,6 +191,127 @@ static ssize_t show_modes(struct class_d
 	return i;
 }
 
+static ssize_t store_config(struct class_device *class_device, const char * buf,
+			  size_t count)
+{
+	struct fb_info *fb_info =
+		(struct fb_info *)class_get_devdata(class_device);
+	int err;
+	char c, *y;
+	const char *x = buf;
+	unsigned int field = 0, bpp = 0;
+	struct fb_var_screeninfo var;
+
+	var = fb_info->var;
+	while (x < buf + count) {
+		x++;
+		field = simple_strtoul(x, &y, 10);
+		x = y;
+		bpp += field;
+	}
+	if (!bpp)
+		return -EINVAL;
+	var.bits_per_pixel = bpp;
+
+	x = buf;
+	while (x < buf + count) {
+		c = *x++;
+		field = simple_strtoul(x, &y, 10);
+		x = y;
+		bpp -= field;
+		switch (toupper(c)) {
+		case 'A':
+			var.transp.length = field;
+			var.transp.offset = bpp;
+			break;
+		case 'M':
+			var.grayscale = 1;
+			/* fall through */
+		case 'I':
+			var.red.length = var.green.length = var.blue.length = field;
+			var.red.offset = var.green.offset = var.blue.offset = 0;
+			break;
+		case 'R':
+			var.red.length = field;
+			var.red.offset = bpp;
+			break;
+		case 'G':
+			var.green.length = field;
+			var.green.offset = bpp;
+			break;
+		case 'B':
+			var.blue.length = field;
+			var.blue.offset = bpp;
+			break;
+		}
+	}
+	if ((err = activate(fb_info, &var)))
+		return err;
+
+	return count;
+}
+
+static ssize_t show_config(struct class_device *class_device, char *buf)
+{
+	struct fb_info *fb_info =
+		(struct fb_info *)class_get_devdata(class_device);
+	int i, off, count;
+	char field[4][10];
+
+	count = off = 0;
+	buf[0] = '\n';
+
+	for (i = 0; i < 4; i++) {
+		field[i][0] = '\0';
+		if ((off == 0) && ((fb_info->var.red.offset == 0) &&
+				(fb_info->var.blue.offset == 0) && (fb_info->var.green.offset == 0))) {
+			snprintf(&field[i][0], sizeof(field[0]), "I%d", fb_info->var.red.length);
+			off += fb_info->var.red.length;
+			continue;
+		}
+		if ((fb_info->var.red.offset == off) && (fb_info->var.red.length != 0)) {
+			snprintf(&field[i][0], sizeof(field[0]), "R%d", fb_info->var.red.length);
+			off += fb_info->var.red.length;
+			continue;
+		}
+		if ((fb_info->var.green.offset == off) && (fb_info->var.green.length != 0)) {
+			snprintf(&field[i][0], sizeof(field[0]), "G%d", fb_info->var.green.length);
+			off += fb_info->var.green.length;
+			continue;
+		}
+		if ((fb_info->var.blue.offset == off) && (fb_info->var.blue.length != 0)) {
+			snprintf(&field[i][0], sizeof(field[0]), "B%d", fb_info->var.blue.length);
+			off += fb_info->var.blue.length;
+			continue;
+		}
+		if ((fb_info->var.transp.offset == off) && (fb_info->var.transp.length != 0)) {
+			snprintf(&field[i][0], sizeof(field[0]), "A%d", fb_info->var.transp.length);
+			off += fb_info->var.transp.length;
+			continue;
+		}
+	}
+	for (i = 3; i >= 0; i--)
+		if (field[i][0] != '\0')
+			count += snprintf(&buf[count], PAGE_SIZE - count, "%s", &field[i][0]);
+			
+	if (count)
+		count += snprintf(&buf[count], PAGE_SIZE - count, "\n");
+	return count;
+}
+
+static ssize_t show_configs(struct class_device *class_device, char *buf)
+{
+	struct fb_info *fb_info =
+		(struct fb_info *)class_get_devdata(class_device);
+	int count = 0;
+
+	if (fb_info->fbops->fb_get_configs) {
+		strncpy(buf, fb_info->fbops->fb_get_configs(fb_info), PAGE_SIZE);
+		count = strlen(buf);
+	}
+	return count;
+}
+
 static ssize_t store_bpp(struct class_device *class_device, const char * buf,
 			 size_t count)
 {
@@ -355,32 +477,6 @@ static ssize_t show_blank(struct class_d
 	return 0;
 }
 
-static ssize_t store_console(struct class_device *class_device,
-			     const char * buf, size_t count)
-{
-//	struct fb_info *fb_info = (struct fb_info *)class_get_devdata(class_device);
-	return 0;
-}
-
-static ssize_t show_console(struct class_device *class_device, char *buf)
-{
-//	struct fb_info *fb_info = (struct fb_info *)class_get_devdata(class_device);
-	return 0;
-}
-
-static ssize_t store_cursor(struct class_device *class_device,
-			    const char * buf, size_t count)
-{
-//	struct fb_info *fb_info = (struct fb_info *)class_get_devdata(class_device);
-	return 0;
-}
-
-static ssize_t show_cursor(struct class_device *class_device, char *buf)
-{
-//	struct fb_info *fb_info = (struct fb_info *)class_get_devdata(class_device);
-	return 0;
-}
-
 static ssize_t store_pan(struct class_device *class_device, const char * buf,
 			 size_t count)
 {
@@ -425,10 +521,10 @@ static struct class_device_attribute cla
 	__ATTR(bits_per_pixel, S_IRUGO|S_IWUSR, show_bpp, store_bpp),
 	__ATTR(blank, S_IRUGO|S_IWUSR, show_blank, store_blank),
 	__ATTR(color_map, S_IRUGO|S_IWUSR, show_cmap, store_cmap),
-	__ATTR(console, S_IRUGO|S_IWUSR, show_console, store_console),
-	__ATTR(cursor, S_IRUGO|S_IWUSR, show_cursor, store_cursor),
 	__ATTR(mode, S_IRUGO|S_IWUSR, show_mode, store_mode),
 	__ATTR(modes, S_IRUGO|S_IWUSR, show_modes, store_modes),
+	__ATTR(config, S_IRUGO|S_IWUSR, show_config, store_config),
+	__ATTR(configs, S_IRUGO|S_IWUSR, show_configs, NULL),
 	__ATTR(pan, S_IRUGO|S_IWUSR, show_pan, store_pan),
 	__ATTR(virtual_size, S_IRUGO|S_IWUSR, show_virtual, store_virtual),
 	__ATTR(name, S_IRUGO, show_name, NULL),
diff --git a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -598,6 +598,10 @@ struct fb_ops {
 
 	/* perform fb specific mmap */
 	int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
+
+	/* Get allowable configs */
+	char * (*fb_get_configs) (struct fb_info *info);
+
 };
 
 #ifdef CONFIG_FB_TILEBLITTING
diff --git a/include/video/radeon.h b/include/video/radeon.h
--- a/include/video/radeon.h
+++ b/include/video/radeon.h
@@ -800,6 +800,18 @@
 #define DST_X_LEFT_TO_RIGHT_S                      0x80000000
 
 
+/* CRTC_PIC_WIDTH constants */
+#define PIX_WIDTH_I4                               0x00000001
+#define PIX_WIDTH_I8                               0x00000002
+#define PIX_WIDTH_A1R5G5B5                         0x00000003
+#define PIX_WIDTH_R5G6B5                           0x00000004
+#define PIX_WIDTH_R8B8G8                           0x00000005
+#define PIX_WIDTH_A8R8G8B8                         0x00000006
+#define PIX_WIDTH_A4R4B4G4                         0x00000007
+#define PIX_WIDTH_A8I8                             0x00000008
+#define PIX_WIDTH_A2R10G10B10                      0x00000009
+
+
 /* DP_DATATYPE bit constants */
 #define DST_8BPP                                   0x00000002
 #define DST_15BPP                                  0x00000003

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Fri, 12 Aug 2005, Antonino A. Daplas wrote:
> Geert Uytterhoeven wrote:
> > On Thu, 11 Aug 2005, Antonino Daplas wrote:
> > > (Depending on how correct I am with the interpretation, there might be
> > > some bugs in fbdev on how it determines the color depth. No one is
> > > complaining yet though, so greater than 1-bit monochrome is probably
> > > rare if not nonexistent.)
> > 
> > There definitely are bugs w.r.t. this, especially in the 2.4 logo code ;-)
> > 
> 
> Yes, I would agree.  Do you know of any outstanding bugs on color handling
> in 2.6 code, especially for hardware with bitdepths < 8? I would like to
> fix them.

Unfortunately not. Due to personel reasons, I temporarily don't have much
time left to do real coding.

You can always try vgafb's 16 color mode and check for yourself.

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Antonino A. Daplas]

Geert Uytterhoeven wrote:
> On Fri, 12 Aug 2005, Antonino A. Daplas wrote:
>> Geert Uytterhoeven wrote:
>>> On Thu, 11 Aug 2005, Antonino Daplas wrote:
>>>> (Depending on how correct I am with the interpretation, there might be
>>>> some bugs in fbdev on how it determines the color depth. No one is
>>>> complaining yet though, so greater than 1-bit monochrome is probably
>>>> rare if not nonexistent.)
>>> There definitely are bugs w.r.t. this, especially in the 2.4 logo code ;-)
>>>
>> Yes, I would agree.  Do you know of any outstanding bugs on color handling
>> in 2.6 code, especially for hardware with bitdepths < 8? I would like to
>> fix them.
> 
> Unfortunately not. Due to personel reasons, I temporarily don't have much
> time left to do real coding.
> 
> You can always try vgafb's 16 color mode and check for yourself.

That's okay. I'm actually emulating these low bit depths using pseudocolor whenever
I look for bugs for depths < 4 (ie monochrome text attributes). I haven't found
any yet except for the greater than 1-bit monochrome color handling which I've
already fixed in my tree.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Jon Smirl]

Could everyone give this a try and give me some feedback?

On 8/11/05, Jon Smirl <jonsmirl@gmail.com> wrote:
> Here's a new version that actually lets me set all possible scanout
> configs on radeonfb. I can even set I4 but I don't think the code is
> correct for it yet everywhere in radeonfb. The core code in the patch
> should be ok. My further changes should be restricted to the radeonfb
> code. For example, I haven't added the logic to radeonfb to "round up"
> to the next config.
> 
> You get two new sysfs attributes:
> configs - optional, but really nice to have, list of all configs
> supported by the driver
> config - current config the hardware is set to.
> 
> example syntax...
> [root@jonsmirl fb0]# cat configs
> I4
> I8
> A1R5G5B5
> R5G6B5
> R8G8B8
> A8R8G8B8
> A4R4G4B4
> A8I8
> A2R10G10B10
> 
> Offsets are computed from the field widths. So if a card sets BGR vs
> RGB and you cat its config you will see RGB or BGR in the config
> string. M is used for a grayscale field.
> 
> So give the patch a try and start expanding it to handle other cards.
> 
> --
> Jon Smirl
> jonsmirl@gmail.com
> 
> 
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Antonino A. Daplas]

Jon Smirl wrote:
> Could everyone give this a try and give me some feedback?
> 

Just merging your patch in my tree.  Will give you feedback in a
day or so.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Jon Smirl]

The patch is just for testing, don't send it on. The radeonfb portion
is definitely not finished.

This adds an optional function to each driver that advertises what
configs it offers.

+char *radeonfb_getconfigs(struct fb_info *info)
+{
+	return "I4\nI8\nA1R5G5B5\nR5G6B5\nR8G8B8\nA8R8G8B8\nA4R4G4B4\nA8I8\nA2R10G10B10\n";
+}
 
  static struct fb_ops radeonfb_ops = {
 	.owner			= THIS_MODULE,
@@ -1873,6 +1909,7 @@ static struct fb_ops radeonfb_ops = {
 	.fb_fillrect		= radeonfb_fillrect,
 	.fb_copyarea		= radeonfb_copyarea,
 	.fb_imageblit		= radeonfb_imageblit,
+	.fb_get_configs		= radeonfb_getconfigs,
 };

If you know what configs the driver support try setting them via the
sysfs attribute. You can also check out your config match code by
putting in non-supported configs and setting what gets returned in the
attribute.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Fri, 19 Aug 2005, Jon Smirl wrote:
> The patch is just for testing, don't send it on. The radeonfb portion
> is definitely not finished.
> 
> This adds an optional function to each driver that advertises what
> configs it offers.
> 
> +char *radeonfb_getconfigs(struct fb_info *info)
> +{
> +	return "I4\nI8\nA1R5G5B5\nR5G6B5\nR8G8B8\nA8R8G8B8\nA4R4G4B4\nA8I8\nA2R10G10B10\n";
> +}
>  
>   static struct fb_ops radeonfb_ops = {
>  	.owner			= THIS_MODULE,
> @@ -1873,6 +1909,7 @@ static struct fb_ops radeonfb_ops = {
>  	.fb_fillrect		= radeonfb_fillrect,
>  	.fb_copyarea		= radeonfb_copyarea,
>  	.fb_imageblit		= radeonfb_imageblit,
> +	.fb_get_configs		= radeonfb_getconfigs,
>  };

Do we really need this?

You can easily write a `probe loop' to find out about all supported configs for
a driver like this:

    for_all_possible_configs(config) {
	struct fb_var_screeninfo var;
	set_up_var(var, config);
	var.activate |= FB_ACTIVATE_TEST;
	if (ioctl(FBIOPUT_VSCREENINFO)) {
	    /* config not supported */
	} else if (config_has_changed(var, config) {
	    /* config not supported */
	} else {
	    /* config is supported */
	}
    }

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Richard Smith]

> > This adds an optional function to each driver that advertises what
> > configs it offers.
> >
> 
> Do we really need this?
> 
> You can easily write a `probe loop' to find out about all supported configs for
> a driver like this:
> 
>     for_all_possible_configs(config) {
>         struct fb_var_screeninfo var;

This will actually try to set the mode right?

SDL does it this way and its caused me some pain dealing with
framebuffers on hardware that has issues with certain modes.  Its also
a good bit slower for the app to startup while the code crunches out
the pll settings.

From a users perspective I think advertising valid modes is a good thing.

-- 
Richard A. Smith


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Mon, 22 Aug 2005, Richard Smith wrote:
> > > This adds an optional function to each driver that advertises what
> > > configs it offers.
> > 
> > Do we really need this?
> > 
> > You can easily write a `probe loop' to find out about all supported configs for
> > a driver like this:
> > 
> >     for_all_possible_configs(config) {
> >         struct fb_var_screeninfo var;
> 
> This will actually try to set the mode right?

No, you cut the following line:

| var.activate |= FB_ACTIVATE_TEST;

which will cause the driver to check whether the mode is valid (or can be made
valid by rounding up).

> SDL does it this way and its caused me some pain dealing with
> framebuffers on hardware that has issues with certain modes.  Its also
> a good bit slower for the app to startup while the code crunches out
> the pll settings.
> 
> >From a users perspective I think advertising valid modes is a good thing.

Except that on most hardware the list of valid modes is _very_ large...
How many combinations of resolution, color depth, and timings do you think you
can have? I guess the complete list can easily fill up all your RAM...

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Richard Smith]

> 
> No, you cut the following line:
> 
> | var.activate |= FB_ACTIVATE_TEST;
> 

Sorry. I was shorting and I went too far.

> which will cause the driver to check whether the mode is valid (or can be made
> valid by rounding up).

Ah well that sounds more like was thinking of.  Is FB_ACTIVATE_TEST
new from 2.4 -> 2.6?
Be nice if SDL (and other apps) did it that way rather than actually
makeing the driver try to switch to the mode.
  
-- 
Richard A. Smith


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Antonino A. Daplas]

Richard Smith wrote:
> 
> Ah well that sounds more like was thinking of.  Is FB_ACTIVATE_TEST
> new from 2.4 -> 2.6?
> Be nice if SDL (and other apps) did it that way rather than actually
> makeing the driver try to switch to the mode.
>   

2.4 has this also.

I agree with Geert though. Just too many combinations, and this is just
for RGB.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Jon Smirl]

On 8/22/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, 19 Aug 2005, Jon Smirl wrote:
> > The patch is just for testing, don't send it on. The radeonfb portion
> > is definitely not finished.
> >
> > This adds an optional function to each driver that advertises what
> > configs it offers.
> >
> > +char *radeonfb_getconfigs(struct fb_info *info)
> > +{
> > +     return "I4\nI8\nA1R5G5B5\nR5G6B5\nR8G8B8\nA8R8G8B8\nA4R4G4B4\nA8I8\nA2R10G10B10\n";
> > +}
> >
> >   static struct fb_ops radeonfb_ops = {
> >       .owner                  = THIS_MODULE,
> > @@ -1873,6 +1909,7 @@ static struct fb_ops radeonfb_ops = {
> >       .fb_fillrect            = radeonfb_fillrect,
> >       .fb_copyarea            = radeonfb_copyarea,
> >       .fb_imageblit           = radeonfb_imageblit,
> > +     .fb_get_configs         = radeonfb_getconfigs,
> >  };
> 
> Do we really need this?

It is optional. It's used in sysfs, where you cat the config variable
to get a list of valid configs. Once in sysfs a program could then use
it to generate a list to pick from, etc...

It seems hard to use the search method if you are looking for a config
that is in the middle of the list.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Geert Uytterhoeven]

On Mon, 22 Aug 2005, Richard Smith wrote:
> > No, you cut the following line:
> > 
> > | var.activate |= FB_ACTIVATE_TEST;
> 
> Sorry. I was shorting and I went too far.
> 
> > which will cause the driver to check whether the mode is valid (or can be made
> > valid by rounding up).
> 
> Ah well that sounds more like was thinking of.  Is FB_ACTIVATE_TEST
> new from 2.4 -> 2.6?

It's been there from the beginning (i.e. from 1994). In fact very little was
changed in the public (userspace) fbdev interface since then :-)

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Richard Smith]

> > Ah well that sounds more like was thinking of.  Is FB_ACTIVATE_TEST
> > new from 2.4 -> 2.6?
> 
> It's been there from the beginning (i.e. from 1994). In fact very little was
> changed in the public (userspace) fbdev interface since then :-)
> 

Hmmm.. I just went and looked at the SDL code and indeed thats what
its doing so I was mistaken.  Untill now I was just assuming that SDL
was doing that.

The stpcfb (from ST) code must be totally messing that IOCTL up then. 
I guess thats not so suprising since the stpcfb was broken in a couple
of other ways.  That device has been responsible for the bulk of my
pain.

I'll go compare it to a few of the other drivers and see what its
doing wrong now that I know its a bug and not a feature.

Thanks.  

-- 
Richard A. Smith


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: mono, gray and index configs

[Richard Smith]

> Hmmm.. I just went and looked at the SDL code and indeed thats what
> its doing so I was mistaken.  Untill now I was just assuming that SDL
> was doing that.

I think what led me to believe this is that SDL has a setting for
broken modes.  If you set this then it dosen't do a mode scan and only
tries to set what you request.  Normall it tries to match the nearest
mode if it can't find what you request.

So I glarked out that the ioctl must be trying to apply the settings
but I bet its for the other graphics backends that SDL supports.

-- 
Richard A. Smith


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf