Hello,
here's the mentioned scripts. There are 2 main ones:
- decode.sh : turns raw usb log in higher level form
- cmd.sh : turns the output of the decoding in high level status dumps
The first script uses a swarm of little awk scripts that handle a
little step
of decoding each. At the end, there shoudn't be any lines 'URB .....'
remaining if everything has been decoded. In case any are left, they're
meaning has to be understood so that the scripts can handle them. Usually the
left over are custom button or power saving handling. If needed, they can be
filtered out as shown in decode.sh .
The second script parses the high level output and builds a in memory
status
of the scanner. Each time a motor start is found (motor start is use as
a 'commit'), the whole status (slope tables, analog fronted and registers) is
dumped. It allow to compare the debugging output of the backend with the
expected status of the scanner. This filters out the many useless registers
writing/reading done by drivers.
All scripts keeps data, so logs may be huge, but you can then rebuild
pictures of scans from the recorded data. which help understanding what the
scanner is doing. Doing such his explained in
http://perso.modulonet.fr/~stefdev/sane/gl646-wip03.odt
I'll be out for a couple of day, so I will answer any question/point
when
I'll be back.
Regards,
Stef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dist.tar.bz2
Type: application/x-tbz
Size: 10784 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061203/17f783d6/dist.tar-0001.bin
From jkds...@gmail.com Sun Dec 3 21:41:22 2006
From: jkds...@gmail.com (JKD)
Date: Sun Dec 3 22:05:10 2006
Subject: [sane-devel] Location of some backend's files
In-Reply-To: <pine.lnx.4.61.0612031104310.29...@limos.pfeiffer.edu>
References: <eb141f9e0612021648k1fd05544ge830c3c8c4d3a...@mail.gmail.com>
<pine.lnx.4.61.0612031104310.29...@limos.pfeiffer.edu>
Message-ID: <20061203204122.gl3...@jkdsoftware.dyndns.org>
El Sun, 03 de Dec de 2006, a las 11:13:07AM -0500, m. allan noah dijo:
> On Sun, 3 Dec 2006, JKD wrote:
>
> >Hello,
> >
> >I'm hp3900 backend's developer. Due to this backend supports some
> >scanners and new devices could be supported in the future I'm thinking
> >about the possibility to create different config files for each
> >scanner capabilities to maintain code's structure legible.
>
> but you will have to add code that parses these files, and builds them
> into an array of structs. having that array compiled into the backend
> will be faster, and maybe less code.
Code to parse files would be done the first time. Sources wouldn't
need to be rewriten each time a new scanner is added. Due to config is
out of code, application's size is much lower and only is necessary to
allocate dynamic memory for one scanner instead of all supported
scanners. Another advantage is that any change in structs wouldn't affect
configuration causing compilation problems. The only disadvantage as you
say is that there is a little lapsus of time (may be not perceptible)
when using "sane_open" function. But after sane_open, backend works
as fast as it was before.
> >It's not simple configuration which user should change but internal
> >values to program RTS8822 chip in each case (area constrains to scan,
> >sensor timing values, motor curves...) so I wouldn't set them at
> >sane.d/hp3900.conf
>
> if they are not user-changeable, then why do they need to be a separate
> file?
Because it's easier for any developer or anyone who wants to try to
support his new scanner, under his own responsability, editing desired
values without compiling backend in each change (It's faster in
this way). For security reasons these files can be "read only" so normal
users can not make any change.
> >
> >Is there any standard path in SANE to locate such files? Something
> >like sane.d/backend's name/ or may be /usr/share/backend's name/
> >
>
> i would consider it a security risk to have such a low-level control file
> read from the home-dir of the user, and non-linux systems may not have a
> /usr/share, but they will have the sane.d config-file dir, so perhaps
> sane.d/backendname/ is best (though i dont see the need for it...)
>
> allan
If all of you think that it's not a good idea I'll keep config inside
code.
Jonathan Bravo Lopez
