Le lundi 1 janvier 2007 07:50, JKD a ?crit : > El Sat, 30 de Dec de 2006, a las 05:27:43PM +0100, Jean-Christophe 'Jice' Cardot dijo: > > Hi > > > > I've developped a GUI + daemon (based on code by Rene Rebe - avision > > backend) for buttons support through SANE. > > Web site: http://cardot.net/KScannerButtons > > At the moment the daemon is a quick and dirty hack based on Rene's code, > > but at least working. The GUI is built using Kommander from kde-webdev; > > only the daemon is mandatory. > > > > It's using the SANE backend to talk to the scanner (and not adressing the > > scanner directly through libusb as scanbuttond does - see > > scanbuttond.sourceforge.net). > > > > I tested it only with the avision backend and a HP 5300 C scanner. > > > > I was wondering wether or not there is a convention for buttons among > > backends: in the avision backend, the option name is equal to > > "button-<button number>". > > > > Also, which backend support buttons? > > > > Could you please test my software with your scanner (if your backend > > support buttons) to help me build a list of supported devices? > > I've added support for buttons in hp3900 scanner in the same way avision > does (SVN server at sourceforge). So at least these scanners should work > with KScannerButtons: > > - hp scanjet 3800 (3 buttons) > - hp scanjet 3970 (4 buttons) [tested] > - hp scanjet 4070 (4 buttons) > - hp scanjet 4370 (4 buttons) [tested] > - umax astra 4900 (4 buttons) > - umax astra 4950 (4 buttons) > > Changes in hp3900 will be official in the next version. I included a > module in scanbuttond project to manage these scanners too.
Hi Jonathan This will be reflected on the web site soon. I hope some more backend developpers will answer my email so that we can expand that list. > I've translated your frontend to spanish. If you want to add that > language to your project you can download ".po" file at this location: Thanks! Will be in next version :) > http://jkdsoftware.dyndns.org/files/others/kscannerbuttons-es.tar.gz > > > PS: I was also wondering why the button support as found in scanbuttond > > is not (or is it?) in the backends. For me SANE is the preferred way to > > access scanners, and any button daemon should make use of SANE > > backends... > > I agree with you. I suppose this stuff is going to be solved when SANE2 > arrives but I think that will take a long time. IMHO sanebuttonsd (and > your frontend) is better solution than scanbuttond. yep. But do you know if there is a specification on how should the SANE backends handle the buttons? > Jonathan Bravo Lopez bye -- Jean-Christophe "Jic?" Cardot - http://lea-linux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070101/8ebdfb06/attachment.pgp From adeur...@gmx.net Mon Jan 1 23:16:53 2007 From: adeur...@gmx.net (abel deuring) Date: Mon Jan 1 23:17:39 2007 Subject: [sane-devel] Sane and HAL Message-ID: <45998855.1060...@gmx.net> Hi all, a happy new year to you all! I tried to become a bit more familiar with HAL (http://freedesktop.org/wiki/Software_2fhal) and I think that this is a project that Sane should support. And no, it will not create any compatibility problems, as feared by some colleagues during the short discussion in December last year. As I understand it, HAL is mainly a daemon that manages a list/database of hardware resources, monitors hotplugging, and provides mechanisms for device configuration and other things like automatic launch of an application, if a certain device is detected/plugged in. The minimum we can (and IMO should) do is to provide an XML file (or ".fdi file" in HAL terminology) that describes the scanners supported by Sane, and optionally the unsupported scanners. The fdi file contains information like scanner vendor/model name, interface type (USB/SCSI/parport...), Sane backend(s) for the device, and "unique device information", like USB vendor/product ID or the SCSI vendor/product strings. This file can be easily generated from our *.desc files. Right now, the latter contain already all required information for USB scanners; for the SCSI interface, we would need to add the keyword :scsiid; an entry for this keyword should look like :scsiid "SHARP" "JX250 SCSI" A similar keyword would be needed for the Firewire interface, but I have no idea, how Firewire devices can be identified; if some parport scanners supported by a Sane backend can also tell something about themselves in some standardized way, this should be included too in the *.desc files. I wrote a little Python script that transforms the data from the *.desc files into an .fdi file; if this file if placed at /usr/share/hal/fdi/... , the program lshal for example lists a number of details about the available scanners (e.g., vendor/model name and useable backend(s)); similary, "interested" applications can use this data to find a scanner and a suitable Sane backend and launch for example xsane or access the scanner directly. (If anybody is interested, how practical work with HAL looks like, the source code of lshal is a good start. It is not too long and easy to read.) This leads to a second option: HAL provides so-called UDIs (means "uniform device identifiers", I believe), strings of the form "/org/freedesktop/Hal/devices/usb_device_4c5_10e0_100_noserial_if0". If such a udi represents a scanner, it can be used to look up a backend that supports the device and to find the SG device file or the USB bus and device numbers that can be used to build the Sane specific strings to identify and open a device like "sharp:/dev/sg2" or "plustek:libusb:002:004". We can leave the work to build the latter, Sane-specific, identifiers to applications that are HAL-aware, or we can add support for device identifiers like "udi:sharp:/org/freedesktop/..." to sane-backends. A possible place would be the function sane_open in dll.c, which already replaces device identifiers defined in dll.aliases by "regular" IDs, so we would add just another "substitution mechanism". Another option would be another meta-backend named "udi", but I believe that this would be overkill. Open questions: - do all backends for USB scanners use libusb, or do some backends use other ways to access the device; if yes, what kind of "device identifiers" are used? - Handling of parport scanners. This can be a bit more complicated, if they cannot be automatically detected. On the other hand, the HAL people already discussed the question of devices that need some user help for identification and configuration: http://lists.freedesktop.org/archives/hal/2006-September/006086.html I can't claim that I understand all ideas, but a possible advantage I see is to get rid of the "permission problem" for these scanners. If I understand and remember some discussions on this list correctly, users quite often need to access a parport scanner with root rights. HAL might be a way to integrate the permission handling for parport scanners into the general "permission management" of a Linux distribution. Abel PS: Seems that we all forgot to celebrate "10 years Sane" last year: According to ChangeLog-1.0.0, version 0.1 was released on 1 Dec 1996.
