клавиатура жестко переназначить клавиши?


19

Я пытаюсь найти способ принудительно переназначить клавиши клавиатуры.
Я пытался использовать xmodmap и setxkbmap, но они не работают для одного конкретного приложения. Такие команды работают для других обычных оконных / приложений на X tho.

Я думаю, что приложение может читать исходные данные с клавиатуры и игнорировать ввод X?

Итак, как переназначить ключи без использования xmodmap и setxkbmap? если это когда-либо возможно сделать с помощью какого-либо программного обеспечения.

Я также пробовал xkeycaps, xkbcomp, но не пробовал loadkeys, так как он работает на X.

Я нашел здесь , что я мог бы попробовать setkeycodes, «потому что после назначения ядра кода ключа кнопка должна работать в Xorg» , но я также обнаружил , что «вы не можете использовать„setkeycodes“на USB - клавиатурами» , это мой случай (я заинтересован в случае кто-то заставляет его работать на PS2, как я думаю, я мог бы использовать адаптер).

Это казалось многообещающим «Сопоставить коды сканирования с кодами клавиш» , но после нескольких тестов ничего не изменилось, вот они:
я нашел код клавиши «36» (клавиша «j») на vt1 и showkey
обнаружил код сканирования «7e» (клавиатура ».) В VT1 сshowkey --scancodes

$cat >/etc/udev/hwdb.d/90-custom-keyboard.hwdb
keyboard:usb:v*p*
keyboard:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
 KEYBOARD_KEY_7e=36
$udevadm hwdb --update #updates file: /lib/udev/hwdb.bin
$udevadm trigger #should apply the changes but nothing happened
$cat /lib/udev/hwdb.bin |egrep "KEYBOARD_KEY_7e.{10}" -ao
KEYBOARD_KEY_7eleftmeta
$#that cat on hwdb.bin did not change after the commands..

Обс .: не работал ни с: KEYBOARD_KEY_7e=j

Еще несколько альтернативных способов (автор @ vinc17) найти ключи:
evtest /dev/input/by-id/... или
input-kbd 3(поместите индекс id, найденный в ls -l /dev/input/by-id/*ex. Event3)

PS .: * Если вы заинтересованы в тестировании самих себя, соответствующая тема для приложения: http://forums.thedarkmod.com/topic/14266-keyboard-issue-in-new-version-108/ Вопросы, которые я имеют одно и то же: некоторые ключи (KP_Decimal, DownArrow, UpArrow, RightArrow) игнорируются и рассматриваются все с одинаковым значением там "0x00"


Обновленный файл должен быть /etc/udev/hwdb.bin, а не /lib/udev/hwdb.bin. Но хотя этот файл обновлен правильно, это не работает для меня, даже после перезагрузки. Возможно, чего-то не хватает в документации. Об этом: bugs.freedesktop.org/show_bug.cgi?id=82311
vinc17

@ vinc17, что действительно интересно, как только я смогу, я попробую снова, я думаю, что мы должны найти этот файл настроек и попытаться подражать ему, спасибо!
Водолей Пауэр

1
Моя проблема была связана с тем, что строки KEYBOARD_KEY_ начинались с 2 пробелов вместо одного (это не было задокументировано, и я не получил сообщений об ошибках!). Я не знаю для вас, но с моей клавиатурой USB, showkey --scancodesне дает коды сканирования, которые ожидает udev (значения разные); input-kbdутилита дает правильные сканкоды.
vinc17

1
evtestУтилита должна также дать вам правильные сканкоды: после ввода ключа, вы должны получить 2 строки и первый один должен заканчиваться чем - то форма code 4 (MSC_SCAN), value xxx, где xxxесть скан. Но драйвер для моей клавиатуры глючит, и я не получаю эту MSC_SCANстроку для некоторых клавиш, которые я хотел переназначить. Вот почему я использовал input-kbd, в котором перечислены все коды сканирования для выбранного устройства.
vinc17

1
Я разместил подробную информацию в ответ. Теперь я не уверен, что 36 или 7002c работает как значение. Я думаю, что вам нужен идентификатор кода ключа. Смотри мой ответ.
vinc17

Ответы:


17

Сначала найдите скан-код ключа, который необходимо переназначить, например, с помощью evtestутилиты. MSC_SCANДолжна быть выведена строка, подобная следующей (с включенным в нее):

Event: time 1417131619.686259, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70068

сопровождаемый вторым, дающим текущий код ключа. Если MSC_SCANстрока не выводится, это связано с ошибкой драйвера ядра, но скан-код все еще можно найти с помощью input-kbdутилиты; evtestдолжен был дать код ключа, чтобы было легко найти соответствующую строку в input-kbdвыводе (например, с помощью grep).

После того, как коды сканирования ключей, которые должны быть переназначены, были определены, создайте файл, такой как /etc/udev/hwdb.d/98-custom-keyboard.hwdbсодержащий переназначения. Начало файла /lib/udev/hwdb.d/60-keyboard.hwdbдает некоторую информацию. В моем случае (который работает) у меня есть:

evdev:input:b0003v05ACp0221*
 KEYBOARD_KEY_70035=102nd       # Left to z: backslash bar
 KEYBOARD_KEY_70064=grave       # Left to 1: grave notsign
 KEYBOARD_KEY_70068=insert      # F13: Insert

(До udev 220 мне пришлось использовать keyboard:usb:v05ACp0221*для первой строки.)

evdev:Строка должна быть в начале строки. Обратите внимание, что буквы в поставщике и идентификатор продукта должны быть заглавными буквами. Каждый KEYBOARD_KEY_параметр должен иметь ровно один пробел (примечание: строка без пробелов выдаст сообщение об ошибке, а строка с двумя пробелами в старых версиях udev молча игнорировалась). KEYBOARD_KEY_за ним следует скан-код в шестнадцатеричном формате (вроде того, что оба evtestи input-kbdдают). Допустимые значения могут быть получены либо из evtestвыходных input-kbdданных, либо из выходных данных, либо даже из /usr/include/linux/input.hфайла: например, KEY_102NDдадут 102nd(удалив KEY_и преобразовав в нижний регистр), который я использовал выше.

После сохранения файла введите:

udevadm hwdb --update

(пере) построить базу данных /etc/udev/hwdb.bin(вы можете проверить ее метку времени). Потом,

udevadm trigger --sysname-match="event*"

приму новые настройки к сведению. Вы можете проверить с evtest.

В 2014 году выпущенная версия udev содержала неполную / ошибочную информацию /lib/udev/hwdb.d/60-keyboard.hwdb, но вы можете посмотреть последнюю версию файла и / или мой отчет об ошибках и обсуждение проблем с документацией и пробелами.

Если это не сработает, проблема может быть обнаружена после временного увеличения уровня журнала udevdс помощью udevadm control(подробности см. На справочной странице udevadm (8)).

Для старых udevверсий, таких как 204, этот метод все еще должен работать.


Когда я запускаю команды udevadm, файл, который обновляется /lib/udev/hwdb.bin, просматривается, blessи я вижу KEYBOARD_KEY_70085его в конце. Я думаю, что Ubuntu 14.04 настроен (защищен?) Таким образом. Я пытался udevadm control --log-priority=debug. на основе lsusb(045e: 0750) моя клавиатура выглядит как keyboard:usb:v045ep0750*, но я keyboard:usb:v*p*тоже пробовал . Я думаю, что это /etc/udev/hwdb.binдолжно быть обновлено, но даже не существует.
Водолей Сила

Когда я читаю здесь, может быть, что я использовал эту команду udevadm hwdb --usr --update, несмотря на то, что я не был.
Водолей Сила

После того, как udevadm hwdb --updateя скопировал /lib/udev/hwdb.binв /etc/udev/hwdb.binи побежал , strace udevadm trigger --sysname-match="event*"и файл , hwdb.binкажется , не были прочитаны им (если это как это работает).
Водолей Сила

1
@ AquariusPower Да, может быть ошибка, специфичная для Ubuntu (я использую Debian / unstable). Чтобы увидеть, читается ли база данных при выполнении udevadm trigger ..., посмотрите мой тест здесь . Обратите внимание, что перед запуском udevadm trigger ...необходимо убедиться, что время изменения файла было обновлено, иначе время доступа не будет обновляться при чтении файла.
vinc17

1
@AquariusPower udevadm --version: 215 (и версия пакета udev: 215-7). Спасибо udevadm trigger ..., вам не нужно перезагружаться (если вы не хотите удалить настройки, AFAIK). Но вы можете попробовать перезагрузить компьютер, чтобы увидеть, есть ли какой-либо эффект.
vinc17
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.