Re: patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128

Re: patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128

[Michel Danzer]

--- Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> wrote:

> > > Possibly; I've also seen the X server convert XFree mode lines into
> > > fbdev timings, thereby overwriting the 565 with 000. Doesn't hurt for
16
> > > bits, only for 32 bits.
> >
> > Doesn't hurt for probing, but maybe for the ioctl?
>
> The ioctl has been disabled long time ago.

I meant when you hadn't disabled it. It hung there at the time, right? Now a
hang in an ioctl is a kernel bug, or am I missing something?


> I'll get back to poking around in there as soon as I can figure out how to
> see the kernel messages (i.e. how to switch back to the text console fast
> enough, or never let the X server switch to VT 7 in the first place).

A remote machine might be handy...


> Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
> me, perhaps.

Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.

I don't understand the code there...

BTW I've just discovered that the fbdev driver sets the weight explicitly to
{0,0,0}... now I'm (really ;) confused.


> I guess it all boils down to PCI messups.

How do you come to this conclusion? Why should it influence ioctls?


Michel

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

Re: patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128

[Michael Schmitz]

> > > Doesn't hurt for probing, but maybe for the ioctl?
> >
> > The ioctl has been disabled long time ago.
>
> I meant when you hadn't disabled it. It hung there at the time, right? Now a
> hang in an ioctl is a kernel bug, or am I missing something?

No, you're right :-)

> > I'll get back to poking around in there as soon as I can figure out how to
> > see the kernel messages (i.e. how to switch back to the text console fast
> > enough, or never let the X server switch to VT 7 in the first place).
>
> A remote machine might be handy...

That's what I'm using already. But the kernel messages that otherwise
appear on the text screen won't get redirected to a remote machine.
Nothing ever ends up in the syslog, anyway. I guess the klogd/syslogd
combo is too slow in this case.

> > Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
> > me, perhaps.
>
> Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.

Probably. I'll have to trace all these ioctls as soon as I can keep the X
server from switching consoles.

> I don't understand the code there...

The cmap only passes the pointers to the color values. fb_set_cmap does
get_user on those so it should be OK. Don't ask me why X sets each entry
separately though (on some braindead Mac video cards this means you have
to start setting the cmap from entry 0 until you hit the right one, each
time).

> BTW I've just discovered that the fbdev driver sets the weight explicitly to
> {0,0,0}... now I'm (really ;) confused.

So was I.

> > I guess it all boils down to PCI messups.
>
> How do you come to this conclusion? Why should it influence ioctls?

Because these ioctls will, ultimately, write to the card again? If the X
server actually messes with the PCI bridges, the card might no longer be
mapped?
I admit that I understand next to nothing about PCI, or how the X server
uses PCI. Makes it a bit harder to spot the flaky code :-)

Anyway, the X server appears to complete screen init OK but I never
actually get to see the cross hatch pattern.

	Michael


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

Re: patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128

[Kostas Gewrgiou]

On Wed, 15 Mar 2000, Michael Schmitz wrote:

>
> > > I guess it all boils down to PCI messups.
> >
> > How do you come to this conclusion? Why should it influence ioctls?
>
> Because these ioctls will, ultimately, write to the card again? If the X
> server actually messes with the PCI bridges, the card might no longer be
> mapped?
> I admit that I understand next to nothing about PCI, or how the X server
> uses PCI. Makes it a bit harder to spot the flaky code :-)
>
> Anyway, the X server appears to complete screen init OK but I never
> actually get to see the cross hatch pattern.


  The X server has played with the cards mappings, since it believed the
old ones were wrong. atyfb will still try to access the card in the old
location and thats what gives you the hard locks.

  The question is why the X server doesn't like the old mappings ?
If you can send me the /var/log/XFree86.0.log and lspci output i'll
forward it in the xfree devel list and see what answers we can get from
there.

  Kostas


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

Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kevin Hendricks]

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

Hi Kostas,

With lots of help from Ben, we were able to figure out that the OF values used
to initialize the Rage128 and Rage128Pro cards are the same ones used by the
MacOS and that we can actually read the X_MPLL_REF_FB_DIV value, the XCLK_CNTL,
and PLL_REF_DIV values and calculate the proper XCLK.  In a similar way you can
calculate the MCLK value too so you can get or calculate almost all of the same
info as is probed from the Bios under x86 machines.

This allows both machines with G3s, and G4 (even with the Rage 128 cards) to
work with the same aty128fb.c kernel driver without any table lookups.

The patch to add this to the aty128fb.c is attached.  I have also used
similar code to replace the bios code probe for powerpc in the r128_driver.c for
xf400. The patch to do that is also attached.

These patches have been tested and work fine on my B+W G3 rev 2, my brand new
G4 with Rage128Pro card, and on Ben's older G4 with the non-pro card.

We still need to test this on a B+W G3 revision 1 just to be complete (but Ben
will do that soon).

Assuming they test out fine, Kostas would you see about getting the r128 patch
integrated into the next xf40X release while I see about getting Paul and/or
Anthony to integrate the aty128fb.c patch into both the stable and development
kernels.

Hopefully with these in place, new G4s will work as well as older G4s
and G3s.

Thanks!!!

Kevin


--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


[-- Attachment #2: xf4_usepll.patch.gz --]
[-- Type: application/x-gzip, Size: 968 bytes --]

[-- Attachment #3: aty128fb_fix.patch.gz --]
[-- Type: application/x-gzip, Size: 899 bytes --]

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[anthony tong]

Kevin Hendricks (Mon, Mar 20, 2000 at 09:48:30PM -0500):
> Assuming they test out fine, Kostas would you see about getting the r128 patch
> integrated into the next xf40X release while I see about getting Paul and/or
> Anthony to integrate the aty128fb.c patch into both the stable and development
> kernels.
>
> Hopefully with these in place, new G4s will work as well as older G4s
> and G3s.

Looks good and works fine here..

Thanks for the hard work, Kevin!
-at

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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Benjamin Herrenschmidt]

On Mon, Mar 20, 2000, Kevin Hendricks <khendricks@ivey.uwo.ca> wrote:

>These patches have been tested and work fine on my B+W G3 rev 2, my brand new
>G4 with Rage128Pro card, and on Ben's older G4 with the non-pro card.
>
>We still need to test this on a B+W G3 revision 1 just to be complete
(but Ben
>will do that soon).

Apparently, it works on all machines. I just tested on a B&W G3 rev. 1
and an iMac DV. It works also on the M3 (new r128 mobility in pismo).

However, I noticed that in all cases (or almost all cases), we have the
same XCLK as MacOS (and probably the same MCLK, I didn't verify), but we
obtain it using a lower divider. For example, on the B&W rev. 1, we have
0x1f for the ref. div, and I have 0x38 (instead of 0x3b used by MacOS).

I don't know if there's a real impact (less precise pixel clock ?). At
least, now it works on all machines, which was not the case previously.

My rsync tree contains the same kernel as Paul's latest stable tree with
a backport of 2.3.x current aty128fb with your changes (and other pismo
powerbook support stuffs). I didn't add Ani Joshi patches yet.

I'll post pre-compiled once I feel the pismo stuffs are clean enough (and
there's another problem with the latest aty128, sometimes, I've seen some
erase problems in console mode. Not very important, but...). I'll then
merge my stuffs in 2.2.x and 2.3.x bk trees.


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kostas Gewrgiou]

On Mon, 20 Mar 2000, Kevin Hendricks wrote:

> Hi Kostas,
>
> With lots of help from Ben, we were able to figure out that the OF values used
> to initialize the Rage128 and Rage128Pro cards are the same ones used by the
> MacOS and that we can actually read the X_MPLL_REF_FB_DIV value, the XCLK_CNTL,
> and PLL_REF_DIV values and calculate the proper XCLK.  In a similar way you can
> calculate the MCLK value too so you can get or calculate almost all of the same
> info as is probed from the Bios under x86 machines.
>

 From the patches i see that the reference freq is still assumed to be
29.50Mhz
     /* Assume REF clock is 2950 (in units of 10khz) */
     /* and that all pllclk must be between 125 Mhz and 250Mhz */
     pll->reference_freq = 2950;
     pll->min_pll_freq   = 12500;
     pll->max_pll_freq   = 25000;

 From the comments in the xfree driver (and the ati docs) this isn't always
true:
     /* These probably aren't going to work for
        the card you are using.  Specifically,
        reference freq can be 29.50MHz,
        28.63MHz, or 14.32MHz.  YMMV. */

So we need to find a way to calculate the reference freq, without it
xfree/aty128fb still won't do the right thing :(


> This allows both machines with G3s, and G4 (even with the Rage 128 cards) to
> work with the same aty128fb.c kernel driver without any table lookups.
>
> The patch to add this to the aty128fb.c is attached.  I have also used
> similar code to replace the bios code probe for powerpc in the r128_driver.c for
> xf400. The patch to do that is also attached.
>
> These patches have been tested and work fine on my B+W G3 rev 2, my brand new
> G4 with Rage128Pro card, and on Ben's older G4 with the non-pro card.
>
> We still need to test this on a B+W G3 revision 1 just to be complete (but Ben
> will do that soon).
>
> Assuming they test out fine, Kostas would you see about getting the r128 patch
> integrated into the next xf40X release while I see about getting Paul and/or
> Anthony to integrate the aty128fb.c patch into both the stable and development
> kernels.
>

  I'll be more than happy to get the patches in the xfree tree, even with
the reference_freq hardcoded its still an improvement.

#ifdef __powerpc__ for this it should be better to see if the card has
an OF or BIOS rom first since that will allow people to keep using cards
with bios roms under ppc (i wonder if anyone is doing this)
Any ideas on how we can check if a card has OF or BIOS roms ?

> Hopefully with these in place, new G4s will work as well as older G4s
> and G3s.
>
> Thanks!!!
>
> Kevin


  Kostas


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[anthony tong]

Kostas Gewrgiou (Tue, Mar 21, 2000 at 06:56:25PM +0200):
>  From the patches i see that the reference freq is still assumed to be
> 29.50Mhz
>      /* Assume REF clock is 2950 (in units of 10khz) */
>      /* and that all pllclk must be between 125 Mhz and 250Mhz */
>      pll->reference_freq = 2950;
>      pll->min_pll_freq   = 12500;
>      pll->max_pll_freq   = 25000;
>
>  From the comments in the xfree driver (and the ati docs) this isn't always
> true:
>      /* These probably aren't going to work for
>         the card you are using.  Specifically,
>         reference freq can be 29.50MHz,
>         28.63MHz, or 14.32MHz.  YMMV. */

I think that we can assume a 29.50 clock *for now*; lower clocks are
probably for future low powered/mobile versions of the chip.

> #ifdef __powerpc__ for this it should be better to see if the card has
> an OF or BIOS rom first since that will allow people to keep using cards
> with bios roms under ppc (i wonder if anyone is doing this)
> Any ideas on how we can check if a card has OF or BIOS roms ?

this is from memory (probably from the mach64 days): Bit 0 of the
PCI configuration register 0x30 is 0 if a PC style BIOS doesn't
exist. So we could do a check for that instead if this is verified
to still be true.

-at

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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Geert Uytterhoeven]

On Tue, 21 Mar 2000, anthony tong wrote:
> Kostas Gewrgiou (Tue, Mar 21, 2000 at 06:56:25PM +0200):
> > #ifdef __powerpc__ for this it should be better to see if the card has
> > an OF or BIOS rom first since that will allow people to keep using cards
> > with bios roms under ppc (i wonder if anyone is doing this)
> > Any ideas on how we can check if a card has OF or BIOS roms ?
>
> this is from memory (probably from the mach64 days): Bit 0 of the
> PCI configuration register 0x30 is 0 if a PC style BIOS doesn't
> exist. So we could do a check for that instead if this is verified
> to still be true.

Not true. Register 0x30 is 0 for both my S3 (with PC BIOS) and ATI (with OF
BIOS). I think you refer to the indiator for the enabled ROM?

    #define  PCI_ROM_ADDRESS_ENABLE 0x01

So you have to enable the ROM and check for the PC BIOS signature (don't know
what it is, but it should exist).

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: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kostas Gewrgiou]

On Tue, 21 Mar 2000, anthony tong wrote:

> Kostas Gewrgiou (Tue, Mar 21, 2000 at 06:56:25PM +0200):
> >  From the patches i see that the reference freq is still assumed to be
> > 29.50Mhz
> >      /* Assume REF clock is 2950 (in units of 10khz) */
> >      /* and that all pllclk must be between 125 Mhz and 250Mhz */
> >      pll->reference_freq = 2950;
> >      pll->min_pll_freq   = 12500;
> >      pll->max_pll_freq   = 25000;
> >
> >  From the comments in the xfree driver (and the ati docs) this isn't always
> > true:
> >      /* These probably aren't going to work for
> >         the card you are using.  Specifically,
> >         reference freq can be 29.50MHz,
> >         28.63MHz, or 14.32MHz.  YMMV. */
>
> I think that we can assume a 29.50 clock *for now*; lower clocks are
> probably for future low powered/mobile versions of the chip.
>

  Well in my x86 machine the ati card uses a lower clock now
if cards with a clock different than 29.50MHz are used in Macs
or not is another matter.

(--) r128(0): Chipset: "ATI Rage 128 RF (AGP)" (ChipID = 0x5246)
(--) r128(0): VideoRAM: 32768 kByte (64-bit SDR SGRAM 2:1)
(II) r128(0): PLL parameters: rf=1432 rd=31 min=12500 max=25000; xclk=6000

>
> -at


 Kostas


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kevin B. Hendricks]

Hi,

>> I think that we can assume a 29.50 clock *for now*; lower clocks are
>> probably for future low powered/mobile versions of the chip.
>>
>
>  Well in my x86 machine the ati card uses a lower clock now
>if cards with a clock different than 29.50MHz are used in Macs
>or not is another matter.
>
>(--) r128(0): Chipset: "ATI Rage 128 RF (AGP)" (ChipID = 0x5246)
>(--) r128(0): VideoRAM: 32768 kByte (64-bit SDR SGRAM 2:1)
>(II) r128(0): PLL parameters: rf=1432 rd=31 min=12500 max=25000; xclk=6000

>From reading the Rage 128 register pdf info, there is one interesting
constraint that may help us here.

As it turns out you can read the M, Nx, and Nm values from the
X_MPLL_REF_FB_DIV register and it is used in the following constraints:

REF >= 40 * M    (from REF/M >= 400khz)

REF >= 625 * M / min(Nx,Nm)   (from 125MHZ <= PLLCLK <= 250MHZ
                                 for xpllclk, and mpllclk)

REF <= 1250 * M / max(Nx,Nm)  (ditto)


So we should be able to check each ratio and eliminate and the values of
REF that don't meet this constraint.

There are probably other constraints as well.  I will keep looking.  Maybe
in some combination, we can rule out all but one value for REF  (he said
hopefully...with his fingers crossed).

Kevin


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kevin B. Hendricks]

Hi,


Whoops I am off by a factor of 10 in conmstraints 2 and 3 below

>REF >= 625 * M / min(Nx,Nm)   (from 125MHZ <= PLLCLK <= 250MHZ

Should be REF >= 6250 * M / min(Nx,Nm)


>REF <= 1250 * M / max(Nx,Nm)  (ditto)

Should be REF <= 12500 * M / max(Nx,Nm).

Using the values from my Rage128Pro

X_MPLL_REF_FB_DIV = 0xe88a3a

so
Nm = 0xe8 = 232
Nx = 0x8a = 138
M = 0x3a = 58

So

REF >= (40 * 58) = 2320  (so this rules out the 14.32 MHZ version)

REF >= 6250 * 58 / min(232,138) = 2626

REF <= 12500 * 58 / max(232,138) = 3125


So unfortunately, we still need another constraint to select between the
29.50 MHZ REF value and the 28.63 MHZ REF value.  They may be so close that
we won't be able to ever tell them apart.

I will keep looking.

Kevin


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kevin B. Hendricks]

Hi,

> From the patches i see that the reference freq is still assumed to be
>29.50Mhz
>     /* Assume REF clock is 2950 (in units of 10khz) */
>     /* and that all pllclk must be between 125 Mhz and 250Mhz */
>     pll->reference_freq = 2950;
>     pll->min_pll_freq   = 12500;
>     pll->max_pll_freq   = 25000;


Yes, that's true.  Luckily, all of the Mac's use Rage128 cards with 2950 AFAIK.
I will keep looking through the manual to see if I can figure out a way to
determine this without a bios.

> From the comments in the xfree driver (and the ati docs) this isn't always
>true:
>     /* These probably aren't going to work for
>        the card you are using.  Specifically,
>        reference freq can be 29.50MHz,
>        28.63MHz, or 14.32MHz.  YMMV. */

Yes I know.

>  I'll be more than happy to get the patches in the xfree tree, even with
>the reference_freq hardcoded its still an improvement.

Jacl Howarth just report a 30% performance increase in some x11perf tests
on XF 4.0 with the new patch versus the old values!  That makes me feel
better.

>#ifdef __powerpc__ for this it should be better to see if the card has
>an OF or BIOS rom first since that will allow people to keep using cards
>with bios roms under ppc (i wonder if anyone is doing this)
>Any ideas on how we can check if a card has OF or BIOS roms ?

Unforntunately, the current xf4 bios check does not work on some G3s and
G4's.  Literally tmp[] comes back with the right values that leads you to
believe that the Bios is there but the values for ref, the max and min pll,
read from the "Bios" etc are truly garbage (i.e. xlck reads as 0).  The
only reason it still worked was that none of the builtin modes fit the max
and min pll values so no modes were found so the r128_driver.c just
defaulted to the current fb mode which works.

I think a better check for a bios being present would detect the issue and
we code default to of values set in the pll registers next.

Thanks!

Kevin


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Kostas Gewrgiou]

On Tue, 21 Mar 2000, Kevin B. Hendricks wrote:

> Hi,
>
> > From the patches i see that the reference freq is still assumed to be
> >29.50Mhz
> >     /* Assume REF clock is 2950 (in units of 10khz) */
> >     /* and that all pllclk must be between 125 Mhz and 250Mhz */
> >     pll->reference_freq = 2950;
> >     pll->min_pll_freq   = 12500;
> >     pll->max_pll_freq   = 25000;
>
>
> Yes, that's true.  Luckily, all of the Mac's use Rage128 cards with 2950 AFAIK.
> I will keep looking through the manual to see if I can figure out a way to
> determine this without a bios.
>

  If most Mac's use cards with 2950 then we should be fine for now, but for
the future we need to find a way to get this right.

> > From the comments in the xfree driver (and the ati docs) this isn't always
> >true:
> >     /* These probably aren't going to work for
> >        the card you are using.  Specifically,
> >        reference freq can be 29.50MHz,
> >        28.63MHz, or 14.32MHz.  YMMV. */
>
> Yes I know.
>
> >  I'll be more than happy to get the patches in the xfree tree, even with
> >the reference_freq hardcoded its still an improvement.
>
> Jacl Howarth just report a 30% performance increase in some x11perf tests
> on XF 4.0 with the new patch versus the old values!  That makes me feel
> better.
>

 Wow thats something :)

> >#ifdef __powerpc__ for this it should be better to see if the card has
> >an OF or BIOS rom first since that will allow people to keep using cards
> >with bios roms under ppc (i wonder if anyone is doing this)
> >Any ideas on how we can check if a card has OF or BIOS roms ?
>
> Unforntunately, the current xf4 bios check does not work on some G3s and
> G4's.  Literally tmp[] comes back with the right values that leads you to
> believe that the Bios is there but the values for ref, the max and min pll,
> read from the "Bios" etc are truly garbage (i.e. xlck reads as 0).  The
> only reason it still worked was that none of the builtin modes fit the max
> and min pll values so no modes were found so the r128_driver.c just
> defaulted to the current fb mode which works.
>
> I think a better check for a bios being present would detect the issue and
> we code default to of values set in the pll registers next.
>

  The current code always assume that the ROM is a BIOS one, the 2 bytes
that it checks in the beggining are probably present in OF ati cards as
well so it thinks that everything is ok, we need to know if the card has
an OF rom or not (this is needed for other places in xfree as well the
int10 module will try to softboot OF cards also), i am sure there is a way
to find this i'll check the OF docs and see if i can find something.

> Thanks!
>
> Kevin
>


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

Re: Patches to fix aty128fb and xf400 r128 to work with both Rage128 and Rage128Pros

[Gabriel Paubert]

On Tue, 21 Mar 2000, Kostas Gewrgiou wrote:

>   The current code always assume that the ROM is a BIOS one, the 2 bytes
> that it checks in the beggining are probably present in OF ati cards as
> well so it thinks that everything is ok, we need to know if the card has
> an OF rom or not (this is needed for other places in xfree as well the
> int10 module will try to softboot OF cards also), i am sure there is a way
> to find this i'll check the OF docs and see if i can find something.

All ROMS start AFAICT with 0x55,0xaa (or the other way around) followed by
a byte which gives the size of the ROM in 512 bytes blocks. On x86 the
entry point is at offset 0x03 and is always a jump (at least I have never
seen a board in whichit was not a jump), the opcode of which is 0xe9 or
0xeb. Could this be used as a test or as at least an heuristic ?

	Gabriel.


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

Some issues to resolve with XFree 4.0 yet

[Kevin Hendricks]

Hi Kostas,

I have set up my XF86Config file to allow mode switching (with valid mode info)
by hitting the Cntl-Alt-KeyPad- and Cntl-Alt-KeyPad+ keys.  Unfortunately,
although the mode seems to switch the screen is very messed up.  Luckily, if I
keep hitting the key combo I get back to a good resolution.  I tracked this
back to fbdevxxxSwitchMode which uses a framebuffer ioctl (FBIOPUT_VSCREENINFO)
which in turn is handled in linux/drivers/video/fbmem.c and eventually calls
aty128fb.c set_var routine.

Something here is broken but I can't put my finger on what yet.  Does using the
key combo to switch modes on the fly under R128 work for you on your x86
machine?

Also, I tried to test this under the XFree86 running fbdev as its driver.  Each
time I tried this I ended up with a complete hard lockup (kernel went boom).  I
tried connecting from other machines on my home network but I got no response
at all.

This used to work fine under xf 3.9.17.   Have you tried this recently?

Thanks,

Kevin


--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


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