date:20080317

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
plugged to the system. HAL provide a system wide API for listing
devices, receiving signals (new device, device property changed, unplug,
etc.). For each device, HAL provide a lots of informations : vendor,
product, capabilities (think all-in-one devices), etc.




Discussion for HAL and SANE integration from 2006 leds to the key point
of linking SANE device name and HAL UDI. SANE device name and HAL UDI
are defined at runtime and thus can't be stored in the FDI.

A HAL aware frontend use HAL to detect scanners and receive plug and
unplug event. Once it has a scanner UDI, it open it with SANE. It then
need the SANE device name. Where to find the SANE device name ? I found
two possible solutions.

  * HAL device has a scanner.sane.name string property allowing the
frontend to simply read that property and pass it to
sane_open().
  * SANE handle device name like "hal:".
  * SANE provide an extra function to translation hal udi to SANE
device name. e.g. char* sane_hal_udi_to_device_name(halctx, udi)


For the first solution, SANE must document device naming in order to
allow external implementation of device naming computation.

For the latters, this will not break the API since neither the behaviour
nor the function prototype will change. I personnally vote for the last
option.
?
So, how can SANE help fixing this ?

Regards,
?tienne

[sane-devel] HAL and scanners.

On Mon, Mar 17, 2008 at 9:58 AM, ?tienne Bersac  wrote:
> 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
>  plugged to the system. HAL provide a system wide API for listing
>  devices, receiving signals (new device, device property changed, unplug,
>  etc.). For each device, HAL provide a lots of informations : vendor,
>  product, capabilities (think all-in-one devices), etc.

HAL will determine all of that info without help from any running SANE
code, correct?
Is this where the FDI files are used?

>  Discussion for HAL and SANE integration from 2006 leds to the key point
>  of linking SANE device name and HAL UDI. SANE device name and HAL UDI
>  are defined at runtime and thus can't be stored in the FDI.

what does a UDI look like?

>  A HAL aware frontend use HAL to detect scanners and receive plug and
>  unplug event. Once it has a scanner UDI, it open it with SANE. It then
>  need the SANE device name. Where to find the SANE device name ? I found
>  two possible solutions.
>
>   * HAL device has a scanner.sane.name string property allowing the
> frontend to simply read that property and pass it to
> sane_open().

each backend does its own thing regarding device naming, so this would
require hal to call out to the backend to get the name.

>   * SANE handle device name like "hal:".

then sane would have to query hal to get some device name, then ask
every backend on the system for a list of active scanners, and then
see if one of them matched up with the device name from hal.

>   * SANE provide an extra function to translation hal udi to SANE
> device name. e.g. char* sane_hal_udi_to_device_name(halctx, udi)

this would be the same code as the previous option basically.

>  For the first solution, SANE must document device naming in order to
>  allow external implementation of device naming computation.

cannot be done. some backends are able to use the device serial
number, others use the device name, still others use an ip address,
and in the future, i would not be surprised to see
'sane1to2:oldbackend:device' or 'decompress:newbackend:device'

>  For the latters, this will not break the API since neither the behaviour
>  nor the function prototype will change. I personnally vote for the last
>  option.
>  ?
>  So, how can SANE help fixing this ?
>

how is hal going to deal with network connected scanners? they wont
show up in hal, but they show up just fine if you ask the dll backend
for a device list...

allan

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

[sane-devel] SANE backend epson2 and Epson Perfection V700 Photo

2008-03-17 Thread Claus



Adolf Winterer skrev:
> Hello Claus,
> 
> Am Sonntag, 16. M?rz 2008 00:00 schrieb Claus Boje:
>> L?rdag den 15. Marts 2008 skrev Adolf Winterer:
>> > Thank you for your answer, Alessandro.
>> >
>> > Am Freitag, 14. M?rz 2008 15:17 schrieb Alessandro Zummo:
>> > > On Fri, 14 Mar 2008 08:50:27 +0100
>> > >
>> > > Adolf Winterer  wrote:
>> > > > Can anyone on the list please help me with the following questions?
>> > > >
>> > > > 1. What is missing from the epson2 backend to reach the "complete"
>> > > > status for the Epson V700 Photo?
>> > >
>> > >  maybe some particular features of the scanner are missing. I myself
>> > >  don't own one, but given that is has been listed as good on epson
>> > > backend it should work well on epson2 too.
>> >
>> > I've not yet made up my mind. Maybe I just take the risk and buy the
>> > device.
>>
>> I took the risk with the epson 4990
> 
> When did this happen?

~2 years a ago

>> and ended up with the job to hack the 
>> backend, mostly because the firmware in the scanner made som funny things
>> and have some funny features too. I hacked the epson driver, but this
>> driver did not do the extended commands, but before I got the epson backed
>> update to the extended commands the epson2 driver from Alessandro came up,
> 
> Is this code included in the 1.0.19 backend release?
yes, but in Debian (testing/unstable) the epson2 driver i comment out i
   /etc/sane.d/dll.conf,
   very easy to enable again, maybe it is the same with other dis.

>> and it did the job for me, except for the funny buggy software of the epson
>> 4990 scanner, 
> 
> Wrong or old firmware file?

I don't know but I think wrong.
The problems with the epson 4990 is

-It do not report all resolutions back (only up to 3200 dpi)
-It have some special (and (one) undocumented) commands for the tpu if
you want to use the hole area.
-It sometimes reports error under "lamp warm up" (the drive fix that)

If you take the source (epson2.c) from sane and search for 4990 you can
se what special for 4990 it's not much.

>> which I have hacked today (it is in the driver now). Sow if 
>> your scanner not have funny firmware it proberly runs on epson2 
> 
> The 4990 model is listed with "complete" support both in the epson backend 
> and 
> the epson2 backend. This is somewhat strange as with a support status of 
> "complete" this should never happen.   :-(

The "complete" in the epson driver is more or less my fault, because I
reported it complete before I found the problems with the tpu.
The only "missing" in epson driver I think is that you can't use the
hole tpu area, but there can be more, because I started to hack the
epson2 driver , and then stopped testing the epson driver

>> (if it use 
>> the ESC/I, but I think that both v700 and v750 use the ESC/I commands, but
>> don't blame me if I'm not right) commands, but . We can too ask epson for
>> the programmers manual, I did that with the 4990 and got them without
>> problems.
> 
> How did you get these programmers manuals? Whenever I read something about 
> scanner support I see "no documentation available" and "reverse engineering 
> with USB traffic sniffing".

I got them from here
http://www.epsondevelopers.com/home/guides_redirect, you need to ask for
them, but I got them without problems. You can get the epson 4990 and
4870 from me if you are interested


>> I don't know how much you can do, can you compile a packet your self ? - do
>> you programe/understand some c ?
> 
> I can read C programs to get the most basic idea what it should do, but this 
> is not nearly enough for driver development.   :-(
> 
> You offered a radically different view onto the support situation of the 
> named 
> epson devices (4990 / V700). So I'm again a bit more uncertain about 
> purchasing one of these. But at the moment I'm lacking alternatives!

I chose the epson 4990 because I could get the technical information.

The biggest problem to help you is that I don't have a v700/v750 scanner.

Best

CLaus

[sane-devel] Ricoh IS420

I have just gotten my hands on a Ricoh IS420, with Bell + Howell
badges on it. Both the ibm and hs2p backends attempt to support it,
the former seems to produce only white scans, the latter locks up
after sending a mode_select to change the prefeed.

jeremy (or anyone else)- are you interested in getting this to work? i
can provide debugging info, and even shell access.

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

[sane-devel] HAL scanner addon

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 interface org.freedesktop.Hal.Device.Scanner
providing a "Event"(option_name, value) signal and
ReleaseDevice(), ClaimDevice() method (see documentation)
  * translate HAL UDI to SANE device name in scanner.sane.name
property (see HAL-SANE integration discussion)

Something bad is that i need Abel Deuring fdi generator in order to have
sane backend in the fdi.

I submitted the project to HAL last week and got valuable feedback. My
goal is to avoid having a seperate project and merge the code in either
SANE or HAL. All the udi-sane name code must be in SANE and the addon
must be in HAL.

I publish the tarball at
http://bersace03.free.fr/pub/tmp/hal-scanner-0.1.tar.gz . Doc included.

Please review and comments :)

Regards,
?tienne.

[sane-devel] HAL and scanners.

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 device has a scanner.sane.name string property
> 
> each backend does its own thing regarding device naming, so this would
> require hal to call out to the backend to get the name.

So this need to provide a function sane_hal_get_device_name(backend,
halctx, udi) ?


> >   * SANE handle device name like "hal:".
> 
> then sane would have to query hal to get some device name, then ask
> every backend on the system for a list of active scanners, and then
> see if one of them matched up with the device name from hal.

I guess this is suboptimal. Maybe having "hal::" should
help.

In the end, it seems that having backend and udi info is the good couple
of info needed in order to compute properly the device id.


So, we have two possible solutions :

 1. implement sane_hal_device_get_name(haltcx, udi, backend_name)
 2. handle "hal::" which internally call the above
function.

Which do we choose ?

> how is hal going to deal with network connected scanners?

Network discovery is another problem solved by e.g. avahi
(mdns/zeroconf).

Regards,
?tienne.

[sane-devel] Well known sensor

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* understand the meaning
of a sensor. Software selection option can be dumped to user, title and
desc should be enough for the user. But sensor event must be
interpretted by the software.

Currently, backends often use "button %d" or "button-%d" which actually
does not help frontend to handle events.

The backend is aware of the meaning of sensor. It can know what value
mean what action according to either datasheet or device it self.

frontend needs an untranslated and extensible way to know what to do
with a value from a backend without user interaction.

I propose to extend the standard to provide well known hard selected
options. Here are some exemple :

  * "auto" (for e.g. blank button) : If the device is ready, this
mean trigger scan, else it mean cancel, etc.
  * "scan" trigger scan start
  * "cancel" trigger scan cancelation
  * "mail" send output by mail (e.g. as attached image)
  * "print" send output to printer

We might append or prepend "sensor" before the actual name of the option
in order to avoid collision.

Can we please provide such well known sensor spec and implement it in
backends ?

Regards,
?tienne.

[sane-devel] Well known sensor

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,
?tienne.
-- 
E Ultre?a !

[sane-devel] HAL and scanners.

>  > >   * HAL device has a scanner.sane.name string property
>  >
>
> > each backend does its own thing regarding device naming, so this would
>  > require hal to call out to the backend to get the name.
>
>  So this need to provide a function sane_hal_get_device_name(backend,
>  halctx, udi) ?

>  > >   * SANE handle device name like "hal:".
>  >
>  > then sane would have to query hal to get some device name, then ask
>  > every backend on the system for a list of active scanners, and then
>  > see if one of them matched up with the device name from hal.
>
>  I guess this is suboptimal. Maybe having "hal::" should
>  help.
>
>  In the end, it seems that having backend and udi info is the good couple
>  of info needed in order to compute properly the device id.

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.

>  So, we have two possible solutions :
>
>  1. implement sane_hal_device_get_name(haltcx, udi, backend_name)
>  2. handle "hal::" which internally call the above
> function.
>
>  Which do we choose ?
>
>  > how is hal going to deal with network connected scanners?
>
>  Network discovery is another problem solved by e.g. avahi
>  (mdns/zeroconf).
>

there are scanners (and saned itself) which do not support
autodiscovery protocols. there are scanners which sane supports that
are unknown in the desc files, so would not be in the fdi files
either. both of these would not show up for your program, but work
just fine for users of scanimage or Xsane. now, we dont have to solve
all the problems at once, but i dont think i see what problem hal
integration is trying to solve. can you help me understand?

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

[sane-devel] HAL scanner addon

?tienne Bersac  wrote:

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?

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Well known sensor

?tienne Bersac  wrote:

Hi,

> I propose to extend the standard to provide well known hard selected
> options. Here are some exemple :

This is, or isn't, SANE 2 stuff. You're not going anywhere with that
and SANE 1.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] HAL scanner addon

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 support_status to
select the best or even ask the user which backend to use. This is done
for some other device kind like camera and is one of the goal of HAL.

Regards,
?tienne.

[sane-devel] HAL scanner addon

?tienne Bersac  wrote:

Hi,

> SANE or HAL. All the udi-sane name code must be in SANE and the addon
> must be in HAL.

How does this new piece of SANE code integrate into the SANE
architecture?

I'm sorry, I don't see where this code lies.

I hope you do know that every SANE backend is 100% interchangeable
with every other SANE backend, and that what is called "libsane.so" is
nothing else than the DLL backend.

As such, there's no central SANE library where to put this code. It
means it has to be duplicated into each backend, which sucks about as
much it can.

I'd like more details on what you're trying to do, how you plan to do
it, etc. Your mails look like they've been written in a hurry, and
quality suffers accordingly. I also have the feeling that you're
trying to force that down our throats, which is a little bit
unpleasant.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] HAL scanner addon

On Mon, Mar 17, 2008 at 2:12 PM, Julien BLACHE  wrote:
> ?tienne Bersac  wrote:
>
>  Hi,
>
>
> > SANE or HAL. All the udi-sane name code must be in SANE and the addon
>  > must be in HAL.
>
>  How does this new piece of SANE code integrate into the SANE
>  architecture?
>
>  I'm sorry, I don't see where this code lies.
>
>  I hope you do know that every SANE backend is 100% interchangeable
>  with every other SANE backend, and that what is called "libsane.so" is
>  nothing else than the DLL backend.
>
>  As such, there's no central SANE library where to put this code. It
>  means it has to be duplicated into each backend, which sucks about as
>  much it can.
>
>  I'd like more details on what you're trying to do, how you plan to do
>  it, etc. Your mails look like they've been written in a hurry, and
>  quality suffers accordingly. I also have the feeling that you're
>  trying to force that down our throats, which is a little bit
>  unpleasant.
>

oh- i dont think he is trying to force anything, but this much like
the LSB people. they are so used to thinking about their application,
that they forget to do a sales pitch with people outside their group.
i think we SANE devels suffer from the same problem.

sell us on the IDEA first, then lets look at the implementation.

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

[sane-devel] HAL and scanners.

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 added by Abel Deuring fdi and the
scanner.sane.name property added by hald-addon-scanner.

bersace at thilivren:~$ lshal --show 
/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0
udi = '/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0'
  info.addons = {'hald-addon-scanner'} (string list)
  info.bus = 'usb'  (string)
  info.capabilities = {'scanner', 'scanner', 'access_control'} (string list)
  info.linux.driver = 'usbfs'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial'  
(string)
  info.subsystem = 'usb'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0'  
(string)
  scanner.access_method = 'proprietary'  (string)
  scanner.api = {'sane'} (string list)
  scanner.is_supported = true  (bool)
  scanner.sane.backend = {'plustek', 'plustek'} (string list)
  scanner.sane.name = 'plustek:libusb:001:005'  (string)
  scanner.sane.supportstatus = {'complete'} (string list)
  usb.bus_number = 1  (0x1)  (int)
  usb.can_wake_up = true  (bool)
  usb.device_class = 0  (0x0)  (int)
  usb.device_protocol = 0  (0x0)  (int)
  usb.device_revision_bcd = 256  (0x100)  (int)
  usb.device_subclass = 0  (0x0)  (int)
  usb.interface.class = 255  (0xff)  (int)
  usb.is_self_powered = false  (bool)
  usb.linux.device_number = 5  (0x5)  (int)
  usb.max_power = 0  (0x0)  (int)
  usb.num_configurations = 1  (0x1)  (int)
  usb.num_ports = 0  (0x0)  (int)
  usb.product = 'USB Vendor Specific Interface'  (string)
  usb.product_id = 4096  (0x1000)  (int)
  usb.speed = 12.0 (12) (double)
  usb.speed_bcd = 4608  (0x1200)  (int)
  usb.vendor = 'Portable Peripheral Co., Ltd'  (string)
  usb.vendor_id = 2643  (0xa53)  (int)
  usb.version = 1.0 (1) (double)
  usb.version_bcd = 256  (0x100)  (int)

Backend can access almost all those info, especially usb.bus_number and
usb.linux.device_number.

> now, we dont have to solve
> all the problems at once, but i dont think i see what problem hal
> integration is trying to solve. can you help me understand?

HAL easy hotplug while running sane_get_devices() several times is
suboptimal. Also, UDI are universal accross the desktop (not only Gnome
or KDE) and allow to easily pass a device as argument (think
gnome-volume-manager handle scanner button and launch gnome-scan passing
the emitting device for preselection in the device selector), etc. There
is much much other possibilities given with HAL.

Also, frontend can mix sane_get_device for probe and HAL for hotplug,
etc.

See also hald-addon-scanner which is an elegent solution for propagating
device event (paper-in, button pushed, etc.) since it is launched only
if scanner is plugged, has no redundant code for probing, is cross
desktop (not GNOME or KDE specific), etc.

Anyway, having HAL support does not collide with existing behaviour.

Regards,
?tienne.

[sane-devel] Well known sensor

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
provide a RFC for backend developer in order to have backend consistent
and sensor usable by frontend, without end user interaction to assign
sensor to action.

Currently, SANE backend sensor implementation mean : "Something  happen,
guess what". E.g. plustek backend provide "button 0" to "button 4", both
integer with value 0. Once a button is pushed, value is 1. How can a
frontend know what does mean "button 0"=1 ? Can guess "button 0"
pressed. But what next ??

We definitely need semantic in sensors.

Regards,
?tienne.

[sane-devel] HAL and scanners.

On Mon, Mar 17, 2008 at 2:36 PM, ?tienne Bersac  wrote:
> 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 added by Abel Deuring fdi and the
>  scanner.sane.name property added by hald-addon-scanner.
>
>  bersace at thilivren:~$ lshal --show 
> /org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0
>  udi = '/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0'
>   info.addons = {'hald-addon-scanner'} (string list)
>   info.bus = 'usb'  (string)
>   info.capabilities = {'scanner', 'scanner', 'access_control'} (string list)
>   info.linux.driver = 'usbfs'  (string)
>   info.parent = '/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial'  
> (string)
>   info.subsystem = 'usb'  (string)
>   info.udi = '/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0'  
> (string)
>   scanner.access_method = 'proprietary'  (string)
>   scanner.api = {'sane'} (string list)
>   scanner.is_supported = true  (bool)
>   scanner.sane.backend = {'plustek', 'plustek'} (string list)
>   scanner.sane.name = 'plustek:libusb:001:005'  (string)
>   scanner.sane.supportstatus = {'complete'} (string list)
>   usb.bus_number = 1  (0x1)  (int)
>   usb.can_wake_up = true  (bool)
>   usb.device_class = 0  (0x0)  (int)
>   usb.device_protocol = 0  (0x0)  (int)
>   usb.device_revision_bcd = 256  (0x100)  (int)
>   usb.device_subclass = 0  (0x0)  (int)
>   usb.interface.class = 255  (0xff)  (int)
>   usb.is_self_powered = false  (bool)
>   usb.linux.device_number = 5  (0x5)  (int)
>   usb.max_power = 0  (0x0)  (int)
>   usb.num_configurations = 1  (0x1)  (int)
>   usb.num_ports = 0  (0x0)  (int)
>   usb.product = 'USB Vendor Specific Interface'  (string)
>   usb.product_id = 4096  (0x1000)  (int)
>   usb.speed = 12.0 (12) (double)
>   usb.speed_bcd = 4608  (0x1200)  (int)
>   usb.vendor = 'Portable Peripheral Co., Ltd'  (string)
>   usb.vendor_id = 2643  (0xa53)  (int)
>   usb.version = 1.0 (1) (double)
>   usb.version_bcd = 256  (0x100)  (int)
>
>  Backend can access almost all those info, especially usb.bus_number and
>  usb.linux.device_number.
>

in order for this to work, you would have to link to every backend in
the system, and call this function on the right lib, unless you add
'backend' as an argument to the function. most backends could
implement the function as returning a concatenation of 'libusb:', the
vendor and device ids. the backends that return something else would
actually have to talk to the scanner and get that info.

what would scsi look like? you would have to be able to get the device
file name from hal...

>  > now, we dont have to solve
>  > all the problems at once, but i dont think i see what problem hal
>  > integration is trying to solve. can you help me understand?
>
>  HAL easy hotplug while running sane_get_devices() several times is
>  suboptimal. Also, UDI are universal accross the desktop (not only Gnome
>  or KDE) and allow to easily pass a device as argument (think
>  gnome-volume-manager handle scanner button and launch gnome-scan passing
>  the emitting device for preselection in the device selector), etc. There
>  is much much other possibilities given with HAL.

i am not familiar with gnome-volume-manager, what does it have to do
with button presses? for the button press code to be done properly,
the backend has to be running and talking to the scanner, since only
the backend knows how to interpret the buttons. and, since only the
backend knows what name to use, it sounds like you would be better off
firing up the backend whenever hal finds it, and leaving it running?

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

[sane-devel] Well known sensor

?tienne Bersac  wrote:

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.

And breaking stuff while at it.

> Currently, SANE backend sensor implementation mean : "Something  happen,
> guess what". E.g. plustek backend provide "button 0" to "button 4", both
> integer with value 0. Once a button is pushed, value is 1. How can a
> frontend know what does mean "button 0"=1 ? Can guess "button 0"
> pressed. But what next ??

The backend doesn't know, either. Currently the buttons are used
mostly by custom frontends which do know what's hiding behind the
buttons.

There is no standard in SANE, which is a problem, but even worse
there's nothing standard accross all the hardware.

It's not a trivial problem to fix, as past discussions have shown.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Well known sensor

On Mon, Mar 17, 2008 at 3:17 PM, Julien BLACHE  wrote:
> ?tienne Bersac  wrote:
>
>
> 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.
>
>  And breaking stuff while at it.
>
>
>  > Currently, SANE backend sensor implementation mean : "Something  happen,
>  > guess what". E.g. plustek backend provide "button 0" to "button 4", both
>  > integer with value 0. Once a button is pushed, value is 1. How can a
>  > frontend know what does mean "button 0"=1 ? Can guess "button 0"
>  > pressed. But what next ??
>
>  The backend doesn't know, either. Currently the buttons are used
>  mostly by custom frontends which do know what's hiding behind the
>  buttons.
>
>  There is no standard in SANE, which is a problem, but even worse
>  there's nothing standard accross all the hardware.
>
>  It's not a trivial problem to fix, as past discussions have shown.

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. there is no 'email' button on a fujitsu, there is a 'Send
to' button. This is of course complicated by the fact that some
scanners have localized versions and some only have pictures.

then, you dont need to interpret the values, you only need to ask the
user- what do you want to do when 'Send to button' is pressed?

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

[sane-devel] Well known sensor

2008-03-17 Thread Alessandro Zummo

On Mon, 17 Mar 2008 20:17:50 +0100
Julien BLACHE  wrote:

> The backend doesn't know, either. Currently the buttons are used
> mostly by custom frontends which do know what's hiding behind the
> buttons.
> 
> There is no standard in SANE, which is a problem, but even worse
> there's nothing standard accross all the hardware.
> 
> It's not a trivial problem to fix, as past discussions have shown.

 I believe in windows it works this way:

 - every driver/backend exports the supported buttons
 - the OS asks the user to bind the button to a specific function

 this way it doesn't matter how the button is called.
 I've seen an epson with "Scan, Mail, PDF" and a Fujitsu
 with "Button 0, Button 1, ..." /

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] HAL scanner addon

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 the frontend point of view. Don't hesitate
to read a bit of HAL specs at
http://people.freedesktop.org/~david/hal-spec/hal-spec.html and Havoc
Pennington preliminary talk http://www.ometer.com/hardware.html

HAL means Hardware Abstraction Layer. It is a piece of code that
provides a view of hardware attached to a system. HAL is dynamic and
allow system and desktop-level software to interact with hardware along
their "life" in the system : plug, events, use, unplug.

Each piece of hardware has a Device object with a unique identifier and
which expose a set of key/value set known as device properties. The
devices properties comes from a lot of sources varying from the device
it self, the system, the driver, some device information file, etc.

HAL use DBus as IPC framework for exposing those features accros the
system.

The most important goal of HAL is to provide plug-and-play facilities
for UNIX (currently linux, freebsd and solaris) on desktop system.

HAL does not handle access to hardware, it is up to third party library
like e.g. SANE, CUPS, etc. See
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#ov_halarch
for more details on HAL architecture.

HAL is shiped by a lot of distribution since 2004.

HALd addons are daemon attached to a device, launched on plug and killed
on unplug. They extends feature for device. A good example is
hald-addon-storage which allow to unmount device through DBus in a
system-independent and desktop-independant manner.

hal-scanner provide a addon (named hald-addon-scanner) adding scanner
event propagation using SANE to poll registers and DBus to propagate the
signal thru the system (See the pdf in the tarball).

hald-addon-scanner also provide "scanner.sane.name" device name allowing
frontend to directly open scanner on plug. (See HAL and scanners
discussion).

I primarily announced HAL scanner 0.1 for comments. hal-scanner 0.1 is
rather a proof of concept and i wish it will not be a standalone project
for long. All the fdi generation part must be merged in SANE (either by
extending sane-desc or by including sane-fdi) and hald-addon-scanner
must be merged in HAL itself.

See also scanbuttonsd
https://alioth.debian.org/plugins/scmcvs/cvsweb.php/experimental/button-daemon/?cvsroot=sane
and KScannerButtons http://jice.free.fr/KScannerButtons/ as existing solution
for the same problem.

Please comment.

Regards,
?tienne.

[sane-devel] HAL and scanners.

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

>  the backends that return something else would
> actually have to talk to the scanner and get that info.
> 
> what would scsi look like? you would have to be able to get the device
> file name from hal...

I do not have SCSI on my system, but the info.bus is "scsi". See hal
specification :
http://people.freedesktop.org/~david/hal-spec/hal-spec.html and search
scsi ;)


> i am not familiar with gnome-volume-manager

gnome-volume-manager handler high level hardware event like dvd
inserted, music player plugged, camera plugged, etc. and execute proper
action on it (import photos, launch dvd player, etc.) according to user
configuration.

> it sounds like you would be better off
> firing up the backend whenever hal finds it, and leaving it running?

This is what hald-addon-scanner does. See distinct discussion HAL
scanner addon.

Regards,
?tienne.

[sane-devel] Well known sensor

"m. allan noah"  wrote:

> understands. there is no 'email' button on a fujitsu, there is a 'Send
> to' button. This is of course complicated by the fact that some
> scanners have localized versions and some only have pictures.

UI nightmare :-)

> then, you dont need to interpret the values, you only need to ask the
> user- what do you want to do when 'Send to button' is pressed?

Exactly.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Well known sensor

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
continuing) ! ;)

Regards,
?tienne.

[sane-devel] Well known sensor

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
latter since frontend must not have device specific code, see well-known
option. This is why "resolution" option is not named "dpi" on other
backend.

> there is no 'email' button on a fujitsu, there is a 'Send
> to' button.

Just set title to "Send to" for UI and let's use a generic untranslated
name for frontend. If the consensus is to use "sendto" rather than
"email", then go for it. It just needs to be meaningfull and consistent
accross backend.? I don't mean to forbid other sensors.

> then, you dont need to interpret the values, you only need to ask the
> user- what do you want to do when 'Send to button' is pressed?

Users want computer to *just work*, not to popup dialog everytime
someting happen.


SANE should not decide whether frontend have to interpret or not
sensors.

KScannerButton won't interpret and allow fine tweaking of action (even
allowing to edit the shell script executed ; but GNOME will interpret as
much as possible before asking user what to do. That's a matter of
userbase target.

Please consider i propose well known sensors not to have a nice to see
code, but because users want it. GNOME does not target the same userbase
as KDE or XSane. We (at GNOME) target end user that really don't want to
spend their time configuring their computer, and they are numerous.


So please consider providing well known semantic for sensor as well.
Just like we already do for well known option.


Regards,
?tienne.

[sane-devel] Well known sensor

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 for each backend :

  * Prefix sensor with "button-"
  * Use semantic name
  * "send" for button "send to", "mail", "mail to" or with a
mail icon on the device
  * "scan" for button triggering the scan
  * "duplex" for duplex switch
  * "powersave" once the scanner enter powersave state
  * "adfopen" once the ADF is opened
  * "paperin" once paper is inserted either in sheetfed
scanner or ADF.
  * "auto" for blank button that mean either "scan" or
"cancel" depending on the current stage.
  * other may come, of course

greping the source tree, backends plusteck, hp3900 and pixma use
"button-%d" or similar. Would be nice to have semantic button instead.

Can we publish a document describing such well known sensors ? This is a
tiny incremental evolution of SANE that can make a really good
difference for end user.

Regards,
?tienne.

[sane-devel] Proposed patch for the snapscan semaphore issue

2008-03-17 Thread Oliver Schwartz

Hi,

> The patch only works for libusb devices. Applying it as is means the
> backend will now fail hard if you're using a non-pthread build of SANE
> with a non-libusb access method.
>
> I'm not sure such a combination exists. If I'm not mistaken, OS/2 uses
> pthread by default, so does OS X and all other OSes use libusb.

If I read your patch correctly it would also break support for the  
old USB access by device /dev/usb/scanner0 on Linux 2.4.x (or was it  
2.2.x?) without libusb. Maybe it's a good idea to fall back to the  
old ftok() method if the device name doesn't start with "libusb:".

Apart from that the patch looks ok to me.

Regards,

Oliver

[sane-devel] Well known sensor

On 3/17/08, ?tienne Bersac  wrote:
> 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 am glad you like it :)

>  I just suggest to expand this behaviour for each backend :
>
>   * Prefix sensor with "button-"
>   * Use semantic name
>   * "send" for button "send to", "mail", "mail to" or with a
> mail icon on the device
>   * "scan" for button triggering the scan
>   * "duplex" for duplex switch
>   * "powersave" once the scanner enter powersave state
>   * "adfopen" once the ADF is opened
>   * "paperin" once paper is inserted either in sheetfed
> scanner or ADF.
>   * "auto" for blank button that mean either "scan" or
> "cancel" depending on the current stage.
>   * other may come, of course
>
>  greping the source tree, backends plusteck, hp3900 and pixma use
>  "button-%d" or similar. Would be nice to have semantic button instead.
>
>  Can we publish a document describing such well known sensors ? This is a
>  tiny incremental evolution of SANE that can make a really good
>  difference for end user.

the fujitsu machines also have a 'function' digit, which ranges from
0-9. 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.

the duplex switch is the one i consider most problematic, and i have
considered hiding it, since the backend has a 'source' option to
control that. it is only on older scanners anyway.

i dont have a problem with making button names into well-known
options, as long as we agree that there are scanners with unlabelled
buttons, making button-%d your best option.

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

[sane-devel] HAL and scanners.