[Openchrome-devel] MPEG-LA / Re: Todo list

[Simon Farnsworth]

Harald Welte wrote:
> On Thu, Nov 20, 2008 at 03:07:59PM +0100, Xavier Bachelot wrote:
> 
>> Depends on the chance we have to see the docs in a relatively short  
>> timeframe. Only VIA can answer this, and they depend on MPEG-LA will to  
>> collaborate (or not). Maybe Harald can update us on what's going on  
>> currently between VIA and MPEG-LA ?
> 
> Unfortunately there is no visible result yet.  Bruce has been trying to get
> a response from the MPEG-LA directly, while I've been talking with some
> differnt lawyers.  I hope I can clarify tomorrow if VIA wants to pay for an
> independent legal study on this subject.
> 
An alternative suggestion, if releasing the docs is tricky:

>From what's been released, it looks like the MPEG acceleration engine
hooks in as another input source to the HQV. Would it be possible to
define a sensible ABI between the driver and an XvMC blob, such that an
end user can buy a suitable blob from VIA (paying patent fees when they
buy the blob)? Openchrome would then need a mechanism to try and load
this blob.

In the short term, this is nasty - we end up with a supported ABI to let
a binary blob talk to the hardware. In the long-term, this simplifies
the job of REing the hardware; instead of having to deal with traces
that cover the whole VIA driver, we can just look at what goes through
the defined ABI.

At a first pass, we'd need:
1) A way to pass MC interrupts to the binary blob, and to clear them
when the blob has handled them.
2) A way to allocate a single lump of video memory for the binary blob
to use as it sees fit, including CPU-side mappings if needed.
3) Some way for the blob to tell the driver what HQV setup is needed
(video format, size etc).
4) Some way for the driver to only present an XvMC surface type if the
blob is loaded successfully, and to pass off handling of that surface to
the blob, including passing on all XvMC requests, and any needed subsets
of XVideo.
5) Methods for the blob to prod the hardware without interfering with
the rest of Openchrome.

It also has short-term advantages for VIA - those of us building systems
on VIA hardware can buy licensed binary blobs (which can be accounted
for properly to the MPEG-LA) to get full support *now*, while those who
want properly Free software can help with the RE job, or wait for results.

It also means that if the MPEG-LA change direction, and allow VIA to
release the details freely, VIA has a sample implementation as well as
documentation, so that we can see how the hardware is meant to be used.
-- 
Simon Farnsworth