[sane-devel] genesys backend status update

[stef]

On Sat, May 14, 2005 at 11:35:43AM +0200, Gerhard Jaeger wrote:
> Hi, 
> 
> sorry for the late response.
> 

	Hello, seems I'm not also that fast on mail. I was busy getting
2300c to work ...

> On Wednesday 11 May 2005 19:00, stef wrote:
> > 	Hello,
> >
> > 	I don't think we can have gl641 and gl841 in the same file. First some
> > registers of same index have different bits. Second the enum we use to
> > access registers are different. This overlap make it much harder to have
> > both in one file than to have 2 cleanly separated objects. For instance
> > since register sets are packed differently (not the same amount of
> > registers used), you wouldn't be able to access them simply. You'll have to
> > use the helper function, instead of directly using indexes. Also you'll
> > have defines of the same name which would have to be of different values,
> > and some values would need 2 different defines.
> 
> Probably you're right here, but when having "locally" exported functions,
> don't name it sanei_..., 
> 
> > 	genesys_low.c is no more needed. There are currently a lot of
> > redefinition, but it is because the work on gl841 is at the beginning.
> > Thing will really differ in the future. Furthermor, I expect we will have
> > problem with the Genesys_Gpo struct because gl841 has more GPIOs, and I'm
> > afraid that registers and bits to set the frontend are different, and we
> > then have troubles with Genesys_Sensor.
> 
> These issues, I think have been solved in genesys_new. Anyway as I told
> you I don't insist on continuing with genesys_new, I simply did this
> work to demonstrate how it could be done with the function pointers
> (which - as far as I can see - you have now implemented...)
> 
> > 	For the function pointer method, it seems clean. But we have to be sure
> > to the parameters will be allways the same (still thinking of Genesys_Gpo
> > and Genesys_Sensor). Which seems likely with the current state of the
> > backend. 
> 
> Guess this is not really a problem.
> 
> > It would also decrease limit the number of exported functions. In 
> > fact we would only need a gl646_init_funcs() and a gl841_init_funcs().
> > sanei_genesys_* would still be needed but not sanei_glXXX_* .
> >
> > 	I've look a little at genesys-new, and I don't feel the genesys_mid.c is
> > really needed. If I understood, it holds functions "between" low and high
> > level, do we really want these in an other file (which is included) ? I
> > haven't the feeling that genesys.C has grown too big. Maybe I am missing
> > something ?
> 
> Hmmm, I do really think, that having more than 4000 lines of code is pretty
> too much for one file. One other thing are the gamma settings for the

	I'm not personnaly keen on splitting files and then including them.
However, personal taste is not a sensible argument. 
	Including source files would involve adding an option to makedepend 
in the makefile (we want 'makedepend -o.lo *.c') so that dependencies are
correctly handled. That raise one question, is there a build environnment where
sane objects are built with .o suffixes ? I couldn't find out it from the
makefiles or config files.

> various models, couldn't these values be generated by a function?
> I did some tests and something like:
> 
> 	for( i = 0, c = 0; i<gamma_len; i++ ) {
> 
> 		val = ( gamma_max * pow((double)i / (double)( gamma_len-1.0), 1.0 / gamma ));
> 
> 		if( val > gamma_max )
> 			val = gamma_max;
> 
> 		for( j=0; j<4; j++ )
> 			gamma_table[c++] = val;
> 	}
> 
> generates the table: gamma = 2.2, gamma_len = 4096, gamma_max = 16380;
> 
> > 	Currently, I'd be rather inclined to only add the function pointers to the
> > gensys backend and keep separated objects for low level.
> 

	Gamma tables are currently a nobrainer cut'n past from usb logs. I've
started to see if they can be replace by an init functions. However, the MD6471
case seems a little more complicated than a pow() formula. 

> Okay...
> 
> >
> > Regards,
> > 	Stef
> 
> Anyway, keep up the good work, I currently check the ST12 and ST24 stuff.
> 
> Ciao,
> Gerhard

	After latest check-ins, the HP 2300c is now well supported, and isn't
experimental anymore, like MD5345/MD6228/MD6471.

	What I am looking into now, is to see if we can get rid of the 'static'
gamma tables, adding true lineart scanning and 16 bits scanning. I feel 
like addng a 16bit option and a 'channel filter' select option.

Regards,
	Stef