> Eh? Does that mean it only doesn't start in the boot process but works > correctly if run later on? Could you go into /etc/init.d/acpi-fakekey and add > a > "sleep 5" after the modprobe and before the "start-stop-daemon --start --quiet > --oknodo --exec /usr/sbin/acpi_fakekeyd" and retry?
That is what I'm seeing here. I did what you suggested and added 'sleep 5' right after: 'if ! modprobe -q uinput; then' to /etc/init.d/acpi-fakekey. It still fails at boot, but can start manually, like I stated before. > This seems to be a different problem. Which hardware do you have? What > keycodes > are produced? Please note that acpi-support only translates key events and you > might still need some other software like a mixer to react on these. It maybe a different issue, but I did notice this at the same time as the acpi-fakekey issue. All I know is that it was working fine with alsamixer before and I had not done anything for the keys to work with alsamixer. This is on a Thinkpad T23. xev does not report anything with vol -/+ or mute keys. I forgot to mention this before, I had tried xev to find out what was the cause. But thought nothing of it as it was working fine before. Thanks, Michel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
