Re: LinuxPPC X Server

Re: LinuxPPC X Server

[Iain Sandoe]

n  Sun, Jul 30, 2000,  Steffen Haeuser wrote:
> Am 30-Jul-00 schrieb Iain Sandoe:
>>On the up side I built it yesterday (with Ani's rsync stuff in place of the
>>xfree86 directory).  It build without problem - now all I need is time to
>>test ;-)
>
>>At present I'm not able to host the binaries (and not enough experienced
>>with X to be sure of building the right collection :-)
>
>>On the down side it took **all** day to build on my 300M G3.
>
>>And yes, there have been reports of people trying it (one yesterday - said
>>it was quicker in some places & slower in others...)
>
> Did these sources you have compiled include the DRI Drivers ?

Don't know - I did a make "World" so I guess that should have built
everything?

This will be the first time I've tried XF directly (although my X86 box has
it) - so I'm very new to it.

> Do you know if the bug concerning VidModeExtension 640x480 Fullscreen is gone
> ? (I could send you a small test executable...).

I will mail you off list when I have had time to do a test.

> You told it took 1 day to do... so
> there were big problems/source code changes to do ? Or what caused this ?

No problems, no changes, it's just *BIG* :-)

Iain.

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

Re: LinuxPPC X Server

[Michel D nzer]

Iain Sandoe wrote:

> >>And yes, there have been reports of people trying it (one yesterday - said
> >>it was quicker in some places & slower in others...)

He didn't provide any numbers though. For all chipsets which have an
accelerated driver in X 4, it's almost certainly faster than anything else -
and also for the others it should be faster than X 3.3.x .


> > Did these sources you have compiled include the DRI Drivers ?
>
> Don't know - I did a make "World" so I guess that should have built everything?

See my remark at the end.


> > You told it took 1 day to do... so there were big problems/source code changes to do
> > ? Or what caused this ?
>
> No problems, no changes, it's just *BIG* :-)

Before building, you should have copied xc/config/cf/{xf86site,host}.def

Then edit the newly created host.def - you probably only want to build the
server and drivers, and choose the drivers you want.

For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is only
built on i386 by default.


Michel


--
#include <stdsig.h>

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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 30-Jul-00 schrieb Michel Dnzer:


Hi!

>Before building, you should have copied xc/config/cf/{xf86site,host}.def

>Then edit the newly created host.def - you probably only want to build the
>server and drivers, and choose the drivers you want.

>For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is
only
>built on i386 by default.

Did anybody build a DRI-Driver on PPC successfully yet ?

Steffen


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

Re: LinuxPPC X Server

[Daniel Jacobowitz]

On Sun, Jul 30, 2000 at 08:14:35PM +0200, Michel D?nzer wrote:
> Before building, you should have copied xc/config/cf/{xf86site,host}.def
>
> Then edit the newly created host.def - you probably only want to build the
> server and drivers, and choose the drivers you want.
>
> For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is only
> built on i386 by default.

DRI won't build on powerpc at present.  The first place it dies is in
the makefiles for libOSmesa, where $(SUBDIRS) becomes empty.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: LinuxPPC X Server

[Michel Dänzer]

Daniel Jacobowitz wrote:
>
> On Sun, Jul 30, 2000 at 08:14:35PM +0200, Michel D?nzer wrote:
> > Before building, you should have copied xc/config/cf/{xf86site,host}.def
> >
> > Then edit the newly created host.def - you probably only want to build the
> > server and drivers, and choose the drivers you want.
> >
> > For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is only
> > built on i386 by default.
>
> DRI won't build on powerpc at present.  The first place it dies is in
> the makefiles for libOSmesa, where $(SUBDIRS) becomes empty.

Which tree and version?

I was playing around with stock X 4.0.1 on the train about an hour ago, and
apart from the /dev entries missing (anyone has the majors/minors handy? :),
everything _seemed_ to at least load fine...

I'll report the definite result after more testing.


Michel


--
I don't suffer from stress. I'm a carrier.
______________________________________________________________________________
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: LinuxPPC X Server

[Daniel Jacobowitz]

On Mon, Jul 31, 2000 at 09:40:15AM +0200, Michel Dänzer wrote:
> Daniel Jacobowitz wrote:
> >
> > On Sun, Jul 30, 2000 at 08:14:35PM +0200, Michel D?nzer wrote:
> > > Before building, you should have copied xc/config/cf/{xf86site,host}.def
> > >
> > > Then edit the newly created host.def - you probably only want to build the
> > > server and drivers, and choose the drivers you want.
> > >
> > > For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is only
> > > built on i386 by default.
> >
> > DRI won't build on powerpc at present.  The first place it dies is in
> > the makefiles for libOSmesa, where $(SUBDIRS) becomes empty.
>
> Which tree and version?
>
> I was playing around with stock X 4.0.1 on the train about an hour ago, and
> apart from the /dev entries missing (anyone has the majors/minors handy? :),
> everything _seemed_ to at least load fine...
>
> I'll report the definite result after more testing.

Straight 4.0.1.  I turned on BuildXF86DRI in linux.cf in an attempt to
build libOSmesa, and failed.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: LinuxPPC X Server

[Michael Schmitz]

> > >>And yes, there have been reports of people trying it (one yesterday - said
> > >>it was quicker in some places & slower in others...)
>
> He didn't provide any numbers though. For all chipsets which have an
> accelerated driver in X 4, it's almost certainly faster than anything else -
> and also for the others it should be faster than X 3.3.x .

Talking about x11perf on Mach64? It's faster for scrolls and rectcopys but
as fast as the fbdev driver or slightly slower for other stuff. I can send
logs (at 32 bpp) to anyone that cares to analyze them. Switching back to
3.3.x is something I always wanted to do but never found time for, but
even the fbdev driver on 4.01 feels a lot faster than the 3.3.x one.

	Michael


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

Re: LinuxPPC X Server

[Martin Costabel]

Michael Schmitz wrote:
>
> > > >>And yes, there have been reports of people trying it (one yesterday - said
> > > >>it was quicker in some places & slower in others...)
> >
> > He didn't provide any numbers though. For all chipsets which have an
> > accelerated driver in X 4, it's almost certainly faster than anything else -
> > and also for the others it should be faster than X 3.3.x .
>
> Talking about x11perf on Mach64? It's faster for scrolls and rectcopys but
> as fast as the fbdev driver or slightly slower for other stuff. I can send
> logs (at 32 bpp) to anyone that cares to analyze them. Switching back to
> 3.3.x is something I always wanted to do but never found time for, but
> even the fbdev driver on 4.01 feels a lot faster than the 3.3.x one.

I installed Franz's XFree-4.0.1-0.36a RPMs, and with these I can run
either the new XFree68 server or the XF68_FBDev server from 3.3.6 or
Xpmac. In fact, I have all three of them running right now at the same
time on different VCs (well, Xpmac isn't really usable, because I don't
know how to talk it into using the new mouse stuff, but that's a
different story).

So I don't see any need to switch back to 3.3.x for anything except
possibly the server binary itself. All the rest, font server, libraries,
seem to be compatible.

And although I am only using the fbdev driver, it is definitely faster:
For x11perf -scroll500, I get (8 bit video on valkyriefb):

  36.5/sec for XFree-4.0.1
  13.0/sec for XF68_FBDev-3.3.6 (similarly for Xpmac, from memory)

So scrolling is nearly 3 times faster!

Two or three small annoying problems remain:

1) Clicking on a scroll arrow (in netscape, for example) for more than 1
or 2 seconds, sometimes even less, makes the window scroll all the way
to the end.

2) There are color palette problems on the 8 bit display. Probably the
defaults have changed for colors that cannot be allocated? Sometimes
this gives me black text on black background, for instance in "make
menuconfig" or in pinfo. These are unusable when some color hungry
program such as netscape is already running.

While these 2 problems only occur with the new XFree86 server and not
with XF68_FBDev, the following seems to come from the new libraries. To
verify this suspicion, I would have to revert to the XFree-3.3.6 RPMs.
It could also come from a number of other packages I upgraded recently.
Difficult to find out.

3) Mozilla-M16 (and M17_BRANCH) doesn't work any more. It starts
loading, and when called with an URL, gets to the first browser window.
Any further action gives "segmentation fault" or "illegal instruction"
or just silent death. When called without URL, it dies silently before
the first window comes up.

--
Martin

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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 30-Jul-00 schrieb Iain Sandoe:

Hi!

>Don't know - I did a make "World" so I guess that should have built
>everything?

How many fps do you get, if you run the "gears" demo of Mesa3D ? This is
a good test for if 3D HW Acceleration is present... if it is below 100,
then it is software... some other demos which are not in the Mesa3D Archive
for example "fire" (I could send you source code) is even better for the test.
On Software it usually does not even give *one frame*.

>I will mail you off list when I have had time to do a test.

Okay.

>> You told it took 1 day to do... so
>> there were big problems/source code changes to do ? Or what caused this ?

>No problems, no changes, it's just *BIG* :-)

Ah, so this was just plain compile time ? No complications or such ? Sounds
good... maybe I should try it... :)

Steffen


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

Re: LinuxPPC X Server

[Jack Howarth]

Kostas,
    So what will we end up when we build 4.0.1 using those patches you
provided today? Will we gain any dri acceleration on the r128 driver?
Or will we still need to apply additional patches for that. I am
still a tad confused about exactly how dependent the DRI code is in
4.0.1 on AGPgart. I am assuming if you set the AGPgart flag to NO
in host.def then DRI will be built without any code requiring AGPgart
to be available. Or am I misunderstanding the situation. I think
I will try building the dri modules tonight and see what happens in
the Mesa gears demo since that benchmarks framerate. Do you know what
additional lines have to be added into XF86Config to enable the DRI
modules? Thanks in advance.
                  Jack

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

Re: LinuxPPC X Server

[Kostas Gewrgiou]

On Wed, 2 Aug 2000, Jack Howarth wrote:

>
> Kostas,
>     So what will we end up when we build 4.0.1 using those patches you
> provided today? Will we gain any dri acceleration on the r128 driver?
> Or will we still need to apply additional patches for that. I am
> still a tad confused about exactly how dependent the DRI code is in
> 4.0.1 on AGPgart. I am assuming if you set the AGPgart flag to NO
> in host.def then DRI will be built without any code requiring AGPgart
> to be available. Or am I misunderstanding the situation. I think
> I will try building the dri modules tonight and see what happens in
> the Mesa gears demo since that benchmarks framerate. Do you know what
> additional lines have to be added into XF86Config to enable the DRI
> modules? Thanks in advance.
>                   Jack
>

You don't have to define AGPgart flag to NO, the r128 module builds
fine without any other changes, the only problem without the agpgart
module will be lower performance (this might have changed though
by now).

To get DRI working we need a few other changes as well, the R128_READ/WRITE
macros need to do byteswapping/eieio. Writes to the CCE ring buffer might
need byteswapping as well but i am not sure (i haven't read the r128 docs
yet).

The only required change in XF86Config is to load the dri module
and configure the permissions for the device.

Section "Module
...
  Load  "dri"
...
EndSection

Section "DRI"
  Mode 0666
EndSection


  Kostas


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

Re: LinuxPPC X Server

[Iain Sandoe]

>> > However, 300M G3, UW SCSI + 256 Mb RAM ==> 6.5-ish Hours (*all* day was
only
>> > a slight exaggeration :-).
>> >
>> > (OK, so I did a kernel build as well [30 mins] and had a screen saver
>> > running - but... )
>>
>> I'm guessing that your screen saver might have been using a bit much
>> CPU.  I built XF4 on my powerbook wallstreet 233 in a little under 2
>> hours, with no configuration file changes. (except for ProjectRoot).
>
> Similar here on a Lombard 400 MHz - 1.5 hours, with ProjectRoot on a NFS
> mount. Only 64 MB RAM, only config file change was not to build fonts.
>
> The screen saver must have been running at over 60% CPU :-)

Which is rather worrying (seti screensaver runs very nice-d)  and I wasn't
using the graphics output...

Ho Hum... :-)

Hey, I'll try it again (with the correct config.) sometime soon...

Iain.

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

Re: LinuxPPC X Server

[Benjamin Herrenschmidt]

>> >> - A likely timeframe for first 3D Drivers
>> >>   to be released, which optimally should
>> >>   not be more than 3 months from now
>>
>> >Again, what is not working for you?  What have you tried to get them
>> >working for you and how did it fair?
>>
>> I cannot try getting something to work what does not exist. And appearently
>> there are no GLX- or DRI-Drivers for ATI Rage (or any other hardware) yet.
>> I am talking about Hardware Accelerated Mesa3D here...
>
>Ok, you should say so (3D support for older video cards like ATI Rage) in
>your previous message then.  As you may know, DRI drivers already exist
>for mga, r128, tdfx, i810 in source form.
>

I'm working on a /dev/agpgart implementation for new machines. But DRI
should be already port-able using the PCI GART provided by most ATI
chipsets. Any volunteer ?

Ben.


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

Re: LinuxPPC X Server

[Michel Dänzer]

Benjamin Herrenschmidt wrote:

> I'm working on a /dev/agpgart implementation for new machines.

Great, I'd happily beta-test and/or help, will that be in your rsync-tree or
in 2.4?

> But DRI should be already port-able using the PCI GART provided by most ATI
> chipsets.

The latest r128 DRI driver should work without AGP GART, but AFAIK PCI GART
support is only planned yet - I assume and hope it should work anyway?

> Any volunteer ?

I'll have a try. (checking out the DRI CVS tree now :)


Michel


--
Man invented language to satisfy his deep need to complain.
______________________________________________________________________________
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: LinuxPPC X Server

[Michel Dänzer]

Benjamin Herrenschmidt wrote:
>
> >
> >Great, I'd happily beta-test and/or help, will that be in your rsync-tree
> > or in 2.4?
>
> It's far from finished yet. It will be in 2.4 bk tree once done

Cool, so it will be in our APUS 2.4 tree :)


> Also, I need to figure out why XF4 (Franz 4.0.1 RPMs) die with 2.4 on
> both my Pismo and my G4. It works fine on any 2.2 with the exact same
> overall setup. It dies late (after all driver initialize), with or
> without the r128 driver, with or without aty128fb in the kernel. Black
> screen and no answer to signals. I can kill it remotely (telnet) and I
> can get the screen back by launching Xpmac. I didn't yet manage to figure
> out what's wrong.

Strange, it works fine here running 2.4.0-test4 from linux-pmac-devel...


Michel


--
Man invented language to satisfy his deep need to complain.
______________________________________________________________________________
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: LinuxPPC X Server

[Michel Dänzer]

Benjamin Herrenschmidt wrote:

> >> >Great, I'd happily beta-test and/or help, will that be in your
> >> >rsync-tree or in 2.4?
> >>
> >> It's far from finished yet. It will be in 2.4 bk tree once done
> >
> >Cool, so it will be in our APUS 2.4 tree :)
>
> Well, I don't see what good Uni-North AGP bridge support can be to APUS
> machines, but if you think it's cool ...

I don't have a bitkeeper tree, but the APUS tree is based on it, so I can
build the agpgart stuff from there.


> >> Also, I need to figure out why XF4 (Franz 4.0.1 RPMs) die with 2.4 on
> >> both my Pismo and my G4.
> >
> >Strange, it works fine here running 2.4.0-test4 from linux-pmac-devel...
>
> I'll compare with this kernel. Also, which version of glibc do you have ?

book(~): dpkg -l|grep libc6
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone
ii  libc6-dev      2.1.3-10       GNU C Library: Development Libraries and Hea

> Did you compile XF4 yourself ? If yes, which gcc did you use ? (just in
> case...)

book(~): gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)

Compiled both X 4.0.1 (more or less stock AFAIR) and the kernel with that.


Michel


--
                               Reboot America.
______________________________________________________________________________
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: LinuxPPC X Server

[Geert Uytterhoeven]

On Tue, 1 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> Benjamin Herrenschmidt wrote:
> > >> >Great, I'd happily beta-test and/or help, will that be in your
> > >> >rsync-tree or in 2.4?
> > >>
> > >> It's far from finished yet. It will be in 2.4 bk tree once done
> > >
> > >Cool, so it will be in our APUS 2.4 tree :)
> >
> > Well, I don't see what good Uni-North AGP bridge support can be to APUS
> > machines, but if you think it's cool ...
>
> I don't have a bitkeeper tree, but the APUS tree is based on it, so I can
> build the agpgart stuff from there.

APUS doesn't even have AGP.

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: LinuxPPC X Server

[Michel Dänzer]

Geert Uytterhoeven wrote:
>
> > > >> >Great, I'd happily beta-test and/or help, will that be in your
> > > >> >rsync-tree or in 2.4?
> > > >>
> > > >> It's far from finished yet. It will be in 2.4 bk tree once done
> > > >
> > > >Cool, so it will be in our APUS 2.4 tree :)
> > >
> > > Well, I don't see what good Uni-North AGP bridge support can be to APUS
> > > machines, but if you think it's cool ...
> >
> > I don't have a bitkeeper tree, but the APUS tree is based on it, so I can
> > build the agpgart stuff from there.
>
> APUS doesn't even have AGP.

I know.

May I still build the agpgart module for my Pismo from the APUS 2.4 tree
(which happens to reside on the Pismo BTW ;) ? Please? :)


Michel


--
So many Christians, so few lions.
______________________________________________________________________________
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: LinuxPPC X Server

[Iain Sandoe]

On  Sun, Jul 30, 2000, Timothy A. Seufert wrote:
> At 5:56 PM +0100 7/30/00, Iain Sandoe wrote:
>
>>On the down side it took **all** day to build on my 300M G3.
>
> How much RAM do you have?  You might have been swapping a lot -- make
> World took maybe 1 to 1.5 hours (didn't time it, but I think that's
> about right) on my 500MHz G3 with 192MB RAM and a UW SCSI HD.

I think I may have made a configuration mistake (see Michel's mail).

However, 300M G3, UW SCSI + 256 Mb RAM ==> 6.5-ish Hours (*all* day was only
a slight exaggeration :-).

(OK, so I did a kernel build as well [30 mins] and had a screen saver
running - but... )

Iain.

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

Re: LinuxPPC X Server

[Josh Huber]

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

On Sun, Jul 30, 2000 at 10:24:19PM +0100, Iain Sandoe wrote:
> 
> I think I may have made a configuration mistake (see Michel's mail).

Hmm, that's probably not the reason. (see below)

> However, 300M G3, UW SCSI + 256 Mb RAM ==> 6.5-ish Hours (*all* day was only
> a slight exaggeration :-).
> 
> (OK, so I did a kernel build as well [30 mins] and had a screen saver
> running - but... )

I'm guessing that your screen saver might have been using a bit much
CPU.  I built XF4 on my powerbook wallstreet 233 in a little under 2
hours, with no configuration file changes. (except for ProjectRoot).

Definately no UW SCSI and only 160M of ram.  You should be able to
build in 1.5 hours I would think, with that setup. :)

ttyl,

-- 
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: LinuxPPC X Server

[Michael Schmitz]

> > However, 300M G3, UW SCSI + 256 Mb RAM ==> 6.5-ish Hours (*all* day was only
> > a slight exaggeration :-).
> >
> > (OK, so I did a kernel build as well [30 mins] and had a screen saver
> > running - but... )
>
> I'm guessing that your screen saver might have been using a bit much
> CPU.  I built XF4 on my powerbook wallstreet 233 in a little under 2
> hours, with no configuration file changes. (except for ProjectRoot).

Similar here on a Lombard 400 MHz - 1.5 hours, with ProjectRoot on a NFS
mount. Only 64 MB RAM, only config file change was not to build fonts.

The screen saver must have been running at over 60% CPU :-)

	Michael


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

Re: LinuxPPC X Server

[Iain Sandoe]

Thanks Michel,

I *did* say I saw very new to this...

on  Sun, Jul 30, 2000, Michel D‰nzer wrote:
> Iain Sandoe wrote:
[...]

> Before building, you should have copied xc/config/cf/{xf86site,host}.def
>
> Then edit the newly created host.def - you probably only want to build the
> server and drivers, and choose the drivers you want.

Oh-oh.

This was a step missing from the instructions :-(

Maybe I complied a lot more than necessary (and hence the time)...

Would I need to build all the apps once (so that they are compatible?).

After that, I suppose, I just rebuild the driver when the rsync changes...

> For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is only
> built on i386 by default.

Do I also need to enable different support in the kernel?
(e.g. /dev/agpart support ?)
(there's been a fair amount about different fb stuff flying around...)
(I have ATI{mach64,r128}/IMSTT support enabled by default - since these are
the cards I have).

Iain.

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

Re: LinuxPPC X Server

[Michel Dänzer]

Iain Sandoe wrote:

> > Before building, you should have copied xc/config/cf/{xf86site,host}.def
> >
> > Then edit the newly created host.def - you probably only want to build the
> > server and drivers, and choose the drivers you want.
>
> Oh-oh.
>
> This was a step missing from the instructions :-(
>
> Maybe I complied a lot more than necessary (and hence the time)...

Probably.


> Would I need to build all the apps once (so that they are compatible?).

Not absolutely. Servers and clients should be compatible at any version each
(apart from a few issues, of course ;)


> After that, I suppose, I just rebuild the driver when the rsync changes...

Yep, make -C xc/programs/Xserver should do. (And copying the modules to the
ModulePath again)


> > For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is
> > only built on i386 by default.
>
> Do I also need to enable different support in the kernel?
> (e.g. /dev/agpart support ?)

That would be good, but AFAIK there's no such thing for our hardware yet.

You'll have to go to
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
Makefile.linux (won't build out of the box - I've added '#include
<asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
i386 assembly to just call mb() - anyone knows if this makes sense?) and then
modprobe r128.o


> (I have ATI{mach64,r128}/IMSTT support enabled by default - since these are
> the cards I have).

Only the r128 is even theoretically supported by DRI ATM.


Michel


--
Pauli's exclusive, Heisenberg's uncertain, and Schroedinger just waves.
______________________________________________________________________________
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: LinuxPPC X Server

[Steffen Haeuser]

Am 31-Jul-00 schrieb Michel Dänzer:

>Iain Sandoe wrote:

Hi!

>> > For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is
>> > only built on i386 by default.
>>
>> Do I also need to enable different support in the kernel?
>> (e.g. /dev/agpart support ?)

>That would be good, but AFAIK there's no such thing for our hardware yet.

Exactly this is AFAIK currently the problem as to 3D Hardware support...
the /dev/agpart support... a solution might be to use GLX instead of
DRI ... after all since 4.0 Beta X Server Driver there *is* support for GLX
in the LinuxPPC X Server...

>You'll have to go to
>xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
>Makefile.linux (won't build out of the box - I've added '#include
><asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
>i386 assembly to just call mb() - anyone knows if this makes sense?) and then
>modprobe r128.o

Hmmm... what sort of ASM is this ? Is this the only reason why agpart is not
supported on Mac yet, some lines of ASM ? (Well, AFAIK it is not even
confirmed
if this AGPart thing works with PCI, but AFAIK it was said that it "should").

>> (I have ATI{mach64,r128}/IMSTT support enabled by default - since these are
>> the cards I have).

>Only the r128 is even theoretically supported by DRI ATM.

I think a lot people confuse 2D Hardware Accelerated with 3D Hardware
Accelerated
Support. There *is* already 2D Hardware Acceleration for LinuxPPC, but not
3D...

The most clever thing probably would be to do a GLX Driver (which does not
require
this AGPart thing...). Of course all also depends if Chipset information is
available.
To do such a driver should be possible in 3-4 weeks at most... I know of what
I am speaking
as before Hyperion existed people of our company did the 3D Drivers for the
Amiga
3D Boards, and I know how long THEY took for a 3D Driver... (and before
someone
asks: No, these people are 100% busy with game coding now... no time for
drivers...).

Steffen

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

Re: LinuxPPC X Server

[Michel Dänzer]

Steffen Haeuser wrote:

> >> Do I also need to enable different support in the kernel?
> >> (e.g. /dev/agpart support ?)
>
> >That would be good, but AFAIK there's no such thing for our hardware yet.
>
> Exactly this is AFAIK currently the problem as to 3D Hardware support...
> the /dev/agpart support...

agpgart was required _for r128 DRI_ until some time ago. It's possible that
it's still needed by the driver in X 4.0.1 but definitely not in the latest
DRI CVS.

> a solution might be to use GLX instead of DRI ... after all since 4.0 Beta X
> Server Driver there *is* support for GLX in the LinuxPPC X Server...

Yep, and DRI adds hardware acceleration to it.


> >You'll have to go to
> >xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
> >Makefile.linux (won't build out of the box - I've added '#include
> ><asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
> >i386 assembly to just call mb() - anyone knows if this makes sense?) and
> > then modprobe r128.o
>
> Hmmm... what sort of ASM is this ?

It's for flushing write combining buffers AFAIR, thus I thought an mb() should
do on PPC.

> Is this the only reason why agpart is not supported on Mac yet, some lines
> of ASM ?

This is not about agpgart at all but about the DRM (direct rendering manager,
the kernel part of DRI) kernel module.

> (Well, AFAIK it is not even confirmed if this AGPart thing works with PCI,
> but AFAIK it was said that it "should").

PCI is not AGP, thus I don't think agpgart can work on PCI. There's also PCI
GART, but there isn't PPC support for it either yet.


> The most clever thing probably would be to do a GLX Driver (which does not
> require this AGPart thing...). Of course all also depends if Chipset
> information is available.
> To do such a driver should be possible in 3-4 weeks at most... I know of
> what I am speaking as before Hyperion existed people of our company did the
> 3D Drivers for the Amiga 3D Boards, and I know how long THEY took for a 3D
> Driver... (and before someone asks: No, these people are 100% busy with game
> coding now... no time for drivers...).

I doubt it would be as easy on Linux - much more complexity to deal with than
on AmigaOS :)


Michel


--
Hark! What rock through yonder window breaks?
______________________________________________________________________________
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: LinuxPPC X Server

[Steffen Haeuser]

Am 31-Jul-00 schrieb Michel Dänzer:

>Steffen Haeuser wrote:

Hi!

>agpgart was required _for r128 DRI_ until some time ago. It's possible that
>it's still needed by the driver in X 4.0.1 but definitely not in the latest
>DRI CVS.

That is really good news :) If anyone had the chance to try it out, please
tell so...
if this works, we might even take some of you guys into the Sin Beta Tester
programs,
if I remember right, we still need a handful of testers (but I have to check
with
the guy doing the Betatester issues in our company...).

>It's for flushing write combining buffers AFAIR, thus I thought an mb()
should
>do on PPC.

Yeah, think you should be right here... :)

>> (Well, AFAIK it is not even confirmed if this AGPart thing works with PCI,
>> but AFAIK it was said that it "should").

>PCI is not AGP, thus I don't think agpgart can work on PCI. There's also PCI
>GART, but there isn't PPC support for it either yet.

Well, the author of AGPart was cited that he "thinks it should work on PCI
too".
I cannot comment further on it. But if DRI does not require it any longer,
anyways,
seems this is no longer an issue :)

>I doubt it would be as easy on Linux - much more complexity to deal with than
>on AmigaOS :)

Driver Coding normally has not that much to do with the OS... :)
The main work is to find out how this Chip works, and then duplicate the
functionality
of an API by using the Chip Registers (and some of those sometimes do things
in a
*really cruel way*... some years ago I had to do some stuff on the old Virge
chip...
this was nasty...) The difficult is usually the register setup... not the
interface
to the OS...

Steffen


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

Re: LinuxPPC X Server

[Michel Dänzer]

Steffen Haeuser wrote:

> >agpgart was required _for r128 DRI_ until some time ago. It's possible that
> >it's still needed by the driver in X 4.0.1 but definitely not in the latest
> >DRI CVS.
>
> That is really good news :) If anyone had the chance to try it out, please
> tell so...

Hold on, I will :)


> if this works, we might even take some of you guys into the Sin Beta Tester
> programs, if I remember right, we still need a handful of testers (but I
> have to check with the guy doing the Betatester issues in our company...).

I for one wouldn't say no...


> Driver Coding normally has not that much to do with the OS... :)
> The main work is to find out how this Chip works, and then duplicate the
> functionality of an API by using the Chip Registers (and some of those
> sometimes do things in a *really cruel way*... some years ago I had to do
> some stuff on the old Virge chip...
> this was nasty...) The difficult is usually the register setup... not the
> interface to the OS...

AFAIK the specs for Rage128 aren't publicly available, but there's working
code in DRI - I'm convinced it will be far more easier to get it working than
write something new from scratch.


Michel


--
UNIX is like Sex:
If you don't know it, you don't miss it. But if you know it, you'll need it.
______________________________________________________________________________
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: LinuxPPC X Server

[Steffen Haeuser]

Am 31-Jul-00 schrieb Michel Dänzer:

>Steffen Haeuser wrote:

Hi!

>> That is really good news :) If anyone had the chance to try it out, please
>> tell so...

>Hold on, I will :)

Great :)

>> if this works, we might even take some of you guys into the Sin Beta Tester
>> programs, if I remember right, we still need a handful of testers (but I
>> have to check with the guy doing the Betatester issues in our company...).

>I for one wouldn't say no...

Hehehe, who would...

>AFAIK the specs for Rage128 aren't publicly available, but there's working
>code in DRI - I'm convinced it will be far more easier to get it working than
>write something new from scratch.

Okay, that's a point...

Steffen


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

Re: LinuxPPC X Server

[Kostas Gewrgiou]

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

>
> Steffen Haeuser wrote:
>
> > >> Do I also need to enable different support in the kernel?
> > >> (e.g. /dev/agpart support ?)
> >
> > >That would be good, but AFAIK there's no such thing for our hardware yet.
> >
> > Exactly this is AFAIK currently the problem as to 3D Hardware support...
> > the /dev/agpart support...
>
> agpgart was required _for r128 DRI_ until some time ago. It's possible that
> it's still needed by the driver in X 4.0.1 but definitely not in the latest
> DRI CVS.
>

 If i remember corectly 4.0.1 doesn't need agpgart but i fear that 3d
performance is far worst without it.

> > >You'll have to go to
> > >xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
> > >Makefile.linux (won't build out of the box - I've added '#include
> > ><asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
> > >i386 assembly to just call mb() - anyone knows if this makes sense?) and
> > > then modprobe r128.o
> >
> > Hmmm... what sort of ASM is this ?
>
> It's for flushing write combining buffers AFAIR, thus I thought an mb() should
> do on PPC.
>

The mb() should be enough in r128_dma.c (we might not need it at all though
but it shouldn't hurt). The R128_WRITE/R128_READ macros in r128_drv.h will
need to do byteswapping also i imagine.

The writes to the CCE ring buffer might be a problem also you might need
to do different swaps depending on where the buffer lives (host memory or
in the framebuffer) since the framebuffer writes get swapped depending on
the current depth. (voodoo3 has this problem)

The drm modules need some asm code as well, look at my patches in
dri.sourceforge.net (patch_id 100488,100568) the code is almost a copy
from the glibc sources (i know next to nothing about ppc asm) but they
work well with my voodoo3.

Also note that the DRI drivers don't get build by default in PPC
you have to #define BuildXF86DRI YES in xf config files *AND*
patch xc/lib/GL/mesa/src/drv/Imakefile to enable the dri drivers
to build under ppc.

Unfortunately i don't have an r128 card so i can't do anything here :(

   Kostas Gewrgiou


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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 01-Aug-00 schrieb Kostas Gewrgiou:

Hi!

> If i remember corectly 4.0.1 doesn't need agpgart but i fear that 3d
>performance is far worst without it.

Surely faster than *no* 3D Acceleration :)

Steffen


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

Re: LinuxPPC X Server

[Daniel Jacobowitz]

On Tue, Aug 01, 2000 at 03:54:37PM +0300, Kostas Gewrgiou wrote:
> The mb() should be enough in r128_dma.c (we might not need it at all though
> but it shouldn't hurt). The R128_WRITE/R128_READ macros in r128_drv.h will
> need to do byteswapping also i imagine.
>
> The writes to the CCE ring buffer might be a problem also you might need
> to do different swaps depending on where the buffer lives (host memory or
> in the framebuffer) since the framebuffer writes get swapped depending on
> the current depth. (voodoo3 has this problem)
>
> The drm modules need some asm code as well, look at my patches in
> dri.sourceforge.net (patch_id 100488,100568) the code is almost a copy
> from the glibc sources (i know next to nothing about ppc asm) but they
> work well with my voodoo3.
>
> Also note that the DRI drivers don't get build by default in PPC
> you have to #define BuildXF86DRI YES in xf config files *AND*
> patch xc/lib/GL/mesa/src/drv/Imakefile to enable the dri drivers
> to build under ppc.
>
> Unfortunately i don't have an r128 card so i can't do anything here :(

What sort of patch do we need to that Imakefile?  I couldn't figure out
what to do.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: LinuxPPC X Server

[Michel Dänzer]

Daniel Jacobowitz wrote:

> > Also note that the DRI drivers don't get build by default in PPC
> > you have to #define BuildXF86DRI YES in xf config files *AND*
> > patch xc/lib/GL/mesa/src/drv/Imakefile to enable the dri drivers
> > to build under ppc.
> >
> > Unfortunately i don't have an r128 card so i can't do anything here :(
>
> What sort of patch do we need to that Imakefile?  I couldn't figure out
> what to do.

What I did is I went directly to xc/lib/GL/mesa/src/drv/r128, created the
Makefile manually (go to any other directory and do make Makefile to get the
idea) and then did make depend includes all . That got me
modules/dri/r128_dri.so .


> I turned on BuildXF86DRI in linux.cf in an attempt to build libOSmesa, and
> failed.

Is libOSmesa needed for DRI?


Michel


--
Death is just Nature's way of saying, "Hey! You're not alive anymore!"
______________________________________________________________________________
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: LinuxPPC X Server

[Kostas Gewrgiou]

On Tue, 1 Aug 2000, Daniel Jacobowitz wrote:

>
> On Tue, Aug 01, 2000 at 03:54:37PM +0300, Kostas Gewrgiou wrote:
> > The mb() should be enough in r128_dma.c (we might not need it at all though
> > but it shouldn't hurt). The R128_WRITE/R128_READ macros in r128_drv.h will
> > need to do byteswapping also i imagine.
> >
> > The writes to the CCE ring buffer might be a problem also you might need
> > to do different swaps depending on where the buffer lives (host memory or
> > in the framebuffer) since the framebuffer writes get swapped depending on
> > the current depth. (voodoo3 has this problem)
> >
> > The drm modules need some asm code as well, look at my patches in
> > dri.sourceforge.net (patch_id 100488,100568) the code is almost a copy
> > from the glibc sources (i know next to nothing about ppc asm) but they
> > work well with my voodoo3.
> >
> > Also note that the DRI drivers don't get build by default in PPC
> > you have to #define BuildXF86DRI YES in xf config files *AND*
> > patch xc/lib/GL/mesa/src/drv/Imakefile to enable the dri drivers
> > to build under ppc.
> >
> > Unfortunately i don't have an r128 card so i can't do anything here :(
>
> What sort of patch do we need to that Imakefile?  I couldn't figure out
> what to do.
>

To enable the dri drivers you'll need the following patch:

--- xc/lib/GL/mesa/src/drv/Imakefile-orig       Tue Jul 18 14:32:34 2000
+++ xc/lib/GL/mesa/src/drv/Imakefile    Tue Jul 18 14:33:41 2000
@@ -54,6 +54,14 @@
 SUBDIRS += common
 SUBDIRS += mga
 SUBDIRS += r128
+#elif defined(PpcArchitecture)
+SUBDIRS += gamma
+#if HasGlide3
+SUBDIRS += tdfx
+#endif
+SUBDIRS += common
+SUBDIRS += mga
+SUBDIRS += r128
 #elif defined(SparcArchitecture)
 SUBDIRS += ffb
 #endif

For the build problems because of the empty subdirs in xc/lib/GL/mesa/src
the following will do, its not actually correct but i am not sure how to fix
it.

--- xc/lib/GL/mesa/src/Imakefile-orig   Tue Jul 18 18:29:32 2000
+++ xc/lib/GL/mesa/src/Imakefile        Wed Aug  2 21:13:47 2000
@@ -389,7 +389,7 @@
 #define IHaveSubdirs
 #define PassCDebugFlags

-SUBDIRS = $(MESASUBDIRS) $(ASMSUBDIRS)
+SUBDIRS = $(MESASUBDIRS) $(ASMSUBDIRS) drv

 MakeSubdirs($(SUBDIRS))
 DependSubdirs($(SUBDIRS))


 Kostas


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

Re: LinuxPPC X Server

[Iain Sandoe]

On  Sun, Jul 30, 2000, Steffen Haeuser wrote:
> Am 30-Jul-00 schrieb Takashi Oe:
>
> Hi!
>
>>> Well, if it is not fixed it most likely WILL hold up...
>
>>What's wrong with XF68_FBDev?
>
> Hmmm... I was told to use the ATI thing... did not think this was only a thing
> related to the ATI Driver... but maybe I should try this.
>
>>> Hmmm... I was told that no DRI Drivers would exist even for r128 ... can
> you
>>> point me to a place where I can get this ? And if they exist in Source
> form,
>>> someone has them already in Binary form maybe ?
>
>>www.xfree86.org
>>4.0.1 has them.
>
> Hmmm... I looked on the site, but could only see versions for x86 and Alpha
> there,
> not for PPC... has anybody TRIED this stuff (source) on PPC yet ?
>
> I really do not have the time to try around with untried stuff...
>
> *Has* anybody tried compiling this 4.0.1 version on PPC? Does it work ? Are
> there
> any problems ? Is a Binary Version available anywhere ?

Look back through archive from this list for a post from Ani Joshi - it was
an [ANN].

I saw, also that there are some binaries (don't remember who, sorry) but
these do not include the newest drivers.

On the up side I built it yesterday (with Ani's rsync stuff in place of the
xfree86 directory).  It build without problem - now all I need is time to
test ;-)

At present I'm not able to host the binaries (and not enough experienced
with X to be sure of building the right collection :-)

On the down side it took **all** day to build on my 300M G3.

And yes, there have been reports of people trying it (one yesterday - said
it was quicker in some places & slower in others...)

Iain.

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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 30-Jul-00 schrieb Iain Sandoe:

Hi!

>On the up side I built it yesterday (with Ani's rsync stuff in place of the
>xfree86 directory).  It build without problem - now all I need is time to
>test ;-)

>At present I'm not able to host the binaries (and not enough experienced
>with X to be sure of building the right collection :-)

>On the down side it took **all** day to build on my 300M G3.

>And yes, there have been reports of people trying it (one yesterday - said
>it was quicker in some places & slower in others...)

Did these sources you have compiled include the DRI Drivers ?

Do you know if the bug concerning VidModeExtension 640x480 Fullscreen is gone
? (I
could send you a small test executable...). You told it took 1 day to do... so
there were big problems/source code changes to do ? Or what caused this ?

Steffen


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

Re: LinuxPPC X Server

[Timothy A. Seufert]

At 5:56 PM +0100 7/30/00, Iain Sandoe wrote:

>On the down side it took **all** day to build on my 300M G3.

How much RAM do you have?  You might have been swapping a lot -- make
World took maybe 1 to 1.5 hours (didn't time it, but I think that's
about right) on my 500MHz G3 with 192MB RAM and a UW SCSI HD.

   Tim Seufert

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

LinuxPPC X Server

[Steffen Haeuser]

Hi!

Again me concerning the X Server...

I had yesteday a "critical" discussion concerning the LinuxPPC Version of Sin.
It ended in the question "Do we want to delay the release of the Linux-x86
version because of the LinuxPPC version ?" All present people agreed with "No"
(including myselves). At the end I was asked - which I can of course not
answer, so I am asking for it - "At what *likely* timeframe would be the
problems in the LinuxPPC X Server being fixed, at least as much problems
fixed, that Sin it at least USABLE on LinuxPPC?"

We are not yet completely finished with the coding of Sin, but we are VERY
close to finishing it. And on that meeting was decided "no delaying of the
release". Of course even if Sin for LinuxPPC falls through there is still the
option to release Shogo or other future Linux titles of us for LinuxPPC also.
But I would like to release also Sin for LinuxPPC, as it is the project I am
working on it, and I am the biggest promotor of LinuxPPC in our company...

It might still happen... but what would really help me in my argumentation in
the company to put the LinuxPPC executable "on" would be:

- A bugfix so that Fullscreen 640x480
  works
- A likely timeframe for first 3D Drivers
  to be released, which optimally should
  not be more than 3 months from now

When is the next Beta for the X Server likely to happen, BTW ?

Knowing a likely timeframe would help my argumentation a lot... especially if
that timeframe is not TOO far away in the future...

Steffen


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

Re: LinuxPPC X Server

[Takashi Oe]

On Sat, 29 Jul 2000, Steffen Haeuser wrote:

> - A bugfix so that Fullscreen 640x480
>   works

What bug?  What is not working for you?  On what hardware?  For both
hardware I own (control and matrox), it is working just fine.

> - A likely timeframe for first 3D Drivers
>   to be released, which optimally should
>   not be more than 3 months from now

Again, what is not working for you?  What have you tried to get them
working for you and how did it fair?


Takashi Oe


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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 29-Jul-00 schrieb Takashi Oe:

>On Sat, 29 Jul 2000, Steffen Haeuser wrote:

Hi!

>> - A bugfix so that Fullscreen 640x480
>>   works

>What bug?  What is not working for you?  On what hardware?  For both
>hardware I own (control and matrox), it is working just fine.

If I use VidModeExtension at first modes which are entered in XF86Config
are entered as 640x481 (but this is of course a minor problem and can be
workarounded). The big problem is that the Screen is totally messed up, looks
to me as if the Bytes_Per_Line are not correct. With 1024x768 it works
correct, but with no other resolutions (and 1024x768 is too slow for the
software renderer of the game, I need 640x480). The Hardware is a
"Blue/White" G3 Mac 1st Revision with (naturally) ATI Rage Graphics
Hardware. I am using the ATI Rage Driver.

>> - A likely timeframe for first 3D Drivers
>>   to be released, which optimally should
>>   not be more than 3 months from now

>Again, what is not working for you?  What have you tried to get them
>working for you and how did it fair?

I cannot try getting something to work what does not exist. And appearently
there are no GLX- or DRI-Drivers for ATI Rage (or any other hardware) yet.
I am talking about Hardware Accelerated Mesa3D here...

Steffen


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

Re: LinuxPPC X Server

[Takashi Oe]

On Sun, 30 Jul 2000, Steffen Haeuser wrote:

> If I use VidModeExtension at first modes which are entered in XF86Config
> are entered as 640x481 (but this is of course a minor problem and can be
> workarounded). The big problem is that the Screen is totally messed up, looks
> to me as if the Bytes_Per_Line are not correct. With 1024x768 it works
> correct, but with no other resolutions (and 1024x768 is too slow for the
> software renderer of the game, I need 640x480). The Hardware is a
> "Blue/White" G3 Mac 1st Revision with (naturally) ATI Rage Graphics
> Hardware. I am using the ATI Rage Driver.

As I said, it works on matrox and control, your problem is specific to ati
support on XF4 (I presume).  Use XF68_FBDev or go bug Ani Joshi or have a
look at the source yourself.  You may be busy at doing your stuff, but
someone with the hardware and interest like you needs to look at this kind
of things.  I hardly think this is a major bug which should hold up a
release of an user app.

> >> - A likely timeframe for first 3D Drivers
> >>   to be released, which optimally should
> >>   not be more than 3 months from now
>
> >Again, what is not working for you?  What have you tried to get them
> >working for you and how did it fair?
>
> I cannot try getting something to work what does not exist. And appearently
> there are no GLX- or DRI-Drivers for ATI Rage (or any other hardware) yet.
> I am talking about Hardware Accelerated Mesa3D here...

Ok, you should say so (3D support for older video cards like ATI Rage) in
your previous message then.  As you may know, DRI drivers already exist
for mga, r128, tdfx, i810 in source form.


Takashi Oe


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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 30-Jul-00 schrieb Takashi Oe:

>On Sun, 30 Jul 2000, Steffen Haeuser wrote:

Hi!

>As I said, it works on matrox and control, your problem is specific to ati

Well, ATI is the hardware you get when you buy a Mac today. So it is the
most important thing.

>support on XF4 (I presume).  Use XF68_FBDev or go bug Ani Joshi or have a
>look at the source yourself.  You may be busy at doing your stuff, but

I was told it is a known problem. (No, I do not have the time to look at it
myselves).

>someone with the hardware and interest like you needs to look at this kind
>of things.  I hardly think this is a major bug which should hold up a
>release of an user app.

Well, if it is not fixed it most likely WILL hold up...

>Ok, you should say so (3D support for older video cards like ATI Rage) in

I meant ATI Rage 128 of course :) It is just my interest about 3D support for
the Boards you will get if you buy a G3 or G4 Mac today (which will be
ATI Rage 128 or ATI Rage Pro, depending on system).

>your previous message then.  As you may know, DRI drivers already exist
>for mga, r128, tdfx, i810 in source form.

Hmmm... I was told that no DRI Drivers would exist even for r128 ... can you
point me to a place where I can get this ? And if they exist in Source form,
someone has them already in Binary form maybe ?

Steffen


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

Re: LinuxPPC X Server

[Takashi Oe]

On Sun, 30 Jul 2000, Steffen Haeuser wrote:

> >support on XF4 (I presume).  Use XF68_FBDev or go bug Ani Joshi or have a
                                ^^^^^^^^^^^^^^
[...]
>                                   (No, I do not have the time to look at it
> myselves).

That's too bad.  I bet this problem of yours won't take you more than a
few hours to spot it; that is, if it's not fixed already.

> >someone with the hardware and interest like you needs to look at this kind
> >of things.  I hardly think this is a major bug which should hold up a
> >release of an user app.
>
> Well, if it is not fixed it most likely WILL hold up...

What's wrong with XF68_FBDev?

>
> >Ok, you should say so (3D support for older video cards like ATI Rage) in
>
> I meant ATI Rage 128 of course :) It is just my interest about 3D support for
> the Boards you will get if you buy a G3 or G4 Mac today (which will be
> ATI Rage 128 or ATI Rage Pro, depending on system).
>
> >your previous message then.  As you may know, DRI drivers already exist
> >for mga, r128, tdfx, i810 in source form.
>
> Hmmm... I was told that no DRI Drivers would exist even for r128 ... can you
> point me to a place where I can get this ? And if they exist in Source form,
> someone has them already in Binary form maybe ?

www.xfree86.org
4.0.1 has them.


Takashi Oe


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

Re: LinuxPPC X Server

[Steffen Haeuser]

Am 30-Jul-00 schrieb Takashi Oe:

Hi!

>> Well, if it is not fixed it most likely WILL hold up...

>What's wrong with XF68_FBDev?

Hmmm... I was told to use the ATI thing... did not think this was only a thing
related to the ATI Driver... but maybe I should try this.

>> Hmmm... I was told that no DRI Drivers would exist even for r128 ... can
you
>> point me to a place where I can get this ? And if they exist in Source
form,
>> someone has them already in Binary form maybe ?

>www.xfree86.org
>4.0.1 has them.

Hmmm... I looked on the site, but could only see versions for x86 and Alpha
there,
not for PPC... has anybody TRIED this stuff (source) on PPC yet ?

I really do not have the time to try around with untried stuff...

*Has* anybody tried compiling this 4.0.1 version on PPC? Does it work ? Are
there
any problems ? Is a Binary Version available anywhere ?

Steffen


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