* index_mm_open: No such file or directory
From: Matt Burgess @ 2012-01-21 20:06 UTC (permalink / raw)
To: linux-hotplug
[reposted to fix linux-hotplug address, apologies!]
Hi all,
When running the following command...
for NIC in /sys/class/net/* ; do
INTERFACE=${NIC##*/} udevadm test --actiond $NIC
done
... I see the following output:
run_command: calling: test
adm_test: version 178
builtin_kmod_init: load module index
index_mm_open: No such file or directory
Now, the command actually runs successfully, and the persistent rules
file is correctly generated, but I'm left scratching my head as to what
file/directory is trying and failing to be read.
I've tried building both udev-178 and kmod-4 with '--enable-debug' but
still don't get any additional output. What am I missing?
Thanks,
Matt.
^ permalink raw reply
* Re: index_mm_open: No such file or directory
From: Lucas De Marchi @ 2012-01-21 20:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1327176371.1776.7.camel@kyoto.localdomain>
Hi Matt,
On Sat, Jan 21, 2012 at 5:55 PM, Matt Burgess
<matthew@linuxfromscratch.org> wrote:
> Hi all,
>
> When running the following command...
>
> for NIC in /sys/class/net/* ; do
> INTERFACE=${NIC##*/} udevadm test --actiond $NIC
> done
>
> ... I see the following output:
>
> run_command: calling: test
> adm_test: version 178
> builtin_kmod_init: load module index
> index_mm_open: No such file or directory
You are missing a ".bin" file at /lib/modules/$(uname -r)/. Do you
have all these 3 files below?
modules.alias.bin
modules.dep.bin
modules.symbols.bin
Yes, the message is a bit misleading, I have a patch pending for that
that will be part of kmod 5.
Thanks
Lucas De Marchi
^ permalink raw reply
* Re: index_mm_open: No such file or directory
From: Matt Burgess @ 2012-01-21 20:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1327176371.1776.7.camel@kyoto.localdomain>
On Sat, 2012-01-21 at 18:09 -0200, Lucas De Marchi wrote:
> Hi Matt,
>
> On Sat, Jan 21, 2012 at 5:55 PM, Matt Burgess
> <matthew@linuxfromscratch.org> wrote:
> > Hi all,
> >
> > When running the following command...
> >
> > for NIC in /sys/class/net/* ; do
> > INTERFACE=${NIC##*/} udevadm test --actiond $NIC
> > done
> >
> > ... I see the following output:
> >
> > run_command: calling: test
> > adm_test: version 178
> > builtin_kmod_init: load module index
> > index_mm_open: No such file or directory
>
> You are missing a ".bin" file at /lib/modules/$(uname -r)/. Do you
> have all these 3 files below?
>
> modules.alias.bin
> modules.dep.bin
> modules.symbols.bin
Ah, that explains it perfectly, thanks! The exact scenario here is that
I'm building udev/kmod in a chroot environment from a Fedora 16 host.
Fedora is running a kernel with a module directory
of /lib/modules/3.1.9-1.fc16.x86_64 but my chroot environment
contains /lib/modules/3.2.1. So, while both the host and my chroot
environment contain all 3 .bin files in their respective modules
directories, because those directories are between the 2 environments, I
see the message above. As it doesn't appear to have any impact on the
functionality I'm after here, I'm happy enough to leave it as-is. I'm
guessing though, that a symlink with the same name as the host's module
directory to the chroot environment directory would work around the
issue.
Regards,
Matt.
^ permalink raw reply
* Re: udev and existing /dev (devtmpfs)
From: William Hubbs @ 2012-01-21 22:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F15CB13.1000703@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
On Tue, Jan 17, 2012 at 08:25:07PM +0100, Piotr Karbowski wrote:
> Hi,
>
> After starting udev on the /dev which is devtmpfs the udev does not
> 'take over' already created nodes unless I add in the udev's init script
>
> 'udevadm trigger --type=devices --action=change'
>
> right after
>
> 'udevadm trigger --type=devices --action=add'
I had asked about this myself here (this is actually a gentoo bug report
and Piotr has now brought it to this list). I also researched the
systemd services and found that our inig script is using the correct
startup sequence to bring up udev. In other words, Piotr is using a
workaround which isn't the correct fix.
Can anyone point the right direction for getting this fixed?
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Udev loads wrong keymap
From: Tobias Frilling @ 2012-01-22 20:03 UTC (permalink / raw)
To: linux-hotplug
Since the upgrade from 175 to 178 udev does not load the correct keymap
file on my Samsung netbook.
Keys like BrightnessUp/Down and a bunch of others do not work.
The correct keymap is samsung-other and it should be loaded from
95-keymap.rules, line 141:
ENV{DMI_VENDOR}="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name
samsung-other"
$ cat /sys/class/dmi/id/{sys_vendor,product_name}
SAMSUNG ELECTRONICS CO., LTD.
N145P/N250P/N260P
Manual loading of the keymap (# /lib/udev/keymap -i input/event0
samsung-other) fixes the issue.
Other users reported similar bugs, see
https://bugs.archlinux.org/task/28049
^ permalink raw reply
* Udev loads wrong keymap
From: Tobias Frilling @ 2012-01-22 20:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Since the upgrade from 175 to 178 udev does not load the correct keymap
file on my Samsung netbook.
Keys like BrightnessUp/Down and a bunch of others do not work.
The correct keymap is samsung-other and it should be loaded from
95-keymap.rules, line 141:
ENV{DMI_VENDOR}="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name
samsung-other"
$ cat /sys/class/dmi/id/{sys_vendor,product_name}
SAMSUNG ELECTRONICS CO., LTD.
N145P/N250P/N260P
Manual loading of the keymap (# /lib/udev/keymap -i input/event0
samsung-other) fixes the issue.
Other users reported similar bugs, see
https://bugs.archlinux.org/task/28049
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPHGutAAoJEEDINPnaM7l+TUwH/3ugfyTQaqddHfNjE7K5+Yr0
4F2ZwORtGvdXGKtTWZNIj1lMuWxMpr4oNID9XScGYnIeaJnwokeeiIXpogZgTea3
EufWGpB9TTLKMHIUqlqmkuM4Thl+b8z5++xyf6O85mvDwfiwq9RSOx7XtXRf6cgq
TrZ6pUWdLBcvsvcr8w6K1p7zaF86L9ZogAGxTDRR9owaly+61G5AgEhQ44HxUsK2
satti7kJX8NWyyBm7Uq8tLnHTAoOidZrr918WjJdl7JCHlc5aiT3T54f+GKZWcwm
y1ssI79U0+WZy8qGAN4P0MjcPr/QBzH7MbRgScbbz60kaj5CyP/vEQtB9pvsCHA=9ZTt
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Udev loads wrong keymap
From: Kay Sievers @ 2012-01-22 20:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
<tobias@frilling-online.de> wrote:
> Since the upgrade from 175 to 178 udev does not load the correct keymap
> file on my Samsung netbook.
> Keys like BrightnessUp/Down and a bunch of others do not work.
>
> The correct keymap is samsung-other and it should be loaded from
> 95-keymap.rules, line 141:
> ENV{DMI_VENDOR}="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name
> samsung-other"
>
> $ cat /sys/class/dmi/id/{sys_vendor,product_name}
> SAMSUNG ELECTRONICS CO., LTD.
> N145P/N250P/N260P
>
> Manual loading of the keymap (# /lib/udev/keymap -i input/event0
> samsung-other) fixes the issue.
>
> Other users reported similar bugs, see
> https://bugs.archlinux.org/task/28049
What does:
$ udevadm test /sys/class/dmi/id
say?
Kay
^ permalink raw reply
* Re: Udev loads wrong keymap
From: Kay Sievers @ 2012-01-22 20:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
On Sun, Jan 22, 2012 at 21:08, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
> <tobias@frilling-online.de> wrote:
>> Since the upgrade from 175 to 178 udev does not load the correct keymap
>> file on my Samsung netbook.
>> Keys like BrightnessUp/Down and a bunch of others do not work.
>>
>> The correct keymap is samsung-other and it should be loaded from
>> 95-keymap.rules, line 141:
>> ENV{DMI_VENDOR}="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name
>> samsung-other"
>>
>> $ cat /sys/class/dmi/id/{sys_vendor,product_name}
>> SAMSUNG ELECTRONICS CO., LTD.
>> N145P/N250P/N260P
>>
>> Manual loading of the keymap (# /lib/udev/keymap -i input/event0
>> samsung-other) fixes the issue.
>>
>> Other users reported similar bugs, see
>> https://bugs.archlinux.org/task/28049
>
> What does:
> Â $ udevadm test /sys/class/dmi/id
> say?
And find the keyboard number X:
$ grep . /sys/class/input/input*/name
and run:
$ udevadm test /sys/class/input/eventX
Kay
^ permalink raw reply
* Re: udev and existing /dev (devtmpfs)
From: Kay Sievers @ 2012-01-22 20:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F15CB13.1000703@gmail.com>
On Sat, Jan 21, 2012 at 23:44, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 08:25:07PM +0100, Piotr Karbowski wrote:
>> After starting udev on the /dev which is devtmpfs the udev does not
>> 'take over' already created nodes unless I add in the udev's init script
>>
>> 'udevadm trigger --typefivices --action=change'
>>
>>     right after
>>
>> 'udevadm trigger --typefivices --action≠d'
>
> I had asked about this myself here (this is actually a gentoo bug report
> and Piotr has now brought it to this list). I also researched the
> systemd services and found that our inig script is using the correct
> startup sequence to bring up udev. In other words, Piotr is using a
> workaround which isn't the correct fix.
>
> Can anyone point the right direction for getting this fixed?
I guess it's some Gentoo-specific bug. Almost everybody just does:
'udevadm trigger --typefivices --action≠d'
once at bootup and nothing else.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Udev loads wrong keymap
From: Kay Sievers @ 2012-01-22 20:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1617 bytes --]
On Sun, Jan 22, 2012 at 21:37, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 22, 2012 at 21:08, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
>> <tobias@frilling-online.de> wrote:
>>> Since the upgrade from 175 to 178 udev does not load the correct keymap
>>> file on my Samsung netbook.
>>> Keys like BrightnessUp/Down and a bunch of others do not work.
>>>
>>> The correct keymap is samsung-other and it should be loaded from
>>> 95-keymap.rules, line 141:
>>> ENV{DMI_VENDOR}="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name
>>> samsung-other"
>>>
>>> $ cat /sys/class/dmi/id/{sys_vendor,product_name}
>>> SAMSUNG ELECTRONICS CO., LTD.
>>> N145P/N250P/N260P
>>>
>>> Manual loading of the keymap (# /lib/udev/keymap -i input/event0
>>> samsung-other) fixes the issue.
>>>
>>> Other users reported similar bugs, see
>>> https://bugs.archlinux.org/task/28049
>>
>> What does:
>> Â $ udevadm test /sys/class/dmi/id
>> say?
>
> And find the keyboard number X:
> Â $ grep . /sys/class/input/input*/name
>
> and run:
> Â $ Â udevadm test /sys/class/input/eventX
The test run shows that it would execute the keymap tool:
udev_rules_apply_to_event: RUN 'keymap $name samsung-other'
/lib/udev/rules.d/95-keymap.rules:141
...
USEC_INITIALIZED99737
run: 'keymap event0 samsung-other'
If you run '/lib/udev/keymap event0 samsung-other', does it work?
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Udev loads wrong keymap
From: Kay Sievers @ 2012-01-23 4:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 1912 bytes --]
On Sun, Jan 22, 2012 at 21:49, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 22, 2012 at 21:37, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Sun, Jan 22, 2012 at 21:08, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>> On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
>>> <tobias@frilling-online.de> wrote:
>>>> Since the upgrade from 175 to 178 udev does not load the correct keymap
>>>> file on my Samsung netbook.
>>>> Keys like BrightnessUp/Down and a bunch of others do not work.
>>>>
>>>> The correct keymap is samsung-other and it should be loaded from
>>>> 95-keymap.rules, line 141:
>>>> ENV{DMI_VENDOR}="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name
>>>> samsung-other"
>>>>
>>>> $ cat /sys/class/dmi/id/{sys_vendor,product_name}
>>>> SAMSUNG ELECTRONICS CO., LTD.
>>>> N145P/N250P/N260P
>>>>
>>>> Manual loading of the keymap (# /lib/udev/keymap -i input/event0
>>>> samsung-other) fixes the issue.
>>>>
>>>> Other users reported similar bugs, see
>>>> https://bugs.archlinux.org/task/28049
>>>
>>> What does:
>>> Â $ udevadm test /sys/class/dmi/id
>>> say?
>>
>> And find the keyboard number X:
>> Â $ grep . /sys/class/input/input*/name
>>
>> and run:
>> Â $ Â udevadm test /sys/class/input/eventX
>
> The test run shows that it would execute the keymap tool:
>
> Â udev_rules_apply_to_event: RUN 'keymap $name samsung-other'
> Â Â /lib/udev/rules.d/95-keymap.rules:141
> Â ...
> Â USEC_INITIALIZED99737
> Â run: 'keymap event0 samsung-other'
>
> If you run '/lib/udev/keymap event0 samsung-other', does it work?
We used the sysfs device name for $name substitutions, which does not
work correctly for device nodes which are in a subdirectory.
This but got exposed by other recent changes, and this should fix it:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h°a00806770a7443d1710d58190a65b4f9f4f60e
Thanks,
Kay
^ permalink raw reply
* Re: udev and existing /dev (devtmpfs)
From: Gabor Z. Papp @ 2012-01-23 16:41 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F15CB13.1000703@gmail.com>
* Kay Sievers <kay.sievers@vrfy.org>:
| I guess it's some Gentoo-specific bug. Almost everybody just does:
| 'udevadm trigger --typefivices --action≠d'
| once at bootup and nothing else.
udevadm trigger && udevadm settle
isn't anymore the suggested command after udevd --daemon?
As I see from the man page, trigger's default action is change, not add.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: udev and existing /dev (devtmpfs)
From: Kay Sievers @ 2012-01-23 17:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F15CB13.1000703@gmail.com>
On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp <gzp@papp.hu> wrote:
> * Kay Sievers <kay.sievers@vrfy.org>:
>
> | I guess it's some Gentoo-specific bug. Almost everybody just does:
> | Â Â 'udevadm trigger --typeÞvices --actiond'
> | once at bootup and nothing else.
>
> udevadm trigger && udevadm settle
> isn't anymore the suggested command after udevd --daemon?
It was always 'add' which was suggested. It was the default action,
but it was changed to 'change' because 'add' must not be used anywhere
else than once after bootup.
Triggering 'change' has some valid use cases, not many though, and
most of them are workarounds for broken things.
Settle is only needed to block until broken subsystems catch up with
reality during bootup, and with reality how hotplug systems work
today. It is not pulled-in for systems which do not run broken or
legacy tools.
> As I see from the man page, trigger's default action is change, not add.
Yes, that changed May 2010 with udev 154.
Kay
^ permalink raw reply
* Udev loads wrong keymap
From: ajaxas @ 2012-01-24 13:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
Good evening!
I'm sorry this mail is out of thread, I just subscribed so I can't reply.
There are people (including me) who report that fix doesn't solve the
problem: brightness keys on many laptops still don't work with the GIT
version of udev.
I will describe my problem down here, but it might be easier to read
my post on archlinux forums:
https://bbs.archlinux.org/viewtopic.php?pid\x1046260
-----
My specs:
Hardware: SONY VAIO VPC-EH2L1R
Linux distribution: archlinux, XFCE
udev versions: 177, 178 (core), udev-git 20120123-1 (AUR)
keyboard driver: evdev
At least a week earlier I had some of Sony Vaio Keys working: Volume
control (Fn+F2: mute, Fn+F3: down, Fn+F4: up) and Brightness control
(Fn+F5: down, Fn+F6: up). Other Vaio Keys (Fn+F1: touchpad switch,
Fn+F7: switch video mode, Fn+F12: suspend) never worked.
At some point (I think after updating to udev-177-1) Brightness
control keys stopped working. Volume control keys still work.
Brightness control still works directly via acpi.
I blame it on udev, however, downgrading to udev-175 doesn't solve the
problem. Neither does updating to GIT version of udev or loading
correct keymap (module-sony) manually.
I also observe some interesting quirks which may give a clue to
someone more adept in linux than me.
My keyboards are detected correctly:
> [ajaxas@r2d2 ~]$ /lib/udev/findkeyboards
> AT keyboard: input/event0
> module: input/event1
where input/event1 is Sony Vaio Keys, /proc/bus/input/devices lists it properly.
However, my Volume control keys seem to be mapped to input/event0
(keyboard itself):
> [root@r2d2 ajaxas]# /lib/udev/keynap -i input/event0
> scan code: 0xA0 key code: mute
> scan code: 0xAE key code: volumedown
> scan code: 0xB0 key code: volumeup
and these scan codes correspond not to my keymap (0x06, 0x07, 0x08),
but to /lib/udev/keymaps/force-release/common-volume-keys. Manually
removing that keymap and even udev rule for force-release doesn't
change anything (!).
On the other hand, my Brightness control keys, mapped as 0x09 and 0x0A
in the keymap, are reported by udev as:
> [root@r2d2 ajaxas]# /lib/udev/keymap -i input/event1
> scan code: 0x10 key code: brightnessdown
> scan code: 0x11 key code: brightnessup
If I change my keymap file (0x09 -> 0x10, 0x0A -> 0x11) and load
keymap manually, nothing changes. And when I reboot with this changed
keymap, udev reports this for my Brightness control keys:
> [root@r2d2 ajaxas]# /lib/udev/keymap -i input/event1
> scan code: 0x10 key code: fn_f5
> scan code: 0x11 key code: fn_f6
Again, nothing works, and keys are not reported as Brightness control
keys anymore. Here's where I'm lost.
Could you please help me?
With best regards,
Vladimir
^ permalink raw reply
* wpa_supplicant with systemd
From: Allin Cottrell @ 2012-01-24 14:17 UTC (permalink / raw)
To: linux-hotplug
I've mostly succeeded in switching my services over to the
non-forking setup recommended for use with systemd. There's
one exception, and I wonder if anyone has ideas about it,
namely the wifi trope of wpa_supplicant followed on success by
dhcpcd.
I use a wired network connection when it's available, wifi
otherwise, and sometimes need to switch between the two.
This is easily done via something like
systemctl stop <wired>.service
systemctl start <wifi>.service
But at present my <wifi>.service file calls an old-style
init.d script:
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/init.d/wifi.wfu start
ExecStop=/etc/init.d/wifi.wfu stop
Works OK, but it would be nice to make it more
systemd-friendly.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
^ permalink raw reply
* Re: wpa_supplicant with systemd
From: Kay Sievers @ 2012-01-24 15:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LNX.2.01.1201240904480.437@waverley.dhcp.wfu.edu>
On Tue, Jan 24, 2012 at 15:17, Allin Cottrell <cottrell@wfu.edu> wrote:
> I've mostly succeeded in switching my services over to the non-forking setup
> recommended for use with systemd. There's one exception, and I wonder if
> anyone has ideas about it, namely the wifi trope of wpa_supplicant followed
> on success by dhcpcd.
System issue are better handled at:
systemd-devel@lists.freedesktop.org., or on freenode IRC #systemd.
But there is not much work in the static network interface management
area at the moment, so I wouldn't expect too much response. We'll get
to that topic over the next months.
Kay
^ permalink raw reply
* [ANNOUNCE] udev 179
From: Kay Sievers @ 2012-01-24 23:13 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 179
====
Bugfix for $name resolution, which broke at least some keymap handling.
^ permalink raw reply
* Re: Udev loads wrong keymap
From: Martin Pitt @ 2012-01-25 9:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]
Hello Ajaxas,
ajaxas [2012-01-24 20:28 +0700]:
> At least a week earlier I had some of Sony Vaio Keys working: Volume
> control (Fn+F2: mute, Fn+F3: down, Fn+F4: up) and Brightness control
> (Fn+F5: down, Fn+F6: up). Other Vaio Keys (Fn+F1: touchpad switch,
> Fn+F7: switch video mode, Fn+F12: suspend) never worked.
> At some point (I think after updating to udev-177-1) Brightness
> control keys stopped working. Volume control keys still work.
> Brightness control still works directly via acpi.
Note that between udev 175 and 179 the Sony rules and keymaps did not
change at all. The only bug I am aware of is the one you already
pointed out in your forum post, and you said that the fix [1] did not
help.
> I blame it on udev, however, downgrading to udev-175 doesn't solve the
> problem.
OK, this is consistent with what you and I wrote above.
On your forum post you say that keymap -i actually shows the right key
codes (brightnessup/brightnessdown) when you press the corresponding
keys. Can you confirm that this is still true with the latest udev?
Once that's working, all the udev rules, keymaps, etc. have already
been exercised.
Could it be that you upgraded something else in e. g. GNOME which now
fails to act on the key events? You could try "xev" to see whether you
get proper X11 events for these keys, and try a fresh user account to
ensure it's not some changed configuration of your's.
> However, my Volume control keys seem to be mapped to input/event0
> (keyboard itself):
>
> > [root@r2d2 ajaxas]# /lib/udev/keynap -i input/event0
Funny "keynap" typo :)
> > scan code: 0xA0 key code: mute
> > scan code: 0xAE key code: volumedown
> > scan code: 0xB0 key code: volumeup
It's a bit unexpected indeed, I had expected these to also come out of
the "Sony Vaio Module"; does anythign happen on keymap -i input/event1
if you press these keys?
> and these scan codes correspond not to my keymap (0x06, 0x07, 0x08),
> but to /lib/udev/keymaps/force-release/common-volume-keys.
This is a sheer coincidence. common-volume-keys is not applied on
Sony, so that's not relevant here.
> If I change my keymap file (0x09 -> 0x10, 0x0A -> 0x11) and load
> keymap manually, nothing changes. And when I reboot with this changed
> keymap, udev reports this for my Brightness control keys:
>
> > [root@r2d2 ajaxas]# /lib/udev/keymap -i input/event1
> > scan code: 0x10 key code: fn_f5
> > scan code: 0x11 key code: fn_f6
This just double-confirms that the current keymap is correct and gets
loaded properly.
> Again, nothing works, and keys are not reported as Brightness control
> keys anymore. Here's where I'm lost.
Reported to where? keymap -i certainly seems to get them correct. Are
they lost in xev?
Did you happen to upgrade X.org recently? 1.12 introduces a completely
new input stack, and some distros might already use that (I know
Ubuntu's X.org 1.11 packages have that backported for the multi-touch
stuff, for example).
Thanks,
Martin
[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=e605cf7782fdf1dc2e13b95e906e731d61e6cf12
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Udev loads wrong keymap
From: ajaxas @ 2012-01-25 13:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
Thank you for your fast reply! And it was ultimately useful!
I should have known better than to trust XFCE, as I've already had my
troubles with it's stupid components interfering with xorg settings.
Following your instructions step by step I installed udev-179 from
testing repository (nothing changed), tried xev (it responded) and
then created new user only to find Brightness control keys working.
Now I have to find what XFCE component is responsible for this.
Although I still don't know why my Volume control scan codes differ
from those in module-sony keymap file.
>> > [root@r2d2 ajaxas]# /lib/udev/keynap -i input/event0
>
> Funny "keynap" typo :)
Yeah, well, I had to switch to the console and use |tee, which of
course didn't capture the command itself, so I typed it by hand only
to disgrace myself even more :)
> Thanks,
>
> Martin
Thank you very much, Martin!
--
With best regards,
Vladimir
^ permalink raw reply
* Re: Udev loads wrong keymap
From: Robby Workman @ 2012-01-25 14:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
On Wed, 25 Jan 2012 20:51:35 +0700
ajaxas <ajaxas@gmail.com> wrote:
> Thank you for your fast reply! And it was ultimately useful!
>
> I should have known better than to trust XFCE, as I've already had my
> troubles with it's stupid components interfering with xorg settings.
> Following your instructions step by step I installed udev-179 from
> testing repository (nothing changed), tried xev (it responded) and
> then created new user only to find Brightness control keys working.
>
> Now I have to find what XFCE component is responsible for this.
Probably xfce4-xkb-plugin - it doesn't inherit any current keyboard
settings when it switches a layout (note that this isn't necessarily
a bug in itself), so perhaps the layout that it applies is somehow
bad.
> Although I still don't know why my Volume control scan codes differ
> from those in module-sony keymap file.
Do you have xfce4-volumed (and its dep, keybinder) installed? I don't
know what they might be doing (if anything), but perhaps that's a
place to start looking...
-RW
^ permalink raw reply
* Re: Udev loads wrong keymap
From: ajaxas @ 2012-01-25 15:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F1C6B98.5040005@frilling-online.de>
On Wed, Jan 25, 2012 at 9:18 PM, Robby Workman <robby@rlworkman.net> wrote:
> On Wed, 25 Jan 2012 20:51:35 +0700
> ajaxas <ajaxas@gmail.com> wrote:
>
>> Thank you for your fast reply! And it was ultimately useful!
>>
>> I should have known better than to trust XFCE, as I've already had my
>> troubles with it's stupid components interfering with xorg settings.
>> Following your instructions step by step I installed udev-179 from
>> testing repository (nothing changed), tried xev (it responded) and
>> then created new user only to find Brightness control keys working.
>>
>> Now I have to find what XFCE component is responsible for this.
>
>
> Probably xfce4-xkb-plugin - it doesn't inherit any current keyboard
> settings when it switches a layout (note that this isn't necessarily
> a bug in itself), so perhaps the layout that it applies is somehow
> bad.
No, I already have this removed for the greater justice.
I think I got it: when udev in archlinux updated to 177 and brightness
control stopped working, I (unaware of that being a udev problem)
started searching for solution and, well, broke something. F.e., I
found ~/.Xmodmap file with some strange instructions.
>> Although I still don't know why my Volume control scan codes differ
>> from those in module-sony keymap file.
>
>
> Do you have xfce4-volumed (and its dep, keybinder) installed? Â I don't
> know what they might be doing (if anything), but perhaps that's a
> place to start looking...
Yes, I do. Also I tried disabling it and nothing changed. Perhaps, I'm
gonna try removing it form the system.
Also, Fn+F1 / F7 / F12 still don't work, though among these 3 I only
need Fn+F1 (switch touchpad on/off).
But that's how it was from the beginning! :)
--
With best regards,
Vladimir
^ permalink raw reply
* further firmware (?) regressions
From: Tom Gundersen @ 2012-01-28 11:24 UTC (permalink / raw)
To: linux-hotplug
Hi guys,
It seems that people are still having problems with ipw2200 drivers as
of udev-179: <https://bugs.archlinux.org/task/28097>.
Any help appreciated.
Cheers,
Tom
^ permalink raw reply
* Re: further firmware (?) regressions
From: Kay Sievers @ 2012-01-28 18:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAG-2HqVGfW-mr0UFWccoaGZg=uMonpEq30FJDq8vnbwFes=iWA@mail.gmail.com>
On Sat, Jan 28, 2012 at 12:24, Tom Gundersen <teg@jklm.no> wrote:
> It seems that people are still having problems with ipw2200 drivers as
> of udev-179: <https://bugs.archlinux.org/task/28097>.
Does rmmod + modprobe of the ipw2200 driver after bootup, work?
Unrelated to the issue, which we should look into, does the iwlwifi driver work?
Kay
^ permalink raw reply
* Mounting only inserted disks
From: Kai Hendry @ 2012-01-29 3:45 UTC (permalink / raw)
To: linux-hotplug
Hi there,
I used some udev automounting scripts in Webconverger:
https://wiki.archlinux.org/index.php/Udev#Auto_mounting_USB_devices
However since users live boot Webconverger and a system that might
already have an operating system installed like Windows, they
surprisingly found that once they reboot back into Windows, a chkdsk
resulted IIUC.
So I've removed the offending scripts:
http://anonscm.debian.org/gitweb/?pÞbian-live/config-webc.git;a=commitdiff;hê18dff8af2b6800c580b70ce4219aacae9dae73;hpecb0929dd60e0e708e55af81f5bd91bc6173fe6
Now I'm thinking is there a way to only mount disks that were
*inserted* only once the machine has booted?
Kind regards,
^ permalink raw reply
* Re: Mounting only inserted disks
From: Kay Sievers @ 2012-01-29 4:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAF8XF0e9P7RC=eJn2P1HOLWF9AqdD+9uTvqetVa_QSFf_RRsUQ@mail.gmail.com>
On Sun, Jan 29, 2012 at 04:45, Kai Hendry <hendry@webconverger.com> wrote:
> I used some udev automounting scripts in Webconverger:
> https://wiki.archlinux.org/index.php/Udev#Auto_mounting_USB_devices
It is very wrong to recommend anything like this to users. It's just
an entirely flawed concept.
> However since users live boot Webconverger and a system that might
> already have an operating system installed like Windows, they
> surprisingly found that once they reboot back into Windows, a chkdsk
> resulted IIUC.
>
> So I've removed the offending scripts:
> http://anonscm.debian.org/gitweb/?pÞbian-live/config-webc.git;a=commitdiff;hê18dff8af2b6800c580b70ce4219aacae9dae73;hpecb0929dd60e0e708e55af81f5bd91bc6173fe6
>
> Now I'm thinking is there a way to only mount disks that were
> *inserted* only once the machine has booted?
No, it is intentional, that udev rules can not distinguish between
bootup from device hotplug; they look exactly the same.
Udev's rule engine is not the right place to hookup mounting of
arbitrary filesystems, or configure non-trivial network settings like
DHCP, or start system daemons, or run any other programs that runs for
an unpredictable amount of time. Udev rules should only be used to
identify or initially configure hardware, but never to execute system
management jobs or things that involve policy or need error handling
like filesystem checking or mounting. Running such programs from udev
rules will block related events, and might render the entire system
unusable. To ensure timely event execution, udev forcefully kills all
programs it has executed from rules, and which take longer than 30 or
60 seconds to finish, and mounting and checking disks can take much
longer than that.
Udev can send events to services which can act on device changes
though. An auto-mounter service can listen to block device events and
take the appropriate actions, such a service will not block udev's
operations for an unpredictable time. Udisks and systemd for example
work like that.
Mounting filesystems is just not simple enough to do that in udev, you
need a real service to do that properly. Udev rules are just not the
right tool for the job, and very likely never will be.
Kay
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox