From: Olaf Hering <hidden> Date: 2001-08-06 08:06:44
On Mon, Aug 06, Geert Uytterhoeven wrote:
IFF this is a correct fix, please also change
- the name in the comment
- the ordering in the table a bit lower (must be sorted)
This isnt the correct fix, only a workaround to avoid a kernel arg ;)
The correct fix is either "video=1280x1024-8@60" as kernel arg (that may
work) or the aty128fb driver must check the panel size. There is some
code for mach64 in XFree86 4.1.
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2001-08-06 10:59:55
Olaf Hering writes:
> This isnt the correct fix, only a workaround to avoid a kernel arg ;)
I tried all the kernel video args that made sense to me and all the
ones that were suggested to me by others. None of them worked. The
second version of the patch works.
> The correct fix is either "video=1280x1024-8@60" as kernel arg
> (that may work)
This is *not* one of the ones I tried. At this point all the kernels
I have on hand have already been hacked with the workaround patch, so
I can't test this on a "clean" kernel until I have time to build one.
Next weekend, maybe. I seem to be the one and only tester for this
issue, so I'll try to do it sooner if I can...
Is '-8' the depth? I.e., should I replace this with '-24' if I want
24-bit color?
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2001-08-06 11:42:49
Olaf Hering writes:
> The correct fix is either "video=1280x1024-8@60" as kernel arg (that may
> work)
OK, I just had time to rebuild 2.4.8-pre3-ben0 with the patch undone.
This video arg with that kernel doesn't solve the problem. I still
get no video on boot.
> or the aty128fb driver must check the panel size.
Sounds like this proper patch is going to be necessary. In the
meantime I'll use the workaround of clobbering the values in one of
the existing modes.
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Dänzer <hidden> Date: 2001-08-06 12:19:58
R Shapiro wrote:
Olaf Hering writes:
> The correct fix is either "video=1280x1024-8@60" as kernel arg (that may
> work)
OK, I just had time to rebuild 2.4.8-pre3-ben0 with the patch undone.
This video arg with that kernel doesn't solve the problem. I still
get no video on boot.
Wouldn't it have to be video=aty128fb:1280x1024-8@60 anyway, and is the modedb
even used on PPC yet?
--
Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast \ XFree86 and DRI project member
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2001-08-07 00:17:03
Michel Dänzer writes:
> Wouldn't it have to be video=aty128fb:1280x1024-8@60
Yep, that seems to be the required syntax. At least it works with an
unpatched 2.4.8-pre3-ben0 kernel. Many thanks.
> is the modedb even used on PPC yet?
I don't know the answer to that one.
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Dänzer <hidden> Date: 2001-08-07 07:16:08
R Shapiro wrote:
Michel Dänzer writes:
> Wouldn't it have to be video=aty128fb:1280x1024-8@60
Yep, that seems to be the required syntax. At least it works with an
unpatched 2.4.8-pre3-ben0 kernel. Many thanks.
Cool.
> is the modedb even used on PPC yet?
I don't know the answer to that one.
Yes you do. :) The fact that the above line works implies that modedb is used.
--
Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast \ XFree86 and DRI project member
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Olaf Hering writes:
> The correct fix is either "video=1280x1024-8@60" as kernel arg (that may
> work)
OK, I just had time to rebuild 2.4.8-pre3-ben0 with the patch undone.
This video arg with that kernel doesn't solve the problem. I still
get no video on boot.
Wouldn't it have to be video=aty128fb:1280x1024-8@60 anyway, and is the modedb
video=mode specifies the global mode, for all fbdevs that use modedb.
even used on PPC yet?
That's not the right question :-) Modedb doesn't depend on the architecture,
but on the driver.
Yes, atyfb was the first one to have modedb. Remember, I have a RAGE II+ in my
LongTrail :-)
PowerMac/CHRP has even extra modedb support in macmodes.
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Dänzer <hidden> Date: 2001-08-08 00:49:05
Geert Uytterhoeven wrote:
On Mon, 6 Aug 2001, Michel Dänzer wrote:
quoted
R Shapiro wrote:
quoted
Olaf Hering writes:
> The correct fix is either "video=1280x1024-8@60" as kernel arg (that
> may work)
OK, I just had time to rebuild 2.4.8-pre3-ben0 with the patch undone.
This video arg with that kernel doesn't solve the problem. I still
get no video on boot.
Wouldn't it have to be video=aty128fb:1280x1024-8@60 anyway, and is the
modedb
video=mode specifies the global mode, for all fbdevs that use modedb.
Ah, cool. So what's your theory on why it didn't work for R?
quoted
even used on PPC yet?
That's not the right question :-) Modedb doesn't depend on the architecture,
but on the driver.
I meant to say 'in aty128fb on PPC'. Last time I looked, the call to find a
mode was disabled for PPC.
Yes, atyfb was the first one to have modedb. Remember, I have a RAGE II+ in
my LongTrail :-)
Didn't mean to question that.
PowerMac/CHRP has even extra modedb support in macmodes.
Would that explain the disabled direct call?
--
Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast \ XFree86 and DRI project member
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Olaf Hering writes:
> The correct fix is either "video=1280x1024-8@60" as kernel arg (that
> may work)
OK, I just had time to rebuild 2.4.8-pre3-ben0 with the patch undone.
This video arg with that kernel doesn't solve the problem. I still
get no video on boot.
Wouldn't it have to be video=aty128fb:1280x1024-8@60 anyway, and is the
modedb
video=mode specifies the global mode, for all fbdevs that use modedb.
Ah, cool. So what's your theory on why it didn't work for R?
quoted
quoted
even used on PPC yet?
That's not the right question :-) Modedb doesn't depend on the architecture,
but on the driver.
I meant to say 'in aty128fb on PPC'. Last time I looked, the call to find a
mode was disabled for PPC.
quoted
PowerMac/CHRP has even extra modedb support in macmodes.
Would that explain the disabled direct call?
If it calls mac_fb_find_mode() instead, that's fine, since it falls back to
fb_find_mode() if the mode name doesn't match mac*.
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2001-08-08 11:25:14
Michel Dänzer writes:
> > video=mode specifies the global mode, for all fbdevs that use modedb.
>
> Ah, cool. So what's your theory on why it didn't work for R?
I'm also curious about this.
Is video=1280x1024-8@60 supposed to haved worked? It doesn't work for
me, but video=atyfb128:1280x1024-8@60 does work -- does that mean my
system is misconfigured in some way? If so I'd like to fix it. I'm
running 2.4.8-pre3-ben0 on a G4/450 with a Rage128 graphics card, a
DVIator dvi->adc adapter, and an Apple lcd17. dmesg says:
aty128fb: Rage128 Pro PF (AGP) [chip rev 0x1] 16M 128-bit SDR SGRAM (1:1)
Console: switching to colour frame buffer device 160x64
fb0: ATY Rage128 frame buffer device on PCI
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/