| Summary: | [915gm xvideo] partially obscuring an xvideo output window causes Xserver hang | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Dag Bakke <dag> | ||||||||
| Component: | Driver/intel | Assignee: | Wang Zhenyu <zhenyu.z.wang> | ||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | ||||||||||
| Version: | git | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 15933 [details]
xorg.conf
Created attachment 15934 [details]
dmesg
I can't see your issue on 915G here, with gnome and mplayer. I tested with xserver-1.4 and xserver-1.5. Anywhere I can test your video clip? How about test it in other wm like twm, etc.? Good point. Will do. I can no longer recreate the problem, thus tagging the bug WORKSFORME. :-) Using: - kernel 2.6.25-gentoo - head of xf86-video-intel @ 2c135ef8ac40f8e7cd071de7414adfae019f9198 - mplayer 1.0_rc2_p26454-r2 ...and the rest as noted above. The performance is *highly* impressive. The mediafile is x264-encoded at 960x528. Fairly demanding. The CPU mostly ticks at 800MHz and any clock change is completely invisible and -audible in audio/video. Smoking! Does it work in xf86-video-intel-2.3-branch too? I tried with x11-drivers/xf86-video-i810-2.2.99.903 from gentoos portage. IT appears to work the same as git HEAD. I see some oddball interaction with icewm, when alt-tab'ing "too much", but it does not instantaneously hang, as was the case initially. This is the case with git HEAD as well. Audio/video may stutter a bit, but appears to recover after a little while. At this time, I am seriously starting to consider icewm being buggy, as alt-tab'ing over a vncviewer on an entirely different machine hangs the xserver in a similar way as in my initial report. Running icewm 1.2.35 on both machines. I did eventually manage to make the xserver hang again. Excessive alt-tab'ing on top of mplayer or tightvnc would do it. Some analysis with assistance from MrCooper and others on irc lead me to #13511, for which there is a patch in #14449. This patch is not in th xserver 1.4 tree, although it is included in HEAD and 1.5. I think this may have been two separate bugs, as the crash initially was instant. With updated bits it was reliably reproducable, although not instant. Tagging the bug as a duplicte of #13511. *** This bug has been marked as a duplicate of bug 13511 *** |
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.
Created attachment 15932 [details] Xorg.0.log xf86-video-intel : 90d6b178473ba32cf66e6e654e608cb4374e4a19 drm/libdrm : 1ad1bd5bd95db71500edfcea8b46421d7f3cdb15 xserver:1.4.0.90-r3 mesa: 7.0.2 kernel: 2.6.25-rc9 distro: gentoo hw: mini-pc Manufacturer: AOpen Product Name: i915GMx-F I am trying out latest git and video playback. My P-M 1.7G/915GM based system can now play 960x528 24bpp 23.976 fps without skipping. Thank you very much. But anything which partially obscures the video output window will cause playback to freeze and the Xserver to consume 99+ % cpu. Nothing crashes, there are no messages to dmesg or Xorg.0.log. mplayer can be terminated with ctrl-c, and Xorg with a kill -9. The typical testcase is playing a movie in a windowed mplayer instance, and use alt-tab to cycle through the open programs. (typically just mplayer and a single xterm). The alt-tab 'window' shows up in the middle of the video window. (icewm), and this appears to cause the xserver to become awfully busy and hang video playback. top tells me that I have sufficient CPU to play back the video. Using 'textured video' or 'video overlay' makes no difference. Using a less taxing media file makes no difference, so it doesn't appear to be a bandwidth issue. And finally, attaching gdb to the xserver provides no 'gdb>' prompt when it loops. I'll admit to be awfully green when it comes to gdb, though. I will happily provide further details as needed.