I just tried debian's RC3 xorg server + intel driver packages, and it works much better than RC2. I have however still issues with XV. In the following I'm always using the attached xorg.conf for running X on my laptop. I first try to run the X server with no connected external VGA screen, Xorg.0.log.LVDS is attached and xvinfo produces the attached information. I then try to mplayer a movie. It opens a black window, waits one second, then the window turns blue and mplayer really starts playing the movie, but the window keeps being blue, the movie isn't shown in it. The mplayer output is attached as mplayer-out. Using mplayer -vo x11 works fine. Sometimes it's even worse: when I quit mplayer, the display freezes. The ACPI button lets me nicely shut down the box and get the end of the attached Xorg.0.log.LVDS. Note that I never asked for a VT switch. Same results with Xine. Now, if I connect an external screen and run xrandr --output VGA --auto, the external screen properly shows the movie (while the LVDS still shows a blue window). BTW, how can I request for the movie to show up on the LVDS instead of the VGA (or even both)? Now, if I run xrandr --output VGA --below LVDS, the window is always blue, whether I put it on VGA or on LVDS. Last issue, sometimes when I for instance start X with external VGA connected and then run xrandr --output VGA --below LVDS, the box completely locks up without anything more written to Xorg.0.log. You may see the very few differences between Xorg.0.log.LVDS+VGA-GOOD and Xorg.0.log.LVDS+VGA-BAD.
Created attachment 9365 [details] My Xorg.conf
Created attachment 9366 [details] Xorg Log in LVDS-only mode, terminating with a crash
Created attachment 9367 [details] xvinfo output
Created attachment 9368 [details] mplayer output
Created attachment 9369 [details] Xorg log with dual screen, NOT hanging on xrandr desktop extension request
Created attachment 9370 [details] Xorg log with dual screen, hanging on xrandr desktop extension request
Oops, sorry, I spoke too fast. I still have the warning and the hang.
(In reply to comment #7) > Oops, sorry, I spoke too fast. I still have the warning and the hang. Was this meant for bug 10467?
Eergl, yes. I wonder how it went to this bug...
I appear to be experiencing the same bug reported here, still occuring with video-intel 2.0rc4 (debian 1.9.94-1). Xv output (in vlc, for instance) produces a blue window and then freezes the entire system. xrandr 1.2.0 also freezes the system hard by running "xrandr --auto" to update the current set of connected monitors and then running "xrandr -q". Likewise "xrandr -q --verbose" freezes the system. The freezes appear to be occuring too quickly for any error statements to be written to the log files.
The freezes seem to have been cured in video-intel 2.0RC5. The blue video windows under Xv are still there. Will be interesting to see if the Xorg mailing list thread titled "xf86-video-intel: XV using the wrong pipe" clears it up.
My apologies, in the previous comment I should have said that I'm not seeing the freezes with xserver 1.3RC5 (1.2.99.905), with video-intel still at 2.0RC4 (1.9.94).
Could someone check if the patch in bug #10645 clears up this bug? If it does, this should be marked as a dup.
With the two patches from bug #10645, I now always have the XV overlay on the LVDS, but never on the VGA (which is kind of problematic for a beamer-based home cinema :) ). I haven't yet been able to reproduce the crash.
However, the lock on xrandr calls still happens. I'll fill another bug entry for that.
Same here on my HP laptop with an i855. Do the patches from bug #10645 need more testing? Anything else I can provide? Thanks.
I don't seem to have problems any more with today's git (which has recent overlay fixes), can be marked as Fixed for me.
+1 Fixed for me as well
I also confirm this working on the latest git version. Running Debian unstable/ xserver 1.3.0 and intel git driver. I'll dare to mark this as fixed. As usual if anyone has any problem, please reopen the bug.
I'm still experiencing the Xv bug after installing git up to commit ff8c8cb869a3c780dbd826f7c94f06e4f3fda6af (25/5/07). That is, videos in vlc play with a blue window. It was working successfully when I tested the new driver. The only difference I can think of is that now I've resumed from an S4 hibernation. Those of you who reported it working, have tested after a hibernation cycle?
I, for one, never use any kind of suspend or hibernate (mainly to avoid those issues). It could be interesting to try and validate with and without suspend/hibernate to try and isolate the bug.
I never used hibernation indeed.
Well I would say that after 2007/05/27 git version I got this working, even after hibernating(suspend2) and/or suspend to ram. Well, I should add that this is true only when the kde composite/translucency manager is off (not enabled). The behaviour on those cases was weird since after some tests with mplayer and xine backends worked seldomly, but I didn't investigae further to get a rule for that. When disabling tranlucencies/tranparencies on KDE Xv related features worked as they should. I'll be careful about this thing in case I see anything strange,
Submitter reported this one fixed. (Anyone else, please open separate bugs instead of reopening this one)
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.