Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

[Petr Vandrovec]

On  3 Jan 01 at 10:54, Tom Rini wrote:
> I agree this sounds good.  I just think it's too late to do it now. :)
> 
> The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> now to remove it) but documented as obsolete, and removed in 2.5.

I personally prefer 'video=matrox:vesa:0x105' over 
'video=matrox:1024x768-8', as with matroxfb you can modify this mode with
'left', 'right', 'fv', 'fh'... options, and without these parameters it is 
unusable on fixed sync monitors (f.e. 'sync' is vital to specify 
sync-on-green feature).

If someone will create modedb, which will allow specifying all parameters
of fb_var_screeninfo, I'll remove this parsing code from matroxfb. But 
without it I think that 'vesa' will survive forever... And as I can test
only vga16fb and matroxfb, I'm not probably right one to do this.
                                            Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

[Geert Uytterhoeven]

On Wed, 3 Jan 2001, Petr Vandrovec wrote:
> On  3 Jan 01 at 10:54, Tom Rini wrote:
> > I agree this sounds good.  I just think it's too late to do it now. :)
> > 
> > The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> > now to remove it) but documented as obsolete, and removed in 2.5.
> 
> I personally prefer 'video=matrox:vesa:0x105' over 
> 'video=matrox:1024x768-8', as with matroxfb you can modify this mode with
> 'left', 'right', 'fv', 'fh'... options, and without these parameters it is 
> unusable on fixed sync monitors (f.e. 'sync' is vital to specify 
> sync-on-green feature).
> 
> If someone will create modedb, which will allow specifying all parameters
> of fb_var_screeninfo, I'll remove this parsing code from matroxfb. But 
> without it I think that 'vesa' will survive forever... And as I can test
> only vga16fb and matroxfb, I'm not probably right one to do this.

Just add these options to the fb_find_mode() parser in modedb.c, and they'll
work on all fbdev drivers that use modedb. There's no reason to duplicate that
code in each fbdev.

Since matroxfb has the richest set of features (even more than atyfb ;-),
you're actually in the right position to do this :-)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] matroxfb as a module (PPC)

[Tom Rini]

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

Hello all.  I've recently been playing with modules on my PPC system, and
noticed that matroxfb doesn't work as a module, because of mac_vmode_to_par.
But, after looking at other drivers which did work (aty and aty128) I noticed
matroxfb was doing something it didn't need to be doing.
First, the code should never get compiled, if this is a module, and even then
the code only needs to be compiled on ALL_PPC (which is Pmac/PReP/CHRP).
Second, it's only valid to call the default_{vmode,cmode} code on a PMAC 
(tested on a pmac, and ran it by one of the IBM guys who agrees it shouldn't
break anything, but he's still working on making the machine boot to start
with. :))
Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
Finally, the VMODE_CHOOSE stuff is 0'ed out in atyfb with a comment about this
not actually working, so I removed it.

Comments?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

[-- Attachment #2: matroxfb_base.patch --]
[-- Type: text/plain, Size: 1706 bytes --]

===== drivers/video/matrox/matroxfb_base.c 1.13 vs edited =====
--- 1.13/drivers/video/matrox/matroxfb_base.c	Fri Dec 15 14:12:43 2000
+++ edited/drivers/video/matrox/matroxfb_base.c	Sun Dec 31 10:39:11 2000
@@ -1842,33 +1842,33 @@
 	}
 
 	/* FIXME: Where to move this?! */
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_ALL_PPC)
 #if defined(CONFIG_FB_COMPAT_XPMAC)
 	strcpy(ACCESS_FBINFO(matrox_name), "MTRX,");	/* OpenFirmware naming convension */
 	strncat(ACCESS_FBINFO(matrox_name), b->name, 26);
 	if (!console_fb_info)
 		console_fb_info = &ACCESS_FBINFO(fbcon);
 #endif
-	if ((xres <= 640) && (yres <= 480)) {
+#ifndef MODULE
+	if (_machine == _MACH_Pmac) {
 		struct fb_var_screeninfo var;
-		if (default_vmode == VMODE_NVRAM) {
-			default_vmode = nvram_read_byte(NV_VMODE);
-			if (default_vmode <= 0 || default_vmode > VMODE_MAX)
-				default_vmode = VMODE_CHOOSE;
-		}
 		if (default_vmode <= 0 || default_vmode > VMODE_MAX)
 			default_vmode = VMODE_640_480_60;
+#ifdef CONFIG_NVRAM
 		if (default_cmode == CMODE_NVRAM)
 			default_cmode = nvram_read_byte(NV_CMODE);
+#endif
 		if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
 			default_cmode = CMODE_8;
 		if (!mac_vmode_to_var(default_vmode, default_cmode, &var)) {
 			var.accel_flags = vesafb_defined.accel_flags;
 			var.xoffset = var.yoffset = 0;
-			vesafb_defined = var; /* Note: mac_vmode_to_var() doesnot set all parameters */
+			/* Note: mac_vmode_to_var() does not set all parameters */
+			vesafb_defined = var;
 		}
 	}
-#endif /* CONFIG_PPC */
+#endif /* !MODULE */
+#endif /* CONFIG_ALL_PPC */
 	vesafb_defined.xres_virtual = vesafb_defined.xres;
 	if (nopan) {
 		vesafb_defined.yres_virtual = vesafb_defined.yres;

Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

[Geert Uytterhoeven]

On Wed, 3 Jan 2001, Tom Rini wrote:
> Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.

I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
it will work automagically for all drivers on PowerMac.

I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
the archictecture-neutral `<xres>x<yres>[-<bpp>][@<refresh>]' and
`<name>[-<bpp>][@<refresh>]' arguments (which already work on mac, BTW).
You can already use `mac<vmode>' instead of `vmode:<vmode>'.

IMHO, the less PowerMac-specific code in _each_ driver, the better.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

[Tom Rini]

On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote:
> On Wed, 3 Jan 2001, Tom Rini wrote:
> > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
> 
> I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
> it will work automagically for all drivers on PowerMac.
> 
> I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
> the archictecture-neutral `<xres>x<yres>[-<bpp>][@<refresh>]' and
> `<name>[-<bpp>][@<refresh>]' arguments (which already work on mac, BTW).

Quite wonderfully, almost.  My monitor (ViewSonic G810) claims it can do
1280x1024@90, but when i boot with that on my x86 box, it comes up at 87.5
or so (and shifted to the left ~1 penguin).  But anyways..

> You can already use `mac<vmode>' instead of `vmode:<vmode>'.

Ah, is this documented anywhere?  I'm sure it'd make some peoples life
easier.

> IMHO, the less PowerMac-specific code in _each_ driver, the better.

I agree this sounds good.  I just think it's too late to do it now. :)

The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
now to remove it) but documented as obsolete, and removed in 2.5.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

[Geert Uytterhoeven]

On Wed, 3 Jan 2001, Tom Rini wrote:
> On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 3 Jan 2001, Tom Rini wrote:
> > > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
> > 
> > I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
> > it will work automagically for all drivers on PowerMac.
> > 
> > I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
> > the archictecture-neutral `<xres>x<yres>[-<bpp>][@<refresh>]' and
> > `<name>[-<bpp>][@<refresh>]' arguments (which already work on mac, BTW).
> 
> Quite wonderfully, almost.  My monitor (ViewSonic G810) claims it can do
> 1280x1024@90, but when i boot with that on my x86 box, it comes up at 87.5
> or so (and shifted to the left ~1 penguin).  But anyways..
> 
> > You can already use `mac<vmode>' instead of `vmode:<vmode>'.
> 
> Ah, is this documented anywhere?  I'm sure it'd make some peoples life
> easier.

It's not documented, but read macmodes.c and modedb.c. The Mac modes have names
`mac1' to `mac20', so they can be specified using the `<name>[-<bpp>]' syntax.

> > IMHO, the less PowerMac-specific code in _each_ driver, the better.
> 
> I agree this sounds good.  I just think it's too late to do it now. :)
> 
> The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> now to remove it) but documented as obsolete, and removed in 2.5.

Yep, too late for 2.4.0.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/