[sane-devel] frame and batch mode

[Jonathan Buzzard]

m. allan noah wrote:
> On Dec 18, 2007 12:37 PM, Jonathan Buzzard  wrote:
>> On Tue, 2007-12-18 at 08:40 -0500, m. allan noah wrote:
>>> On 12/18/07, Giuseppe Sacco  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 :/

[stef]

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=30186&atid=410366&func=detail&ai
>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.

>
> 
> 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 ...
>  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 2>scan.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 2>&1 >probe.log' with these 
variables 
set would also be interesting.

Regards,
Stef

[sane-devel] permission request

[stef]

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

[Alessandro Zummo]

On Wed, 19 Dec 2007 06:57:27 +0100
stef  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

[cwl...@tpg.com.au]

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

[cgi-mai...@kundenserver.de]

===
== 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 /dev/usbscanner10.

[sane-devel] permission request

[m. allan noah]

On 12/19/07, Alessandro Zummo  wrote:
> On Wed, 19 Dec 2007 06:57:27 +0100
> stef  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

[Mike Reichel]

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

[Colin Hogben]

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

[m. allan noah]

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

[m. allan noah]

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  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 :
> > > > 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 onl

[sane-devel] permission request

[Alessandro Zummo]

On Wed, 19 Dec 2007 08:36:09 -0500
"m. allan noah"  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

[m. allan noah]

On Dec 19, 2007 11:11 AM, Alessandro Zummo  wrote:
> On Wed, 19 Dec 2007 08:36:09 -0500
> "m. allan noah"  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

[Alessandro Zummo]

On Wed, 19 Dec 2007 11:34:56 -0500
"m. allan noah"  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

[m. allan noah]

> > 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

[Alessandro Zummo]

On Wed, 19 Dec 2007 11:42:39 -0500
"m. allan noah"  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

[m. allan noah]

On Dec 19, 2007 9:41 AM, Colin Hogben  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?

[m. allan noah]

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)

[Oliver Rauch]

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)

[Alessandro Zummo]

On Wed, 19 Dec 2007 18:48:54 +0100
Oliver Rauch  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)

[m. allan noah]

On Dec 19, 2007 12:48 PM, Oliver Rauch  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?

[fireandy]

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

[Julien BLACHE]

Oliver Rauch  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    
  GPG KeyID 0xF5D65169

[sane-devel] Formulardaten

[cgi-mai...@kundenserver.de]

===
== 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 /dev/usbscann

[sane-devel] The future of the SANE-Standard

[Oliver Rauch]

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

[Alessandro Zummo]

On Wed, 19 Dec 2007 20:30:12 +0100
Oliver Rauch  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

[Julien BLACHE]

Oliver Rauch  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    
  GPG KeyID 0xF5D65169

[sane-devel] The future of the SANE-Standard

[Étienne Bersac]

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

[stef]

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)
> chec

[sane-devel] The future of the SANE-Standard

[m. allan noah]

On Dec 19, 2007 2:30 PM, Oliver Rauch  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

[m. allan noah]

On Dec 19, 2007 3:18 PM, ?tienne Bersac  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

[Franz Bakan]

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

[m. allan noah]

right- my fault. lost that function somewhere along the line- fix
coming up momentarily.

allan

On Dec 19, 2007 4:40 PM, Franz Bakan  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

[Franz Bakan]

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