[sane-devel] SANE 1.1.0 Release discussion
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.
[sane-devel] SANE 1.1.0 Release discussion
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 least in order to update UI. I think that simply adding cap HARD_SELECT should be enough to tell the frontend : poll this if you want to know when the user change the value of this option from the device. Regards, ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
Hi, From my point of view, everything is fine. Regards, ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
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, ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
Hi, Agree, HW_BUTTON is redundant with HARD_SELECT. Sorry for not notifying it earlier. ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
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 ?) * mailto * print I'm pretty sure you have other button from fujitsu. Also, i have no idea about numbered button (like in plustek) or about wheel and such high level device button. Regards, ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
Hi, So you mean an hardware selected option that can be read after the scan ? Sounds good ! Regards, ?tienne.
[sane-devel] SANE 1.1.0 Release discussion
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.
[sane-devel] Front end that respects SANE_INFO_RELOAD_PARAMS and SANE_INFO_INEXACT?
Hi, GNOME Scan do it. ?tienne.
[sane-devel] a wish list for SANE improvements
Hi, - more well known-options I'd include more well-knonw sensor option like in fujitsu backend. +1 for the entire wishlist. ?tienne.
[sane-devel] SANE2 standard completion
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 my mouth. ?tienne.
[sane-devel] SANE2 standard completion
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 along) in order to allow to bypass the service. I'm quite sick of the desktop people trying to overtake everything. I guess you are labeling me as one of those desktop people. Desktop users and developers, distributors and backend developers are sick of conservative people always considering other people as invader. Everything is not a desktop, the desktop is only one use case. ? Don't reduce desktop as window manager + xsane. And we DO care about it, thanks very much. Sorry, what does mean DO ? Integrating WITH a desktop doesn't mean writing the whole stack FOR the desktop. Where did you read such statment ??? Now, please try to understand that. Please try to understand end-users. ?tienne. -- E Ultre?a !
[sane-devel] SANE2 standard completion
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.
[sane-devel] SANE2 standard completion
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
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] HAL and scanners.
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 proprietary backend to provide its own HAL callout. The discussion is not about patching e.g. XSane to use HAL, but rather to allow parallel unified device naming in SANE backends. This will allow a HAL callout to compute mostly working SANE device name in order HAL addon to open a device on plug and monitor its sensors, and much more. Regards, ?tienne.
[sane-devel] HAL and scanners.
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 HAL rather than imposing UDI everywhere in SANE. The idea of alternative naming is very good. I vote for it. Regards, ?tienne.
[sane-devel] HAL and scanners.
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 supports some well known naming scheme along their own specific naming scheme. Then, for scanner specific events (paper-in, adf-opened, mailto button pushed, etc.), a HAL addon would fit, but then linking to SANE and requiring 'scanner' privileges. That's how it see it for now. Please comments. Regards, ?tienne.
[sane-devel] HAL and scanners.
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 does sane_open on it,
then does button monitoring, etc
3. modifying all existing sane backends to accept default device names
1. and 3.. 2. will be an addon (in HAL).
i have two small concerns about this plan: replication of naming code
makes that convention a de facto API
?
This convention is just need if you want to have your scanner usable for
HAL frontend. It is not mendatory. How could we avoid code replication ?
and what about external backends?
External backends can have heir own callout or follow common policy.
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-id and id 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] HAL scanner addon
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 before launching the scanner UI, he's stuck to close the software and relaunch the probe. I want him just to power the device and it appear right in the device selector. Again, making it *just work* ;) Which scanner events do you have in mind? Only plug/unplug events or something else too? HAL handle generic plug/unplug event. We just need to load drivers to handle hardware specific sensors (paper in, cover opened, mailto button pushed, etc.). Do you mean that when a scanner is plugged in, a frontend is automatically launched It's up to the user to determine what to do on scanner plug, not SANE. The best behaviour on scanner plug is to add an entry to every scanner selector opened in the desktop. Think user firing Scan in Gimp and forgot to plug their scanner in, just plug it and it appear right in the selector, clic on it and continue your job. :) Again, the desktop behaviour is not up to SANE, this discussion was just an annoucement of a proof of concept project for adding scanner event monitoring accessible through the desktop. I don't ask SANE to launch a frontend on plug ;). Regards, ?tienne
[sane-devel] Well known sensor
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 information. 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. Agree. About duplex, note that i prefer backend to have a boolean duplex option, similar to printing option. This is the frontend point of view thru ;) 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. Agree. However, buttons with icon should be translated to text as much as possible. I guess think that picture labelled button doesn't change meaning accross countries. So, go for some well known options for sensors. How to publish them ? Which option to publish ? Should you append it to the SANE standard or use an external document subject to more evolution ? Regards, ?tienne.
[sane-devel] HAL and scanners.
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.
[sane-devel] HAL and scanners.
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 scanner.access_method hardcoded to proprietary, the latter is pretty useless ;) Please keep in mind that supporting HAL does NOT mean depending on HAL nor breaking API. Abel Deuring did a very nice job on sane-fdi, a parser for .desc file that provide much useful information right in the fdi. Sadly, the discussion stopped without a lot of success. I updated the sane-fdi script from Abel following the advice from Abel and Johannes Meixner. A device rule looks like : device match key=usb.vendor_id int=0x04a9 match key=usb.product_id int=0x2207 append key=info.capabilities type=strlistscanner/append append key=scanner.api type=strlistsane/append append key=scanner.sane.model type=strlistCanon CanoScan N1220U/append append key=scanner.sane.backends type=strlistplustek/append append key=scanner.sane.backends.plustek.supportstatus type=strlistcomplete/append append key=scanner.sane.backends.plustek.comment type=strlistIdentical to UMAX 3400/append /match /match /device The updated sane-fdi script is available at http://bersace03.free.fr/pub/Development/Scanner/sane-fdi . There is still one thing needed to get full HAL support by SANE, build the SANE device name from those infos. One goal would be to allow frontend to provide an entry for each backend allowing user to select the backend to use. Using e.g. Cannon CanoScan N1220U (complete support with plustek driver) along Canon CanoScan N1220U (complete support with umax driver) will allow user to easily select driver. According to discussion about HAL and SANE last year, seems that the udi:backend:udi would be the solution for SANE to support HAL (without depending on it). See http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018353.html for details. So, can we move forward ? :) Regards, ?tienne. -- E Ultre?a !
[sane-devel] HAL and scanners.
Hi, ? We should encapsulate all HAL/DBus call inside hal backend. the hal backend will load 'backend', and ask it for a list of scanners it can find, and somehow pick the one that goes with the 'udi'. But how can hal backend filter the device list ? Can we avoid the actual backend to search scanner and rather just try to use directly the right device according to some info passed from the HAL backend i am worried that the last step means that each backend will have to know how to translate udi's. Thus, the hal backend should pass enough information to the actual backend : libusb usb_dev struct or just bus num and dev num, linux device, etc.. This can be done depending on device type (usb or scsi for now). Please comment. Regards, ?tienne.
[sane-devel] HAL and scanners.
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 can this way decide, if a Sane device matches the current HAL device. So basically, we have have two solutions : 1. a HAL callout + sane_get_device_informations()? 2. a SANE meta backend 3. extends the meaning of sane_open() I actually prefer the first since it imply less modification in SANE. Something good would be to avoid reloading all backends since HAL know which backends support the device. Something like sane_backend_get_devices would be very cool. Which solution is the right ? Other solution are welcome ;) Please comment. Many thanks Abel for commenting. Regards, ?tienne.
[sane-devel] HAL and scanners.
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 usb, scsi and ieee1394, it makes sens to have a common scanner naming policy : * USB = backend:libusb:busnum:devnum * SCSI = backend:devfile * IEEE1394 = backend:? I have no idea for IEEE1394, but it would be nice to provide also a well known device name for IEEE1394. With a well known naming policy, a HAL callout could just compute the sane device name on plug and publish it as HAL device property. Once we have a resonnable policy for well known device name, we could list backend that needs to comply. I didn't find, but i'm not very skilled at search in all sane backends. Regards, ?tienne.
[sane-devel] HAL and scanners.
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:udi. * 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 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:udi. 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:backend:udi 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:backend:udi 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 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 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 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
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] rts8891 backend inclusion
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 done per model, without modifying the underlying option handling (based on button number). I'm telling you this, writing hal-scanner support which should help a lot on makeing use of scanner buttons in frontend like GNOME Scan and KDE. The idea is to help as much as possible the frontend to auto determine what to do on button event. I would like to open a discussion about button naming for 1.2, once i have a reasonnable hald-addon-scanner version. Regards, ?tienne.
[sane-devel] rts8891 backend inclusion
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 others backends. title and desc are translatable, so it make it impossible for frontend to handle in a generic manner. Since backend only rely on option index, it's just plain useless to use button%d (some backend uses button-%d through). Since this is quite a mess for buttons naming, i guess you should not base your naming on this ;) Having 'well known' button names seems sensible. Have you allready got an idea ? For instance the 4470c has: - power button - scanner button - www button - copy button - mail button - printer button - '+' button - '-' button - toggle color/gray scan mode button - spanner button - red triangle within a red circle button very very interesting, especially scan,www,mail,printer,etc. Having a set a well known buttons would help so much to provide smart button handling on high level. Prodividing extended meaning in title, desc and man pages will help handling such button in frontend. Regards, ?tienne.
[sane-devel] Announce: GNOME Scan 0.6
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-scan-06-ready-for-wider-adoption/ Regards, ?tienne.
[sane-devel] more actions fore sane 1.1
Does a german and an itilian understand the same thing behind Tweaking ? ;) ?tienne.
[sane-devel] more actions fore sane 1.1
Hi, That's the shame with english. When will SANE switch to Esperanto ;) Regards, ?tienne.
[sane-devel] Install HAL fdi
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 other). Regards, ?tienne. -- E Ultre?a ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080301/6e053509/attachment.pgp
[sane-devel] Install HAL fdi
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 was scrubbed... Name: sane-intall-hal-fdi.patch Type: text/x-patch Size: 1269 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080229/b6bd399a/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080229/b6bd399a/attachment.pgp
[sane-devel] Install HAL fdi
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 was scrubbed... Name: sane-intall-hal-fdi.patch Type: text/x-patch Size: 1269 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080229/22966191/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080229/22966191/attachment.pgp
[sane-devel] Install HAL fdi
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 was scrubbed... Name: sane-intall-hal-fdi.patch Type: text/x-patch Size: 1219 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080229/1a8778f3/attachment.bin
[sane-devel] The future of the SANE-Standard
Hi, What we really need, err, what USERS really need, is a range of frontends that match their needs as closely as possible: - one frontend for the average joe user to handle basic scanning needs (b/w text, documents, photos) - one frontend for the advanced user (would be today's XSane) - one frontend for the ?ber-advanced imaging guru, with advanced features like IR, etc. I do fully agree with you. As developer of Gnome Scan, i really don't want to support all use-case, but 100% of maman use cases so that she never ask me again to do the scan for her again. I'm pretty sure gnome-scan will never handle IR or such advanced feature ! However, i'm pretty concerned by hotplug and event handling wich is a lame of SANE for now. Regards, ?tienne. -- E Ultre?a ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071219/da894629/attachment.pgp
[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)
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) support 6. hotplug support (through HAL or whatever the host uses). ?tienne. -- E Ultre?a ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071217/3ea40369/attachment.pgp
[sane-devel] SANE Release?
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 !
[sane-devel] test backend
Hi, As a frontend developer, I'm very interested in such addition to test backend !! Regards, ?tienne. -- E Ultre?a !
[sane-devel] Intend to write driver(s)
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. I don't own any Windows(r). Would be nice to provide a kind of tutorial or any documentation helping new backend writer. ?tienne. -- verso l'Alto !
[sane-devel] Additional frame types in Sane 1
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 !
[sane-devel] Additional frame types in Sane 1
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 source options ;-). ?tienne -- verso l'Alto !
[sane-devel] Make source consistent accross backends
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. However, backends have inconsistent source values.
[sane-devel] xsane-0.992 released
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 non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070126/c49571cf/attachment.pgp From stef@free.fr Fri Jan 26 14:28:40 2007 From: stef@free.fr (=?iso-8859-15?q?St=E9phane_VOLTZ?=) Date: Fri Jan 26 14:28:50 2007 Subject: [sane-devel] Lexmark x1185 Can't Find Home In-Reply-To: bay106-f26b9bb9e5d0d1cc224de8c4...@phx.gbl References: bay106-f26b9bb9e5d0d1cc224de8c4...@phx.gbl Message-ID: 200701261428.40853.stef@free.fr Le mardi 23 janvier 2007 00:28, Robert Price a ?crit?: Sorry, here are details on my setup: Slackware 10.2 with kernel 2.6.18. Vendor=OX043D, Product=OXOO7c, Chip=rts8858c. Thanks. From: Robert Price bobpricem...@hotmail.com To: sane-devel@lists.alioth.debian.org Subject: [sane-devel] Lexmark x1185 Can't Find Home Date: Mon, 22 Jan 2007 17:08:08 -0600 Greetings; Attached is the debug output produced when I try to scan with a Lexmark x1185. The behavior of the machine is that it will make a distressing mechanical buzzing noise and stop. This happens with the release and CVS versions of sane. The scanner works fine on the same computer under Windows XP. I know this problem has been in the bug tracker for a while but I was hoping that posting the debug text here might prompt some ideas. I've attached the entire debug output but the last thing it shows before hanging is: [lexmark] sane_start: handle=0x82508a0 [lexmark] sane_get_parameters: handle=0x82508a0, params=(nil) [lexmark] sane_get_parameters: Data size determined as 3e12a [lexmark] sane_get_parameters: [lexmark] format: SANE_FRAME_RGB [lexmark] last_frame: TRUE [lexmark] lines 177 [lexmark] depth 8 [lexmark] pixels_per_line e2 [lexmark] bytes_per_line 2a6 [lexmark] sanei_lexmark_x1100_search_home_fwd: [lexmark] sanei_lexmark_x1100_search_home_bwd: Killed Hello, I've put at http://stef.dev.free.fr/sane/lexmark/ an patched and compile tarball so you can try it. Regards, Stef
[sane-devel] Well known option consensus
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 size, and disable the options tl-x, tl-y, br-x, br-y. No ! If a user want to scan only a portion of the paper, he must be able to set scan area, but as long as there is no scan surface, we use paper size as scan surface. That make sense ! ?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 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070122/14116d8f/attachment.pgp From kitno...@gmail.com Mon Jan 22 14:43:25 2007 From: kitno...@gmail.com (m. allan noah) Date: Mon Jan 22 14:50:42 2007 Subject: [sane-devel] Well known option consensus In-Reply-To: 1169466263.5734.1.camel@thilivren References: 1169400182.5609.23.camel@thilivren 45b4083a.7070...@gmx.net 97246d0e0701211646s24e11ee5o7f0e2e397b45e...@mail.gmail.com 45b41a2c.9000...@gmx.net 1169466263.5734.1.camel@thilivren Message-ID: 97246d0e0701220543t16978099jed1efc3934e0b...@mail.gmail.com On 1/22/07, ?tienne Bersac bersac...@laposte.net wrote: 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 size, and disable the options tl-x, tl-y, br-x, br-y. No ! If a user want to scan only a portion of the paper, he must be able to set scan area, but as long as there is no scan surface, we use paper size as scan surface. That make sense ! you missed the point here. we are talking about an overscan option, which causes the scanner to add space all around the scan, such that the back- ground shows thru. but i think a person might want to overscan and still have only a small area of the page (one of the corners?) i think i can work this out, and still be compatible with the text of our suggestion. allan -- The truth is an offense, but not a sin
[sane-devel] Well known option consensus
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 : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070121/d1eb3c70/attachment.pgp From bersac...@laposte.net Sun Jan 21 18:56:43 2007 From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac) Date: Sun Jan 21 18:56:51 2007 Subject: [sane-devel] Using host operating system hardware detection Message-ID: 1169402203.5609.57.camel@thilivren Hi, Following HAL sane support, i talk a bit at freedesktop about a scanner infrastructure (mostly on top of SANE), for handling buttons event, and so on. One more time, i heard this idea i join : SANE should use host operating system hardware detection and handling. As stated above, sanei should be able to handle either HAL UDI and similar standard in Unix, Windows, Mac OS X, ? The better solution would be to receive UDI and only UDI, not backends. So that a frontend can use HAL to query scanner list, and directly sane_open the result. The same on Windows, Mac OS X, Unix, ? At build time, it's simple to choose which source can be understand by sanei. Please comment. ?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 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070121/07c9bee1/attachment.pgp From e...@erikwickstrom.com Sun Jan 21 17:47:12 2007 From: e...@erikwickstrom.com (Erik Wickstrom) Date: Sun Jan 21 19:41:28 2007 Subject: [sane-devel] scanimage: sane_read: Error during device I/O Message-ID: 3d381e170701210847k61b0debftcace5fe66af1...@mail.gmail.com Hi all, I've been trying to get my scanner working, but no luck so far. Whenever I try to scan in sane/xsane I get this error during device i/o message. I'm running Ubuntu Edgy (6.10) and my scanner is an HP LaserJet 3330 MFP. scanimage prints a bunch of binary data to standard output while the scanner is scanning. Then it prints this message. Ubuntu/xsane auto-detect my scanner. I've also tried installing HPLIB. I have no idea what to try next. Thanks for your help! Erik -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070121/c306c02f/attachment.html From j...@gmx.de Sun Jan 21 20:39:54 2007 From: j...@gmx.de (Jan Kandziora) Date: Sun Jan 21 20:47:15 2007 Subject: [sane-devel] Pages all white with Cybercom 9352 (mustek_pp) backend Message-ID: 200701212039.54719@gmx.de Dear All, I have problems with this old parport scanner. It works fine with MS-Windows 98, but SANE's scanimage (xsane, too) only give back all white images. Playing a little with the resolution option (others do not apply to this scanner), I got all the same result. It just scans the whole page, but the image is plain white... I found an older posting http://lists.alioth.debian.org/pipermail/sane-devel/2004-February/010102.html which reports the same problem but, to my pity, no respones. Any ideas/pointers? (YES, I indeed put some colored paper on the scanner...) Kind regards Jan -- Ber?chtigte Euphemismen: Industriestandard
[sane-devel] (no subject)
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 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070119/4b838297/attachment.pgp From kilg...@banach.math.auburn.edu Fri Jan 19 22:48:02 2007 From: kilg...@banach.math.auburn.edu (kilg...@banach.math.auburn.edu) Date: Fri Jan 19 22:00:46 2007 Subject: [sane-devel] Setting up a dedicated machine to run scanner Message-ID: pine.lnx.4.64.0701191529260.9...@banach.math.auburn.edu Hi, I want to set up a dedicated machine in a semi-public location (departmental printer room in my university) which will do the following things: 1. allow people to use it freely to run the attached scanner and to do something with the output 2. output can be sent to the printer (which requires network access), or 2a. sent by scp to another machine on which the scanner user has an account (obviously also needs network access), or 2b. copied to the user's USB flash drive which the user can be plugged into the back of the machine (obviously requires automatic mounting and umounting of said flash drive) So, there is an obvious conflict between usability and security. I would say that it is not the right kind of environment to go making people to get an account on the machine; they should be able just to come and run the scanner. I would say that it should not be permissible to run any shell (by, for example, launching an xterm with a command prompt) and also it would be good to set up xsane so that it automatically clobbers the previous output file when a new scan is done, and the user who walks up to the machine cannot change that. Also, the save-the-file dialog should only allow the file to be saved in the scanner account's directory, or on the flash drive (which would require a hookup of the save-file dialog to mount the flash drive automatically and invisibly, but with a warning in case it has been attached, and to unmount it when the file has been copied, along with another warning if said flash drive is removed prematurely). Furthermore, the save-file dialog should only allow inspection of the scanner home directory and of the flash drive, not other directories. Has anyone already done something like this? To what extent is it possible to configure xsane by means of an .rc file, which the user cannot alter? Also, how difficult would it be to get the Help key to give some help which is specific to the situation, telling the user what can and cannot be done, and how to do what can be done? I have figured out how to do things like set up an account which will start X straightaway and will then do nothing but to run xsane, or perhaps a TCL menu box which will do nothing but offer certain options. But how much of what I want could be done inside of xsane, with custom configurations, without a major overhaul of source code? Theodore Kilgore
[sane-devel] SANE2 commitment
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 each time you launch the app. I wonder if we need a kind of cups for scanner that use sane to access, receive job request and return stream of pictures. I wonder how to handle local and networked detection. I want to add avahi feature to scanner share. Likely, SANE 2 offer a new sane_open () prototype that allow to get device description without doing the probe. But how can hal know the sane device name ? I would like to add a scanner.sane.name field or similar into hal scanner device in order to allow app to use directly SANE (basically, a scaner cups will do that). Is this possible with SANE 1 ? If not, how does SANE 2 help for that ? Some of you may be attached to the double work of sane : device support, device probe. But i really think SANE must add a way for developer to handle device detection according to the target system standard (e.g. hal, windows, Solaris, etc.). I do not want sane to drop sane_get_devices (). Would be nice to get sane device name from vid/pid or some other info an OS/hal can give. That's easy to implement a simple hal addon that handle the filling of scanner.sane.name field. I wish you will understand that need. Kind regards, ?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 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061217/d5528193/attachment.pgp From bersac...@laposte.net Sun Dec 17 22:36:23 2006 From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac) Date: Tue Dec 19 19:42:50 2006 Subject: [sane-devel] SANE2 commitment In-Reply-To: 69ff73b20612171152h1110e1deleb7b80d30264...@mail.gmail.com References: 20061215175700.4c974c89@inspiron 45854deb.9010...@penguin-breeder.org 20061217172351.70067897@inspiron 45858d8f.6080...@zago.net 20061217201545.2a7c85c3@inspiron 4585998d.7030...@zago.net 20061217203458.10327e0e@inspiron 69ff73b20612171152h1110e1deleb7b80d30264...@mail.gmail.com Message-ID: 1166391382.5549.17.camel@thilivren 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 : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061217/a9772311/attachment.pgp From bersac...@laposte.net Tue Dec 19 15:55:10 2006 From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac) Date: Tue Dec 19 20:19:59 2006 Subject: [sane-devel] SANE2 commitment In-Reply-To: 1166539654.30598.31.camel@casa References: 20061215175700.4c974c89@inspiron 45854deb.9010...@penguin-breeder.org 20061217172351.70067897@inspiron 45858d8f.6080...@zago.net 20061217201545.2a7c85c3@inspiron 4585998d.7030...@zago.net 20061217203458.10327e0e@inspiron 69ff73b20612171152h1110e1deleb7b80d30264...@mail.gmail.com 1166539654.30598.31.camel@casa Message-ID: 1166540109.5681.35.camel@thilivren Hi, That would be really nice. I wonder if this will only work on linux. What about *BSD, Solaris and Windows? I think that SANE must implement a modular OS - SANE API that allow OS to ask SANE to load a driver for one device and the monitor buttons, ? SANE should then also implement a legacy probe mecanism for other OSes or other purpose (distro not shiping HAL, etc.). ?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 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061219/36fc8090/attachment.pgp From bersac...@laposte.net Tue Dec 19 20:57:38 2006 From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac) Date: Tue Dec 19 22:58:39 2006 Subject: [sane-devel] Frontends : Gnome Scan 0.4 ! Message-ID: 1166558258.5681.99.camel@thilivren Hi all ! Gnome Scan 0.4 has been released with nice gui improvments and new features like x/y resolutions, computed area rotation, ? http://gnome-scan.blogspot.com/2006/12/releasing-04-is-your-app-people-ready.html ?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
[sane-devel] New frontend: Gnome Scan / flegita
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 end user apps plugins bundle is called flegita. It currently include flegita (the standalone app) and flegita-gimp, a gimp plugin. A few features are implemented today. The project is far from ready for distribution in Gnome releases. See http://home.gna.org/gnomescan/index for further information and links. The UI is quite simple and incomplete as of now. However, i work a lot in the past week to make SANE call reliable. Before continuing development of end user feature (such as preview zoom, fixed area, mass acquisition, etc.), i want to make use of HAL and DBus to get device list. Thanks. ?tienne. -- Verso l'Alto !
[sane-devel] SANE 2 suggestion: move SANE_Parameters doc to Data Types section
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 !
[sane-devel] sane_control_option() confusion
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 !
[sane-devel] SANE 2 proposal : sane_get_device_descriptor()
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_String_Const array); * create const SANE_Device_Descriptor* sane_get_device_descriptor(SANE_String_Const name) wich return the device name descriptor. * Drop the name field of SANE_Device_Descriptor. I wish you find this suggestion useful. ?tienne. -- Verso l'Alto !
[sane-devel] plustek:libusb bugs on canon canoscan n1220U
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
^^^
The USB in USB flatbed scanner is very annoying since that make type
parsing hard if an app want to show an icon representing the type of the
device. I guess an enum should be better than string.
SANE_TYPE_OPTION does not exist
Sorry, i meant SANE_TYPE_{BOOL,INT,FIXED,STRING}.
The 5 options button have SANE_TYPE_BOOL as type (in
SANE_Option_Descriptor struct). That should be SANE_TYPE_BUTTON.
Thanks.
?tienne.
--
Verso l'Alto !
[sane-devel] plustek:libusb bugs on canon canoscan n1220U
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_BUTTON is maybe misleading. It is intended to be used by a backend to allow changes by pressing that button from the GUI and NOT to reflect the status of a scanner button. An option of type SANE_TYPE_BUTTON has no value. See also chapter 4.2.9.4 of the SANE Standard http://www.sane-project.org/html/doc011.html Okey, the strange part of this button handling is : how an app using sane know an option reflect a button status ? Just in order to ignore that option. For example, xsane advanced options dialog shows a fieldset entitled Buttons with one option Scanner button which is inactive and always false. That's useless. I don't know how multiple buttons are handle. Do the app has to parse name or title or desc field in order to find a button string and then treat the option as a button state option ? Thanks for all. ?tienne. -- Verso l'Alto !
[sane-devel] plustek:libusb bugs on canon canoscan n1220U
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 button of type SANE_TYPE_OPTION instead of SANE_TYPE_BUTTON * the device type is USB flatbed scanner instead of flatbed scanner. I do not have such bug with an HP all-in-one printer. So i guess this are backend bug. Thanks. -- Verso l'Alto !
