Red Hat Bugzilla – Bug 36682
(ATI Rage 128 pro PF / mga g200) KDE 3D screensavers fail
Last modified: 2007-04-18 12:32:44 EDT
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. Reproducible: Always 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 only.
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 CPU.
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 except Morph3d lock-up XFree86 in full-screen mode in about a second after start. Xscreensavers WORK fine! From KDE bugzilla, I found out that these screensavers use some sort of double-buffering, the lock-ups look suspiciously like ones due to lack of video ram (indeed, windowed demos do not lock up. To reproduce the problem on 32 MB card one should use some crazy resolution, I guess.
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 KDE screensavers. 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 screen. I have seen this problems with both Xfree86 4.0.3 and 4.0.99.3.
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 kde-devel list. It is KDE or Qt problem reassign this bug back to bero@redhat.com, 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 analysis. *** This bug has been marked as a duplicate of 73827 ***