On Wed, Jan 21, 2009 at 12:55:19PM +0100, Nicolas Huillard wrote:
> Is the below rough summary correct ?
> What it currently is :
> * a patch set to DRM kernel modules, xine-lib and xineliboutput

...not to forget the Xserver-DDX (hardware specific module) itself.

For pre-avivo Radeons you need to patch in all four areas. For Intel
i9xx chips patches in DRM kernel modules are obsolete since certain 
functionality is already implemented in graphics hardware.

> * that adds proper interlaced output from ATI and Intel GPUs


> * it also adds FrameRateControl under some conditions

yes. For pre-avivo Radeons and i9xx Intels FrameRateControl is possible

> * it's stable and works on VGA, but seems to also work on HDMI

for some people at vdr-portal and me it already works stable:-)
Compared to a FF card WSS is not yet implemented for Radeons. You
currently must use one of the available SCART Pin 8 solutions there.

Intel graphics allow hardware scaling in Y dimension even in interlaced mode 
(if needed). So WSS is obsolete there.

Still lacking an HDMI capable device I mainly focused on VGA/SCART output 
method. But also some working configurations already exist with 
FrameRateControl over HDMI. Please see link to 'durchfliegers' thread above.

> * only works with Xv (does/can not make use of XvMC)

currently it only works with Xv since this is the lowest common
denominator for video things under X available as open source. I don't
think MPEG2 decoding is worth all the effort to implement that in
firmware. Even on very slow processors MPEG2 decoding alone (with NO
deinterlacing) is running sufficiently fast.

> * can work with any display device (CRT, LCD, plasma)

should work with most VGA or SCART capable display devices. I tested
with several CRT-SCART-TVs and LCD-SCART-TVs and experienced no problems yet.

Some other people also could successfully rebuild the system.

> * make most use of the display device capability (interlaced display on 
> a SD CRT, "picture enhancers" on HD LCD/Plasma)

that's the main intention behind the idea. At least it should relieve the 
software of deinterlacing because todays PC architectures still can't do that 
efficiently by means of the main CPU.

> Ideal goal would probably imply :
> * output mode change upon source mode change (output 720x576i on the VGA 
> when playing SDTV, output 1920x1080i/p when playing HDTV contents, etc.)

this interesting theme has already been addressed by 'durchflieger' from
vdr-portal. I even think Petri has adopted some parts of durchflieger's
patch for xineliboutput. But I don't know exactly. Thread:


> * make use of hardware decoding capabilities when available (specially 
> for HDTV)

for HDTV use of hardware decoding capabilities are a future goal. For
SDTV as already mentioned I don't think it's worth the additional effort. 
I never understood all these discussing about MPEG2 decoding in
hardware/firmware. Even low end machines as SMT7020 decode with CPU with
no problems.

> Side-needs :
> * add support for nVidia, VIA chips, etc. (feasability ?)

most nVidia chips are VGA2SCART capable out-of-the-box even with 
recent open source Xserver-DDX. I threw a quick glance at this a few weeks 

As specifications are not available for nVidia chips there is no way to
implement FrameRateControl there. So VGA2SCART provides no special benefits 
for nVidia chips except that you drive an real 50Hz-capable (PAL) device.

I never dealt with VIA chips so far.

> * integrate these patches upstream (feasability, propagation delays?)

although ATI and Intel Xorg developers always kindly answered my
questions they seem not to be very interested in abusing a VGA port for
SCART. Even simple interlaced modelines are often not supported
yet without additional patches.

Current upstream development mainly focuses on conventional TV-out ports. 
Probably because todays graphics hardware is not directly designed 
with VGA2SCART in mind. Not to mention VGA2SCART+FrameRateControl which can 
only be achieved by playing some tricks.

I think special VDR distributions like easy-vdr currently are the only 
means to make the patches available to everyone in a convenient way.

- Thomas

vdr mailing list

Reply via email to