Alexandre Oliva wrote:
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?
This is just a table with X (lets say 256) mapping of measured color to
corrected color, so the table gets addressed/indexed with the 0-255 value
returned for a pixel color by the cam, and then returns a corrected value for
that measured value, the perfect case (iow no correction needed) of such a
table would be inited like this:
u8 color_correct[256];
int i;
for (i=0; i<256; i++)
color_correct[i] = i;
so looking up a certain index would return the index, however in the real world
their might be a difference between the value as measured by the sensors, and
the real value, because the sensos is non linear, sucha table corrects this,
this is obvious to anyone with the skills to modify such a driver and making
changes to get a different correction behavior is trivial.
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.
The array is called jpeg_header, what more can one want?
3) register initialization tables consisting of { reg_addr, value } pairs
Now this could be a problem or not.
<snip>
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):
<snip>
- Sorry, I don't understand them myself. I just copied them from the
Windows driver.
I didn't write this driver, but this is the most likely correct answer. Still
given that I needed to explain color correction lookup tables to you. I
_seriously_ doubt your ability to decide if this makes some code non free.
First of all this is data, not code, and you can study the data all you want,
just as you can study a picture all your want without needing to have to know
why each pixel is the color it is.
You are also free to modify, derive, and spread it so I see no problem here.
I do seriously wonder if you've ever seen real hardware documentation in your
live, as in datasheets, or the one one gets under NDA?
Often the official docs contains tables with initialization values like this,
sure someone on the planet (the designer of the silicium) might now the meaning
of some of these values, other of these values are just magic numbers. When
designing an analog circuit, you cannot know exactly how it will work out on
silicium (to many variables) so one adds things like configurable bias
settings, etc. Which are then determined by ...
(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.
So although those numbers are taken from the windows driver (I think), the
windows driver may have derived them this way. IF you even call this non free
you seem to _really_ be out of touch with the _physical_ reality. Some systems
are svery complex: too many variables, with to much uncertainty as to what
their values are as that cannot be predicted as its dependend upon the
production process and often even the batch.
This is a fact of _physical_ reality, and this is solved by adding some knobs
to compensate for the uncertainty of some variables, the correct position of
these knobs is then often determined by ... trial and error.
No amount of philosophical discussion will change the fact that sometimes some
values in registers are just there because they need to be there.
---
Lets take an olden goldy as example the ne2000 network card. Well known, well
documented (esp by now).
Still all drivers use the exact same initialization sequence, basicly setting
magic numbers in a couple of register and setting those in a fixed order, so
first register 3 then 1 then 17 then 2 then 5, etc.
If you look at the docs there is no reason to do things in this order, but the
actual hardware gets very upset (as in doesn't work) if you change the order.
There are most likely other orders as the one which is currently used which may
work too. But the current one works, as has been determined by trial and error.
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.
Luckily Jeff seems to more down to earth then you on this, and has already
re-added the driver to the libre kernels.
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
