WO2015165774A1

WO2015165774A1 - Automatic device driver switching

Info

Publication number: WO2015165774A1
Application number: PCT/EP2015/058597
Authority: WO
Inventors: Martin LIEPERT
Original assignee: Sfnt Germany Gmbh
Priority date: 2014-04-28
Filing date: 2015-04-21
Publication date: 2015-11-05

Abstract

To install a peripheral to a computer, computers have generic device drivers. A certain device driver for a certain peripheral is provided on certain computers. That peripheral is operable either with the certain device driver or with a generic class device driver. When a peripheral is connected to a computer, the computer generates messages to request configuration information from the peripheral. The certain computer modifies a message to signal the presence of the certain device driver, the modification affecting only an unused part of the message. If the certain peripheral detects the modification, it supplies specific configuration information identifying the specific device driver, and the computer activates the specific device driver. If the modification is not detected, the certain peripheral supplies configuration information identifying a generic device driver, and the computer activates the requested generic device driver. Other peripherals ignore the modification, and request their usual device drivers.

Description

AUTOMATIC DEVICE DRIVER SWITCHING

BACKGROUND

[0001] The present specification relates to attaching peripheral devices to a computer or similar.

[0002] Certain types of external connector on computers and similar devices, for example, the Universal Serial Bus (USB) port that is currently common on personal computers and many other "Plug and Play" interfaces, such as Bluetooth and Fire Wire, rely on a host, which may be implemented in specialized hardware or may be software running on a general purpose processor, to manage interactions with any devices that may be attached to the connector. When a new peripheral device is attached, this typically involves the host obtaining information about the device and selecting the correct driver for the device. In the USB standard, that process is known as "enumerating" the device. The USB host has a number of standard device classes, such as "Human Interface Device" (HID) and "Mass Storage Device," and many devices are designed to function with the drivers for one of those standard classes.

[0003] The USB standard also allows a device to use an individual "vendor specific" device driver installed on the host machine. That makes it possible for a device to connect to a USB port and operate, even if the device requires functionality that is not supported by any of the standard USB device classes. However, if the device demands an individual driver, and that driver is not installed on the host machine, the enumeration process will fail, and the device will not be able to function.

SUMMARY

[0004] According to one embodiment, there are provided systems, methods, and computer programs in which a standard message from the host system to the device, at an early stage in the enumeration process, is modified to indicate whether a specific device driver is installed on the host machine. The corresponding device detects the presence or absence of that indication. If the driver is present, the device enumerates as a device using that driver, while configuring itself for that driver based communication protocol. If the driver is not present, the device enumerates as a device using one of the standard classes. The HID class may be suitable in many cases, because that class allows a wide variety of data signals both to and from the device. Many devices can function adequately in one of the standard USB classes, even if they would function better with their own specific device driver. [0005] According to an embodiment, there is provided a method of installing a peripheral device to a computer, comprising providing on the computer a specific device driver for the peripheral device. The computer comprises at least one generic class device driver, and the peripheral device is operable either with the specific device driver or with the at least one generic class device driver. When the peripheral device is connected to the computer, the computer generates at least one message to request configuration information relating to the peripheral device. The computer makes a modification to the at least one message to signal the presence of a device driver for the peripheral device, wherein the modification affects only an unused part of the at least one message under a relevant standard. The peripheral device detects the modification. Where the modification is detected the peripheral device supplies specific configuration information identifying the specific device driver. Where the computer receives the specific configuration information, the computer activates the specific device driver. In this embodiment, if the computer does not make the specific modification to the at least one message, the peripheral device assumes that the specific device driver is not available and supplies more generic configuration information identifying a generic device driver. Where the computer receives the more generic configuration information, the computer activates an appropriate generic device driver.

[0006] An embodiment of a method of installing a peripheral device to a computer comprises providing on the computer a specific device driver for the peripheral device, connecting the peripheral device to the computer, wherein the computer comprises at least one generic class device driver, and the peripheral device is operable either with the specific device driver or with the at least one generic class device driver, by the computer, generating at least one message to request configuration information relating to the peripheral device, by the computer, making a modification to the at least one message to signal the presence of a device driver for the peripheral device, wherein the modification affects only an unused part of the at least one message under a relevant standard, by the peripheral device, detecting the modification, where the modification is detected, by the peripheral device, supplying specific configuration information identifying the specific device driver; and by the computer, where the specific configuration information is received, activating the specific device driver.

[0007] An embodiment of a computer comprises a port for connection of peripheral devices, complying with a standard; a host for the port, operative to exchange messages with a peripheral device connected to that port, and to configure the port differently for different ones of peripheral devices dependent on information supplied by a respective peripheral device in accordance with the standard, the host including at least one generic class device driver for a class of peripheral devices; a specific device driver for a specific one of the peripheral devices; the computer being operative to make a modification to at least one message specified by the standard to signal the presence of a device driver for the peripheral device, wherein the modification affects only a part of the at least one message unused under the standard; the computer being operative to activate the specific device driver or to activate a said generic class device driver as requested by the peripheral device.

[0008] An embodiment of a method for installing a peripheral device to a computer, comprises connecting the peripheral device to the computer; and at the peripheral device, receiving at least one message to request configuration information relating to the peripheral device, inspecting the at least one message for a specific modification in an unused part of the at least one message under a relevant standard, where the modification is detected, supplying to the computer specific configuration information identifying a device driver specific to said peripheral device; and where the modification is not detected, supplying to the computer configuration information identifying a generic class device driver; and on completion of a configuration process, operating in cooperation with the identified device driver.

[0009] An embodiment of a peripheral device for a computer is connectable to a port of the computer in accordance with a standard, and is operative: to receive from the computer at least one message to request configuration information relating to the peripheral device; to inspect the at least one message for a specific modification in an unused part of the at least one message under a relevant standard; where the modification is detected, to supply to the computer specific configuration information identifying a device driver specific to said peripheral device; where the modification is not detected, to supply to the computer configuration information identifying a generic class device driver; and on completion of a configuration process, operating in cooperation with the identified device driver.

[0010] In these and other embodiments, the modified part of the message is "unused" only in the sense that if a peripheral device is connected that does not use the specific device driver, and complies strictly with the relevant standard, the peripheral device does not react to the modification, and responds to the message as if the modification were not there. The part of the message may be a part that is used in other contexts. The same part may be used, preferably with different modifications, for different instances of the described method. If more than one specific device driver in accordance with the described method is to be provided on the same computer, the modifications may overlap, but care is desirable to ensure that the modifications are not inconsistent or incompatible.

[0011] The peripheral device may connect to the computer at a "plug and play" port. The port may be a USB (Universal Serial Bus) port. The at least one message may then be a USB Get Descriptor message. The GetDescriptor message may be a message requesting a USB Device Descriptor.

[0012] The at least one message may have a field for a language ID for a string, but the message may not relate to a string, and the modification may then be to the field provided for the language ID.

[0013] A non-volatile computer readable storage medium may contain computer code operative to cause a suitable computer to act as a computer according to any of the mentioned embodiments.

[0014] A non-volatile computer readable storage medium may contain computer code operative to cause a suitable device to act as a device according to any of the mentioned embodiments.

[0015] Other aspects of the invention include methods, computers and computer systems, computer programs, and non-transitory computer-readable storage media containing computer programs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The above and other aspects, features, and advantages of the present invention may be more apparent from the following more particular description of embodiments thereof, presented in conjunction with the following drawings. In the drawings:

[0017] FIG. 1 is a schematic diagram of an embodiment of a computer system.

[0018] FIG. 2 is a schematic diagram of an embodiment of a peripheral device.

[0019] FIG. 3 is a flow-chart.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

[0020] A better understanding of various features and advantages of the present methods and devices may be obtained by reference to the following detailed description of illustrative embodiments and accompanying drawings. Although these drawings depict embodiments of the contemplated methods and devices, they should not be construed as foreclosing alternative or equivalent embodiments apparent to those of ordinary skill in the subject art.

[0021] Referring to the drawings, and initially to FIG. 1 , an example of a computer apparatus indicated generally by the reference number 20 comprises, among other equipment, a processor 22, input and output devices 24, 26, random access memory (RAM) 28, read-only memory (ROM) 30, magnetic disks or other long-term non-volatile storage 32, and an interface 34 to an external network 36 or other communications media.

[0022] Computer apparatus 20 also includes a USB port 40, into which a USB device 42 can be inserted, and from which the USB device can be removed. The USB port 40 is controlled by a USB host device 44, which typically maintains a "stack" of device drivers at different levels of the communication model. For example, the lower level drivers typically deal with physical host controller hardware, whereas the upper layers deal with logical communication channels, and the highest level deals with device classes and the like. In most relevant operating systems, drivers in each layer of the host stack do not call the layer below directly. Instead, they use a Function Table in RAM. The USB host 44 is conventional, except for the modifications specifically described below, and in the interests of conciseness is not described in more detail. The USB host 44 is loaded into RAM 28 and running as a process on CPU 22 whenever the computer 20 is in normal operation.

[0023] When a user inserts a USB device 42 into the USB port 40, an exchange of information known as "enumeration" takes place between the USB host 44 and a processor on the inserted device 42. As part of the enumeration process, the USB host 44 sends to the USB device 42 one or more "GetDescriptor" messages having the following format.

[0024] The wValue field identifies the type of descriptor being requested. The index identifies an individual descriptor when the device has more than one descriptor of a given type. If the descriptor type indicates a string descriptor, the windex field contains a 2-byte code specifying the requested language for the descriptor. If the descriptor is of any other type (for example, device or configuration), the windex field is unused and defaults to zero. In that case, the receiving device will usually ignore the windex field. The windex field can therefore be used for another purpose without interfering with the normal operation of the GetDescriptor message.

[0025] Referring now also to FIG. 2, a typical USB peripheral device 42 comprises a USB port 60 that can connect to the USB port 40 of the computer 20, a processor 62, and storage 64 for programs and data. The connection between USB ports 40 and 60 may be direct, by plugging a plug into a socket, via a cable, or via one or more intermediate hubs or other devices. The peripheral device 42 may also contain other components 66 to enable the USB peripheral device 42 to carry out a useful function. Those other components 66 will depend on the intended function of the specific peripheral device 42, and may be conventional for any given intended function. In the interests of conciseness, such other components 66 are not described in detail.

[0026] Referring now also to FIG. 3, in a preparatory stage, in step 102 a user may, or may not, install on computer 20 a specific device driver 50 for USB device 42. The device driver is in the form of a file stored on non-volatile storage 32. The user, or more usually a setup program being run by the user, at the same time modifies a Function Table in one of the layers of the USB Host Stack to divert enumeration request messages through additional custom executable code. This interception is known as "hooking" the communication between different layers. The procedure is well known and, in the interests of conciseness, will not be described in more detail. Typically, the modification to the USB Host Stack will be done automatically by the setup program installing the device driver 50, so it is transparent to the end-user. On most current computer systems, the changes will require a level of control over the computer greater than that of the ordinary end-user, sometimes called "administrator privilege." However, installing the device driver 50 typically also requires administrator privilege, so the user responsible for the installation will probably not notice anything unusual.

[0027] After installation and modification of the USB Host Stack Function Table, the custom executable code will automatically be called instead of the original function. In this way, the custom executable code can listen to, and modify, data (including enumeration request messages) sent from one layer to another. The custom executable code then returns the process to the original function at the next layer of the USB stack, so that the USB Host is not aware of any modification. The effect of the custom executable code inserted in step 102 is explained at steps 108, 1 10, and 112 below.

[0028] The path bypassing step 102 represents an unmodified computer 20, without device driver 50.

[0029] The computer 20, with or without the device driver 50, may then be used normally, represented symbolically by the loop at step 104, until a USB device 42 is inserted into the USB port 40.

[0030] At step 106, the USB host 44 of computer 20 enumerates the new device 42. At step 108, the additional executable code that has been added to the USB Host Stack of USB host 44 of computer 20 monitors the USB commands passed through the host stack. Unless the GetDescriptor command for the Device Descriptor is detected at step 1 10, the USB commands are processed normally at step 1 11 , and the process returns to step 108 to monitor the next command.

[0031] When the GetDescriptor command for the Device Descriptor is detected at step 110, the wlndex field is modified in step 1 12 to include the above-mentioned arbitrary code, and in step 114 the modified GetDescriptor command is sent to the device 42. If the host requests the Device Descriptor, the custom executable code may repeat step 112, or step 1 12 may be carried out at the host, and may be expected by the device 42, only at the first occurrence of the Device Descriptor. All other messages are ignored by the additional executable code, and pass between the USB host 44 and the USB device 42 in the usual way as required by the USB standard specification.

[0032] The subsequent process depends on whether the new USB device 42 is a device associated with the driver 50, symbolized by the decision block 116. If the USB device 42 is not interested in the driver 50, then the USB device 42 does not even look at the content of the wlndex field, and enumerates normally in step 118.

[0033] If the USB device 42 is associated with the driver 50, then in step 120 the USB device 42 inspects the wlndex field of the GetDescriptor message, to see whether the correct arbitrary code is present. [0034] If the correct arbitrary code is present, then in step 122 the USB device 42 returns a descriptor identifying USB device 42 as a device using driver 50, and configures itself internally to use the driver 50. In step 124, the USB host 44 loads the driver 50, and the device 42 then operates using driver 50.

[0035] If in step 120 the correct arbitrary code is not detected, then in step 126 the USB device 42 returns a descriptor identifying itself as a member of one of the generic USB classes, for example, a Human Interface Device, and configures itself internally to use the chosen generic class driver. The device 42 then operates accordingly, although without the benefit of the specific device driver 50.

[0036] Although specific embodiments have been described, various modifications are possible without departing from the spirit of the invention or the scope of the appended claims, and features of the different embodiments may be combined into one embodiment.

[0037] For example, the embodiment has been described as using an arbitrary code substituted for a zero value in the wlndex field of a Get Descriptor message. However, any part of any message from the host 40 to the new device 42 may be used, provided that:

[0038] - the message is sent to the new device 42 before the new device has to describe itself as requiring or not requiring the device driver 50; and

[0039] - the message part in question is reserved or otherwise unused in normal execution of the

USB standard specification, and will be ignored by conventional USB devices.

[0040] The embodiment has been described as operating under the USB specification. However, the same concept may be applied to any specification for exchangeable peripheral devices that supports optional vendor-specific device drivers, and in which a suitable exchange of messages takes place between the host machine and a newly connected peripheral device.

[0041] In the interests of simplicity, computer 20 is described as a single, stand-alone computing machine. Computer 20 may instead be a network or distributed computing system, or part of a

"cloud."

[0042] Accordingly, reference should be made to the appended claims, rather than to the foregoing specification, as indicating the scope of the invention.

Claims

1. A method of installing a peripheral device to a computer, comprising:

providing on the computer a specific device driver for the peripheral device;

connecting the peripheral device to the computer, wherein the computer comprises at least one generic class device driver, and the peripheral device is operable either with the specific device driver or with the at least one generic class device driver;

by the computer, generating at least one message to request configuration information relating to the peripheral device;

by the computer, making a modification to the at least one message to signal the presence of a device driver for the peripheral device, wherein the modification affects only an unused part of the at least one message under a relevant standard;

by the peripheral device, detecting the modification;

where the modification is detected, by the peripheral device, supplying specific configuration information identifying the specific device driver; and

by the computer, where the specific configuration information is received, activating the specific device driver.

2. The method of claim 1 , wherein the peripheral device connects to the computer at a USB (Universal Serial Bus) port, the at least one message is a USB Get Descriptor message.

3. The method of claim 1 , wherein the at least one message has a field for a language ID for a string, the message does not relate to a string, and the modification is to the field provided for the language ID.

4. A method for installing a peripheral device to a computer, comprising: connecting the peripheral device to the computer; and

at the peripheral device:

receiving at least one message to request configuration information relating to the peripheral device;

inspecting the at least one message for a specific modification in an unused part of the at least one message under a relevant standard; where the modification is detected, supplying to the computer specific configuration information identifying a device driver specific to said peripheral device; and

where the modification is not detected, supplying to the computer configuration information identifying a generic class device driver; and

on completion of a configuration process, operating in cooperation with the identified device driver.

5. The method of claim 4, wherein the peripheral device connects to the computer at a USB (Universal Serial Bus) port, the at least one message is a USB Get Descriptor message.

6. The method of claim 5, wherein the at least one message has a field for a language ID for a string, the message does not relate to a string, and the modification is to the field provided for the language ID.

7. A computer, comprising:

a port for connection of peripheral devices, complying with a standard;

a host for said port, operative to exchange messages with a peripheral device connected to said port, and to configure said port differently for different ones of said peripheral devices dependent on information supplied by said peripheral device in accordance with said standard, said host including at least one generic class device driver for a class of said peripheral devices; a specific device driver for a specific one of said peripheral devices;

the computer being operative to make a modification to at least one message specified by the standard to signal the presence of a device driver for the peripheral device, wherein the modification affects only a part of the at least one message unused under the standard;

the computer being operative to activate the specific device driver or to activate a said generic class device driver as requested by the peripheral device.

8. The method of claim 7, wherein the peripheral device connects to the computer at a USB (Universal Serial Bus) port, the at least one message is a USB Get Descriptor message.

9. The method of claim 7, wherein the at least one message has a field for a language ID for a string, the message does not relate to a string, and the modification is to the field provided for the language ID.

10. A peripheral device for a computer, the peripheral device being connectable to a port of the computer in accordance with a standard, and being operative:

to receive from the computer at least one message to request configuration information relating to the peripheral device;

to inspect the at least one message for a specific modification in an unused part of the at least one message under a relevant standard;

where the modification is detected, to supply to the computer specific configuration information identifying a device driver specific to said peripheral device;

where the modification is not detected, to supply to the computer configuration information identifying a generic class device driver; and

11. The method of claim 10, wherein the peripheral device connects to the computer at a USB (Universal Serial Bus) port, the at least one message is a USB Get Descriptor message.

12. The method of claim 10, wherein the at least one message has a field for a language ID for a string, the message does not relate to a string, and the modification is to the field provided for the language ID.

13. A non-volatile computer readable storage medium containing computer code operative to cause a suitable computer to act as a computer according to claim 7.

14. A non-volatile computer readable storage medium containing computer code operative to cause a suitable device to act as a device according to claim 10.