Microsoft Input Configuration Device Driver Download
Haldis Momeni
The following figure shows the configuration of device objects for a Plug and Play PS/2-style keyboard and mouse device. Each class driver creates an upper-level class filter device object (filter DO) that is attached to a function device object (FDO) through an optional upper-level device filter DO. An upper-level device filter driver creates the upper-level device filter DO. I8042prt creates the function DO and attaches it to a physical device object (PDO) created by the root bus driver.
Kbdclass and Mouclass can support more than one device in two different modes. In the one-to-one mode, each device has an independent device stack. The class driver creates and attaches an independent class DO to each device stack. Each device stack has its own control state and input buffer. The Microsoft Win32 subsystem accesses input from each device through a unique file object.
The Microsoft Win32 subsystem opens all keyboard and mouse devices for its exclusive use. For each device class, the Win32 subsystem treats input from all the devices as if the input came from a single input device. An application cannot request to receive input from only one particular device.
The Win32 subsystem dynamically opens Plug and Play input devices after it receives notification from the Plug and Play manager that a GUID_CLASS_KEYBOARD or GUID_CLASS_MOUSE device interface is enabled. The Win32 subsystem closes Plug and Play devices after it receives notification that an opened interface is disabled. The Win32 subsystem also opens legacy devices by name (for example, "\Device\KeyboardLegacyClass0"). Note that once the Win32 subsystem successfully opens a legacy device, it cannot determine if the device is later physically removed.
If the device is in the Plug and Play started state, the class driver sends the IRP_MJ_CREATE request down the driver stack. Otherwise the class driver completes the request without sending the request down the driver stack. The class driver sets the trusted file that has read access to the device. If there is a grandmaster device, the class driver sends a create request to all the ports that are associated with the subordinate class devices.
The class drivers must connect their class service to a device before the device can be opened. The class drivers connect their class service after they attach a class DO to a device stack. The function driver uses the class service callback to transfer input data from a device to the class data queue for the device. The function driver's ISR dispatch completion routine for a device calls the class service callback. Kbdclass provides the class service callback KeyboardClassServiceCallback, and Mouclass provides the class service callback MouseClassServiceCallback.
A vendor can modify the operation of a class service callback by installing an upper-level filter driver for a device. The sample keyboard filter driver Kbfiltr defines the KbFilter_ServiceCallback callback, and the sample mouse filter driver Moufiltr defines the MouFilter_ServiceCallback callback. The sample filter service callbacks can be configured to modify the input data that is transferred from the port input buffer for a device to the class data queue. For example, the filter service callback can delete, transform, or insert data.
The class driver sends an internal device connect request down the device stack (IOCTL_INTERNAL_KEYBOARD_CONNECT or IOCTL_INTERNAL_MOUSE_CONNECT). The class connect data is specified by a CONNECT_DATA structure that includes a pointer to the class device object, and a pointer to the class service callback.
After the filter driver receives the connect request, it saves a copy of the class connect data, and replaces the request's connect data with filter connect data. The filter connect data specifies a pointer to the filter device object and a pointer to the filter driver service callback. The filter driver then sends the filtered connect request to the function driver.
In Microsoft Windows operating systems, PS/2-compatible scan codes provided by an input device are converted into virtual keys, which are propagated through the system in the form of Windows messages. If a device produces an incorrect scan code for a certain key, the wrong virtual key message will be sent. This can be fixed by writing a filter driver that analyzes the scan codes generated by firmware and modifies the incorrect scan code to one understood by the system. However, this is a tedious process and can sometimes lead to severe problems, if errors exist in the kernel-level filter driver.
For an absolute pointing device, the device's function driver must set the LastX, LastY, and Flags members of the MOUSE_INPUT_DATA structures in the following way:
If the input should be mapped by Window Manager to an entire virtual desktop, the driver sets the MOUSE_VIRTUAL_DESKTOP flag in Flags. If the MOUSE_VIRTUAL_DESKTOP flag is not set, Window Manager maps the input to only the primary monitor.
An upper-level filter driver is required. The filter driver supplies an IsrHook callback and a class service callback. I8042prt calls the IsrHook to handle raw device input, and calls the filter class service callback to filter the input. The filter class service callback, in turn, calls MouseClassServiceCallback. The combination of the IsrHook callback and the class service callback handles device-specific input, creates the required MOUSE_INPUT_DATA structures, scales the device input data, and sets the MOUSE_MOVE_ABSOLUTE flag.
A Plug and Play function driver is required. The function driver creates the required MOUSE_INPUT_DATA structures, scales the device input data, and sets the MOUSE_MOVE_ABSOLUTE flag before it calls MouseClassServiceCallback.
A device-specific function driver is required. The function driver creates the required MOUSE_INPUT_DATA structures, scales the device input data, and sets the MOUSE_MOVE_ABSOLUTE flag before it calls MouseClassServiceCallback.
In the device's Properties dialog box, click the Driver tab, and then click Update Driver to start the Hardware Update Wizard. Follow the instructions to update the driver. If updating the driver does not work, see your hardware documentation for more information.
Note You may be prompted to provide the path of the driver. Windows may have the driver built-in, or may still have the driver files installed from the last time that you set up the device. If you are asked for the driver and you do not have it, you can try to download the latest driver from the hardware vendor's website.
Note You may be prompted to provide the path of the driver. Windows may have the driver built-in, or may still have the driver files installed from the last time that you set up the device. However, sometimes, it will open the New Hardware Wizard which may ask for the driver. If you are asked for the driver and you do not have it, you can try to download the latest driver from the hardware vendor's website.
The device is installed incorrectly. The problem could be a hardware failure, or a new driver might be needed. Devices stay in this state if they have been prepared for removal. After you remove the device, this error disappears.
The device requires manual configuration. See the hardware documentation or contact the hardware vendor for instructions on manually configuring the device. After you configure the device itself, you can use the Resources tab in Device Manager to configure the resource settings in Windows.
A duplicate device was detected. This error occurs when a bus driver incorrectly creates two identically named sub-processes (known as a bus driver error), or when a device with a serial number is discovered in a new location before it is removed from the old location.
The system hive has exceeded its maximum size and new devices cannot work until the size is reduced. The system hive is a permanent part of the registry associated with a set of files that contains information related to the configuration of the computer on which the operating system is installed. Configured items include applications, user preferences, devices, and so on. The problem might be specific devices that are no longer attached to the computer but are still listed in the system hive.
Windows cannot apply all of the properties for this device. Device properties may include information that describes the device's capabilities and settings (such as security settings for example). To fix this problem, you can try reinstalling this device. However,we recommend that you contact the hardware manufacturer for a new driver. (Code50)
Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)
Human Interface Devices (HID) is a device class definition to replace PS/2-style connectors with a generic USB driver to support HID devices such as keyboards, mice, game controllers, and so on. Prior to HID, devices could only utilize strictly defined protocols for mice and keyboards. Hardware innovation required either overloading data in an existing protocol or creating nonstandard hardware with its own specialized driver. HID provides support for boot mode devices while adding support for innovation through extensible, standardized, and easily programmable interfaces.
HID began with USB but was designed to be bus-agnostic. It was designed for low latency, low bandwidth devices but with flexibility to specify the rate in the underlying transport. The USB-IF ratified the specification for HID over USB in 1996. Support for HID over other transports soon followed. Details on currently supported transports can be found in HID Transports Supported in Windows. Third-party, vendor-specific transports are also allowed via custom transport drivers.
8d45195817