LINUX.ORG.RU

Кривая работа клавиатуры i8042 в Debian

 


0

2

Есть нетбук Asus EeePC 1025c. Родная клавиатура нормально работает в: BIOS, GRUB, Windows 7.

В установочных образах и установленной системе Debian нормально работает только внешняя USB-клавиатура. Родная клавиатура воспринимает лишь первое нажатие. В момент нажатия в логах ничего не появляется.

# evtest /dev/input/event0
...
Testing ... (interrupt to exit)
Event: time 1727881204.929672, type 4 (EV_MSC), code 4 (MSC_SCAN), value 02
Event: time 1727881204.929672, type 1 (EV_KEY), code 2 (KEY_1), value 1
Event: time 1727881204.929672, -------------- SYN_REPORT ------------
# dmesg | grep i8042
[    3.706092] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    3.723988] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.724010] serio: i8042 AUX port at 0x60,0x64 irq 12
[    3.736960] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
# uname -a
Linux debian 6.1.0-25-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) i686 GNU/Linux

Как можно заставить работать родную клавиатуру?

  1. попробуй загружать livecd предыдущих версий дебиана (debian11, debian10 и тд) - качай образы без gui, чтобы не тратить время зря

  2. попробуй ядру передавать параметры, затрагивающие работу i8042
    (сходу вспоминаются i8042.debug или i8042.noaux или i8042.nomux)

  3. попробуй livecd вообще не дебиановские (arch/fedora/*bsd)

  4. самое главное/надёжное - продолжай гуглить по модели своего нетбука и/или чипсета матери :)

d00fy ★★★
()
Ответ на: комментарий от d00fy

попробуй загружать livecd предыдущих версий дебиана (debian11, debian10 и тд) - качай образы без gui, чтобы не тратить время зря

Пробовал Debian LiveCD и установщики разных версий вплоть до 7. На всех эта проблема. Один раз немного повезло в установщике Debian 7: при нажатии кнопки на внешней клавиатуре начала работать и родная. Но после установки она тоже перестала работать. Второй раз воспроизвести даже такую работоспособность мне не удалось.

попробуй ядру передавать параметры, затрагивающие работу i8042 (сходу вспоминаются i8042.debug или i8042.noaux или i8042.nomux)

В Debian12 я проверял разные найденные сочетания параметров, которые кому-то помогли, но мне не помогло ни одно из них. Я плохо понимаю назначение этих параметров, поэтому не знаю, какие из сочетаний имеет смысл применять. Подробного гайда найти не смог, нашел только короткий справочник по параметрам ядра.

самое главное/надёжное - продолжай гуглить по модели своего нетбука и/или чипсета матери :)

Продолжать уже не знаю как, поэтому решил спросить. Долго гуглил и по модели и по чёртовой матери.

попробуй livecd вообще не дебиановские (arch/fedora/*bsd)

Спасибо, попробую.

newbie24
() автор топика
Ответ на: комментарий от d00fy

@mky предлагает добавлять i8042.reset i8042.nomux оба сразу

Не помогло. Подскажите, я хоть правильно меняю параметры?

# grep GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="i8042.reset i8042.nomux=1"

# update-grub && reboot

newbie24
() автор топика
Ответ на: комментарий от newbie24

после того, как залогинился в систему, посмотри вывод cat /proc/cmdline

ps. перед тем, как делать update-grub, обычно их (параметры) сперва просто добавляют/изменяют, нажимая клавишу ‘e’ в меню граба при включении нетбука (если подошли - ок, апдейтим граб; если нет - то и не надо)

d00fy ★★★
()
Последнее исправление: d00fy (всего исправлений: 2)
Ответ на: комментарий от newbie24

Эти i8042.* все тёмный лес.

i8042.nomux, i8042.noloop, i8042.noaux, ИМХО, вам не помогут, раз первый символ проходи, значит как-то всё определяется.

К i8042.reset можно ещё добавить atkbd.reset, на уроне шаманства, а может, наоборот, нужно запретить Reset (i8042.reset=n).

Ещё можете понаблюдать за содержимым /proc/interrupts, там у IRQ1 должен расти счётчик при каждом нажати на клавишу. Если нет, скорее всего проблема в неправилно настроеной обработки прерываний EDGE/LEVEL, ACTIVE_LOW/ACTIVE_HIGH. Тогда может поможет i8042.nopnp, а может правка DSDT https://bbs.archlinux.org/viewtopic.php?id=291569 или пересборка ядра, чтобы там добавить в drivers/acpi/resource.c.

В момент нажатия в логах ничего не появляется.

Ну, можете добавить i8042.debug, может что будет появляться.

mky ★★★★★
()
Ответ на: комментарий от NiTr0

банальный вопрос: биос хоть последний зашит?…

Я об этом не подумал, т.к. в Windows проблем с клавиатурой не было. Обновил до последней версии. Проблему это не решило, но теперь, видимо, надо заново тестировать разные параметры ядра.

newbie24
() автор топика
Ответ на: комментарий от mky

К i8042.reset можно ещё добавить atkbd.reset, на уроне шаманства, а может, наоборот, нужно запретить Reset (i8042.reset=n).

Все 4 комбинации i8042.reset и atkbd.reset не решили проблему.

Ну, можете добавить i8042.debug, может что будет появляться.

Я думал, в логах может появиться какая-то ошибка при нажатии. Но ошибок в тот момент не появилось. При добавлении i8042.debug появляется единственное сообщение о нажатии клавиши. Сообщений об отпускании нет.

Еще появляется около 70 сообщений во время загрузки системы. Можно ли их дешифровать? Имеет ли это смысл в диагностике моей проблемы?

Ещё можете понаблюдать за содержимым /proc/interrupts, там у IRQ1 должен расти счётчик при каждом нажати на клавишу.

Для внешней клавиатуры счётчик каждый раз увеличивается на 1 как при нажатии, так и отпускании, а для встроенной увеличивается только при первом нажатии. Второе и последующие прерывания не приходят.

Если нет, скорее всего проблема в неправилно настроеной обработки прерываний EDGE/LEVEL, ACTIVE_LOW/ACTIVE_HIGH. Тогда может поможет i8042.nopnp, а может правка DSDT https://bbs.archlinux.org/viewtopic.php?id=291569 или пересборка ядра, чтобы там добавить в drivers/acpi/resource.c.

А как это применить в моем случае? С одной стороны, первое прерывание приходит, а с другой — не приходят последующие. Параметр i8042.nopnp я уже безрезультатно добавлял в своих прошлых экспериментах в комбинации с другими параметрами. Возможно, требуется какая-то особая комбинация, чтобы этот параметр работал?

newbie24
() автор топика
7 марта 2025 г.
Ответ на: комментарий от mky

Эти i8042.* все тёмный лес.

Но я всё же попробую сквозь этот лес продраться.

Множественными экспериментами обнаружено костыльное решение моей проблемы. Сначала я обнаружил, что встроенная клавиатура при каких-то обстоятельствах может включиться. В начале всё это выглядело чистым шаманством, но в итоге я добился чёткого воспроизведения результата, пока в ручном режиме.

Прежде чем начну писать скрипт, я прошу совета у экспертного сообщества. Возможно, существует менее костыльное решение.

Алгоритм:

  • Указываем параметр ядра i8042.debug=1, чтобы нажатия на клавиши отображались в dmesg.
  • При обнаружении в выводе dmesg строки ** <- i8042 (interrupt, 0, 1) выполняем:
# echo "i8042" | tee /sys/bus/platform/drivers/i8042/bind > /sys/bus/platform/drivers/i8042/unbind
  • Повторяем до тех пор, пока в dmesg не появится строка i8042 (auxerr).

Сейчас я подключаюсь к ноутбуку по SSH. В одной консоли ввожу:

# dmesg -ew | egrep 'i8042.*(auxerr|\*\*.*interrupt)'

В другой повторяю команду на переподключение. При этом надо нажимать клавиши на ноутбуке. При нажатии в dmesg появляется строка ** <- i8042 (interrupt, 0, 1). При нормально работающей клавиатуре должна следовать точно такая же строка на отжатие клавиши. Но в случае проблемы следующее прерывание не обнаруживается.

Переподключение клавиатуры может как восстановить её работу, так и не восстановить. От чего это зависит, мне понять не удалось. Но я обанаружил, что если переподключение помогло, то в dmesg появляется строка i8042 (auxerr). Это значит, что переподключение выполнять уже не требуется. Более того, очередное переподключение может клавиатуру снова сломать.

Есть у кого-нибудь объяснение этого трюка? И можно ли на его основе сделать менее костыльное решение?

newbie24
() автор топика
Ответ на: комментарий от newbie24

i8042.dumbkbd=1 пробовали?

Объяснения должны давать инженеры, проектировавшие чип, использованый в вашем Eee. Ядро как-то неправильно с их точки зрения ицициализирует i8042, а нажатие клавиши в нужный момент что-то меняет в регистарах контроллера.

По хорошему, нужно брать документацию i8042, исходники линуксового драйвра и пробовать работать из user-space с портами ввода-вывода, относящимся к контроллеру клавы, чтобы понять где ошибка. Возможно, нужно просто пауза после изменения одного регистра, прежде чем что-то писать в другой...

в dmesg появляется строка i8042 (auxerr)

И при этом ничего не отпадывает? Вроде как, эта строка означает, что не будет «Detected active multiplexing controller», а на этом мултиплексе, может, тачпад висит или подсветка чего-нибудь.

mky ★★★★★
()
Ответ на: комментарий от newbie24

Есть у кого-нибудь объяснение этого трюка?

Наверное активное мультиплексирование у вас так и не отключается полностью при помощи nomux=1, а трюком вы лишь выполняете работу контроллера.

Гляньте этот патч, вдруг что-то пригодится https://lkml.org/lkml/2014/10/10/354

vaddd ★☆
()