For some reason this rule stopped working:
KERNEL=="event*", SYSFS{manufacturer}="Logitech", SYSFS{product}="USB
Receiver", NAME="input/mx1000", MODE="0644"
Did stuff in /sys/ change? Do I need to change all my rules to make up
for this? udevs fault? I do have the correct /dev/input/event0 node.
Aaron Gyes
On Mon, Oct 17, 2005 at 09:35:13PM -0700, Aaron Gyes wrote:
> For some reason this rule stopped working:
>
> KERNEL=="event*", SYSFS{manufacturer}="Logitech", SYSFS{product}="USB
> Receiver", NAME="input/mx1000", MODE="0644"
>
> Did stuff in /sys/ change? Do I need to change all my rules to make up
> for this? udevs fault? I do have the correct /dev/input/event0 node.
You have that node? That's a good start :)
I think the "name" might have changed, it looks like I messed that up
somehow. What does:
udevinfo -p /sys/class/input/input0/event0/ -a
show (or whatever that sysfs path is.)
Oops, heh, that dies on my box too. Ok, I think that's the issue,
sorry. I'm working on it...
thanks,
greg k-h
On Mon, Oct 17, 2005 at 10:50:03PM -0700, Greg KH wrote:
> On Mon, Oct 17, 2005 at 09:35:13PM -0700, Aaron Gyes wrote:
> > For some reason this rule stopped working:
> >
> > KERNEL=="event*", SYSFS{manufacturer}="Logitech", SYSFS{product}="USB
> > Receiver", NAME="input/mx1000", MODE="0644"
> >
> > Did stuff in /sys/ change? Do I need to change all my rules to make up
> > for this? udevs fault? I do have the correct /dev/input/event0 node.
>
> You have that node? That's a good start :)
>
> I think the "name" might have changed, it looks like I messed that up
> somehow. What does:
> udevinfo -p /sys/class/input/input0/event0/ -a
>
> show (or whatever that sysfs path is.)
>
> Oops, heh, that dies on my box too. Ok, I think that's the issue,
> sorry. I'm working on it...
Can you try the patch below to see if that fixes the issue? That should
keep udevinfo from dieing.
thanks,
greg k-h
---
drivers/input/input.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- gregkh-2.6.orig/drivers/input/input.c
+++ gregkh-2.6/drivers/input/input.c
@@ -522,17 +522,22 @@ static ssize_t input_dev_show_##name(str
up(&input_dev->sem); \
\
return retval; \
-}
+} \
+static CLASS_DEVICE_ATTR(name, S_IRUGO, input_dev_show_##name, NULL);
INPUT_DEV_STRING_ATTR_SHOW(name);
INPUT_DEV_STRING_ATTR_SHOW(phys);
INPUT_DEV_STRING_ATTR_SHOW(uniq);
-static struct class_device_attribute input_dev_attrs[] = {
- __ATTR(name, S_IRUGO, input_dev_show_name, NULL),
- __ATTR(phys, S_IRUGO, input_dev_show_phys, NULL),
- __ATTR(uniq, S_IRUGO, input_dev_show_uniq, NULL),
- __ATTR_NULL
+static struct attribute *input_dev_attrs[] = {
+ &class_device_attr_name.attr,
+ &class_device_attr_phys.attr,
+ &class_device_attr_uniq.attr,
+ NULL
+};
+
+static struct attribute_group input_dev_group = {
+ .attrs = input_dev_attrs,
};
#define INPUT_DEV_ID_ATTR(name) \
@@ -694,7 +699,6 @@ struct class input_class = {
.name = "input",
.release = input_dev_release,
.hotplug = input_dev_hotplug,
- .class_dev_attrs = input_dev_attrs,
};
struct input_dev *input_allocate_device(void)
@@ -732,6 +736,7 @@ static void input_register_classdevice(s
kfree(path);
class_device_add(&dev->cdev);
+ sysfs_create_group(&dev->cdev.kobj, &input_dev_group);
sysfs_create_group(&dev->cdev.kobj, &input_dev_id_attr_group);
sysfs_create_group(&dev->cdev.kobj, &input_dev_caps_attr_group);
}
Greg KH <[email protected]> disait dernièrement que :
> On Mon, Oct 17, 2005 at 10:50:03PM -0700, Greg KH wrote:
>> On Mon, Oct 17, 2005 at 09:35:13PM -0700, Aaron Gyes wrote:
>> > For some reason this rule stopped working:
>> >
>> > KERNEL=="event*", SYSFS{manufacturer}="Logitech", SYSFS{product}="USB
>> > Receiver", NAME="input/mx1000", MODE="0644"
>> >
>> > Did stuff in /sys/ change? Do I need to change all my rules to make up
>> > for this? udevs fault? I do have the correct /dev/input/event0 node.
>>
>> You have that node? That's a good start :)
>>
>> I think the "name" might have changed, it looks like I messed that up
>> somehow. What does:
>> udevinfo -p /sys/class/input/input0/event0/ -a
>>
>> show (or whatever that sysfs path is.)
>>
>> Oops, heh, that dies on my box too. Ok, I think that's the issue,
>> sorry. I'm working on it...
>
> Can you try the patch below to see if that fixes the issue? That should
> keep udevinfo from dieing.
huh, it doesn't apply to 2.6.14-rc4-mm1....
for which tree is it exactly ?
patching file drivers/input/input.c
Hunk #1 succeeded at 641 (offset 119 lines).
Hunk #2 FAILED at 818.
Hunk #3 succeeded at 769 (offset 33 lines).
1 out of 3 hunks FAILED -- saving rejects to file drivers/input/input.c.rej
best regards,
--
Mathieu
On Tue, Oct 18, 2005 at 10:31:44AM +0200, Mathieu Segaud wrote:
> Greg KH <[email protected]> disait derni??rement que :
>
> > On Mon, Oct 17, 2005 at 10:50:03PM -0700, Greg KH wrote:
> >> On Mon, Oct 17, 2005 at 09:35:13PM -0700, Aaron Gyes wrote:
> >> > For some reason this rule stopped working:
> >> >
> >> > KERNEL=="event*", SYSFS{manufacturer}="Logitech", SYSFS{product}="USB
> >> > Receiver", NAME="input/mx1000", MODE="0644"
> >> >
> >> > Did stuff in /sys/ change? Do I need to change all my rules to make up
> >> > for this? udevs fault? I do have the correct /dev/input/event0 node.
> >>
> >> You have that node? That's a good start :)
> >>
> >> I think the "name" might have changed, it looks like I messed that up
> >> somehow. What does:
> >> udevinfo -p /sys/class/input/input0/event0/ -a
> >>
> >> show (or whatever that sysfs path is.)
> >>
> >> Oops, heh, that dies on my box too. Ok, I think that's the issue,
> >> sorry. I'm working on it...
> >
> > Can you try the patch below to see if that fixes the issue? That should
> > keep udevinfo from dieing.
>
> huh, it doesn't apply to 2.6.14-rc4-mm1....
> for which tree is it exactly ?
>
> patching file drivers/input/input.c
> Hunk #1 succeeded at 641 (offset 119 lines).
> Hunk #2 FAILED at 818.
> Hunk #3 succeeded at 769 (offset 33 lines).
> 1 out of 3 hunks FAILED -- saving rejects to file drivers/input/input.c.rej
I was against my latest tree, which is on kernel.org. Someone already
posted an updated patch on lkml if you can't get that second hunk to
apply.
thanks,
greg k-h
On Tue, 2005-10-18 at 20:44 -0700, Greg KH wrote:
> I was against my latest tree, which is on kernel.org. Someone already
> posted an updated patch on lkml if you can't get that second hunk to
> apply.
I applied that, and I still don't see the node being created.
Here's the udevinfo output you originally asked for:
floam@agorastome ~ $ udevinfo -p /sys/class/input/event0/ -a
udevinfo starts with the device the node belongs to and then walks up
the
device chain, to print for every device found, all possibly useful
attributes
in the udev key format.
Only attributes within one device section may be used together in one
rule,
to match the device for which the node will be created.
device '/sys/class/input/event0' has major:minor 13:64
looking at class device '/sys/class/input/event0':
KERNEL=="event0"
SUBSYSTEM=="input"
SYSFS{dev}=="13:64"
Greg KH <[email protected]> disait dernièrement que :
> On Tue, Oct 18, 2005 at 10:31:44AM +0200, Mathieu Segaud wrote:
>> Greg KH <[email protected]> disait derni??rement que :
>>
>> > On Mon, Oct 17, 2005 at 10:50:03PM -0700, Greg KH wrote:
>> >> On Mon, Oct 17, 2005 at 09:35:13PM -0700, Aaron Gyes wrote:
>> >> > For some reason this rule stopped working:
>> >> >
>> >> > KERNEL=="event*", SYSFS{manufacturer}="Logitech", SYSFS{product}="USB
>> >> > Receiver", NAME="input/mx1000", MODE="0644"
>> >> >
>> >> > Did stuff in /sys/ change? Do I need to change all my rules to make up
>> >> > for this? udevs fault? I do have the correct /dev/input/event0 node.
>> >>
>> >> You have that node? That's a good start :)
>> >>
>> >> I think the "name" might have changed, it looks like I messed that up
>> >> somehow. What does:
>> >> udevinfo -p /sys/class/input/input0/event0/ -a
>> >>
>> >> show (or whatever that sysfs path is.)
>> >>
>> >> Oops, heh, that dies on my box too. Ok, I think that's the issue,
>> >> sorry. I'm working on it...
>> >
>> > Can you try the patch below to see if that fixes the issue? That should
>> > keep udevinfo from dieing.
>>
>> huh, it doesn't apply to 2.6.14-rc4-mm1....
>> for which tree is it exactly ?
>>
>> patching file drivers/input/input.c
>> Hunk #1 succeeded at 641 (offset 119 lines).
>> Hunk #2 FAILED at 818.
>> Hunk #3 succeeded at 769 (offset 33 lines).
>> 1 out of 3 hunks FAILED -- saving rejects to file drivers/input/input.c.rej
>
> I was against my latest tree, which is on kernel.org. Someone already
> posted an updated patch on lkml if you can't get that second hunk to
> apply.
I made it apply :)
thanks, I was just wondering if some bot had put an email into the
chaos-bin. It solved the problems with udevinfo as expected. Thanks a
lot.
--
Mathieu
On Tue, Oct 18, 2005 at 11:00:08PM -0700, Aaron Gyes wrote:
> On Tue, 2005-10-18 at 20:44 -0700, Greg KH wrote:
> > I was against my latest tree, which is on kernel.org. Someone already
> > posted an updated patch on lkml if you can't get that second hunk to
> > apply.
>
> I applied that, and I still don't see the node being created.
Yeah, sorry.
You need a udev update. 071 has been released which should fix this
problem (fixes it for me.) Can you try that out?
thanks,
greg k-h
On Wed, 2005-10-19 at 16:44 -0700, Greg KH wrote:
> You need a udev update. 071 has been released which should fix this
> problem (fixes it for me.) Can you try that out?
>
> thanks,
>
> greg k-h
Excuse my igorance, but for the life of me I can't find udev 071.
Obviously it exists somewhere since my distribution (x86_64 Gentoo)
seems to have a package for it, but it's failing to be able to grab it,
and I'm unable to find a tarball anywhere at kernel.org
Aaron Gyes
On Wed, Oct 19, 2005 at 08:34:11PM -0700, Aaron Gyes wrote:
> On Wed, 2005-10-19 at 16:44 -0700, Greg KH wrote:
> > You need a udev update. 071 has been released which should fix this
> > problem (fixes it for me.) Can you try that out?
> >
> > thanks,
> >
> > greg k-h
>
> Excuse my igorance, but for the life of me I can't find udev 071.
> Obviously it exists somewhere since my distribution (x86_64 Gentoo)
> seems to have a package for it, but it's failing to be able to grab it,
> and I'm unable to find a tarball anywhere at kernel.org
It looks like the kernel.org mirror system got stuck again, the tarball
is sitting on the upload server, but hasn't been mirrored out to the
public side yet. Give it a few hours...
thanks,
greg k-h