CuBox

[Lennart Sorensen]

On Thu, Jan 19, 2012 at 09:36:52PM -0500, D. Hugh Redelmeier wrote:
> Oh, and here I thought "Documentation and Sources" meant source.
> Silly me.
> 
> Still, you *could* distribute source code that is patent encumbered.
> 
> I'm not sure what they mean by codecs.  Are these codecs that exploit
> the video hardware or are they regular CPU codecs?

Almost certainly the video hardware, since it appears to have the ARM
MALI video core.

> Dynamic linking per se isn't an evil work-around.
> 
> Most video drivers need to live in kernel space (often as modules).
> There is no stable kernel ABI for modules so binary-only modules are
> specific to kernel versions and that makes them ephemeral.  Not
> something I want.

They don't really have to.  All you need in kernel space is a stub that
can talk to the hardware.  The actual logic could be in user space.

> I think that nVidia has gone to considerable work to make the binary
> portion of their video drivers fairly agnostic about kernel versions.
> They have an open-source shim that matches a particular kernel with
> the binary video driver.  Even so, binary drivers have to be updated
> once in a while.  So old nVidia cards are no longer supported on
> current kernels with the proprietary drivers.

They do drop support for very old cards once in a while.  It is quite
old hardware though.

> I think that the situation in the ARM world is much worse.

Actually it seems pretty similar to the nvidia case.

You have open source drivers to use the video as a frame buffer with
some minimal accaleration of scrolling and such.  If you want openGL or
video decoding though you need some binary blob to do it.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists