Hello Guennadi,
On Thu, Apr 16, 2009 at 9:06 PM, Guennadi Liakhovetski
<g.liakhovetski@xxxxxx> wrote:
> On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote:
>
>> My concern is all about the logical thing. "Why can't we open device
>> node even if it is not opened from any other process."
>
> The answer is of course "because the other node is currently active," but
> I can understand the sort of "confusion" that the user might have: we have
> two "independent" device nodes, but only one of them can be active at any
> given time. So, in a way you're right, this might not be very intuitive.
>
>> I have been working on dual camera with Linux for few years, and
>> everybody who I'm working with wants not to fail opening camera device
>> node in the first place. Actually I'm mobile phone developer and I've
>> been seeing so many exceptional cases in field with dual camera
>> applications. With all my experiences, I got my conclusion which is
>> "Don't make user get confused with device opening failure". I want you
>> to know that no offence but just want to make it better.
>
> Sure, I appreciate your opinion and respect your experience, but let's
> have a look at the current concept:
>
> 1. the platform has N cameras on camera interface X
> 2. soc_camera.c finds the matching interface X and creates M (<= N) nodes
> for all successfully probed devices.
> 3. in the beginning, as long as no device is open, all cameras are powered
> down / inactive.
> 4. you then open() one of them, it gets powered on / activated, the others
> become unaccessible as long as one is used.
> 5. this way switching is easy - you're sure, that when no device is open,
> all cameras are powered down, so, you can safely select any of them.
> 6. module reference-counting is easy too - every open() of a device-node
> increments the use-count
>
Honestly it is not that bad. but in situation of multiple processes
trying to access camera devices like process A already opened video0
and process B tries to open video1, process B should face an error
returns even though process B checked for video1 is already opened or
not and verified that it is not opened.
> With your proposed approach:
>
> 1. the platform has N cameras on camera interface X.
> 2. as long as at least one camera probed successfully for interface X, you
> create a videoX device and count inputs for it - successfully probed
> cameras.
> 3. you open videoX, one "default" camera gets activated immediately - not
> all applications issue S_INPUT, so, there has to be a default.
> 4. if an S_INPUT is issued, you have to verify, whether any camera is
> currently active / capturing, if none - switch to the requested one, if
> one is active - return -EBUSY.
> 5. reference-counting and guaranteeing consistency is more difficult, as
> well as handling camera driver loading / unloading.
Oops I forgot to say that we need to enforce legacy v4l2 applications
to use VIDIOC_S_INPUT after opening device.
And every S_INPUT issuing should come after G_INPUT like every "set"
API in v4l2.
>
> So, I would say, your approach adds complexity and asymmetry. Can it be
> that one camera client has several inputs itself? E.g., a decoder? In any
> case, I wouldn't do this now, if we do decide in favour of your approach,
> then only after the v4l2-device transition, please.
>
Of course. I didn't mean to disturb your transition job. Please do
your priority job first.
And about camera client with several inputs question, I will say that
almost every 3G UMTS phone has dual camera on it. And we can consider
every 3G UMTS smart phones have dual camera on it with soc camera
solution.
BTW, thank you for this conversation. It was a pleasure to discuss
about this issue with you.
Cheers,
Nate
>> But the mt9v022 case, I should need some research.
>
> Ok.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
>
--
========================================================
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@xxxxxxxxx
dongsoo45.kim@xxxxxxxxxxx
========================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
