[RFC] move sensor control out of kernel

["eric miao" <eric.y.miao@xxxxxxxxx>]

I know some one has different opinion, but since the sensor control logic is
getting more and more complicated, and provided that differences between
sensors and vendors are already too many. Is it better to move sensor
control out of kernel.

Most sensors come with a serial control channel, I2C as can be seen
most commonly. Access to the control information can be done by
i2c-dev interface if possible, thus the driver can be freed as an I2C
stub only. So technically, this is practical.

The benefits I can think of now are:

1. simplified sensor driver design

2. sensor control related debugging can be moved to user space thus
    reducing the debugging effort

3. accessing registers in user space can be done by many other ways
    say, UART. E.g.
    ADCM2650 and ADCM2670 differs in the control channel connection,
    one by I2C and the other by UART, the user space control logic has
    only to decide which device node to open: /dev/i2c/xxx or /dev/ttyXX

Another biggest concern to the V4L2 API itself, sensor nowadays has
more control ability than it used to be, some smart sensor provides
even more like auto focus control, lens control, flash mode, and many
other features that current V4L2 API cannot cover.

Besides, along with the complicated image processing chain, it might
be better described by kinds of pipeline, like what gstreamer is doing
now. Moving some or most of the logic to user space will also significantly
reduce the effort of kernel development.

Now the problem is: we don't have a standard in user space :(

Just a topic, any comments. Thanks

-- 
Cheers
- eric

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list