Summary: | v4l Xv overlay output stops working after a few hours. | ||
---|---|---|---|
Product: | xorg | Reporter: | Aaron VanDevender <sig> |
Component: | * Other | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED NOTOURBUG | QA Contact: | |
Severity: | normal | ||
Priority: | high | ||
Version: | 6.8.2 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Aaron VanDevender
2005-07-13 12:17:16 UTC
I compared values of xvinfo from while Xv v4l is working and after it chokes, and the thing that stuck out at me is that before it stops wowrking XV_FREQ in Adapter #0 "video4linux" is set to 0. After it stops working its set to 68718 which is outside the allowed range of 0-16000. If XvSetPortAttribute is called with a value above 16000 it should return BadValue, but for some reason, it is instead actually setting the erroneous value. I don't know if that is what is causing my problem, but that certainly isn't helping. This effect (video not displaying) is due to some applications setting XV_AUTOPAINT_COLORKEY=0. For example, xine does this, and it has a bug whereby under some circumstances it dose not set the Xv attribute back to 1 when it quits. You can set it from the commandline using xvattr -a XV_AUTOPAINT_COLORKEY -v 1 I still think Xv should refuse to set XV_FREQ to a value outside of its range, but it appears that has nothing to do with this display problem, so I'm closing this bug none the less, and I'll go and file a bug with xine, the real perpetrator. |
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.