Bug 27464 - Mesa 7.8: screen/keyboard frozen when using menus in GLUT application
Summary: Mesa 7.8: screen/keyboard frozen when using menus in GLUT application
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200 (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2010-04-05 05:46 UTC by Zbigniew
Modified: 2014-02-26 08:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Mesa 7.8: screen/keyboard frozen when using menus in GLUT application (872 bytes, application/x-gzip)
2010-04-05 05:46 UTC, Zbigniew
Details
The requested xorg.log (38.14 KB, application/octet-stream)
2010-04-06 03:51 UTC, Zbigniew
Details

Description Zbigniew 2010-04-05 05:46:57 UTC
Created attachment 34670 [details]
Mesa 7.8: screen/keyboard frozen when using menus in GLUT application

The problem a bit similar to that formerly reported (Bug 27461) - use attached code, that I've found in GLUT tutorial. After compilation it can be started quite normally, so choose the corpse to draw (second menu point). After it'll appear in the window, now (important!) having pressed right mouse button traverse all three menu points "top-to-bottom" to highlight them all one-by-one. After the last menu point ("Quit") will be highlighted and left by mouse cursor, the corpse disappears, and the screen and keyboard will be locked.

It's not my code, so I'm not sure about ev. errors in coding - but it's very short, so it's easy to examine.
Comment 1 Zbigniew 2010-04-05 05:47:15 UTC
Tested using Kernel 2.6.32.10, Glibc 2.10.1, Gobolinux 0.14 (32-bit), Mesa  
7.8, Xorg 7.5, X-Server 1.7.6, IceWM 1.2.37, Pentium III/750, old mobo Intel 
BX-based, ATI Technologies Inc RV280 [Radeon 9200 PRO]
Comment 2 Pauli 2010-04-06 01:51:54 UTC
Sounds like 3D driver bug. Can you test 3D with kernel 2.6.33 and KMS enabled libdrm, xf86-video-ati and mesa? http://www.x.org/wiki/radeonBuildHowTo is ood source of information if you need to compile something.

Please attach your xorg.log.
Comment 3 Zbigniew 2010-04-06 03:51:30 UTC
Created attachment 34709 [details]
The requested xorg.log
Comment 4 Zbigniew 2010-05-26 08:48:57 UTC
(In reply to comment #2)
> Sounds like 3D driver bug. Can you test 3D with kernel 2.6.33 and KMS enabled
> libdrm, xf86-video-ati and mesa? http://www.x.org/wiki/radeonBuildHowTo is ood
> source of information if you need to compile something.

Today I made a test using newest kernel 2.6.34 with KMS enabled (of course, 
I've recompiled appropriate libs&drivers according to instructions from the page mentioned above), using driver xf86-video-ati-6.13.0.tar.bz2 (formerly it was version 12.4) - so I would to add to my bug report:

- there weren't any more "freezes" neither while switching desktops, nor when using WM's menu
- still there is heavy CPU load when displaying WireTeapot
- I noticed, that glxgears now shows about 710 FPS - formerly it was over 1000 FPS (why such radical slowdown?)
Comment 5 Zbigniew 2010-05-26 08:59:47 UTC
(In reply to comment #2)
> Sounds like 3D driver bug. Can you test 3D with kernel 2.6.33 and KMS enabled
> libdrm, xf86-video-ati and mesa?

I forgot to mention, that I'm using now Xorg-Server 1.7.7 (former was 1.7.6), configured WITHOUT two options, that was in use before:

--disable-dmx
--disable-secure-rpc

Is it possible, that the two options could have any influence on the problem reported (and perhaps on the lower actual FPS rate, when dmx and secure-rpc aren't disabled)?
Comment 6 smoki 2014-02-26 08:50:33 UTC
(In reply to comment #4)
> 
> - still there is heavy CPU load when displaying WireTeapot

 Today it use ZERO CPU :) tested with mesa 10.2... Overall no problem here at all now wit this example, so this bug can be closed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.