Hi,
I'm having a real bad time with this, I've just noticed the strangest thing:
The product id on the box changes when loading the firmware:
from the initial vid:pid of 03f3:008b to 03f3:008c I guess the same
also happens for 03f3:0087 to 03f3:0088
This is way the original firmware loader uses the
Paulo Assis wrote:
> For the box to function it needs a firmware upload. Currently this is
> managed by a udev script that in turn calls an application (multiload)
> that provides for the upload.
> What I would like to know is, if this the best way to handle it?
> The problem with this process is t
Devin Heitmueller wrote:
> On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis wrote:
>> Hi,
>> Is there any simpler/standard way of handling these firmware uploads ?
>>
>> Regards,
>> Paulo
>
> Hi Paulo,
>
> I would start by looking at the request_firmware() function, which is
> used by a variety of
On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis wrote:
> Hi,
> I'm currently porting the GPL linux-avc2210k driver (
> http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2.
> The current version has it's own API that makes it incompatible with
> any software except for specific user space apps
Hi,
I'm currently porting the GPL linux-avc2210k driver (
http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2.
The current version has it's own API that makes it incompatible with
any software except for specific user space apps (avcctrl, avctune)
bundled with the driver.
Since development s
