Thanks for the comments - certainly good arguments to our lawyers :-)...
actually the information of how to config the ISP HW is requested to be
protected for now, we are working on certain degree of openness.
The HW config code is just a small part of the user space (daemon)
tasks, the user space code also processes ISP states, carries out 3A
algorithm and perform post processing features, etc. which will have to
be protected, this is the reason why the daemon is used in QC solution.
On 1/4/2011 4:15 PM, Laurent Pinchart wrote:
Hi,
On Tuesday 04 January 2011 20:37:31 Yan, Yupeng wrote:
We will exploring the usage of libv4l2...however we still have the
difficulties to open-source hardware: our ISP and sensors, will need help
on how to address such issues.
I suppose you mean open-sourcing hardware driver. There's no requirement to
open-source the hardware at this point, although I would love to see that
happening :-)
Let's start with sensors, it's the easiest. Sensor drivers must not depend on
the ISP driver, and the ISP driver must not depend on sensor drivers. They
communicate together through the media controller and the V4L2 subdev APIs.
You will obviously need to test your ISP driver with at least one sensor, but
you're not required to submit the sensor driver along with the ISP driver
(although it would be nice if you did so).
Correct me if I'm wrong, but I don't think Qualcomm produces video sensors, so
no Qualcomm confidential information would be disclosed in a sensor driver. If
the sensor manufacturer hasn't released a sensor driver, or sensor
specifications covered by a license that allows a GPL driver to be written,
you will need to sort it out with the manufacturer. Note that public
documentation is not strictly required to release an open-source driver (see
the SMIA++ driver written by Nokia for instance), but that would be
appreciated.
For the ISP the problem is not that complex either. From what I understand
Qualcomm is scared that publishing an open-source driver will backfire. I can
see several reasons (I should probably say myths instead of reasons) for that
fear:
- "Competitors will steal my code". They can't. The code is highly hardware
specific and doesn't contain much added value. It can't be reused as such.
Even if code could be reused, it couldn't be "stolen" as it will be covered by
the GPLv2.
- "Competitors will get key information about my hardware". You need to ask
yourself what you consider as key information. The fact that the output width
is stored in register 0x12345678 is hardly key information (if it is, there's
a more basic issue). The way statistics are computed might be. Based on my
experience with ISPs key information isn't disclosed by the driver. The
hardware algorithms (such as color conversion, faulty pixels correction,
statistics gathering, ...) implementation are usually not disclosed by the
code.
- "Competitors will sue me for patent infringement". This goes along with the
previous point. Patented ISP features are usually the ones you consider as key
information, and details are thus not disclosed by the driver. Note that I
don't care here about trivial patents with broad claims such as "a system to
capture an image to memory". Even without any open-source driver infringement
can still easily be proven (and the patent can easily be invalidated, although
that costs money - Qualcomm should join the Open Invention Network :-)).
None of those reasons are valid compared to the benefits you get from an open-
source Linux driver.
--
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
