Bug 18378

Summary:

Non-compiz compositing breaks xf86-video-savage XVideo colorkeying

Product:

xorg

Reporter:

Alex Villacís Lasso <avillaci>

Component:

Driver/savage

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

Version:

git

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
gst-launch xvimagesink, no compositing manager active	none
gst-launch xvimagesink, metacity internal compositing manager active	none
Patch to conditionally use xf86XVFillKeyHelperDrawable if available	none

Description Alex Villacís Lasso 2008-11-04 16:31:55 UTC

Observed in stock Fedora 8 xorg, confirmed in latest git.

The xf86-video-savage driver uses colorkeying for its implementation of XVideo extension. Also, this driver does not support compiz, so I think compositing managers must use xrender in order to implement compositing when using this driver. When there is no compositing manager active, the xv colorkeying works correctly in all applications (tested totem, gst-launch pipe, mplayer).

When a compositing manager is enabled (tested with internal metacity compositor), mplayer is not affected, but gstreamer clients (gst-launch and totem) flash the video contents for an instant, and then the video area is covered by garbage composed of old screen bitmaps. Sometimes, dragging the video window makes the video content appear for an instant, but while dragging, the video area repeatedly flashes between the video content and garbage bitmaps. Somentimes, when dropping the video window, the video area remains normal, but other times, it is covered again by screen bitmaps.

Tested at 16bpp.

Comment 1 Alex Villacís Lasso 2008-11-04 16:34:56 UTC

Created attachment 20054 [details]
gst-launch xvimagesink, no compositing manager active

Screenshot of gst-launch with xvimagesink and no compositing manager. Dark-green square is the normal color key used in my system.

Comment 2 Alex Villacís Lasso 2008-11-04 16:39:38 UTC

Created attachment 20055 [details]
gst-launch xvimagesink, metacity internal compositing manager active

This shows gst-launch with xvimagesink and metacity compositing manager active. Here, the colorkeying has been overwritten by a copy of the background image.

Comment 3 Michel Dänzer 2008-11-05 02:26:38 UTC

This is a driver issue. At the very least, it should use xf86XVFillKeyHelperDrawable() when available instead of xf86XVFillKeyHelper() to make sure the colour key is drawn correctly for composited windows.

Comment 4 Alex Villacís Lasso 2008-11-05 08:12:03 UTC

(In reply to comment #3)
> This is a driver issue. At the very least, it should use
> xf86XVFillKeyHelperDrawable() when available instead of xf86XVFillKeyHelper()
> to make sure the colour key is drawn correctly for composited windows.
> 

Thanks for the explanation. I will try to whip up a patch tonight. However, a grep on the drivers from current git show that the only user of xf86XVFillKeyHelperDrawable() is xf86-video-ati. Assuming your explanation is correct, then every single driver that implements xvideo via colorkeying is broken in the same way as xf86-video-savage. How come nobody has noticed it?

Comment 5 Michel Dänzer 2008-11-05 08:18:09 UTC

(In reply to comment #4)
> Assuming your explanation is correct, then every single driver that implements
> xvideo via colorkeying is broken in the same way as xf86-video-savage.

Right.

> How come nobody has noticed it?

Not sure, I guess most people don't realize there's a way to improve the problem without using textured video.

Comment 6 Alex Villacís Lasso 2008-11-06 07:56:16 UTC

Created attachment 20115 [details] [review]
Patch to conditionally use xf86XVFillKeyHelperDrawable if available

This patch implements a conditional test for the xf86XVFillKeyHelperDrawable and uses it if available. This fixes the colorkeying corruption in the cases I could test (gst-launch and totem). Applies against current git.

Comment 7 Alex Villacís Lasso 2008-11-07 08:02:46 UTC

Suggested patch has been committed to current git.

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.