Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 36682 - (ATI Rage 128 pro PF / mga g200) KDE 3D screensavers fail
(ATI Rage 128 pro PF / mga g200) KDE 3D screensavers fail
Status: CLOSED DUPLICATE of bug 73827
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Mike A. Harris
Aaron Brown
:
Depends On:
Blocks: screensaver
  Show dependency treegraph
 
Reported: 2001-04-19 15:58 EDT by Alexei Podtelezhnikov
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-14 02:44:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XFree86 under influence of two kpipes.kss, log for g200 (22.37 KB, text/plain)
2001-07-13 18:08 EDT, Alexei Podtelezhnikov
no flags Details

  None (edit)
Description Alexei Podtelezhnikov 2001-04-19 15:58:16 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.
Comment 1 Alexei Podtelezhnikov 2001-04-19 16:17:37 EDT
Just checked - everything works on G400. Thus, this is related to kss on r128
only.
Comment 2 Aaron Brown 2001-04-19 16:30:05 EDT
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.

Comment 3 Alexei Podtelezhnikov 2001-04-19 17:50:10 EDT
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.
Comment 4 Bernhard Rosenkraenzer 2001-04-20 18:21:29 EDT
Since it's specific to one piece of hardware, it's either an X bug or a local 
installation issue. Reassigning.
Comment 5 Markku Kolkka 2001-04-23 14:28:09 EDT
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.
Comment 6 Alexei Podtelezhnikov 2001-05-04 21:31:01 EDT
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. 

Comment 7 Mike A. Harris 2001-05-22 06:44:27 EDT
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.
Comment 8 Alexei Podtelezhnikov 2001-05-22 14:09:29 EDT
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.
Comment 9 Mike A. Harris 2001-06-14 23:07:18 EDT
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.
Comment 10 Alexei Podtelezhnikov 2001-06-18 04:11:51 EDT
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.
Comment 11 Alexei Podtelezhnikov 2001-07-13 18:02:16 EDT
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.
Comment 12 Alexei Podtelezhnikov 2001-07-13 18:09:00 EDT
Created attachment 23567 [details]
XFree86 under influence of two kpipes.kss, log for g200
Comment 13 Mike A. Harris 2001-08-14 02:43:18 EDT
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..
Comment 14 Mike A. Harris 2002-09-11 17:51:32 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.