[sane-devel] genesys backend status update

Gerhard Jaeger gerhard@gjaeger.de
Sat, 14 May 2005 11:35:43 +0200


sorry for the late response.

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
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.


> Regards,
> 	Stef

Anyway, keep up the good work, I currently check the ST12 and ST24 stuff.