Я слабо представляю ситуацию, когда ядро не видит нажатие клавиши. Скорее всего на эти клавиши у тебя ничего не забиндено, никаких действий. Собственно «драйвер» в Windows только то и делает, что биндит действия.

Проверить просто:
Установи xev , запусти его (в консоле), и понажимай клавиши. Если реагирует - значит ядро видит нажания. А дальше - либо забиндить через твое DE (знаю как в KDE делается, в других - не знаю), либо хардкором - через xbindkeys (или сегодня уже модно xmodmap?).

Вот, почитай: http://ru.gentoo-wiki.com/wiki/HOWTO_Мультимедийные_кнопки_(клавиши) . Там описано и DE, и xmodmap .

поиск кому придуман????

Что делать с клавишами, которые не ловятся через showkey и xev? (комментарий)

xev тоже не реагирует на эти клавиши.
я уже гуглил и читал темы, не видно их никак.

Тогда попробуй то, что предложил novitchok комментом выше.

http://en.gentoo-wiki.com/wiki/Multimedia_Keys#If_key_presses_generate_no_X_e...

try showkeys. If it will show key codes larger than 255 - read on.

Повторяю. У меня не реагируют никакие программы:
showkeys
dmesg
xev
acpi_listen

showkeys показывает такие коды при нажатиях:
F4 - нет реакции
F5 - 224
F6 - 225
F7 - нет реакции
F8 - 227
F9 - нет реакции
F10 - нет реакции
F11 - нет реакции
F12 - нет реакции

Вы вообще по ссылке ходили?

Ходил.
Попробовал:

sudo /lib/udev/keymap -i input/event6
Press ESC to finish, or Control-C if this device is not your primary keyboard
(no scan code received)  key code: brightnessup
(no scan code received)  key code: brightnessdown
(no scan code received)  key code: switchvideomode

no scan code received

Вот теперь, насколько я понимаю, можно с чистой совестью бросать это дело. Вот тут есть какая-то подсказка, но мне не приходилось сталкиваться с подобным: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654936

(no scan code received)  key code: brightnessup
(no scan code received)  key code: brightnessdown
(no scan code received)  key code: switchvideomode

Это выводится при нажатии работающих клавиш и даже значок яркости появляется. А на клавиши громкости не реагирует ни одна программа из тех что я пробовал.

Эх, надо смотреть... Поставь программу evtest, скорее всего она есть в дистрибутиве, но если нет — исходники тут: http://cgit.freedesktop.org/~whot/evtest/ Эта программа показывает входящие события с устройства.

Затем посмотри, какие у тебя есть устройства ввода /dev/input/event*

Для каждого из этих устройств запусти от рута команду:

evtest /dev/input/eventX

Чтобы не перебирать устройства вручную, можно сразу открыть несколько консолек и в каждой запустить по evtest-у. Например, если установлен xterm, и sudo работает, от обычного юзера:

for i in /dev/input/event*; do xterm -e bash -c "echo $i; sudo evtest $i" & done

Вывод того evtest-а, где устройство реагирует на нажатия нужных кнопок, скинь на любой pastebin. Учти, какое-то из устройств ввода — это мыша, и оно будет писать в консоль очень много всего на каждое движение мыши. :)

http://pastebin.com/cKw3C6YU

http://pastebin.com/WXL4m5DX

Во втором есть реакция на Fn + F5-F8
Fn + F8 дает код 227, значит Fn + F9-F12 должны давать коды с 228 по 231.

http://s.stdns.ru/up/description/cache/price_item_full_watermark/156456_6.134...

http://pastebin.com/cKw3C6YU

В этом выводе я вижу нажатия кнопок Enter, F9, F10 (не Fn+F9 и Fn+F10, а именно F9 и F10) и Ctrl+C. То есть обычные кнопки.

Кстати, обрати внимание — evtest детектит отдельно нажатие кнопок и отдельно отпускание. Причём и там и там выводятся два события: сканкод и кейкод.

http://pastebin.com/WXL4m5DX

О, тут интереснее. Насколько я понимаю, тут три нажатия с кейкодами 224, 225, 227. Какие именно при этом нажимались кнопки?

Но, что самое интересное, в этом выводе нет сканкодов. То есть их совсем нет. Модуль ядра, который отвечает за это устройство, не присылает сканкодов. Жутко интересно, какой это модуль ядра? Запусти у себя команду:

for i in /dev/input/event*; do udevadm info -a -p $(udevadm info -q path -n $i); done

На данный момент получается, что это баг в одном из модулей ядра. Если мы сами ничего не придумаем, то когда мы выясним, в каком модуле баг, вполне можно связаться с его автором и спросить, что делать дальше. :)

PS: Плохо, что ноутбук х.з.какой, трудно гуглить проблему, пока ближайшее, что удалось найти: https://bugs.launchpad.net/ubuntu/ source/linux/ bug/735756

PPS: Поскольку баг — в ядре, можно попробовать более новое. Просто для теста, на случай если в новом ядре баг исправлен. Для этого можно, например, скачать и записать на флешку последнюю ночную сборку федоры: http://alt.fedoraproject.org/pub/alt/nightly-composes/ в ней обычно последние ядра. Ставить её не нужно, это — только для теста. :) В федоре тоже можно установит evtest и сравнить, есть ли что-нибудь новое в его выводе.

Судя по всему, нужен платформенный драйвер или драйвер для WMI. Если его нет, нужно писать самостоятельно. Для этого стоит заглянуть в доступные WMI программой wmidump — если там есть ACPI_WMI_EVENT, то нужно написать минимальный драйвер и посмотреть, какие события приходят туда при каких обстоятельствах. Если через WMI получить нажатия клавиш не получится, то есть вероятность, что нужно писать драйвер для EC. В таком случае, скорее всего, стоит изучить DSDT — это может помочь понять, как устроено взаимодействие с EC на данном ноутбуке. Возможно, в этом случае придётся ловить ACPI notify и читать из EC состояние клавиш. Гораздо проще это всё делается, если уже есть готовый драйвер для другой модели того же производителя [и той же серии], потому что тогда сразу будет понятно, как обрабатываются клавиши, и придётся немного допилить готовый драйвер.

showkeys показывает такие коды при нажатиях:
FN +
F4 - нет реакции
F5 - 224
F6 - 225
F7 - нет реакции
F8 - 227
F9 - нет реакции
F10 - нет реакции
F11 - нет реакции
F12 - нет реакции

for i in /dev/input/event*; do udevadm info -a -p $(udevadm info -q path -n $i); done
http://pastebin.com/cNr1rEVz
В dmesg ничего нового не появляется.
Ноутбук какой то такой http://3logic.ru/?A=5&SI=1&I=37619

http://pastebin.com/WXL4m5DX

Тут видно, что события генерирует event5 с именем «Video Bus».

for i in /dev/input/event*; do udevadm info -a -p $(udevadm info -q path -n $i); done
http://pastebin.com/cNr1rEVz

А тут видно, что устройством с именем «Video Bus», которое теперь event7 (от запуска к запуску номера могут меняться) заведует драйвер acpi.

В этом месте надо было бы написать багрепорт в багзиллу своего дистрибутива, указав, что баг относится к ядру, и дописав, что этот баг возможно связан с https://bugs.launchpad.net/ubuntu/ source/linux/ bug/735756 В нём тестировали какое-то патченое ядро, но ни патча ни ядра уже нету. Если ответа на багрепорт не будет, то можно попробовать написать емейл Seth Forshee <seth.forshee <at> canonical.com> (добавив ему ссылку на новосозданный багрепорт).

А из того, что делать самим... Простые решения мне пока в голову не приходят. Могу предложить только попробовать разные шаманства.
1. При загрузке в grub-е дописать в параметры ядра: acpi_backlight=vendor (именно слово «vendor», не «asus», «dns» и т.д.). Загрузиться с этим параметром. Проверить, что он есть в /proc/cmdline. Запустить evtest, понажимать кнопки и посмотреть, что изменится.
2. Попробовать сделать от рута «modprobe toshiba_acpi». Если модуль загрузится (посмотреть lsmod), то запустить evtest и посмотреть, что изменится. Ещё можно заглянуть в dmesg и посмотреть там.
3. В некоторых багрепортах пишут, что suspend меняет поведение. Так что можно засаспендить ноутбук (suspend to ram), вернуть обратно, и не перезагружаясь посмотреть, что изменится.
4. Попробовать загрузиться с livecd/флешки Fedora Nightly с последним ядром, поставить там evtest и посмотреть, что он напишет. Заодно повторить на нём тесты #1-#3

Обратить внимание на то, что от загрузки к загрузке соответствующий eventX может быть под разным номером.

Краткое пояснение: сейчас проблема в том, что acpi-модуль ядра не возвращает события нажатий, поэтому никакая программа их не видит. Проще всего это проверяется с помощью evtest. Evtest — это небольшая утилита, которая выводит все передаваемые ядром события для указанного устройства ввода. Если evtest увидит нажатия кнопок, то и остальные программы можно будет настроить.

В dmesg ничего нового не появляется.

Меня интересовало не только новое, но вообще весь dmesg, вдруг там есть что-то важное по поводу ACPI, клавиатуры или какого-нибудь модуля, от чего можно было бы оттолкнуться при поиске решения.

PS: gentoo_root просит DSDT, поэтому выложи вывод acpidump на какой-нибудь pastebin. Вдруг он сможет что-нибудь подсказать.

Разобраться со всем этим все еще нет времени. Пока попробовал только Fedora Nightly - клавиши не заработали. Щас в настройках догадался поставить хот-кеи на обычные клавиши. Буду так пользоваться. Потом может когда нибудь еще поизучаю эту проблему.

Пока попробовал только Fedora Nightly - клавиши не заработали.

Значит в новом ядре баг не исправлен. Жаль.

Разобраться со всем этим все еще нет времени.

Тогда хоть багрепорт напиши в багзиллу своего дистрибутива, что у тебя вообще есть такой баг.

В идеале, к багрепорту приаттачь вывод команд dmesg, lsmod, acpidump и фотографию своей клавиатуры. :) А в тексте бага укажи этот вывод evtest-а и написать, что срабатывают только кнопки Fn+F5, Fn+F6 и Fn+F8.

Написать багрепорт — это всего-то минут десять, но мало ли, вдруг девелоперы сами решат эту проблему, и им не хватает только твоих логов чтобы добавить в модуле поддержку твоего ноута. :)