Hi,
> but what is the frontend going to do with that, read the user's
> setting, then turn the data back around and set the resolution and
> duplex options? it seems that would be better done in the backend
> itself.?
But the frontend should be aware that the device has changed some value,
at lea
Hi,
> or perhaps scan2 or altscan?
No ! you need to keep to semantic ! altscan or scan is not
selfexplanatory. Please prefer "film" or "scan-film".
We should also state whether we should use "_" or "-" in option name. I
guess that the standard is lowercase + hyphen + digit.
?tienne.
Hi,
>From my point of view, everything is fine.
Regards,
?tienne.
Hi,
> Maybe "fax" and "copy" too?
"fax" is good, but "copy" may be redundant with print, isn't it ?
> The Canon LiDE 60 I have to hand has "copy", "scan", "pdf", "e-mail"
> buttons on the front
We should add "pdf" as well. "e-mail" should be renamed to "mailto" (or
vice versa).
Regards,
?tie
Hi,
> Then i will await your list of preferred button names :)
I suggest :
* "auto" for blank/context dependant button.
* "scan" for start button
* "cancel"
* "paper-in" but what for multiple source device ? (maybe
autoselecting source is enough ?)
*
Hi,
Agree, HW_BUTTON is redundant with HARD_SELECT. Sorry for not notifying
it earlier.
?tienne.
Hi,
> 5. One new SANE_TYPE value: HW_BUTTON (do we also need consistent names?)
Yes, well-known naming would be very nice. Fujitsu backend is fairly
good for that. This will allow frontend to predetermine action for
sensor (paper-in, cancel, etc.). The less you ask user to describe their
hardwar
Hi,
So you mean an hardware selected option that can be read after the
scan ? Sounds good !
Regards,
?tienne.
Hi,
Please avoid using paper name and rather keep using paper lengths and
let frontend use papernames on top of that. This allow frontend to use
custom paper sizes (without specifying top left corner coordinate) or i
will end up with three way of specifying ROI : coordinates, paper
lengths and pap
Hi,
> it is something
> that should be considered when the need arises, in order to not
> have the same situation we had with the options that we are now
> going to standardize.
+1000 :)
Please provide a "well-known" DTD :)
?tienne.
Hi,
Thanks alan fo this post. I agree with everything on you list. Just add
something : would it be possible to just "ensure" that all usb scanner
backends support libusb:xxx:yyy as "fallback" device name ?
Regards,
?tienne.
Hi,
> I include it based on long discussion i had with E. Bersac about adf
> machines and how to properly align the x/y coordinates when using
> paper that is narrower than the maximum.
Yes, but this mean that paper-size is paper with and height, unlike
epson "quick-format" (A4, CD cover, etc.) w
Hi,
GNOME Scan do it.
?tienne.
Hi,
> - more well known-options
I'd include more well-knonw "sensor option" like in fujitsu backend.
+1 for the entire wishlist.
?tienne.
Hi,
> Now tell me, how do you transparently share scanners from one box to
> another without a daemon?
I never said that. I said ? how to avoid running service if there is no
scanner plugged ? ?. I even implemented a daemon for polling sensor.
Please reread past mail rather than putting words in
Hi,
> GUI clients are probably the largest group of _users_ of SANE. CLI
> clients probably aquire more _images_. The needs of both groups must
> be met.
Completely agree.
Best regards,
?tienne.
Hi,
> I also quite like the "users don't want another daemon running"
Personnaly, i don't care to have a cups for scanner. But people in
distributions, dev in other pieces of the stacks and end-users tell so.
Again, we should not impose a service but rather keep at least library
(and the daemon a
Hi,
> especially if you are going to go blogging about us behind our backs :)
Do you mean i have to post each blog post about SANE here ;)
?tienne.
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.
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 d
Hi,
First of all, i have to apologize for being away from computer since few
days. This was easter days. Happy easter days :D
About proprietary backends. They have to support SANE, but SANE has not
to support those backends. Actually, as Allan said, nothing will be
break. And it's up to the propr
Hi,
> 1. a small callout, distributed with hal, which replicates the
> sanei_{usb,scsi} device naming logic, and saves this device_name
> string back into the hal data structure
>
> 2. a bigger callout, distributed with ??, which links to the dll
> backend, and takes that device_name string, and d
Hi,
Very interesting, thanks goes to SUSE for working for long time on
scanner integration with udev and HAL.
The HAL callout goal would be simply to compute the SANE device name put
it to HAL device property scanner.sane.device_name . This does not need
any SANE call as long as all backends supp
Hi,
> i think the best you can do is to require that the backend accept
> alternate names for the scanner if it is going to use something other
> than the list you gave above.
Sorry, i didn't mean to impose one unique device name, but as you said,
simply require one common naming for supporting H
Hi,
> extending sane_open just a bit to always
> support 'libusb:xxx:yyy' or '/dev/sgX' is not an API change, so could
> be implemented much sooner, and really only requires changes to the
> backends that dont already use those names, which is few.
Right. Considering that HAL currently support us
Hi,
I answer both allan and abel in this mail.
> we can also add a function like sane_get_device_information to the
> Sane API that would return data like USB bus and devices numbers [?]
> A HAL callout can then call sane_get_devices, call
> sane_get_device_information for each Sane device and c
Hi,
?
We should encapsulate all HAL/DBus call inside hal backend.
> the hal backend will load '', and ask
> it for a list of scanners it can find, and somehow pick the one that
> goes with the ''.
But how can hal backend filter the device list ? Can we avoid the actual
backend to search scanner
Hi,
In january 2007, happened a very good discussion this list about SANE
and HAL wich led to shipping a basic fdi.
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018343.html.
Currently, sane-desc generate a very basic fdi which only badge device
as scanner and add a property "
Hi,
> unfortunately, no /dev/sgX name for the device in hal, but we can use
> the host/chan/id/lun to get it.
HAL provide itself the /dev/sgX for SCSI in e.g. "linux.device_file".
Regards,
?tienne.
Hi,
> the windows software does boolean logic on this value, along with
> the state of the other buttons and sensors, to provide many 'preset'
> scan modes. it might be nice if your code could support that idea.
Agree, i'll implement this once i have user feedback. I may ping you
then for deeper
Hi,
> Could you explain which end-user issues do you like to solve?
Currently, if user put paper and push "scan" button, nothing happen.
While scanning, if user push "cancel" button, nothing happen (except
maybe some high level device like all-in-one). If forgot to plug or
switch on the scanner b
Hi,
I read a bit the fujitsu backend source (sadly, i don't have such fuji
scanners). The sensor handling is exactly what i asked for :D !!
Each sensor is named "button-" and is not a number but
something like "send", "scan", etc. :) That is PER - FECT :D
I just suggest to expand this behaviour
Hi,
> the button should be called something as close as possible to the
> writing on the scanner, not the front-end authors list of words he
> understands.
I don't mean to impose naming, just propose convention. Is the goal of
SANE just to dump device design or to abstract device ? I guess the
la
Hi,
KScannerButtons work like this. See
http://jice.free.fr/KScannerButtons/ .
However, this is completely incompatible with end user (think grand-ma)
who just want the scanner to cancel once she pushed that damn cancel
button, and not one more popup asking what to do (while the scanning is
conti
Hi,
> unless you add 'backend' as an argument to the function.
Reread carefully, i talked about adding backend argument along UDI. ;)
> most backends could implement the function as returning a
> concatenation of 'libusb:', the vendor and device ids.
I guess you talk about bus number and device
Hi,
You're right, i though that SANE people were a bit aware of HAL since it
has already been discussed in this list years ago.
> sell us on the IDEA first, then lets look at the implementation.
Let me explain that for SANE people. Please remember i'm primarily GNOME
Scan developer and thus have
Hi,
> This is, or isn't, SANE 2 stuff. You're not going anywhere with that
> and SANE 1.
I don't understand your sentence. I just mean renaming option in
backend, change some option type. That is mostly a matter of
implementation.
If you don't want to extend SANE 1 standard (like e.g. 1.2), just
Hi,
> you may have a chain of backend names. the udi is only useful if each
> backend can use it to get enough info from hal to indentify the
> scanner. i dont know what hal can provide in that case.
Here is an example of HAL device properties (stripped), you will notify
the scanner namespace add
Hi,
> > Something bad is that i need Abel Deuring fdi generator in order to have
> > sane backend in the fdi.
>
> How do you handle scanners supported by several backends?
Currently, hal addon use the first backend available. Remember it is
rather a proof of concept. The code should check suppor
Hi,
I forgot to talk about sensor type.
Push button must be boolean representing the "pressed" state of the
button.
Wheel button should be either Word, fixed or string. Well known string
value should be good like "color-mode", "grey-mode" for hardware mode
selector.
Please comment.
Regards,
?t
Hi,
SANE allow hardware selected option. I call this "sensor" for short. It
can represent push button (like "scan", "cancel", "mail", etc.), wheel
button (ask Allan for details), paper sensor, cover sensor, etc. Some
device have blank button.
Unlike software selected option, frontend *must* under
Hi,
The fdi just need to tell "this is a scanner", at least. We may add
extra info like device type, backend, etc. See Abel Deuring fdi
generator.
> what does a UDI look like?
This is the one of a QScan scanner :
/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0
> > * HAL dev
Hi,
I worked on HAL-scanner, a project providing a HALd addon for monitoring
hardware selection option of SANE device just like scannerbuttond.
Features are :
* once instance per device (more robust)
* run only once a device is plugged (thanks HAL)
* provide a tiny DBus interfa
Hi,
In order to have hotplug, quicker probe, more information about device
and better integration with the desktop, i want to use HAL to detect
scanner.
Quick HAL intro. HAL means hardware abstraction layer. It's a piece of
code running on Linux and *BSD providing high level features over device
Hi,
Along GNOME 2.22 si GNOME Scan 0.6 released. This version includes a
full rewrite. The goal of GNOME Scan is to make scanning as easy as
printing for both users and developers in the GNOME desktop.
You can learn more about this release at :
http://blogs.gnome.org/gnome-scan/2008/03/11/gnome-s
Hi,
> They are allready of 'type' boolean:
VERY good ! I was talking about general buttons handling (plustek uses
integer).
> I may put a more accurate 'title' and 'desc' field (it was on my TODO
> list).
> For the 'name' field, I'll stick to "button%d" like it is currently done in
Hi,
That's very nice to have button handling in your backend. Please provide
semantic button naming like "paper-in", "trigger", "cancel" or default
to "auto" or something similar. Also, please use boolean rather than 0/1
int option for button, this is as well more semantic. Button naming can
be do
Hi,
That's the shame with english. When will SANE switch to Esperanto ;)
Regards,
?tienne.
Hi,
http://dictionary.cambridge.org/define.asp?key=85620&dict=CALD tells the
reverse :
> to change slightly, especially in order to make more correct,
> effective, or suitable:
One given example is even about computer science :
> The software is pretty much there - it just needs a little tweaki
Does a german and an itilian understand the same thing behind
"Tweaking" ? ;)
?tienne.
Hi,
Sorry for the multi post, i got sink under all those mail accounts. I'm
developing HAL scanner support and need the fdi file. This is why i ask
for it to be installed.
Distribution packages should be able to install without modifying the
source, (debian can, i guess Arch can't, don't know for
Hi,
In CVS, sane-desc tool generate tools/hal/libsane.fdi, however, it is
not installed. Could you please install it ? Attached a patch installing
fdi file if --enable-hal-fdi is passed to configure.
Regards,
?tienne.
--
E Ultre?a !
-- next part --
A non-text attachment w
Hi,
In CVS, sane-desc tool generate tools/hal/libsane.fdi, however, it is
not installed. Could you please install it ? Attached a patch installing
fdi file if --enable-hal-fdi is passed to configure.
Regards,
?tienne.
--
E Ultre?a !
-- next part --
A non-text attachment w
Hi,
In CVS, sane-desc tool generate tools/hal/libsane.fdi, however, it is
not installed. Could you please install it ? Attached a patch installing
fdi file if --enable-hal-fdi is passed to configure.
Regards,
?tienne.
--
E Ultre?a !
-- next part --
A non-text attachment w
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 XS
Hi,
> 1. There is a need for more well-known options controlling certain
> hardware (ie- adf)
> 2. There is a need to expose additional image types to specialized front ends.
> 3. The SANE2 draft is fairly large
> 4. The number of developers is limited
Let me add :
5. event (button, sensors)
Hi,
This would be very nice to have a release allowing major distros to ship
with updated SANE for next spring. Ubuntu ships CVS version of SANE
(2007-05-05). There is definitily a needs for a new release.
Regards,
?tienne
--
E Ultre?a !
Hi,
As a frontend developer, I'm very interested in such addition to test
backend !!
Regards,
?tienne.
--
E Ultre?a !
Hi,
I'm pretty much in the same case. I have two device without driver. I
sent one device to Gerard Jeager who nicely add support for this
device in plustek. I also own another device, but this time, i would
like to add sane support for this device (IRIS IBCR II), but i'm quite
lost in the process
Hi,
As a frontend developer, i would really enjoy that SANE 2 get
developped, especially for its larger amount of well-known options.
However, i'm not agree with the curent handling of scanner button (as
we discussed earlier).
Regards,
?tienne
--
verso l'Alto !
Hi,
I agree with the proposal. Even if i wonder who do SANE 2, and if this
change does not actually open the SANE 2 development ? do you intend
to create at least a SANE 2 branch in CVS or save SANE 1 in a CVS
branch ? (i don't know if CVS handle branch like SVN)
Would be nice also to harmonize s
Hi,
Currently, SANE propose three macro for scan mode values (Color, Gray
and Lineart) in order to keep backends consistent.
Writing a frontend, i would like to know wether the source is ADF or
not, this will allow frontend to scan until SANE_STATUS_NO_DOCS is
returned or just do one scan. Howeve
hi all,
In order to ease development of frontend, i produce a patch that
generate a pkg-config file for sane. Attached the patch to
configure.in and the sane.pc.in file to add at the root of the source
tree.
I don't know how to patch root Makefile.in in order to install sane.pc
in $(libdir)/pkgco
Hi,
> xsane sane-pnm and
> xsane sane-pnm:xsane-calibration.pnm and
> sane-test equivilants seems not to work eighter?
use xsane pnm or xsane test or configure /etc/sane.d to load test
backend (uncomment test in dll.conf)
?Tienne.
--
Verso l'Alto !
-- next part --
A
Hi,
> But back to the problem I have/had with Etienne's suggstion for the
> "relations" between page size and scan window coordinates: It does
> not make much sense to allow to set a scan window in overscan mode:
> The backend should calculate the scan window settings automatically
> from the page
Skipped content of type multipart/mixed-- 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 :
ht
Hi,
Download SANE CVS. See backend-writing.txt document. And start to hack.
?tienne.
--
Verso l'Alto !
-- 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
=?
hi all,
I'm working on Gnome Scan and intend to be very active in this realm in
the next year.
This may hurt some people here.
I want to bring scan support to hal. I intended to talk with sane people
in january. I want in Gnome to use sane for access, not probe/detection.
That's bad to probe ea
Hello,
As part a Google Summer of Code, i wrote another SANE frontend. The
design of the frontend looks similar to libkscan. The purpose of the
project is to provide libraries to build scan UI.
So i wrote libgnomescan which is the frontend to SANE ; libgnomescanui
that provide widget to scan. The
Hello,
In SANE 1 documentation. SANE_Parameters is documented in Operations
section. I suggest to document it in Data Types sections and to add an
entry in the Table of Contents for it.
?tienne.
--
Verso l'Alto !
> It is the n that I am confused about. Specifically, what does n = 0 mean?
0 is the index of the "option count" option.
--
Verso l'Alto !
Hello,
Using SANE 1, application can retreive informations only about detected
devices by sane_get_devices(). That would be nice if SANE allow to
retreive such data for any device name.
I suggest :
* make sane_get_devices() returns a list of device name (e.g. a
NULL terminated SANE_
Hello,
> SANE standard 1 does not specify how to handle scanner buttons,
> but it is clear, that an option, which deals with a button has to deliver
> a value (button pressed or not). Regarding that requirement, you have either
> to use SANE_TYPE_BOOL or SANE_TYPE_INT - I choose BOOL.
> SANE_TYPE_
Hello,
> scanimage -L reports:
> device `plustek:libusb:003:003' is a Canon N1220U USB flatbed scanner
User should have
bersace@celebrad:~$ scanimage -L
device `plustek:libusb:002:002' is a Canon CanoScan N1220U flatbed
scanner
Hello,
I own a flatbed scanner Canon CanoScan N1220U. The device name is
"plustek:libusb:002:002". I find some bug in that backend or at least in
that device support.
* The product name is "N1220U" instead of "CanoScan N1220U"
* The option group "buttons" has 5 readonly options "butto
75 matches
Mail list logo
