Linux что такое hal

Hardware abstraction layer

Hardware abstraction layer

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

В операционных системах семейства Windows NT HAL является неотъемлемой частью кода, исполняемого в режиме ядра, находится в отдельном загрузочном модуле, загружаемым совместно с ядром. [1] Это обеспечивает возможность использования одного и того же загрузочного модуля собственно ядра ОС Windows NT на ряде систем с различными архитектурами шин ввода/вывода, управления прерываниями и таймерами. К примеру, рабочие станции, основанные на SGI Intel x86, были не совместимы с IBM PC-совместимыми рабочими станциями, но благодаря HAL Windows NT мог запускаться на них. Аналогичным образом одно и то же ядро Windows NT используется и на современных системах с контроллером прерываний APIC, так и на устаревших системах без поддержки APIC.

BSD, Mac OS X, Linux, CP/M, MS-DOS, Solaris и некоторые другие портируемые ОС также имеют HAL, несмотря на то, что он не разрабатывался явно для выполнения описанных выше функций. Некоторые системы, такие как Linux, имеют возможность вставлять подобный слой, к примеру Adeos, во время работы. Ядро операционной системы NetBSD широко известно наличием чистого слоя абстрагирования от аппаратного обеспечения (HAL), что позволяет ему быть высоко-портируемым. Частью этой системы являются uvm(9) [2] /pmap(9) [3] , bus_space(9) [4] , bus_dma(9) [5] и другие подсистемы. Популярные шины, которые используются более чем на одной архитектуре, такие как ISA, EISA, PCI, PCI-E и др., также абстрагированы, позволяя написанным под них драйверам также быть высоко-портируемыми с минимальным изменением кода.

«Экстремальный» пример HAL может быть найден в архитектурах System/38 и AS/400. Большинство компиляторов для таких систем генерируют абстрактный машинный код. Лицензированный внутренний код (Licensed Internal Code, LIC) переводит этот виртуальный машинный код во внутренний(собственный) код процессора, на котором он запускается, и выполняет получившийся внутренний код. (Исключение составляют компиляторы, которые сами генерируют ЛИК; эти компиляторы не доступны за пределами IBM). К примеру, прикладное программное обеспечение и программное обеспечение операционной системы, расположенные над слоем ЛИК, скомпилированные на оригинальной архитектуре System/38, запускаются без каких-либо модификаций и перекомпиляций на последних системах AS/400. И это несмотря на тот факт, что лежащее в основе аппаратное обеспечение было кардинально изменено; по крайней мере три различных типа микропроцессоров находились в использовании.

HAL является даже более низким уровнем в компьютерных языках программирования, чем API, потому что он взаимодействует непосредственно с аппаратным обеспечением вместо ядра системы, следовательно HAL требует меньше процессорного времени чем API. Языки высокого уровня часто используют HAL и API для взаимодействия с компонентами более низкого уровня.

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

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

HAL (Hardware Abstraction Layer)

HAL (Hardware Abstraction Layer)

Предыдущий выпуск:	0.5.14 / 30 ноября 2009
Состояние разработки:	Разработка прекращена
Операционная система:	Linux, FreeBSD, NetBSD, OpenSolaris, Solaris
Платформа:	UNIX
Лицензия:	GNU General Public License и Academic Free License
Веб-сайт	freedesktop .org

Hardware Abstraction Layer (HAL, Слой аппаратных абстракций) — слой абстрагирования, реализованный в программном обеспечении, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, запускаемом на этом компьютере. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части ядра операционной системы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при её запуске на системах с различным аппаратным обеспечением. На персональных компьютерах HAL, по существу, может рассматриваться как драйвер материнской платы, позволяющий взаимодействовать инструкциям высокоуровневых языков программирования с низкоуровневыми компонентами, такими, как аппаратное обеспечение [Источник 1] .

В операционных системах семейства Windows NT HAL является неотъемлемой частью кода, исполняемого в режиме ядра, находится в отдельном загрузочном модуле, загружаемом совместно с ядром. Это обеспечивает возможность использования одного и того же загрузочного модуля собственно ядра ОС Windows NT на ряде систем с различными архитектурами шин ввода-вывода, управления прерываниями и таймерами. К примеру, рабочие станции, основанные на SGI Intel x86, были не совместимы с IBM PC-совместимыми рабочими станциями, но благодаря HAL Windows NT мог запускаться на них. Аналогичным образом одно и то же ядро Windows NT используется как на современных системах с контроллером прерываний APIC, так и на устаревших системах без поддержки APIC.

Windows Vista и выше (Windows Server 2008 и выше для серверов) автоматически определяют, какой уровень HAL должен быть использован во время загрузки.

BSD, Mac OS X, Linux, Solaris, CP/M, MS-DOS и некоторые другие портируемые ОС также имеют HAL, несмотря на то, что он не разрабатывался явно для выполнения описанных выше функций. Некоторые системы, такие, как Linux, имеют возможность вставлять подобный слой, к примеру, Adeos (англ.)русск., во время работы. Ядро операционной системы NetBSD широко известно наличием чистого слоя абстрагирования от аппаратного обеспечения (HAL), что позволяет ему быть высоко-портируемым. Частью этой системы являются uvm(9)/pmap(9), bus_space(9), bus_dma(9) и другие подсистемы. Популярные шины, которые используются более чем на одной архитектуре, такие, как ISA, EISA, PCI, PCI-E и др., также абстрагированы, позволяя написанным под них драйверам также быть высокопортируемыми с минимальным изменением кода.

«Экстремальный» пример HAL может быть найден в архитектурах System/38 (англ.)русск. и AS/400. Большинство компиляторов для таких систем генерируют абстрактный машинный код. Лицензированный внутренний код (LIC) переводит этот виртуальный машинный код во внутренний (собственный) код процессора, на котором он запускается, и выполняет получившийся внутренний код (исключение составляют компиляторы, которые сами генерируют LIC; эти компиляторы не доступны за пределами IBM). К примеру, прикладное программное обеспечение и программное обеспечение операционной системы, расположенные над слоем LIC, скомпилированные на оригинальной архитектуре System/38, запускаются без каких-либо модификаций и перекомпиляций на последних системах AS/400. И это несмотря на тот факт, что лежащее в основе аппаратное обеспечение было кардинально изменено; по крайней мере, три различных типа микропроцессоров находились в использовании.

HAL является даже более низким уровнем в компьютерных языках программирования, чем API, потому что он взаимодействует непосредственно с аппаратным обеспечением вместо ядра системы, следовательно, HAL требует меньше процессорного времени, чем API. Языки высокого уровня часто используют HAL и API для взаимодействия с компонентами более низкого уровня.

Операционные системы, имеющие HAL, легко портируются на различное оборудование. Это особенно важно для встраиваемых систем, которые должны работать на большом количестве различных платформ [Источник 2] .

Содержание

Текущее состояние

HAL является устаревшим и не рекомендуется к использованию. Решения, поставленные за основу при проектировании HAL, на практике оказались неэффективными и единственным выходом оказалось создание новой подсистемы и перенос функциональности. Такой системой стал udev. В настоящий момент поддержка HAL убрана из ядра, а самые крупные дистрибутивы (Ubuntu[3], Debian и Fedora) завершили переход и используют Udev.

Причины устранения

Основное преимущество в новой подсистеме udev (перед HAL) в том, что первый является событийно-управляемой и имеет тесную интеграцию с ядром, а HAL же, будучи реализованным в userspace в виде демона, вынужден периодически опрашивать ядро. Таким образом, использование событийно-управляемого udev значительно снижает нагрузку на систему, а значит и электропотребление. Также, описания правил для устройств выполнены в виде простых файлов конфигурации и гораздо проще и понятней для пользователей и разработчиков, чем XML примененный ранее в HAL. И наконец, udev разработан «с чистого листа», с учётом предыдущего опыта и в нём отсутствует устаревший или беспорядочный код.

Процесс миграции c HAL на udev

Изначально большая часть логики HAL была перенесена в udev, а правила в новый модуль — DeviceKit (не путать с PolicyKit или ConsoleKit). Однако вскоре схема udev+DeviceKit несколько изменилась — разработчики обнаружили, что большая часть аппаратуры уже управляется различными программными компонентами и необходимы только правила для дисков (udisks) и питания (upower). Проект DeviceKit был разбит на несколько более мелких частей и больше не используется и не упоминается. Таким образом современные дистрибутивы используют только Udev и правила к нему (udisks, upower — часть пакета udev-extras). Однако ввиду инерционности кода, многие программы всё ещё требуют устаревший HAL (в основном для обнаружения дисков) и поэтому дистрибутивы вынуждены поставлять HAL, фактически дублируя логику (например Qt3, и столкнувшийся с этим проект Trinity).

Источник

HAL (freedesktop.org)

HAL (сокр. от англ. Hardware Abstraction Layer ) — более не разрабатываемый демон, представлявший слой аппаратных абстракций для Linux и некоторых других Unix-образных систем.

Содержание

Задачи и история разработки

Проект был изначально создан Red Hat. Демон HAL получает информацию об аппаратном обеспечении от ядра ОС (в Linux, например, HAL черпает большую часть информации из sysfs), и предоставляет программам-клиентам через D-Bus в удобном для использования виде. Получение информации напрямую от ядра — процесс сложный и может быть сопряжен с проблемами с безопасностью; следовательно, наличие HAL сильно упрощает разработку программ, которые должны знать об аппаратной части компьютера (например, что пользователь только что отсоединил принтер или вставил флешку). Поскольку HAL на всех платформах предоставляет информацию в одном формате, независимо от операционной системы и версии ядра, он также облегчает разработку кроссплатформенного ПО. Кроме того, HAL делал возможным создавать автоматические действия (автоматическое монтирование дисков, автоматическую настройку принтеров итд) через правила.

HAL распространяется по лицензиям GNU General Public License и Academic Free License, и является свободным ПО [1] .

Текущее состояние

HAL является устаревшим и не рекомендуется к использованию. Решения, поставленные за основу при проектировании HAL, на практике оказались неэффективными и единственным выходом оказалось создание новой подсистемы и перенос функциональности. Такой системой стал udev [2] .

В настоящий момент поддержка HAL убрана из ядра,а самые крупные дистрибутивы (Ubuntu [3] , Debian [4] и Fedora [5] ) завершили переход и используют Udev.

Причины устранения

Основное преимущество в новой подсистеме udev (перед HAL) в том, что первый является событийно-управляемой и имеет тесную интеграцию с ядром, а HAL же, будучи реализованным в userspace в виде демона, вынужден периодически опрашивать ядро. Таким образом, использование событийно-управляемого udev значительно снижает нагрузку на систему, а значит и электропотребление. Также, описания правил для устройств выполнены в виде простых файлов конфигурации и гораздо проще и понятней для пользователей и разработчиков, чем XML примененный ранее в HAL. И наконец, udev разработан «с чистого листа», с учетом предыдущего опыта и в нем отсутсвует устаревший или беспорядочный код.

Процесс миграции c HAL на udev

Изначально большая часть логики HAL была перенесена в udev, а правила в новый модуль — DeviceKit (не путать с PolicyKit или ConsoleKit).

Однако вскоре схема udev+DeviceKit несколько изменилась — разработчики обнаружили, что большая часть аппаратуры уже управляется различными программными компонентами и необходимы только правила для дисков(udisks) [6] и питания(upower) [7] . Проект DeviceKit был разбит на несколько более мелких частей и больше не используется и не упоминается. [8]

Таким образом современные дистрибутивы используют только Udev и правила к нему (udisks, upower — часть пакета udev-extras). Однако ввиду инерционности кода, многие программы всё ещё требуют устаревший HAL (в основном для обнаружения дисков) и поэтому дистрибутивы вынуждены поставлять HAL, фактически дублируя логику (например Qt3, и столкнувшийся с этим проект Trinity).

Источник

Разборки с HAL’ом

Автор: Алексей Федорчук

Заметка была написана в связи в некоторой практической работой — и как её часть. Это во-первых. А во-вторых — в связи с тем, что проблемы автоматического общения с оборудованием возникают постоянно. И при этом — каждый раз новые. Ну неймётся разработчикам… Так что ниже — просто набор рецептов, опробованных на ограниченном материале.

Механизм udev, только что описанный в соответствующей заметке, отвечая за создание файлов устройств в соответствие с реальным оборудованием, в том числе и горячего подключения, не обеспечивает, однако, монтирования сменных накопителей. Это надо выполнять в ручном или в полуавтоматическом (с определением в файле /etc/fstab соответствующих устройств с опциями типа noauto,user и т.д.) режиме.

Однако есть и более радикальный метод настройки монтирования сменных носителей
от лица пользователя — использование механизма HAL (Hardware Abstraction Level).
В общем случае HAL предназначен для сокрытия различий в аппаратном обеспечении
от основной части ядра операционной системы, и в той или иной мере используется
в самых разных ОС, от Windows до NetBSD (именно абстрагирование от аппаратуры обеспечивает быстрое и безболезненное портирование последней на самые различные платформы).

Однако здесь речь пойдёт об одной из вполне конкретных реализаций HAL — той, что прижилась в Linux’е и может быть задействована в родственных BSD-системах. Это — демон, первоначально разрабатывавшийся фирмой Red Hat (первый разработчик — David
Zeuthen), а ныне представляющий собой составную часть freedesktop.org.
На официальной
странице проекта можно найти исходные тексты программы, её зависимости,
а также некоторую документацию — не очень богатую и, разумеется, англоязычную.

Демон HAL получает информацию об аппаратном обеспечении от ядра ОС (в
Linux, например, — из sysfs), и предоставляет её прикладным программам в подходящем
для них (и, что немаловажно, одинаковом для всех платформ) формате, избавляя их
от необходимости обращаться к ядру самостоятельно.

При посредстве демона HAL осуществляется, в частности, автоматическое монтирование
сменных накопителей. Однако этим его роль не исчерпывается. В современных версиях Xorg через него получает информацию об аппаратуре (клавиатуре и мыши) X-сервер
— что делает возможным запуск Иксов без традиционного их конфигурационного
файла /etc/X11/xorg.conf.

Следует, однако, подчеркнуть, что сам по себе демон HAL никакие накопители не
монтирует, никакие устройства в X-сервере не настраивает. Он лишь определяет
наличные устройства, фиксирует их параметры и представляет их в виде,
доступном тем программам, которые будут заниматься непосредственно указанными
действиями — монтированием, управлением раскладками клавиатуры, поведением
кнопок мыши, и так далее.

Вообще, просмотреть, какие устройства определяются HAL’ом, можно с помощью
кломанды:

Предупреждаю, вывод её будет весьма длинным (почему и целесообразно передать
его команде less). Зато внимательное его рассмотрение даст практически
исчерпывающую информацию о наличных устройствах и их параметрах, почему нам
ещё придётся к ней возвращаться. Например, так выглядит фрагмент, относящийся к
500-гигабайтному SATA-винчестеру Samsung:

Это вывод команды в так называемом “длинном” формате, обеспечиваемом опцией -l (или –long), каковая, впрочем, используется по умолчанию. Возможны и более компактные или более удочитаемые формы вывода команды lshal. Так, данная в форме

она представит только список устройств, без подробной расшифровки:

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

Посредством lshal с опцией -u можно вытащить сведения о некоем конкретном устройстве. Для чего нужно только знать его UDI (Unique Device Identifier — уникальный идентификатор устройства в системе именования HAL — это не то же самое, о чем говорилось в предыдущей заметке), который задаётся в качестве значения этой опции. Например, команда

даст нам полные сведения всё о том же винчестере:

в относительно читаемом виде.

“Посредничество” между демоном HAL и программами, использующими полученную
от него информацию, выполняется специальными конфигурационными файлами
— именно с помощью них можно переопределить параметры устройств и условия их
использования. Это, во-первых, файл /etc/PolicyKit/PolicyKit.conf, определяющий глобальную “политику” демона, во-вторых — набор fdi-файлов для конкретных устройств,
расположенных обычно в каталоге /etc/hal/fdi/policy. Следует отметить, что в
свежеустановленном дистрибутиве последний может быть практически пуст, однако их образцы, описывающие умолчания системы, можно найти в каталоге /usr/share/hal/fdi/policy/.

Все конфигурационные файлы HAL’а представляют собой XML-документы, начинающиеся с определения типа, например,

для файла PolicyKit.conf, или

для одного из fdi-файлов. Внутренний формат конфигов мы рассмотрим на конкретных примерах.

Начнём с монтирования сменных устройств. Во всех современных дистрибутивах Linux, которые мне доводилось видеть в последнее время, он задействован по умолчанию, соответствующие пакеты — Xorg, интегрированные декстопы GNOME, KDE, Xfce — уже собраны с его поддерожкой. Тем не менее, если это окажется не так, то настроить HAL руками тоже не составит большого труда.

Итак, для начала необходимо установить (средствами пакетного менеджмента данного дистрибутива) соответствующий пакет, который так и называется — hal. Хотя, как только что было сказано, при установке Иксов и какой-либо из интегрированных сред он уже будет инсталлирован как зависимость. Причём, возможно, вместе с собственно монтировщиком — в случае с GNOME и Xfce это будет пакет gnome-mount; если такового не окажется — нужно будет дополнительно озаботиться его установкой.

Далее, надо обеспечить запуск соответствующих демонов при старте системы. Собственно, демон, отвечающий за механизм HAL, так и называется — hald. Однако он зависит еще от нескольких стартовых служб — devd, usbd, dbus. Некоторые из них могут быть уже запущены. Определить, какие демоны уже функционируют можно, например, командой

Просматриваем её вывод и вписываем в файл (или файлы), отвечающий за запуск
стартовых служб, недостающие демоны.

Подчеркну, что никакой необходимости в установке прав доступа к файлам устройств или редактировании /etc/fstab, что требовалось при настройке пользовательского монтировании вручную, при использовании механизма HAL не возникает.

Теперь — собственно настройка. И тут возможны варианты, опять-таки зависящие
от дистрибутива. Рассмотрим самый простой способ: отправляемся в каталог
/etc/PolicyKit и обнаруживаем там файл PolicyKit.conf, о котором говорилось выше. По
умолчанию содержимое его примерно следующее:

Что предваряется следующей фразой:

Руководствуясь man (5) PolicyKit.conf, между строками

дописываем следующие строки:

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

Это пример для дистрибутивов, в которых группа wheel задействована: только её
члены могут получить доступ к правам администратора, например, командой su.
Но в принципе группу можно определить произвольно — главное, чтобы пользователь,
которому разрешено автоматическое монтирование сменных накопителей, был её членом.

И после реинициализации системы (например, посредством временного перехода в однопользовательский режим или полного рестарта) указанный пользователь получает возможность автоматического монтирования сменных устройств сразу вслед за их помещением в привод или подсоединением к USB-порту. Точнее, монтирование это происходит само, без всякого его участия.

По собственному опыту, через HAL нормально монтируется всё, что способно монтироваться: CD- и DVD-диски, флэшки, внешние винчестеры с USB-интерфейсом, носители внутри фотокамер и они же, подключённые через кард-ридер. Единственная проблема у меня возникла с флэшкой, переформатированной через штатную опцию Windows, то есть с файловой системой VFAT не на разделе, а непосредственно на raw-устройстве. Впрочем, и было это не в Linux’е, а во FreeBSD.

После монтирования флэшки или компакта описанным способом на рабочем столе
интегрированного десктопа типа KDE, GNOME, Xfce появляется соответствующая
пиктограмма, а команда mount без параметров показывает в списке смонтированных
файловых систем соответствующее устройство.

Содержимое смонтированного устройства можно просмотреть в каталоге
/media/mount_point. Точке монтирования, как правило, присваивается имя метки (Label)
накопителя. Если таковая не была задана — каталог для монтирования будет носить
имя типа Disk1 и так далее. Иногда раньше бывали случаи, когда устройство без
метки отказывалось монтироваться, но я с этим давно уже не сталкивался.

При необходимости извлечь автоматически смонтированное устройство его, тем не
менее, следует размонтировать. Для этого достаточно щелкнуть правой клавишей
на указанной пиктограмме и в контекстном меню выбрать соответствующий пункт —
Отключить том для USB-накопителей или Извлечь том — для компакт-диска.

Однако в некоторых ситуациях возникает необходимость в ручном отмонтировании
автоматически смонтированного накопителя. По крайней мере с одной такой я неоднократно сталкивался: это запись уже использовавшихся CD-RW или DVD-RW. Будучи вставленные в привод, они автоматически монтируются и некоторыми фронт-эндами для записи дисков (например, Brasero), не могут быть повторно записаны даже после принудительной очистки. Подчеркну — это баг конкретных программ записи (или даже конкретных их сборок — например, Brasero в дистрибутиве Zenwalk), а не самого механизма HAL.

Решается проблема просто, хотя и не очень изящно: нужно просто в командной
строке (например, терминала) от лица администратора отмонтировать
“неправильное” устройство, например, так:

Указывать в качестве аргумента имя устройства предпочтительно, потому что
метки компакт-дисков (и, соответственно, точки их монтирования) иногда могут
иметь длинные и нечленораздельные имена.

Ещё раз подчеркну, что в большинстве современных дистрибутивов Linux’ никаких
специальных действий по настройке автоматического монтирования делать,
скорее всего не придётся. В отличие, скажем, от FreeBSD, где хотя HAL и задействуется
точно также, как в Linux’е, но по умолчанию не настроен совершенно (на счет чего имеется соответствующая заметка).

А вот с настройками Иксов через HAL, возможно, придётся иметь дело в любом случае. Ибо современные версии X-сервера (в исполнении Xorg) именно через него по умолчанию получают сведения об аппаратуре, не используя данные в файле
/etc/X11/xorg.conf. Такое положение можно (пока?) изменить, но, похоже, на ближайшее время именно оно будет соответствовать генеральной линии развития, так что разбираться с этим так или иначе придётся.

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

Для начала проверяем текущее состояние с раскладками клавиатуры. Это цели служит всё та же команда lshal. Для начала, дав её без опций в составе конструкции примерно такого вида

выловим UDI нашего устройства ввода:

который и зададим как значение опции -u, повторив команду:

Нас будет интересовать лишь фрагмент её вывода:

В котором мы видим название клавиатуры, имя драйвера, ею управляющего, доступные
ракладки и модель.

Для начала обращаем внимание на драйвер: при использовании HAL вместо
стандартного драйвера клавиатуры kbd (он содержится в пакете xserver-xorg-input-kbd) по умолчанию применяется драйвер evdev (пакет xserver-xorg-input-evdev), хотя, вроде бы, и kbd не возбраняется. Я лично не заметил между ними никакой разницы — единственное, нужно проследить за тем, чтобы указанный здесь драйвер соответствовал установленному пакету.

Далее мы видим, что в наличие имеется единственная раскладка, и та американская;
соответственно, о каких-либо вариантах и переключателях говорить не приходится.
Вот это положение нам и надлежит исправить.

За настройки клавиатуры отвечает файл вида 10-keymap.fdi — умолчальный его вариант
можно найти в каталоге /usr/share/hal/fdi/policy/10osvendor: точный путь может
различаться в разных дистрибутивах, поэтому для страховки лучше воспользоваться
поиском (например, утилитой find) по маске \*keymap.fdi. Во избежание разночтений копируем его в место, специально предназначенное для конфигурационных файлов — а именно:

После чего открываем в любимом редакторе с правами суперпользователя:

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

В данном примере задано переключение с латиницы на кирилицу по левой win-клавише, а в качестве индикатора кириллической раскладки выбран ScrollLock; разумеется, эти значения следует заменить на привычные.

В качестве варианта раскладки, вместо winkeys (соответствующего фабричной маркировке всех современных клавиатур) при желании можно указать legacy (маркировка
старых клавиатур времён “чёрного” DOS’а) или typewriter (маркировка пишущих машинок — по моему мнению, самая разумная, но, увы, напрочь забытая).

После этого перезапускаем демона HAL:

И, передя на кириллицу посредством выбранного переключателя, убеждаемся в возможности ввода русских букв. Для дополнительного контроля повторяем команду

в выводе которой наблюдаем все сделанные нами изменения:

Впрочем, у меня в Xubuntu изменения в выводе команды lshal появляются только после
перезапуска X-сервера.

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

Кроме задачи подключения HAL’а, в ряде случаев не менее актуальной оказывается обратная задача — его отключения, по крайней мере отдельных компонентов. И именно тех, которые касаются настройки клавиатуры и мыши в Иксах.

Как я уже говорил, современные версии X-сервера благополучно могут стартовать без всякого конфигурационного файла вообще (то есть без /etc/X11/xorg.conf). Тем не менее, многие пользователи предпочитают использовать его и поныне — во-первых, в силу привычки (у меня, например, до недавнего времени один и тот же xorg.conf на протяжении многих лет кочевал, с минимальными правками, из дистрибутива в дистрибутив и из системы в систему).

Да и гораздо проще дописать в автоматически сгенерированный, например, посредством

конфиг две-три строки, чем разбираться с не вполне прозрачными XML-файлами HAL’а.

И вот тут могут начаться проблемы: результаты автоопределения оборудования через HAL, в частности, мышь и клавиатура, вступают в противоречие с их описанием в соответствующих секциях xorg.conf.

И в результате после успешного, казалось бы, старта Иксов (вне зависимости, через startx или какой-либо менеджер сеансов) оба эти устройства не подают признаков жизни. А в файле /var/log/Xorg.0.log обнаруживается такое сообщение:

Правда, решается эта проблема очень просто: достаточно в секцию Section
“ServerLayout” файла /etc/X11/xorg.conf после строк,
идентифицирующих устройства ввода

вписать запрет их автоматического добавления:

После чего Иксы наконец благополучно запускаются. Не возникает при этом и проблемы с переключением раскладок.

И в заключение надо сказать несколько слов о D-Bus. Потому что это тот самый механизм, который обеспечивает передачу данных об оборудовании, полученных посредством HAL’а, системным и прикладным программам, таковые использующим. Хотя значение его далеко выходит за эти рамки.

D-Bus – это один из механизмов межпроцессного взаимодействия (иначе IPC – InterProcess Communication), подобный широко известному CORBA или DCOP, до недавнего времени использовавшемуся в KDE вплоть до вертки 3.X включительно. Он, как и HAL, разрабатывается в рамках метапроекта freedesktop.org (официальная страница проекта здесь ). И первоначально использовался в GNOME, хотя ныне передаваемые по нему данные
доступны и в других рабочих средах (Xfce, KDE, начиная с ветки 4.X) и системах разработки (Mono, Java и другие).

Практически этот механизм реализован в виде одноимённого демона dbus (как уже говорилось, он выступает в качестве записимости пакета hal), работа которого организована по шинному принципу. Шин, то есть каналов передачи сообщений, две:

• системная шина – по ней происходит обмен сообщениями с другими демонами (например, с тем же демоном hal);
• сессионная шина –- создаёт для зарегистрированного в системе пользователя, для каждого из которых запускается собственная копия демона; по этой шине происходит обмен сообщениями с приложениями, запущенными пользователем (например, X-сервером или программой монтирования накопителей).

Я не очень представляю, каково может быть вмешательство пользователя в работу демона dbus (помимо установки соответствующего пакета и обеспечения его запуска). Разве что сочинить сценарий для отслеживания устройств, и поиграться с подсоединением и отсоединением мыши, USB-накопителей и так далее.

Источник