Иллюстрированный самоучитель по теории операционных систем

Архитектура драйвера

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

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

В примере 10.1 приводится скелет функции write () драйвера последовательного устройства в системе Linux. Скелет упрощенный (в частности, никак не решается проблема реентерабельности функции foo_write. Использованный механизм синхронизации с обработчиком прерывания также оставляет желать лучшего), но имеет именно такую архитектуру, которая была описана ранее. Текст цитируется по документу [HOWTO khg], перевод комментариев и дополнительные комментарии автора.

Пример 10.1. Скелет драйвера последовательного устройства для ОС Linux.

Примечание
Обратите внимание, что кроме инициализации устройства драйвер перед засыпанием еще устанавливает «будильник» – таймер, который должен разбудить процесс через заданный интервал времени. Это необходимо на случай, если произойдет аппаратная ошибка и устройство не сгенерирует прерывания. Если бы такой будильник не устанавливался, драйвер в случае ошибки мог бы заснуть навсегда, заблокировав при этом пользовательский процесс. В нашем случае таймер также используется, чтобы разбудить процесс, если прерывание произойдет до вызова interruptible_sleep_on основной нитью.

Многие устройства, однако, требуют для исполнения некоторых, даже относительно простых, операций, несколько команд и несколько прерываний. Так, при записи данных посредством контроллера гибких дисков, драйвер должен:

• включить мотор дисковода;
• дождаться, пока диск разгонится до рабочей скорости (большинство контроллеров генерируют по этому случаю прерывание);
• дать устройству команду на перемещение считывающей головки;
• дождаться прерывания по концу операции перемещения;
• запрограммировать ПДП и инициировать операцию записи;
• дождаться прерывания, сигнализирующего о конце операции.

Лишь после этого можно будет передать данные программе. Наивная реализация таких многошаговых операций могла бы выглядеть так (за основу по-прежнему взят код из [HOWTO khg], обработка ошибок опущена), как показано в примере 10.2.

HID Architecture

The architecture of the HID driver stack in Windows is built on the class driver named hidclass.sys. Clients and transport minidrivers access the class driver from user-mode or kernel-mode.

The HID Class Driver

The system-supplied HID class driver is the WDM function driver and bus driver for the HID device setup class (HIDClass). The executable component of the HID class driver is hidclass.sys. The HID Class driver is the glue between HID clients and various transports. This allows a HID Client to be written in an independent way from transports. This level of abstraction allows clients to continue to work (with little to no modifications) when a new standard, or a 3rd party transport is introduced.

The following is an architectural representation.

The preceding diagram includes the following:

• HID Clients – Identifies the Windows and 3rd party clients and their interfaces.
• HID Class driver — The hidclass.sys executable.
• HID Transport Minidriver — Identifies the Windows and 3rd party transports and their interfaces.

Here is the device stack diagram of a generic HID client and transport.

Here is another device stack diagram showing HID keyboard and mouse collections over USB.

HID Clients

The HID Clients are drivers, services or applications that communicate with HIDClass.sys and often represent a specific type of device (E.g. sensor, keyboard, mouse, etc). They identify the device via a hardware ID or a specific HID Collection and communicate with the HID Collection via the following guidance.

User-mode drivers and applications, and kernel-mode drivers, do the following to operate HID collections:

• User-mode drivers and applications use HIDClass support routines (HidD_Xxx) to obtain information about a HID collection.
• Kernel-mode drivers, user-mode drivers and applications use HID parsing support routines (HidP_Xxx), and kernel-mode drivers use HID class driver IOCTLs to handle HID reports.

The following table is a simplification of the information listed above.

Mode	Drivers	Applications
User Mode	HidD_Xxx	HidP_Xxx
Kernel Mode	HidD_Xxx OR IOCTL_HID_xxx	N/A

HID Clients Supported in Windows

Windows supports the following top-level collections:

Usage Page	Usage	Windows 7	Windows 8	Windows 10	Notes	Access Mode
0x0001	0x0001 — 0x0002	Yes	Yes	Yes	Mouse class driver and mapper driver	Exclusive
0x0001	0x0004 — 0x0005	Yes	Yes	Yes	Game Controllers	Shared
0x0001	0x0006 — 0x0007	Yes	Yes	Yes	Keyboard / Keypad class driver and mapper driver	Exclusive
0x0001	0x000C	No	Yes	Yes	Flight Mode Switch	Shared
0x0001	0x0080	Yes	Yes	Yes	System Controls (Power)	Shared
0x000C	0x0001	Yes	Yes	Yes (For both Windows 10 and Windows 10 Mobile)	Consumer Controls	Shared (For both Windows 10 and Windows 10 Mobile)
0x000D	0x0001	Yes	Yes	Yes	External Pen Device	Exclusive
0x000D	0x0002	Yes	Yes	Yes	Integrated Pen Device	Exclusive
0x000D	0x0004	Yes	Yes	Yes	Touchscreen	Exclusive
0x000D	0x0005	No	Yes	Yes	Precision Touchpad (PTP)	Exclusive
0x0020	*Multiple	No	Yes	Yes	Sensors	Shared
0x0084	0x004	Yes	Yes	Yes	HID UPS Battery	Shared
0x008C	0x0002	No	Yes (Windows 8.1 and later)	Yes	Barcode Scanner (hidscanner.dll)	Shared

In the preceding table, the access mode for input HID clients is Exclusive to prevent other HID clients from intercepting or receiving global input state when they are not the target recipient of that input. Therefore, for security reasons RIM (Raw Input Manager) opens all such devices exclusively.

If device is opened in Exclusive mode by RIM (Raw Input Manager) user can still open HID device interface without requesting read and write permissions and obtain HID device information via HIDClass support routines (HidD_GetXxx).

Sharing mode allows multiple applications to access the device. For example, multiple applications can access a barcode scanner to inquire about device capabilities and retrieve statistics. However, retrieving decoded data from a barcode scanner is done in Exclusive mode. Usages are defined by the USB-IF Usage Tables.

*Multiple: Sensors usages from 0x00 – 0xFF are segmented for different purposes. For example 0x10 indicates a Biometric sensor; 0x40 indicates a Light sensor. Those allocations are not contiguous. For the list of sensor usages, see USB-IF Device Class Defnitions for HID. For information about sensors usages that are supported in Windows, HID Sensors Usages.

The HID Transport Driver

The HID class driver is designed to use HID minidrivers to access a hardware input device. A HID minidriver abstracts the device-specific operation of the input devices that it supports. The HID minidriver binds its operation to the HID class driver by registering with the HID class driver. The HID class driver communicates with a HID minidriver by calling the minidriver’s support routines. The HID minidriver, in turn, sends communications down the driver stack to an underlying bus or port driver.

HID Transports Supported in Windows

See this page for a list of supported HID Transports.

USB Generic HID Test in the Windows Hardware Lab Kit (HLK) covers HidUsb and HidClass drivers. There is no HLK test for third-party HID mini drivers.

Printer Driver Architecture

Print jobs are created by applications through calls to Microsoft Win32 GDI or, in Windows Vista, Windows Presentation Foundation (WPF) functions. The Win32 functions spool application data as EMF records for later playback by the EMF print processor, or they can immediately render a printable image for each document page. The WPF functions spool application data as an XPS spool file.

Prior to Windows Vista, applications communicated printer settings to the printer by using a DEVMODEW structure. In Windows Vista, the Print Ticket and Print Capabilities technologies communicate printer settings so that printer settings are more compatible across printers and applications.

Image rendering, whether performed immediately or during print processing, is performed in the print driver:

A GDI-based printer driver performs the image rendering during the playback of EMF records from the spool file and is controlled by the GDI rendering engine. During the rendering operation, the GDI rendering engine calls the appropriate Windows 2000 and later printer driver for assistance.

XPSDrv print drivers use a series of processing filters to process the XPS spool file content for output to the printer.

Windows 2000 and later GDI-based printer drivers must:

Assist GDI in rendering print jobs by providing printer-specific drawing capabilities that GDI cannot support.

Send the rendered image’s data stream to the print spooler.

Provide a user interface to the modifiable configuration parameters that are associated with printers and print documents, such as which input and output trays are selected, the number of copies, image resolution and orientation, and so on.

XPSDrv printer drivers have the same user interface responsibility as the GDI-based drivers and are also responsible for processing the print job data and sending the data to the printer. XPSDrv printer drivers, however, do not need to use GDI to render the page images for the printer.

Windows 2000 and later printer drivers are made up of a set of printer driver components that divide a driver’s drawing and user interface operations into separate DLLs. XPSDrv printer drivers are also made up of components that divide the configuration and the drawing and rendering functions into separate objects.

This section is intended to help you understand the different types of printer drivers that the Windows 2000 and later operating systems support, but you should also remember that the following three printer drivers are shipped with the operating system:

These three drivers support most printing devices that end-users can purchase today. You need to write a printer driver only if your printing device is not compatible with the appropriate Microsoft-supplied driver. You can support most new printers by simply adding a printer data file to one of the Microsoft-supplied drivers. Devices that might require a new driver include those containing hardware drawing accelerators controlled by proprietary command sequences.

This section contains the following topics, which describe the Windows printing architecture.

Универсальный драйвер аудиоустройств (Universal Audio Architecture, UAA) класса High Definition Audio версии 1.0а для Windows Server 2003, Windows XP и Windows 2000

Эта статья предназначена для опытных пользователей. Если дополнительные способы устранения неполадок слишком сложны, можно обратиться за помощью к специалисту или в службу поддержки. Сведения о том, как это сделать, см. на веб-сайте корпорации Майкрософт по следующему адресу:

ВВЕДЕНИЕ

Выпущена версия 1.0a универсального драйвера аудиоустройств класса High Definition Audio для системы Microsoft Windows. Данный выпуск поддерживает устройства класса High Definition Audio и модемы, известные корпорации Майкрософт на 1 августа 2004 года. Это вторая версия данного драйвера.

Версия 1.0a драйвера устройств класса High Definition Audio не будет работать с устройствами High Definition Audio, которые были заявлены в Майкрософт после 1 августа 2004 года.

Перед установкой драйвера устройства класса High Definition Audio версии 1.0a необходимо удалить драйвер версии 1.0.

Дополнительные сведения о драйвере UAA класса High Definition версии 1.0 см. в следующей статье базы знаний Майкрософт:

835221 Универсальный драйвер аудиоустройств (Universal Audio Architecture, UAA) класса High Definition Audio для Windows Server 2003, Windows XP и Windows 2000

Дополнительная информация

Сведения об обновлении

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

Если функция доступна для загрузки, в начале этой статьи базы знаний отображается раздел «Исправление доступно для загрузки». Если этот раздел отсутствует, обратитесь в службу поддержки пользователей Майкрософт, чтобы получить ее.

Примечание. В случае возникновения других проблем и при необходимости устранения неполадок может потребоваться отдельный запрос на обслуживание. Дополнительные услуги по технической поддержке, не связанные с этой функцией, оплачиваются на стандартных условиях. Чтобы просмотреть полный список телефонных номеров службы поддержки пользователей Майкрософт или создать отдельный запрос на обслуживание, посетите указанный ниже веб-сайт:

http://support.microsoft.com/contactus/?ws=support?ln=ruПримечание. В форме «Исправление доступно для загрузки» отображаются языки, для которых доступна эта функция. Если нужный вам язык не отображается, это означает, что функция для данного языка отсутствует.

Предварительные условия (и необходимые компоненты)

Драйвер совместим со следующими версиями операционных систем:

Исходный выпуск Microsoft Windows Server 2003

Примечание. Данный драйвер не совместим с Windows Server 2003 с пакетом обновления 1 (SP1) или более поздним пакетом обновления.

Microsoft Windows XP с пакетом обновления 1 (SP1) или с пакетом обновления 2 (SP2)

Windows 2000 с пакетом обновления 4 (SP4)

Необходимость перезагрузки

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

Сведения о файлах

Английская версия этого обновления имеет атрибуты файлов, приведенные в следующей таблице, или более поздние. Дата и время для файлов указаны в формате универсального всемирного времени (по Гринвичу). При просмотре сведений о файле в системе происходит перевод соответствующих значений в местное время. Чтобы выяснить разницу между временем в формате UTC и местным временем, откройте вкладку Часовой пояс элемента «Дата и время» на панели управления.