[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 19 17:40 Richard Ryniker wrote (shortened): > Udev rules are never likely to be a "stable interface". Hardware > devices and connection mechanisms change over time, therefore new and > different information will be produced I forgot to mention that it is always possible to add new

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Udev rules are never likely to be a "stable interface". Hardware devices and connection mechanisms change over time, therefore new and different information will be produced; the events recognized and reported may change as the kernel's structure evolves; additional function in the applications th

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 18 13:35 Richard Ryniker wrote (shortened): > The syscall interface is how applications request kernel services. > It is not a general mechanism for the kernel to start userspace > applications. I did not mean only the particular "syscall interface". I mean the general idea behind

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Johannes Meixner wrote: > On Nov 18 09:20 Alesh Slovak wrote (shortened): >> But like I said, I really don't care who is the cause >> of this problem, I just want to see if we can fix it somehow. > > If you don't care who is the cause of this problem, > you cannot fix the problem and actually your

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Julien BLACHE wrote: > If we really want to do that, then we must agree on a location for those > files and we need to ship a wrapper script that will rebuild the rules > from the desc files. > > This is how it'll work: > - third party backend package is installed > -> calls update-sane-udev

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Johannes Meixner wrote: Hi, > the syscall interface for udev is not stable > which is udev's fault, I'm not sure netlink qualifies as a syscall interface, so it may very well escape Greg KH's law of stable APIs. *g* JB. -- Julien BLACHE

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Alesh Slovak wrote: Hi, > Ah, good point. But the rules will need to be regenerated when a SANE > upgrade contains changes to the generation tool, which means the third > party .desc files from which the rules are generated need to be > someplace where SANE can find them. We could use an environ

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

The syscall interface is how applications request kernel services. It is not a general mechanism for the kernel to start userspace applications. HAL and udev are mechanisms intended to give the kernel a flexible way to invoke userspace applications when events such as "hardware device connection"

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 17 18:53 Julien BLACHE wrote (shortened): > Johannes Meixner wrote: > >>> That was a change in the USB layer in the kernel that needed a >>> new/modified udev rule to create the device nodes. >> >> Perhaps you misunderstood me. >> I meant it as an example to show which awkward work

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

m. allan noah wrote: > uhg- I don't like that idea. I think it should be possible to place > these third-party rules files someplace that they won't get wiped out > by a sane-backends upgrade, rather than having to append some magic > someplace to call a script. Ah, good point. But the rules will n

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 18 09:20 Alesh Slovak wrote (shortened): > But like I said, I really don't care who is the cause > of this problem, I just want to see if we can fix it somehow. If you don't care who is the cause of this problem, you cannot fix the problem and actually your proposal does not fix th

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

OK, so this thread has sort of exploded. So the idea so far, is that we want to install the udev/HAL rules generation tool (with some possible modifications) along with all the .desc files. We also need to provide some standard location for third parties to place their .desc files, because the

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Julien BLACHE wrote: > However, when it comes to udev rules, care must be taken with the LABELs > inside the rules file. The LABELs must not be repeated from one file to > another; failing that, chaos will ensue. (that may make a machine > unbootable until all duplicate LABELs are removed ... been

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Johannes Meixner wrote: > As far as I understand udev (and HAL and how all this stuff is > called nowadays) it seems you are wrong when you think it is > the distros which introduce all this never ending mess > of incompatible changes. From my point of view it was the distros that kept changin

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

"m. allan noah" wrote: > I am aware. That is why I asked if it is possible for this smaller, > third-party files to avoid it. Yes, sorry for that. Complete answer this time around ;) Yes it's possible, if they're short enough. It's really an optimization in our rules file because it's so big.

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

On Tue, Nov 17, 2009 at 7:53 PM, Alesh Slovak wrote: > OK, so this thread has sort of exploded. yes- there is a bit of frustration here :) > So the idea so far, is that we want to install the udev/HAL rules generation > tool (with some possible modifications) along with all the .desc files. > >

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

"m. allan noah" wrote: > Ouch. I don't want us to do anything like that. I wonder if it will be > possible for the 'third party' files to avoid using LABEL? We use LABELs already. JB. -- Julien BLACHE

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Johannes Meixner wrote: Hi, >> That was a change in the USB layer in the kernel that needed a >> new/modified udev rule to create the device nodes. > > Perhaps you misunderstood me. > I meant it as an example to show which awkward workarounds are needed > to make this thingy hopefully work for a

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

"m. allan noah" wrote: Hi, > question- If the distro is already producing a modified version of our > tool to turn .desc files into whatever format is required, can we not > install that tool as part of sane? And, can we not modify it such that > it can take arguments to find the .desc file? The

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 17 08:42 m. allan noah wrote (shortened): > On Tue, Nov 17, 2009 at 6:42 AM, Julien BLACHE wrote: >> Johannes Meixner wrote: >> >>> What the heck has udev libsane.rules to do >>> with a particular kernel minor version number? >> >> That was a change in the USB layer in the kernel

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 17 12:42 Julien BLACHE wrote (shortened): > Johannes Meixner wrote: > >> What the heck has udev libsane.rules to do >> with a particular kernel minor version number? > > That was a change in the USB layer in the kernel that needed a > new/modified udev rule to create the device nod

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

On Tue, Nov 17, 2009 at 1:47 PM, Julien BLACHE wrote: > "m. allan noah" wrote: > >> Ouch. I don't want us to do anything like that. I wonder if it will be >> possible for the 'third party' files to avoid using LABEL? > > We use LABELs already. I am aware. That is why I asked if it is possible fo

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

On Tue, Nov 17, 2009 at 12:46 PM, Julien BLACHE wrote: > "m. allan noah" wrote: > > Hi, > >> question- If the distro is already producing a modified version of our >> tool to turn .desc files into whatever format is required, can we not >> install that tool as part of sane? And, can we not modify

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Johannes Meixner wrote: Hi, > What the heck has udev libsane.rules to do > with a particular kernel minor version number? That was a change in the USB layer in the kernel that needed a new/modified udev rule to create the device nodes. Now remember that the same people that brought you that un

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Alesh Slovak wrote: > that there is a reason many third party SANE backend providers screw > up when it comes to scanner permissions. I am not trying to blame Yup, and we all know what those reasons are: - developers that know zilch about UNIX development - developers that know zilch about int

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hello, On Nov 16 08:53 Alesh Slovak wrote (shortened): > ... distro policy ... udev rules ... ... > We can't use a static rules file because each distro > uses slightly different syntax. ... > ... changes distros themselves keep making to their udev rules ... ... > ... breakage nearly every time

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Julien BLACHE wrote: > Alesh Slovak wrote: >> We can't use a static rules file because each distro uses slightly >> different syntax. And even then, we can't keep up with all the changes >> distros themselves keep making to their udev rules files resulting in >> breakage nearly every time a new ve

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

On Tue, Nov 17, 2009 at 6:42 AM, Julien BLACHE wrote: > Johannes Meixner wrote: > > Hi, > >> What the heck has udev libsane.rules to do >> with a particular kernel minor version number? > > That was a change in the USB layer in the kernel that needed a > new/modified udev rule to create the devic

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

m. allan noah wrote: > I was under the impression that certain scanners also required > proprietary plugins, but that is irrelevant to this discussion. Yes. > well, its more than just udev, it is also hal .fdi files too. but > certainly the distros could compile the script such that its default >

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Hi Allan, Thanks for your comments. m. allan noah wrote: >> We can't use a static rules file because each distro uses slightly different >> syntax. And even then, we can't keep up with all the changes distros >> themselves keep making to their udev rules files resulting in breakage >> nearly ever

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Alesh Slovak wrote: Hi, > We can't use a static rules file because each distro uses slightly > different syntax. And even then, we can't keep up with all the changes > distros themselves keep making to their udev rules files resulting in > breakage nearly every time a new version of a distro is

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

m. allan noah wrote: > agreed. I have just had the same discussion in the bug tracker with a > user of the proprietary brother backend. I think it is time that these > external drivers started providing their own proper installation, > instead of relying on us. Easy for you to say. In reality this

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

On Mon, Nov 16, 2009 at 12:04 AM, Alesh Slovak wrote: > Hi Allan, > > Thanks for your comments. > > m. allan noah wrote: >>> >>> We can't use a static rules file because each distro uses slightly >>> different >>> syntax. And even then, we can't keep up with all the changes distros >>> themselves

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

On Sun, Nov 15, 2009 at 6:53 PM, Alesh Slovak wrote: > m. allan noah wrote: >> >> agreed. I have just had the same discussion in the bug tracker with a >> user of the proprietary brother backend. I think it is time that these >> external drivers started providing their own proper installation, >>

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Ciprian Ciubotariu wrote: Hi, > ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3011", MODE="0664", > GROUP="scanner", ENV{libsane_matched}="yes" > > It's a printer-scanner combo. And, as such, it's supported by hplip which is not part of sane-backends, so we won't add this rule. It's up to hplip

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

Output of lsusb: Bus 003 Device 002: ID 03f0:3011 Hewlett-Packard PSC 1100 series So I have tried with... ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3011", MODE="0664", GROUP="scanner", ENV{libsane_matched}="yes" It's a printer-scanner combo.

[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

agreed. I have just had the same discussion in the bug tracker with a user of the proprietary brother backend. I think it is time that these external drivers started providing their own proper installation, instead of relying on us. allan On Sat, Nov 14, 2009 at 5:25 PM, Julien BLACHE wrote: > C