[sane-devel] Epson Stylus CX5500 Scanner
Johannes Meixner jsmeix at suse.de writes: On Apr 23 21:01 Garry B wrote (shortened): I am running OpenSuse 10.3 can't get an Epson scanner to work. The scanner is an Epson CX5500 multi-function. See http://www.sane-project.org/cgi-bin/driver.pl?manu=epsonmodel=CX5500 openSUSE 10.3 provides Iscan version 2.8.0. Sorry, you need 2.9.0 (as mentioned in my other follow-up). Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] Calling a script after USB scanner is plugged
Hello,
On Apr 23 22:53 Rainer Dorsch wrote:
Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
Johannes Meixner jsmeix at suse.de wrote:
Hi,
umax1220u scripts are started in a sequence (i.e. not in parallel, when
one is completed the next one starts).
When troubleshooting udev rules, use udevmonitor to actually see
what's happening in terms of udev events and their properties.
That was a very good hint, thanks. A single scanimage -L causes these events:
UEVENT[1208979136.171525] remove /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UEVENT[1208979136.171696] remove /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UEVENT[1208979136.171702] remove /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
UEVENT[1208979136.171707] add /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UEVENT[1208979136.171712] add /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UEVENT[1208979136.171717] add /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
UDEV [1208979136.172276] remove /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UDEV [1208979136.172803] remove /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UDEV [1208979136.173239] remove /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
UDEV [1208979136.174020] add /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UDEV [1208979136.174831] add /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UDEV [1208979136.175619] add /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
I wonder how scanimage -L causes any add or remove event at all.
I cannot imagine that those add or remove events are the
same add or remove events which happen when the device
is plugged-in at the USB or plugged-off from the USB.
Do you know what those different usb_endpoints are?
Perhaps the different USB interfaces for the one USB device?
I wonder how one could specify a udev rule which matches
to the one add event for the one USB device instead of
whatever bulk of add events for whatever stuff which
is related to the one USB device.
ACTION!=add, GOTO=end
SYSFS{idVendor}==04b8, SYSFS{idProduct}==010b, RUN+=...
LABEL=end
Be careful with the labels you use. Always use a unique label name, or
you're asking for troubles. (been there, done that, accidentally
rendered a number of systems unbootable due to that ...)
Many thanks for this enlightening info!
Impressive: A thoroughly thought out fail-safe design!
Actually - just because of a queasy feeling - I used
ACTION!=add, GOTO=sane_backends_autoconfig_rules_end
Of course man udev does not mention that all labels
in all udev rules files must be unique.
I can only guess that what udev actually does is to
concatenate all udev rules files into one single set
of rules and then it is not surprising when arbitrary
nonsense happens depending on which individual udev rules
files exist on a particular system which depends on which
individual software packages are installed on this system.
Very nice to debug!
Very easy to help others!
Makes all users very happy of course - or so they say.
I tried that before after I saw the z60_libsane.rules
ACTION!=add, GOTO=post_lamp_off
SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, MODE=0664,
GROUP=scanner, NAME=umax%n, RUN+=/usr/local/bin/umax1220u start,
ENV{lamp_off}=yes
LABEL=post_lamp_off
But given the events, it is obvious not surprising that this is not working.
Welcome in the hell of udev, HAL and whatever else sophisticated
stuff which is required to make users happy or so they say...
aol /
I added now in my script a file system lock:
if [ ! -e /tmp/umax1220u-plugged ]; then
touch /tmp/umax1220u-plugged
Is anybody aware of a more elegant solution for this problem?
You cannot have udev and elegant at the same time
and you cannot have HAL and elegant at the same time.
Just do whatever dirty hack fits at the moment for you
and be prepared that next version is sufficiently different
so that your stuff does no longer work.
Then just do whatever other dirty hack and so on ad nauseam
which makes you happy of course or so they say...
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] incompatible iscan-2.11.0
Johannes Meixner jsmeix at suse.de writes: Hello, Hi Johannes, I've kept my quiet for a while on purpose. You Cc:d the sane-devel list and that means I have to watch out (even more) with what I say. My activities on sane-devel are not always equally appreciated in all quarters. As always, all comments are my own and do neither reflect my employer's nor my employer's customer's opinion/policy. The latter are the ones that fund the work on iscan so they do have a big say in what does and does not happen. Anyway, I have forwarded your mail and the thread that unsued up the corporate food chain in hopes of improvement, again. What will and will not happen remains to be seen. I have tried to explain your gripes (most of which other people hanging out on sane-devel and I personally share) the best I could. Now let's hope other quarters catch on and get to take note of *user* priorities. only by chance I detected on http://www.avasys.jp/english/linux_e/index.html that for certain models iscan-2.11.0 is used (at least when one selects the Perfection V500 Photo which requires iscan-plugin-gt-x770-2.1.0-0). For other models (e.g. Perfection 2480 Photo) there is still iscan-2.10.0 shown (with iscan-plugin-gt-f500-1.0.0-1). Sorry for not putting out an announcement on sane-devel. My bad. Whatever iscan release announcements I make on sane-devel are really just a courtesy (ditto with the diff's to epkowa.desc) and this time it slipped. Sorry! Unfortunately the iscan-2.11.0 NEWS file reads --- does not work with *any* of the plugins that have a version number less than 2.1. Please use iscan-2.10.0 if you need such a plugin. --- The problem is not the actual incompatibility. The problem is that - as far as I see (*) - the other plugins are not available for iscan-2.11.0 (i.e. with a version number 2.1 or higher) - at least not for a 2480 Photo. Not yet. There are plans to at least provide updated plugins for the more recent models. Exactly which ones and when they will be released is up in the air.
[sane-devel] incompatible iscan-2.11.0
Julien BLACHE jb at jblache.org writes: Johannes Meixner jsmeix at suse.de wrote: Hi, Perhaps it leads to the solution that the Linux distributors agree to no longer distribute their proprietary stuff? That would be a good first step... That said, I have never distributed anything else beside the epkowa backend itself, so no changes on my side :) But now I have a real problem, that is there is a new iscan release, people know (or will know) about it and they're going to bug me to upgrade the backend. It's not possible to upgrade the backend without losing support for some scanners at least, and not upgrading means losing support for the other scanners, I guess. Not saying this is an ideal solution, but you as the libsane-extras package maintainer can upgrade. Whether people will install the upgraded or not is their choice. Let's face it, the upgraded package is not going to go into stable (etch). It will make it into testing (lenny) and people running that should know better than to upgrade without thinking. If you add the right conflicts to the package they should take note, one may assume. I have added a long list of conflicts to our iscan RPM and (still experimental) Debian packaging support so that people get notified about the incompatibility. I know it's a PITA to do the same to libsane-extras, but without breaking backward compatibility (for a few non-free plugins) there was just no way that I could add support for independent X/Y resolutions that give access to resolutions over 3200dpi. That was something people have been clamouring about several times here wrt iscan. You can't always and immediately have it both ways. Can't imagine a better situation than this one... I can, but just imagining it is not going to help anyone :-( -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] incompatible iscan-2.11.0
Julien BLACHE jb at jblache.org writes: Johannes Meixner jsmeix at suse.de wrote: But again it is only a proprietary model - shit happens - go to Epson Avasys issue. Unfortunately sooner or later it'll land in my mailbox :| I wonder how Epson Avasys supports this case. They don't is my guess. See how the download form gives you one version or the other is how they handle it. For the time being, yes, that is how my employer supports this. I really hope we can get rid of this ugly situation quickly and provide updated plugins that work with iscan-2.11.0 and later for all models. Now, if I were a hardware manufacturer, I might be (very?) tempted to drop support for some older models. Especially those that are also supported by alternative backends ... Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] incompatible iscan-2.11.0
Johannes Meixner jsmeix at suse.de writes: On Apr 23 17:04 m. allan noah wrote (shortened): On 4/23/08, Julien BLACHE jb at jblache.org wrote: Well, without the non-free bits it provides better support for some scanner, and supports devices no other backend supports :) which scanners are those? I wonder if the best course of action would be to update the epson or epson2 backends to support those scanners, then you could drop epkowa. Use something like egrep ':model|:comment' doc/descriptions-external/epkowa.desc \ | grep -B1 ':comment.*non-free' and you get entries like [snip] Johannes and I discussed the format of the comment entries after he started using what I had started adding on a voluntary basis. I was happy to know that the information was useful. Unfortunately most models which require a non-free plugin are not supported by another (i.e. free) backend. Very sad, but true. Me not happy. Furthermore many of the proprietary models require firmware upload which is automatically done by the epkowa backend together with the matching non-free plugin. To be precise the upload is done by the plugin, not by the backend. I wish I had the time for extract the upload bit into a separate utility that can be started from udev ... Currently - as far as I found out (see below) - firmware files are only needed for the following scanners: [snip] To determine for which models the firmware files are: For each firmware file do strings $firmware-file | grep ^EPSON. At the moment this results the following models: esfw41.bin: GT-F500 esfw32.bin: GT-9400 esfw52.bin: GT-F520 esfw43.bin: GT-F600 esfw54.bin: GT-X750 esfw66.bin: GT-S600 esfw68.bin: GT-F700 esfw7A.bin: GT-F670 Then check epkowa.desc which other models require the same non-free plugin and assume that all those models require the respective firmware file too. By the way: I must know which models require firmware upload so that I can inform our users when they try out a free backend where the firmware upload must be configured manually. Again a nice example which awkward things I do to deal with Epson Avasys' proprietary stuff in particular because their official policy is to not help distributors to package their proprietary stuff well and easily. Johannes, when did you ask? I can add the firmware files to the epkowa.desc file if you want but it would be nice if there were some extra fields (or a mechanism for custom fields, something like the X-* header with mail) where I could put them. Adding everything to the comment field gets a bit messy and kludgey. As to the official policy bit, at least this developer here is not aware of any such policy and wonders how you found out about it. Griping about things you don't like is one thing, but (quite likely) misrepresenting the state of affairs is another and it doesn't look good on you. Stick with the fact and let's see if something can be worked out. Step by step Epson Avasys' official policy results what they actually ask for: do not actually realase it but keep it under Epson Avasys' full control - o.k. - they conviced me - they can get what they ask for... About official policy I don't know, but I do know that you asked for a couple of things in the past and got several of them. The non-free references in epkowa.desc is one of them, easy build support on unsupported architectures is another. Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] incompatible iscan-2.11.0
Hello Olaf, first of all many thanks for your answers. Of course I know that it is not and never was you who is responsible for the mess with the proprietary parts in IScan. I hope I made it sufficiently clear that the management of Epson or Avaysy is responsible for the mess, in particular because those managers seem to be either chicken-hearted or arrogant because they just do not talk to the people who try to provide out-of-the-box support for their proprietary crap but finally this ordeal seems to come to an end soon. On Apr 24 16:35 Olaf Meeuwissen wrote (shortened): Johannes Meixner jsmeix at suse.de writes: For example I would of course still distribute the free part of Iscan in our iscan-free package but drop the packages which contain proprietary stuff and add an explanatory message to the YaST scanner config to direct the user to the Epson Avasys web site if a proprietary model is used. You know what would be even better? YaST being able to offer the user to download, install and configure that proprietary crap automatically. Because of legal issues we cannot do anything automatically with proprietary stuff. For example when currently a proprietary model requires our proprietary iscan package from our CD/DVD/repository, I cannot install it via the YaST scanner configuration because here the installation would happen somewhat silently and automatically in the background. All I can do is to show a message which tells the user to install it manually (with the YaST installer module) because only the manual installation makes sure that the popup regarding the proprietary license is shown and that possible conflicts (iscan conflicts with iscan-free) are shown in full detail together with the matching choices/buttons what to do regarding a proprietary license and/or regarding conflicts. Those are the messages that the YaST scanner config shows for openSUSE 11.0 if the proprietary iscan is needed: - The package iscan should be installed but it contains proprietary binary-only i386-only software. Therefore it is only available for i386-compatible architectures. Some scanners are also supported by another driver. If you really want to install iscan, you must do it manually. - And an addendum if iscan is needed on AMD 64-bit systems: --- Iscan is only available as 32-bit software. On AMD 64-bit (x86_64) systems the scanner driver in the iscan package works only if also the scanning user frontend is 32-bit software. You can use the special frontend /usr/bin/iscan for Epson scanners which is included in the iscan package. If you like to use a standard frontend like scanimage, xscanimage, xsane, or kooka, you must explicitely install the 32-bit package version (i.e. get the package from the right media or repository). --- see https://bugzilla.novell.com/show_bug.cgi?id=337816 The 32-bit-only mess with the proprietary stuff is another reason not to try to do anything automated here. Compare for example the proprietary stuff in HPLIP https://bugzilla.novell.com/show_bug.cgi?id=342704#c3 HP was in contact with me regarding how to provide support for ZJStream printers in compliance to the free licenses. In the end they do it the same way as IScan: Via an optional external library (via dlopen). The crucial point is that the HPLIP software works well in general even without such a library. Only the ZJStream printers need it. HP checked the third-party license stuff and all what is requird is a EULA which must be accepted by the user. The download functionality of hp-setup does the right thing which is needed to support ZJStream printers. We take only the perfectly free-software upstream HPLIP package and distribute it. We do not download and/or distribute any proprietray stuff from HP. We distribute the HP setup tool as is in the free-software upstream package. We rely on HP's setup tool as is to take care of everything regarding their proprietray stuff (e.g. displaying the EULA, downloading the right proprietray stuff from the right server, install the proprietary stuff at the right place with the right permissions, set up the printer accordingly, whatever else...). I think for future openSUSE versions (not for 11.0 which provides iscan 2.10.0 packages as we did before) I will do the same for IScan: I distribute only the free parts of IScan. I do not distribute and/or download and/or install any proprietray stuff from Avasys (or elsewhere). Because there is no iscan-setup tool available, I can only show a message to the user to go to the Avasys web site. Perhaps a free iscan-setup tool in the IScan
[sane-devel] incompatible iscan-2.11.0
On Thu, 24 Apr 2008 16:50:45 +0900 Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Johannes, when did you ask? I can add the firmware files to the epkowa.desc file if you want but it would be nice if there were some extra fields (or a mechanism for custom fields, something like the X-* header with mail) where I could put them. Adding everything to the comment field gets a bit messy and kludgey. an extra field for firmware could be very helpful indeed. +1 :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] incompatible iscan-2.11.0
On Thu, 24 Apr 2008 16:05:32 +0900 Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Not yet. There are plans to at least provide updated plugins for the more recent models. Exactly which ones and when they will be released is up in the air. what's changed between the old and the new plugins that introduced incompatibilities? BTW, as of 2008-04-01 our company changed its name, again. It is now AVASYS Corporation, without the EPSON. :-D that's funny strategy :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] incompatible iscan-2.11.0
Alessandro Zummo azummo-lists at towertech.it writes: On Thu, 24 Apr 2008 16:05:32 +0900 Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Not yet. There are plans to at least provide updated plugins for the more recent models. Exactly which ones and when they will be released is up in the air. what's changed between the old and the new plugins that introduced incompatibilities? Well, there's only one new plugin at the moment, but we've added support for high resolutions (3200dpi) to iscan. On the backend side that means we are setting the horizontal and vertical resolutions independently based on information from the 'ESC i' command. The problem is that all those old plugin-requiring models don't accept just any ole combination of the two. In the new plugin, the one for the Perfection V500 PHOTO (GT-X770), I've doctored it so that feeding it an 'ESC i' returns only allowed combinations (depending on whether you want to scan from the flatbed or TPU or ADF) and all is well. The old plugins return info that more often than not results in an invalid argument, even for the lower resolutions. The result is that trying to use iscan-2.11.0 with those old plugins will make it just about impossible to scan anything. All you get are invalid argument errors. BTW, as of 2008-04-01 our company changed its name, again. It is now AVASYS Corporation, without the EPSON. :-D that's funny strategy :) Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] incompatible iscan-2.11.0
Hello, On Apr 24 16:50 Olaf Meeuwissen wrote (shortened): Johannes and I discussed the format of the comment entries after he started using what I had started adding on a voluntary basis. I was happy to know that the information was useful. Many thanks again! Yes, such information is more than just useful, it is mandatory so that I can provide good out-of-the-box support. To be precise the upload is done by the plugin, not by the backend. I wish I had the time for extract the upload bit into a separate utility that can be started from udev ... I would appreciate it so have a free firmware upload utility and the firmware files provided for download separated from the proprietary plugin. By the way: Compare how HP does the firmware upload for their proprietary crap models and see how happy I am about such bad hardware: https://bugs.launchpad.net/hplip/+bug/187049 --- The /etc/udev/rules.d/86-hpmu-hp_laserjet_1020.rules file, which is installed by hp-setup, controls the firmware download. The firmware should be downloaded at every lj1020 plug-and-play add event. . . . ... the firmware upload happens while the printer is in its internal startup procedure. It seems this stupid peice of cheapest hardware becomes totally confused if it gets data while it is in startup mode. When this has happened, no further usage is possible... --- The usual warm feeling in the udev plug-and-play hell... I must know which models require firmware upload so that I can inform our users when they try out a free backend where the firmware upload must be configured manually. Again a nice example which awkward things I do to deal with Epson Avasys' proprietary stuff in particular because their official policy is to not help distributors to package their proprietary stuff well and easily. Johannes, when did you ask? See the mail which I appended at the bottom. I can add the firmware files to the epkowa.desc file if you want Yes, please! It is very much better to have explicite information as a makeshift in a comment than no such info at all. but it would be nice if there were some extra fields Of course. I asked for firmware fields in *.desc some time ago here on this list, see http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015949.html As to the official policy bit, at least this developer here is not aware of any such policy and wonders how you found out about it. What else could I do when nobody who is responsible at Avasys talks to me than to deduce from what the actual results are in the past years? Whatever you may forward to those who are actually responsible to make decissions, the results of their decissions show clearly what their policy is and I just call this the official policy even when such a policy will be of course never officially announced by them. If you get the feeling that the incompatible iscan-2.11.0 is the last drop which wears away the stone of my patience and that I am at the end of my tether to care about the proprietary mess in IScan, you are 100% right. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex ##
[sane-devel] incompatible iscan-2.11.0
On Thu, 24 Apr 2008 18:44:42 +0900 Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Well, there's only one new plugin at the moment, but we've added support for high resolutions (3200dpi) to iscan. On the backend side that means we are setting the horizontal and vertical resolutions independently based on information from the 'ESC i' command. ack. One day I'll have to reverse engineer those new scanners and put and end to this nightmare. :( -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] incompatible iscan-2.11.0
On Thu, Apr 24, 2008 at 2:20 AM, Johannes Meixner jsmeix at suse.de wrote: Hello, On Apr 23 17:04 m. allan noah wrote (shortened): On 4/23/08, Julien BLACHE jb at jblache.org wrote: Well, without the non-free bits it provides better support for some scanner, and supports devices no other backend supports :) which scanners are those? I wonder if the best course of action would be to update the epson or epson2 backends to support those scanners, then you could drop epkowa. Use something like egrep ':model|:comment' doc/descriptions-external/epkowa.desc \ | grep -B1 ':comment.*non-free' no- go back and re-read my question. i want to know what models are supported by free software in epkowa backend, but not in epson/epson2 backend. allan -- The truth is an offense, but not a sin
[sane-devel] incompatible iscan-2.11.0
On Thu, 24 Apr 2008 09:33:48 -0400 m. allan noah kitno455 at gmail.com wrote: no- go back and re-read my question. i want to know what models are supported by free software in epkowa backend, but not in epson/epson2 backend. given that epkowa started from epson, I'd hope there is none. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] (no subject)
Hello,
Is there a possibility to determine a maximum of parameter like :
typedef struct
{
int optical_res; (OK, for me 2400)
int black_pixels;(don't know how to determine)
int dummy_pixel; (content of 0x34 ?)
int CCD_start_xoffset; (test of page upper border ?)
int sensor_pixels; (just 216/2.54*2400 ?)
int fau_gain_white_ref; (don't know how to determine)
int gain_white_ref; (don't know how to determine)
u_int8_t regs_0x08_0x0b[4]; (OK windows snoop)
u_int8_t regs_0x10_0x1d[14]; (OK windows snoop)
u_int8_t regs_0x52_0x5e[13]; (OK windows snoop)
float red_gamma; (don't know how to determine)
float green_gamma; (don't know how to determine)
float blue_gamma;(don't know how to determine)
u_int16_t *red_gamma_table; (OK NULL)
u_int16_t *green_gamma_table;(OK NULL)
u_int16_t *blue_gamma_table; (OK NULL)
} Genesys_Sensor;
or :
typedef struct
{
SANE_Int base_ydpi;(4800 ? : Lide90 is 2400x4800)
SANE_Int optical_ydpi; (4800 ? : Lide90 is 2400x4800)
SANE_Int max_step_type;(don't know how to determine)
SANE_Int power_mode_count; (don't know how to determine)
Genesys_Motor_Slope slopes[2][3]; (don't know how to determine)
} Genesys_Motor;
Guillaume Gastebois schrieb:
Hello,
I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to
port
that. I backend ready for 2400dpi (I think so regarding portion of code) ?
I am not sure, as there could not happen any testing. But in theory, it
should work. In the future, there should be some afford made to make
other resolutions than 2400, 1200 and 600 work, but these 3 are trivial
with this chip.
I write 2400 dpi in genesys_sensor for lide 90. But how to know pixel number
for
CCD sensor ?
I guess the manufacturer is not lying about the density of the ccd, so
that should be enough. The rest of the settings is in real units. The
backend calculates the exact number of pixel from the density and the
width of the scanning area.
After writing 2400 dpi in sensor, I get quarter sized images !!! Why ?
With 600 dpi in sensor I get full sized images with (300dpi scanning) or
without
half_ccd (1200dpi scanning) (with my code for gpio 14).
Regards
Guillaume
I'd first try to get the correct gpio setting for a full resolution
scan(i.E. at 2400dpi). If you cannot get a full-width-scan, look for the
DPISET register, and try half/twice the dpi there. Also, make sure the
DPIHW is set for the 2400dpi mode.
When that works, figure out how to setup gpios for half_ccd mode. From
the view of the current code base, you are done here. You can try to
find a quarter_ccd mode(which would show up as half-width in the
half_ccd modes), and leave a comment in the code, or even implement the
quarter_ccd mode for real.
Yes, DPIHW is 0x80 (2400dpi)
for 300dpi scanning dpiset is 0x258 (600). Is that good ?
I find that GPIO14 is quarter CCD but by testing all other unknown GPIOs I can't
find one for half CCD Strange no ?
Regards,
Pierre
I see too that If I is image and B is black, I get for 1200dpi, 600dpi, 300dpi
and 150dpi scanning :
1200 :
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
600 :
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
300 :
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
150 :
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
Why ?
Regards
Guillaume
[sane-devel] Doubt about sane_get_devices
Hi all Im just wanna know if this function retrives the list of devices at every moment. Let me explain, i launch my program with the scanner disconected, then i conect it and call this function. Doc say This function can be called repeatedly to detect when new devices become available but this is not my case, i get a null pointer. thanks in advance Tobias.
[sane-devel] Doubt about sane_get_devices
this depends entirely on the backend. i have tried to make sure that the backends i maintain will re-find scanners at every call, but other backends may not. allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: Hi all Im just wanna know if this function retrives the list of devices at every moment. Let me explain, i launch my program with the scanner disconected, then i conect it and call this function. Doc say This function can be called repeatedly to detect when new devices become available but this is not my case, i get a null pointer. thanks in advance Tobias. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
[sane-devel] Doubt about sane_get_devices
So in the fujitsu backend should work? On Thu, Apr 24, 2008 at 3:43 PM, m. allan noah kitno455 at gmail.com wrote: this depends entirely on the backend. i have tried to make sure that the backends i maintain will re-find scanners at every call, but other backends may not. allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: Hi all Im just wanna know if this function retrives the list of devices at every moment. Let me explain, i launch my program with the scanner disconected, then i conect it and call this function. Doc say This function can be called repeatedly to detect when new devices become available but this is not my case, i get a null pointer. thanks in advance Tobias. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
[sane-devel] Calling a script after USB scanner is plugged
Johannes, Am Donnerstag, 24. April 2008 schrieb Johannes Meixner: Hello, On Apr 23 22:53 Rainer Dorsch wrote: Am Mittwoch, 23. April 2008 schrieb Julien BLACHE: Johannes Meixner jsmeix at suse.de wrote: Hi, umax1220u scripts are started in a sequence (i.e. not in parallel, when one is completed the next one starts). When troubleshooting udev rules, use udevmonitor to actually see what's happening in terms of udev events and their properties. That was a very good hint, thanks. A single scanimage -L causes these events: UEVENT[1208979136.171525] remove /class/usb_endpoint/usbdev1.5_ep01 (usb_endpoint) UEVENT[1208979136.171696] remove /class/usb_endpoint/usbdev1.5_ep82 (usb_endpoint) UEVENT[1208979136.171702] remove /class/usb_endpoint/usbdev1.5_ep83 (usb_endpoint) UEVENT[1208979136.171707] add /class/usb_endpoint/usbdev1.5_ep01 (usb_endpoint) UEVENT[1208979136.171712] add /class/usb_endpoint/usbdev1.5_ep82 (usb_endpoint) UEVENT[1208979136.171717] add /class/usb_endpoint/usbdev1.5_ep83 (usb_endpoint) UDEV [1208979136.172276] remove /class/usb_endpoint/usbdev1.5_ep01 (usb_endpoint) UDEV [1208979136.172803] remove /class/usb_endpoint/usbdev1.5_ep82 (usb_endpoint) UDEV [1208979136.173239] remove /class/usb_endpoint/usbdev1.5_ep83 (usb_endpoint) UDEV [1208979136.174020] add /class/usb_endpoint/usbdev1.5_ep01 (usb_endpoint) UDEV [1208979136.174831] add /class/usb_endpoint/usbdev1.5_ep82 (usb_endpoint) UDEV [1208979136.175619] add /class/usb_endpoint/usbdev1.5_ep83 (usb_endpoint) I wonder how scanimage -L causes any add or remove event at all. I cannot imagine that those add or remove events are the same add or remove events which happen when the device is plugged-in at the USB or plugged-off from the USB. Judging from the udevmonitor output it seems they are at least very similar. Apparently the /class/usb_endpoint/usbdev1.6_ep00 is not included in the events of the scanimage call but it is included when I replug the device. This is the output of udevmonitor when replugging the device (commented out the udev rule which calls the script with scanimage): UEVENT[1209064961.290600] remove /class/usb_endpoint/usbdev1.6_ep01 (usb_endpoint) UEVENT[1209064961.290627] remove /class/usb_endpoint/usbdev1.6_ep82 (usb_endpoint) UEVENT[1209064961.290633] remove /class/usb_endpoint/usbdev1.6_ep83 (usb_endpoint) UEVENT[1209064961.290638] remove /devices/pci:00/:00:1a.0/usb1/1-1/1-1:1.0 (usb) UEVENT[1209064961.290643] remove /class/usb_device/usbdev1.6 (usb_device) UEVENT[1209064961.290648] remove /class/usb_endpoint/usbdev1.6_ep00 (usb_endpoint) UEVENT[1209064961.290653] remove /devices/pci:00/:00:1a.0/usb1/1-1 (usb) UDEV [1209064961.291029] remove /class/usb_endpoint/usbdev1.6_ep01 (usb_endpoint) UDEV [1209064961.291540] remove /class/usb_endpoint/usbdev1.6_ep82 (usb_endpoint) UDEV [1209064961.291973] remove /class/usb_endpoint/usbdev1.6_ep83 (usb_endpoint) UDEV [1209064961.292349] remove /devices/pci:00/:00:1a.0/usb1/1-1/1-1:1.0 (usb) UDEV [1209064961.292882] remove /class/usb_device/usbdev1.6 (usb_device) UDEV [1209064961.293363] remove /class/usb_endpoint/usbdev1.6_ep00 (usb_endpoint) UEVENT[1209064965.393967] add /devices/pci:00/:00:1a.0/usb1/1-1 (usb) UEVENT[1209064965.394013] add /class/usb_endpoint/usbdev1.7_ep00 (usb_endpoint) UEVENT[1209064965.398030] add /devices/pci:00/:00:1a.0/usb1/1-1/1-1:1.0 (usb) UEVENT[1209064965.398042] add /class/usb_endpoint/usbdev1.7_ep01 (usb_endpoint) UEVENT[1209064965.398048] add /class/usb_endpoint/usbdev1.7_ep82 (usb_endpoint) UEVENT[1209064965.398053] add /class/usb_endpoint/usbdev1.7_ep83 (usb_endpoint) UEVENT[1209064965.398058] add /class/usb_device/usbdev1.7 (usb_device) UDEV [1209064965.399964] add /devices/pci:00/:00:1a.0/usb1/1-1 (usb) UDEV [1209064965.401533] add /class/usb_endpoint/usbdev1.7_ep00 (usb_endpoint) UDEV [1209064965.401976] add /devices/pci:00/:00:1a.0/usb1/1-1/1-1:1.0 (usb) UDEV [1209064965.437713] add /class/usb_endpoint/usbdev1.7_ep01 (usb_endpoint) UDEV [1209064965.437730] add /class/usb_endpoint/usbdev1.7_ep82 (usb_endpoint) UDEV [1209064965.437736] add /class/usb_endpoint/usbdev1.7_ep83 (usb_endpoint) UDEV [1209064965.448441] add /class/usb_device/usbdev1.7 (usb_device) These are the events from a scanimage -L: UEVENT[1209064997.544063] remove /class/usb_endpoint/usbdev1.7_ep01 (usb_endpoint) UEVENT[1209064997.544262] remove /class/usb_endpoint/usbdev1.7_ep82 (usb_endpoint) UEVENT[1209064997.544301] remove /class/usb_endpoint/usbdev1.7_ep83 (usb_endpoint) UEVENT[1209064997.544337] add /class/usb_endpoint/usbdev1.7_ep01 (usb_endpoint) UEVENT[1209064997.544372] add /class/usb_endpoint/usbdev1.7_ep82
[sane-devel] incompatible iscan-2.11.0
Johannes Meixner jsmeix at suse.de wrote: esfw41.bin: Perfection 2480 PHOTO / GT-F500, Perfection 2580 PHOTO / GT-F550 Supported by the snapscan backend, same for the 3490 and 3590 IIRC. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Calling a script after USB scanner is plugged
Johannes Meixner jsmeix at suse.de wrote: Hi, I wonder how scanimage -L causes any add or remove event at all. I cannot imagine that those add or remove events are the same add or remove events which happen when the device is plugged-in at the USB or plugged-off from the USB. Not sure about this, but it's possible the endpoints are removed when they're in use and readded once they're no longer used. Do you know what those different usb_endpoints are? They're USB endpoints. An element of the USB interface/protocol. Perhaps the different USB interfaces for the one USB device? They're the USB endpoints offered by the device :) I wonder how one could specify a udev rule which matches to the one add event for the one USB device instead of whatever bulk of add events for whatever stuff which is related to the one USB device. See the top of the libsane udev rules ? :) JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Question about Genesys_Frontend
Hello,
In genesys backend, we can find :
typedef struct
{
u_int8_t reg[4];
u_int8_t sign[3];
u_int8_t offset[3];
u_int8_t gain[3];
u_int8_t reg2[3];
} Genesys_Frontend;
but in WM8199 regs don't have the same name.
For me registers addresses are :
reg[0]=0x01,reg[1]=0x02,reg[2]=0x03,reg[3]=0x06,
sign[0]=?,sign[1]=?,sign[2]=?,
offset[0]=0x20,offset[1]=0x21,offset[2]=0x22,
gain[0]=0x28,gain[1]=0x29,gain[2]=0x2a,
reg2[0]=0x08,reg2[1]=0x09,reg2[2]=?,
I anybody able to replace ? and/or correct mistakes in text before ?
Thanks
Regards
Guillaume
[sane-devel] Calling a script after USB scanner is plugged
Johannes Meixner jsmeix at suse.de wrote:
Hi,
Be careful with the labels you use. Always use a unique label name, or
you're asking for troubles. (been there, done that, accidentally
rendered a number of systems unbootable due to that ...)
Many thanks for this enlightening info!
Impressive: A thoroughly thought out fail-safe design!
udev is an incredible piece of crap, but the good news is that this
piece of crap is mostly stable those days. Which is a big step forward
already.
(and I'll refrain from saying anything at all about the genius who
invented udev. I'll just mention that he's also the author of stable
API is a nonsense.)
I can only guess that what udev actually does is to
concatenate all udev rules files into one single set
of rules and then it is not surprising when arbitrary
nonsense happens depending on which individual udev rules
files exist on a particular system which depends on which
individual software packages are installed on this system.
You got it.
Very nice to debug!
deWHAT?
I tried that before after I saw the z60_libsane.rules
ACTION!=add, GOTO=post_lamp_off
SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, MODE=0664,
GROUP=scanner, NAME=umax%n, RUN+=/usr/local/bin/umax1220u start,
ENV{lamp_off}=yes
LABEL=post_lamp_off
But given the events, it is obvious not surprising that this is not working.
Is anybody aware of a more elegant solution for this problem?
You need to copy a bit more than that from. See the top of the file,
there's more to it than that, also the way to identify a USB device
event changed starting with 2.6.22 and the rules are
backward-compatible in this respect too.
You cannot have udev and elegant at the same time
Actually, you can, but you need a bit of udev/uevent knowledge and
some time on your hands.
and you cannot have HAL and elegant at the same time.
It's all HALegant, pff.
Welcome to udev-land, Johannes!
JB.
--
Julien BLACHE http://www.jblache.org
jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Doubt about sane_get_devices
it should, but i take it from your question that it does not? :) allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: So in the fujitsu backend should work? On Thu, Apr 24, 2008 at 3:43 PM, m. allan noah kitno455 at gmail.com wrote: this depends entirely on the backend. i have tried to make sure that the backends i maintain will re-find scanners at every call, but other backends may not. allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: Hi all Im just wanna know if this function retrives the list of devices at every moment. Let me explain, i launch my program with the scanner disconected, then i conect it and call this function. Doc say This function can be called repeatedly to detect when new devices become available but this is not my case, i get a null pointer. thanks in advance Tobias. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin -- The truth is an offense, but not a sin
[sane-devel] Doubt about sane_get_devices
ahh, but you dont just query the list again, you call sane_exit and sane_init first. just call sane_get_devices, and see if that helps. allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: Nop, doesnt work. Maybe im doing something wrong. I got this logs. Log 1 ##Start the program with scanner disconnected [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e1' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e7' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10f2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10fe' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1135' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x114d' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1155' [fujitsu] find_scanners: found 0 scanner(s) [fujitsu] find_scanners: finish [fujitsu] sane_get_devices: finish ##Connect scanner and wait a seconds, query list [fujitsu] sane_exit: start [fujitsu] sane_exit: finish [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e1' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e7' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10f2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10fe' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1135' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x114d' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1155' [fujitsu] find_scanners: found 0 scanner(s) [fujitsu] find_scanners: finish [fujitsu] sane_get_devices: finish [fujitsu] sane_exit: start [fujitsu] sane_exit: finish Log 2 [doors at localhost ~]$ export SANE_DEBUG_FUJITSU=30 [doors at localhost ~]$ doors [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] attach_one: start [fujitsu] attach_one: looking for 'libusb:003:003' [fujitsu] connect_fd: start [fujitsu] connect_fd: opening USB device [fujitsu] wait_scanner: start [fujitsu] do_usb_cmd: start [fujitsu] cmd: writing 31 bytes, timeout 500 [fujitsu] cmd: [fujitsu] 000: 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
