Re: lcd17 kernel patches?

Re: lcd17 kernel patches?

[R Shapiro]

Olaf Hering writes:
 > Try this one in the meantime:

I tried this patch with the current benh tree.  No luck.  It compiles
ok, in fact in runs ok, but without any video.  This is the same
behavior I get when I run my previously built 2.4.6 and 2.4.7 kernels.
This is *not* the behavior with the 2.4.2 kernel at the suse ftp site.
Something more must have been done to that one.

I guess I'll stick with 2.4.2 a little longer.

--
reshapiro@mediaone.net


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lcd17 kernel patches?

[R Shapiro]

Olaf Hering writes:
 > Try this one in the meantime:

OK, this mostly works with the 2.4.7 kernel sources, but there's one
important difference between the building a kernel this way and
running that prebuilt 2.4.2.  The prebuilt kernel has working video
immediately on booting.  The kernel I built with your patch has no
video at all until I run 'fbset 1280x1024-60'.  Clearly there's more
to that prebuilt 2.4.2 than just an additional mode definition.

But this will do for now - thanks for the patch.  I created an init.d
entry which runs the fbset command and I set it to run very early
(00).  So at least I can see some of the boot messages as they go by.
Maybe I could put it in inittab or rc.sysinit to get it even earlier.
But I might rather wait for a real patch.




--
reshapiro@mediaone.net


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lcd17 kernel patches?

[Olaf Hering]

On Sun, Aug 05, Olaf Hering wrote:

>
> On Sun, Aug 05, R Shapiro wrote:
>
> >
> > When will the lcd17 kernel patches (needed to run linux on Apple's 17"
> > flat panel display) make it into penguinppc.org::linux-2.4-benh?  Or
> > are they there already? I'm running someone's prebuilt 2.4.2 with
> > those patches right now, since that seemed to be the only way to get
> > them.  But I'd really rather build my own kernel, with my preferred
> > .config and newer souces, if I can.
>
> Try this one in the meantime:
>
> diff -urN linux-2.4.7-orig/drivers/video/macmodes.c
> linux-2.4.7-pci/drivers/video/macmodes.c
> --- linux-2.4.7-orig/drivers/video/macmodes.c   Thu Jun 28 02:10:55 2001
> +++ linux-2.4.7-pci/drivers/video/macmodes.c    Sun Aug  5 20:03:16 2001
> @@ -68,7 +68,7 @@
>         0, FB_VMODE_NONINTERLACED
>      }, {
>         /* 1024x768, 60 Hz, Non-Interlaced (65.00 MHz dotclock) */
> -       "mac14", 60, 1024, 768, 15385, 144, 40, 29, 3, 136, 6,
> +        "mac14", 60, 1280, 1024, 15358, 160, 24, 29, 3, 136, 6,
>         0, FB_VMODE_NONINTERLACED
>      }, {
>         /* 1024x768, 72 Hz, Non-Interlaced (75.00 MHz dotclock) */

wrong timings:

9260 248 48 38 1 112 3
replace the 15358 .. with the stuff above.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lcd17 kernel patches?

[Geert Uytterhoeven]

On Sun, 5 Aug 2001, Olaf Hering wrote:
> On Sun, Aug 05, R Shapiro wrote:
> > When will the lcd17 kernel patches (needed to run linux on Apple's 17"
> > flat panel display) make it into penguinppc.org::linux-2.4-benh?  Or
> > are they there already? I'm running someone's prebuilt 2.4.2 with
> > those patches right now, since that seemed to be the only way to get
> > them.  But I'd really rather build my own kernel, with my preferred
> > .config and newer souces, if I can.
>
> Try this one in the meantime:
>
> diff -urN linux-2.4.7-orig/drivers/video/macmodes.c
> linux-2.4.7-pci/drivers/video/macmodes.c
> --- linux-2.4.7-orig/drivers/video/macmodes.c   Thu Jun 28 02:10:55 2001
> +++ linux-2.4.7-pci/drivers/video/macmodes.c    Sun Aug  5 20:03:16 2001
> @@ -68,7 +68,7 @@
>         0, FB_VMODE_NONINTERLACED
>      }, {
>         /* 1024x768, 60 Hz, Non-Interlaced (65.00 MHz dotclock) */
> -       "mac14", 60, 1024, 768, 15385, 144, 40, 29, 3, 136, 6,
> +        "mac14", 60, 1280, 1024, 15358, 160, 24, 29, 3, 136, 6,
>         0, FB_VMODE_NONINTERLACED
>      }, {
>         /* 1024x768, 72 Hz, Non-Interlaced (75.00 MHz dotclock) */

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)

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/

Re: lcd17 kernel patches?

[Olaf Hering]

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/

Re: lcd17 kernel patches?

[R Shapiro]

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/

Re: lcd17 kernel patches?

[Olaf Hering]

On Mon, Aug 06, R Shapiro wrote:

> Is '-8' the depth?  I.e., should I replace this with '-24' if I want
> 24-bit color?

It is 8bit, but no need to have more than 8 bit on the console, it will
only make it slow. X can switch the color depth if needed.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lcd17 kernel patches?

[R Shapiro]

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/

Re: lcd17 kernel patches?

[Michel Dänzer]

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/

Re: lcd17 kernel patches?

[R Shapiro]

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/

Re: lcd17 kernel patches?

[Michel Dänzer]

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/

Re: lcd17 kernel patches?

[Geert Uytterhoeven]

On Mon, 6 Aug 2001, Michel Dänzer wrote:
> 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

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/

Re: lcd17 kernel patches?

[Olaf Hering]

On Tue, Aug 07, Geert Uytterhoeven wrote:

> On Mon, 6 Aug 2001, Michel Dänzer wrote:
> > 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
>
> video=mode specifies the global mode, for all fbdevs that use modedb.

You mean video=1280x1024-8@60 is supposed to work? I think that syntax
makes much more sense than video=aty128fb:1280x1024-8@60 when you have
only one card or when only one fbdriver is active.



Gruss Olaf


--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lcd17 kernel patches?

[Michel Dänzer]

Geert Uytterhoeven wrote:
>
> On Mon, 6 Aug 2001, Michel Dänzer wrote:
> > 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
>
> 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?


> > 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/

Re: lcd17 kernel patches?

[Geert Uytterhoeven]

On Wed, 8 Aug 2001, Michel Dänzer wrote:
> Geert Uytterhoeven wrote:
> > On Mon, 6 Aug 2001, Michel Dänzer wrote:
> > > 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
> >
> > 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?
>
>
> > > 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.
>
> > 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/

Re: lcd17 kernel patches?

[R Shapiro]

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/