kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide

[Hans de Goede]

Alexandre Oliva wrote:
> Hi, Hans,
> 
> On Mar 29, 2008, Hans de Goede <j.w.r.degoede at hhs.nl> 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