Date: Mon, 15 Sep 1997 21:44:59 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Tomi Vainio <tomppa@fidata.fi> Cc: multimedia@FreeBSD.ORG Subject: Re: Fxtv 0.44 / bt848 Message-ID: <19970915214459.04161@ct.picker.com> In-Reply-To: <199709092232.BAA04521@zeta.fidata.fi>; from Tomi Vainio on Wed, Sep 10, 1997 at 01:32:19AM %2B0300 References: <199709092232.BAA04521@zeta.fidata.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
Tomi Vainio:
|Today I supped latest 2.2-stable with new bt848 driver. I also got
|new Fxtv. Now these are working very well. All problems with Fxtv
|are now gone. On July I reported to Randall about low picture quality,
|fuzzy picture, slow screen update (5-7fps), resizing problems, tilted
|screen and losing picture. Now I can watch full screen fast scrolling
Hey, good deal! Sounds like several things coming together got you up to
100%. Most of these were of course from the PAL/weurope fixes in the
driver of late, with maybe a little help from AFC which is now defaulted
on.
Faster screen updates though are a result of your running with direct video
now rather than ximages mode, as you noticed. Two changes that resulted in
this. First I think you might have switched from Xaccel to XFree. And
second, your Fxtv pixel geometry cfg now matches your frame buffer's
geometry whereas it didn't before.
If you run 24bpp, the relevent change is likely to be that I changed the
default frame-buffer byte order for 24bpp in the Fxtv rsrc file between
0.43 and 0.44:
< Fxtv.bswap3Bpp: false
> Fxtv.bswap3Bpp: true
Folks are expected to tweak these swap settings to match their video cards
since the DGA extension doesn't support querying this information (yet).
It could also be that XFree has changed the byte ordering for the video
mode on your card that you've been using. Amancio said they did that on
his Millenium, for whatever reason, and that got him going with direct
video.
| Now there are two smaller problems. Sometimes when I
|start fxtv video feed appears screen before I place window on desktop.
|I use manual window placement with Fvwm. Fxtv don't show video
|anymore when window is under another one.
Yeah, that's because the X protocol wasn't designed for clients to be
dumping video on the display themselves. :-) That is, there aren't any
"We've Started Moving" and "We've Stopped Moving" events sent to a client,
just "Moving" (actually, it's called Configure). If you have opaque moves
on in your window manager (grep for OpaqueMove), the X server just sends
the client "move,move,move,move..." when its moving. 'course with direct
video, this results in the client trashing the screen a bit.
I have it on my list to look deeper into the X protocol sometime and make
sure I can't infer some virtual "Start Move" and "Stop Move" events
somehow. If I can't, any other solution is just a hack. Things I'll
probably do is expand the area around the TV window that's refreshed on a
move (to include the Fxtv control widgets and some fringe area) as well as
lengthen the delay after a window move before the video is restarted.
Codeless hacks you can use for now include: 1) freeze the video before
moving it, 2) turning off OpaqueMove in your window manager, 3) running in
XImages mode. Like I said, all of these are hacks. I'll keep this on my
list of things to look at.
As to not showing video when the video window is partly obscured by another
window, that's also on my list. Amancio's added rectangular clipping to
the driver; I just need to add it to the app which, once supported, should
handle obscuration by windows not using the SHAPE extension. Right now,
Fxtv doesn't support clipping at all, so rather than blasting video on top
of the obscuring window, it just disables capture and cleans up the screen.
Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970915214459.04161>