>Date: Mon, 14 Nov 2005 22:32:26 +0100
>From: Peter Teichmann 
>To: Stuart Winter 
>Subject: Re: X-Patch for ARM, Kernel-Patch for IYONIX
>Parts/Attachments:

Hello Stuart,

Attached you find a patch to enable 24bpp for the RiscPC. It is quite simple,
but before applying please check that the other things it fixes are not
already included, because it is for kernel 2.6.11.

> Thanks -- that works.  Now I remember why I used to run the RiscPC in
> a low colour, 1024x768 screen res; I definitley won't be recommending
> anybody runs KDE on a RiscPC! ;-)

I believe xfce or fvwm were reasonably fast. Windowmaker is probably also ok,
but that is a bit a matter of taste.

Here I list again the 3 maximum video modes for 24/16/8 bpp. It is probably
the best to indclude them by default in the xorg.conf for the RiscPC. Even
for 8bpp it gives an improvement, otherwise you just get a 60 Hz refresh
rate. Fersonally I found 1280x1024-75 at 8bpp quite ok.

# 800x600 @ 56Hz (VESA) hsync: 35.2kHz
ModeLine "800x600"    36.0  800  824  896 1024    600  601  603  625 +hsync +vsync
# 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
ModeLine "1024x768"   75.0 1024 1048 1184 1328    768  771  777  806 -hsync -vsync
# 1280x1024 @ 75Hz (VESA) hsync: 80.0kHz
ModeLine "1280x1024" 135.0 1280 1296 1440 1688   1024 1025 1028 1066 +hsync +vsync

But I am still planning to fix the mode enumeration bug. Xorg knows these
modes also by itself, it just does not find them...

> With regard to patches: do you happen to know Debian's policy on pushing
> them upstream? There seem to be an abundance of patches Debian never push
> upstream.  For example: look in Debian's diff for xfree86/xorg -- some
> (none?) of those ARM patches have been pushed up stream (or maybe were
> refused by Xfree86 who were renouned for never accepting patches);
> some of them (the RiscPC stuff in particular) say that they have never
> been pushed.
>
No, I don't know that. But I guess they are just a bit overloaded by work. I
submitted my 2 patches to the Debian bug reporting system. Soon I was
contacted by Michel Dänzer with some questions, but also the suggestion to
better push them upstream by myself. See Bug#338245/Bug#338241.

> It'd be nice to get the patches upstream if appropriate/isn't more effort
> than it's worth.

I will do that once I had time to check a minor change he suggested.

Peter

--- linux-2.6.11/drivers/video/acornfb.c	2005-11-14 20:57:28.000000000 +0100
+++ linux-2.6.11.build/drivers/video/acornfb.c	2005-11-14 22:14:55.000000000 +0100
@@ -754,6 +754,8 @@
 		var->transp.length = 1;
 		break;
 
+	case 24:
+		var->bits_per_pixel = 32;
 	case 32:
 		var->red.offset    = 0;
 		var->red.length    = 8;
@@ -774,6 +776,18 @@
 	 */
 	if (!acornfb_valid_pixrate(var))
 		return -EINVAL;
+		
+ 	/*
+	 * Neither interlace nor doublescan do work properly.
+	 * Interlace would require software to store odd and even field
+	 * separately and the kernel to switch between odd and even field
+	 * at VSYNC. Doublescan is only possible if handled totally in
+	 * software. -> Disabled as it does not cause the expected result.
+	 */
+
+	 if (((var->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED) ||
+	     ((var->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE))
+	 	return -EINVAL;
 
 	/*
 	 * Validate and adjust the resolution to
@@ -1236,12 +1250,12 @@
 
 /*
  * Detect type of monitor connected
- *  For now, we just assume SVGA
+ * For now, we just assume Multi Freq
  */
 static int __init
 acornfb_detect_monitortype(void)
 {
-	return 4;
+	return 1;
 }
 
 /*