From: R Shapiro <hidden> Date: 2000-09-23 12:52:51
[I'm posting to dev since xf 4 support for linuxppc still seems to be
in the development stage]
Subject says it all, really. I can't get the xf 4.0.x driver to work
either on a rev. a beige G3 with rage II or a rev. b beige G3 with
rage pro. Should it be working, or am I wasting my time trying? Fwiw
the r128 driver works great on my G4....
Specifics: with the ati driver selected, xf throws away my mode def,
since it thinks (incorrectly) that there isn't enough vram, and then
quits since it can't find any valid modes. In both cases I'm running
4.0.1 from Franz Sirl's linuxppc page. I also tried 4.0.0 from the
Howarth page and got exactly the same results. I haven't tried
compiling xf myself but I'm perfectly willing to do so if that's
likely to help (eg if there are some known ati patches missing from
the Sirl rpms).
The rev. a machine is running 2.2.15pre3 from the 2000 cd, booted via
BootX with "no video driver" checked. The rev. b machine is running a
2.2.16 kernel compiled from kernel.org sources, booted directly from
OF. Both are started with kernel args video=atyfb:vmode:20,cmode:16.
I can run xf 4.0.x using the fbdev driver, more or less, with an
otherwise identical XF86Config, though xf with fbdev is noticably
slower than Xpmac.rev10. Also the screen is oddly "wrapped" on the
rage II machine with the fbdev driver: I can see the full screen but
the virtual edge starts about 75% in, instead of matching the physical
edge, and then wraps around. I don't see this artifact on the rage
pro G3.
Eventually I want to get multiple monitors going. I already have what
I think is a valid config file for it, but I'm guessing I'll never be
able to do it with fbdev.
A search of the lists on this topic suggested only that there were
some known issues with the ati driver some time ago, but I couldn't
find anything like a definitive answer specific to the beige G3s.
If you have any suggestions at all, please cc: me directly -- I'll see
it more quickly that way.
Thanks -
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-23 15:00:59
R Shapiro schrieb:
Specifics: with the ati driver selected, xf throws away my mode def,
since it thinks (incorrectly) that there isn't enough vram,
Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?
and then quits since it can't find any valid modes. In both cases I'm
running 4.0.1 from Franz Sirl's linuxppc page.
While we're at it, can you please send me the URL of those?
I also tried 4.0.0 from the Howarth page and got exactly the same results.
I think they're too old to work with Mach based ATI chips.
I haven't tried compiling xf myself but I'm perfectly willing to do so if
that's likely to help (eg if there are some known ati patches missing from
the Sirl rpms).
I thought they contained the necessary stuff from Ani Joshi's rsync tree. If
you try to build yourself, you absolutely need that.
The rev. a machine is running 2.2.15pre3 from the 2000 cd, booted via
BootX with "no video driver" checked.
I don't think this can work with the ati driver, it needs atyfb.
The rev. b machine is running a 2.2.16 kernel compiled from kernel.org
sources, booted directly from OF. Both are started with kernel args
video=atyfb:vmode:20,cmode:16.
I can run xf 4.0.x using the fbdev driver, more or less, with an
otherwise identical XF86Config, though xf with fbdev is noticably
slower than Xpmac.rev10.
No big surprise as the fbdev driver doesn't have any hardware acceleration.
Also the screen is oddly "wrapped" on the rage II machine with the fbdev
driver: I can see the full screen but the virtual edge starts about 75% in,
instead of matching the physical edge, and then wraps around. I don't see
this artifact on the rage pro G3.
This is a known problem, which is also kind of fixed in Ani's tree AFAIK. I'm
currently working with Geert Uytterheuven to get the definite fix.
Eventually I want to get multiple monitors going. I already have what
I think is a valid config file for it, but I'm guessing I'll never be
able to do it with fbdev.
That should work if you have multiple framebuffer devices. Use
Option "fbdev" "/dev/fb1"
for the second one etc.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-23 15:32:21
Michel Dänzer writes:
> > Specifics: with the ati driver selected, xf throws away my mode def,
> > since it thinks (incorrectly) that there isn't enough vram,
>
> Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?
The xf probe says 2MB, but in fact I have 4MB. The dmesg line says:
atyfb: 3D RAGE PRO (PQFP, PCI) [0x4750 rev 0x7c] 4M SGRAM, 14.31818
MHz XTAL, 230 MHz PLL, 75 Mhz MCLK
I tried both UseFBDev on and off. It didn't seem to make any
difference. Btw, which is correct setting if I'm not using the fbdev
driver?
> > and then quits since it can't find any valid modes. In both cases I'm
> > running 4.0.1 from Franz Sirl's linuxppc page.
>
> While we're at it, can you please send me the URL of those?
ftp://devel.linuxppc.org/users/fsirl/xf4/RPMS/
> I thought they contained the necessary stuff from Ani Joshi's rsync tree. If
> you try to build yourself, you absolutely need that.
I just rebuilt it myself, with the rsync xfree, on the G4. The
rebuilt version works fine there (I'm using it now) with the r128
driver. I won't be able to test the newly built ati driver on the G3s
until Monday. Can I just move that driver to the drivers diretory of
the current installation on the two G3s, or do I need to do a complete
rebuild/reinstall on each of them?
> > The rev. a machine is running 2.2.15pre3 from the 2000 cd, booted via
> > BootX with "no video driver" checked.
>
> I don't think this can work with the ati driver, it needs atyfb.
OK, I'll uncheck that box. What about the "force video" BootX option
-- on or off? I did try all four combinations of these two and never
got anything to work with ati. Unchecking the box seemed to confuse
MOL on the console, so I left it checked.
> > I can run xf 4.0.x using the fbdev driver, more or less, with an
> > otherwise identical XF86Config, though xf with fbdev is noticably
> > slower than Xpmac.rev10.
>
> No big surprise as the fbdev driver doesn't have any hardware acceleration.
That's what I figured. If I can get it going properly, and get it to
support multiple monitors (especially xinerama mode - that would be
ideal), I'm happy to live with the slight decrease in speed. But of
course real ati support would be nicer....
>
> That should work if you have multiple framebuffer devices. Use
>
> Option "fbdev" "/dev/fb1"
>
> for the second one etc.
Ah ha, I didn't think of that. I'll make the change in the Device
entries.
Speaking of configs, I have a Device entry and a Screen entry for each
physical display but they're all sharing the same Monitor entry (all
three physical monitors are identical). It that likely to work?
Many thanks for the quick and thorough reply.
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-23 16:09:24
> > Specifics: with the ati driver selected, xf throws away my mode def,
> > since it thinks (incorrectly) that there isn't enough vram,
>
> Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?
The xf probe says 2MB, but in fact I have 4MB. The dmesg line says:
That might be due to a bug in the ati driver (last time I rsynced in
mid-July, there was a bug in Mach64PPCPreInit:
pScrn->videoRam = fbdevHWGetVidmem(pScrn) / 1024;
/* hack */
pScrn->videoRam = 2048;
/* TODO kludge for GI chip */
pATI->VideoRAM = pScrn->videoRam;
The hack to unconditionally set pScrn->videoRam to 2M should be removed,
that should be all. I was planning to send Ani another patch as soon as
the 16 bit color stuff was solved but I never got around to it (neither
solving the 16 bit problem nor sending a diff), sorry.
I just rebuilt it myself, with the rsync xfree, on the G4. The
rebuilt version works fine there (I'm using it now) with the r128
driver. I won't be able to test the newly built ati driver on the G3s
until Monday. Can I just move that driver to the drivers diretory of
the current installation on the two G3s, or do I need to do a complete
rebuild/reinstall on each of them?
Just copy ati_drv.o over.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-09-23 17:08:37
On 23 Sep, this message from Michel Dänzer echoed through cyberspace:
quoted
Also the screen is oddly "wrapped" on the rage II machine with the fbdev
driver: I can see the full screen but the virtual edge starts about 75% in,
instead of matching the physical edge, and then wraps around. I don't see
this artifact on the rage pro G3.
This is a known problem, which is also kind of fixed in Ani's tree AFAIK. I'm
currently working with Geert Uytterheuven to get the definite fix.
Is this the already-known problem of handling an offset for the screen
start within the framebuffer memory?
Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
valkyrie), AFAICT. So it would be helpful if this problem would get
fixed once and for all. FWIW, no propblem with XF3.x.
Thanks
Michel (the other one)
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: William Blew <hidden> Date: 2000-09-23 17:37:43
On Sat, 23 Sep 2000, R Shapiro wrote:
Subject says it all, really. I can't get the xf 4.0.x driver to work
either on a rev. a beige G3 with rage II or a rev. b beige G3 with
rage pro. Should it be working, or am I wasting my time trying? Fwiw
the r128 driver works great on my G4....
As if a couple of weeks ago I looked at the mach64 drivers that are being
developed. While I think the progress has been good, I would not describe
their mach64 support under linuxPPC as being ready for use. They still
need quite a bit of work, particularly with the 3D rage pro (mach64's GT
family) support.
Specifics: with the ati driver selected, xf throws away my mode def,
since it thinks (incorrectly) that there isn't enough vram, and then
quits since it can't find any valid modes. In both cases I'm running
4.0.1 from Franz Sirl's linuxppc page. I also tried 4.0.0 from the
Howarth page and got exactly the same results. I haven't tried
compiling xf myself but I'm perfectly willing to do so if that's
likely to help (eg if there are some known ati patches missing from
the Sirl rpms).
This is because the ati driver (linuxPPC via the framebuffer device) is
not yet correctly probing all of the mach64 chipset's families. This
includes the size of the card's frame buffer ram and its ram type, at
least (it detects my 6MB of SGRAM as EDO).
Further, last I checked, when inadequate ram (incorrect for 3D rage pro)
eliminates a video mode, that mode is still getting sent to the kernel,
even with its incorrect clock rate, etal. This causes a kernel reject of
the mode setting IOCTL.
If you have any suggestions at all, please cc: me directly -- I'll see
it more quickly that way.
I am using 3.3.6 still (due to the above issues). However, if you are
interested in development work, there is some porting of the frame buffer
driver related interface that can be done from the FB driver to the ATI
(under LinuxPPC) driver that would help in resolving these issues.
--
William Blew, wblew@home.com
Gamer by Choice, Geek by Birth
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-23 22:19:22
Michael Schmitz writes:
> That might be due to a bug in the ati driver (last time I rsynced in
> mid-July, there was a bug in Mach64PPCPreInit:
> [...]
> /* hack */
> pScrn->videoRam = 2048;
> [...]
> The hack to unconditionally set pScrn->videoRam to 2M should be removed,
The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore. The hardwired vram setting
certainly could have caused at least some of the problems I was
running into on Friday. I'll try this new ati driver first thing
Monday and report back.
--
reshapiro@mediaone.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-23 22:25:17
> /* hack */
> pScrn->videoRam = 2048;
> [...]
> The hack to unconditionally set pScrn->videoRam to 2M should be removed,
The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore. The hardwired vram setting
It was too obvious to go undetected for long :-). Now if the kernel
framebuffer driver (atyfb, and don't check the 'no video driver' option
when using BootX) reportds the correct vram size the X server should see
the correct size as well.
If you have trouble with the predefined modes, just use the ones returned
by fbset -x.
I'll rsync again to see what else may have changed.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-23 23:20:03
R Shapiro wrote:
Michel Dänzer writes:
> > Specifics: with the ati driver selected, xf throws away my mode def,
> > since it thinks (incorrectly) that there isn't enough vram,
>
> Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?
The xf probe says 2MB, but in fact I have 4MB. The dmesg line says:
atyfb: 3D RAGE PRO (PQFP, PCI) [0x4750 rev 0x7c] 4M SGRAM, 14.31818
MHz XTAL, 230 MHz PLL, 75 Mhz MCLK
Which looks good. I am confident that the xfree86-pmac rsync driver will probe
that correctly using fbdev.
I tried both UseFBDev on and off. It didn't seem to make any
difference. Btw, which is correct setting if I'm not using the fbdev
driver?
I don't think any version of the ati driver will work without "UseFBDev" on
PPC yet, and you need atyfb for that.
> > and then quits since it can't find any valid modes. In both cases I'm
> > running 4.0.1 from Franz Sirl's linuxppc page.
>
> While we're at it, can you please send me the URL of those?
ftp://devel.linuxppc.org/users/fsirl/xf4/RPMS/
Thanks, I've forwarded this to the apus-user list.
Speaking of configs, I have a Device entry and a Screen entry for each
physical display but they're all sharing the same Monitor entry (all
three physical monitors are identical). It that likely to work?
Don't know, if it doesn't work, just duplicate the Sections and give them
different Identifiers.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-24 13:30:43
Michel Lanners wrote:
On 23 Sep, this message from Michel Dänzer echoed through cyberspace:
quoted
quoted
Also the screen is oddly "wrapped" on the rage II machine with the fbdev
driver: I can see the full screen but the virtual edge starts about 75%
in, instead of matching the physical edge, and then wraps around. I
don't see this artifact on the rage pro G3.
This is a known problem, which is also kind of fixed in Ani's tree AFAIK.
I'm currently working with Geert Uytterheuven to get the definite fix.
Is this the already-known problem of handling an offset for the screen
start within the framebuffer memory?
Yes.
Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
valkyrie), AFAICT. So it would be helpful if this problem would get
fixed once and for all. FWIW, no propblem with XF3.x.
That's why I'm working with Geert, who wrote the 3.x code :)
I'm currently having problems with the MMIO mapping of his code, will
investigate. The Vidmem mapping works for me (although it also worked before),
so any volunteers for testing please line up to me for a patch :)
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
> /* hack */
> pScrn->videoRam = 2048;
> [...]
> The hack to unconditionally set pScrn->videoRam to 2M should be removed,
The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore. The hardwired vram setting
It was too obvious to go undetected for long :-). Now if the kernel
framebuffer driver (atyfb, and don't check the 'no video driver' option
when using BootX) reportds the correct vram size the X server should see
the correct size as well.
However, I see a problem. Atyfb reports the video RAM size minus the cursor
area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
end up with 1 MB too few :-(
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/
On 23 Sep, this message from Michel Dänzer echoed through cyberspace:
quoted
quoted
Also the screen is oddly "wrapped" on the rage II machine with the fbdev
driver: I can see the full screen but the virtual edge starts about 75% in,
instead of matching the physical edge, and then wraps around. I don't see
this artifact on the rage pro G3.
This is a known problem, which is also kind of fixed in Ani's tree AFAIK. I'm
currently working with Geert Uytterheuven to get the definite fix.
Is this the already-known problem of handling an offset for the screen
start within the framebuffer memory?
Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
valkyrie), AFAICT. So it would be helpful if this problem would get
fixed once and for all. FWIW, no propblem with XF3.x.
Should be fixed after applying the untested patch I sent to Michel D.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Martin Costabel <hidden> Date: 2000-09-24 16:02:55
Michel Dänzer wrote:
Michel Lanners wrote:
[]
quoted
Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
valkyrie), AFAICT. So it would be helpful if this problem would get
For what it's worth: I have *no* problem with Franz's 4.0.1 RPMs and a
valkyrie display. It works for 8 bit color without and for 15 bit color
with a modeline in XFConfig. It doesn't work for 16 bit color (and more
than that is out of reach for valkyrie with 1MB VRAM).
quoted
fixed once and for all. FWIW, no propblem with XF3.x.
That's why I'm working with Geert, who wrote the 3.x code :)
I'm currently having problems with the MMIO mapping of his code, will
investigate. The Vidmem mapping works for me (although it also worked before),
so any volunteers for testing please line up to me for a patch :)
I'd volunteer if you provide a precompiled server binary. For compiling
XFree86 myself, my machine is too slow.
--
Martin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-24 16:14:34
Martin Costabel wrote:
Michel Dänzer wrote:
quoted
Michel Lanners wrote:
[]
quoted
quoted
Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
valkyrie), AFAICT. So it would be helpful if this problem would get
For what it's worth: I have *no* problem with Franz's 4.0.1 RPMs and a
valkyrie display. It works for 8 bit color without and for 15 bit color
with a modeline in XFConfig. It doesn't work for 16 bit color (and more
than that is out of reach for valkyrie with 1MB VRAM).
The X 4 fbdev code used to pass the depth incorrectly in the PUTSCREENINFO
ioctl. I have a fix for that too and will submit it with the rest.
quoted
quoted
fixed once and for all. FWIW, no propblem with XF3.x.
That's why I'm working with Geert, who wrote the 3.x code :)
I'm currently having problems with the MMIO mapping of his code, will
investigate. The Vidmem mapping works for me (although it also worked
before), so any volunteers for testing please line up to me for a patch :)
I'd volunteer if you provide a precompiled server binary. For compiling
XFree86 myself, my machine is too slow.
All you'd need to update would be the libfbdevhw.a and fbdev_drv.o modules. I
think I'll put them up RSN at
http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2
Beware: DON'T use this with an accelerated driver right now.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-24 19:51:00
Mostly good news:
1. On the rev. a beige G3 w/Mach64 Rage II, the fbdev driver I built
yesterday from the latest rsync fixes the skew/wrap oddity. In other
words, it seems to work fine on this platform now.
2. On the same machine, I now have a working multi(3)-headed X! I'm
very impressed that the linuxppc X development team got this going so
quickly. It only works with the fbdev driver (see below), but I'm not
complaining. The only issue I've run into so far is the known bug
with screenblanking, which I can fix easily enough via xset.
I can't test xinerama on this platform because the three screen don't
all run at same depth (two use depth 15/16, one uses depth 8). And my
preferred window manager (blackbox) doesn't seem to happy running more
than once from the same .blackboxrc (fvwm will do for now). But these
are details...
3. On the same machine, the ati driver I built yesterday hoses linux
completely and doesn't leave a core file. I'm happy to help the
developers try to debug this, but I'm not sure what information I can
provide in this situation (it's also not my machine, so I can't always
crash it at will).
4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
be working. The XF probe still gets the wrong amount of vram, and it
still throws away the mode I constructed via fbset -x. But it finds
another valid mode somewhere else (where are these default modes
coming from anyway?) and it definitely feels accelerated. I'm a
little worried that it may be driving the monitor too hard but I'm not
sure how to find out. xpydinfo doesn't say anything useful. The
output from startx includes this:
(II) ATI(0): Monitor0: Using hsync range of 30.00- 94.00 kHz
(II) ATI(0): Monitor0: Using vrefresh range of 48.00-120.00 Hz
which are the numbers I put in the XF86Config (taken straight from the
monitor manual). But somehow it looks like it's running too high a
sync rate.
All in all, worth coming in to work on a Sunday for :)
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-24 23:17:36
R Shapiro wrote:
2. On the same machine, I now have a working multi(3)-headed X! I'm
very impressed that the linuxppc X development team got this going so
quickly. It only works with the fbdev driver (see below), but I'm not
complaining. The only issue I've run into so far is the known bug
with screenblanking, which I can fix easily enough via xset.
What bug with screenblanking?
I can't test xinerama on this platform because the three screen don't
all run at same depth (two use depth 15/16, one uses depth 8).
What about just testing it with the two heads who run at 16 bpp, or run all
heads in depth 8?
3. On the same machine, the ati driver I built yesterday hoses linux
completely and doesn't leave a core file. I'm happy to help the
developers try to debug this, but I'm not sure what information I can
provide in this situation (it's also not my machine, so I can't always
crash it at will).
The server log and maybe the XF86Config are always a good start for
information.
4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
be working. The XF probe still gets the wrong amount of vram,
Hint to Ani or whoever is working on the ati driver: Why not get the VRAM size
from the framebuffer device?
and it still throws away the mode I constructed via fbset -x.
What reason does it give for rejecting it?
But it finds another valid mode somewhere else (where are these default
modes coming from anyway?)
They're built into the server binary. Mostly VESA standard modes AFAICT.
and it definitely feels accelerated. I'm a little worried that it may be
driving the monitor too hard but I'm not sure how to find out. xpydinfo
doesn't say anything useful.
xvidtune gives information about the modes.
The output from startx includes this:
(II) ATI(0): Monitor0: Using hsync range of 30.00- 94.00 kHz
(II) ATI(0): Monitor0: Using vrefresh range of 48.00-120.00 Hz
which are the numbers I put in the XF86Config (taken straight from the
monitor manual). But somehow it looks like it's running too high a
sync rate.
Look at the log (/var/log/XFree86.0.log), there should be values for all modes
used and rejected.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-25 01:24:54
Michel Dänzer writes:
> What bug with screenblanking?
Using the fbdev driver with xf 4.0.1, the default screenblanker kills
the server as soon as the blanker is activated. This can easily be
replicated via 'xset s activate' or by letting the screenblanker
activate itself by timing out. The ati driver and the r128 driver
don't have this problem, only fbdev.
I've seen this on all three platforms where I've tested 4.0.1, either
using Franz Sirl's rpms or using the version I built with sources
rsync'd yesterday.
Martin Costabel reported this back in July on the users list so I
assumed it was a known but low-priority bug (it's easily gotten around
via 'xset s noblank').
> > I can't test xinerama on this platform because the three screen don't
> > all run at same depth (two use depth 15/16, one uses depth 8).
>
> What about just testing it with the two heads who run at 16 bpp, or run all
> heads in depth 8?
I won't have access to the machine for a few days: the multi screen X
will be used off and on for demos all week :) But I'll test this as
soon as I can fiddle with the config file again.
What's the right syntax for starting in this mode? startx -- +xinerama ?
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Martin Costabel <hidden> Date: 2000-09-25 06:43:08
R Shapiro wrote:
Michel Dänzer writes:
> What bug with screenblanking?
Using the fbdev driver with xf 4.0.1, the default screenblanker kills
the server as soon as the blanker is activated. This can easily be
replicated via 'xset s activate' or by letting the screenblanker
activate itself by timing out. The ati driver and the r128 driver
don't have this problem, only fbdev.
I've seen this on all three platforms where I've tested 4.0.1, either
using Franz Sirl's rpms or using the version I built with sources
rsync'd yesterday.
Martin Costabel reported this back in July on the users list so I
assumed it was a known but low-priority bug (it's easily gotten around
via 'xset s noblank').
I had this at the beginning after switching to Franz' RPMs, but it went
away soon, I don't remember why, maybe with Franz' 0.36a instead of
0.30c. Now screen blanking is OK, except that it blanks selectively,
i.e. parts of the screen with active widgets, clocks or ads or whatever,
remain visible. This has also been observed before by someone else (or
maybe it's a feature?).
The most annoying bug for me is that sometimes keys repeat (almost)
indefinitely. Most frequently mouse clicks on scroll arrows that scroll
all the way to the end of the file, but I had it also with the delete
(backwards) key that instead of only 2 characters erased 90% of the
whole text. This bug is random, but its probability is variable:
sometimes it happens practically always and sometimes almost never.
--
Martin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-25 08:56:53
Is this the already-known problem of handling an offset for the screen
start within the framebuffer memory?
Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
Sounds like Apple. It's been a problem on the m68k Apple framebuffers as
well, and got fixed for those by Geert in 3.3. The fix got lost or
incorrectly applied in 4.0 ...
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-25 09:03:59
3. On the same machine, the ati driver I built yesterday hoses linux
completely and doesn't leave a core file. I'm happy to help the
developers try to debug this, but I'm not sure what information I can
provide in this situation (it's also not my machine, so I can't always
crash it at will).
Does the X server complain about PCI resource conflicts when run as X
--probeonly? Anything about PCI problems in the server log?
If so, send the output of lspci -vv.
BTW: Can you use yaboot for booting?
4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
be working. The XF probe still gets the wrong amount of vram, and it
still throws away the mode I constructed via fbset -x. But it finds
Perhaps the video RAM detection typo which should be gone now ...
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
The most annoying bug for me is that sometimes keys repeat (almost)
indefinitely. Most frequently mouse clicks on scroll arrows that scroll
all the way to the end of the file, but I had it also with the delete
(backwards) key that instead of only 2 characters erased 90% of the
whole text. This bug is random, but its probability is variable:
sometimes it happens practically always and sometimes almost never.
I noticed the same thing also only in kernels with the input layer though,
i haven't heard of any similar problems in the x86 side and since the code
in x is the same i suspect that the problem is in the kernel side.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-25 10:38:08
Martin Costabel writes:
> I had this at the beginning after switching to Franz' RPMs, but it went
> away soon, I don't remember why, maybe with Franz' 0.36a instead of
> 0.30c.
I was seeing it in 0.36, and it's still there with the complete rsync
and rebuild I did on Saturday. It may be an intermittent problem but
I don't think it's been fixed yet.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-25 11:39:23
Michael Schmitz writes:
> [ati driver on rev. a Rage II beige G3 hoses linux]
> Does the X server complain about PCI resource conflicts when run as X
> --probeonly?
I'll run this test as soon as the Rage II machine is available again.
> Anything about PCI problems in the server log?
The only server log I have right now is for the X I left running
yesterday with the fbdev driver. There are a couple of PCI warnings
in this one but no errors (no surprise, since everything is working
well with fbdev):
(**) (null)(2): claimed PCI slot 0:15:0
(II) FBDev(2): using /dev/fb2
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
(II) window:
[0] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(II) resSize:
(II) window fixed:
[0] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
I didn't save any logs from the ati tests that hung linux. I'll try
to generate one next time the machine is available for crashing :)
> BTW: Can you use yaboot for booting?
I don't know, can I use yaboot on a rev. a beige G3? I think the
answer is 'no' but I'm not sure. I don't think I can use quik either,
since the linux installation is on an ide drive (the rev. b G3 uses
quik but it has scsi drives only, no ide). Maybe miBoot would work,
I've never tried to use that one before.
Are there known X-related problems using BootX?
> > 4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
> > be working. The XF probe still gets the wrong amount of vram, and it
> > still throws away the mode I constructed via fbset -x. But it finds
>
> Perhaps the video RAM detection typo which should be gone now ...
Fwiw I'm using the ati driver I built from sources rsync'd on
Saturday.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-25 12:42:49
> Anything about PCI problems in the server log?
The only server log I have right now is for the X I left running
yesterday with the fbdev driver. There are a couple of PCI warnings
in this one but no errors (no surprise, since everything is working
well with fbdev):
(**) (null)(2): claimed PCI slot 0:15:0
(II) FBDev(2): using /dev/fb2
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
(II) window:
[0] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(II) resSize:
(II) window fixed:
[0] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
These shouldn't be critical (but they shouldn't happen, either).
> BTW: Can you use yaboot for booting?
I don't know, can I use yaboot on a rev. a beige G3? I think the
Probably not - it could work with the b&w one, that's why I asked.
Are there known X-related problems using BootX?
You were looking at it, from what I guess. Apple's drivers set up
overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
these. Unfortunatly, the kernel doesn't notice.
> > 4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
> > be working. The XF probe still gets the wrong amount of vram, and it
> > still throws away the mode I constructed via fbset -x. But it finds
>
> Perhaps the video RAM detection typo which should be gone now ...
Fwiw I'm using the ati driver I built from sources rsync'd on
Saturday.
That should have the stupid typo removed ...
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-25 12:52:33
Michel Dänzer writes:
> > I can't test xinerama on this platform because the three screen don't
> > all run at same depth (two use depth 15/16, one uses depth 8).
>
> What about just testing it with the two heads who run at 16 bpp, or run all
> heads in depth 8?
I just did it tried running +xinerama with all three monitors at 8pp.
It works! Blackbox is happy to move windows across screens, or even
leave a window half on one and half on another. Basically just like
the multiple monitor support that MacOS has always had.
Very nice :)
Btw for those who might want to try this, +xinerama is a server arg so
the command is 'startx -- +xinerama'.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-25 17:37:12
On Sun, 24 Sep 2000, Michael Schmitz wrote:
quoted
quoted
> /* hack */
> pScrn->videoRam = 2048;
> [...]
> The hack to unconditionally set pScrn->videoRam to 2M should be removed,
The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore. The hardwired vram setting
It was too obvious to go undetected for long :-). Now if the kernel
framebuffer driver (atyfb, and don't check the 'no video driver' option
when using BootX) reportds the correct vram size the X server should see
the correct size as well.
However, I see a problem. Atyfb reports the video RAM size minus the cursor
area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
end up with 1 MB too few :-(
Rather 1k too few if you mean the truncation error - or is the cursor area
really 1 MB?
My LT Pro reports 8188 kB. Seems I can live without the four that have
gone missing.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
> /* hack */
> pScrn->videoRam = 2048;
> [...]
> The hack to unconditionally set pScrn->videoRam to 2M should be removed,
The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore. The hardwired vram setting
It was too obvious to go undetected for long :-). Now if the kernel
framebuffer driver (atyfb, and don't check the 'no video driver' option
when using BootX) reportds the correct vram size the X server should see
the correct size as well.
However, I see a problem. Atyfb reports the video RAM size minus the cursor
area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
end up with 1 MB too few :-(
Hmm does this mean that mmapping the framebuffer doesn't give you the
start of vram but vram+offset ? if yes then we have a big problem here.
BTW you'll end up 1KB too few not 1MB, pScrn->videoRam is in KBytes :)
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-25 17:43:05
R Shapiro wrote:
I just did it tried running +xinerama with all three monitors at 8pp.
It works! Blackbox is happy to move windows across screens, or even
leave a window half on one and half on another. Basically just like
the multiple monitor support that MacOS has always had.
Very nice :)
Cool.
Btw for those who might want to try this, +xinerama is a server arg so
the command is 'startx -- +xinerama'.
There's also an option for XF86Config, read the manpage - the logical place
would be in the Layout Section.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-25 18:38:08
Hmm does this mean that mmapping the framebuffer doesn't give you the
start of vram but vram+offset ? if yes then we have a big problem here.
No, atyfb reserved some space at the end of vram (MMIO mirrored there,
please try to memset (0) that area for kicks. Makes you think you're
melting your display).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-25 18:57:30
Michel Dänzer writes:
> > Btw for those who might want to try this, +xinerama is a server arg so
> > the command is 'startx -- +xinerama'.
>
> There's also an option for XF86Config, read the manpage - the logical place
> would be in the Layout Section.
I searched the XF86Config and XFree86 man pages and found no
references to xinerama. Is it somewhere else? None of the
ServerLayout settings seem relevant to xinerama as distinguished from
the standard multi-head mode (multiple X screens).
I'd rather put this option in the XF86Config but I can't find a place
for it.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-25 18:59:49
R Shapiro wrote:
> > Btw for those who might want to try this, +xinerama is a server arg so
> > the command is 'startx -- +xinerama'.
>
> There's also an option for XF86Config, read the manpage - the logical
> place would be in the Layout Section.
I searched the XF86Config and XFree86 man pages and found no
references to xinerama. Is it somewhere else? None of the
ServerLayout settings seem relevant to xinerama as distinguished from
the standard multi-head mode (multiple X screens).
I'd rather put this option in the XF86Config but I can't find a place
for it.
If (wild guess)
Option "UseXinerama"
in the Layout Section doesn't work, please ask on xpert@XFree86.Org .
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
> /* hack */
> pScrn->videoRam = 2048;
> [...]
> The hack to unconditionally set pScrn->videoRam to 2M should be removed,
The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore. The hardwired vram setting
It was too obvious to go undetected for long :-). Now if the kernel
framebuffer driver (atyfb, and don't check the 'no video driver' option
when using BootX) reportds the correct vram size the X server should see
the correct size as well.
However, I see a problem. Atyfb reports the video RAM size minus the cursor
area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
end up with 1 MB too few :-(
Rather 1k too few if you mean the truncation error - or is the cursor area
really 1 MB?
You're right. I was thinking MB instead of kB...
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/
> Anything about PCI problems in the server log?
The only server log I have right now is for the X I left running
yesterday with the fbdev driver. There are a couple of PCI warnings
in this one but no errors (no surprise, since everything is working
well with fbdev):
(**) (null)(2): claimed PCI slot 0:15:0
(II) FBDev(2): using /dev/fb2
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
(II) window:
[0] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(II) resSize:
(II) window fixed:
[0] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
These shouldn't be critical (but they shouldn't happen, either).
quoted
Are there known X-related problems using BootX?
You were looking at it, from what I guess. Apple's drivers set up
overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
these. Unfortunatly, the kernel doesn't notice.
Fortunately these PCI assignment bugs should be circumvented by the new PCI
code we're working on.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-26 18:35:23
quoted
quoted
Are there known X-related problems using BootX?
You were looking at it, from what I guess. Apple's drivers set up
overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
these. Unfortunatly, the kernel doesn't notice.
Fortunately these PCI assignment bugs should be circumvented by the new PCI
code we're working on.
... in 2.4.x, I believe. Problem is, most people aren't crazy enough to
use 2.4.0 (-test8 in particular).
All you can do in 2.2 is the 'pick and pray' approach: pick an alternate
address for MMIO bases on some heuristics or wild guesses, and pray you
don't trample on other card's resources. Works for me, but I warn anyone
to be careful with that method.
I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-26 19:04:37
Michael Schmitz writes:
> > 3. On the same machine, the ati driver I built yesterday hoses linux
> > completely and doesn't leave a core file.
>
> Does the X server complain about PCI resource conflicts when run as X
> --probeonly? Anything about PCI problems in the server log?
"startx -- -probeonly" also crashes linux when the ati drivers are
selected.
Here's the log, which ends somewhat abruptly. The final two lines
reject the two modes I generated with fbset. Both are considered ok
by the fbdev driver.
XFree86 Version 4.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 1 July 2000
If the server is older than 6-12 months, or if your card is newer
than the above date, look for a newer version before reporting
problems. (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.17pre10-ben2 ppc [ELF]
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Tue Sep 26 14:44:57 2000
(==) Using config file: "/etc/X11/XF86Config"
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "Monitor"
(**) | |-->Device "device0"
(**) |-->Screen "Screen1" (1)
(**) | |-->Monitor "Monitor"
(**) | |-->Device "device1"
(**) |-->Screen "Screen2" (2)
(**) | |-->Monitor "Monitor"
(**) | |-->Device "device2"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "XkbModel" "macintosh_old"
(**) XKB: model: "macintosh_old"
(**) FontPath set to "unix/:7100,tcp/blatz:7100"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.1
XFree86 Video Driver: 0.2
XFree86 XInput driver : 0.1
XFree86 Server Extension : 0.1
XFree86 Font Renderer : 0.1
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.1
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.2
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1057,0002 card 0000,0000 rev 40 class 06,00,00 hdr 00
(II) PCI: 00:0d:0: chip 1002,4749 card 1002,0000 rev 5c class 03,00,00 hdr 00
(II) PCI: 00:0f:0: chip 1002,4749 card 1002,0000 rev 5c class 03,00,00 hdr 00
(II) PCI: 00:10:0: chip 106b,0010 card 0000,0000 rev 01 class ff,00,00 hdr 00
(II) PCI: 00:12:0: chip 1002,4754 card 0000,0000 rev 9a class 03,00,00 hdr 00
(II) PCI: End of PCI scan
(II) LoadModule: "scanpci"
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.2
(II) UnloadModule: "scanpci"
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(--) PCI: (0:13:0) ATI Mach64 GI rev 92, Mem @ 0x84000000/24, 0x81801000/12, I/O @ 0x0400/8
(--) PCI: (0:15:0) ATI Mach64 GI rev 92, Mem @ 0x83000000/24, 0x81800000/12, I/O @ 0x0400/8
(--) PCI: (0:18:0) ATI Mach64 GT rev 154, Mem @ 0x82000000/24, I/O @ 0x0400/8
(II) Addressable bus resource ranges are
[0] -1 0x00000000 - 0xffffffff (0x0) MXB
[1] -1 0x00000000 - 0x0000ffff (0x10000) IXB
(II) OS-reported resource ranges:
(II) Active PCI resource ranges:
[0] -1 0xf3000000 - 0xf3ffffff (0x1000000) MXBE
[1] -1 0x82000000 - 0x82ffffff (0x1000000) MXB(B)
[2] -1 0x81820000 - 0x8183ffff (0x20000) MXB(B)
[3] -1 0x81800000 - 0x81800fff (0x1000) MXB(B)
[4] -1 0x83000000 - 0x83ffffff (0x1000000) MXB(B)
[5] -1 0x81840000 - 0x8185ffff (0x20000) MXB(B)
[6] -1 0x81801000 - 0x81801fff (0x1000) MXB(B)
[7] -1 0x84000000 - 0x84ffffff (0x1000000) MXB(B)
[8] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[9] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[10] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
(II) Active PCI resource ranges after removing overlaps:
[0] -1 0xf3000000 - 0xf3ffffff (0x1000000) MXBE
[1] -1 0x82000000 - 0x82ffffff (0x1000000) MXB(B)
[2] -1 0x81820000 - 0x8183ffff (0x20000) MXB(B)
[3] -1 0x81800000 - 0x81800fff (0x1000) MXB(B)
[4] -1 0x83000000 - 0x83ffffff (0x1000000) MXB(B)
[5] -1 0x81840000 - 0x8185ffff (0x20000) MXB(B)
[6] -1 0x81801000 - 0x81801fff (0x1000) MXB(B)
[7] -1 0x84000000 - 0x84ffffff (0x1000000) MXB(B)
[8] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[9] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[10] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
(II) OS-reported resource ranges after removing overlaps with PCI:
(II) All system resource ranges:
[0] -1 0xf3000000 - 0xf3ffffff (0x1000000) MXBE
[1] -1 0x82000000 - 0x82ffffff (0x1000000) MXB(B)
[2] -1 0x81820000 - 0x8183ffff (0x20000) MXB(B)
[3] -1 0x81800000 - 0x81800fff (0x1000) MXB(B)
[4] -1 0x83000000 - 0x83ffffff (0x1000000) MXB(B)
[5] -1 0x81840000 - 0x8185ffff (0x20000) MXB(B)
[6] -1 0x81801000 - 0x81801fff (0x1000) MXB(B)
[7] -1 0x84000000 - 0x84ffffff (0x1000000) MXB(B)
[8] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[9] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[10] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.1
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Server Extension
ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Server Extension
ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension DPMS
(II) Loading extension FontCache
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension GLX
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Reloading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) LoadModule: "pex5"
(II) Loading /usr/X11R6/lib/modules/extensions/libpex5.a
(II) Module pex5: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Server Extension
ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension X3D-PEX
(II) LoadModule: "record"
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.13.0
Module class: XFree86 Server Extension
ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension RECORD
(II) LoadModule: "xie"
(II) Loading /usr/X11R6/lib/modules/extensions/libxie.a
(II) Module xie: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Server Extension
ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension XIE
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.1
(II) Loading font Type1
(II) Loading font CID
(II) LoadModule: "speedo"
(II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a
(II) Module speedo: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.1
(II) Loading font Speedo
(II) LoadModule: "ati"
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 5.3.5
Module class: XFree86 Video Driver
ABI class: XFree86 Video Driver, version 0.2
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 1.0.0
Module class: XFree86 XInput Driver
ABI class: XFree86 XInput driver, version 0.1
(II) ATI: ATI driver (version 5.3.5) for chipsets: ati, ativga
(--) Chipset ATI Mach64 3D Rage Pro (BGA, PCI) found
(--) Chipset ATI Mach64 3D Rage Pro (BGA, PCI) found
(--) Chipset ATI Mach64 GT (PCI) found
(II) resource ranges after xf86ClaimFixedResources() call:
[0] -1 0xf3000000 - 0xf3ffffff (0x1000000) MXBE
[1] -1 0x82000000 - 0x82ffffff (0x1000000) MXB(B)
[2] -1 0x81820000 - 0x8183ffff (0x20000) MXB(B)
[3] -1 0x81800000 - 0x81800fff (0x1000) MXB(B)
[4] -1 0x83000000 - 0x83ffffff (0x1000000) MXB(B)
[5] -1 0x81840000 - 0x8185ffff (0x20000) MXB(B)
[6] -1 0x81801000 - 0x81801fff (0x1000) MXB(B)
[7] -1 0x84000000 - 0x84ffffff (0x1000000) MXB(B)
[8] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[9] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[10] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
Found a Mach64 on a PowerPC
(II) resource ranges after probing:
[0] -1 0xf3000000 - 0xf3ffffff (0x1000000) MXBE
[1] -1 0x82000000 - 0x82ffffff (0x1000000) MXB(B)
[2] -1 0x81820000 - 0x8183ffff (0x20000) MXB(B)
[3] -1 0x81800000 - 0x81800fff (0x1000) MXB(B)
[4] -1 0x83000000 - 0x83ffffff (0x1000000) MXB(B)
[5] -1 0x81840000 - 0x8185ffff (0x20000) MXB(B)
[6] -1 0x81801000 - 0x81801fff (0x1000) MXB(B)
[7] -1 0x84000000 - 0x84ffffff (0x1000000) MXB(B)
[8] 0 0x000a0000 - 0x000affff (0x10000) MSB
[9] 0 0x000b0000 - 0x000b7fff (0x8000) MSB
[10] 0 0x000b8000 - 0x000bffff (0x8000) MSB
[11] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[12] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[13] -1 0x00000400 - 0x000004ff (0x100) IXB(B)
[14] 0 0x000003b0 - 0x000003bb (0xc) ISB
[15] 0 0x000003c0 - 0x000003df (0x20) ISB
(II) Setting vga for screen 0.
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
compiled for 4.0.1, module version = 0.0.1
ABI class: XFree86 Video Driver, version 0.2
(**) ATI(0): Depth 8, (--) framebuffer bpp 8
(==) ATI(0): Default visual is PseudoColor
Mapping MMIO @ 0x847ff000 with size 0x1000
testing mmio w/ scratch regs...
SCRATCH_REG0 = 0x3d5d
SCRATCH_REG0 = 0x12345678
SCRATCH_REG1 = 0x0
SCRATCH_REG1 = 0xdeadbeef
Chip Type = 0x4749, Rev = 0x7c
(--) ATI(0): VideoRam: 1 kByte (EDO)
(==) ATI(0): Using gamma correction (1.0, 1.0, 1.0)
(II) ATI(0): Monitor: Using hsync range of 1.00-300.00 kHz
(II) ATI(0): Monitor: Using vrefresh range of 1.00-300.00 Hz
(II) ATI(0): Maximum clock: 120.00 MHz
(WW) ATI(0): Mode "1152x870" deleted (bad mode clock/interlace/doublescan)
(WW) ATI(0): Mode "1280x1024" deleted (bad mode clock/interlace/doublescan)
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-26 19:24:27
R Shapiro wrote:
Michael Schmitz writes:
> > 3. On the same machine, the ati driver I built yesterday hoses linux
> > completely and doesn't leave a core file.
>
> Does the X server complain about PCI resource conflicts when run as X
> --probeonly? Anything about PCI problems in the server log?
"startx -- -probeonly" also crashes linux when the ati drivers are
selected.
Here's the log, which ends somewhat abruptly.
[...]
(--) PCI: (0:13:0) ATI Mach64 GI rev 92, Mem @ 0x84000000/24, 0x81801000/12, I/O @ 0x0400/8
(--) PCI: (0:15:0) ATI Mach64 GI rev 92, Mem @ 0x83000000/24, 0x81800000/12, I/O @ 0x0400/8
(--) PCI: (0:18:0) ATI Mach64 GT rev 154, Mem @ 0x82000000/24, I/O @ 0x0400/8
[...]
(--) ATI(0): VideoRam: 1 kByte (EDO)
That's quite little VRAM :)
Do you have an atyfb for each head? If so, try also passing the "fbdev" option
with the devices for the ati driver.
The final two lines reject the two modes I generated with fbset. Both are
considered ok by the fbdev driver.
Are the modes below 120 MHz? Have you tried uncommenting your mode definitions
so that is uses internal modes?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-26 19:33:30
quoted
> Does the X server complain about PCI resource conflicts when run as X
> --probeonly? Anything about PCI problems in the server log?
"startx -- -probeonly" also crashes linux when the ati drivers are
selected.
Here's the log, which ends somewhat abruptly.
[...]
quoted
(--) PCI: (0:13:0) ATI Mach64 GI rev 92, Mem @ 0x84000000/24, 0x81801000/12, I/O @ 0x0400/8
(--) PCI: (0:15:0) ATI Mach64 GI rev 92, Mem @ 0x83000000/24, 0x81800000/12, I/O @ 0x0400/8
(--) PCI: (0:18:0) ATI Mach64 GT rev 154, Mem @ 0x82000000/24, I/O @ 0x0400/8
[...]
quoted
(--) ATI(0): VideoRam: 1 kByte (EDO)
That's quite little VRAM :)
Yep, that can't really be the 2048 bug anymore.
But that's also quite a lot of mach64 cards. Are there really two GI's in
the machine?
No PCI regions overlap so my patch doesn't apply.
Do you have an atyfb for each head? If so, try also passing the "fbdev" option
with the devices for the ati driver.
You will have to pass multipe atyfb= kernel parameters to make the kernel
initialize one framebuffer device for each. Right now I doubt
atyfb_of_init will do the right thing here - could you post the kernel
boot messages again? I wonder if the device you specify via the busid is
the same the kernel initialized as atyfb.
Also helpful: a dump of the OF device tree.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-26 20:55:55
Michael Schmitz writes:
> > > (--) ATI(0): VideoRam: 1 kByte (EDO)
> >
> > That's quite little VRAM :)
>
> Yep, that can't really be the 2048 bug anymore.
Fwiw the probed VideoRam on my rev. b beige G3 is also some
ridiculously small number (though not as small as this) yet it runs
the ati driver without any problems. That one has a single monitor
and Rage Pro video.
> But that's also quite a lot of mach64 cards. Are there really two GI's in
> the machine?
It's a three-headed machine: two Rage Pro cards plus the onboard Rage
II. If I set all three Devices to use fbdev, X happily drives all
three displays (in xinerama, even). It's only the ati driver that
causes the trouble.
> You will have to pass multipe atyfb= kernel parameters to make the kernel
> initialize one framebuffer device for each.
Right now my kernel args are
video=atyfb:vmode:20,cmode:8
I don't know the syntax for specifying multiple atyfb's.
I'm using BootX to boot. I tried miBoot but I couldn't get X 4.0.1 to
run at all that way, even with the fbdev driver. I don't think quik
booting works on this machine, so BootX seems to be the only option.
> Also helpful: a dump of the OF device tree.
Remind me how to get that and I'll try to generate one.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
You were looking at it, from what I guess. Apple's drivers set up
overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
these. Unfortunatly, the kernel doesn't notice.
Fortunately these PCI assignment bugs should be circumvented by the new PCI
code we're working on.
... in 2.4.x, I believe. Problem is, most people aren't crazy enough to
use 2.4.0 (-test8 in particular).
All you can do in 2.2 is the 'pick and pray' approach: pick an alternate
address for MMIO bases on some heuristics or wild guesses, and pray you
don't trample on other card's resources. Works for me, but I warn anyone
to be careful with that method.
I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).
You should walk all PCI devices and construct your own resource tree from
pci_dev->base_address[i]. After that you know the conflicts and unassigned
addresses and can look for free space. Unfortunately this is probably nearly
as much work as backporting the 2.4.x PCI resource code (which is tested,
unlike new code you would invent).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-27 18:21:32
quoted
I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).
You should walk all PCI devices and construct your own resource tree from
pci_dev->base_address[i]. After that you know the conflicts and unassigned
addresses and can look for free space. Unfortunately this is probably nearly
as much work as backporting the 2.4.x PCI resource code (which is tested,
unlike new code you would invent).
Yep, I'm aware of that. I'm way too lazy to backport the PCI resource code
and the problem seemed solved by using yaboot for me. I didn't
fully realize the Wallstreet doesn't have this option.
Instead of walking the whole device tree, I hope to get away with just
picking a free area (assuming pci_dev->base_address[i] == 0 means free)
instead. But I won't get to it before the weekend. If BenH implements a
cleaner way, the better.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-27 18:36:31
MacOS display is /pci/ATY,mach64_3DU
atyfb: 3D RAGE (GT) [0x4754 rev 0x9a] 2M SGRAM, 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK
BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
7b23a040 86010182 004215b3 25010001 03000200 002806e3 02100503
PLL ad d5 21 44 e8 13 80 b5 8e 9e 98 04 a6 1b 00 00
Console: switching to colour frame buffer device 160x64
fb0: ATY Mach64 frame buffer device on /pci/ATY,mach64_3DU
atyfb: 3D RAGE PRO (BGA, PCI) [0x4749 rev 0x7c] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK
BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
7b33a040 87010182 04651a77 75130c01 03000300 00280509 01f004f1
PLL ad d5 21 64 e4 13 80 b5 8e 9e 98 01 a6 1b 00 00
fb1: ATY Mach64 frame buffer device on /pci/ATY,XCLAIM3DPro
atyfb: 3D RAGE PRO (BGA, PCI) [0x4749 rev 0x7c] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK
BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
7b33a040 87010102 04651a77 75130c01 03000300 00280509 01f004f1
PLL ad d5 21 64 e4 13 80 b5 8e 9e 98 01 a6 1b 00 00
fb2: ATY Mach64 frame buffer device on /pci/ATY,XCLAIM3DPro
atyfb handles three displays just fine (could have guessed so, sorry Geert).
So here we have three fb devices in the kernel (you could check with
fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
to cope. You specify the PCI bus ID but not the corresponding framebuffer
device node - I heard someone mention this was possible when I was
fighting the Lombard crashes, could anyone point out the syntax to use
there?
If we can't specify the fb node XFree will have to probe for it (Geert
mentioned an easy way to do that: open the device and compare
pScrn->memPhysBase or fPtr->fix.smem_start to the PCI base address).
BTW Geert: why is fPtr->fboff calculated from fix.smem_len not
fix.smem_start while pScrn->fbOffset is calculated from fix.smem_start?
void*
fbdevHWMapVidmem(ScrnInfoPtr pScrn)
{
fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
TRACE_ENTER("MapVidmem");
if (NULL == fPtr->fbmem) {
fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
fPtr->fbmem = mmap(NULL, fPtr->fix.smem_len, PROT_READ | PROT_W
MAP_SHARED, fPtr->fd, 0);
if (-1 == (int)fPtr->fbmem) {
perror("mmap fbmem");
fPtr->fbmem = NULL;
}
}
pScrn->memPhysBase = (unsigned long)fPtr->fix.smem_start & (unsigned long)(PAGE_MASK);
pScrn->fbOffset = (unsigned long)fPtr->fix.smem_start & (unsigned long) (~PAGE_MASK);
return fPtr->fbmem;
}
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-27 18:45:34
Michael Schmitz writes:
> So here we have three fb devices in the kernel (you could check with
> fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
> to cope.
The ati driver unable to cope. The fbdev driver copes without
complaint.
> You specify the PCI bus ID but not the corresponding framebuffer
> device node
In the XF86Config? That has both the bus id and the dev node:
Option "UseFBDev"
Option "fbdev" "/dev/fb0"
Driver "fbdev"
BusID "PCI:0:18:0"
Similarly for the second and third devices (/dev/fb1 & PCI:0:13:0,
/dev/fb2 & PCI:0:15:0, respectively).
Hmm, if change the driver to "ati", am I also supposed the change the
device node Option to "ati", ie 'Option "ati" "/dev/fb0"'? I never
tried that.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-27 19:07:16
> So here we have three fb devices in the kernel (you could check with
> fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
> to cope.
The ati driver unable to cope. The fbdev driver copes without
complaint.
That's what I mean - the fbdev driver knows about the correct addresses
(it gets them from the fb.fix strucure).
> You specify the PCI bus ID but not the corresponding framebuffer
> device node
In the XF86Config? That has both the bus id and the dev node:
Option "UseFBDev"
Option "fbdev" "/dev/fb0"
Driver "fbdev"
BusID "PCI:0:18:0"
S**t. I overlooked that. Ok, I officially declare the ati driver unable to
cope. Please disable the fb_open_pci() call in fbdevhw.c:
Bool
fbdevHWInit(ScrnInfoPtr pScrn, pciVideoPtr pPci, char *device)
{
fbdevHWPtr fPtr;
TRACE_ENTER("Init");
fbdevHWGetRec(pScrn);
fPtr = FBDEVHWPTR(pScrn);
/* open device */
#if 0
if (pPci)
fPtr->fd = fbdev_open_pci(pPci,NULL);
else
#endif
fPtr->fd = fbdev_open(device,NULL);
Hmm, if change the driver to "ati", am I also supposed the change the
device node Option to "ati", ie 'Option "ati" "/dev/fb0"'? I never
tried that.
Nope, the syntax should be OK. Question is does the ati driver parse that
option if fb_open_pci is used.
I'm just speculating here, and I've never tried using the traditional fb
open so no guarantee it will work - and you're on your own if the ati
driver insist on using PCI.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-27 19:16:03
Michael Schmitz writes:
> S**t. I overlooked that. Ok, I officially declare the ati driver unable to
> cope.
Just to mention: the ati driver *does* work on my other G3, a
single-monitor rev. b Rage Pro running the same XFree 4.0.1 (different
kernel though). Is it useful to see the log for that one? I notice
that it's throwing away the mode I got from fbset -x and using one of
the built-in modes instead. It also gets a silly value back from the
vram probe:
(--) ATI(0): VideoRam: 3 kByte (EDO)
But it runs ok, at least so far.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-27 19:18:27
> S**t. I overlooked that. Ok, I officially declare the ati driver unable to
> cope.
Just to mention: the ati driver *does* work on my other G3, a
single-monitor rev. b Rage Pro running the same XFree 4.0.1 (different
Unable to cope with multiple framebuffers :-) Single framebuffer is easy:
PCI and fb should address the same card.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-27 20:32:29
Yep, I'm aware of that. I'm way too lazy to backport the PCI resource code
and the problem seemed solved by using yaboot for me. I didn't
fully realize the Wallstreet doesn't have this option.
Instead of walking the whole device tree, I hope to get away with just
picking a free area (assuming pci_dev->base_address[i] == 0 means free)
instead. But I won't get to it before the weekend. If BenH implements a
cleaner way, the better.
Well, since this concerns only one machine, in a given configuration, I
beleive it's safe to just hard-code a new mappping we know won't conflict.
How does OF sets up the mapping of the ATI on the Lombard ? Maybe we can
just stuff that in some fixup routine for the wallstreet...
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-28 00:05:47
Michael Schmitz wrote:
quoted
Hmm, if change the driver to "ati", am I also supposed the change the
device node Option to "ati", ie 'Option "ati" "/dev/fb0"'? I never
tried that.
Certainly not, "fbdev" if anything.
Nope, the syntax should be OK. Question is does the ati driver parse that
option if fb_open_pci is used.
I just rsynced Ani's tree, and the ati driver doesn't. Ani, why not?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
So here we have three fb devices in the kernel (you could check with
fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
to cope. You specify the PCI bus ID but not the corresponding framebuffer
device node - I heard someone mention this was possible when I was
fighting the Lombard crashes, could anyone point out the syntax to use
there?
If we can't specify the fb node XFree will have to probe for it (Geert
mentioned an easy way to do that: open the device and compare
pScrn->memPhysBase or fPtr->fix.smem_start to the PCI base address).
Besides, the current fbdev_open_pci() can't cope with multiple cards of the
same type, and doesn't recognize ATI Mach64.
BTW Geert: why is fPtr->fboff calculated from fix.smem_len not
fix.smem_start while pScrn->fbOffset is calculated from fix.smem_start?
That's indeed incorrect. But it's not the only bug in that part of the code
:-)
Hmmm... I just noticed I kept that bug in my version...
For reference, these are my (untested) patches...
Michel, I'll send you a diff relative to my previous version.
diff -urN michel/fbdevhw.c geert-3/fbdevhw.c
@@ -86,8 +86,10 @@char*device;intfd;void*fbmem;-intfboff;+unsignedintfbmem_len;+unsignedintfboff;void*mmio;+unsignedintmmio_len;/* current hardware state */structfb_fix_screeninfofix;
@@ -194,7 +198,7 @@var->sync|=FB_SYNC_VERT_HIGH_ACT;if(mode->Flags&V_PCSYNC)var->sync|=FB_SYNC_COMP_HIGH_ACT;-#if 0+#if 1 /* Badly needed for PAL/NTSC on Amiga (amifb)!! [geert] */if(mode->Flags&V_BCAST)var->sync|=FB_SYNC_BROADCAST;#endif
@@ -222,7 +226,7 @@mode->Flags|=var->sync&FB_SYNC_HOR_HIGH_ACT?V_PHSYNC:V_NHSYNC;mode->Flags|=var->sync&FB_SYNC_VERT_HIGH_ACT?V_PVSYNC:V_NVSYNC;mode->Flags|=var->sync&FB_SYNC_COMP_HIGH_ACT?V_PCSYNC:V_NCSYNC;-#if 0+#if 1 /* Badly needed for PAL/NTSC on Amiga (amifb)!! [geert] */if(var->sync&FB_SYNC_BROADCAST)mode->Flags|=V_BCAST;#endif
@@ -247,28 +251,6 @@/* -------------------------------------------------------------------- *//* open correct framebuffer device */-staticstructfb2pci_entry{-CARD32id;-CARD32vendor;-CARD32chip;-}fb2pci_map[]={-{FB_ACCEL_MATROX_MGA2064W,PCI_VENDOR_MATROX,PCI_CHIP_MGA2064},-{FB_ACCEL_MATROX_MGA1064SG,PCI_VENDOR_MATROX,PCI_CHIP_MGA1064},-{FB_ACCEL_MATROX_MGA2164W,PCI_VENDOR_MATROX,PCI_CHIP_MGA2164},-{FB_ACCEL_MATROX_MGA2164W_AGP,PCI_VENDOR_MATROX,PCI_CHIP_MGA2164_AGP},-{FB_ACCEL_MATROX_MGAG100,PCI_VENDOR_MATROX,PCI_CHIP_MGAG100},-{FB_ACCEL_MATROX_MGAG200,PCI_VENDOR_MATROX,PCI_CHIP_MGAG200},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128RE},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128RF},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128RK},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128RL},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128PF},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128LE},-{FB_ACCEL_ATI_RAGE128,PCI_VENDOR_ATI,PCI_CHIP_RAGE128LF},-{FB_ACCEL_3DFX_BANSHEE,PCI_VENDOR_3DFX,PCI_CHIP_VOODOO3},-};-#define FB2PCICOUNT (sizeof(fb2pci_map)/sizeof(struct fb2pci_entry))-/* try to find the framebuffer device for a given PCI device */staticintfbdev_open_pci(pciVideoPtrpPci,char**namep)
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/
On Thu, 28 Sep 2000, Michel [iso-8859-1] Dδnzer wrote:
Michael Schmitz wrote:
quoted
Nope, the syntax should be OK. Question is does the ati driver parse that
option if fb_open_pci is used.
I just rsynced Ani's tree, and the ati driver doesn't. Ani, why not?
Only the fbdev and glint drivers use this option, all the others get the
fbdev device from the BusID option, unfortunately fbdev_open_pci() will open
the *first* device that matches the device so if you have more than 2
devices it will map the first one again with bad results.
Geert posted recently a patch recently for fbdev_open_pci so it will do the
right thing (i never tested it though) give it a try.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-28 17:55:41
quoted
Instead of walking the whole device tree, I hope to get away with just
picking a free area (assuming pci_dev->base_address[i] == 0 means free)
instead. But I won't get to it before the weekend. If BenH implements a
cleaner way, the better.
Well, since this concerns only one machine, in a given configuration, I
beleive it's safe to just hard-code a new mappping we know won't conflict.
It at least concerns Wallstreet and Lombard (Pismo has a r128?). Hardcode
and double check it's free, that be it then.
How does OF sets up the mapping of the ATI on the Lombard ? Maybe we can
just stuff that in some fixup routine for the wallstreet...
Broken (VRAM included both LE and BE aperture, and MMIO overlaps the end
of the LE aperture (where MMIO actually shows up even without the
separate mapping. I know nothing about decoding priorities though).
atyfb (and, by extension, the fbdev driver _and_ the ati driver with
UseFBDev) use the MMIO alias at the end of the BE aperture (which is why
we reserve that four k segment to prevent it from being used for
framebuffer).
Sketch:
V -- free --- | VRAM LE ........... (MMIO) | VRAM BE ........... (MMIO) |
M | MMIO |
V = PCI BAR 0 for VRAM, M = PCI BAR 2 for MMIO (not in the OF device
tree) IIRC. BAR 1 is the IO mapping.
Can't give you the exact addresses off the cuff, but I've described it
here before a week or two after the 4.01 release.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-29 09:03:06
Kostas Gewrgiou wrote:
On Thu, 28 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
Michael Schmitz wrote:
quoted
Nope, the syntax should be OK. Question is does the ati driver parse
that option if fb_open_pci is used.
I just rsynced Ani's tree, and the ati driver doesn't. Ani, why not?
Only the fbdev and glint drivers use this option, all the others get the
fbdev device from the BusID option, unfortunately fbdev_open_pci() will open
the *first* device that matches the device so if you have more than 2
devices it will map the first one again with bad results.
Geert posted recently a patch recently for fbdev_open_pci so it will do the
right thing (i never tested it though) give it a try.
Yep, I've got that in my local CVS tree and will submit it when we've ironed
out the remaining issues.
However, I think the "fbdev" option should also be available, it might be more
straightforward for some users than the bus ID. Would it also be possible to
go the opposite way fbdev -> pcidev and then claim the PCI device?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-29 10:35:30
Michel Dänzer wrote:
quoted
quoted
quoted
Because I'm experiencing this as well with fbdev, and the problem is
the same for all Apple non-accelerated framebuffers (control,
platinum, valkyrie), AFAICT. So it would be helpful if this problem
would get
For what it's worth: I have *no* problem with Franz's 4.0.1 RPMs and a
valkyrie display. It works for 8 bit color without and for 15 bit color
with a modeline in XFConfig. It doesn't work for 16 bit color (and more
than that is out of reach for valkyrie with 1MB VRAM).
The X 4 fbdev code used to pass the depth incorrectly in the PUTSCREENINFO
ioctl. I have a fix for that too and will submit it with the rest.
quoted
quoted
quoted
fixed once and for all. FWIW, no propblem with XF3.x.
That's why I'm working with Geert, who wrote the 3.x code :)
I'm currently having problems with the MMIO mapping of his code, will
investigate. The Vidmem mapping works for me (although it also worked
before), so any volunteers for testing please line up to me for a patch
:)
I'd volunteer if you provide a precompiled server binary. For compiling
XFree86 myself, my machine is too slow.
This warning should be obsolete now, I've updated the tarball and for those
who like to build themselves I've also put up a diff:
http://n.ethz.ch/student/daenzerm/download/X-fbdev.diff.gz
Please test and let me know how it works, if noone complains I'll submit it to
XFree86.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-29 12:02:37
Geert Uytterhoeven wrote:
On Wed, 27 Sep 2000, Michael Schmitz wrote:
quoted
So here we have three fb devices in the kernel (you could check with
fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
to cope. You specify the PCI bus ID but not the corresponding framebuffer
device node - I heard someone mention this was possible when I was
fighting the Lombard crashes, could anyone point out the syntax to use
there?
If we can't specify the fb node XFree will have to probe for it (Geert
mentioned an easy way to do that: open the device and compare
pScrn->memPhysBase or fPtr->fix.smem_start to the PCI base address).
Besides, the current fbdev_open_pci() can't cope with multiple cards of the
same type, and doesn't recognize ATI Mach64.
From: R Shapiro <hidden> Date: 2000-09-29 14:17:01
Michel Dänzer writes:
> Mr Shapiro, please test if this makes the ati driver work in your
> triple-head box.
No luck.
Booting with BootX, the ati driver still hoses linux when X starts. I
can send you (or post) the log. Worse, using the new fbdev driver
itself produces a confused display on the 2nd and 3rd monitor, with
images appearing multiple times.
Booting with miBoot, any attempt to run X with either driver still
hoses linux.
I don't have quik booting working yet, so I couldn't test that.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-29 14:34:44
> Mr Shapiro, please test if this makes the ati driver work in your
> triple-head box.
No luck.
Booting with BootX, the ati driver still hoses linux when X starts. I
That's not fixable at the X level (well, technically it is but I can't
figure out how and the X people refuse to consider that method). You will
need to boot via OF and yaboot (or equivalent oldworld) directly, not via
BootX to avoid the PCI resource conflict. Alternative: fix the resource
conflict at the kernel level, new patch by me in the works.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-29 14:55:30
R Shapiro wrote:
Michel Dänzer writes:
> Mr Shapiro, please test if this makes the ati driver work in your
> triple-head box.
No luck.
Booting with BootX, the ati driver still hoses linux when X starts. I
can send you (or post) the log. Worse, using the new fbdev driver
itself produces a confused display on the 2nd and 3rd monitor, with
images appearing multiple times.
Oh no :( Can you please describe the corruptness more?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Michel> This warning should be obsolete now, I've updated the tarball
I tried your binary with ati driver from
penguinppc.org::xfree86-pmac on iMac revB. It worked for 15
bit color but did not used to work for 24 bit color. After
installation of your binary, it works well!!
Result of x11perf --scroll500 under your binary + ati driver;
Sync time adjustment is 0.2300 msecs.
300 reps @ 19.5974 msec ( 51.0/sec): Scroll 500x500 pixels
300 reps @ 19.4797 msec ( 51.3/sec): Scroll 500x500 pixels
300 reps @ 19.3297 msec ( 51.7/sec): Scroll 500x500 pixels
300 reps @ 19.3649 msec ( 51.6/sec): Scroll 500x500 pixels
300 reps @ 19.1724 msec ( 52.2/sec): Scroll 500x500 pixels
1500 trep @ 19.3888 msec ( 51.6/sec): Scroll 500x500 pixels
I know this is not so fast especially for r128 people, but
for me this is great improvement.
Thanks a lot.
Kohkichi Hosoda
E-mail address: khosoda@venus.dti.ne.jp
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Michel> This warning should be obsolete now, I've updated the tarball
I tried your binary with ati driver from
penguinppc.org::xfree86-pmac on iMac revB. It worked for 15
bit color but did not used to work for 24 bit color. After
installation of your binary, it works well!!
That's great! How did it fail before?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-29 15:33:52
Michael Schmitz writes:
> That's not fixable at the X level (well, technically it is but I can't
> figure out how and the X people refuse to consider that method). You will
> need to boot via OF and yaboot (or equivalent oldworld) directly
I tried miBoot. Is that equivalent from the X perspective? I can't
get X to run with any driver at all, old or new, when the machine is
booted with miBoot.
I haven't yet found a way to quik-boot this ide-only beige g3. I've
been given some suggestions of things to try, but they guy who
actually owns this machine needs to do real work on it today. I don't
know when I'll get to play with OF/quik booting.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
That's not fixable at the X level (well, technically it is but I can't
figure out how and the X people refuse to consider that method). You will
need to boot via OF and yaboot (or equivalent oldworld) directly, not via
BootX to avoid the PCI resource conflict. Alternative: fix the resource
conflict at the kernel level, new patch by me in the works.
Hmm if you think that its fixable in the X level then we should give it
a try, i can't see how though unless we get X to accept this allocations
(are they legal ?). Any relocation is going to break the fbdev side since
there is no way to inform the atyfb driver about this changes.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-29 16:39:42
Kostas Gewrgiou wrote:
On Fri, 29 Sep 2000, Michael Schmitz wrote:
quoted
That's not fixable at the X level (well, technically it is but I can't
figure out how and the X people refuse to consider that method). You will
need to boot via OF and yaboot (or equivalent oldworld) directly, not via
BootX to avoid the PCI resource conflict. Alternative: fix the resource
conflict at the kernel level, new patch by me in the works.
Hmm if you think that its fixable in the X level then we should give it
a try, i can't see how though unless we get X to accept this allocations
(are they legal ?).
I don't know, but I'm pretty sure that Egbert or whoever made the code disable
it has done so for a reason.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, 29 Sep 2000, Michel [iso-8859-1] Dδnzer wrote:
However, I think the "fbdev" option should also be available, it might be more
straightforward for some users than the bus ID. Would it also be possible to
go the opposite way fbdev -> pcidev and then claim the PCI device?
It should be possible to do it, i'll give it a try once i have some free
time. We could get away from the busID requirement in the fbdev driver then
(its very easy to missmatch busID/fbdev and nothing can detect this error)
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-29 17:23:16
Michael Schmitz writes:
> That's not fixable at the X level (well, technically it is but I can't
> figure out how and the X people refuse to consider that method). You will
> need to boot via OF and yaboot (or equivalent oldworld) directly, not via
> BootX to avoid the PCI resource conflict.
I just spent an hour on this. Sorry guys, but I can't get linux to
quik-boot off the ide drive and yaboot doesn't work on this platform.
It's either BootX or miBoot.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-29 17:27:44
Michel Dänzer writes:
> Oh no :( Can you please describe the corruptness more?
I'm sure there's a technical term for it but I'm afraid I don't know
what it is. The main monitor is ok, but on the other two, whatever
gets drawn (the mouse cursor, say, or a popup menu, appears where it
should, and then again a little left and down, and then again a little
more left and down, etc etc.
Does that make sense? Fwiw the main monitor is Rage II, while the
other two are Rage Pro.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-29 19:33:35
Michael Schmitz writes:
> That's not fixable at the X level (well, technically it is but I can't
> figure out how and the X people refuse to consider that method). You will
> need to boot via OF and yaboot (or equivalent oldworld) directly
I tried miBoot. Is that equivalent from the X perspective? I can't
Show me your lspci -vv log :-)
Re: OF device tree, there's a tool named lsprop you need to run on
/proc/device_tree (see Paul's or BenH's pages for the source or ask me
for a copy).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-29 19:40:13
quoted
That's not fixable at the X level (well, technically it is but I can't
figure out how and the X people refuse to consider that method). You will
need to boot via OF and yaboot (or equivalent oldworld) directly, not via
BootX to avoid the PCI resource conflict. Alternative: fix the resource
conflict at the kernel level, new patch by me in the works.
Hmm if you think that its fixable in the X level then we should give it
a try, i can't see how though unless we get X to accept this allocations
(are they legal ?). Any relocation is going to break the fbdev side since
there is no way to inform the atyfb driver about this changes.
I think it is fixable at the X PCI probe level, I just don't know how to
do it (can you say entangled web of maze?).
Another idea (strictly in the Unix tradition): X knows how to mess up the
PCI config from user space so why shouldn't we, before X gets a shot at
it? 'Just' write the correct mapping to the offending BAR from a rc
script. Obvious drawback: the kernel OF tree won't be updated, and the
kernel can't safeguard against insane BAR settings (at least I can't tell
how that would work, one of the PCI gurus please enlighten me). Makes a
nice local DOS tool.
(Don't tell me that's been done already - something like PCI PNP utils
for Linux, anyone?)
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-29 19:45:38
> That's not fixable at the X level (well, technically it is but I can't
I just spent an hour on this. Sorry guys, but I can't get linux to
quik-boot off the ide drive and yaboot doesn't work on this platform.
It's either BootX or miBoot.
Ok already, I'm working on it.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-29 21:04:38
> Show me your lspci -vv log :-)
The result in miBoot is the same as in BootX:
00:0d.0 VGA compatible controller: ATI Technologies Inc 215GI [Mach64 GI] (rev 5c)
Interrupt: pin A routed to IRQ 23
Region 0: Memory at 84000000 (32-bit, prefetchable)
Region 1: I/O ports at 0400 [disabled]
Region 2: Memory at 81801000 (32-bit, non-prefetchable)
00:0f.0 VGA compatible controller: ATI Technologies Inc 215GI [Mach64 GI] (rev 5c)
Interrupt: pin A routed to IRQ 25
Region 0: Memory at 83000000 (32-bit, prefetchable)
Region 1: I/O ports at 0400 [disabled]
Region 2: Memory at 81800000 (32-bit, non-prefetchable)
00:12.0 VGA compatible controller: ATI Technologies Inc 215GT [Mach64 GT] (rev 9a)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at 82000000 (32-bit, non-prefetchable)
Region 1: I/O ports at 0400 [disabled]
That does indeed look legit to me, unless XFree decides to disable two out
of three because the (disabled) IO regions are identical.
Assuming the MMIO size is 0x1000 (which is the case for me).
Did the machine survice XFree86 -probeonly? If so, what's the mappings
after that?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: R Shapiro <hidden> Date: 2000-09-30 01:40:02
Michael Schmitz writes:
> Did the machine survice XFree86 -probeonly?
Not with the ati driver. I didn't test it with the fbdev driver.
--
rshapiro@bbn.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I tried your binary with ati driver from
penguinppc.org::xfree86-pmac on iMac revB. It worked for
15 bit color but did not used to work for 24 bit color.
After installation of your binary, it works well!!
Michel> That's great! How did it fail before?
Well, I'm confused. When I tried 24 bit color with default
fbdev and ati a week ago, it did not work. Now, however, it
works well although it is slower than 24 bit color with your
binary.
Result of x11perf --scroll500 with default fbdev and ati;
Sync time adjustment is 0.1741 msecs.
200 reps @ 26.9526 msec ( 37.1/sec): Scroll 500x500 pixels
200 reps @ 27.0679 msec ( 36.9/sec): Scroll 500x500 pixels
200 reps @ 27.0197 msec ( 37.0/sec): Scroll 500x500 pixels
200 reps @ 27.1500 msec ( 36.8/sec): Scroll 500x500 pixels
200 reps @ 26.9818 msec ( 37.1/sec): Scroll 500x500 pixels
1000 trep @ 27.0344 msec ( 37.0/sec): Scroll 500x500 pixels
With yur binary, it is around 1.5 times faster, as described
in the previous mail.
It's weird, but I can't figure out why default fbdev started
to work with 24 bit color again. According to my poor
memory, XFree86.0.log used to show "Fatal server error:
failed to initialize core devices" in the last part,
although I'm not sure.
Anyway, thanks a lot for providing a better driver.
Kohkichi Hosoda
E-mail address: khosoda@venus.dti.ne.jp
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
That's not fixable at the X level (well, technically it is but I can't
figure out how and the X people refuse to consider that method). You will
need to boot via OF and yaboot (or equivalent oldworld) directly, not via
BootX to avoid the PCI resource conflict. Alternative: fix the resource
conflict at the kernel level, new patch by me in the works.
Hmm if you think that its fixable in the X level then we should give it
a try, i can't see how though unless we get X to accept this allocations
(are they legal ?). Any relocation is going to break the fbdev side since
there is no way to inform the atyfb driver about this changes.
I think it is fixable at the X PCI probe level, I just don't know how to
do it (can you say entangled web of maze?).
Another idea (strictly in the Unix tradition): X knows how to mess up the
PCI config from user space so why shouldn't we, before X gets a shot at
it? 'Just' write the correct mapping to the offending BAR from a rc
script. Obvious drawback: the kernel OF tree won't be updated, and the
kernel can't safeguard against insane BAR settings (at least I can't tell
how that would work, one of the PCI gurus please enlighten me). Makes a
nice local DOS tool.
(Don't tell me that's been done already - something like PCI PNP utils
for Linux, anyone?)
Hmm fixing the resources from userland wont help you, you have to do it
before atyfb starts up. If i remember right from your logs X didn't had
any problems doing the relocation.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-09-30 15:05:55
R Shapiro wrote:
Michel Dänzer writes:
> Mr Shapiro, please test if this makes the ati driver work in your
> triple-head box.
No luck.
Booting with BootX, the ati driver still hoses linux when X starts. I
can send you (or post) the log. Worse, using the new fbdev driver
itself produces a confused display on the 2nd and 3rd monitor, with
images appearing multiple times.
I've got something new to try:
http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.diff
Don't expect it to fix your problems, but one never knows... And if it still
doesn't work, please send me the logs privately.
And I'd be really interested to hear from the people with weird hardware if
this works for them.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/