LINUX.ORG.RU

evdev, X11 и магия

 , ,


0

1

Давно не пользовался нетбуком MSI Wind U100 (видеокарта intel 945GSE), накатил на него генту. Т.к. это может быть важно, у меня systemd. Конфиг ядра. dmesg (с кучей багов с видеокартой). Ещё systemd-logind где-то писал ошибку kernel does not support evdev-revocation, но я уже не могу найти её ни в каком логе.

Суть заключается в том, что я обнаружил, что при нажатии кнопочек яркости она меняется на две ступени сразу. sudo showkey из-под иксов (там KDE 4) действительно показывал двойные нажатия клавиш. Потыкался по /dev/input/event* и оказалось, что события идут из event4 (Video Bus) и из event5 (AT Translated Set 2 keyboard). Проблема знакомая — на моём другом ноуте та же фигня. Поэтому первым делом я решил применить решение с другого ноута — сказать иксам игнорировать Video Bus:

/etc/udev/rules.d/90-intel-quirks.rules:

ACTION=="add", KERNEL=="event*", ENV{ID_PATH}=="acpi-LNXVIDEO:00", ENV{ID_INPUT.tags}="intel-video-bus"

/etc/X11/xorg.conf.d/90-intel-quirks.conf:

Section "InputClass"
        Identifier "Ignore Intel brightness keys"
        MatchTag "intel-video-bus"
        Option "Ignore" "on"
EndSection

После перезагрузки или перезапуска иксов (не имеет значения) результат оказался неожиданным. Из /dev/input/event5 события клавиш яркости больше не сыпались! При этом event5 — это клавиатура, обычные клавиши работали и сыпались из файла. А event4 игнорировался моим конфигом, поэтому яркость вообще не регулировалась. Номера evdev'ов не менялись, это я проверяю каждый раз. Если убрать /etc/X11/xorg.conf.d/90-intel-quirks.conf, то события снова начинают сыпаться и из /dev/input/event4, и из /dev/input/event5. Это мне показалось очень и очень странным.

Но ещё более странным оказалось то, что как только я переключаюсь на виртуальный терминал, события клавиш яркости из event5 сразу же перестают сыпаться!

Из этого я делаю вывод: если Xorg не игнорирует Video Bus, то он что-то делает, что в иксах кнопочки яркости начинают сыпаться и из event5. Это какая-то магия, и я прошу кого-нибудь объяснить, как же это работает.

Вдобавок стоит сказать, что в hwdb для моего ноута настроены следующие маппинги клавиш:

KEYBOARD_KEY_f7=brightnessdown # Fn+F4
KEYBOARD_KEY_f8=brightnessup   # Fn+F5

Если их убрать из hwdb, то события из event5 продолжают сыпяться по тому же правилу, но т.к. коды клавиш другие, яркость переключается по одной ступеньке. Это можно считать workaround'ом моей проблемы, но мой вопрос в том, как же работает вышеописанная магия?

Ответ на: комментарий от AEP

добавляем в командную строку ядра: video.brightness_switch_enabled=0

Я же dmesg не зря прикрепил. Там видна моя командная строка ядра. Там это уже есть.

Меня больше интересуют причины магического поведения /dev/input/event5, потому что workaround для яркости я нашёл и описал в ОП, но это никак не объясняет происходящую магию.

А магия в том, что если запущены и активны иксы, которые не игнорируют event4, то в event5 начинают появляться нажатия клавиш яркости. В остальных случаях (активна консоль, либо же event4 игнорируется X-сервером) в event5 почему-то нет нажатий клавиш яркости, хотя они там должны быть. Чтобы окончательно запутаться, я обнаружил, что при минимальной яркости и нажатии на яркость_вниз всё-таки событие в event5 появляется всегда.

gentoo_root ★★★★★
() автор топика

Сделал следующий тест. Запустил в sddm не сессию KDE, а просто сессию с xterm. Video Bus не игнорировал. Поведение клавиш — самое разумное, которое только можно придумать: из event4 сыпятся нажатия клавиш яркости, которые могут что-то изменить, а из event5 — которые не могут. Например, если яркость на нуле, то кнопка вниз вылезет из event5, а кнопка вверх из event4. Если яркость на 4, то обе кнопки вылезут из event4. Если яркость на 8, то кнопка вверх из event5, кнопка вниз из event4.

Выходит, KDE что-то такое делает, что кнопочки начинают вести себя по-другому. Например, я нажимаю вверх при нулевом уровне яркости, у меня приходит событие из event4, а следом его догоняет событие из event5, хотя оно должно быть только при максимальном уровне яркости. Если в бесконечном цикле смотреть cat /sys/class/backlight/acpi_video0/brightness, то он сначала 0, потом 1, потом 2.

Важное отличие KDE от остального в том, что яркость от нажатий кнопок регулируется только в KDE, не в сессии с xterm или консольной. Это может быть близко к разгадке, однако непонятно, почему событие из event5 появляется при первом повышении уровня. Он же не максимальный после этого, да и клавиша один раз нажата.

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

Такой же результат воспроизвёл в консоли. Установил яркость в 0, ввёл команду установки яркости в 1 (не нажимая enter), потом быстро нажал клавишу яркости вверх и enter, пока клавиша яркости ещё не была отпущена. Выходит, если яркость повышается при нажатой клавише яркости, то event5 плюнет ещё одним нажатием на кнопку повышения яркости по непонятным причинам. Судя по тому, что event5 — это atkbd, такой код генерирует железка и исправить это не представляется возможным, только отмапить эти клавиши с event5 (но тогда при попытке уменьшить яркость ниже нуля никто вообще не увидит нажатий, индикатор на экране не возникнет, хотя он и на другом компе не возникает, где есть нужные события).

Почему при игнорировании event4 нет событий из event5, тоже становится понятно. Потому что кривые события из event5 появляются в результате изменения яркости при ещё нажатой клавише, полученной из event4.

Почему раньше всё работало — вот это непонятно. Нужно провести ещё тесты со старыми линуксами, но не убунтами, потому что в убунтах некоторое время было ядро с патчем, который ломал некоторую функциональность нетбука из-за кривого биоса.

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

Проверь более старые ядра. Если проблема недавно возникла, можно найти последнюю рабочую версию, перебирая версии бинарным поиском.

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

Deleted
()

я в xfce4-power-manager снял галку «Handle display brightness keys»

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

Проверь более старые ядра.

Загрузился с флешки в старый LFS с ядром 2.6.35. Проблема имеет аппаратный характер и известна давно, как оказалось. Смысл в том, что при нажатии клавиши изменения яркости, если яркость в эту сторону можно изменить, генерируется событие на Video Bus. Оно обрабатывается либо KDE, либо ядром, если video.brightness_switch_enabled=1. Яркость меняется. Вслед за этим возникает событие на event5 (клавиатура). Естественно, если я юзаю KDE, оно отреагирует и на это событие тоже и изменит яркость ещё на одну ступень.

Теперь почему раньше работало.

Когда ещё маппинги клавиш управлялись udev'ом через 95-keymap.rules, там был следующий код, относящийся к моему ноуту:

ENV{DMI_VENDOR}=="MICRO-STAR*|Micro-Star*", RUN+="keymap $name micro-star"

# some MSI models generate ACPI/input events on the LNXVIDEO input devices,
# plus some extra synthesized ones on atkbd as an echo of actually changing the
# brightness; so ignore those atkbd ones, to avoid loops
ENV{DMI_VENDOR}=="MICRO-STAR*", ATTR{[dmi/id]product_name}=="*U-100*|*U100*|*N033", RUN+="keymap $name 0xF7 reserved 0xF8 reserved"

# MSI Wind U90/U100 generates separate touchpad on/off keycodes so ignore touchpad toggle keycode
ENV{DMI_VENDOR}=="MICRO-STAR*", ATTR{[dmi/id]product_name}=="U90/U100", RUN+="keymap $name 0xE4 reserved"

Первое правило назначает все клавиши, в том числе 0xF7 на brightnessdown, 0xF8 на brightnessup. Второе правило на моём нетбуке отменяет маппинги 0xF7 и 0xF8 (я предлагал это как workaround в ОП). Третье правило когда-то в своё время добавил я, но оно для тачпада, к яркости не имеет отношения.

Таким образом, на моём нетбуке udev настраивал всё так, чтобы события из event5 о клавишах яркости игнорировались. И всё работало.

Потом произошёл переход на hwdb. Формат файла стал лучше, комменты все почему-то потёрли, стало так:

keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*
keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*
 KEYBOARD_KEY_a0=mute                                   # Fn+F9
 KEYBOARD_KEY_ae=volumedown                             # Fn+F7
 KEYBOARD_KEY_b0=volumeup                               # Fn+F8
 KEYBOARD_KEY_b2=www                                    # e button
 KEYBOARD_KEY_df=sleep                                  # Fn+F12
 KEYBOARD_KEY_e2=bluetooth                              # satellite dish2
 KEYBOARD_KEY_e4=f21                                    # Fn+F3 Touchpad disable
 KEYBOARD_KEY_ec=email                                  # envelope button
 KEYBOARD_KEY_ee=camera                                 # Fn+F6 camera disable
 KEYBOARD_KEY_f6=wlan                                   # satellite dish1
 KEYBOARD_KEY_f7=brightnessdown                         # Fn+F4
 KEYBOARD_KEY_f8=brightnessup                           # Fn+F5
 KEYBOARD_KEY_f9=search

#
keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr*
keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr*
keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*N033:*
 KEYBOARD_KEY_f7=reserved
 KEYBOARD_KEY_f8=reserved

#
keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pnU90/U100:*
 KEYBOARD_KEY_e4=reserved

Как видим, все правила на месте. Однако почему-то f7 и f8 не делаются reserved. Вероятно, применяется только первое встреченное правило. Я разберусь с этой регрессией в udev и отправлю репорт.

gentoo_root ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.