From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-6.2.1 i686)
I was only able to see only Morph3D running fine on r128 system with DRI
enabled. Others just produce blank screen. The problem goes back to 7.1
betas. Supprisingly, corresponding xscreensaver modules are running fine.
Steps to Reproduce:
1. goto KDE Kontrol
2. test 3D screensavers (under look and feel)
3. or run them any other way you can on Rage 128 PF (AiW)
Actual Results: All but morph3d produce blank screen. Good thing they
don't consume CPU time either. They are just idle I guess.
Expected Results: They should be just as good as xscreensaver modules.
Just checked - everything works on G400. Thus, this is related to kss on r128
I don't have any problems on a AGP Rage 128P, non AiW.
Looks like this might be an AiW problem.
What bus does your AiW use? I ran with a PCI AiW for about a third of the
testing cycle, and don't remember any problems (except that 3D was slow, which
is why I put the AGP card in...) If it's PCI, I'll throw mine in tonight and
see if I can duplicate the bug.
This happens on 16 Mb All-in-Wonder 128 PRO (AGP). This is an Athlon system with
MSI's K7Pro motherboard with AMD 751/756 chipsets, 1x AGP. 3D-acceleration of
xscreensavers is very fast and stable.
Since it's specific to one piece of hardware, it's either an X bug or a local
installation issue. Reassigning.
I see this same bug on a non-AiW Rage 128 card, XPert2000Pro (32 MB, ATI Rage
128 Pro PF AGP). Motherboard is MSI K7T Pro2 (VIA KT133 chipset), Duron 750
This does look like a problem with KDE screensavers rather than XFree86 problem.
Now, using 16 Mb g200 with XFree86-4.0.3-11 or later, all 3D KDE screensavers
Morph3d lock-up XFree86 in full-screen mode in about a second after start.
From KDE bugzilla, I found out that these screensavers use some sort of
the lock-ups look suspiciously like ones due to lack of video ram (indeed,
do not lock up. To reproduce the problem on 32 MB card one should use some crazy
If you use DRI, you need to do so in 16 bit depth. Also, you can not use
ultra-high res, or there isn't enough memory for DRI to work. X will let you
create bad configurations and will try to use them also.
Just for testing purposes. Set your resolution to 640x480 or 800x600, and
set it to depth 16 (no virtual screen). Does the problem go away? If so,
your card doesn't have enough memory to run at the res/depth you are in
with DRI enabled.
I am using reasonable resolution of 1280x1024x16bpp on 16 Mb g200 or Rage 128
PF. I want to emphasize that OpenGL Xscreensavers work perfectly well, thus,
confirming the suitability of this resolution for 3d acceleration. The problem
exists with 3d KDE screensavers ONLY.
It's true, that at lower resolution (or windowed demo) mode KDE screensavers
work on g200. In fact I can cause the X lock-up just by resizing the window
beyond certain size. Thus, I think it's a problem with bad videoram usage in
On Rage 128 PF, the 3d KDE screensavers just fail, producing blank screen: no
segfaults, no core dumps, no CPU time consumption - just an idle task of black
I have seen this problems with both Xfree86 4.0.3 and 220.127.116.11.
Just as a test only - put your X in 640x480x16 mode and try them out again.
Does it work now? That will help track the problem down. Try at 800x600
also. make sure you are not using a virtual screen.
Also make sure you are using the rawhide kernel. There was a problem with
DRI on r128 that is fixed in our rawhide kernel.
I use the fixed kernel. On Rage128pro 3D KDE screensavers don't work. Could you
explain me why xscreensavers happen to work perfectly then?
I suspect this is because Qt is compiled with GL support when it shouldn't be.
3D stuff should be left entirely for X. At least this is the answer I got on
It is KDE or Qt problem reassign this bug back to firstname.lastname@example.org, where I
originally filed it.
It seems that I found the problem. At least, now I have a better description.
The following wrong behaviour has been verified on g200 at the moment.
Basically, all KDE 3d-screensavers work on 16 Mb g200 at a reasonable
resolution of 1280x1024x16bpp. What doesn't work is the "Test" button in KDE
Control Center. Pressing this button start 2 (two!) instances of kpipes.kss,
for example. This is deadly. It hangs XFree86 - no responce to keyboard or
mouse. Remote "init 3" remains unfinished untill I kill both kpipes.kss!
Without any "init 3", the remotely killing the both instances of kpipes.kss
just revives X. Not really though, each subsequent run of "gears" hangs X
again. Killing "gears" - back on track.
I'm attaching log bellow, nothing interesting is there though. It's been
recorded during the hang, but contains no indication of it.
This problem was observed with kdm and just by startx alike.
Created attachment 23567 [details]
XFree86 under influence of two kpipes.kss, log for g200
I believe I've found the problem to be buggy VIA motherboard BIOS's.
Please check your manufacturer's website and download and install
any BIOS upgrades for your motherboard. This should fix problems
on VIA chipsets, especially Athlon boards.
If the problem persists, which I doubt, please change status back
to REOPENED or ASSIGNED, etc..
This bug has been in MODIFIED state for over a year with no response
as to wether the suggestions worked or not. I would ordinarily close
this as resolved now without hearing back however we've discovered
a DRM bug that is most commonly triggered by screensavers, and we
believe most of the screensaver-locks-X bugs reported are due to this
now. I'm closing this as a DUPE of our tracker bug. Please read
the text of the dupe bug, and test out the suggestions there. If this
does not fix the problem, please reopen this bug report for continued
*** This bug has been marked as a duplicate of 73827 ***