Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 `x[-][@]' and
> > `[-][@]' 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' instead of `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 `[-]' 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 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 `x[-][@]' and > `[-][@]' 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' instead of `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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 `x[-][@]' and
`[-][@]' arguments (which already work on mac, BTW).
You can already use `mac' instead of `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 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 `xresxyres[-bpp][@refresh]' and
`name[-bpp][@refresh]' arguments (which already work on mac, BTW).
You can already use `macvmode' 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 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 `xresxyres[-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 `macvmode' 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
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 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
