[sane-devel] [RFC][PATCHES] adding MD5345/MD6471 to genesys backend
Thu, 25 Nov 2004 21:51:17 +0100
On Thu, Nov 25, 2004 at 08:35:27AM +0100, Gerhard Jaeger wrote:
> Hi Stef,
> On Thursday 25 November 2004 07:06, firstname.lastname@example.org wrote:
> > Hello,
> > here are as set of patches that add the MEDION MD5345/MD6228/MD6471
> > to the experimental genesys backend.
> great, it's good to see, that there's some wip.
> > The first patch adds on ly the new model so that it can be
> > detected: http://perso.wanadoo.fr/septieme/MD6471/00_add_md5345.patch
> > I think it is OK to check in, but I'd wish other people working on the
> > genesys backend to have a look first.
> One comment, you're introducing DAC_WOLFSON_5345 - why? The settings are the
> same as for the ST24. Probably they're using the same Wolfson-DAC. I think
> it's not necessary to define DAC_WOLFSON_5345 - I'll change it back to
> DAC_WOLFSON_ST24 (in the device settings) and apply the patch to CVS - if this
> is okay for you.
I'm okay with it .
> > The second http://perso.wanadoo.fr/septieme/MD6471/01_misc_fixes.patch
> > contains would be fixes in registers init:
> > - memset regs so that we are sure that unset registers are zeroed
> > - disable gamma in R05, since we don't use it yet
> > - init R06
> should be okay.
> > The third
> > http://perso.wanadoo.fr/septieme/MD6471/02_add_gpo_struct.patch
> > adds a Genesy_Gpo struct to manage GPO differences between models, in the same
> > way that Genesys_Sensor does for sensor.
> Okay - good idea.
> > BTW, I have a few questions to ask:
> > - does writting 0x00 to R0e is enough to reset the ASIC ? The MD6471
> > driver writes 0x01.
> > - as anyone allready thought of how to handle the differences between
> > the motors ?
> Hmmmm, the problem is, that at least you need to figure out the various
> parameters for your motor. I don't think, that the MOTOR_GEAR is the only one
> to tweak. I think it's necessary to figure out how to get the necessary parameters
> out of the USB-logs. Futhermore I think the function we currently have needs some
> cleanup - think of the overwritten parameters...
> I'm planning to do some more work on that during the next days.
Well, I'll have a close look at motor related data to see I can
find some patterns.
> > - and last, what is the start point for y_offset_calib and
> > x_offset_mark ? I disassembled the scanner and I know where
> > they are placed, but I need to translate it into useful values.
> I don't know :(