Hi Andrew,
[...]
> > After this change, things are working, but I still have a little
> > problem: in my setup, I first run a program that opens /dev/video1, does
> > some ioctl() to configure the stream, and exits; then I run a different
> > program that opens /dev/video1 for reading. With your patch, this does
> > not work because when the second program starts to read from /dev/video1
> > saa6752hs_init() is called with params == NULL, hence it restores all
> > the parameters to the default. I think that adding a
> > i2c_set_clientdata(client, cachedParams);
> > at the end of saa6752hs_init() fixes this problem (at least, it works
> > for me, but I don't know if it is the correct thing to do -- I do not
> > know the i2c stuff well).
>
> Hmm, its supposed to be able to support that (I do something similar). When
> its called with (params!=NULL), it copies them into the cachedParams. When
> its called with (params==NULL), it just uses the cachedParams, as set by the
> previous call. Must be an annoying bug somewhere - I'll see if I can spot it.
Sorry, after some investigation I discovered that this was my own fault:
saa6752hs_init() is ok as it is (in fact, looking at the code I see that
calling i2c_set_clientdata(client, cachedParams) at the end of
saa6752hs_init() is perfectly useless).
The fact is that an ioctl() was silently failing again and I did not
notice it.
I am thinking... Maybe we can fix this problem by adding a "retval"
field to the mpeg_params structure? saa6752hs_init() could do
params->retval = -EINVAL; return -EINVAL;
instead of a simple
return -EINVAL;
and saa7134-ts.c:ts_init_encoder() could do
return params->retval;
instead of always returning 0...
What do you think? Can it work? If you agree, I'll add try to implement
this in the next patch.
Thanks,
Luca
--
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
N O W A R ! ! !
