[mythtv] [mythtv-commits] mythtv commit: r14461 by nigel

[Daniel Kristjansson]

On Mon, 2007-09-10 at 19:43 -0400, Doug Larrick wrote:
> RTC might not be too bad, at least on a tickless system.  But I pity the
> fool who tries to run a combined OpenGL/RTC vsync on a 100Hz-tick
> system, especially w/o real-time scheduling.

It will obviously need to be verified like the existing RTC. I'm also
thinking we should put something like the following in the sample
mythbackend init scripts:
  echo 1024 > /proc/sys/dev/rtc/max-user-freq

Along with some notes for distributors like: run xfs_fsr nightly or
the equivalent for whatever file system you standardize on, install
LIRC and make include setserial in the distro, tune mysql at least
a little bit and delete the binary logs once in a while, no one wants
a 200 GB log with weeks of DB queries filling up /var, etc, etc.

> Is top/bottom field actually available?? It was not when I wrote this code.

It is, by looking at the frame number. This is initialized to
either an odd or even number, then it is incremented on every
field and sync starts on the top field, so by last the last bit
after the first V-Sync you can get the top/bottom with a simple
xor against the saved bit.

> Any thoughts toward porting the video-out system to use Xcb, which is
> thread-safe, instead of Xlib?

A big undertaking, I would think stability wise a port to Qt 4.0
would have more of a long term impact. We're fairly good about X11
locking these days, except we of course don't control Qt's X11
calls. Xcb would do nothing about the glX calls which are the more
serious problems with respect to X11 locking; some of them take
a while to complete so the locking can kill performance if you're
also doing something requiring access to the lock, like XvMC
decoding.

-- Daniel