сканер штрихкода и Fedora 4

Как добавить для него русскую раскладку? Какая должна быть XkbModel?

Это мы у тебя должны спросить.

В выхлоп lsusb смотрел? Если оно не USB, то на этом наши полномочия всё.

Сканер usb. В lsusb пишется какая xkbmodel должна быть?

С таким количеством вводных данных тебе лучше обратиться не на ЛОР, а к экстрасенсу.

Могу предположить, что XkbModel — pc105, если производитель из Европы или Китая. Но это неточно.

а в таком случае разве он не должен был подхватить настройки клавиатуры? Я так понимаю, что для сканеров должна быть отдельная XkbModel

P.S. Сканер атол

а в таком случае разве он не должен был подхватить настройки клавиатуры?

Если он хоть что-то печатает — значит подхватил… какой-то дефолт.

От XkbModel зависит только одно — правильное определение non-ANSI (дополнительных) кейкодов (критично для CJK) без их дополнительной настройки. Причём за раскладку оно не отвечает и к ней по большому счёту не причастно (с неверным XkbModel для немецкой раскладки придётся настроить всего одну кнопку).

«Не знаешь что выбрать — выбирай pc104.» В случае с немецкой раскладкой — pc105. Для русской хватает pc104. Но вот если оно ведёт себя совсем нестандартно, то, вероятно, придётся ковырять xkb и вручную править /usr/share/X11/xkb/geometry/* (можно даже написать свой файл, чтобы не затёрлось обновлениями).

чтобы не затёрлось обновлениями).

Fedora Core 4

лол.

PS я-то сейчас сижу на системе, прошедшей все обновления с fc4. Это в принципе возможно.

лол.

Ну извини, я RPM щупал крайне поверхностно и очень давно. И вообще, я не использую Linux.

Обновлять федору4 сегодня, это всё равно что обновлять семечко свеклы до борща.

И что, на неё даже бэкпорты не делают хотя бы изредка, хотя бы какие-нибудь левые васяны с прямыми руками?

Ну если кто намертво на ней застрял - то наверное делает для себя. Куда он денется.

Если в пакете есть конфиг, обновление затрёт существующий. Или нет?

Я об этом.

Всё что в /usr конфигами не считается и будет затёрто (кроме /usr/local, туда rpm не лезет).

В /etc конфиги не затираются (если имеющийся в системе конфигфайл изменён, это известно т.к. его md5 запомнена в базе данных rpm).

В большинстве случаев новый опакеченый дефолтный конфиг при обнове положится в /etc/**.rpmnew . Изредка бывают обновы, когда по мнению сопровождающего конфиг вот прямо обязательно надо заменить, тогда старый (ручками правленный) переименовывается в .rpmsave.

Последнее время хорошей практикой считает хранить конфиги покрошенные на отдельные файлы типа

/etc/X11/xorg.conf.d/00-important
/etc/X11/xorg.conf.d/50-somestuff
/etc/X11/xorg.conf.d/70-someotherstuff

Но с xkb это не прокатит — оно всё хранится в /usr/share/X11/xkb. Насколько я помню, в Gentoo есть механизм защиты файлов от перезаписи при обновлении, если такого нет в Fedora, можно наваять какой-нибудь костылик, заменяющий заменённый обновлениями файл на сохранённый (я так в FreeBSD делал для fprintd).

Судя по пустому выхлопу rpm --query --configfiles `rpm --query --file /usr/share/X11/xkb/` там действительно всё затрётся при обновлении. Если бы мне такое надо было делать на федоре (и я разбирался в этой xkb-хрени, прямо скажем непростой), то сделал бы одно из следующего:

1. создал новый файл в этой директории (и как-то настроил бы чтобы именно он использовался)

2. сделал свой патченный пакет

3. похакал бы файл и запретил бы системе обновлять xkeyboard-config через исключения dnf.

создал новый файл в этой директории

Если директория как-то принадлежит пакету, менеджер пакетов может бахнуть её вне зависимости от её содержимого (не знаю про dnf, но некоторые таким страдают), заменив диру целиком, а не файлы в ней.

Для dnf это не так. Он очень бережно относится к файлам пользователя и удаляет только своё.

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