[sane-devel] SANE2 standard completion

[Rene Rebe]

Have you counted thru how many developers are willing to rewrite
their code (backends, frontends, etc.) for this arbitrarily defined SANE
2 "thing" ?

My votes still are: preferably compatibly change SANE 1 or adopt
TWAIN for Linux.

On 27.03.2008, at 18:22, stef wrote:

>   Hello,
>
>   before any work can start on SANE 2, the current proposal has to be  
> completed.
>
>   The major change is the image data format. SANE 2 will be able to  
> handle new formats easily (which matches the current needs,  
> especially regarding ir
> channel). There will be 2 major image format, one pixel oriented and  
> the other will give images as a mime attachment. There is also  
> standard part for button handling.
>
>   Here is a summary of the differences between SANE 1 and SANE 2  
> proposal standards:
>
> structures changes:
>   - the SANE_Device struct has more fields, giving contact  
> information about the devices in case of bug, and the ability to  
> send device capability flags
>   - the SANE_Parameters changes to suit the image format improvement.  
> It also gives new informations such as a proposed filename and X/Y  
> dpi.
>   
> options changes:
>   - capability hidden and allways settable added
>   - more commonly used options are now part of the standard
>
> SANE operations changes:
>   - sane_open has a SANE_Device ** parameter
>   - scanner's button handling
>
> newtwork operation:
>   The Network Protocol chapter seems to lag behind the SANE 1  
> chapter, and the SANE_NET_OPEN call needs to be updated to reflect  
> sane_open evolution.
>
>   The current proposal is in good shape, and the change regarding 
>  
> image format seems to suit the current need for new formats.  
> Converting current backends
> to SANE2 doesn't seem that difficult.
>
>   But before starting, there are some things I'd like to see in the  
> new standard:
>   - the current code flow is
>   sane_init
>   sane_open
>   sane_start
>   sane_read
>   sane_cancel
>   sane_close
>   sane_exit
>   
>   rather than calling sane_cancel at the end of scan, I'd like to 
>  
> have a sane_end function. Leaving the use of sane_cancel for  
> canceling the scan like it allready does. This new function would do  
> about the same, but code flow would be cleaner and easier to  
> understand:
>   sane_init
>   sane_open
>   sane_start
>   sane_read
>   sane_end
>   sane_close
>   sane_exit
>   
>   - the proposed button handling would surely be better if we create  
> sane_lock_buttons(), sane_update_buttons() and sane_unlock()  
> buttons, instead
> of doing this with control options.
>   
>   - we should also add something about panels. Would some control  
> options be enough,  or do we also need some lock/update/unlock  
> behavior ?
>   
>   - there are some issues about backends configuration. In order to  
> be detected, some backends need their  configuration files tweaked.  
> I think that
> having well-known configuration options would improve  the situation  
> and would
> also let us have a common way of accessing configuration parameters  
> across
> backends.
>   
>   - do we want to improve warmup handling ? Currently there is no  
> feedback when warming-up is going on, which is sometime confusing,  
> we can have the feeling that nothing is happening. Do we want a  
> sane_warm_up() or a
> SANE_STATUS_WARMING_UP would be enough ?
>   
>   There are other points that I feel they could be improved, but  
> could be done as we develop SANE2:
>   - we need a sane type for scanner buttons. Either we rename the  
> SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON for
> physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a  
> frontend can easily detect hardware buttons. There should be a list  
> of well-known buttons
> description to use when  possible.
>   - a SANE_TYPE_PANEL would be handy
>   - since there are well-know options there should be well-known  
> groups, and the SANE_CAP of these options should also be given.
>   - a SANE_STATUS_LOCKED could be added to handle the case where the  
> hardware lock of a scanner has been left.
>   
> Regards,
>   Stef
>   
>   
>
> -- 
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>to sane-devel-request at lists.alioth.debian.org

-- 
  Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[Alessandro Zummo]

On Fri, 28 Mar 2008 08:52:51 +0100
Rene Rebe  wrote:

> Have you counted thru how many developers are willing to rewrite
> their code (backends, frontends, etc.) for this arbitrarily defined SANE
> 2 "thing" ?
> 
> My votes still are: preferably compatibly change SANE 1 or adopt
> TWAIN for Linux.

 I believe that Stef has made very clear its intentions
 to go toward SANE 2. TWAIn for linux would be a complete
 rewrite of everything, and compatible changes to SANE1 are
 already available in SANE Evolution

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 09:16, Alessandro Zummo wrote:

> On Fri, 28 Mar 2008 08:52:51 +0100
> Rene Rebe  wrote:
>
>> Have you counted thru how many developers are willing to rewrite
>> their code (backends, frontends, etc.) for this arbitrarily defined  
>> SANE
>> 2 "thing" ?
>>
>> My votes still are: preferably compatibly change SANE 1 or adopt
>> TWAIN for Linux.
>
> I believe that Stef has made very clear its intentions
> to go toward SANE 2. TWAIn for linux would be a complete
> rewrite of everything, and compatible changes to SANE1 are
> already available in SANE Evolution


As SANE2 is a quite complete rewrite anyway, it makes more
sense to adopt and contribute to an wide industry standard
than to try to force yet another incompatible API into the wild.

Btw. I noticed your SANE Evolution fork.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] hp backend fails to detect HP SCSI scanner

[Johannes Meixner]

Hello,

On Mar 27 08:16 m. allan noah wrote (shortened):
> can you get the original poster to put it back to stock, and get a
> debug log like this:
> 
> SANE_DEBUG_SANEI_SCSI=5 SANE_DEBUG_HP=128 scanimage -L

Done.

See
https://bugzilla.novell.com/show_bug.cgi?id=350688#c17
or the debug output directly
https://bugzilla.novell.com/attachment.cgi?id=204409


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

[sane-devel] Formulardaten

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

===
== Neuer Eintrag
===

  
---
-- Formular: 'adddev'
---

1. Your email address:
   'mail at test.ws'
2. Manufacturer (e.g. "Mustek"):
   ''
3. Model name (e.g. ScanExpress 1200UB):
   'paealiniks'
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):
   'http://firehotsite.com/pharmacy/buy-valium.htm";>buy 
valiumhttp://firehotsite.com/pharmacy/buy-tramadol-online.htm";>buy tramadol 
onlinehttp://firehotsite.com/pharmacy/buy-xanax-online.htm";>buy xanax 
onlinehttp://viagrahere.wikidot.com ">buy viagra 
onlinehttp://www.joomlart.com/forums/member.php?u=105920 ">buy 
cialis online'
9. Data (e.g. sane-find-scanner -v -v):
   ''

[sane-devel] [05.20] Re: SANE2 standard completion

[Alessandro Zummo]

On Fri, 28 Mar 2008 09:34:22 +0100
Rene Rebe  wrote:

> 
> > I believe that Stef has made very clear its intentions
> > to go toward SANE 2. TWAIn for linux would be a complete
> > rewrite of everything, and compatible changes to SANE1 are
> > already available in SANE Evolution
> 
> 
> As SANE2 is a quite complete rewrite anyway, it makes more
> sense to adopt and contribute to an wide industry standard
> than to try to force yet another incompatible API into the wild.

 It's true that is a de facto standard, but it is so only
 for windows machines, right? So given that there is no prior
 art in the unix world and that the sane userbase is (I think)
 almost Linux, there's no particular reason to go for it.

 SANE2 is a rewrite but it has a sense of coherence with
 SANE1 and with the user base.


> Btw. I noticed your SANE Evolution fork.

 good ;) 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2 standard completion

[m. allan noah]

On Thu, Mar 27, 2008 at 1:22 PM, stef  wrote:
> Hello,
>
> before any work can start on SANE 2, the current proposal has to be 
> completed.

and before we can complete it, we must acknowlege that it has not been
touched in 5 years, and many of its contributors are no longer active,
and many current sane devels (myself included) were not party to any
of the discussions.

> The major change is the image data format. SANE 2 will be able to 
> handle new formats easily (which matches the current needs, especially 
> regarding ir
>   channel). There will be 2 major image format, one pixel oriented and the 
> other will give images as a mime attachment. There is also standard part for 
> button handling.

but the mime type code creates new problems. it will allow any backend
to produce any kind of output that it wishes, as long as there is a
mime-type for it. frontends will never know what to expect. I would
much rather produce a list of known frame types, and put a note in the
standard that frontend devels should expect new types to be added.
this enables us to specify exactly how common types will be presented.

> Here is a summary of the differences between SANE 1 and SANE 2 
> proposal standards:
>
>  structures changes:
> - the SANE_Device struct has more fields, giving contact information 
> about the devices in case of bug, and the ability to send device capability 
> flags

general idea sounds good.

> - the SANE_Parameters changes to suit the image format improvement. 
> It also gives new informations such as a proposed filename and X/Y dpi.

these should be re-addressed.

>
>  options changes:
> - capability hidden and allways settable added
> - more commonly used options are now part of the standard

general idea sounds good.

>
>  SANE operations changes:
> - sane_open has a SANE_Device ** parameter

sounds good.

> - scanner's button handling

this is overly complicated, and should be re-examined.

[snip]

> But before starting, there are some things I'd like to see in the new 
> standard:
> - the current code flow is
> sane_init
> sane_open
> sane_start
> sane_read
> sane_cancel
> sane_close
> sane_exit
>
> rather than calling sane_cancel at the end of scan, I'd like 
> to have a sane_end function. Leaving the use of sane_cancel for canceling the 
> scan like it allready does. This new function would do about the same, but 
> code flow would be cleaner and easier to understand:
> sane_init
> sane_open
> sane_start
> sane_read
> sane_end
> sane_close
> sane_exit
>

this is a simple, single scan case. can you draw up what you think an
ADF or duplex scan would look like? right now, it does sane_start,
sane_read, sane_start, sane_read, sane_start, sane_read,


> - the proposed button handling would surely be better if we create 
> sane_lock_buttons(), sane_update_buttons() and sane_unlock() buttons, instead
>  of doing this with control options.

i have implemented button support in the fujitsu backend without any
locking at all, and it works well, and is compatible with SANE1. Maybe
i am missing something, but i dont see the need for the complication.

> - we should also add something about panels. Would some control 
> options be enough,  or do we also need some lock/update/unlock behavior ?

Control panels vary so widely between scanners, that i dont know if we
can build a generic facility to support them all. can you give some
examples?

> - there are some issues about backends configuration. In order to be 
> detected, some backends need their  configuration files tweaked. I think that
>  having well-known configuration options would improve  the situation and 
> would
>  also let us have a common way of accessing configuration parameters across
>  backends.

I might be inclined to go a step further and build a common config
file format, with better sanei_config support library that all
backends could use.

>
> - do we want to improve warmup handling ? Currently there is no 
> feedback when warming-up is going on, which is sometime confusing, we can 
> have the feeling that nothing is happening. Do we want a sane_warm_up() or a
>  SANE_STATUS_WARMING_UP would be enough ?
>

i would be inclined to use the status value, and perhaps a note in the
spec that the frontend should retry? this enables a backend to send
warm up during sane_start, or first sane_read, or even sane_open i
guess.

> There are other points that I feel they could be improved, but could 
> be done as we develop SANE2:
> - we need a sane type for scanner buttons. Either we rename the 
> SANE_TYPE_BUTTON to SANE_TYPE_SOFT_B

[sane-devel] hp backend fails to detect HP SCSI scanner

[m. allan noah]

and this fix has been committed to cvs.

allan

On Fri, Mar 28, 2008 at 4:58 AM, Johannes Meixner  wrote:
>
>  Hello,
>
>  On Mar 27 08:16 m. allan noah wrote (shortened):
>
> > can you get the original poster to put it back to stock, and get a
>  > debug log like this:
>  >
>  > SANE_DEBUG_SANEI_SCSI=5 SANE_DEBUG_HP=128 scanimage -L
>
>  Done.
>
>  See
>  https://bugzilla.novell.com/show_bug.cgi?id=350688#c17
>  or the debug output directly
>  https://bugzilla.novell.com/attachment.cgi?id=204409
>
>
>
>
>  Kind Regards
>  Johannes Meixner
>  --
>  SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
>  AG Nuernberg, HRB 16746, GF: Markus Rex
>
>  --
>  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] [05.20] Re: SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 11:52, Alessandro Zummo wrote:

> On Fri, 28 Mar 2008 09:34:22 +0100
> Rene Rebe  wrote:
>
>>
>>> I believe that Stef has made very clear its intentions
>>> to go toward SANE 2. TWAIn for linux would be a complete
>>> rewrite of everything, and compatible changes to SANE1 are
>>> already available in SANE Evolution
>>
>>
>> As SANE2 is a quite complete rewrite anyway, it makes more
>> sense to adopt and contribute to an wide industry standard
>> than to try to force yet another incompatible API into the wild.
>
> It's true that is a de facto standard, but it is so only
> for windows machines, right? So given that there is no prior
> art in the unix world and that the sane userbase is (I think)
> almost Linux, there's no particular reason to go for it.

Mac OS < 10 and Mac OS X as well. There is no reason
not to use it on Linux, Unix, ...

> SANE2 is a rewrite but it has a sense of coherence with
> SANE1 and with the user base.

When the SANE1 user- and application-base has to adapt
to incompatible rewrites they could also adapt to something
more standard.

Btw. most programs, like Gimp, OpenOffice et. al. come with
TWAIN support for the other OSs anyway.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   Gesch?ftsf?hrer: Susanne Klaus, Ren? Rebe
   Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
   USt-IdNr.: DE251602478
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] [PATCH] make scanimage work with HP ScanJet (HP 6250C), finally

[Jim Meyering]

Peter Kirchgessner  wrote:
> I have no problem if the usleep(1000) is added. If it helps, it's
> ok. For a typical scan about 200 inquiries are done. So setting up the
> scanner is slowed down by 0.2 seconds in total. That is far less than
> the scan will need.
> I don't know if it is possible with libusb to check if an answer of
> the scanner is available or not. But if you tried increasing the value
> and it still did not work every second run I would say there are still
> some other problems with USB. My ScanJet 6250 is working without
> problems for years using USB.

Thanks for looking at it.
Maybe we have different hardware, in spite of the
identical model numbers.  Mine is 9 or 10 years old.
I don't recall if I ever updated the driver.
Do you know which you have?

> Who will apply the patch to the official SANE-backends ?

Who do we prod? ;-)

[sane-devel] [PATCH] make scanimage work with HP ScanJet (HP 6250C), finally

[m. allan noah]

On Fri, Mar 28, 2008 at 10:25 AM, Jim Meyering  wrote:
> Peter Kirchgessner  wrote:
>  > I have no problem if the usleep(1000) is added. If it helps, it's
>  > ok. For a typical scan about 200 inquiries are done. So setting up the
>  > scanner is slowed down by 0.2 seconds in total. That is far less than
>  > the scan will need.
>  > I don't know if it is possible with libusb to check if an answer of
>  > the scanner is available or not. But if you tried increasing the value
>  > and it still did not work every second run I would say there are still
>  > some other problems with USB. My ScanJet 6250 is working without
>  > problems for years using USB.
>
>  Thanks for looking at it.
>  Maybe we have different hardware, in spite of the
>  identical model numbers.  Mine is 9 or 10 years old.
>  I don't recall if I ever updated the driver.
>  Do you know which you have?
>
>
>  > Who will apply the patch to the official SANE-backends ?
>
>  Who do we prod? ;-)
>

i will do it now. however, there still seem to be some issues for me,
so i might find some time to play with it in the next few weeks, and
produce another patch. would you be willing to test that?

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] [PATCH] make scanimage work with HP ScanJet (HP 6250C), finally

[Jim Meyering]

"m. allan noah"  wrote:
> On Fri, Mar 28, 2008 at 10:25 AM, Jim Meyering  wrote:
>> Peter Kirchgessner  wrote:
>>  > I have no problem if the usleep(1000) is added. If it helps, it's
>>  > ok. For a typical scan about 200 inquiries are done. So setting up the
>>  > scanner is slowed down by 0.2 seconds in total. That is far less than
>>  > the scan will need.
>>  > I don't know if it is possible with libusb to check if an answer of
>>  > the scanner is available or not. But if you tried increasing the value
>>  > and it still did not work every second run I would say there are still
>>  > some other problems with USB. My ScanJet 6250 is working without
>>  > problems for years using USB.
>>
>>  Thanks for looking at it.
>>  Maybe we have different hardware, in spite of the
>>  identical model numbers.  Mine is 9 or 10 years old.
>>  I don't recall if I ever updated the driver.
>>  Do you know which you have?
>>
>>
>>  > Who will apply the patch to the official SANE-backends ?
>>
>>  Who do we prod? ;-)
>
> i will do it now. however, there still seem to be some issues for me,

Thanks.

> so i might find some time to play with it in the next few weeks, and
> produce another patch. would you be willing to test that?

Sure.

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi Allan,

On 28.03.2008, at 14:46, m. allan noah wrote:

> On Thu, Mar 27, 2008 at 1:22 PM, stef  wrote:
>>Hello,
>>
>>before any work can start on SANE 2, the current proposal  
>> has to be completed.
>
> and before we can complete it, we must acknowlege that it has not been
> touched in 5 years, and many of its contributors are no longer active,
> and many current sane devels (myself included) were not party to any
> of the discussions.

Actually I was active the time but never saw a need for an incompatible
change that has zero benefit for the 150++ scanners my Avision backend
supports and just consumes more of my time.

Right now the only thing I miss are marks for infra-red frames, and  
maybe
a ability to pass duplex data without buffering the rear side, which  
becomes
even more of a problem with the next generation, higher end devices I  
got
here on my desk due to the immense amount of data generate at that
speed (I got prototypes of future products here, so I can not name  
numbers,
but the current devices already support up to 60 pages per minute, which
are 120 images per minute, so you can imagine ...).

Buffering and reading that data just needlessly consumes CPU cycles and
contribute to data processing gaps between the pages.

Btw. I think the consumer scanner market is falling away anyway, because
the main use to scan photos is no longer needed with the rise of digital
cameras. So API innovation are most required for the mostly remaining
need where the document are in use and we need to process more
data with less overhead.

>>The major change is the image data format. SANE 2 will be  
>> able to handle new formats easily (which matches the current needs,  
>> especially regarding ir
>>  channel). There will be 2 major image format, one pixel oriented  
>> and the other will give images as a mime attachment. There is also  
>> standard part for button handling.
>
> but the mime type code creates new problems. it will allow any backend
> to produce any kind of output that it wishes, as long as there is a
> mime-type for it. frontends will never know what to expect. I would
> much rather produce a list of known frame types, and put a note in the
> standard that frontend devels should expect new types to be added.
> this enables us to specify exactly how common types will be presented.

Ack
.
>>- scanner's button handling
>
> this is overly complicated, and should be re-examined.
>
> [snip]

Ack.

>>But before starting, there are some things I'd like to see  
>> in the new standard:
>>- the current code flow is
>>sane_init
>>sane_open
>>sane_start
>>sane_read
>>sane_cancel
>>sane_close
>>sane_exit
>>
>>rather than calling sane_cancel at the end of scan,  
>> I'd like to have a sane_end function. Leaving the use of  
>> sane_cancel for canceling the scan like it allready does. This new  
>> function would do about the same, but code flow would be cleaner  
>> and easier to understand:
>>sane_init
>>sane_open
>>sane_start
>>sane_read
>>sane_end
>>sane_close
>>sane_exit
>>
>
> this is a simple, single scan case. can you draw up what you think an
> ADF or duplex scan would look like? right now, it does sane_start,
> sane_read, sane_start, sane_read, sane_start, sane_read,

I do not see a problem in this call graph. Sure, we could leave the
cancel (or rename it to _end :-), however existing codebase like
frontends (applications) have deal with the current API and
backends (drivers) anyway. This is what I mean when I declare
unnecessary work. The gain is just a little nicer callgraph on
the paper.

>>- the proposed button handling would surely be better if we  
>> create sane_lock_buttons(), sane_update_buttons() and sane_unlock()  
>> buttons, instead
>> of doing this with control options.
>
> i have implemented button support in the fujitsu backend without any
> locking at all, and it works well, and is compatible with SANE1. Maybe
> i am missing something, but i dont see the need for the complication.

Ditto for the Avision backend.


>>- we should also add something about panels. Would some  
>> control options be enough,  or do we also need some lock/update/ 
>> unlock behavior ?
>
> Control panels vary so widely between scanners, that i dont know if we
> can build a generic facility to support them all. can you give some
> examples?

Yes, they differ a lot. From profile selection of current Avision (and
OEM) devices, to simplex duplex buttons, to even whole resolution
and color selection of the HP 7400 even in the Avision family of
devices.

I finally support this  (except the 7400 which I did not found spare
time for) by just having a single message option in th

[sane-devel] Xsane & the Epson V200

[Doug Robinson]

Hello

My friend has a Ubuntu 7.10 system on an older machine, which seems
to work fine.

I installed the drivers as suggested at
http://www.avasys.jp/english/linux_e/dl_scan.html

and all is not well.

It works fine at 300 dpi but 1200 dpi & 4800 dpi produce a box with
the message

"Out of memory". It seem unlikely the  system is out of memory it has 1
GB. So what does this
message mean | what is running out of memory?

Thanks for your time.

dkr

[sane-devel] SANE2 standard completion

[Oliver Rauch]

I can not believe it.

There is someone who says I will start working on SANE2 and you have
nothing better to do than to tell him it is better not to do it.

This is called progress. Really good.


Best regards
Oliver

Am Freitag, den 28.03.2008, 08:52 +0100 schrieb Rene Rebe:
> Have you counted thru how many developers are willing to rewrite
> their code (backends, frontends, etc.) for this arbitrarily defined SANE
> 2 "thing" ?
> 
> My votes still are: preferably compatibly change SANE 1 or adopt
> TWAIN for Linux.
> 
> On 27.03.2008, at 18:22, stef wrote:
> 
> > Hello,
> >
> > before any work can start on SANE 2, the current proposal has to be  
> > completed.
> >
> > The major change is the image data format. SANE 2 will be able to  
> > handle new formats easily (which matches the current needs,  
> > especially regarding ir
> > channel). There will be 2 major image format, one pixel oriented and  
> > the other will give images as a mime attachment. There is also  
> > standard part for button handling.
> >
> > Here is a summary of the differences between SANE 1 and SANE 2  
> > proposal standards:
> >
> > structures changes:
> > - the SANE_Device struct has more fields, giving contact  
> > information about the devices in case of bug, and the ability to  
> > send device capability flags
> > - the SANE_Parameters changes to suit the image format improvement.  
> > It also gives new informations such as a proposed filename and X/Y  
> > dpi.
> > 
> > options changes:
> > - capability hidden and allways settable added
> > - more commonly used options are now part of the standard
> >
> > SANE operations changes:
> > - sane_open has a SANE_Device ** parameter
> > - scanner's button handling
> >
> > newtwork operation:
> > The Network Protocol chapter seems to lag behind the SANE 1  
> > chapter, and the SANE_NET_OPEN call needs to be updated to reflect  
> > sane_open evolution.
> >
> > The current proposal is in good shape, and the change regarding 
> >  
> > image format seems to suit the current need for new formats.  
> > Converting current backends
> > to SANE2 doesn't seem that difficult.
> >
> > But before starting, there are some things I'd like to see in the  
> > new standard:
> > - the current code flow is
> > sane_init
> > sane_open
> > sane_start
> > sane_read
> > sane_cancel
> > sane_close
> > sane_exit
> > 
> > rather than calling sane_cancel at the end of scan, I'd like to 
> >  
> > have a sane_end function. Leaving the use of sane_cancel for  
> > canceling the scan like it allready does. This new function would do  
> > about the same, but code flow would be cleaner and easier to  
> > understand:
> > sane_init
> > sane_open
> > sane_start
> > sane_read
> > sane_end
> > sane_close
> > sane_exit
> > 
> > - the proposed button handling would surely be better if we create  
> > sane_lock_buttons(), sane_update_buttons() and sane_unlock()  
> > buttons, instead
> > of doing this with control options.
> > 
> > - we should also add something about panels. Would some control  
> > options be enough,  or do we also need some lock/update/unlock  
> > behavior ?
> > 
> > - there are some issues about backends configuration. In order to  
> > be detected, some backends need their  configuration files tweaked.  
> > I think that
> > having well-known configuration options would improve  the situation  
> > and would
> > also let us have a common way of accessing configuration parameters  
> > across
> > backends.
> > 
> > - do we want to improve warmup handling ? Currently there is no  
> > feedback when warming-up is going on, which is sometime confusing,  
> > we can have the feeling that nothing is happening. Do we want a  
> > sane_warm_up() or a
> > SANE_STATUS_WARMING_UP would be enough ?
> > 
> > There are other points that I feel they could be improved, but  
> > could be done as we develop SANE2:
> > - we need a sane type for scanner buttons. Either we rename the  
> > SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON for
> > physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a  
> > frontend can easily detect hardware buttons. There should be a list  
> > of well-known buttons
> > description to use when  possible.
> > - a SANE_TYPE_PANEL would be handy
> > - since there are well-know options there should be well-known  
> > groups, and the SANE_CAP of these options should also be given.
> > - a SANE_STATUS_LOCKED could be added to handle the case where the  
> > hardware lock of a scanner has been left.
> > 
> > Regards,
> > Stef
> > 
> > 
> >
> > -- 
> > sane-devel mailing list: sane-devel at lis

[sane-devel] SANE2 standard completion

[Julien BLACHE]

"m. allan noah"  wrote:

Hi,

>> - scanner's button handling
>
> this is overly complicated, and should be re-examined.

For that and other reasons, I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.

This would provide a central point (saned) handling the hardware
entirely, it can chat with other things (HAL, anything over D-Bus, you
name it) and we totally avoid the current side effects we have today.

The more I think about it, the more I think this is the way to go.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 18:40, Oliver Rauch wrote:

> I can not believe it.
>
> There is someone who says I will start working on SANE2 and you have
> nothing better to do than to tell him it is better not to do it.

I did not tell him not to, but expressed my disbelieve in the whole  
rewrite
"everything" approach.

You did not even reply ta my last mail where I note that TWAIN is not
that far off, and also has the quite same notion regarding frontends and
backends.

> This is called progress. Really good.

I do not call ever changing APIs a progress, a process in which probably
a lot of older drivers will just be left lingering around and vanish.

Microsoft has not archived such a penetration because they changed
the API thus annoyed users and developers all the time, but preserved
some sort of compatibility.

LIkewise X-Windows and Linux do not break (at least the external) API
continuously. And yes, if you do a Google search you notice I contribute
to all of them.

If some of you have too much free time they better grab one of the not
yet supported devices and get some new backend running, or existing
one improved. Changing internal or external APIs for god's sake does
not look too useful from my perspective.

Still, that is MHO - you are free to do whatever, even implement an
API that we do still not agree on.

I can tell you one thing fore sure, before I rewrite my backend for your
fun, I rather go and join the TWAIN working group.

Yours,
   Ren?

> Best regards
> Oliver
>
> Am Freitag, den 28.03.2008, 08:52 +0100 schrieb Rene Rebe:
>> Have you counted thru how many developers are willing to rewrite
>> their code (backends, frontends, etc.) for this arbitrarily defined  
>> SANE
>> 2 "thing" ?
>>
>> My votes still are: preferably compatibly change SANE 1 or adopt
>> TWAIN for Linux.
>>
>> On 27.03.2008, at 18:22, stef wrote:
>>
>>> Hello,
>>>
>>> before any work can start on SANE 2, the current proposal has to be
>>> completed.
>>>
>>> The major change is the image data format. SANE 2 will be able to
>>> handle new formats easily (which matches the current needs,
>>> especially regarding ir
>>> channel). There will be 2 major image format, one pixel oriented and
>>> the other will give images as a mime attachment. There is also
>>> standard part for button handling.
>>>
>>> Here is a summary of the differences between SANE 1 and SANE 2
>>> proposal standards:
>>>
>>> structures changes:
>>> - the SANE_Device struct has more fields, giving contact
>>> information about the devices in case of bug, and the ability to
>>> send device capability flags
>>> - the SANE_Parameters changes to suit the image format improvement.
>>> It also gives new informations such as a proposed filename and X/Y
>>> dpi.
>>> 
>>> options changes:
>>> - capability hidden and allways settable added
>>> - more commonly used options are now part of the standard
>>>
>>> SANE operations changes:
>>> - sane_open has a SANE_Device ** parameter
>>> - scanner's button handling
>>>
>>> newtwork operation:
>>> The Network Protocol chapter seems to lag behind the SANE 1
>>> chapter, and the SANE_NET_OPEN call needs to be updated to reflect
>>> sane_open evolution.
>>>
>>> The current proposal is in good shape, and the change regarding
>>> image format seems to suit the current need for new formats.
>>> Converting current backends
>>> to SANE2 doesn't seem that difficult.
>>>
>>> But before starting, there are some things I'd like to see in the
>>> new standard:
>>> - the current code flow is
>>> sane_init
>>> sane_open
>>> sane_start
>>> sane_read
>>> sane_cancel
>>> sane_close
>>> sane_exit
>>> 
>>> rather than calling sane_cancel at the end of scan, I'd like to
>>> have a sane_end function. Leaving the use of sane_cancel for
>>> canceling the scan like it allready does. This new function would do
>>> about the same, but code flow would be cleaner and easier to
>>> understand:
>>> sane_init
>>> sane_open
>>> sane_start
>>> sane_read
>>> sane_end
>>> sane_close
>>> sane_exit
>>> 
>>> - the proposed button handling would surely be better if we create
>>> sane_lock_buttons(), sane_update_buttons() and sane_unlock()
>>> buttons, instead
>>> of doing this with control options.
>>> 
>>> - we should also add something about panels. Would some control
>>> options be enough,  or do we also need some lock/update/unlock
>>> behavior ?
>>> 
>>> - there are some issues about backends configuration. In order to
>>> be detected, some backends need their  configuration files tweaked.
>>> I think that
>>> having well-known configuration options would improve  the situation
>>> and would
>>> also let us have a common way of accessing configuration param

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 18:40, Julien BLACHE wrote:

> "m. allan noah"  wrote:
>
> Hi,
>
>>>- scanner's button handling
>>
>> this is overly complicated, and should be re-examined.
>
> For that and other reasons, I think it'd really be better to have the
> frontends be entirely isolated from the backends, as I explained
> already.
>
> This would provide a central point (saned) handling the hardware
> entirely, it can chat with other things (HAL, anything over D-Bus, you
> name it) and we totally avoid the current side effects we have today.
>
> The more I think about it, the more I think this is the way to go.

Sounds a bit Data Source Manager like-ish (in TWAIN terms), definetly
and idea for desktops.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

> This would provide a central point (saned) handling the hardware
> entirely, it can chat with other things (HAL, anything over D-Bus, you
> name it) and we totally avoid the current side effects we have today.

Do you mean having some cups for scanner ?

Actually, i wish not, because users don't want another service. HAL can
launch addon per device which allow to launch nothing if no scanner
present.

On the other end, scanner are more and more for professionnal which
heavily use networked scanner, thus, having a protocol (like ipp for
printing might be a good idea). But who will develop this ? How much
years ?

Regards,
?tienne.

[sane-devel] SANE2 standard completion

[Alessandro Zummo]

On Fri, 28 Mar 2008 15:49:17 +0100
Rene Rebe  wrote:

> 
> Right now the only thing I miss are marks for infra-red frames, and  
> maybe
> a ability to pass duplex data without buffering the rear side, which  
> becomes
> even more of a problem with the next generation, higher end devices I  
> got

 I'm interested in this.. you receive the data of two pages at
 the same time? It's interleaved in some way?


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2 standard completion

[Julien BLACHE]

?tienne Bersac  wrote:

Hi,

> Do you mean having some cups for scanner ?

Something much more simple than CUPS, but yeah, basically.

> Actually, i wish not, because users don't want another service. HAL can
> launch addon per device which allow to launch nothing if no scanner
> present.

Could you PLEASE stop thinking "HAL" all the time? I don't use HAL, I
don't want to use HAL, I don't need HAL for fsck's sake.

Other OSes do not have HAL.

HAL is, will be and must be an add-on, and nothing more. It must not
be either a dependency or a pre-requisite.

> On the other end, scanner are more and more for professionnal which
> heavily use networked scanner, thus, having a protocol (like ipp for
> printing might be a good idea). But who will develop this ? How much
> years ?

Based on the current saned, it can already be achieved:
 - link saned statically to libsane-dll (what we know as libsane
   today)
 - ship libsane-net as libsane
 - add a local connection to saned, typically a UNIX socket and listen
   to that and that only unless general networking is explicitly
   enabled. Ditto libsane only connects to the UNIX socket by
   default. (the UNIX socket wins hands down against localhost/TCP)

There, done. Keep all the underlying architecture as far as saned is
concerned.

After that, implement whatever new feature you want in the
backends. The backends API is now a private API between saned and the
backends. Updates to the public SANE API as implemented by libsane
only requires changing libsane. As an added bonus, a compat layer can
probably be offered for current backends that cannot be modified.

The network protocol will also probably need to change at some point,
I haven't thought about that particular point yet. More interactivity,
more status messages and the ability to feed scan data over a unique
TCP stream would be nice.

User ACLs can be added to the mix.

We're losing the ability to link an application to a backend directly
as is possible today, but it's seldomly use and we're getting rid of
those frigging side effects we have today.

If we're redoing SANE, let's at least do it the right way. Investing
time and effort into something that'll only be marginally better than
what we have today makes no sense.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Julien BLACHE]

Rene Rebe  wrote:

Hi,

> Sounds a bit Data Source Manager like-ish (in TWAIN terms), definetly
> and idea for desktops.

Yes. From what you told about TWAIN the other day, I think I like the
architecture. I don't know enough about TWAIN to tell for sure,
though.


Oh, I forgot to add: we get real locking/device management that way,
too.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:02, Alessandro Zummo wrote:

> On Fri, 28 Mar 2008 15:49:17 +0100
> Rene Rebe  wrote:
>
>>
>> Right now the only thing I miss are marks for infra-red frames, and
>> maybe
>> a ability to pass duplex data without buffering the rear side, which
>> becomes
>> even more of a problem with the next generation, higher end devices I
>> got
>
> I'm interested in this.. you receive the data of two pages at
> the same time? It's interleaved in some way?

I speak about the duplex devices here, which have 2 CCDs (or
similar and scan both sides at the same time (long supported by
the Avision backend, btw. :-)

Avision developed several ways to transfer the duplex data (aside
from the few, trivial) paper flipping devices with just a single CCD),
for some they buffer the page in-memory inside the scanner, for newer
ones there are several interlaced variants.

For the interlaced variants I so far buffer the rear stripes in the  
backend
and return the backed data every second frame.

Probably the fujitsu backend does something similar.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   Gesch?ftsf?hrer: Susanne Klaus, Ren? Rebe
   Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
   USt-IdNr.: DE251602478
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 19:09, Julien BLACHE wrote:

> ?tienne Bersac  wrote:
>
> Hi,
>
>> Do you mean having some cups for scanner ?
>
> Something much more simple than CUPS, but yeah, basically.
>
>> Actually, i wish not, because users don't want another service. HAL  
>> can
>> launch addon per device which allow to launch nothing if no scanner
>> present.
>
> Could you PLEASE stop thinking "HAL" all the time? I don't use HAL, I
> don't want to use HAL, I don't need HAL for fsck's sake.
>
> Other OSes do not have HAL.
>
> HAL is, will be and must be an add-on, and nothing more. It must not
> be either a dependency or a pre-requisite.
>
>> On the other end, scanner are more and more for professionnal which
>> heavily use networked scanner, thus, having a protocol (like ipp for
>> printing might be a good idea). But who will develop this ? How much
>> years ?
>
> Based on the current saned, it can already be achieved:
> - link saned statically to libsane-dll (what we know as libsane
>   today)
> - ship libsane-net as libsane
> - add a local connection to saned, typically a UNIX socket and listen
>   to that and that only unless general networking is explicitly
>   enabled. Ditto libsane only connects to the UNIX socket by
>   default. (the UNIX socket wins hands down against localhost/TCP)
>
> There, done. Keep all the underlying architecture as far as saned is
> concerned.
>
> After that, implement whatever new feature you want in the
> backends. The backends API is now a private API between saned and the
> backends. Updates to the public SANE API as implemented by libsane
> only requires changing libsane. As an added bonus, a compat layer can
> probably be offered for current backends that cannot be modified.
>
> The network protocol will also probably need to change at some point,
> I haven't thought about that particular point yet. More interactivity,
> more status messages and the ability to feed scan data over a unique
> TCP stream would be nice.
>
> User ACLs can be added to the mix.
>
> We're losing the ability to link an application to a backend directly
> as is possible today, but it's seldomly use and we're getting rid of
> those frigging side effects we have today.
>
> If we're redoing SANE, let's at least do it the right way. Investing
> time and effort into something that'll only be marginally better than
> what we have today makes no sense.

+1 from me.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[m. allan noah]

On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe  wrote:
>
>  On 28.03.2008, at 19:02, Alessandro Zummo wrote:
>
>  > On Fri, 28 Mar 2008 15:49:17 +0100
>  > Rene Rebe  wrote:
>  >
>  >>
>  >> Right now the only thing I miss are marks for infra-red frames, and
>  >> maybe
>  >> a ability to pass duplex data without buffering the rear side, which
>  >> becomes
>  >> even more of a problem with the next generation, higher end devices I
>  >> got
>  >
>  > I'm interested in this.. you receive the data of two pages at
>  > the same time? It's interleaved in some way?
>
>  I speak about the duplex devices here, which have 2 CCDs (or
>  similar and scan both sides at the same time (long supported by
>  the Avision backend, btw. :-)
>
>  Avision developed several ways to transfer the duplex data (aside
>  from the few, trivial) paper flipping devices with just a single CCD),
>  for some they buffer the page in-memory inside the scanner, for newer
>  ones there are several interlaced variants.
>
>  For the interlaced variants I so far buffer the rear stripes in the
>  backend
>  and return the backed data every second frame.
>
>  Probably the fujitsu backend does something similar.
>

yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
you will see several variants.

my (as yet unreleased) backend for the big kodak machines does not
have this problem, because the machines have tons of ram, and buffer
the images themselves, and there is no way to stop it :)

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 19:13, Julien BLACHE wrote:

> Rene Rebe  wrote:
>
> Hi,
>
>> Sounds a bit Data Source Manager like-ish (in TWAIN terms), definetly
>> and idea for desktops.
>
> Yes. From what you told about TWAIN the other day, I think I like the
> architecture. I don't know enough about TWAIN to tell for sure,
> though.
>
>
> Oh, I forgot to add: we get real locking/device management that way,
> too.

The TWAIN standard is open, and here is the link:

   http://twain.org/docs/TWAIN19.pdf

Actually the capabilities are even quite similar.

In retrospect I wonder why TWAIN was not used when SANE was
started for the open / free OSs. Maybe just to do it differently than
on Windows and the Mac.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] Xsane & the Epson V200

[m. allan noah]

the sane project does not provide this driver. i would suggest that
you ask the maker.

allan

On Fri, Mar 28, 2008 at 12:52 PM, Doug Robinson  wrote:
> Hello
>
> My friend has a Ubuntu 7.10 system on an older machine, which seems
>  to work fine.
>
> I installed the drivers as suggested at
>  http://www.avasys.jp/english/linux_e/dl_scan.html
>  
>  and all is not well.
>
> It works fine at 300 dpi but 1200 dpi & 4800 dpi produce a box with
>  the message
>
>  "Out of memory". It seem unlikely the  system is out of memory it has 1
>  GB. So what does this
>  message mean | what is running out of memory?
>
> Thanks for your time.
>
>  dkr
>
>
>
>  --
>  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] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:19, m. allan noah wrote:

> On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe  wrote:
>>
>> On 28.03.2008, at 19:02, Alessandro Zummo wrote:
>>
>>> On Fri, 28 Mar 2008 15:49:17 +0100
>>> Rene Rebe  wrote:
>>>

 Right now the only thing I miss are marks for infra-red frames, and
 maybe
 a ability to pass duplex data without buffering the rear side,  
 which
 becomes
 even more of a problem with the next generation, higher end  
 devices I
 got
>>>
>>> I'm interested in this.. you receive the data of two pages at
>>> the same time? It's interleaved in some way?
>>
>> I speak about the duplex devices here, which have 2 CCDs (or
>> similar and scan both sides at the same time (long supported by
>> the Avision backend, btw. :-)
>>
>> Avision developed several ways to transfer the duplex data (aside
>> from the few, trivial) paper flipping devices with just a single  
>> CCD),
>> for some they buffer the page in-memory inside the scanner, for newer
>> ones there are several interlaced variants.
>>
>> For the interlaced variants I so far buffer the rear stripes in the
>> backend
>> and return the backed data every second frame.
>>
>> Probably the fujitsu backend does something similar.
>>
>
> yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
> you will see several variants.
>
> my (as yet unreleased) backend for the big kodak machines does not
> have this problem, because the machines have tons of ram, and buffer
> the images themselves, and there is no way to stop it :)

WIth "no way to stop", you mean no way to stop the processing? Because
that is also a point that could get improvements in SANE, the backend
should these days better push the data to the frontend, like begin page,
data, end page. As the bigger machines tend to deliver data so fast they
only honor a cancel with n++ pages in memory or on the network wire ...
(or not at all).

IMHO that are areas where SANE could _evolve_, not some cosmetic
mime-types, or s/sane_cancel/sane_end/

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[m. allan noah]

On Fri, Mar 28, 2008 at 2:28 PM, Rene Rebe  wrote:
>
>
>  On 28.03.2008, at 19:19, m. allan noah wrote:
>
>
> > On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe  wrote:
> >
> > >
> > > On 28.03.2008, at 19:02, Alessandro Zummo wrote:
> > >
> > >
> > > > On Fri, 28 Mar 2008 15:49:17 +0100
> > > > Rene Rebe  wrote:
> > > >
> > > >
> > > > >
> > > > > Right now the only thing I miss are marks for infra-red frames, and
> > > > > maybe
> > > > > a ability to pass duplex data without buffering the rear side, which
> > > > > becomes
> > > > > even more of a problem with the next generation, higher end devices
> I
> > > > > got
> > > > >
> > > >
> > > > I'm interested in this.. you receive the data of two pages at
> > > > the same time? It's interleaved in some way?
> > > >
> > >
> > > I speak about the duplex devices here, which have 2 CCDs (or
> > > similar and scan both sides at the same time (long supported by
> > > the Avision backend, btw. :-)
> > >
> > > Avision developed several ways to transfer the duplex data (aside
> > > from the few, trivial) paper flipping devices with just a single CCD),
> > > for some they buffer the page in-memory inside the scanner, for newer
> > > ones there are several interlaced variants.
> > >
> > > For the interlaced variants I so far buffer the rear stripes in the
> > > backend
> > > and return the backed data every second frame.
> > >
> > > Probably the fujitsu backend does something similar.
> > >
> > >
> >
> > yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
> > you will see several variants.
> >
> > my (as yet unreleased) backend for the big kodak machines does not
> > have this problem, because the machines have tons of ram, and buffer
> > the images themselves, and there is no way to stop it :)
> >
>
>  WIth "no way to stop", you mean no way to stop the processing?

no- i mean no way to tell scanner that you want it to interlace front and back.

>  Because
>  that is also a point that could get improvements in SANE, the backend
>  should these days better push the data to the frontend, like begin page,
>  data, end page. As the bigger machines tend to deliver data so fast they
>  only honor a cancel with n++ pages in memory or on the network wire ...
>  (or not at all).

this is true of the bigger machines, it might be 20 or 30 pages ahead
of the wire when the cancel call comes in, especially if you are not
using a compressed image type.

for your other points, i dont really see how push is any better than
blocking pull...

allan
-- 
"The truth is an offense, but not a sin"

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

> Could you PLEASE stop thinking "HAL" all the time?

Could you please stop taking HAL as an offense all the time ?

By talking about HAL, i mean do not impose another system service and
let external project do it on top of SANE, be it either a DBus daemon, a
HAL addon, a regular daemon, etc.

?tienne.
-- 
All?luia !

[sane-devel] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:34, m. allan noah wrote:

> On Fri, Mar 28, 2008 at 2:28 PM, Rene Rebe  wrote:
>>
>>
>> On 28.03.2008, at 19:19, m. allan noah wrote:
>>
>>
>>> On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe   
>>> wrote:
>>>

 On 28.03.2008, at 19:02, Alessandro Zummo wrote:


> On Fri, 28 Mar 2008 15:49:17 +0100
> Rene Rebe  wrote:
>
>
>>
>> Right now the only thing I miss are marks for infra-red frames,  
>> and
>> maybe
>> a ability to pass duplex data without buffering the rear side,  
>> which
>> becomes
>> even more of a problem with the next generation, higher end  
>> devices
>> I
>> got
>>
>
> I'm interested in this.. you receive the data of two pages at
> the same time? It's interleaved in some way?
>

 I speak about the duplex devices here, which have 2 CCDs (or
 similar and scan both sides at the same time (long supported by
 the Avision backend, btw. :-)

 Avision developed several ways to transfer the duplex data (aside
 from the few, trivial) paper flipping devices with just a single  
 CCD),
 for some they buffer the page in-memory inside the scanner, for  
 newer
 ones there are several interlaced variants.

 For the interlaced variants I so far buffer the rear stripes in the
 backend
 and return the backed data every second frame.

 Probably the fujitsu backend does something similar.


>>>
>>> yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
>>> you will see several variants.
>>>
>>> my (as yet unreleased) backend for the big kodak machines does not
>>> have this problem, because the machines have tons of ram, and buffer
>>> the images themselves, and there is no way to stop it :)
>>>
>>
>> WIth "no way to stop", you mean no way to stop the processing?
>
> no- i mean no way to tell scanner that you want it to interlace  
> front and back.
>
>> Because
>> that is also a point that could get improvements in SANE, the backend
>> should these days better push the data to the frontend, like begin  
>> page,
>> data, end page. As the bigger machines tend to deliver data so fast  
>> they
>> only honor a cancel with n++ pages in memory or on the network  
>> wire ...
>> (or not at all).
>
> this is true of the bigger machines, it might be 20 or 30 pages ahead
> of the wire when the cancel call comes in, especially if you are not
> using a compressed image type.
>
> for your other points, i dont really see how push is any better than
> blocking pull...

I found some machines touchy when the data is not cleared, so
in cancel or close you sometimes end up throwing data away
until the device is in a sane state again, ... An future version
of SANE using a push model would make that easier to
code, and IIRC there where issues with endorser pages
might have a scan index no. printed which where thrown
away later on, etc. pp.

It is not a must, as I said I'm more happy with the current SANE
than an artificially forced SANE2. One can usually convert
and poll etc. as needed, despite printed endorser guarantees,
but IIRC we just ended up with some custom scan script that
would throw all images into the database anyway, as you
usually do not use like scanimage in production :-)

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[Julien BLACHE]

Rene Rebe  wrote:

> The TWAIN standard is open, and here is the link:
>
>   http://twain.org/docs/TWAIN19.pdf

Back in the days, ISTR it wasn't open. I'll try to find some time to
go through it.

> Actually the capabilities are even quite similar.

That's what makes the most sense I think, so it's no surprise.

> In retrospect I wonder why TWAIN was not used when SANE was
> started for the open / free OSs. Maybe just to do it differently than
> on Windows and the Mac.

NIH syndrom? :) I wasn't here back then, but my feeling about TWAIN at
that time (was fiddling with a handheld scanner on Windows 3.11) was
that it was something really complicated, so I can understand why SANE
came out as something simpler.

These days, we may not see TWAIN as something as complicated as we
used to think back then because we're now used to similar designs all
over the place (and the cost of such designs in terms of code and
runtime performance is quite smaller these days, too).

Well, OK, enough random thoughts ;)

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Julien BLACHE]

?tienne Bersac  wrote:

> By talking about HAL, i mean do not impose another system service and
> let external project do it on top of SANE, be it either a DBus daemon, a
> HAL addon, a regular daemon, etc.

Bar telling "no new service please, HAL can launch things as needed".

Yeah, that's it.

I also quite like the "users don't want another daemon running",
coming from the HAL/udev/FAM/gconfd side. I'm forgetting a couple, I'm
sure.

I'm quite sick of the desktop people trying to overtake
everything. Everything is not a desktop, the desktop is only one use
case. And we DO care about it, thanks very much.

Integrating WITH a desktop doesn't mean writing the whole stack FOR
the desktop. There are things that must be taken into consideration in
the process, but that's it.

Now, please try to understand that.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[m. allan noah]

On 3/28/08, Julien BLACHE  wrote:
> ?tienne Bersac  wrote:
>
>
> > By talking about HAL, i mean do not impose another system service and
>  > let external project do it on top of SANE, be it either a DBus daemon, a
>  > HAL addon, a regular daemon, etc.
>
>
> Bar telling "no new service please, HAL can launch things as needed".
>
>  Yeah, that's it.
>
>  I also quite like the "users don't want another daemon running",
>  coming from the HAL/udev/FAM/gconfd side. I'm forgetting a couple, I'm
>  sure.
>
>  I'm quite sick of the desktop people trying to overtake
>  everything. Everything is not a desktop, the desktop is only one use
>  case. And we DO care about it, thanks very much.
>
>  Integrating WITH a desktop doesn't mean writing the whole stack FOR
>  the desktop. There are things that must be taken into consideration in
>  the process, but that's it.
>
>  Now, please try to understand that.

yes- especially if you are going to go blogging about us behind our backs :)

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] SANE2, what do we want ?

[stef]

Hello,

it seems that the real question is what do we want for SANE future ?

1 - the current situation is perfectly fine, don't need to change a 
thing.

2 - only a couple of new image formats are needed, simply evolve a few 
things.

3 - put together the things we need to improve SANE, and have a new 
standard.

4 - other proposition ...

I think that once there is an agreement on a common goal for SANE, it 
will be easier to debate on how to achieve it.

I'm rather inclined to the "3" goal, since I feel there are quite a few 
things to do to improve SANE. Having a new standard doesn't mean SANE 1 stops 
to exist. Both can coexist.

Regards,
Stef

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

stef  wrote:

Hi,

>   I'm rather inclined to the "3" goal, since I feel there are
> quite a few things to do to improve SANE. Having a new standard
> doesn't mean SANE 1 stops to exist. Both can coexist.

Do you really think there is the needed manpower to co-maintain 2
versions of SANE?

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[stef]

Le Friday 28 March 2008 22:05:24 Julien BLACHE, vous avez ?crit?:
> stef  wrote:
> 
> Hi,
> 
> > I'm rather inclined to the "3" goal, since I feel there are
> > quite a few things to do to improve SANE. Having a new standard
> > doesn't mean SANE 1 stops to exist. Both can coexist.
> 
> Do you really think there is the needed manpower to co-maintain 2
> versions of SANE?
> 
> JB.
> 
> -- 
> Julien BLACHE    
>   GPG KeyID 0xF5D65169
> 

Hello,

indeed we are only a few people. But things can be done so that it 
isn't hard to achieve.
However, does it mean you are akin to keep things as they are ? which is -of 
course- perfectly fine.

Regards,
Stef

[sane-devel] SANE2, what do we want ?

[Till Kamppeter]

Note also one thing about the SANE2 discussion: Currently I am working 
on getting SANE1 into the LSB (I posted already about this some months 
ago and no one answered). This will help us that it is much easier for 
scanner manufacturers to ship drivers with their scanners. They can 
simply build them with the LSB DDK and then they will work on all 
(LSB-compliant) distros.

Till

stef wrote:
> Le Friday 28 March 2008 22:05:24 Julien BLACHE, vous avez ?crit :
>> stef  wrote:
>>
>> Hi,
>>
>>> I'm rather inclined to the "3" goal, since I feel there are
>>> quite a few things to do to improve SANE. Having a new standard
>>> doesn't mean SANE 1 stops to exist. Both can coexist.
>> Do you really think there is the needed manpower to co-maintain 2
>> versions of SANE?
>>
>> JB.
>>
>> -- 
>> Julien BLACHE    
>>   GPG KeyID 0xF5D65169
>>
> 
>   Hello,
> 
>   indeed we are only a few people. But things can be done so that it 
> isn't hard to achieve.
> However, does it mean you are akin to keep things as they are ? which is -of 
> course- perfectly fine.
> 
> Regards,
>   Stef
> 

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

stef  wrote:

Hi,

Your mails are horribly formatted, please wrap your lines at 72
characters. Thanks!

>   indeed we are only a few people. But things can be done so
> that it isn't hard to achieve.
> However, does it mean you are akin to keep things as they are ? which
> is -of course- perfectly fine.

No, absolutely not. From my previous postings, I think it's obvious :)

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Till Kamppeter  wrote:

> ago and no one answered). This will help us that it is much easier for 
> scanner manufacturers to ship drivers with their scanners. They can 

This is all but a good thing. Currently, binary backends provided by
the manufacturers are nothing more than a total annoyance.

They're crappy, non-debuggable, under-documented, badly written, badly
tested, and available for Linux/i386 only.

Encouraging binary backends undermines the efforts done by backends
developers over the past years to obtain specification/documentation
from the manufacturers.

Think twice, please. You're actually actively harming both SANE and
the users by doing so.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Jon Chambers]

On Friday 28 March 2008, Julien BLACHE wrote:
> > I'm rather inclined to the "3" goal, since I feel there are
> > quite a few things to do to improve SANE. Having a new standard
> > doesn't mean SANE 1 stops to exist. Both can coexist.
> Do you really think there is the needed manpower to co-maintain 2
> versions of SANE?

To expand slightly on a previously made point: supposing a new 
(non-backward-compatible) standard were to be agreed upon then two 
glue/compatibility adaptors could be written:
1. connect SANE1 frontends to SANEX backends
2. connect SANEX-only frontends to SANE1 backends

This handles the cases of binary/abandoned front and back ends.  I suspect 
that hard bit will deciding all-new standard...

My 2p's worth...

cheers,
Jon

-- 
== Jon Chambers =
 http://www.jon.demon.co.uk, 020 8575 7097, 07931 961669
=