Thanks Henning, I'll make the changes as indicated by you and others. Do you have any info about creating manual pages. I've never done that before.
regards, Fred O. Henning Meier-Geinitz wrote: >Hi, > >On Sat, Sep 24, 2005 at 07:45:45PM -0400, Fred Odendaal wrote: > > >>I've put a patch file for the Lexmark X1100 backend on my website. >>Instructions for getting it are at >>http://ca.geocities.com/freshsh...@rogers.com/scanner_driver/download.html >> >> > >Ok, let's have a look (I only mention stuff that hasn't already been >listed by other people): > >AUTHORS: > - your email address is missing > >configure.in > - is missing (ok, for now it's ok but the final patch that should go > to CVS should have configure.in patched, not configure) > >backend/Makefile.in: > | libsane-lexmark.la: $(addsuffix .lo,$(EXTRA_lexmark)) > See below for comments. > > | libsane-lexmark.la: ../sanei/sanei_config2.lo > Are you sure that you need this (this is used for SCSI devices) > >backend/lexmark.c > | static SANE_String_Const mode_list[] = { > | "Color", "Gray", "Black & White", NULL > | }; > "Lineart" is used in most backends instead of "Black & White". See > also include/saneopts.h: > #define SANE_VALUE_SCAN_MODE_COLOR SANE_I18N("Color") > #define SANE_VALUE_SCAN_MODE_GRAY SANE_I18N("Gray") > #define SANE_VALUE_SCAN_MODE_LINEART SANE_I18N("Lineart") > > | SANE_Status > | init_options (Lexmark_Device * lexmark_device) > All functions that are not part of the SANE API must be either > static or start with "sanei_lexmark_". I would make everything > static and only rename the functions in lexmark-x1100.c that are > called from lexmark.c "sanei_lexmark_". Or, as a workaround, just > #include lexmark-x1100.c in lexmark.c and make everything but the > API functions static. See doc/backend-writing.txt for details. > > | sane_init > In my experience it's a good idea to print the version/build number of > the backend in a DBG message. That way you always know what version > was used when you get a bug report. For an example, see gt68xx.c. > > | in sane_start > | sane_get_parameters (handle, 0); > check return value? > |if ((lexmark_device->params.lines == 0) || > | (lexmark_device->params.pixels_per_line == 0) || > | (lexmark_device->params.bytes_per_line == 0)) > | return SANE_STATUS_INVAL; > A DBG message twelling what's wrong would be nice. > >backend/lexmark-x1100.c: > - no problems found > >One additional thing: You could write a test for the chipset used in >these scanners in tools/check-usb-chip.c. That way it's easy to find >out which other scanners also use the same chipset. > >Once you have implemented the changes mentioned here and you have a >manual page, please provide another patch so the backend can be >included into CVS. > >Bye, > Henning > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050925/5d2d745d/attachment-0001.html From bert...@zonnet.nl Sun Sep 25 20:35:55 2005 From: bert...@zonnet.nl (Bertrik Sikken) Date: Sun Sep 25 20:36:38 2005 Subject: [sane-devel] USB recordings MD6190 available In-Reply-To: <1127676080572.lauri.pirttiaho.30916.y5nn2uupkmxb7-rw17a...@luukku.com> References: <1127676080572.lauri.pirttiaho.30916.y5nn2uupkmxb7-rw17a...@luukku.com> Message-ID: <43370a2b.1080...@zonnet.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lauri Pirttiaho wrote: > Bertrik Sikken on Sun Sep 25 13:26:18 UTC 2005 > >>Hi again, >> >>I just noticed that many of the things I reported in my other >>reply in this thread were already figured out by you in a thread >>on the canoscan 3200 on june 26th 2005. > > > Further things that I have figured out since then are e.g > the following: > -- values 0029 and 002a are a write/read pair that handle two integers > at addresses FB83/FB82 and FB81/FB80. These integers are used > later by the scan command (value 0030) but I don't yet know > for what. > -- value 0080 returns a version number string Hmm, haven't seen this one in the logs. > -- values 00e1 and 00e0 are a write/read pair that access consecutive > bytes in the external 64K address space of the processor. High > addresses FE00-FFFF are peripherals (USB interface is at FE00-FE0B > but others I haven't figured out yet, except interrupt mask > for USB at FE15 and cause at FE17). > -- values 002b and 002c are a similar pair as above but access > bytes at FB00 up. That area seems to be used as a parameter > buffer e.g. for the scan command. > -- ie0 of the processor indicates USB traffic, ie1 is connected to > motor control and maybe something else. > -- value 0040 returns state of a state machine driven by ie1 as its > first byte and I suspect that state machine to be the motor control. > The second byte is port 1 bit 0 which I suspect to be he head home > detector. Additionally there are 3 more bytes of info (I con't > know the meaning of these yet), 0xAA and then 0's. I noticed some increasing number at bytes 2 and 3 and suspect that this is the current line number of the carriage. > -- There is some kind of clocked serial device connecter to processor > port 0 bits 5-7 -- it may be an EEPROM but maybe also something else. Wow, you opened up the device and attached a 'scope? > -- Also I know that the so-called mystery files contain parameters > that are written directly to HW registers but I don't know their > meanings yet. > > CanoScan firmware carries version number 0054 but the Medion > one has 1228 (at the end of the file). Also the structure of the > code is so much different that I suspect a driver for CanoScan > may not work with the Medion scanner, but then, maybe it does. > Have to check once we have some kind of test driver available... > > >>How about creating a kind of 'reverse-engineered datasheet' for >>this scanner (and similar ones) on the wiki page of Martin? > > > That is being worked on but proceeds slowly, about 1 hour per night... I made a start with the datasheet on Martin's wiki page. > If someone wants to help with reading the firmware I can provide > more details about tools to do the disassembly and code analysis. > It would help if someone decompiled the Medion version of the > firmware (doing manual detection of the C-compiler emit patterns > in the assembly code or write a tool to do that automatically). I can have a try at that. I don't have any experience with the 8032 but I do have experience with other (similar) processors. All the best, Bertrik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNworETD6mlrWxPURAqiRAKCSXVelOaRpaIEM4VkEJppBvbwMvgCfdPUj cOxki5zbgpM0VM2Ep9S2rVU= =qEqI -----END PGP SIGNATURE-----
