Bug 24543

Created attachment 30441 [details]
dmesg

It doesn't work with yesterday's drm-intel-next on my side either.

I wonder if the kms overlay support code has actually settle down, though bug#20901 is marked as fixed.

From the dmesg:

[drm] initialized overlay support

so it looks like the userspace part is somehow borked. Just to check: You
need latest libdrm master, xf86-video-intel master for this to work.
Furthermore you need to insert

#define DRM_MODE_OVERLAY_LANDED

at the top of xf86-video-intel/src/i830_video.c, otherwise the actual
ioctl upcalls get #ifdef'ed out. This is because libdrm has not yet been
released with the new overlay definitions.

-Daniel

(In reply to comment #3)
> From the dmesg:
> 
> [drm] initialized overlay support
> 
> so it looks like the userspace part is somehow borked. Just to check: You
> need latest libdrm master, xf86-video-intel master for this to work.
> Furthermore you need to insert
> 
> #define DRM_MODE_OVERLAY_LANDED
> 
> at the top of xf86-video-intel/src/i830_video.c, otherwise the actual
> ioctl upcalls get #ifdef'ed out.

Indeed, works much better now. Video playback is smooth and flicker-free. The video does stay black a little longer when resizing/moving the window than before. But that's not an issue, just something I happened to notice.

Thanks a bunch for writing this :)

> This is because libdrm has not yet been
> released with the new overlay definitions.

Eric, would you mind if I bumped libdrm's version in master and made the DDX depend on it? With maybe a conditional?

In any case, closing fixed.

Thanks

On Fri, Oct 16, 2009 at 08:42:51AM -0700, bugzilla-daemon@freedesktop.org wrote:
> Indeed, works much better now. Video playback is smooth and flicker-free. The
> video does stay black a little longer when resizing/moving the window than
> before. But that's not an issue, just something I happened to notice.

I see this, too. What's happening is most likely:

1) You move/resize the window
2) Window gets redrawn with the background color (black)
3) mplayer does the Xv call to update the video
4a) X does the kernel ioctl to update the overlay
4b) Only _afterwards_ X paints the video area in the color-key color.

The ordering in 4) is to prevent that ugly blue from showing up when you
start a video. With ums, this was no problem, because 4a) never stalls in
the old implementation. With my kernel code, the kernel stalls userspace
if it gets to far ahead.  This easily happens when resizing (as long as
you wiggle the mouse fast enough to get more resize events than vblanks).
So 4a) stalls and you can actually see the black window drawn in 2).

Thinking about this again I've got an idea for an hack to prevent this.
Will cook a patch.

> Thanks a bunch for writing this :)

Thanks for testing, Daniel

On Mon, Oct 19, 2009 at 04:25:57AM -0700, bugzilla-daemon@freedesktop.org wrote:
> Thinking about this again I've got an idea for an hack to prevent this.
> Will cook a patch.

Unfortunately, none of my ideas seemed to help, so no patch. But I'm
fairly convinced that it is simply mplayer screwing up for vlc works
flawless, at least here.

-Daniel

(In reply to comment #6)
> Unfortunately, none of my ideas seemed to help, so no patch. But I'm
> fairly convinced that it is simply mplayer screwing up for vlc works
> flawless, at least here.

Yeah, gstreamer has absolutely no issues either so mplayer is probably screwing something up (wouldn't be the first time...)

Totem does seem to "freeze" X for a second or 2 at startup, but it even happens when it's starting up without a video, and gstreamer's gst-launch doesn't have that problem, so I'm thinking this particular issue is probably Totem's fault.

Anyhow, a week into KMS and it all works great.

Thanks

(In reply to comment #3)

> Furthermore you need to insert
> 
> #define DRM_MODE_OVERLAY_LANDED
> 
> at the top of xf86-video-intel/src/i830_video.c, otherwise the actual
> ioctl upcalls get #ifdef'ed out. This is because libdrm has not yet been
> released with the new overlay definitions.

Let's keep this tracker open until all the user-level components (mentioned above) are settled down.

Have all the required patches been committed? We need to close this in Q4.

> --- Comment #9 from Gordon Jin <gordon.jin@intel.com>  2009-11-30 21:31:45 PST ---
> Have all the required patches been committed? We need to close this in Q4.

All the code is committed (and already being used by early testers) but
not yet enabled by default (you still have to put a define somewhere. I
think Eric is waiting for the kernel part to hit a stable mainline release
(linux kernel abi policy) before being officially used. It's headed for
2.6.33 which means Q1 next year.

-Daniel

commit bd81734465912d79d6320a6fb021ce43d258b906
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Dec 8 15:27:41 2009 +0100

    Xv: enable drmmode overlay

Thanks a bunch to all :)