> The commands sent to the camera are roughly 'fire and forget': there =
> no ACK mechanism in IIDC. The only way to verify that a value has =
> accepted would be to read the register after a reasonable delay (say,
> 10ms). This would lower the throughput of the controls which explains
> why we don't do that in libdc.
I tried Matt's small test program and it fails as expected. That's =
I though I had a test case too that does do something like that.
> The error codes returned by the functions actually mirror the success =
> the raw1394 write function: if the data was sent on the bus then the
> function will report a success.
I had a bus analyser running when I did this test and I saw the packets =
the bus and they look properly. The only problem was that the gap =
command and response packet was too small. This probably needs some =
> My personal experience is that if the value is within boundaries, it
> works. Some cameras may take more time to set the parameters, in =
> case you need to insert a small delay between the write and the read.
Hhm, the small delay shouldn't be there since every camera should only
it's response packet when the parameter was set.=20
> For me both work well. Since I exclude a kernel/libraw issue =
> works) the problem could be at the camera level or in the user =
For me Matt's test program looks valid. Maybe he could resent it to the =
and you take a look at it.
Dipl.-Inf. Matthias H=E4nel
Get latest updates about Open Source Projects, Conferences and News.