[sane-devel] Problem with libusb and 64 bits 2.6.25 kernel
Sam V. posted recently a bug report with a 64 bits kernel, running the pixma backend and a MF-4270 Canon MFP. Details here: https://alioth.debian.org/tracker/?group_id=30186&atid=410366&func=detail&aid=310861 He has the pixma backend running fine with a 32 bits kernel (same version as 64 bits) in same conditions. On a 64 bits 2.6.25 kernel (Fedora 9) or 2.6.24 (Ubuntu), the logs show that sometimes (but not always, that's why scanning finally works, but takes very long time), there appears to be a: "Resource temporarily unavailable" error for read calls, from either sanei_usb_read_int() or sanei_usb_read_bulk(). They are triggered by usb_bulk_read() or usb_interrupt_read() calls from libusb. This error induces the timeouts, thus long scanning time. There do not appear to be errors on write calls (this would make scanning fail). I don't know what could cause this libusb error for the 64 bits kernel ? Anyone here already experienced this, or would have a clue ? Nicolas
[sane-devel] Problem with libusb and 64 bits 2.6.25 kernel
two random thoughts- 1. can he try 32 bit kernel on same exact machine, just to rule out hardware problems? 2. is there a pattern to the timeouts, like always same number of errors before a good packet? allan On 5/26/08, Nicolas wrote: > Sam V. posted recently a bug report with a 64 bits kernel, running the > pixma backend and a MF-4270 Canon MFP. > > Details here: > > > https://alioth.debian.org/tracker/?group_id=30186&atid=410366&func=detail&aid=310861 > > He has the pixma backend running fine with a 32 bits kernel (same > version as 64 bits) in same conditions. > > On a 64 bits 2.6.25 kernel (Fedora 9) or 2.6.24 (Ubuntu), the logs show > that sometimes (but not always, that's why scanning finally works, but > takes very long time), there appears to be a: > > "Resource temporarily unavailable" > > error for read calls, from either sanei_usb_read_int() or > sanei_usb_read_bulk(). They are triggered by usb_bulk_read() or > usb_interrupt_read() calls from libusb. > > This error induces the timeouts, thus long scanning time. > > There do not appear to be errors on write calls (this would make > scanning fail). > > I don't know what could cause this libusb error for the 64 bits kernel ? > > Anyone here already experienced this, or would have a clue ? > > Nicolas > > > > -- > 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] Re : CanoScan LiDE90 support
Hello, I work on, but don't know when It'll be good working. > I want to ask if anyone can tell me if there is any hope to have > support in sane for this model of scanner. Thanks in advance. >
[sane-devel] SANE 1.1 impacts on sane-frontends
> > Hello, > > > > I have started to change sane-frontends to handle new status > > code > > from SANE > > 1.1 . But before any commit, I suppose one should tag current > > sources. > > > > new status code ? > Hmm where should I snoop to know what to change ? > I might have to update Sanity later... > Or maybe Philippe is reading this ? > Forget it I just found the feature list. Fran?ois.
[sane-devel] SANE 1.1 impacts on sane-frontends
> Hello, > > I have started to change sane-frontends to handle new status code > from SANE > 1.1 . But before any commit, I suppose one should tag current > sources. > new status code ? Hmm where should I snoop to know what to change ? I might have to update Sanity later... Or maybe Philippe is reading this ?
[sane-devel] SANE 1.1.0 Release discussion
Hi, ps: this time to the list as well :-) m. allan noah wrote: > On 5/26/08, Ren? Rebe wrote: >> Hi Allan, >> >> can you explain the paper width option to me? Why can we >> not simply use br x/y? >> >> Actually I got a Fujitsu scanner here and find the duplicate >> paper width option annoying at best. > > it is not duplicate. it is used by the backend to properly center the > users x/y params to the moving paper guides. otherwise, if they want > to scan an entire sheet of A5, they have to set the tl_x/y to some > weird value that they have to calculate from the scanner's maximum > width. > how do you handle this in avision now? not at all, I consider this a front end job, it also avoids the simple arithmetic in every backend. The page size then also appears to indirectly change the maximal scan area? I find this way more "complex" than just allow frontends to center the scan area on the maximal area. >> Aside the already mentioned button to use some more extend-able >> XML encoding instead of a hardcoded set, I wonder if it is >> good to expose sensors, frontends would rarely (if ever?) want >> to check for them explicitly and the backend must check the >> sensors before or during scan to generate proper errors >> accordingly anyway. > > don't assume that sensors only indicate errors. the paper-in signal is > quite useful in high volume apps- the front-end can start scanning > immediately. Ah ok, media presense is indeed useful, granted. One could also start scaning on cover close, indeed. I was just afraid on exposing random sensors (home, etc.) without a real need. > xml does not fix this problem, cause we would still have to define a > schema so that front-ends could interpret it. so, lets just avoid the > xml dependency. Still, many Avisions have Simplex / Duplex buttons, and some, like the HP 7400, allow resolution, color mode, and number of copies to be set on the device. How would you like to handle those then (and yes, the Avision backend does not export the 7400 options, yet, as I had no idea, beside a pre-formated string message, how to expose them)? The problem with letting some buttons change the backend internal state configuration (resolution et al.) and some be exposed to the frontend (scan, fax, print) exposes two problems: One the frontend UI (if any) does not update when the user changes scanner values, and second may yield to scans with other parameters than the frontend believed to scan with. Having one flow of hardware "notifications" might be more structured and frontend friendly. Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] SANE 1.1.0 Release discussion
Hi, > but what is the frontend going to do with that, read the user's > setting, then turn the data back around and set the resolution and > duplex options? it seems that would be better done in the backend > itself.? But the frontend should be aware that the device has changed some value, at least in order to update UI. I think that simply adding cap HARD_SELECT should be enough to tell the frontend : poll this if you want to know when the user change the value of this option from the device. Regards, ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
Hi Allan,
can you explain the paper width option to me? Why can we
not simply use br x/y?
Actually I got a Fujitsu scanner here and find the duplicate
paper width option annoying at best.
Aside the already mentioned button to use some more extend-able
XML encoding instead of a hardcoded set, I wonder if it is
good to expose sensors, frontends would rarely (if ever?) want
to check for them explicitly and the backend must check the
sensors before or during scan to generate proper errors
accordingly anyway.
Yours,
m. allan noah wrote:
> ok guys- take 3:
>
> Six general points for sane 1.1.x:
> - no changes to function calls
> - no changes to structures
> - 1.0 backends forward compatible with 1.1
> - improve backend consistency
> - support more advanced scanners
> - improve cooperation with modern system services
>
> Specific proposals:
>
> 1. Consistent, translatable option groups:
>
> 'Standard' = source, mode, resolution
> 'Geometry' = x/y and paper size params
> 'Enhancement' = bright/gamma/contrast/thresh, rif, halftone, etc
> 'Advanced' = compression, calibration, feed controls, etc
> 'Sensors' = an option for every hardware button or sensor
>
> 2. Two new well-known options for ADF paper alignment: page-width and
> page-height
>
> 3. Two new SANE_STATUS values: HW_LOCKED and WARMING_UP
>
> 4. Nine new SANE_FRAME values: TEXT, JPEG, G31D, G32D, G42D, IR, RGBI,
> GRAYI, and XML
>
> 5. Several new well-known options for buttons and sensors. Backends
> should use the closest one to the meaning of the label on the scanner
> or the button's use in the manufacturer's software. Backends may also
> use a different name if no suitable one is found, or button1, etc for
> unlabeled buttons
>
> well-known buttons:
> scan, email, fax, copy, pdf, cancel
>
> well-known sensors:
> page-loaded, cover-open
>
> 6. Clarify standard text for SANE_CAP_HARD_SELECT to indicate it
> should be used for polling the current state of hardware sensors and
> buttons, with a refresh interval <= 1 sec.
>
> 7. New DBGBM macro for bitmask debugging output (bit # listed below):
>
> 1 DBG_LVL_ERROR (errors only)
> 2 DBG_LVL_FUNC (function tracing 'enter xxx()' or 'exit xxx()')
> 3 DBG_LVL_DETAIL ('trying action X' or 'action succeeded' etc)
> 4 DBG_LVL_OPTION (any sane_option parsing code)
> 5 DBG_LVL_CALIB (calibration info)
> 6 DBG_LVL_IMAGE (dump image data read from scanner)
> 7 DBG_LVL_DATA (dump data packets read from scanner, other than
> image or cal?)
> 8 DBG_LVL_FILE (write internal data files to disk from within backend?)
>
> 8. Add common configuration reading function in sanei_* so that new or
> maintained backends can benefit from it. Wholesale config file restructuring?
>
> 9. Require backends to always accept the sanei device name as an
> alternative to the backend generated name.
>
> The first 5 are already in SANE CVS, and the fujitsu backend is
> updated to use them. I'd like to get some more comment on the rest
> before we more forward. Particularly on #8, if your backend uses a
> complex config file format, we need to hear from you...
>
> Timetable is still feature freeze around July 4th, and release close
> to July 30th.
>
> Comments welcome-
>
> allan
--
Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
Gesch?ftsf?hrer: Susanne Klaus, Ren? Rebe
Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
USt-IdNr.: DE251602478
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] Problem with avision and HP ScanJet 8250 on Mac OS X 10.5.2
Dear David, I do not have a device for testing. The SANE CVS might or might not work better. If it does not work better on your device you could donate a device for testing and it should be fixable quickly. Alternative, if you know C, you could try and debug the problem. Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin Gesch?ftsf?hrer: Susanne Klaus, Ren? Rebe Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B USt-IdNr.: DE251602478 http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] SANE 1.1.0 Release discussion
Hi, some scanners even have simplex / duplex buttons or even fine grained to up/down arrows to setup resolution, color mode etc. (i.g. the popular HP 7400). In the Avision backend I know use a string option to spit out a message the program can parse. Going with the current trend, maybe a xml string should be used to describe whatever is setup on the device? Yours, m. allan noah wrote: > or perhaps scan2 or altscan? > > allan > > On 5/25/08, JKD wrote: >> El Wednesday 21 May 2008 20:50:46 m. allan noah escribi?: >> >> >> > 5. Several new well-known options for buttons and sensors. Backends >> > should use the closest one to the meaning of the label on the scanner >> > or the button's use in the manufacturer's software. Backends may also >> > use a different name if no suitable one is found, or button1, etc for >> > unlabeled buttons >> > >> > well-known buttons: >> > scan, email, fax, copy, pdf, cancel >> >> >> Some scanners have different buttons to perform a normal scan and >> negative/slide scans. May be another well-kown button name could be >> something >> like scan_film >> >> Jonathan >> >> >> -- >> La m?quina m?s segura es una m?quina apagada >> >> >> -- >> 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 >> > > -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin Gesch?ftsf?hrer: Susanne Klaus, Ren? Rebe Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B USt-IdNr.: DE251602478 http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] SANE 1.1.0 Release discussion
Hi, > or perhaps scan2 or altscan? No ! you need to keep to semantic ! altscan or scan is not selfexplanatory. Please prefer "film" or "scan-film". We should also state whether we should use "_" or "-" in option name. I guess that the standard is lowercase + hyphen + digit. ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
On 5/26/08, Ren? Rebe wrote: > Hi, > > ps: this time to the list as well :-) > > m. allan noah wrote: > > > On 5/26/08, Ren? Rebe wrote: > > > > > Hi Allan, > > > > > > can you explain the paper width option to me? Why can we > > > not simply use br x/y? > > > > > > Actually I got a Fujitsu scanner here and find the duplicate > > > paper width option annoying at best. > > > > > > > it is not duplicate. it is used by the backend to properly center the > > users x/y params to the moving paper guides. otherwise, if they want > > to scan an entire sheet of A5, they have to set the tl_x/y to some > > weird value that they have to calculate from the scanner's maximum > > width. > > how do you handle this in avision now? > > > > not at all, I consider this a front end job, it also avoids the simple > arithmetic in every backend. The page size then also appears to indirectly > change the maximal scan area? I find this way more "complex" than just > allow > frontends to center the scan area on the maximal area. ahh, but you assume that the paper guides always center the paper. i have a lexmark that i am working on, which has only one moving paper guide. this code should be done in the backend, especially since it is so simple :) > > > Aside the already mentioned button to use some more extend-able > > > XML encoding instead of a hardcoded set, I wonder if it is > > > good to expose sensors, frontends would rarely (if ever?) want > > > to check for them explicitly and the backend must check the > > > sensors before or during scan to generate proper errors > > > accordingly anyway. > > > > > > > don't assume that sensors only indicate errors. the paper-in signal is > > quite useful in high volume apps- the front-end can start scanning > > immediately. > > > > Ah ok, media presense is indeed useful, granted. One could also > start scaning on cover close, indeed. I was just afraid on exposing > random sensors (home, etc.) without a real need. > > > > xml does not fix this problem, cause we would still have to define a > > schema so that front-ends could interpret it. so, lets just avoid the > > xml dependency. > > > > Still, many Avisions have Simplex / Duplex buttons, and some, like the > HP 7400, allow resolution, color mode, and number of copies to be > set on the device. How would you like to handle those then (and yes, > the Avision backend does not export the 7400 options, yet, as I had > no idea, beside a pre-formated string message, how to expose them)? > > The problem with letting some buttons change the backend internal > state configuration (resolution et al.) and some be exposed to the > frontend (scan, fax, print) exposes two problems: One the frontend > UI (if any) does not update when the user changes scanner values, > and second may yield to scans with other parameters than the frontend > believed to scan with. Having one flow of hardware "notifications" > might be more structured and frontend friendly. you have a good point, but only if the button names dont collide with existing options, or we need a boolean control that the user can use to state that those options are gotten from hardware... allan -- "The truth is an offense, but not a sin"
[sane-devel] SANE 1.1.0 Release discussion
On 5/26/08, ?tienne Bersac wrote: > Hi, > > > > but what is the frontend going to do with that, read the user's > > setting, then turn the data back around and set the resolution and > > duplex options? it seems that would be better done in the backend > > > itself.? > > But the frontend should be aware that the device has changed some value, > at least in order to update UI. I think that simply adding cap > HARD_SELECT should be enough to tell the frontend : poll this if you > want to know when the user change the value of this option from the > device. ahh, but the option cannot be both HARD and SOFT_SELECT at the same time. for this very reason, i dont actually use the duplex button on the older fujitsu machines to change the duplex setting in the backend. allan -- "The truth is an offense, but not a sin"
[sane-devel] SANE 1.1.0 Release discussion
sorry rene- this should have gone to list... On 5/26/08, m. allan noah wrote: > On 5/26/08, Ren? Rebe wrote: > > > Hi Allan, > > > > can you explain the paper width option to me? Why can we > > not simply use br x/y? > > > > Actually I got a Fujitsu scanner here and find the duplicate > > paper width option annoying at best. > > > it is not duplicate. it is used by the backend to properly center the > users x/y params to the moving paper guides. otherwise, if they want > to scan an entire sheet of A5, they have to set the tl_x/y to some > weird value that they have to calculate from the scanner's maximum > width. > how do you handle this in avision now? > > > > > > Aside the already mentioned button to use some more extend-able > > XML encoding instead of a hardcoded set, I wonder if it is > > good to expose sensors, frontends would rarely (if ever?) want > > to check for them explicitly and the backend must check the > > sensors before or during scan to generate proper errors > > accordingly anyway. > > > don't assume that sensors only indicate errors. the paper-in signal is > quite useful in high volume apps- the front-end can start scanning > immediately. > > xml does not fix this problem, cause we would still have to define a > schema so that front-ends could interpret it. so, lets just avoid the > xml dependency. > > > allan > -- > "The truth is an offense, but not a sin" > -- "The truth is an offense, but not a sin"
[sane-devel] SANE 1.1.0 Release discussion
On 5/26/08, Ren? Rebe wrote: > Hi, > > some scanners even have simplex / duplex buttons or even fine grained > to up/down arrows to setup resolution, color mode etc. (i.g. the > popular HP 7400). right- but what is the frontend going to do with that, read the user's setting, then turn the data back around and set the resolution and duplex options? it seems that would be better done in the backend itself. > > In the Avision backend I know use a string option to spit out > a message the program can parse. > > Going with the current trend, maybe a xml string should be used > to describe whatever is setup on the device? i see no point in this, however, it does point to an interesting problem. all these buttons are now semantically named, so you wont be able to have one called 'resolution', since you already have an option with that name. should we prefix these with 'button-' or some such? allan -- "The truth is an offense, but not a sin"
[sane-devel] SANE 1.1.0 Release discussion
On 5/26/08, ?tienne Bersac wrote: > Hi, > > > > or perhaps scan2 or altscan? > > > No ! you need to keep to semantic ! altscan or scan is not > selfexplanatory. Please prefer "film" or "scan-film". i doubt any frontend is going to code distinct support for such a unique button, but we can craft the standard to state than any alternate buttons should be named 'scan-xxx' or some such. however, we are shooting for a list of common names, not everything. > > We should also state whether we should use "_" or "-" in option name. I > guess that the standard is lowercase + hyphen + digit. > you are correct about the standard. allan -- "The truth is an offense, but not a sin"
[sane-devel] SANE 1.1 impacts on sane-frontends
Hello, I have started to change sane-frontends to handle new status code from SANE 1.1 . But before any commit, I suppose one should tag current sources. Regards, Stef
