Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michel Dänzer]

[For the linuxppc-dev people: this is about the DRI CVS trunk]

Kostas Gewrgiou wrote:

> > GL clients even seem to attempt direct rendering now, however I get one of
> > two different errors every time:
> >
> > Error: Rage 128 timed out... exiting
> >
> > Error: Could not submit packet... exiting
>
>   From what i see the problem is probably in the R128_READ/WRITE macros in
> r128_drv.h you need byteswapping functions there (and memory barriers as
> usual).

That did it, thanks! I changed those macros to use the same inline functions
which are used for MMIO_{IN,OUT} on PPC, and here we go!


The remaining problems are:

16 bit doesn't work neither with fbdev (colors completely off - does aty128fb
still use 15 bit in fact?) nor without (at least the grey tones are right
there - wrong endianness?)

At 32 bit, it flickers badly on my Pismo, probably because it only has 8 megs
of VRAM. (These messages appear in the log:
(EE) r128(0): Unable to reserve depth buffer
(EE) r128(0): Unable to reserve texture space in frame buffer
) Curious how it works out for people with more...


About performance: It's much better than software rendering (at least for big
windows) of course, however not too fast with lots of polygons. AGP GART would
definitely be a good thing I guess (Ben: hint, hint :)


Still, big kudos to the DRI team for a great work!

Michel


--
Sometimes you have to stride boldly up to life,
 look it straight in the eye, and say "huh?"
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michel Dänzer]

Michel Dänzer wrote:

> 16 bit doesn't work neither with fbdev (colors completely off - does
> aty128fb still use 15 bit in fact?)

fbset -i reveals that it does.


Is anyone actively maintaining aty128fb or should I try to fix that as well as
the panning? Looking at the X r128 driver, it shouldn't be too hard.


Michel


--
Coming to you live from a finite point in the space-time continuum!
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Benjamin Herrenschmidt]

>fbset -i reveals that it does.
>
>
>Is anyone actively maintaining aty128fb or should I try to fix that as
well as
>the panning? Looking at the X r128 driver, it shouldn't be too hard.

Brad Douglas, but he doesn't have a PPC machine.


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

Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michel Dänzer]

Benjamin Herrenschmidt wrote:

[about aty128fb setting the RAMDAC to 15 bit for depth 16]

> > fbset -i reveals that it does.
> >
> > Is anyone actively maintaining aty128fb or should I try to fix that as
> > well as the panning? Looking at the X r128 driver, it shouldn't be too
> > hard.
>
> Brad Douglas, but he doesn't have a PPC machine.

Okay, I'll contact him, thanks.

My priority is to get 16 bit working, panning isn't so important for me
because only one mode works on the Pismo anyway.

Unfortunately, I don't have time over the weekend, but I'm cooking up a patch
X 4.0.1 -> DRI CVS which I'm sending to the people involved.


Michel


--
I'm so hungry, I could almost eat health food.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Kostas Gewrgiou]

On Fri, 4 Aug 2000, Michel [iso-8859-1] Dδnzer wrote:

>
> [For the linuxppc-dev people: this is about the DRI CVS trunk]
>
> Kostas Gewrgiou wrote:
>
> > > GL clients even seem to attempt direct rendering now, however I get one of
> > > two different errors every time:
> > >
> > > Error: Rage 128 timed out... exiting
> > >
> > > Error: Could not submit packet... exiting
> >
> >   From what i see the problem is probably in the R128_READ/WRITE macros in
> > r128_drv.h you need byteswapping functions there (and memory barriers as
> > usual).
>
> That did it, thanks! I changed those macros to use the same inline functions
> which are used for MMIO_{IN,OUT} on PPC, and here we go!
>

Great news :)

> The remaining problems are:
>
> 16 bit doesn't work neither with fbdev (colors completely off - does aty128fb
> still use 15 bit in fact?) nor without (at least the grey tones are right
> there - wrong endianness?)

Yes aty128fb still doesn't support 16 bit, you could run the r128 driver
without fbdev to get 16 bits, but the code to switch the framebuffer to do
byteswapping is missing so the colors will be wrong (easy to add though).

> At 32 bit, it flickers badly on my Pismo, probably because it only has 8 megs
> of VRAM. (These messages appear in the log:
> (EE) r128(0): Unable to reserve depth buffer
> (EE) r128(0): Unable to reserve texture space in frame buffer
> ) Curious how it works out for people with more...

Not enough memory for all the buffers indeed, you could try with a lower
res (if prismo allows that) to save some memory.

>
> About performance: It's much better than software rendering (at least for big
> windows) of course, however not too fast with lots of polygons. AGP GART would
> definitely be a good thing I guess (Ben: hint, hint :)
>

Do you have any numbers from gears, glquake etc ??

   Kostas


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

Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Benjamin Herrenschmidt]

>> At 32 bit, it flickers badly on my Pismo, probably because it only has
>8 megs
>> of VRAM. (These messages appear in the log:
>> (EE) r128(0): Unable to reserve depth buffer
>> (EE) r128(0): Unable to reserve texture space in frame buffer
>> ) Curious how it works out for people with more...
>
>Not enough memory for all the buffers indeed, you could try with a lower
>res (if prismo allows that) to save some memory.

The Pismo allows that by scaling the LCD, but I don't think code for that
is implemented in the XFree r128 driver (I didn't check lately).

Ben.

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Gareth Hughes]

Kostas Gewrgiou wrote:
>
> >
> > About performance: It's much better than software rendering (at least for big
> > windows) of course, however not too fast with lots of polygons. AGP GART would
> > definitely be a good thing I guess (Ben: hint, hint :)
> >
>
> Do you have any numbers from gears, glquake etc ??

Is someone working on the AGP GART module for PPC Linux?  Without that,
you're stuck with PIO mode which can be slower than software rendering.

Again, I'd love to help you guys out.  Do you have patches we could look
at?

-- Gareth

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michel Dänzer]

Benjamin Herrenschmidt wrote:
>
> >> At 32 bit, it flickers badly on my Pismo, probably because it only has
> >8 megs
> >> of VRAM. (These messages appear in the log:
> >> (EE) r128(0): Unable to reserve depth buffer
> >> (EE) r128(0): Unable to reserve texture space in frame buffer
> >> ) Curious how it works out for people with more...
> >
> >Not enough memory for all the buffers indeed, you could try with a lower
> >res (if prismo allows that) to save some memory.
>
> The Pismo allows that by scaling the LCD, but I don't think code for that
> is implemented in the XFree r128 driver (I didn't check lately).

No it doesn't work, neither with aty128fb. Would that be hard to implement?


Michel


--
If the box says `Windows 95 or better'', it should run on Linux, right?
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michel Dänzer]

Kostas Gewrgiou wrote:

> > The remaining problems are:
> >
> > 16 bit doesn't work neither with fbdev (colors completely off - does
> > aty128fb still use 15 bit in fact?) nor without (at least the grey tones
> > are right there - wrong endianness?)
>
> Yes aty128fb still doesn't support 16 bit, you could run the r128 driver
> without fbdev to get 16 bits, but the code to switch the framebuffer to do
> byteswapping is missing so the colors will be wrong

Yep, that's the second thing I was referring to.

> (easy to add though).

Where and how?


> > About performance: It's much better than software rendering (at least for
> > big windows) of course, however not too fast with lots of polygons. AGP
> > GART would definitely be a good thing I guess (Ben: hint, hint :)
>
> Do you have any numbers from gears, glquake etc ??

The numbers are very varying and not too high yet. AGP GART should change
that.


Michel


--
                                Tax the rich.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Josh Huber]

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

On Mon, Aug 07, 2000 at 09:08:01AM +0200, Michel D?nzer wrote:
> Benjamin Herrenschmidt wrote:
> > The Pismo allows that by scaling the LCD, but I don't think code for that
> > is implemented in the XFree r128 driver (I didn't check lately).
> 
> No it doesn't work, neither with aty128fb. Would that be hard to implement?

If it's anything like the mach 64, it shouldn't be hard to implement
at all.  you just have to program 3 registers.

Speaking of this, I'm having trouble with the stretching setup for my
wallstreet.  It works fine in console mode, but something in the X
server is messing with the chip setup in a way to screw up the
rendering.  After playing with it I was able to get proper output:

console settings:
    mclk = 99.844107 MHz
    vclk = 44.702930 MHz
    dsp_loop_latency = 10
    dsp_precision = 5
    dsp_xclks_per_row = 1143 => 17.859375
    dsp_on = 69 => 34.500000
    dsp_off = 1113 => 556.500000

X (xf4.0.1) settings:
    mclk = 99.844107 MHz
    vclk = 44.702930 MHz
    dsp_loop_latency = 10
    dsp_precision = 4
    dsp_xclks_per_row = 1143 => 8.929688
    dsp_on = 103 => 25.750000
    dsp_off = 1119 => 279.750000

X after tweaks to get it working properly:
    mclk = 99.844107 MHz
    vclk = 59.603906 MHz
    dsp_loop_latency = 10
    dsp_precision = 4
    dsp_xclks_per_row = 1143 => 8.929688
    dsp_on = 131 => 32.750000
    dsp_off = 1986 => 496.500000

using geerts handy ati debugging application, I set the vclk post
divider to 3 (was 4), and changed the high and low watermarks back to
what the console settings were, and things worked great in X now.  Of
course, if I switch back to a VC and back to X the old (bad) settings
come back.

Where's the proper place to fix this?  I assume it's not in the fbcon
interface, because text mode is correctly displayed.

Thoughts?

-- 
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Kostas Gewrgiou]

On Mon, 7 Aug 2000, Michel [iso-8859-1] Dδnzer wrote:

>
> Kostas Gewrgiou wrote:
>
> > > The remaining problems are:
> > >
> > > 16 bit doesn't work neither with fbdev (colors completely off - does
> > > aty128fb still use 15 bit in fact?) nor without (at least the grey tones
> > > are right there - wrong endianness?)
> >
> > Yes aty128fb still doesn't support 16 bit, you could run the r128 driver
> > without fbdev to get 16 bits, but the code to switch the framebuffer to do
> > byteswapping is missing so the colors will be wrong
>
> Yep, that's the second thing I was referring to.
>
> > (easy to add though).
>
> Where and how?
>

  Somewhere in R128ModeInit (or the functions that get called from it) will
do fine i think.
About how now look at the following code from aty128fb that does the same
thing.

    config = aty_ld_le32(CONFIG_CNTL) & ~3;
#if defined(__BIG_ENDIAN)
    if (par->crtc.bpp >= 24)
        config |= 2;    /* make aperture do 32 byte swapping */
    else if (par->crtc.bpp > 8)
        config |= 1;    /* make aperture do 16 byte swapping */
#endif
    aty_st_le32(CONFIG_CNTL, config);

  Kostas


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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Sven Goethel]

Dear r128/ppc developers,

I do follow your discussion for some days with a lot of
euphorism. I want to try hardware acceleration with my powerbook,
XF401+DRI for the GL4Java development.

Just a few questions:
	- which kernel ? (I currently use 2.4.0-test5)
	- XF4.0.1 ?
	- When and/or where can I get the working r128 linux kernel
	  sources for ppc - they seemed not to be included in the current CVS
tree.
	  I only get a LOCK_PREFIX unknown ...

Thanxs a lot for your engagement and time.

Yours, Sven
--
mailto:sgoethel@jausoft.com
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC XServer))

[Michel Dänzer]

Sven Goethel wrote:

>         - which kernel ? (I currently use 2.4.0-test5)

That should be fine, at least it works for me with test4 and test6 :)

>         - XF4.0.1 ?

Maybe. I've got it working using the DRI CVS trunk, but the differences
against X4.0.1 are minor.

>         - When and/or where can I get the working r128 linux kernel
>           sources for ppc - they seemed not to be included in the current
>           CVS tree.
>           I only get a LOCK_PREFIX unknown ...

Apply the patch I have posted to the linuxppc-dev list yesterday. I can send
it to you privately if you can't get it for some reason.


Michel


--
The computer revolution is over. The computers won.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC XServer))

[Michel Dänzer]

Kostas Gewrgiou wrote:

> > > [...] you could run the r128 driver without fbdev to get 16 bits, but
> > > the code to switch the framebuffer to do byteswapping is missing so the
> > > colors will be wron (easy to add though).
> >
> > Where and how?
>
>   Somewhere in R128ModeInit (or the functions that get called from it) will
> do fine i think.

I'll be trying in R128{Save,Restore}Crtc... , adding a config field to the
...Save... struct for the CONFIG_CNTL register. Does that make sense?


> About how now look at the following code from aty128fb that does the same
> thing.
>
>     config = aty_ld_le32(CONFIG_CNTL) & ~3;
> #if defined(__BIG_ENDIAN)
>     if (par->crtc.bpp >= 24)
>         config |= 2;    /* make aperture do 32 byte swapping */
>     else if (par->crtc.bpp > 8)
>         config |= 1;    /* make aperture do 16 byte swapping */
> #endif
>     aty_st_le32(CONFIG_CNTL, config);

Thanks, that code also caught my eye this morning on the train :)


Michel


--
Why drink & drive when you can smoke and fly???
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Geert Uytterhoeven]

On Mon, 7 Aug 2000, Josh Huber wrote:
> On Mon, Aug 07, 2000 at 09:08:01AM +0200, Michel D?nzer wrote:
> > Benjamin Herrenschmidt wrote:
> > > The Pismo allows that by scaling the LCD, but I don't think code for that
> > > is implemented in the XFree r128 driver (I didn't check lately).
> >
> > No it doesn't work, neither with aty128fb. Would that be hard to implement?
>
> If it's anything like the mach 64, it shouldn't be hard to implement
> at all.  you just have to program 3 registers.
>
> Speaking of this, I'm having trouble with the stretching setup for my
> wallstreet.  It works fine in console mode, but something in the X
> server is messing with the chip setup in a way to screw up the
> rendering.  After playing with it I was able to get proper output:
>
> console settings:
>     mclk = 99.844107 MHz
>     vclk = 44.702930 MHz
>     dsp_loop_latency = 10
>     dsp_precision = 5
>     dsp_xclks_per_row = 1143 => 17.859375
>     dsp_on = 69 => 34.500000
>     dsp_off = 1113 => 556.500000
>
> X (xf4.0.1) settings:
>     mclk = 99.844107 MHz
>     vclk = 44.702930 MHz
>     dsp_loop_latency = 10
>     dsp_precision = 4
>     dsp_xclks_per_row = 1143 => 8.929688
>     dsp_on = 103 => 25.750000
>     dsp_off = 1119 => 279.750000

Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
the DSP registers is part of the video mode initialization and thus is the
sole responsability of the frame buffer device, when running in `fbdev' mode.

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: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Josh Huber]

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

On Tue, Aug 08, 2000 at 02:35:19PM +0200, Geert Uytterhoeven wrote:
> 
> Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
> the DSP registers is part of the video mode initialization and thus is the
> sole responsability of the frame buffer device, when running in `fbdev' mode.

Yes.  The server shows the SAME behavior using the fbdev driver and
the ati driver.  Also, as a note, the 3.3.6 XF68FB_Dev server with ati
accel also does the same thing!   So there's some code that's getting
used by all three that is wrong?

I'm a little confused as to where the problem lies...

-- 
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Geert Uytterhoeven]

On Tue, 8 Aug 2000, Josh Huber wrote:
> On Tue, Aug 08, 2000 at 02:35:19PM +0200, Geert Uytterhoeven wrote:
> > Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
> > the DSP registers is part of the video mode initialization and thus is the
> > sole responsability of the frame buffer device, when running in `fbdev' mode.
>
> Yes.  The server shows the SAME behavior using the fbdev driver and
> the ati driver.  Also, as a note, the 3.3.6 XF68FB_Dev server with ati
> accel also does the same thing!   So there's some code that's getting
> used by all three that is wrong?
>
> I'm a little confused as to where the problem lies...

An X server does:

 1. video mode programming
 2. color map setting
 3. accel engine setup
 4. accel engine programming

A `hardware banging' X server does all 4 of them by banging the hardware.
An X-server in fbdev mode must use ioctl() for 1 and 2, and use hardware
banging for 3 and 4.

Playing with the DSP registers is definitely part of 1, so the X server must
not touch those registers when in fbdev mode. Probably there's some code to
change the DSP registers in the accel engine setup code in both 3.3.6 and 4.x.

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: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michael Schmitz]

> >
> > Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
> > the DSP registers is part of the video mode initialization and thus is the
> > sole responsability of the frame buffer device, when running in `fbdev' mode.
>
> Yes.  The server shows the SAME behavior using the fbdev driver and
> the ati driver.  Also, as a note, the 3.3.6 XF68FB_Dev server with ati
> accel also does the same thing!   So there's some code that's getting
> used by all three that is wrong?

Both the fbdev and ati driver use the fbdvhw functions to do mode init and
the like. So it seems the bug is in the kernel driver (sorry Geert).

	Michael


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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Geert Uytterhoeven]

On Tue, 8 Aug 2000, Michael Schmitz wrote:
> > > Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
> > > the DSP registers is part of the video mode initialization and thus is the
> > > sole responsability of the frame buffer device, when running in `fbdev' mode.
> >
> > Yes.  The server shows the SAME behavior using the fbdev driver and
> > the ati driver.  Also, as a note, the 3.3.6 XF68FB_Dev server with ati
> > accel also does the same thing!   So there's some code that's getting
> > used by all three that is wrong?
>
> Both the fbdev and ati driver use the fbdvhw functions to do mode init and
> the like. So it seems the bug is in the kernel driver (sorry Geert).

I don't see how it can be in the kernel driver, if running 3.3.6 XF68FB_Dev
changes the contents of the DSP registers.

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: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Michael Schmitz]

> > Both the fbdev and ati driver use the fbdvhw functions to do mode init and
> > the like. So it seems the bug is in the kernel driver (sorry Geert).
>
> I don't see how it can be in the kernel driver, if running 3.3.6 XF68FB_Dev
> changes the contents of the DSP registers.

Which doesn't use any fbdev IOCTLs to do mode init (via setting the var
screeninfo), I gather?

	Michael


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

Re: [Dri-devel] Re: Kind of success! (r128 on PPC (Re: LinuxPPC X Server))

[Geert Uytterhoeven]

On Wed, 9 Aug 2000, Michael Schmitz wrote:
> > > Both the fbdev and ati driver use the fbdvhw functions to do mode init and
> > > the like. So it seems the bug is in the kernel driver (sorry Geert).
> >
> > I don't see how it can be in the kernel driver, if running 3.3.6 XF68FB_Dev
> > changes the contents of the DSP registers.
>
> Which doesn't use any fbdev IOCTLs to do mode init (via setting the var
> screeninfo), I gather?

It's the _fbdev_ server, so it does use the ioctl()s.

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/