SOLO6x10 MPEG4/H.264 encoder driver

Krzysztof Hałasa
2013-09-09T10:56:26Z

Hi Hans,

I'm trying to move to Linux 3.11 and I noticed you've made some
significant changes to the SOLO6x10 driver. While I don't yet have
the big picture, I can see some regressions here:

- the driver doesn't even try to work on big endian systems (I'm using
IXP4xx-based system which is BE). For instance, you're now using
bitfields for frame headers (struct vop_header) and this is well known
to fail (unless you have a different struct for each endianness).

This is actually what I have fixed with commit
c55564fdf793797dd2740a67c35a2cedc133c9ff in 2011, and you brought the
old buggy version back with dcae5dacbce518513abf7776cb450b7bd95d722b.

- you removed my dynamic building of MPEG4/H.264 VOP headers (the same
commit c55564fdf793797dd2740a67c35a2cedc133c9ff) and replaced it with
precomputed static binary headers, one for each PAL/NTSC/D1/CIF
combination. While I don't strictly object the precomputed data,
perhaps you could consider adding some tool to optionally calculate
them, as required by the license. For now, It seems it's practically
impossible to make modifications to the header data, without, for
example, extracting the code from older driver version.

- what was the motivation behind renaming all (C language) files in
drivers/staging/media/solo6x10 to solo6x10-* (commits
dad7fab933622ee67774a9219d5c18040d97a5e5 and
7bce33daeaca26a3ea3f6099fdfe4e11ea46cac6, essentially a reversion of
my commit ae69b22c6ca7d1d7fdccf0b664dafbc777099abe)? I'm under
impression that a driver file names don't need (and shouldn't) contain
the driver name if the directory is already named after the driver.

This is also the case with b3c7d453a00b7dadc2a7435f68b012371ccc3a3e:

> [media] solo6x10: rename jpeg.h to solo6x10-jpeg.h
>
> This header clashes with the jpeg.h in gspca when doing a compatibility
> build using the media_build system.

What is this media_build system and why is it forcing code in
different directories to have unique file names?

I appreciate the switch to VB2 and other improvements (though I can't
test them yet), but perhaps it could be done without causing major
breakage?

I'm thinking about a correct course of action now. I need the driver
functional so I'll revert the struct vop_header thing again, any
thoughts?
--
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland