On 7 Nov 2003, Gerd Knorr wrote:
> Koos Vriezen <koos.vriezen@xxxxxxxxx> writes:
>
> > Any ideas?
Thanks for your answer. May I add that I use bttv/xawtv for five years.
Many thanks for that!
> It's the new bttv driver, the same happens with 2.4.x + bttv 0.9.x
>
> bttv 0.9.x allways switches stuff on/off on the irq handler. That is
> needed to get certain corner cases right, for example doing vbi
> capture and video overlay at the same time.
VBI is new to me, does this mean this works on the same device
simultaneously (recording and overlay viewing)?
> The bttv ioctl to change
> the overlay blocks until the changes are active, which might be up to
> 40 ms. Because of that there is a longer latency for clipping changes
> in the X-Server.
>
> What happens within the X-Server looks like that:
>
> (1) disable overlay (via ioctl, up to 40 us delay)
> (2) handle clipping changes within X11, i.e. redraw window
> backgrounds and the like
> (3) pass clipping changes down to the bttv driver
> (4) reenable overlay (up to 40 us delay again).
>
> > X uses nv driver:
> > (II) NV(0): v4l[/dev/video0]: using hw video scaling [YUY2].
>
> With a yuv overlay in place and clipping done with chromakeying the
> v4l module could shortcut that in many cases, i.e. don't stop/start
> overlay as long as the window size doesn't change. It doesn't right
> now through ...
For what I use it, just watching TV, this is quite a usability
degradation. It's not only moving/resizing xawtv, but also effects windows
moving or popups on top of xawtv.
Are you saying the X folks should fix it, or is there a way in the bttv
driver to detect these corner cases as simultaneous grab and overlay
usage (and do the slow stuff only then)?
Fwiw, I did found a small improvement in rootv.c by guarding 'video_blit'
with:
if (event.xconfigure.width != old_width ||
event.xconfigure.height != old_height)
in the ConfigureNotify event case. Improves only moving a little bit.
Koos
