[sane-devel] frame and batch mode
m. allan noah wrote: On Dec 18, 2007 12:37 PM, Jonathan Buzzard jonathan at buzzard.me.uk wrote: On Tue, 2007-12-18 at 08:40 -0500, m. allan noah wrote: On 12/18/07, Giuseppe Sacco giuseppe at eppesuigoccas.homedns.org wrote: Il giorno mar, 18/12/2007 alle 12.00 +, Jonathan Buzzard ha scritto: On Tue, 2007-12-18 at 12:13 +0100, Giuseppe Sacco wrote: [...] So, my questions: is there already any standard for those action? Is there any defined rule for how to name a backend parameter like --frame-number? Is there any way to know what feeder types are available at a given time? Good grief, those feelings of d?ja vu. are pretty strong at the moment. The basics are that as it stands the SANE standard is heavily geared to transmission scanning on flatbed scanners. Understandable as it probably accounts for 99% of users requirements. Is this problem solved with SANE2? would both of you please excuse my ignorance, as i primarily deal with ADF machines, but- why does the front-end need to be involved in the movement at all? can the backend not detect the additional slides and move the feeder automatically? perhaps i am not picturing the mechanism correctly... Imagine I have just stuck an APS adaptor into my film scanner and loaded up a 40 frame APS film. I wish to scan *one* frame which I happen to know from the contact print I got when they where developed. How without the front end telling the scanner which frame to advance to and scan do you propose scanning this? From memory a TIFF image from an APS frame on my scanner is about 30MB and takes about 1min over 400Mbps Firewire. Scanning the lot is utterly impractical. With 35mm film, I load the strip into a holder and insert the holder. I want to scan just two frames from the possible six in the holder, and they are frame 2 and 4. Oh and I want to scan 4 first so that it is not sticking out the scanner with dust settling on it. Does that illustrate the point? yes- though i did have to lookup what APS was :) the original question was what to name the SANE options that would control this mess, and i suppose what option type they should be. sounds almost like a comma-separated list: 4,2 or 4,2-1 if you wanted to skip #3. that sounds a bit like the gamma vector control that some backends use... I would say more like selecting pages to print so 4,2 or 4,2,1 or 4-1 for frames 4 through 1. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195
[sane-devel] Lexmark X1180 - weird noises :/
Le Monday 17 December 2007 22:28:19 gottox at s01.de, vous avez ?crit?: Hi! I got a problem with a Lexmark X1180. The scanner starts making weird noises when I scan. There's a similiar Bug report: http://alioth.debian.org/tracker/?group_id=30186atid=410366func=detailai d=303960 This bug report is against 1.0.18 which hasn't an updated lexmark backend and so won't work. Is there some workaround or fix? regards Gottox the output of sane-find-scanner -v -v: This is sane-find-scanner from sane-backends 1.0.18-cvs However, the sane-find-scanner test was done with a recent CVS version which has an updated backend. trying to find out which USB chip is used checking for GT-6801 ... this is not a GT-6801 (bDeviceClass = 0) checking for GT-6816 ... this is not a GT-6816 (bNumEndpoints = 3) checking for GT-8911 ... this is not a GT-8911 (check 5, bNumEndpoints = 3) checking for MA-1017 ... this is not a MA-1017 (bDeviceClass = 0, bInterfaceClass = 255) checking for MA-1015 ... this is not a MA-1015 (bDeviceClass = 0) checking for MA-1509 ... this is not a MA-1509 (bDeviceClass = 0) checking for LM983[1,2,3] ... this is not a LM983x (bEndpointAddress = 0x81, bmAttributes = 0x2, wMaxPacketSize = 0x40, bInterval = 0x0) checking for GL646 ... this is not a GL646 (bDeviceClass = 0, bInterfaceClass = 255) checking for GL646_HP ... this is not a GL646_HP (bDeviceClass = 0, bInterfaceClass = 255) checking for GL660+GL646 ... this is not a GL660+GL646 (bDeviceClass = 0, bInterfaceClass = 255) checking for GL841 ... this is not a GL841 (bDeviceClass = 0, bInterfaceClass = 255) checking for ICM532B ... this is not a ICM532B (check 1, bDeviceClass = 0, bInterfaceClass = 255) checking for PV8630/LM9830 ... this is not a PV8630/LM9830 (bcdUSB = 0x110) checking for M011 ... this is not a M011 (bDeviceClass = 0) checking for RTS8822L-01H ... this is not a RTS8822L-01H (bEndpointAddress = 0x81, bmAttributes = 0x2, wMaxPacketSize = 0x40, bInterval = 0x0) checking for rts8858c ... This USB chip looks like a rts8858c (result from sane-backends 1.0.18-cvs) found USB scanner (vendor=0x043d, product=0x007c, chip=rts8858c) at libusb:003:003 - End forwarded message - Did your scan tests done with a recent CVS version ? If this is the case, can you run 'scanimage -d lexmark 2scan.log scan.pnm' from the command line after setting these environment variables: export SANE_DEBUG_LEXMARK=255 export SANE_DEBUG_LEXMARK_LOW=255 Then send the 'scan.log' file to the list (if compressed log is below the 4K attachment threshold on the mailing list) or directly to Fred and me, so that we can try to understand what's going on. The output of a simple 'scanimage -L 21 probe.log' with these variables set would also be interesting. Regards, Stef
[sane-devel] permission request
Le Tuesday 18 December 2007 21:01:50 Gerhard Jaeger, vous avez ?crit?: Am Dienstag, 18. Dezember 2007 15:03:59 schrieb Alessandro Zummo: I would like, in the interest of the SANE community of users and developers, to kindly ask the permission to add some much required frame types to the repository. Given that: - some types are already in use by in-repository backends - other types are in use by external backends - the JPEG frame type has already been added - any well written frontend will not notice the change - the new types are not active by default I ask you to ease the work of backend authors and allow this much requested change. No objections from here - but, will we branch off 1.1.0 and have 1.0.x as maintenance branch? What about the future of sane2? - Gerhard Hello, if a branch is created, to support new data formats, could it be done to handle them the way (or a subset of) SANE2 is planned to do it? So that we move incrementally toward SANE2. Regards, Stef
[sane-devel] permission request
On Wed, 19 Dec 2007 06:57:27 +0100 stef stef.dev at free.fr wrote: Hello, if a branch is created, to support new data formats, could it be done to handle them the way (or a subset of) SANE2 is planned to do it? So that we move incrementally toward SANE2. I don't think so, because that would mean you really have to implement SANE2. The purpose of the SANE 1.1 branch is to keep compatibility with 1.0 . -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Canon MP140 Support
Hello, Can anyone shed some light on SANE support for the Canon PIXMA MP140 scanner/printer. I see the MP130 and MP150 are documented in the supported devices list but not the MP140. Thanks
[sane-devel] Formulardaten
=== == Neuer Eintrag === --- -- Formular: 'adddev' --- 1. Your email address: 'hoffmann_jens at web.de' 2. Manufacturer (e.g. Mustek): 'Hewlet Packard' 3. Model name (e.g. ScanExpress 1200UB): 'hp scanjet 4400c USB' 4. Bus type: 'USB' 5. Vendor id (e.g. 0x001): '' 6. Product id (e.g. 0x0002): '' 7. Chipset (e.g. lm9831): '' 8. Comments (e.g. similar to Mustek 1234): 'hp scanjet 4400c similar to Realtek RTS8891 ?? ' 9. Data (e.g. sane-find-scanner -v -v): 'This is sane-find-scanner from sane-backends 1.0.18-cvs # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. searching for SCSI scanners: checking /dev/scanner... failed to open (Invalid argument) checking /dev/sg0... failed to open (Access to resource has been denied) checking /dev/sg1... failed to open (Invalid argument) checking /dev/sg2... failed to open (Invalid argument) checking /dev/sg3... failed to open (Invalid argument) checking /dev/sg4... failed to open (Invalid argument) checking /dev/sg5... failed to open (Invalid argument) checking /dev/sg6... failed to open (Invalid argument) checking /dev/sg7... failed to open (Invalid argument) checking /dev/sg8... failed to open (Invalid argument) checking /dev/sg9... failed to open (Invalid argument) checking /dev/sga... failed to open (Invalid argument) checking /dev/sgb... failed to open (Invalid argument) checking /dev/sgc... failed to open (Invalid argument) checking /dev/sgd... failed to open (Invalid argument) checking /dev/sge... failed to open (Invalid argument) checking /dev/sgf... failed to open (Invalid argument) checking /dev/sgg... failed to open (Invalid argument) checking /dev/sgh... failed to open (Invalid argument) checking /dev/sgi... failed to open (Invalid argument) checking /dev/sgj... failed to open (Invalid argument) checking /dev/sgk... failed to open (Invalid argument) checking /dev/sgl... failed to open (Invalid argument) checking /dev/sgm... failed to open (Invalid argument) checking /dev/sgn... failed to open (Invalid argument) checking /dev/sgo... failed to open (Invalid argument) checking /dev/sgp... failed to open (Invalid argument) checking /dev/sgq... failed to open (Invalid argument) checking /dev/sgr... failed to open (Invalid argument) checking /dev/sgs... failed to open (Invalid argument) checking /dev/sgt... failed to open (Invalid argument) checking /dev/sgu... failed to open (Invalid argument) checking /dev/sgv... failed to open (Invalid argument) checking /dev/sgw... failed to open (Invalid argument) checking /dev/sgx... failed to open (Invalid argument) checking /dev/sgy... failed to open (Invalid argument) checking /dev/sgz... failed to open (Invalid argument) # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) checking /dev/usb/scanner1... failed to open (Invalid argument) checking /dev/usb/scanner2... failed to open (Invalid argument) checking /dev/usb/scanner3... failed to open (Invalid argument) checking /dev/usb/scanner4... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner7... failed to open (Invalid argument) checking /dev/usb/scanner8... failed to open (Invalid argument) checking /dev/usb/scanner9... failed to open (Invalid argument) checking /dev/usb/scanner10... failed to open (Invalid argument) checking /dev/usb/scanner11... failed to open (Invalid argument) checking /dev/usb/scanner12... failed to open (Invalid argument) checking /dev/usb/scanner13... failed to open (Invalid argument) checking /dev/usb/scanner14... failed to open (Invalid argument) checking /dev/usb/scanner15... failed to open (Invalid argument) checking /dev/usbscanner... failed to open (Invalid argument) checking /dev/usbscanner0... failed to open (Invalid argument) checking /dev/usbscanner1... failed to open (Invalid argument) checking /dev/usbscanner2... failed to open (Invalid argument) checking /dev/usbscanner3... failed to open (Invalid argument) checking /dev/usbscanner4... failed to open (Invalid argument) checking /dev/usbscanner5... failed to open (Invalid argument) checking /dev/usbscanner6... failed to open (Invalid argument) checking /dev/usbscanner7... failed to open (Invalid argument) checking /dev/usbscanner8... failed to open (Invalid argument) checking /dev/usbscanner9... failed to open (Invalid argument) checking
[sane-devel] permission request
On 12/19/07, Alessandro Zummo azummo-lists at towertech.it wrote: On Wed, 19 Dec 2007 06:57:27 +0100 stef stef.dev at free.fr wrote: Hello, if a branch is created, to support new data formats, could it be done to handle them the way (or a subset of) SANE2 is planned to do it? So that we move incrementally toward SANE2. I don't think so, because that would mean you really have to implement SANE2. The purpose of the SANE 1.1 branch is to keep compatibility with 1.0 . agreed- it seems that we have had so much trouble getting started on sane2 because it is so large and may have incompatibilites with sane1, making it hard to test. my idea was to move forward in smaller steps, trying to keep compatibility, so that old backends require no modifications. allan -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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] Suggestion for new A4 flatbed scanner with DIA/Film scanning capabilities (e.g. Epson V350) with USB 2.0
Hi everybody, after a nightmare of searching the web for the right scanner and asking in IRC my last hope is this mailing list. What I'm looking for: A4 flatbed scanner with transparency scanning for films and negatives (4800 dpi optical) for amateurs with USB 2.0 What have i done: I checked the SANE:supported device list, the mailing list history for some models, Linux and BSD hardware sites The result: nearly nothing besides headaches :( Best hits are: 1. Epson Perfection 4990: Complete support by sane, but with 400 Euro really to expensive for amateur photos :-( (For this price I could by a second Wintel PC only for scanning and a cheaper windows scanner) 2. Epson Photo V350 - is supported by a closed source driver. ADF is not supported, so I can also use the Epson Photo V200. But the same driver, so no support for 64bit Linux and BSD or Solaris. Same for the Perfection 4490 Photo. 3. Similar scanners from other vendors are: Canon CanoScan LiDE 600F HP ScanJet 4850 / 4890 Microtek ScanMaker S450 Mustek Be at rPaw 4800 TA Pro Plustek OpticPro ST64+ aren't supported at all by sane. So I hope, I missed the pearl and somebody could help me to buy a scanner here in germany (or europe). Hey, its christmas ;-) Und Salve Mike
[sane-devel] permission request
m. allan noah wrote: agreed- it seems that we have had so much trouble getting started on sane2 because it is so large and may have incompatibilites with sane1, making it hard to test. my idea was to move forward in smaller steps, trying to keep compatibility, so that old backends require no modifications. Excude me for jumping in having previously been only a lurker... I completely agree - we are unlikely to get SANE2 off the ground if it requires an incompatible big bang. Section 4.1 of the SANE2 draft says a backend always provides support for one and only one version of the standard, but I think this is the wrong approach. Instead we should aim for a situation where: * All backends continue to implement SANE1 interface. So all existing frontends will continue to work with all backends. * Any backend may also implement SANE2. * A SANE2-capable frontend can determine whether or not a backend supports SANE2. Note: SANE2-capability is a property of individual devices, not just backend classes - a meta-backend may need to support SANE2 for some devices but only SANE1 for others. One immediate question: how could a SANE2-capable frontend determine whether a backend supports SANE2? One possibility is that the sane_init() function returns a 'magic' value e.g. SANE_VERSION_CODE(1,255,0). To a SANE1-only frontend, this appears as version 1; a SANE2-capable frontend will recognise the magic value and use SANE2 methods. Another important point to allow smooth migration: we must not change existing interfaces (i.e. ABI) but we may augment them. E.g. do not change the definition of SANE_Device (and therefore sane_get_devices()). instead, define SANE_Device2 structure with the new fields, and a new method sane_get_devices2() which returns them. -- Colin Hogben
[sane-devel] [announce] new backend: epjitsu
Those who are on the sane-commit list have already seen this, but for everyone else- I've add a new backend to sane cvs called epjitsu. It supports Epson-based Fujitsu-branded scanners (hence the name). Currently this includes the fi-60F A6 flatbed, and the ScanSnap S300 legal ADF scanners. These machines are pretty stupid, with limited resolution choices, always scanning full-width, lots of padding bytes, and no binary mode support. The S300 is even worse, as it always scans in triplex (duplex plus a side worth of padding bytes), and it does not have a grayscale mode. They also require firmware files, and usb 2.0 (usb 1.1 is too slow). The backend is fairly simplistic, with reverse engineered calibration (which i really dont understand for CIS devices- i could use some pointers here), and no scan area or brightness/contrast/threshold support. It has been tested fairly heavily on x86, x86-64, and ARM9. allan -- The truth is an offense, but not a sin
[sane-devel] Canon PIXMA MP130
no problem. come back to the list if you have questions or get stuck- but be prepared to spend hundreds of hours on the project if the machine uses an undocumented command set. allan On Dec 19, 2007 11:01 AM, Johnny Rosenberg gurus.knugum at gmail.com wrote: Ok, thanks guys. I will take a look and see if this is something that I possibly can understand and even make something from. Johnny 2007/12/18, m. allan noah kitno455 at gmail.com: have you read the contribute page at www.sane-project.org? it includes links to various documents you might find useful, particularly the website for sniffusb and doc/backend-writing.txt. you will also want to get a current sane CVS checkout, and read the sane standard, which is included in the doc directory. Opening the scanner to look at the chips can often be helpful as well. allan On Dec 18, 2007 4:36 PM, Johnny Rosenberg gurus.knugum at gmail.com wrote: 2007/12/18, James Crow james at ultratans.com: You might want to check the list archives for Canon PIXMA driver support. I have the MP160 and it is supported. There is driver that works in CVS. It may also include support for your printer. Start here: http://home.arcor.de/wittawat/pixma/ Thanks, James There's exactly where I looked. Here's a quote from that site: Unknown protocol: These devices don't work with this backend and there is no easy way to add supports because they use a different command set which has to be analyzed first. Co-programmers are welcome! :-) I personally cannot do this because I don't have the devices. MP110 4A9:1700 1200 N N - N unsupported MP130 4A9:1701 1200 N N - N unsupported I saw that someone wrote here about the MP110. Maybe the MP130 can use the same driver? Anyway, the site I referred to when I first wrote, suggested that someone could write a backend to this and other unsupported drivers and it also said that it is not a very hard thing to do for people who know a little C, for example. Well, since I have studied C a long time ago, I thought that maybe this isn't very impossible after all, but I guess I will need some help to get me started. I don't know where to begin, kind of. I don't even know exactly how a driver in general works... I need some basic knowledge to get started, and I just thought that someone here could give me some kind of clue where to start or some links that explain things... What do I need (except a C compiler and the scanner)? Can the fact that I also have Windows XP with a working driver be of any help? Is there some kind of software for Windows that can give me any clues about how the MP130 works? Yes, I can do some C programming, but I need to know what I need to do... otherwise it's kind of being told to create a schoilkus program in C without also being told what a schoilkus program is (in this case nothing since I just made it up...). Johnny Rosenberg On Tue, 2007-12-18 at 19:30 +0100, Johnny Rosenberg wrote: 2007/12/10, Epostlistor gurus.knugum at gmail.com: I visited http://www.sane-project.org/contrib.html and readed about contributing to the project - Writing a Backend (Driver). The page said that You don't need to be an experienced programmer. Backends are usually written in C, so some basic knowledge of this language helps. You need a lot of patience, however, especially if you can't get programmer's documentation from your scanner's manufacturer. I learned C many years ago and I still think I remember most of it, but I am not programming very much these days. I am writing here because I think I need all the help I can get. Maybe someone is already doing this, then I might be able to contribute in some way. If not, it feels like there are a lot of things I need to know. Maybe there are similar backend drivers out there that I can get inspiration from and learn how to write things like that. I have the Canon PIXMA MP130 and my operating system is GNU/Linux Ubuntu Studio 7.10. I also have a small partition with Windows XP, so I can use the scanner that way, but of course I want to use it with Ubuntu. At the moment I can only use the printing function with Ubuntu, but I needed to install additional software before that was possible. Is there some kind of software for Windows that can scan what's sent and received to/from the MP130 while scanning etc? I guess that
[sane-devel] permission request
On Wed, 19 Dec 2007 08:36:09 -0500 m. allan noah kitno455 at gmail.com wrote: if a branch is created, to support new data formats, could it be done to handle them the way (or a subset of) SANE2 is planned to do it? So that we move incrementally toward SANE2. I don't think so, because that would mean you really have to implement SANE2. The purpose of the SANE 1.1 branch is to keep compatibility with 1.0 . agreed- it seems that we have had so much trouble getting started on sane2 because it is so large and may have incompatibilites with sane1, making it hard to test. my idea was to move forward in smaller steps, trying to keep compatibility, so that old backends require no modifications. exactly. who can take care to setup the cvs for the 1.1 branch? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] permission request
On Dec 19, 2007 11:11 AM, Alessandro Zummo azummo-lists at towertech.it wrote: On Wed, 19 Dec 2007 08:36:09 -0500 m. allan noah kitno455 at gmail.com wrote: if a branch is created, to support new data formats, could it be done to handle them the way (or a subset of) SANE2 is planned to do it? So that we move incrementally toward SANE2. I don't think so, because that would mean you really have to implement SANE2. The purpose of the SANE 1.1 branch is to keep compatibility with 1.0 . agreed- it seems that we have had so much trouble getting started on sane2 because it is so large and may have incompatibilites with sane1, making it hard to test. my idea was to move forward in smaller steps, trying to keep compatibility, so that old backends require no modifications. exactly. who can take care to setup the cvs for the 1.1 branch? how does this sound: sane 1.0.19- release in Feb, last of the standard 1.0 versions, remove SANE_FRAME_JPEG. sane 1.1.0- release in May?, first of the standard 1.1 versions, no new function calls, only more well-known options and frame types, old backends need no changes, other than required well-known options. sane 2.0.0- first of standard 2.0 versions, new function calls, etc. given the backwards compatibility of standard 1.1, i dont think there is a need for sane 1.0.20. allan -- The truth is an offense, but not a sin
[sane-devel] permission request
On Wed, 19 Dec 2007 11:34:56 -0500 m. allan noah kitno455 at gmail.com wrote: exactly. who can take care to setup the cvs for the 1.1 branch? how does this sound: sane 1.0.19- release in Feb, last of the standard 1.0 versions, remove SANE_FRAME_JPEG. sane 1.1.0- release in May?, first of the standard 1.1 versions, no new function calls, only more well-known options and frame types, old backends need no changes, other than required well-known options. sane 2.0.0- first of standard 2.0 versions, new function calls, etc. given the backwards compatibility of standard 1.1, i dont think there is a need for sane 1.0.20. seems fine. but you want to branch the cvs or wait until feb before starting to work on 1.1 ? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] permission request
how does this sound: sane 1.0.19- release in Feb, last of the standard 1.0 versions, remove SANE_FRAME_JPEG. sane 1.1.0- release in May?, first of the standard 1.1 versions, no new function calls, only more well-known options and frame types, old backends need no changes, other than required well-known options. sane 2.0.0- first of standard 2.0 versions, new function calls, etc. given the backwards compatibility of standard 1.1, i dont think there is a need for sane 1.0.20. seems fine. but you want to branch the cvs or wait until feb before starting to work on 1.1 ? i think we should wait. we can add a dir in the 'experimental' cvs tree for working on the standard and any backends that have 1.1 support, and once 1.0.19 is released, we can just bump the minor number and copy over the changes from experimental. allan -- The truth is an offense, but not a sin
[sane-devel] permission request
On Wed, 19 Dec 2007 11:42:39 -0500 m. allan noah kitno455 at gmail.com wrote: seems fine. but you want to branch the cvs or wait until feb before starting to work on 1.1 ? i think we should wait. we can add a dir in the 'experimental' cvs tree for working on the standard and any backends that have 1.1 support, and once 1.0.19 is released, we can just bump the minor number and copy over the changes from experimental. shouldn't we use the branch/tags features of the cvs? we might have to work with 1.0, 1.1 and 2.0 -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] permission request
On Dec 19, 2007 9:41 AM, Colin Hogben sane at pythontech.co.uk wrote: m. allan noah wrote: agreed- it seems that we have had so much trouble getting started on sane2 because it is so large and may have incompatibilites with sane1, making it hard to test. my idea was to move forward in smaller steps, trying to keep compatibility, so that old backends require no modifications. Excude me for jumping in having previously been only a lurker... no- the more the merrier :) I completely agree - we are unlikely to get SANE2 off the ground if it requires an incompatible big bang. Section 4.1 of the SANE2 draft says a backend always provides support for one and only one version of the standard, but I think this is the wrong approach. Instead we should aim for a situation where: * All backends continue to implement SANE1 interface. So all existing frontends will continue to work with all backends. * Any backend may also implement SANE2. * A SANE2-capable frontend can determine whether or not a backend supports SANE2. Note: SANE2-capability is a property of individual devices, not just backend classes - a meta-backend may need to support SANE2 for some devices but only SANE1 for others. One immediate question: how could a SANE2-capable frontend determine whether a backend supports SANE2? One possibility is that the sane_init() function returns a 'magic' value e.g. SANE_VERSION_CODE(1,255,0). To a SANE1-only frontend, this appears as version 1; a SANE2-capable frontend will recognise the magic value and use SANE2 methods. Another important point to allow smooth migration: we must not change existing interfaces (i.e. ABI) but we may augment them. E.g. do not change the definition of SANE_Device (and therefore sane_get_devices()). instead, define SANE_Device2 structure with the new fields, and a new method sane_get_devices2() which returns them. i think the idea is nice in principal, though the specifics of using the obfuscated version number are not that pleasant. at this moment, my prime concern is extending the standard in a way that might require front-ends to be updated a little, but will not require them to support two versions of sane. if we reach a point where we are prepared to extend the API in an incompatible way, then we can address the mechanism for identification of version. allan -- The truth is an offense, but not a sin
[sane-devel] bug in sanei_usb?
I've noticed that sanei_usb_read_bulk() returns SANE_STATUS_IO_ERROR for all negative return values from the usb stack. One of those errors which i have just started seeing under linux 2.4 on a slow ARM box is EAGAIN, which probably should be converted into SANE_STATUS_DEVICE_BUSY? allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard (was: permission request)
Hello. As most of you know I am against the recent development of the SANE1 standard. We have an almost complete SANE2 standard and a good working SANE1 standard. What is happening in the moment is the destruction of all we have. This will end in a chaos. I don`t understand why nobody wants to start with SANE2. It will take a weekend of work to create a SANE2 backend from an existing SANE1 backend. Because you don`t want to spend this time you destroy the SANE1 standard by creating a chaos. As you say 95% of the users are happy with SANE1. What you are doing now is to make 95% of the users unhappy. When you will do what you are talking about in the moment then I will have to think if I will spend any further time into the SANE project and into xsane. I know if I would continue the work for xsane in this case then I would have to spend 99% of my programming time to answer questions about incompatibilities and problems with the new 1.1-standard. In my opinion it is not fair to create so much problems for SANE1 because you don`t like to spend some days to create SANE2 backends from the SANE1 backends. Please think about what you are doing. Best regards Oliver Am Dienstag, den 18.12.2007, 15:01 +0100 schrieb Alessandro Zummo: To: Gerhard Jaeger Henning Geinitz Julien Blache Oliver Rauch Petter Reinholdtsen M. Allan Noah Hello SANE Admins, I would like, in the interest of the SANE community of users and developers, to kindly ask the permission to add some much required frame types to the repository. Given that: - some types are already in use by in-repository backends - other types are in use by external backends - the JPEG frame type has already been added - any well written frontend will not notice the change - the new types are not active by default I ask you to ease the work of backend authors and allow this much requested change. Thanks in advance for your time and for your answer.
[sane-devel] The future of the SANE-Standard (was: permission request)
On Wed, 19 Dec 2007 18:48:54 +0100 Oliver Rauch Oliver.Rauch at Rauch-Domain.DE wrote: I don`t understand why nobody wants to start with SANE2. It will take a weekend of work to create a SANE2 backend from an existing SANE1 backend. Because you don`t want to spend this time you destroy the SANE1 standard by creating a chaos. I don't think that anybody wants to NOT start it, but that nobody wants to write the core. I truly believe that if someone pledges to write it, the most important backends will follow quickly. As you say 95% of the users are happy with SANE1. What you are doing now is to make 95% of the users unhappy. I don't think so. I'm going to make the other 5% happy. When you will do what you are talking about in the moment then I will have to think if I will spend any further time into the SANE project and into xsane. I know if I would continue the work for xsane in this case then I would have to spend 99% of my programming time to answer questions about incompatibilities and problems with the new 1.1-standard. 1.1 will be 99% compatible with 1.0. I don't believe that fixing that 1% will require 9% of your programming time. In my opinion it is not fair to create so much problems for SANE1 because you don`t like to spend some days to create SANE2 backends from the SANE1 backends. Please think about what you are doing. As I, and many other developers, already said, I'm willing to create backends if someone writes the core and transport. Do you want to be that someone? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard (was: permission request)
On Dec 19, 2007 12:48 PM, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Hello. As most of you know I am against the recent development of the SANE1 standard. We have an almost complete SANE2 standard and a good working SANE1 standard. What is happening in the moment is the destruction of all we have. This will end in a chaos. I don`t understand why nobody wants to start with SANE2. It will take a weekend of work to create a SANE2 backend from an existing SANE1 backend. Because you don`t want to spend this time you destroy the SANE1 standard by creating a chaos. As you say 95% of the users are happy with SANE1. What you are doing now is to make 95% of the users unhappy. When you will do what you are talking about in the moment then I will have to think if I will spend any further time into the SANE project and into xsane. I know if I would continue the work for xsane in this case then I would have to spend 99% of my programming time to answer questions about incompatibilities and problems with the new 1.1-standard. In my opinion it is not fair to create so much problems for SANE1 because you don`t like to spend some days to create SANE2 backends from the SANE1 backends. Please think about what you are doing. Oliver- The changes we discuss are minimal and are not the default output format for any backend. As such, they will not break existing front-ends until the user enables some option. Even then, they will only break a poorly written frontend. And so, it is my preference to place these changes right in sane 1.0. The idea to place them in sane 1.1 instead was purely a compromise to make YOU happy. But it seems that you are not interested in a simple upgrade path to help those remaining 5% of users, but instead want to tell us all to convert our backends and front-ends to SANE2. Please, meet us half-way, and stop using words like 'force' and 'chaos' in every discussion, and stop insisting that SANE2 is the only means to extend sane. That tactic has not worked for the past 5 years, and it does not work now. allan -- The truth is an offense, but not a sin
[sane-devel] bug in sanei_usb?
This sounds interesting to me for the problem: Error during device I/O running saned on WL-500GP under OpenWRT using libusb I would have tested it with kernel 2.6, but I have no access to the device for the next three weeks, so I could report the results of the test on 2.6 and some tests (under 2.6 and 2.4) by converting the errors the (hopefully) right way in about three weeks, when I am able to get the access. Andreas -Urspr?ngliche Nachricht- Von: sane-devel-bounces+fireandy=covers.de at lists.alioth.debian.org [mailto:sane-devel-bounces+fireandy=covers.de at lists.alioth.debian.org] Im Auftrag von m. allan noah Gesendet: Mittwoch, 19. Dezember 2007 18:43 An: SANE-DEVEL Betreff: [sane-devel] bug in sanei_usb? I've noticed that sanei_usb_read_bulk() returns SANE_STATUS_IO_ERROR for all negative return values from the usb stack. One of those errors which i have just started seeing under linux 2.4 on a slow ARM box is EAGAIN, which probably should be converted into SANE_STATUS_DEVICE_BUSY? allan -- The truth is an offense, but not a sin -- 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
[sane-devel] The future of the SANE-Standard
Oliver Rauch Oliver.Rauch at Rauch-Domain.DE wrote: Hi, into xsane. I know if I would continue the work for xsane in this case then I would have to spend 99% of my programming time to answer questions about incompatibilities and problems with the new 1.1-standard. Would you care to explain why the addition of new frame types would create any such problems ? Because that's the only thing that has been discussed so far - no ABI changes, no new functions in the API, just new frame types. Other projects add things to their API all the time and it hasn't caused chaos yet. Why would that not be possible in SANE ? There's no reason why expending the API in a careful and controlled fashion would let to that kind of problems on your end. In my opinion it is not fair to create so much problems for SANE1 because you don`t like to spend some days to create SANE2 backends from the SANE1 backends. For that you'll need to lay out the base of SANE2 first, and at least port the test backend and scanimage. Then we'll have some data and examples to start porting other backends and frontends. As it stands SANE2 is pure theory and until some work has started on implementing it, there's a potential for running into troubles and having to modify the current SANE2. And you want that to happen as early as possible if at all... JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Formulardaten
=== == Neuer Eintrag === --- -- Formular: 'adddev' --- 1. Your email address: 'supp at students.zcu.cz' 2. Manufacturer (e.g. Mustek): 'HP' 3. Model name (e.g. ScanExpress 1200UB): 'LaserJet M2727nf MFP' 4. Bus type: 'USB' 5. Vendor id (e.g. 0x001): '0x03f0' 6. Product id (e.g. 0x0002): '0x4d17' 7. Chipset (e.g. lm9831): 'unknown' 8. Comments (e.g. similar to Mustek 1234): 'New line of multifunction printers/scanners/whatever by HP - hplip/hpijs support only printing. I can do daily testing if needed :-)' 9. Data (e.g. sane-find-scanner -v -v): 'This is sane-find-scanner from sane-backends 1.0.18 # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. searching for SCSI scanners: checking /dev/scanner... failed to open (Invalid argument) checking /dev/sg0... failed to open (Invalid argument) checking /dev/sg1... failed to open (Invalid argument) checking /dev/sg2... failed to open (Invalid argument) checking /dev/sg3... failed to open (Invalid argument) checking /dev/sg4... failed to open (Invalid argument) checking /dev/sg5... failed to open (Invalid argument) checking /dev/sg6... failed to open (Invalid argument) checking /dev/sg7... failed to open (Invalid argument) checking /dev/sg8... failed to open (Invalid argument) checking /dev/sg9... failed to open (Invalid argument) checking /dev/sga... failed to open (Invalid argument) checking /dev/sgb... failed to open (Invalid argument) checking /dev/sgc... failed to open (Invalid argument) checking /dev/sgd... failed to open (Invalid argument) checking /dev/sge... failed to open (Invalid argument) checking /dev/sgf... failed to open (Invalid argument) checking /dev/sgg... failed to open (Invalid argument) checking /dev/sgh... failed to open (Invalid argument) checking /dev/sgi... failed to open (Invalid argument) checking /dev/sgj... failed to open (Invalid argument) checking /dev/sgk... failed to open (Invalid argument) checking /dev/sgl... failed to open (Invalid argument) checking /dev/sgm... failed to open (Invalid argument) checking /dev/sgn... failed to open (Invalid argument) checking /dev/sgo... failed to open (Invalid argument) checking /dev/sgp... failed to open (Invalid argument) checking /dev/sgq... failed to open (Invalid argument) checking /dev/sgr... failed to open (Invalid argument) checking /dev/sgs... failed to open (Invalid argument) checking /dev/sgt... failed to open (Invalid argument) checking /dev/sgu... failed to open (Invalid argument) checking /dev/sgv... failed to open (Invalid argument) checking /dev/sgw... failed to open (Invalid argument) checking /dev/sgx... failed to open (Invalid argument) checking /dev/sgy... failed to open (Invalid argument) checking /dev/sgz... failed to open (Invalid argument) # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) checking /dev/usb/scanner1... failed to open (Invalid argument) checking /dev/usb/scanner2... failed to open (Invalid argument) checking /dev/usb/scanner3... failed to open (Invalid argument) checking /dev/usb/scanner4... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner7... failed to open (Invalid argument) checking /dev/usb/scanner8... failed to open (Invalid argument) checking /dev/usb/scanner9... failed to open (Invalid argument) checking /dev/usb/scanner10... failed to open (Invalid argument) checking /dev/usb/scanner11... failed to open (Invalid argument) checking /dev/usb/scanner12... failed to open (Invalid argument) checking /dev/usb/scanner13... failed to open (Invalid argument) checking /dev/usb/scanner14... failed to open (Invalid argument) checking /dev/usb/scanner15... failed to open (Invalid argument) checking /dev/usbscanner... failed to open (Invalid argument) checking /dev/usbscanner0... failed to open (Invalid argument) checking /dev/usbscanner1... failed to open (Invalid argument) checking /dev/usbscanner2... failed to open (Invalid argument) checking /dev/usbscanner3... failed to open (Invalid argument) checking /dev/usbscanner4... failed to open (Invalid argument) checking /dev/usbscanner5... failed to open (Invalid argument) checking /dev/usbscanner6... failed to open (Invalid argument) checking /dev/usbscanner7... failed to open (Invalid argument) checking /dev/usbscanner8... failed to open (Invalid argument) checking
[sane-devel] The future of the SANE-Standard
Am Mittwoch, den 19.12.2007, 19:27 +0100 schrieb Julien BLACHE: Would you care to explain why the addition of new frame types would create any such problems ? Because that's the only thing that has been discussed so far - no ABI changes, no new functions in the API, just new frame types. What is discussed in the moment is a slow transformation from SANE1 to SANE2 (I don't remeber the exact words). And we do not discuss only some new frame types. It took about 30 minutes after this suggestion to add several other things that are not compatible to SANE1. And what all the people forget is that is may be a simple step to change a backend to send a new frame or image type to the frontend. For the frontends we get a lot of work to handle this. But here are one or two frontend authors that try to discuss with several backend authors. We will get a lot of incompatibilites when we add several new frame types. From the backend author's view this is not much work, the backend simply sends the data the scanner produces. But the frontend authors have to handle this. Now some people will say that we do not need all frontends to handle all frame types. But what is the adavantage of it when the frontends can not handle it. It only makes sense to add e.g. a TIFFg3FAX or JPEG frame type when all frontends can handle this. But when we make this step, then we should make the complet step to SANE2. Best regards Oliver
[sane-devel] The future of the SANE-Standard
On Wed, 19 Dec 2007 20:30:12 +0100 Oliver Rauch Oliver.Rauch at Rauch-Domain.DE wrote: What is discussed in the moment is a slow transformation from SANE1 to SANE2 (I don't remeber the exact words). And we do not discuss only some new frame types. It took about 30 minutes after this suggestion to add several other things that are not compatible to SANE1. Those things are proposals and if implemented they will be implemented in a way so that the current frontends do not have to be altered. And what all the people forget is that is may be a simple step to change a backend to send a new frame or image type to the frontend. For the frontends we get a lot of work to handle this. But here are one or two frontend authors that try to discuss with several backend authors. Let me stress it again. You will not have to change your frontend. The current backends - all of them - will send the same data that is sent right now. We will get a lot of incompatibilites when we add several new frame types. From the backend author's view this is not much work, the backend simply sends the data the scanner produces. But the frontend authors have to handle this. The frontend does not have to handle this unless it wants. No new format will be exposed unless requested. Now some people will say that we do not need all frontends to handle all frame types. But what is the adavantage of it when the frontends can not handle it. It only makes sense to add e.g. a TIFFg3FAX or JPEG frame type when all frontends can handle this. But when we make this step, then we should make the complet step to SANE2. The advantage of it that the people that requires them will be able to use them. You can't wait that all frontends are up-to-date to add features. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
Oliver Rauch Oliver.Rauch at Rauch-Domain.DE wrote: Hi, What is discussed in the moment is a slow transformation from SANE1 to SANE2 (I don't remeber the exact words). And we do not discuss only some new frame types. It took about 30 minutes after this suggestion to add several other things that are not compatible to SANE1. What's nice when you discuss things is that you end up not doing the stupid things that came up during the discussion, and only keep the most interesting ones. Let's keep it at the frame types for now, that would allow for new features and better support for some scanners, and some users may really enjoy that. If we can do that, why not ? Now some people will say that we do not need all frontends to handle all frame types. But what is the adavantage of it when the frontends can not handle it. It only makes sense to add e.g. a TIFFg3FAX or JPEG frame type when all frontends can handle this. But when we make this step, then we should make the complet step to SANE2. As you've just written, not all the frontends need to handle all the frame types. (and let's digress on frontends now) What is important from a frontend point of view is the target audience it's designed for. The one-size-fits-all is absolutely not the solution for something as complex as a scanning frontend. What we really need, err, what USERS really need, is a range of frontends that match their needs as closely as possible: - one frontend for the average joe user to handle basic scanning needs (b/w text, documents, photos) - one frontend for the advanced user (would be today's XSane) - one frontend for the ?ber-advanced imaging guru, with advanced features like IR, etc. That's to give a rough idea of what I mean, it's a bit more complex than that actually, but you get it. As it stands today, users have a hard time finding a frontend that suits their needs, precisely because there isn't any. The average joe user doesn't grok how XSane works, xscanimage doesn't cut it because it's too primitive. Something resembling Epson's iScan! frontend is probably very close to what's needed. Gnome Scan might do it, though, but I'm not convinced. The advanced user is usually well served with XSane (integrated with GIMP). Anybody who wants something more advanced than XSane either goes for VueScan, Windows or writes something, be it a script around scanimage stuff or hacks a tool or even a backend to suit his needs. Just like SNMP needs to put some more S in it, SANE needs to put back some E in SANE. Because some frame types are added to SANE doesn't mean you have to add support for them in XSane. Part of the job in maintaining a piece of software is knowing where you want to go and when to say sorry, no to a feature request. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
Hi, What we really need, err, what USERS really need, is a range of frontends that match their needs as closely as possible: - one frontend for the average joe user to handle basic scanning needs (b/w text, documents, photos) - one frontend for the advanced user (would be today's XSane) - one frontend for the ?ber-advanced imaging guru, with advanced features like IR, etc. I do fully agree with you. As developer of Gnome Scan, i really don't want to support all use-case, but 100% of maman use cases so that she never ask me again to do the scan for her again. I'm pretty sure gnome-scan will never handle IR or such advanced feature ! However, i'm pretty concerned by hotplug and event handling wich is a lame of SANE for now. Regards, ?tienne. -- E Ultre?a ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071219/da894629/attachment.pgp
[sane-devel] Formulardaten
Le Wednesday 19 December 2007 13:42:25 cgi-mailer at kundenserver.de, vous avez ?crit?: === == Neuer Eintrag === --- -- Formular: 'adddev' --- 1. Your email address: 'hoffmann_jens at web.de' 2. Manufacturer (e.g. Mustek): 'Hewlet Packard' 3. Model name (e.g. ScanExpress 1200UB): 'hp scanjet 4400c USB' 4. Bus type: 'USB' 5. Vendor id (e.g. 0x001): '' 6. Product id (e.g. 0x0002): '' 7. Chipset (e.g. lm9831): '' 8. Comments (e.g. similar to Mustek 1234): 'hp scanjet 4400c similar to Realtek RTS8891 ?? ' 9. Data (e.g. sane-find-scanner -v -v): 'This is sane-find-scanner from sane-backends 1.0.18-cvs # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. searching for SCSI scanners: checking /dev/scanner... failed to open (Invalid argument) checking /dev/sg0... failed to open (Access to resource has been denied) checking /dev/sg1... failed to open (Invalid argument) checking /dev/sg2... failed to open (Invalid argument) checking /dev/sg3... failed to open (Invalid argument) checking /dev/sg4... failed to open (Invalid argument) checking /dev/sg5... failed to open (Invalid argument) checking /dev/sg6... failed to open (Invalid argument) checking /dev/sg7... failed to open (Invalid argument) checking /dev/sg8... failed to open (Invalid argument) checking /dev/sg9... failed to open (Invalid argument) checking /dev/sga... failed to open (Invalid argument) checking /dev/sgb... failed to open (Invalid argument) checking /dev/sgc... failed to open (Invalid argument) checking /dev/sgd... failed to open (Invalid argument) checking /dev/sge... failed to open (Invalid argument) checking /dev/sgf... failed to open (Invalid argument) checking /dev/sgg... failed to open (Invalid argument) checking /dev/sgh... failed to open (Invalid argument) checking /dev/sgi... failed to open (Invalid argument) checking /dev/sgj... failed to open (Invalid argument) checking /dev/sgk... failed to open (Invalid argument) checking /dev/sgl... failed to open (Invalid argument) checking /dev/sgm... failed to open (Invalid argument) checking /dev/sgn... failed to open (Invalid argument) checking /dev/sgo... failed to open (Invalid argument) checking /dev/sgp... failed to open (Invalid argument) checking /dev/sgq... failed to open (Invalid argument) checking /dev/sgr... failed to open (Invalid argument) checking /dev/sgs... failed to open (Invalid argument) checking /dev/sgt... failed to open (Invalid argument) checking /dev/sgu... failed to open (Invalid argument) checking /dev/sgv... failed to open (Invalid argument) checking /dev/sgw... failed to open (Invalid argument) checking /dev/sgx... failed to open (Invalid argument) checking /dev/sgy... failed to open (Invalid argument) checking /dev/sgz... failed to open (Invalid argument) # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) checking /dev/usb/scanner1... failed to open (Invalid argument) checking /dev/usb/scanner2... failed to open (Invalid argument) checking /dev/usb/scanner3... failed to open (Invalid argument) checking /dev/usb/scanner4... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner7... failed to open (Invalid argument) checking /dev/usb/scanner8... failed to open (Invalid argument) checking /dev/usb/scanner9... failed to open (Invalid argument) checking /dev/usb/scanner10... failed to open (Invalid argument) checking /dev/usb/scanner11... failed to open (Invalid argument) checking /dev/usb/scanner12... failed to open (Invalid argument) checking /dev/usb/scanner13... failed to open (Invalid argument) checking /dev/usb/scanner14... failed to open (Invalid argument) checking /dev/usb/scanner15... failed to open (Invalid argument) checking /dev/usbscanner... failed to open (Invalid argument) checking /dev/usbscanner0... failed to open (Invalid argument) checking /dev/usbscanner1... failed to open (Invalid argument) checking /dev/usbscanner2... failed to open (Invalid argument) checking /dev/usbscanner3... failed to open (Invalid argument) checking /dev/usbscanner4... failed to open (Invalid argument) checking /dev/usbscanner5... failed to open (Invalid argument) checking /dev/usbscanner6... failed to open (Invalid argument) checking /dev/usbscanner7... failed to
[sane-devel] The future of the SANE-Standard
On Dec 19, 2007 2:30 PM, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Am Mittwoch, den 19.12.2007, 19:27 +0100 schrieb Julien BLACHE: Would you care to explain why the addition of new frame types would create any such problems ? Because that's the only thing that has been discussed so far - no ABI changes, no new functions in the API, just new frame types. What is discussed in the moment is a slow transformation from SANE1 to SANE2 (I don't remeber the exact words). And we do not discuss only some new frame types. It took about 30 minutes after this suggestion to add several other things that are not compatible to SANE1. And if you would care to re-read the thread, you will see that I shot down those ideas as soon as they appeared, and have said repeatedly in this thread that SANE 1.1 will stay backward compatible at the API, by being limited to only new frame types and new well-defined options. And what all the people forget is that is may be a simple step to change a backend to send a new frame or image type to the frontend. For the frontends we get a lot of work to handle this. But here are one or two frontend authors that try to discuss with several backend authors. so you would rather do sane2, which would require more work for these few front-end authors, and more work for ALL backend authors? We will get a lot of incompatibilites when we add several new frame types. From the backend author's view this is not much work, the backend simply sends the data the scanner produces. But the frontend authors have to handle this. its easy- you skip the frames you dont understand! Look at the sane2 standard for a second- it is going to include a SANE_FRAME_MIME! How is that going to reduce the number of image types you have to support? Now some people will say that we do not need all frontends to handle all frame types. But what is the adavantage of it when the frontends can not handle it. It only makes sense to add e.g. a TIFFg3FAX or JPEG frame type when all frontends can handle this. But when we make this step, then we should make the complet step to SANE2. how many frontends never bothered to handle multi-pass RGB or the -1 document length for handheld scanners? Ever notice how it is hard to get scanadf to only scan 1 page? Do you know i personally have three different frontends in hundreds of machines in active use as we speak that would blow up if they received color data- but no one has ever tried! case closed. allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
On Dec 19, 2007 3:18 PM, ?tienne Bersac bersace at gmail.com wrote: Hi, What we really need, err, what USERS really need, is a range of frontends that match their needs as closely as possible: - one frontend for the average joe user to handle basic scanning needs (b/w text, documents, photos) - one frontend for the advanced user (would be today's XSane) - one frontend for the ?ber-advanced imaging guru, with advanced features like IR, etc. I do fully agree with you. As developer of Gnome Scan, i really don't want to support all use-case, but 100% of maman use cases so that she never ask me again to do the scan for her again. I'm pretty sure gnome-scan will never handle IR or such advanced feature ! However, i'm pretty concerned by hotplug and event handling wich is a lame of SANE for now. button handling, if done thru well-known options, and hotplug could be handled in any version of sane, provided we could find some folks with the time and urge to work on it. if button handling is done in some sort of async or call-back mode, that would require changing the API, so it would get pushed back to a later version (sane 2 maybe?) allan -- The truth is an offense, but not a sin
[sane-devel] epjitsu.o: Undefined symbol _free_scanner referenced from text segment
Hi, I just tried to compile the latest CVS from today (on OS/2) and got epjitsu.o: Undefined symbol _free_scanner referenced from text segment Looks like the funciton code is missing. Franz
[sane-devel] epjitsu.o: Undefined symbol _free_scanner referenced from text segment
right- my fault. lost that function somewhere along the line- fix coming up momentarily. allan On Dec 19, 2007 4:40 PM, Franz Bakan fbakan at gmx.net wrote: Hi, I just tried to compile the latest CVS from today (on OS/2) and got epjitsu.o: Undefined symbol _free_scanner referenced from text segment Looks like the funciton code is missing. Franz -- 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] epjitsu.o: Undefined symbol _free_scanner referenced from text segment
On Wed, 19 Dec 2007 17:08:10 -0500, m. allan noah wrote: right- my fault. lost that function somewhere along the line- fix coming up momentarily. Thanks, now all compiles again. Franz
