[sane-devel] more actions fore sane 1.1
On Thu, 28 Feb 2008 17:49:34 -0500 "m. allan noah" wrote: > yes- i am now inclined to agree with you, oliver. > > > Don`t you think you already lost control about what you started? > > Please take a step back and take a look at what you are doing. well, maybe I should declare my intentions in a cleaner way. I would like to evolve sane by little steps, one after another, while keeping compatibility. I want to do that by adding new frame types and new actions. Now if the other developers here can declare their intentions and the way they want to implement them, we can have a better picture of the thing that's going on and we can see if and how we can work together toward the same target. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] more actions fore sane 1.1
Add some more things and we are close to sane2. Don`t you think you already lost control about what you started? Please take a step back and take a look at what you are doing. Oliver Am Donnerstag, den 28.02.2008, 23:39 +0100 schrieb Alessandro Zummo: > > while we are discussing how to implement new features, > here are a couple of things that i'd like to see: > > > - a way to obtain some more info about the scanner. > > I always missed a way to ask the scanner for vendor, model and > serial number. the only option available right now is to cache > them during the initial roundup. > > > - a way to specify the scan area without having to keep > track of the corner options > > This could be easily implemented with an appropriate action. > > > - a way to handle the "lamp warming up" problem > > Still have to think about how to implement this > in a reasonable way. > > Obviously all must be done in a compatible way. > > > I'd love if other people can add their requirements so > we can all see in which direction we must drive sane. > > > -- > > Best regards, > > Alessandro Zummo, > Tower Technologies - Torino, Italy > > http://www.towertech.it > >
[sane-devel] more actions fore sane 1.1
while we are discussing how to implement new features, here are a couple of things that i'd like to see: - a way to obtain some more info about the scanner. I always missed a way to ask the scanner for vendor, model and serial number. the only option available right now is to cache them during the initial roundup. - a way to specify the scan area without having to keep track of the corner options This could be easily implemented with an appropriate action. - a way to handle the "lamp warming up" problem Still have to think about how to implement this in a reasonable way. Obviously all must be done in a compatible way. I'd love if other people can add their requirements so we can all see in which direction we must drive sane. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] [RFC] how to enable 1.1 features
On Thu, 28 Feb 2008 16:48:51 -0500 "m. allan noah" wrote: > > > > but nothing about my suggestion will prevent authors from writing > > good code :) > > > > > > but you are not going to induce them to do so :) > > > > and neither are you :) I would, trust me, I would.. :-D > > > > > > IF the frontend is compliant :) > > > > ahh- but now you see the advantage of my approach- you wont find a > > frontend that uses the caps in a switch/case, because its a bitmask. > > so instead, they are doing macro == tests, so if the option does not > > have SANE_CAP_SOFT_SELECT set, it wont display. I just can't understand why we can't pretend that people uses switch correctly. > > > The fact that the code exists do not make it less ugly. > > > > ah- it might not be perfect, but it MUST continue to exist, so lets > > use it instead of adding a new interface, and requiring authors that > > want their frontends to build against old sane to add ifndef's to > > handle the missing new macros. Why an 1.1 COMPLIANT frontend should be allowed to compile against 1.0 SANE? I've never seen in my whole life any other library that has such a requirement. When the library version changes, you have to change the headers. > > > > Ok, i'll buy that, so lets say that my well-known option should be > > > > tied to the version number rather than the feature name, so how about > > > > we call it 'sane-extension' or some such? > > > > > > the problem is not the name, but the way. Options are - well - options. > > > supporting sane 1.1 is not an option :) > > > > Ah- now i have you- you entire proposal is based around the idea of > > making these features optional for backend/frontend combinations that > > can support them. how are all other optional features in sane enabled? > > > > the existing options interface. My whole idea is to not use well known options for new things. We are forced to keep them, that's true, but if we want one day move toward a newer and better sane (1.x .. 2.0) with must evolve.. make little - non breaking - changes and keep evolving. sane is stagnating since ten years.. let's try a new way, let's try new things. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] [RFC] how to enable 1.1 features
On Thu, 28 Feb 2008 16:03:23 -0500 "m. allan noah" wrote: > > Hi do not agree here. I'd like for both backends and frontends to > > be "well-written". This is the whole point and I believe it > > is perfectly reasonable. > > but nothing about my suggestion will prevent authors from writing good code :) but you are not going to induce them to do so :) > > > > In order to use a well known option, a frontend should track the option > > by its name, doing strcmps on all the options, just like we are > > doing now with corners. > > > > In tiffscan I need to iterate on the options to find the four corners > > because there is no other way to it. Saying that this is ugly is > > not enough. > > ah- but that's really where sane's power comes from- it is the > well-documented mechanism thru which we communicate about the features > of a backend. i see the support for additional frame types as just > another of these features. frame types are completely different from well known options. the existing mechanism has been a problem more than once. > > Adding a flag means that only new frontends that can handle this flag > > will keep the option hidden. > > No, you misunderstand. the caps flag i would add would indicate that > the option could be set only by the frontend itself, all the other > bits would be set to indicate that the option was not user selectable, > and so, would be hidden in ALL frontends. IF the frontend is compliant :) > > On the other side my method would > > a) do no harm to existing backends/frontends > > b) be extremely easy to implement in a frontend > > > > my suggestion does even LESS harm to existing backends and front-ends, > cause you wont have to touch them at all! > and, it's even easier to implement in a front-end, since you already > have code to walk the options array and deal with the corner values :) The fact that the code exists do not make it less ugly. > > By declaring that you are sane 1.1 compliant you, the programmer, > > are telling your users that you have put your efforts into making your > > code robust, to check and handle error codes. > > Ok, i'll buy that, so lets say that my well-known option should be > tied to the version number rather than the feature name, so how about > we call it 'sane-extension' or some such? the problem is not the name, but the way. Options are - well - options. supporting sane 1.1 is not an option :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] [RFC] how to enable 1.1 features
On Thu, 28 Feb 2008 09:28:59 -0500 "m. allan noah" wrote: > in the fujitsu backend, i previously had added a 'compression' option > with the description warning of possible front-end incompatibility, > and the default setting to not compress. i feel this is sufficient, > because it requires no changes at all to a well-written frontend. > > but, if you really want to protect this behaviour by requiring > 'behind-the-scenes' frontend action, i would rather see a well-known > option with its caps flags set to make them invisible. i think > extending that flag (if required) is safer than adding macros or > extending enums, because '==' tests are done on the caps instead of > switch/case statements. > > i would also rather see this well-known option be named by the feature > it implements, instead of a version name. By that means, a backend can > add support for something particular, and a frontend can enable > something particular. Hi do not agree here. I'd like for both backends and frontends to be "well-written". This is the whole point and I believe it is perfectly reasonable. In order to use a well known option, a frontend should track the option by its name, doing strcmps on all the options, just like we are doing now with corners. In tiffscan I need to iterate on the options to find the four corners because there is no other way to it. Saying that this is ugly is not enough. Adding a flag means that only new frontends that can handle this flag will keep the option hidden. On the other side my method would a) do no harm to existing backends/frontends b) be extremely easy to implement in a frontend By declaring that you are sane 1.1 compliant you, the programmer, are telling your users that you have put your efforts into making your code robust, to check and handle error codes. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Formulardaten
=== == Neuer Eintrag === --- -- Formular: 'adddev' --- 1. Your email address: 'cristianefaby at virgilio.it' 2. Manufacturer (e.g. "Mustek"): 'canon' 3. Model name (e.g. ScanExpress 1200UB): 'd646u' 4. Bus type: 'Other' 5. Vendor id (e.g. 0x001): '' 6. Product id (e.g. 0x0002): '' 7. Chipset (e.g. lm9831): '' 8. Comments (e.g. similar to Mustek 1234): ' I am Italian. I have photos of my chipset d646u canon scanner. How can I send you a photo?' 9. Data (e.g. sane-find-scanner -v -v): ''
[sane-devel] [RFC] how to enable 1.1 features
On 2/28/08, Alessandro Zummo wrote: > > With your repeated requests to make other API changes, and your > > willingness to write code, how about we bite this bullet and re-open > > the discussion about building a new, simpler sane2? > > because I don't want to discuss, I want to write code. I very > much like the linux development model. discussion is based on code, > not the other way around. Write a little, discuss a little, repeat. > > But they have Linus as the ultimate deus-ex-machina :) > > But while in linux there's willing to evolve and change, here this > willingness is restricted to a few individuals. > > An interesting read about that can be found in > http://kerneltrap.org/Linux/Kernel_Evolution > > 28 people contributed to the last two changelogs, but > only a few here are saying what they would like to do. > > Even if their desire is to keep the thing as is, it is > very much important to say it. That is not quite a fair characterization- linux does NOT change its userspace ABI in every release, no one would use it! Yes, the kernel module API changes all the time, but linux contains both the kernel AND the modules. we dont have the luxury of shipping all the frontends and backends in one package. the current sane2 draft standard is overly complex (particularly in frame handling) and has not been touched in years. I would not implement it without a complete re-examination of it. But, if we call it the sane3 draft, and implement something very, very small as sane2, then we will get your desired effect of frequent advancements, and protect the frontend authors and users from a mess, by using a soversion bump. so what if sane will have a new soversion once a year? lots of other libs do worse... allan -- "The truth is an offense, but not a sin"
[sane-devel] [RFC] how to enable 1.1 features
On 2/28/08, Alessandro Zummo wrote: > On Thu, 28 Feb 2008 17:57:29 -0500 > > "m. allan noah" wrote: > > > > > Why an 1.1 COMPLIANT frontend should be allowed to compile against 1.0 > > > SANE? > > > > > > I've never seen in my whole life any other library that has such > > > a requirement. When the library version changes, you have to change > > > the headers. > > > > AND YOU ALSO ALWAYS CHANGE THE SONAME. is that clear enough? > > > no need to shout. sorry about that- got carried away thinking about having this discussion over again :( > that's certainly true but then we already have the > problem because the new frames aren't in the old header so a 1.1 frontend > that wants to handle them shall use the 1.1 headers anyway. on the > other side we do not want to change the soname. my original idea was to have the end user protect the frontend by not choosing settings it could not support. that would enable us to make no changes to frontends, no changes to old backends and get sane a much needed feature in a hurry. some folks thought that was playing fast and loose with the standard. calling it sane 1.1, but leaving the soversion at 1 was a compromise to hopefully clue front-end authors in to the existence of these changes, while keeping the advantages of the small, fast solution. That was still not enough for some folks, as this is still an API change. With your repeated requests to make other API changes, and your willingness to write code, how about we bite this bullet and re-open the discussion about building a new, simpler sane2? allan -- "The truth is an offense, but not a sin"
[sane-devel] [RFC] how to enable 1.1 features
On 2/28/08, Alessandro Zummo wrote: > > > > The fact that the code exists do not make it less ugly. > > > > > > ah- it might not be perfect, but it MUST continue to exist, so lets > > > use it instead of adding a new interface, and requiring authors that > > > want their frontends to build against old sane to add ifndef's to > > > handle the missing new macros. > > Why an 1.1 COMPLIANT frontend should be allowed to compile against 1.0 SANE? > > I've never seen in my whole life any other library that has such > a requirement. When the library version changes, you have to change > the headers. AND YOU ALSO ALWAYS CHANGE THE SONAME. is that clear enough? allan -- "The truth is an offense, but not a sin"
[sane-devel] more actions fore sane 1.1
yes- i am now inclined to agree with you, oliver. allan On 2/28/08, Oliver Rauch wrote: > > Add some more things and we are close to sane2. > > Don`t you think you already lost control about what you started? > Please take a step back and take a look at what you are doing. > > Oliver > > Am Donnerstag, den 28.02.2008, 23:39 +0100 schrieb Alessandro Zummo: > > > > > while we are discussing how to implement new features, > > here are a couple of things that i'd like to see: > > > > > > - a way to obtain some more info about the scanner. > > > > I always missed a way to ask the scanner for vendor, model and > > serial number. the only option available right now is to cache > > them during the initial roundup. > > > > > > - a way to specify the scan area without having to keep > > track of the corner options > > > > This could be easily implemented with an appropriate action. > > > > > > - a way to handle the "lamp warming up" problem > > > > Still have to think about how to implement this > > in a reasonable way. > > > > Obviously all must be done in a compatible way. > > > > > > I'd love if other people can add their requirements so > > we can all see in which direction we must drive sane. > > > > > > -- > > > > Best regards, > > > > Alessandro Zummo, > > Tower Technologies - Torino, Italy > > > > http://www.towertech.it > > > > > > > -- > sane-devel mailing list: sane-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-request at lists.alioth.debian.org > -- "The truth is an offense, but not a sin"
[sane-devel] [RFC] how to enable 1.1 features
resend to list- sorry alessandro- On Thu, Feb 28, 2008 at 4:47 PM, m. allan noah wrote: > On Thu, Feb 28, 2008 at 4:20 PM, Alessandro Zummo > > wrote: > > > On Thu, 28 Feb 2008 16:03:23 -0500 > > > > "m. allan noah" wrote: > > > > > > > > Hi do not agree here. I'd like for both backends and frontends to > > > > be "well-written". This is the whole point and I believe it > > > > is perfectly reasonable. > > > > > > but nothing about my suggestion will prevent authors from writing good > code :) > > > > but you are not going to induce them to do so :) > > and neither are you :) > > > > > > > > > > In order to use a well known option, a frontend should track the > option > > > > by its name, doing strcmps on all the options, just like we are > > > > doing now with corners. > > > > > > > > In tiffscan I need to iterate on the options to find the four > corners > > > > because there is no other way to it. Saying that this is ugly is > > > > not enough. > > > > > > ah- but that's really where sane's power comes from- it is the > > > well-documented mechanism thru which we communicate about the features > > > of a backend. i see the support for additional frame types as just > > > another of these features. > > > > frame types are completely different from well known options. > > the existing mechanism has been a problem more than once. > > just because they are not perfect does not mean that adding a new > interface is a better idea. > > > > > > Adding a flag means that only new frontends that can handle this > flag > > > > will keep the option hidden. > > > > > > No, you misunderstand. the caps flag i would add would indicate that > > > the option could be set only by the frontend itself, all the other > > > bits would be set to indicate that the option was not user selectable, > > > and so, would be hidden in ALL frontends. > > > > IF the frontend is compliant :) > > ahh- but now you see the advantage of my approach- you wont find a > frontend that uses the caps in a switch/case, because its a bitmask. > so instead, they are doing macro == tests, so if the option does not > have SANE_CAP_SOFT_SELECT set, it wont display. > > > > > > On the other side my method would > > > > a) do no harm to existing backends/frontends > > > > b) be extremely easy to implement in a frontend > > > > > > > > > > my suggestion does even LESS harm to existing backends and front-ends, > > > cause you wont have to touch them at all! > > > and, it's even easier to implement in a front-end, since you already > > > have code to walk the options array and deal with the corner values :) > > > > The fact that the code exists do not make it less ugly. > > ah- it might not be perfect, but it MUST continue to exist, so lets > use it instead of adding a new interface, and requiring authors that > want their frontends to build against old sane to add ifndef's to > handle the missing new macros. > > > > > > By declaring that you are sane 1.1 compliant you, the programmer, > > > > are telling your users that you have put your efforts into making > your > > > > code robust, to check and handle error codes. > > > > > > Ok, i'll buy that, so lets say that my well-known option should be > > > tied to the version number rather than the feature name, so how about > > > we call it 'sane-extension' or some such? > > > > the problem is not the name, but the way. Options are - well - options. > > supporting sane 1.1 is not an option :) > > Ah- now i have you- you entire proposal is based around the idea of > making these features optional for backend/frontend combinations that > can support them. how are all other optional features in sane enabled? > > the existing options interface. > > > > allan > -- > "The truth is an offense, but not a sin" > -- "The truth is an offense, but not a sin"
[sane-devel] [RFC] how to enable 1.1 features
On Thu, Feb 28, 2008 at 3:46 PM, Alessandro Zummo wrote: > On Thu, 28 Feb 2008 09:28:59 -0500 > "m. allan noah" wrote: > > > in the fujitsu backend, i previously had added a 'compression' option > > with the description warning of possible front-end incompatibility, > > and the default setting to not compress. i feel this is sufficient, > > because it requires no changes at all to a well-written frontend. > > > > but, if you really want to protect this behaviour by requiring > > 'behind-the-scenes' frontend action, i would rather see a well-known > > option with its caps flags set to make them invisible. i think > > extending that flag (if required) is safer than adding macros or > > extending enums, because '==' tests are done on the caps instead of > > switch/case statements. > > > > i would also rather see this well-known option be named by the feature > > it implements, instead of a version name. By that means, a backend can > > add support for something particular, and a frontend can enable > > something particular. > > Hi do not agree here. I'd like for both backends and frontends to > be "well-written". This is the whole point and I believe it > is perfectly reasonable. but nothing about my suggestion will prevent authors from writing good code :) > > In order to use a well known option, a frontend should track the option > by its name, doing strcmps on all the options, just like we are > doing now with corners. > > In tiffscan I need to iterate on the options to find the four corners > because there is no other way to it. Saying that this is ugly is > not enough. ah- but that's really where sane's power comes from- it is the well-documented mechanism thru which we communicate about the features of a backend. i see the support for additional frame types as just another of these features. > Adding a flag means that only new frontends that can handle this flag > will keep the option hidden. No, you misunderstand. the caps flag i would add would indicate that the option could be set only by the frontend itself, all the other bits would be set to indicate that the option was not user selectable, and so, would be hidden in ALL frontends. > On the other side my method would > a) do no harm to existing backends/frontends > b) be extremely easy to implement in a frontend > my suggestion does even LESS harm to existing backends and front-ends, cause you wont have to touch them at all! and, it's even easier to implement in a front-end, since you already have code to walk the options array and deal with the corner values :) > By declaring that you are sane 1.1 compliant you, the programmer, > are telling your users that you have put your efforts into making your > code robust, to check and handle error codes. Ok, i'll buy that, so lets say that my well-known option should be tied to the version number rather than the feature name, so how about we call it 'sane-extension' or some such? allan -- "The truth is an offense, but not a sin"
[sane-devel] Formulardaten
=== == Neuer Eintrag === --- -- Formular: 'adddev' --- 1. Your email address: 'mail at test.ws' 2. Manufacturer (e.g. "Mustek"): '' 3. Model name (e.g. ScanExpress 1200UB): 'Bober' 4. Bus type: 'USB' 5. Vendor id (e.g. 0x001): '' 6. Product id (e.g. 0x0002): '' 7. Chipset (e.g. lm9831): '' 8. Comments (e.g. similar to Mustek 1234): 'http://viagrapill.blinklist.com/";>buy viagra onlinehttp://cialisbest.blinklist.com/";>buy cialis onlinehttp://www.freewebsitetemplates.com/forum/member.php?u=31311";>buy cialishttp://www.conceptart.org/forums/member.php?u=98247";>buy propeciahttp://www.dcresource.com/forums/member.php?u=29167";>Zithromaxhttp://www.gamecareerguide.com/forums/member.php?u=2561";>buy viagrahttp://forum.springframework.org/member.php?u=34397";>buy valiumhttp://forums.ipodhacks.com/member.php?u=35372";>buy tramadolhttp://forum.springframework.org/member.php?u=35065";>generic viagrahttp://xxanax.forum5.com/";>buy xanax online' 9. Data (e.g. sane-find-scanner -v -v): ''
[sane-devel] [RFC] how to enable 1.1 features
On Thu, 28 Feb 2008 08:43:26 +0900 Olaf Meeuwissen wrote: > Alessandro Zummo writes: > > > please see the attached patch regarding my proposal > > for a safe enabling of 1.1 features in the backends. > > Hmm, the SANE Standard Version 1.03 says about SANE_VERSION_CODE(): > > Note that the major version number alone determines whether a > frontend/backend pair is compatible. The minor version and the > build revision are used for informational and bug-fixing purposes > only. > > This means that a backend implementer is free to pass back something > like > > SANE_VERSION_CODE(1,2,3) > > for a SANE 1.0 backend. Isn't that a bit confusing? I think that > just changing the name of the macro to something like SANE_API_LEVEL > would improve code readability and reduce confusion. yes, SANE_API_LEVEL sounds better. The 1.1 standar will have to mention this. > > The same SANE Standard Version 1.03 does not explicitly state what a > backend is supposed to return when passed and unknown action. I'd > assume that any sane developer would return SANE_STATUS_UNSUPPORTED > but I wouldn't quite bet on it. neither do I, that's why I will be checking every backend. UNSUPPORTED would be fine but any error would do. The 1.1 standard will mention that too. > Another issue I have with the SANE_ACTION_COMPAT_LEVEL symbol is that > I don't think of that as an action. A symbol more action-like, like > SANE_ACTION_CHECK_API_LEVEL for example, is clearer IMHO. ack. > Apart from the above (and the fact that it is an ugly hack as SANE 1.0 > surely didn't intend to provide for API major/minor versions ;-), the > above would work fine in practice. We all noticed that SANE 1.0 missed some things.. that's the reason we are still discussing all of that 10 years after :-D -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Agfa Snapscan Touch, X-Sane 0.991, Ubuntu Gutsy Gibbon
Hi. I am trying to get an Agfa Snapscan Touch to work with X-Sane 0.991 on Ubuntu Gutsy Gibbon. I have followed the info at https://help.ubuntu.com/community/ScanningHowTo under Manually installing a scanner. The niash line is already uncommented. I have restarted Gnome but Xsane still cannot find the device. Unfortunately I am a newbie and I am rather bewildered by the various documentation at http://tldp.org/HOWTO/Scanner-HOWTO/index.html and http://bertrik.sikken.nl/hp3300c/README.html. Can anyone help me please? Thanks. Regards Jonathan -- Jonathan Ellis 55 Hindes Road Harrow HA1 1SQ Email: Jonathan at GetMyLicence.co.uk Phone: 020 8861 2229 Mobile: 07981 258433 -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080228/444bab60/attachment.htm
[sane-devel] saned/xinetd
what user did you use with saned -d?
and this post comes to mind-
http://lists.alioth.debian.org/pipermail/sane-devel/2002-September/004235.html
allan
2008/2/27 Gregg Garza :
> Sorry if this is not the right place to send this kind of problem.
>
> I have a small network of computers at home. I just got an Epson V200
> scanner and have been mostly successful in getting it running with "iscan"
> and "xsane" frontends (using the avasys proprietary driver and plugin). I
> can run the scanner from my athlon (32 bit) under ubuntu hardy locally and I
> can access it over the network from any of my other computers using saned.
>
> If I connect the scanner directly to my amd64-x2 running ubuntu hardy (64) I
> can scan locally with "iscan" or "xsane" frontends (using the avasys
> proprietary driver and plugin) and using "libsane and sane-utils" for i386
> (dpkg -i --force-all).
>
> Now, if I run saned -d on the amd64-x2 I can connect from my other machines
> and run "iscan" or "xsane" frontends. Here is the output from the amd64-2
> in this situation
>
>
> gregg at g2-xubuntu:/etc/init.d$ scanimage -L
> [sanei_debug] Setting debug level of dll to 0.
> [sanei_debug] Setting debug level of net to 128.
> [net] sane_init: authorize = 0x804ae30, version_code = 0xff962508
> [net] sane_init: SANE net backend version 1.0.14 (AF-indep+IPv6) from
> sane-backends 1.0.18-cvs
> [net] sane_init: Client has little endian byte order
> [net] sane_init: searching for config file
> [net] sane_init: trying to add 192.168.1.25
> [net] add_device: adding backend 192.168.1.25
> [net] add_device: backend 192.168.1.25 added
> [net] sane_init: done reading config
> [net] sane_init: evaluating environment variable SANE_NET_HOSTS
> [net] sane_init: evaluating environment variable SANE_NET_TIMEOUT
> [net] sane_init: done
> [net] sane_get_devices: local_only = 0
> [net] connect_dev: trying to connect to 192.168.1.25
> [net] connect_dev: [0] connection succeeded (IPv4)
> [net] connect_dev: sanei_w_init
> [net] connect_dev: net_init (user=gregg, local version=1.0.3)
> [net] connect_dev: freeing init reply (status=Success, remote version=1.0.3)
> [net] connect_dev: done
> [net] sane_get_devices: got 192.168.1.25:epkowa:libusb:001:002
> [net] sane_get_devices: finished (1 devices)
> device `epkowa:libusb:001:002' is a Epson Perfection V200 flatbed scanner
> device `net:192.168.1.25:epkowa:libusb:001:002' is a Epson Perfection V200
> flatbed scanner
> [net] sane_exit: exiting
> [net] sane_exit: closing dev 0x8065748, ctl=3
> [net] sane_exit: finished.
>
>
>
> Great! The epkowa and net devices are listed as you can see.
>
>
> Now if I start xinetd and try again, this is what I get.
>
>
> %%%
> gregg at g2-xubuntu:/etc/init.d$ scanimage -L
> [sanei_debug] Setting debug level of dll to 0.
> [sanei_debug] Setting debug level of net to 128.
> [net] sane_init: authorize = 0x804ae30, version_code = 0xffb67f18
> [net] sane_init: SANE net backend version 1.0.14 (AF-indep+IPv6) from
> sane-backends 1.0.18-cvs
> [net] sane_init: Client has little endian byte order
> [net] sane_init: searching for config file
> [net] sane_init: trying to add 192.168.1.25
> [net] add_device: adding backend 192.168.1.25
> [net] add_device: backend 192.168.1.25 added
> [net] sane_init: done reading config
> [net] sane_init: evaluating environment variable SANE_NET_HOSTS
> [net] sane_init: evaluating environment variable SANE_NET_TIMEOUT
> [net] sane_init: done
> [net] sane_get_devices: local_only = 0
> [net] connect_dev: trying to connect to 192.168.1.25
> [net] connect_dev: [0] connection succeeded (IPv4)
> [net] connect_dev: sanei_w_init
> [net] connect_dev: net_init (user=gregg, local version=1.0.3)
> [net] connect_dev: freeing init reply (status=Unknown SANE status code
> 1667329132, remote version=105.110.26400)
> [net] connect_dev: access to 192.168.1.25 denied
> [net] connect_dev: closing connection to 192.168.1.25
> [net] sane_get_devices: ignoring failure to connect to 192.168.1.25
> [net] sane_get_devices: finished (0 devices)
> device `epkowa:libusb:001:002' is a Epson Perfection V200 flatbed scanner
> [net] sane_exit: exiting
> [net] sane_exit: closing dev 0x8065748, ctl=-1
> [net] sane_exit: finished.
>
>
> %%%
>
> [net] connect_dev: freeing init reply (status=Unknown SANE status code
> 1667329132, remote version=105.110.26400)
>
> This doesn't look good to me. I am guessing this is a problem with my
> xinetd.conf setup, permissions, or something like that and not actually a
> problem with saned. Am I on the right path?
>
> This is my xinetd.conf
>
> # Simple configuration file for xinetd
> #
> # Some defaults, and include /etc/xinetd.d/
>
> defaults
> {
>
> # Please note that you need a log_type line to be able to use log_on_success
> # and log_on_failure. The default is the following :
> # log_type = SYSLOG daemon
[sane-devel] [RFC] how to enable 1.1 features
On Thu, Feb 28, 2008 at 4:29 AM, Alessandro Zummo wrote: > On Thu, 28 Feb 2008 08:43:26 +0900 > Olaf Meeuwissen wrote: > > > Alessandro Zummo writes: > > > > > please see the attached patch regarding my proposal > > > for a safe enabling of 1.1 features in the backends. > > > in the fujitsu backend, i previously had added a 'compression' option with the description warning of possible front-end incompatibility, and the default setting to not compress. i feel this is sufficient, because it requires no changes at all to a well-written frontend. but, if you really want to protect this behaviour by requiring 'behind-the-scenes' frontend action, i would rather see a well-known option with its caps flags set to make them invisible. i think extending that flag (if required) is safer than adding macros or extending enums, because '==' tests are done on the caps instead of switch/case statements. i would also rather see this well-known option be named by the feature it implements, instead of a version name. By that means, a backend can add support for something particular, and a frontend can enable something particular. allan -- "The truth is an offense, but not a sin"
[sane-devel] Agfa Snapscan Touch, X-Sane 0.991, Ubuntu Gutsy Gibbon
have you tried running scanimage -L as root, just to cut out any permissions problems? allan 2008/2/28 Jonathan Ellis : > > Hi. > I am trying to get an Agfa Snapscan Touch to work with X-Sane 0.991 on > Ubuntu Gutsy Gibbon. > I have followed the info at https://help.ubuntu.com/community/ScanningHowTo > under Manually installing a scanner. The niash line is already uncommented. > I have restarted Gnome but Xsane still cannot find the device. > > Unfortunately I am a newbie and I am rather bewildered by the various > documentation at http://tldp.org/HOWTO/Scanner-HOWTO/index.html and > http://bertrik.sikken.nl/hp3300c/README.html. > Can anyone help me please? > > Thanks. > > Regards > Jonathan > > -- > Jonathan Ellis > 55 Hindes Road > Harrow > HA1 1SQ > Email: Jonathan at GetMyLicence.co.uk > Phone: 020 8861 2229 > Mobile: 07981 258433 > > > -- > sane-devel mailing list: sane-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-request at lists.alioth.debian.org > -- "The truth is an offense, but not a sin"
[sane-devel] [RFC] how to enable 1.1 features
Alessandro Zummo writes:
> please see the attached patch regarding my proposal
> for a safe enabling of 1.1 features in the backends.
>
> [snip]
> --- sane-backends.orig/include/sane/sane.h2008-02-26 00:07:40.0
> +0100
> +++ sane-backends/include/sane/sane.h 2008-02-26 00:19:29.0 +0100
> @@ -31,6 +31,8 @@ extern "C" {
> | (((SANE_Word) (minor) & 0xff) << 16) \
> | (((SANE_Word) (build) & 0x) << 0))
>
> +#define SANE_VERSION(major,minor) (SANE_VERSION_CODE(major, minor, 0))
> +
> #define SANE_VERSION_MAJOR(code) SANE_Word)(code)) >> 24) & 0xff)
> #define SANE_VERSION_MINOR(code) SANE_Word)(code)) >> 16) & 0xff)
> #define SANE_VERSION_BUILD(code) SANE_Word)(code)) >> 0) & 0x)
Hmm, the SANE Standard Version 1.03 says about SANE_VERSION_CODE():
Note that the major version number alone determines whether a
frontend/backend pair is compatible. The minor version and the
build revision are used for informational and bug-fixing purposes
only.
This means that a backend implementer is free to pass back something
like
SANE_VERSION_CODE(1,2,3)
for a SANE 1.0 backend. Isn't that a bit confusing? I think that
just changing the name of the macro to something like SANE_API_LEVEL
would improve code readability and reduce confusion.
> [snip]
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ sane-backends/doc/sane-11-frontends-howto.txt 2008-02-27
> 22:03:31.0 +0100
> @@ -0,0 +1,27 @@
> +A quick SANE 1.1 guide for frontend authors
> +===
> +
> +If, and only if, a frontend wants to enable 1.1 features
> +in a backed, the following procedure SHOULD be used:
> +
> +
> + SANE_Int sane_version;
> + sane_init(&sane_version, NULL);
> +
> + if (sane_version >= SANE_VERSION(1,1)) {
> + SANE_Int version = SANE_VERSION(1,1);
> + result = sane_control_option(handle, 0,
> SANE_ACTION_COMPAT_LEVEL,
> + &version);
> + }
> +
> +
> +If the backed returns SANE_STATUS_GOOD to that sane_control_option
> +call, the frontend knows that the backend correctly handles any
> +SANE 1.1 feature.
The same SANE Standard Version 1.03 does not explicitly state what a
backend is supposed to return when passed and unknown action. I'd
assume that any sane developer would return SANE_STATUS_UNSUPPORTED
but I wouldn't quite bet on it.
Another issue I have with the SANE_ACTION_COMPAT_LEVEL symbol is that
I don't think of that as an action. A symbol more action-like, like
SANE_ACTION_CHECK_API_LEVEL for example, is clearer IMHO.
Apart from the above (and the fact that it is an ugly hack as SANE 1.0
surely didn't intend to provide for API major/minor versions ;-), the
above would work fine in practice.
Hope this helps,
--
Olaf Meeuwissen FLOSS Engineer -- EPSON AVASYS Corporation
FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] Brother MFC-240c
thanks for the report, but i dont think it makes sense for us to
publish a udev rule for every device a vendor makes, and the IDs for
the 240c are already in sane 1.0.19.
allan
On 2/27/08, Amit Mittal wrote:
> # Brother MFC-240c
> SYSFS{idVendor}=="04f9",MODE="664",GROUP="scanner"
>
>
> Reference:
> http://solutions.brother.com/linux/sol/printer/linux/linux_faq.html#6
>
> --
> sane-devel mailing list:
> sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-request at lists.alioth.debian.org
>
--
"The truth is an offense, but not a sin"
