Hi, Hans,
On Mar 29, 2008, Hans de Goede <j.w.r.degoede@xxxxxx> wrote:
>> USB_SN9C102 - USB SN9C1xx PC Camera Controller support
> Thats a fall positive there are a few hex coded tables in there, but
> those are either:
> 1) color curve lookup tables
I'm not smart enough to understand what "color curve lookup table"
means. Are the comments surrounding the code and published
information available for this decide sufficient for someone
relatively familiar with this topic to figure out what the numbers
mean and to, say, fix the tables such that they work for a lightly
defective camera that encodes colors incorrectly?
> 2) A standard jpg file format header which gets added in front of the raw jpeg
> data returned by the cam
I think this is probably fine, indeed, if there's a comment explaining
this.
> 3) register initialization tables consisting of { reg_addr, value } pairs
Now this could be a problem or not.
I've seen a number of drivers that profusely document the meaning of
each register and how it's to be used, such that someone can really
make sense out of it. This is a great thing to have.
Other drivers simply refer to published specifications that describe
their meanings.
I'd guess that in others, developers didn't mean to deny information,
and they were just too lazy to provide all the information, or they
figured things out by themselves without consulting any documentation
whatsoever. This could be defended as something other than trying to
stop others from having freedom #1, although adding documentation for
these cases would certainly add freedom.
Unfortunately, in other cases, developers were under restrictions
imposed by NDAs, or by copyrights or availability of the documentation
they might have wanted to copy or refer to. For these cases, someone
is indeed hurting freedom #1, even if it's not the developer.
It's hard to tell one case from the other just by looking at the
code. Sometimes you have to ask the developers, or the vendors of the
part the code is for.
You generally get one of these outcomes to a question such as 'Hey,
I'm trying to tweak this code, but I can't figure out these numbers.
Help?' is:
(non-Free IMHO):
- Sorry, I can't help you, I'm under an NDA
- Sorry, I don't understand them myself. The vendor just said this
is what I should use.
- Sorry, I don't understand them myself. I just copied them from the
Windows driver.
(non-sure IMHO :-)
- Sorry, I don't understand them myself. After random trial and error
and some investigation of the behavior of the component while it
interacted with existing software, I got these numbers and they seem
to work for me.
(Free IMHO):
- Sorry, I should have referred to the documentation, it's publicly
available at http://...
- Sorry, I didn't have time to document my findings. Here are the
notes I took while investigating the device.
- Sorry, I didn't have time or permission to copy the entire
documentation, but I'd be happy to send you a copy of the small
portion that explains these numbers in case you'd like to add
documentation to the code.
> I happen to know this driver quite well, which triggered me, but
> chances are quite big that you've many more false positives.
If you can help document the sequences of numbers that you can
understand in there, this would be a great improvement. Then, we'd
have fewer doubts on whether that portion of source code is Free
Software or not. Without the documentation, in Jeff's position and
given his commitment, I think he's taking a correct conservative
position of leaving it out.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
