When playing a movie (either using MPlayer or Totem, both through XV), the Intel driver seems to want to output only on one pipe. On my laptop, LVDS is attached to pipe B, while VGA is attached to pipe A. When the XV overlay window is on the laptop screen, only the overlay color (blue) is shown, without output; when it is on an attached VGA output, XV output is shown there. Similarly, when the display is cloned, only the external VGA output shows, while the laptop display shows blue. When there are no external VGA outputs connected (i.e. only the laptop LCD panel), playing movies via XV shows just the overlay color. See as follows: - on clone: +------------------+ +------------------+ | | | | | external/VGA | | laptop/LVDS | | | | | +------------------+ +------------------+ displays here blue screen here - on mergefb: +------------------+ +------------------+ | | | | | external/VGA | | laptop/LVDS | | | | | +------------------+ +------------------+ overlay window here, displays here +------------------+ +------------------+ | | | | | external/VGA | | laptop/LVDS | | | | | +------------------+ +------------------+ overlay window here, blue screen
Created attachment 9601 [details] xvinfo(1) output Output from xvinfo(1) on my system.
Created attachment 9602 [details] lspci(8) output Output from lspci -vv
Created attachment 9603 [details] Xorg logfile
In src/i830_video.c, the pipe is selected via pPriv->pipe; however, this never is set to a value other than 0, which means only pipe A is ever selected. Previously, pPriv->pipe was set to pI830->pipe (which no longer exists as a member of _I830Rec).
Created attachment 9610 [details] [review] PATCH: Perform pipe selection on XV based on clip rect As I understand it, bug #10645 is caused by the XV code using just pipe 0 (A) instead of selecting the pipe based on where the clip rectangle is. The following patch introduces logic that checks where the clip rectangle really is and selects that pipe for display via XVideo. I've run this patch and it does display on the correct pipe for local LCD, but no output is given on external. Still debugging that.
My Git tree now is configured to turn on overlay debugging (i830_video.c:150 -- switched from '#if 0' to '#if 1'). The debugging output tells me that the code is clipping it when the XV overlay is on the external VGA (where external VGA is --right-of the LVDS) I've also noticed that when the LVDS is --right-of VGA (i.e. the VGA is at 0,0 of the merged framebuffer), the XV output does show on the external VGA but is clipped (I've been testing it with a 1440x900 external LCD display).
Created attachment 9619 [details] [review] PATCH: Translate dstBox coordinates to output-local coordinates
*** Bug 10158 has been marked as a duplicate of this bug. ***
*** Bug 9807 has been marked as a duplicate of this bug. ***
Daniel: regarding comment #9 in bug #9807, is this a side-effect of the patches I introduced? Can you attach the Xorg log (/var/log/Xorg.0.log.old maybe, since your system powers down)?
no, it's nothing to do with your patch. it's been going on for a while, and is some kind of electrical, rather than software, issue: if it's plugged in while the laptop is off, it won't turn on at all.
System: Dell Inspiron 510m w/Intel 82855GM graphics, no external monitors attached. Ubuntu Feisty w/latest updates, xserver-xorg-video-intel 1.9.94-1ubuntu3 Using the RC4 driver I have several issues (which I will post as separate bugs when I find out which aren't related to this). 1. Switching to a VT sometimes causes an irrecoverable system crash, and changing modes (e.g. running ppracer) always causes a crash (no, DRI is functioning correctly for windowed apps). 2. Video playback never works; sometimes the movie plays with a blank window, but mostly the server crashes, restarts and the system freezes with the cursor onscreen before GDM can kick in. I applied JM Ibanez's two patches and recompiled, and now video playback is working with absolutely no crashes reproducible. Aside from issues with bad default contrast and saturation (which is probably unrelated to the patches), I just wanted to let you know these patches helped. I'll attach two Xorg.0.log files, using unpatched and patched driver. If any more logs will be handy, let me know.
Created attachment 9645 [details] xorg.conf
Created attachment 9646 [details] Xorg.0.log (unpatched RC4 driver)
Created attachment 9647 [details] Xorg.0.log (patched RC4 driver)
*** Bug 10732 has been marked as a duplicate of this bug. ***
Hello. I'm interested in this bug. This is closed as of April, 17th but I wonder if patches will be included or if they are accepted. Thanks
I don't see why this bug is marked as fixed. Did anything get committed in git yet? Also, it is said in #10466 that when the patches are applied, the XV overlay is now always on LVDS. It does not look like a good solution to me.
I tried today's git (with the recent overlay fixes), and it works great on my 855GM, I can even move the overlay window between screens, the overlay nicely switches appropriately! That said, sometimes I'd like to show the overlay on both screen. For this, I tried xrandr --output VGA --crtc 1 --auto --output LVDS --crtc 1 --auto (since xrandr --verbose tells me CRTCs: 0 1 for VGA and CRTCs: 1 for LVDS), but this xrandr call fails with error BadMatch on request 156(RANDR) 21. Shouldn't that be possible?
This bug is now fixed, with the overlay choosing the CRTC with the most coverage of the window, and XV_PIPE being available to override it. To Samuel, no, you are often not able to clone different types of outputs on one CRTC due to clocking differences.
> To Samuel, no, you are often not able to clone different types of outputs on > one CRTC due to clocking differences. Well, yes, I knew that, I should have been a bit more precise: when running xrandr --verbose, part of the output is: VGA connected ... 1024x768 (0x4e) 65.0MHz h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz ... LVDS connected ... 1024x768 (0x4e) 65.0MHz h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz So I tried xrandr --output VGA --mode 0x4e --crtc 1 --output LVDS --mode 0x4e --crtc 1 but this fails. Since the clock values are exactly the same, shouldn't this work?
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.