Device driving methods, pre-installed driver modules, electronic devices and storage media

Abstract

This application provides a device driver method, a pre-built driver module, an electronic device, and a storage medium. The method includes: detecting a newly inserted target device in the system, obtaining the device identifier of the target device; if the device identifier of the target device is found in a pre-built conversion list, saving the device handle and device information of the target device in a first device list, and modifying the device type to the target device type; creating a device object corresponding to the target device, and sending a notification message to the Wine kernel; receiving a call request from the Wine kernel to add an interface to the device, the call request carrying the device object; creating a functional device object corresponding to the target device based on the device identifier in the device object, and binding the functional device object of the target device to the physical device object of the target device. This application can solve the problem that applications running in Wine cannot recognize and use the corresponding HID devices.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a device driving method, a pre-installed driver module, an electronic device, and a storage medium. Background Technology

[0002] A USB (Universal Serial Bus) device is an external device that connects to a computer or other host device via a USB port. USB devices typically include the following:

[0003] Audio Class: such as microphones, speakers, etc.

[0004] Image Class: such as cameras, scanners, etc.

[0005] Printer Class: such as a printer.

[0006] Mass Storage Class: such as USB flash drives, external hard drives, and optical drives.

[0007] Human Interface Device (HID): such as mouse, keyboard, game controller, touchpad and handwriting tablet, etc.

[0008] Wine is a compatibility layer that allows Windows applications to run on Linux systems. However, Linux systems have fewer drivers for HID devices than Windows systems. Therefore, for some HID devices, applications running on Windows systems can recognize and use the corresponding HID devices because the corresponding drivers exist in Windows systems; but because Linux systems lack drivers for these HID devices, applications running in Wine cannot recognize and use the corresponding HID devices. Summary of the Invention

[0009] In view of the above problems, embodiments of this application are proposed to provide a device driver method that overcomes or at least partially solves the above problems, which can correctly drive HID devices using a pre-built driver module and solve the problem that applications running in Wine cannot recognize and use the corresponding HID devices.

[0010] Accordingly, embodiments of this application also provide a pre-installed driver module, an electronic device, and a storage medium to ensure the implementation and application of the above method.

[0011] In a first aspect, embodiments of this application disclose a device driver method applied to Wine, the compatibility layer of a Linux system. Wine runs a pre-built driver module as a kernel driver. The pre-built driver module implements a device addition interface and the main function processing function for the pre-built device. The method includes:

[0012] Upon detecting the insertion of a new target device into the Linux system, the device identifier of the target device is obtained, and a preset conversion list is queried, which includes the device identifier of the preset device.

[0013] If the preset conversion list contains the device identifier of the target device, then the device handle and device information of the target device are saved in the first device list; the device information includes the device identifier and device type of the target device, and the device type is modified from the general USB device type to the target device type;

[0014] Create a device object corresponding to the target device, the device object containing the device identifier of the target device, and send a notification message to the Wine kernel, the notification message carrying the device object;

[0015] Receive the Wine kernel's request to add an interface to the device, the request carrying the device object;

[0016] Based on the device identifier in the device object, a functional device object corresponding to the target device is created, and the functional device object of the target device is bound to the physical device object of the target device.

[0017] Secondly, embodiments of this application disclose a pre-installed driver module applied to Wine, the compatibility layer of a Linux system. The pre-installed driver module runs as a kernel driver within Wine. The pre-installed driver module implements a device addition interface and the main function processing function for the pre-installed device. The pre-installed driver module includes:

[0018] An insertion monitoring module is used to obtain the device identifier of the target device and query the preset conversion list when a new target device is detected inserted into the Linux system. The preset conversion list includes the device identifier of the preset device.

[0019] The device adding module is used to save the device handle and device information of the target device in the first device list if the device identifier of the target device is found in the preset conversion list; the device information includes the device identifier and device type of the target device, and the device type is modified from the general USB device type to the target device type;

[0020] The first creation module is used to create a device object corresponding to the target device, the device object containing the device identifier of the target device, and to send a notification message to the Wine kernel, the notification message carrying the device object;

[0021] The second creation module is used to receive the Wine kernel's call request to add an interface to the device, the call request carrying the device object; based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

[0022] Thirdly, embodiments of this application disclose an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform the steps of any of the aforementioned device driving methods.

[0023] Fourthly, embodiments of this application disclose a readable storage medium storing a program or instructions, which, when executed by a processor, can implement any of the device driver methods described in the embodiments of this application.

[0024] The device driving method, preset driving module, electronic device, and storage medium provided in this application have the following advantages:

[0025] This application adds a pre-installed driver module to Wine. This pre-installed driver module runs as a kernel driver within Wine. When a new target device is detected inserted into the Linux system, if the target device is found to be a pre-installed device in the pre-installed conversion list (e.g., an HID device lacking a corresponding driver in the Linux system), the module saves the device handle and device information of the target device in the first device list and modifies its device type from a generic USB device type to the target device type (e.g., HID device type), thus allowing operation of the target device according to the correct device type. Furthermore, the pre-installed driver module implements a device addition interface and a main function for pre-installed devices. By calling the device addition interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device can be bound to the physical device object of the target device. This ensures that subsequent calls to the main function ensure that I / O requests are correctly executed on the physical device. Through this embodiment, the pre-installed driver module can correctly drive HID devices, enabling HID devices lacking drivers in the Linux system to be driven by the pre-installed driver module, thereby allowing Windows applications running in Wine to use HID devices normally. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the process of an exception occurring in a Linux system due to the lack of an HID device driver.

[0027] Figure 2 This is a flowchart illustrating the process of eliminating anomalies by adding a pre-built driver module in Wine in this application;

[0028] Figure 3 This is a flowchart illustrating the steps of one embodiment of the device driving method of this application;

[0029] Figure 4 This is a functional configuration diagram of the pre-installed driver module provided in this application;

[0030] Figure 5 This is a flowchart illustrating the process of handling I / O requests in one example of this application;

[0031] Figure 6 This is a flowchart illustrating the process of handling read / write requests in one example of this application;

[0032] Figure 7 This is a flowchart illustrating the device removal operation in one example of this application;

[0033] Figure 8 This is a structural block diagram of one embodiment of a pre-installed driver module of this application;

[0034] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0035] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0036] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0037] Reference Figure 1 This diagram illustrates the process of an exception occurring in a Linux system due to a missing HID device driver. Figure 1 As shown:

[0038] 1. The USB device is plugged into the operating system's USB port; this USB device is an HID device;

[0039] 2. The system detects the device connection and sends a request to the USB device to obtain device descriptor information;

[0040] 3. The USB device returns device descriptor information;

[0041] 4. The system determines the device type based on the device descriptor information and identifies it as an HID device, but cannot find the corresponding driver, so it uses a generic USB driver for binding.

[0042] 5. The device is ready and the system or application can use it;

[0043] 6. The Wine kernel searches for HID devices in the system via libuev;

[0044] 7. The system returned no search results, causing the application to be unable to use the USB device.

[0045] Because some HID devices lack drivers in the Linux system, these HID devices are treated as general USB devices in the Linux system (Abnormality 1), which in turn causes Wine to search for no HID devices in the Linux system (Abnormality 2), thus causing applications to be unable to use HID devices properly (Abnormality 3).

[0046] Reference Figure 2 The diagram illustrates the process by which this application eliminates the aforementioned anomalies by adding a pre-built driver module in Wine.

[0047] To solve Figure 1 In response to the anomalies encountered, this application adds a pre-built driver module to Wine. The pre-built driver module can provide the following functions: for HID devices in Linux systems that are treated as generic USB devices due to the lack of drivers, convert their device type from generic USB device type to the correct target device type (such as converting them to HID device type); and drive the correctly identified USB devices for use by applications.

[0048] The pre-installed driver module runs as a kernel driver in Wine, the compatibility layer of the Linux system. The pre-installed driver module implements the device addition interface and the main function processing function of the pre-installed device, thereby enabling the driver of the pre-installed device. The pre-installed device can be an HID device in the Linux system that lacks the corresponding driver.

[0049] Figure 3 This illustration shows a flowchart of an embodiment of a device driver method according to this application, applied to a pre-built driver module running in Wine, the compatibility layer of a Linux system. The method may include the following steps:

[0050] Step 101: When a new target device is detected inserted into the Linux system, obtain the device identifier of the target device and query the preset conversion list, which includes the device identifier of the preset device.

[0051] Step 102: If the preset conversion list contains the device identifier of the target device, then save the device handle and device information of the target device in the first device list; the device information includes the device identifier and device type of the target device, and the device type is changed from the general USB device type to the target device type;

[0052] Step 103: Create a device object corresponding to the target device. The device object contains the device identifier of the target device. Send a notification message to the Wine kernel. The notification message carries the device object.

[0053] Step 104: Receive the Wine kernel's call request to add an interface to the device, the call request carrying the device object;

[0054] Step 105: Based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

[0055] The steps of the device driver method provided in this application are mainly described with a pre-built driver module as the execution subject. This application implements a general device driver method by adding a pre-built driver module without changing the original processing flow of the operating system.

[0056] The device driver method provided in this application can be applied to electronic devices based on the Linux operating system. These electronic devices may include, but are not limited to, any of the following: servers, smartphones, voice recorders, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, in-vehicle computers, desktop computers, set-top boxes, smart TVs, wearable devices, etc.

[0057] This application does not limit the type of Linux operating system. For example, the Linux operating system may include, but is not limited to, any one of Debian, Ubuntu, CentOS (Community Enterprise Operating System), UOS (Tongxin Desktop Operating System), Kylin Operating System, Fangde Operating System, etc.

[0058] The Linux system described above runs a compatibility layer called Wine, which can run Windows applications. This application adds a pre-built driver module to Wine, as described above. Figure 4 The diagram shows the functional configuration of the pre-installed driver module provided in this application.

[0059] like Figure 4As shown, the driver module provides a driver entry function (DriverEntry) to implement the driver entry point; a device addition interface (AddDrvice) to implement the addition of device function objects; a driver unloading interface (Unload) to implement the unloading of the pre-installed driver module; and a main function processing function for the pre-installed device to implement the operation of the pre-installed device. The main function processing function refers to the IRP (I / O Request Packet) main function. IRP stands for I / O Request Packet, also known as Input / Output Request Packet. IRP is a data structure in the Windows operating system used to transmit I / O requests. IRP contains relevant information about I / O operations, such as operation type, operation object, parameters, and completion status. This information is passed between various components of the operating system (such as applications, drivers, and the Wine kernel) to complete the processing of I / O requests. I / O requests can include device creation (IRP_MJ_CREATE), device shutdown (IRP_MJ_CLOSE), data reading (IRP_MJ_READ), data writing (IRP_MJ_WRITE), plug-and-play (PnP) (IRP_MJ_PNP), and device control (IOCTL), etc.

[0060] The Wine kernel refers to the core component of Wine, which is responsible for managing device drivers, etc., and is also known as the driver management program.

[0061] The pre-built driver module provides a driver entry function `DriverEntry`, which allows the Wine kernel to load the pre-built driver module after Wine starts by calling the driver entry function. The driver entry function initializes the pre-built driver module, registers the main function processing provided by the pre-built driver module, sets the device types supported by the pre-built driver module, and returns a loading result flag (e.g., whether loading was successful). For example, the device types supported by the pre-built driver module include the device type of the pre-built device. Therefore, the Wine kernel can send I / O requests for the pre-built device to the pre-built driver module of this application for processing.

[0062] After the pre-installed driver module is successfully loaded, it can monitor whether a USB device is inserted into the Linux system. If a USB device (referred to as the target device) is detected, the device identifier of the target device is obtained. The device identifier may include PID (Product ID) and VID (Vendor ID). The PID is a unique identifier assigned by the device manufacturer to a specific product model to distinguish different products manufactured by the same manufacturer. The VID is an identifier that uniquely identifies the device manufacturer.

[0063] Based on the device identifier, a preset conversion list is queried. This preset conversion list is pre-set and includes the device identifier (such as PID and VID) of the preset device. In Windows systems, the device type of the preset device can be correctly identified as an HID device type because a corresponding driver exists; however, in Linux systems, due to the lack of a corresponding driver, the device type is identified as a generic USB device type.

[0064] If the preset conversion list contains the device identifier of the target device, it indicates that the target device is a preset device, the Linux system lacks a driver for the target device, and the preset driver module of this application needs to be used to drive it.

[0065] Furthermore, after detecting the insertion of a new target device into the Linux system as described in step 101, the method may further include:

[0066] Step S11: Obtain a second device list by calling the first function of the USB device access library. The second device list contains device information of all USB devices connected in the Linux system.

[0067] Step S12: Compare the second device list with the preset conversion list to determine the target device that matches the other device and whose device type is a general USB device.

[0068] Step S13: Open the target device by calling the second function of the USB device access library and obtain the device handle of the target device.

[0069] The USB device access library (libusb) is an open-source library for accessing USB devices. After initializing the libusb library, its first function (libusb_get_device_list) can be called to obtain a second device list. This second device list records information about all USB devices connected to the system. Each connected USB device is represented as a libusb_device object within the context of the libusb library. These objects contain information related to the USB device, such as PID, VID, and device type.

[0070] The pre-built driver module compares the second device list with the pre-built conversion list to determine the target device that matches and whose device type is a generic USB device. The target device that matches and whose device type is a generic USB device is the HID device for which the Linux system lacks a corresponding driver. The Linux system has already processed its device type as a generic USB device, and the libusb library recognizes the target device's device type as a generic USB device.

[0071] After finding a target device that matches the second device list in the preset conversion list and whose device type is a general USB device, this application opens the target device by calling the second function of the libusb library (i.e., libusb_open) and obtains the device handle of the target device.

[0072] The libusb_open function can be used to open a specified USB device and return a device handle (libusb_device_handle), which can be used to operate on the USB device.

[0073] This embodiment of the application stores the device handle (i.e., libusb_device_handle) and device information of the target device in the first device list. The first device list is an internal list maintained by the preset driver module, used to store the device handles and device information of the preset devices that have been opened; the device information includes the device identifier and device type of the target device. Since the device type of the target device enumerated by the libusb library is a general USB device type, that is, the device type of the target device in the second device list is a general USB device type, this device type is not the correct device type. Therefore, when storing the device information of the target device in the first device list, this embodiment of the application modifies the device type of the target device in the first device list from the general USB device type to the HID device type, modifying it to the correct device type, so that subsequent operations on the target device can be performed based on the correct device type. It should be noted that this application does not modify the device type in the second device list obtained by the libusb library.

[0074] Furthermore, after opening the target device through the second function libusb_open, the report descriptor information of the target device can be read and stored in memory.

[0075] Specifically, descriptor information at each level can be obtained based on the hierarchical relationship of descriptor information in the HID device. For example, after opening the target device using the second function `libusb_open`, the device handle (`libusb_device_handle`) can be obtained. Based on this device handle, the file descriptor information of the target device can be obtained. Based on the file descriptor information, the configuration descriptor information of the target device can be obtained. Based on the configuration descriptor information, the interface descriptor information of the target device can be obtained. Based on the interface descriptor information, the report descriptor information of the target device can be obtained.

[0076] The report descriptor information specifies the data format for communication with HID devices. In this embodiment, in addition to storing the device handle and device information of the target device in the first device list, the report descriptor information of the target device can also be stored. Therefore, when the pre-built driver module communicates with the target device subsequently, it can do so based on the data format specified by the stored report descriptor information. Furthermore, descriptor information at each level can also be stored for use in subsequent operations on the target device.

[0077] Next, the pre-built driver module creates a device object corresponding to the target device. This device object contains a device identifier to specify the device to be operated on. The pre-built driver module sends a notification message to the Wine kernel, informing it that a new device (target device) has been added. This notification message carries the device object of the target device.

[0078] After receiving the notification message, the Wine kernel calls the device addition interface (AddDrvice) provided by the pre-built driver module. The pre-built driver module receives the device addition interface call request sent by the Wine kernel, and the call request carries the device object.

[0079] The AddDrvice interface is used to create a functional device object corresponding to the target device based on the device identifier in the device object, and bind the functional device object of the target device to the physical device object of the target device.

[0080] A Physical Device Object (PDO) is an abstraction of a physical device by the operating system; it represents the actual, existing hardware device itself. PDOs are typically created by the operating system.

[0081] A Functional Device Object (FDO) resides above the Device Object Object (PDO) in the device stack and is primarily used to implement specific functions of a device. FDOs are typically created by the device driver.

[0082] For example, in a USB camera device, PDO represents the physical USB connection, while FDO contains the logic for implementing functions such as video capture, image format conversion, and video streaming. FDO handles various I / O requests through a series of main function processing functions, thereby enabling the device's functionality.

[0083] In Linux systems, the lack of a driver for the target device prevents the creation of a functional device object (FDO) for that device. In this embodiment, the pre-built driver module implements the AddDrvice interface. By calling this interface, a functional device object (FDO) corresponding to the target device can be created, and the FDO can be bound to the physical device object (PDO) of the target device.

[0084] FDOs (Fixed Device DOs) are used to implement device functions, such as data transmission and device control. These functions require the physical state and characteristics of the device to be implemented. PDOs (Programmed Device DOs) contain physical information about the device, such as PID and VID, and bus information (e.g., the port number and bus speed for USB devices). After the pre-built driver module creates an FDO for the target device, it binds the target device's FDO to the PDO, allowing it to obtain this crucial information from the PDO to correctly implement the functions.

[0085] In the Windows device driver architecture, the device stack is a hierarchical structure. PDOs (Physical Device Execution Objects) are at the bottom, representing the physical device, while FDOs (Fixed Device Execution Objects) are above them, implementing device functions. When an I / O request (such as reading device data) travels from the application through the Wine kernel to the pre-built driver module, it is passed down the device stack. Through their binding relationship with PDOs, FDOs combine functional operations (such as data reading) with the actual data source of the physical device (through the physical connection represented by the PDO), ensuring that the I / O request is correctly executed on the physical device.

[0086] Furthermore, the physical state of a device may change for various reasons, such as being unplugged, entering a low-power mode, or malfunctioning. The PDO can reflect these physical state changes in real time. By binding the FDO to the PDO, the FDO can promptly obtain this state change information and adjust the device's functionality accordingly. For example, when the target device is accidentally unplugged, the PDO will mark it as unavailable. The FDO can detect this change, promptly stop ongoing operations (such as data transmission), and send a notification of device unavailability to the upper-layer application or driver, preventing data loss or system errors.

[0087] This application embodiment adds a pre-installed driver module to Wine. This pre-installed driver module runs as a kernel driver within Wine. When a new target device is detected inserted into the Linux system, if the target device is a pre-installed device (an HID device lacking a corresponding driver in the Linux system), the device handle and device information of the target device are saved in the first device list, and its device type is changed from a generic USB device type to the target device type (such as an HID device type). The pre-installed driver module implements a device addition interface and a main function for pre-installed devices. By calling the device addition interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device is bound to the physical device object of the target device. This ensures that subsequent calls to the main function ensure that I / O requests can be correctly executed on the physical device. Through this application embodiment, the pre-installed driver module can correctly drive pre-installed devices, enabling pre-installed devices lacking drivers in the Linux system to be driven by the pre-installed driver module, thereby allowing Windows applications running in Wine to normally use pre-installed devices (HID devices lacking corresponding drivers in the Linux system).

[0088] Furthermore, this application can also solve the problem that Wine applications cannot use USB devices due to insufficient driver support for certain USB device types (such as Mass Storage Devices) in the Linux system. Specifically, the preset device can be a Mass Storage Device for which the corresponding driver is missing in the Linux system. The preset driver module implements a device adding interface and a main function for processing the preset device (a Mass Storage Device for which the corresponding driver is missing in the Linux system). In this case, the target device type refers to a Mass Storage Device, enabling Windows applications running in Wine to use the preset device (a Mass Storage Device for which the corresponding driver is missing in the Linux system) normally.

[0089] It is understood that, in specific embodiments, the target device type may include, but is not limited to, human-machine interface device type, large-capacity storage device type, printing device type, image device type, audio device type, etc.

[0090] In one optional embodiment of this application, the method may further include:

[0091] The Wine kernel sends registration information related to the target device to the Wine kernel, enabling the Wine kernel to register the target device in the registry based on this information. Windows applications running within Wine can then discover and operate the target device.

[0092] After step 105 is completed, the pre-installed driver module can send the registration information of the target device to the Wine kernel, so that the Wine kernel can register the target device in the registry based on the registration information. Thus, Windows applications running in Wine can discover and operate the target device.

[0093] In one optional embodiment of this application, after step 105, the method may further include:

[0094] Step S21: Receive a first input / output request packet sent by the Wine kernel; the first input / output request packet carries a first main function code and the device object; the first main function code indicates that the target device should be opened;

[0095] Step S22: Execute the first main function processing function. The first main function processing function is used to set a success status code in the first input / output request packet and return the processed first input / output request packet to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

[0096] After the Wine kernel registers the target device in the registry, applications running in Wine can discover and operate the target device.

[0097] Before an application can perform any operation on a USB device, it must first open the USB device. When an application calls an API provided by the operating system (such as CreateFile) to request to open a USB device (such as the target device), the Wine kernel will receive the CreateFile request and convert it into an IRP (referred to here as a First Input / Output Request Packet) and send it to the pre-built driver module for processing.

[0098] In practice, an IRP can consist of: header information, main function code (and sometimes sub-function code), parameter area, and I / O status block.

[0099] The header information contains some basic metadata, such as the size and type of the IRP.

[0100] The main function code defines the type of I / O request. For example, the main function code IRP_MJ_CREATE is used to indicate the creation or opening of a device object, and the main function code IRP_MJ_READ is used to indicate the reading of the contents of a device object.

[0101] Sub-function codes provide more detailed operational information to supplement the main function code. For example, for the main function code IRP_MJ_READ, sub-function codes can be used to specify details such as the starting position of the read and the number of bytes to read.

[0102] Depending on the type of I / O operation, the parameter area can contain different parameters.

[0103] The I / O status block records the completion status of I / O operations, such as success or failure, and the corresponding error code. The Wine kernel can determine whether an I / O operation was successful by checking the I / O status block.

[0104] The main function code of the first IRP is the first main function code (i.e., IRP_MJ_CREATE), and the parameters include the device object of the target device; the first main function code is used to indicate the creation or opening of a device object (such as opening the target device).

[0105] The pre-configured driver module executes the first main function processing function, namely the IRP_MJ_CREATE processing function, to set a success status code in the I / O status block of the first IRP, and returns the processed first IRP to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

[0106] It should be noted that since the target device has already been opened through the libusb library, its device handle is stored in the first device list. The pre-built driver module can obtain the target device's device handle by querying the first device list, and then operate on the target device. Therefore, after receiving the first IRP with the main function code IRP_MJ_CREATE, the pre-built driver module can directly set the success status code in the I / O status block of the first IRP.

[0107] The pre-configured driver module returns the processed first IRP to the Wine kernel. The Wine kernel determines whether opening the target device was successful based on the I / O status block in the first IRP. If the I / O status block of the first IRP contains a success status code, it indicates that the pre-configured driver module has successfully opened the target device, and the Wine kernel returns an object handle to the application for subsequent operations on the target device. If the I / O status block of the first IRP contains a failure status code, it indicates that the pre-configured driver module has failed to open the target device, and the Wine kernel returns an error message to the application.

[0108] It should be noted that the device object refers to a device object that the Wine kernel can recognize. The interaction between the pre-built driver module and the Wine kernel uses this device object.

[0109] The device handle (libusb_device_handle) refers to the device handle of the target device obtained using the libusb library. This device handle is used for interaction between the pre-built driver module and the target device.

[0110] An object handle is a handle provided by the Wine kernel to an application after receiving the first IRP carrying a success status code returned by the pre-configured driver module.

[0111] The object handle corresponds to the device object in the Wine kernel. The device handle in the first device list can be located through the device identifier in the device object, and then the specific target device can be operated.

[0112] In one optional embodiment of this application, after step S22, the method may further include:

[0113] Step S31: Receive a second input / output request packet sent by the Wine kernel; the second input / output request packet carries a second main function code and the device object; the second main function code indicates how to operate the target device according to the type of the second main function code;

[0114] Step S32: Query the first device list based on the device identifier in the device object to obtain the device handle corresponding to the device object;

[0115] Step S33: Execute the second main function processing function, which is used to call the interface corresponding to the type of the second main function code in the USB device access library using the obtained device handle.

[0116] After the application obtains the object handle of the target device returned by the Wine kernel, it can use the object handle to initiate I / O requests to operate the target device.

[0117] Reference Figure 5 The diagram illustrates a flowchart of processing I / O requests in an example of this application. Figure 5 The process shown is after step S22.

[0118] like Figure 5As shown, the requester can be a Windows application or other component running in Wine, and the I / O request can include one of the following: reading data (IRP_MJ_READ), writing data (IRP_MJ_WRITE), or application device control (IRP_MJ_DEVICE_CONTROL). In some cases, the I / O request may be issued by the Wine kernel, in which case there is no... Figure 2 As shown in the example, in this case, the I / O request may include one of the following: kernel internal device control (IRP_MJ_INTERNAL_DEVICE_CONTROL), plug and play (IRP_MJ_PNP), and device shutdown (IRP_MJ_CLOSE).

[0119] Taking an application reading data from a target device as an example, the application can use the acquired object handle to request data reading from the target device by calling system-provided API functions (such as ReadFile). This request is passed to the Wine kernel. The Wine kernel converts this request into an IRP and sends it to the pre-built driver module, referred to here as the second IRP. The main function code of the second IRP is the second main function code (i.e., IRP_MJ_READ), and the parameters include the device object of the target device; this second main function code is used to indicate reading data from the target device.

[0120] The pre-built driver module queries the first device list based on the device identifier (such as PID and VIP) in the device object to obtain the device handle corresponding to the device object; and executes the second main function processing function, namely the IRP_MJ_READ processing function, which is used to call the interface corresponding to the IRP_MJ_READ type in the libusb library, such as libusb_bulk_transfer or libusb_interrupt_transfer. The parameters passed in include the device handle and the number of bytes read.

[0121] In this embodiment, the pre-built driver module converts the second IRP sent by the Wine kernel into an interface that calls the corresponding function in the libusb library to operate the target device. The interface called in the libusb library varies depending on the type of the second main function code. The type of the second main function code can include any of the following: reading data, writing data, kernel internal device control, application device control, and shutting down the device.

[0122] It should be noted that after the pre-configured driver module completes the processing of the IRP requests (such as the first IRP, the second IRP, and the third IRP) sent by the Wine kernel, it can set the processing result in the I / O status block of the processed IRP and return the processed IRP to the Wine kernel.

[0123] Furthermore, when the type of the second main function code is IRP_MJ_READ or IRP_MJ_WRITE, in order to ensure the correctness of reading and writing data, the preset driver module also needs to declare the interface control rights of the target device before operating the target device; and release the interface control rights of the target device after operating the target device.

[0124] Reference Figure 6 This diagram illustrates a flowchart of a read / write request processing example from this application. A read / write request refers to an I / O request that is either a data read request or a data write request, and specifically includes the following steps:

[0125] Step A1: The application sends a read / write request to the USB device (target device). Specifically, the application uses the handle of the target device's device object as a parameter to call system-provided API functions (such as ReadFile / WriteFile) to trigger a read / write request for the target device.

[0126] Step A2: The Wine kernel receives read / write requests and forwards them to the pre-configured driver module. Specifically, after receiving a read / write request triggered by the application, the Wine kernel converts it into an IRP (second IRP) and sends it to the pre-configured driver module. The second main function code is IRP_MJ_READ / IRP_MJ_WRITE.

[0127] Step A3: Declare exclusive control over the device's interface. Specifically, by calling the `libusb_claim_interface` function of the libusb library with the target device's device handle and interface number as parameters, you can declare interface control. The device handle and interface number can both be obtained and saved when the device is inserted. The interface number can be obtained from the configuration descriptor.

[0128] Step A4: Send a read / write request to the USB device. Specifically, the pre-built driver module converts the received IRP into an interface that calls the corresponding function in the libusb library, such as calling the libusb_bulk_transfer or libusb_interrupt_transfer interface.

[0129] Step A5: Receive the result returned by the USB device.

[0130] Step A6: Release interface control of the device. Specifically, by calling the libusb_release_interface function of the libusb library with the device handle and interface number of the target device as parameters, interface control can be released.

[0131] Step A7: Return the request result.

[0132] Step A8: The application receives the request result.

[0133] In this embodiment of the application, the pre-built driver module also implements the IRP main function for two types of device control (IOCTL) requests: application device control (IRP MJ DEVICE CONTROL) and kernel internal device control (IRP_MJ_INTERNAL_DEVICE_CONTROL).

[0134] The IRP_MJ_DEVICE_CONTROL request is used for communication between user-mode applications and USB devices. For example, when an application needs to perform device-specific operations, such as configuring device parameters, obtaining device status information, or sending device-specific commands, and these operations cannot be directly accomplished through standard read / write operations (such as IRP_MJ_READ or IRP_MJ_WRITE), the IRP_MJ_DEVICE_CONTROL request can be used.

[0135] Internal kernel device control is used for communication between drivers in kernel mode. For example, device control operations are performed within a device driver. Unlike IRP_MJ_DEVICE_CONTROL, IRP_MJ_INTERNAL_DEVICE_CONTROL is usually not initiated directly by the application, but is used for inter-level communication within the driver (pre-built driver module) or system-level device management operations.

[0136] For example, the sub-function codes included in the IRP with the main function code IRP_MJ_DEVICE_CONTROL, the operations corresponding to each sub-function code, and the devices involved in the operations are shown in Table 1.

[0137] Table 1

[0138]

[0139]

[0140] For example, the sub-function codes included in the IRP with the main function code IRP_MJ_INTERNAL_DEVICE_CONTROL, the operations corresponding to each sub-function code, and the devices involved in the operations are shown in Table 2.

[0141] Table 2

[0142]

[0143] In one optional embodiment of this application, the method may further include:

[0144] Step S41: Receive a third input / output request packet sent by the Wine kernel; the third input / output request packet carries a third main function code, a sub-function code, and the device object; the sub-function code indicates the method of removing the target device (normal removal or accidental removal);

[0145] Step S42: Trigger the removal processing function corresponding to the sub-function code, and remove the target device according to the removal method indicated by the sub-function code.

[0146] In practice, USB device removal can include both normal removal and accidental removal.

[0147] Normal removal refers to removing a USB device by performing a "safe removal of hardware" operation, such as uninstalling the USB device from the operating system, disabling the USB device, or shutting down the system.

[0148] Accidental removal refers to removing a USB device directly from the interface without performing a "safe removal of hardware" operation, or removing a USB device due to hardware connection failure or other reasons.

[0149] Reference Figure 7 This illustrates a flowchart of a device removal operation in one example of this application. Figure 7 As shown, when a USB device (such as the target device) is unplugged from the system (including normal removal or accidental removal) and needs to be removed by the system, the Wine kernel sends an IRP (referred to here as the third IRP) to the preset driver module to notify the preset driver module that the target device is about to be removed. The preset driver module needs to perform a series of cleanup and resource release operations.

[0150] The third IRP carries a third main function code, sub-function codes, and the device object. The third main function code is IRP_MJ_PNP, indicating that this is a Plug and Play (PnP) device-related operation. For normal removal, the sub-function code is IRP_MN_REMOVE_DEVICE; for accidental removal, the sub-function code is IRP_MN_SURPRISE_REMOVAL. The sub-main function codes can indicate the method of removing the target device (e.g., normal or accidental removal).

[0151] After receiving the third IRP, the preset driver module triggers the removal processing function corresponding to the sub-function code and removes the target device according to the removal method indicated by the sub-function code.

[0152] In the case of normal removal, the removal processing function performs the following operations: stops all I / O operations on the target device (in-progress I / O operations must wait for completion), releases the resources allocated to the target device, and cancels the callback function.

[0153] In the event of an unexpected removal, the removal handler performs the following operations: immediately stops all I / O operations on the target device (without waiting for ongoing I / O operations to complete), releases the resources allocated to the target device, and cancels the callback function.

[0154] Furthermore, after completing the processing of the IRP_MN_REMOVE_DEVICE request or the IRP_MN_SURPRISE_REMOVAL request, the pre-configured driver module can set the processing result in the I / O status block of the third IRP and return the processed third IRP to the Wine kernel to notify the Wine kernel to remove the processing result.

[0155] It should be noted that the IRP with the main function code IRP_MJ_PNP (the third IRP) is sent by the Wine kernel to the pre-installed driver module when the Wine kernel detects that a device is inserted or removed.

[0156] IRP_MJ_PNP is the main function code for handling I / O request packets related to Plug and Play (PnP) devices. It is primarily used to manage operations related to PnP functionality, such as adding or removing devices and reallocating resources. In practice, different sub-function codes can be used to implement these PnP-related operations.

[0157] For example, when a PnP device (such as the target device) is detected and needs to be started, as after step 105, the Wine kernel can send an IRP_MJ_PNP request with the sub-function code IRP_MN_START_DEVICE to the preset driver module. The preset driver module responds to this request by performing the operation to start the target device. This operation initializes the target device and allocates the necessary resources to it so that the target device can function properly.

[0158] For example, the sub-function codes included in the IRP with the main function code IRP_MJ_PNP, the operations corresponding to each sub-function code, and the devices involved in the operations are shown in Table 3.

[0159] Table 3

[0160] operate Sub-function code Equipment involved Start the device IRP_MN_START_DEVICE FDO and PDO Query device ID IRP_MN_QUERY_ID PDO Query device functions IRP_MN_QUERY_CAPABILITIES PDO Query device relationships IRP_MN_QUERY_DEVICE_RELATIONS FDO Accidental removal of device IRP_MN_SURPRISE_REMOVAL FDO and PDO Normal removal of equipment IRP_MN_REMOVE_DEVICE FDO and PDO

[0161] Furthermore, prior to step 101, the method may further include:

[0162] Create the driver file and installation information file corresponding to the pre-built driver module, and modify Wine's configuration file to enable the compilation of the pre-built driver module. This ensures that after compilation, the pre-built driver module runs as a kernel driver within the Wine environment.

[0163] Furthermore, this application can be configured and compiled through the following steps, so that when Wine is run, the pre-built driver module runs in the Wine environment as a service and a kernel driver. Specifically:

[0164] a. Create driver files corresponding to the pre-built driver modules, so that the pre-built driver modules are compiled into files with the .sys extension.

[0165] b. Create the .inf file for the pre-installed driver module (i.e., the Windows Installer information file, used to install the pre-installed driver module). In the .inf file, use the AddService keyword to create a service that matches the pre-installed driver module. Add the following content:

[0166] b1. Description of the service.

[0167] b2. The name of the service.

[0168] b3. The path to the executable program corresponding to the service, that is, the path where the pre-built driver module file is stored after compilation.

[0169] b4. Specify the service loading order group, such as setting it to WinePlugPlay.

[0170] b5. The type of service, such as specifying it as a kernel driver.

[0171] b6. Service startup type, such as setting it to automatic startup.

[0172] b7. Specifies the error control behavior when the service fails to start, such as setting it to display an error message and continue starting.

[0173] c. Modify the Wine configuration file (wine.inf.in). Add the .inf file of the pre-built driver module and its driver information to the InfFiles section.

[0174] d. Modify the Wine configuration file (configure) to enable the compilation of pre-built driver modules.

[0175] The driver file (.sys file) contains the actual code of the pre-built driver module, which implements various operations and functions of the device. This file contains main function calls that handle device I / O requests (such as IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, etc.), defining how to respond to operations such as opening, reading, and writing to the device. The driver file also contains device initialization code; for example, the DriverEntry function (the driver's entry point) performs operations such as creating the device object and allocating resources (such as memory buffer allocation and interrupt resource requests).

[0176] The installation information file (.inf file) is a text file primarily used to provide the system with device identification information and driver installation and configuration information. The .inf file also provides detailed steps and configuration information for driver installation. It specifies the location of the driver file (.sys file) and other related files that need to be copied to the system directory during installation. It also tells the system how to register driver services, including service names, display names, dependencies, and other information. During driver installation, the system follows the instructions in the .inf file, placing the driver files in the correct location and performing necessary registration and configuration.

[0177] After compilation, during Wine's startup initialization process, the Wine kernel loads the pre-built driver module through its driver entry point, initializes the pre-built driver module according to the system driver object format, and registers necessary driver entry point functions (such as AddDrvice and Unload) and necessary IRP main function functions (such as device creation, data reading, data writing, IOCTL, PnP, and device shutdown). After the pre-built driver module is successfully loaded, it can register callback functions of the libusb library to monitor USB device insertion and removal. The pre-built driver module of this application, by registering callback functions of the libusb library, can be notified and execute corresponding operations when specific USB events occur. For example, when a USB device is inserted into or removed from the system, or when an event occurs during data transfer, the callback function can handle these situations promptly without constantly polling the device status. When a device is detected being inserted, step 101 is executed.

[0178] In one optional embodiment of this application, the method may further include:

[0179] In response to the Wine kernel's call request to the driver uninstallation interface, the driver uninstallation operation is performed.

[0180] like Figure 4 As shown, the pre-installed driver module of this application provides a driver unloading interface (such as Unload) for unloading the pre-installed driver module. When the Wine kernel restarts or shuts down, or when the kernel main loop program exits, the driver unloading interface Unload of the pre-installed driver module is called to trigger the pre-installed driver module to execute the Unload function and perform the unloading operation. The Unload function is specifically used to clear and release the first device list.

[0181] The driver uninstallation operation is used to release the resources occupied by the pre-installed driver module when the user actively uninstalls the pre-installed driver module or the system is shut down.

[0182] In summary, this application adds a pre-installed driver module to Wine. This pre-installed driver module runs as a kernel driver within Wine. When a new target device is detected inserted into the Linux system, if the target device is found to be a pre-installed device in the pre-installed conversion list (e.g., an HID device lacking a corresponding driver in the Linux system), the module saves the device handle and device information of the target device in the first device list and modifies its device type from a generic USB device type to the target device type (e.g., HID device type), thus allowing operation of the target device according to the correct device type. Furthermore, the pre-installed driver module implements a device addition interface and a main function for pre-installed devices. By calling the device addition interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device can be bound to the physical device object of the target device. This ensures that subsequent calls to the main function ensure that I / O requests are correctly executed on the physical device. Through this embodiment, the pre-installed driver module can correctly drive HID devices, enabling HID devices lacking drivers in the Linux system to be driven by the pre-installed driver module, thereby allowing Windows applications running in Wine to use HID devices normally.

[0183] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0184] Reference Figure 8 This diagram illustrates a structural block diagram of a pre-installed driver module embodiment of this application, applied to the Wine compatibility layer of a Linux system. The pre-installed driver module runs as a kernel driver within Wine. The pre-installed driver module implements a device addition interface and the main function processing function for pre-installed devices. The pre-installed driver module includes:

[0185] The insertion monitoring module 201 is used to obtain the device identifier of the target device and query the preset conversion list when a new target device is detected inserted into the Linux system. The preset conversion list includes the device identifier of the preset device.

[0186] The device adding module 202 is used to save the device handle and device information of the target device in the first device list if the device identifier of the target device is found in the preset conversion list; the device information includes the device identifier and device type of the target device, and the device type is modified from the general USB device type to the target device type;

[0187] The first creation module 203 is used to create a device object corresponding to the target device, the device object containing the device identifier of the target device, and to send a notification message to the Wine kernel, the notification message carrying the device object;

[0188] The second creation module 204 is used to receive the call request from the Wine kernel to add an interface to the device, the call request carrying the device object; based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

[0189] Optionally, the preset driver module further includes:

[0190] The list acquisition module is used to obtain a second device list by calling the first function of the USB device access library. The second device list contains device information of all USB devices connected in the Linux system.

[0191] The target determination module is used to compare the second device list with the preset conversion list to determine the target device that matches the second list and whose device type is a general USB device type.

[0192] The handle acquisition module is used to open the target device by calling the second function of the USB device access library and obtain the device handle of the target device.

[0193] Optionally, the preset driver module further includes:

[0194] A first request receiving module is configured to receive a first input / output request packet sent by the Wine kernel; the first input / output request packet carries a first main function code and the device object; the first main function code indicates that the target device should be opened.

[0195] The first request processing module is used to execute the first main function processing function, which sets a success status code in the first input / output request packet and returns the processed first input / output request packet to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

[0196] Optionally, the preset driver module further includes:

[0197] The second request receiving module is configured to receive a second input / output request packet sent by the Wine kernel; the second input / output request packet carries a second main function code and the device object; the second main function code indicates the operation of the target device according to the type of the second main function code.

[0198] The second request processing module is used to query the first device list based on the device identifier in the device object to obtain the device handle corresponding to the device object; and to execute a second main function processing function, which is used to call the interface corresponding to the type of the second main function code in the USB device access library using the obtained device handle.

[0199] Optionally, the type of the second main function code includes one of the following: reading data, writing data, kernel internal device control, application device control, plug and play, and shutting down the device.

[0200] Optionally, the preset driver module further includes:

[0201] The registration information sending module is used to send the registration-related information of the target device to the Wine kernel, so that the Wine kernel can register the target device in the registry based on the registration-related information.

[0202] Optionally, the pre-built driver module provides a driver entry function so that the Wine kernel can load the pre-built driver module by calling the driver entry function after Wine starts. The driver entry function is used to initialize the pre-built driver module, register the main function processing function provided by the pre-built driver module, and set the device types supported by the pre-built driver module.

[0203] The pre-installed driver module provided in this application runs as a kernel driver in Wine. When a new target device is detected inserted into the Linux system, if the target device is found to be a pre-installed device in the pre-installed conversion list (e.g., an HID device lacking a corresponding driver in the Linux system), the device handle and device information of the target device are saved in the first device list, and its device type is modified from a general USB device type to the target device type (e.g., modified to an HID device type), thus allowing the target device to be operated according to the correct device type. Furthermore, the pre-installed driver module implements a device addition interface and a main function for pre-installed devices. By calling the device addition interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device can be bound to the physical device object of the target device. This ensures that subsequent calls to the main function ensure that I / O requests can be correctly executed on the physical device. Through the embodiments of this application, the pre-installed driver module can be used to correctly drive HID devices, enabling HID devices lacking drivers in the Linux system to be driven by the pre-installed driver module, thereby allowing Windows applications running in Wine to use HID devices normally.

[0204] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0205] Reference Figure 9 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to execute the steps of the device driving method of the aforementioned embodiment.

[0206] This application provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a terminal's program or processor, enables the terminal to perform the steps of the device driver method described in the foregoing embodiments.

[0207] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0208] Those skilled in the art will understand that embodiments of this application can be provided as methods, pre-built driver modules, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0209] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0210] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0211] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0212] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0213] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A device driving method, characterized in that, A compatibility layer called Wine is applied to Linux systems. Wine runs a pre-built driver module as a kernel driver. This pre-built driver module implements a device addition interface and the main function processing functions for pre-built devices. The method includes: Upon detecting the insertion of a new target device into the Linux system, the device identifier of the target device is obtained, and a preset conversion list is queried, which includes the device identifier of the preset device. If the preset conversion list contains the device identifier of the target device, then the device handle and device information of the target device are saved in the first device list; the device information includes the device identifier and device type of the target device, and the device type is modified from the general USB device type to the target device type; Create a device object corresponding to the target device, the device object containing the device identifier of the target device, and send a notification message to the Wine kernel, the notification message carrying the device object; Receive the Wine kernel's request to add an interface to the device, the request carrying the device object; Based on the device identifier in the device object, a functional device object corresponding to the target device is created, and the functional device object of the target device is bound to the physical device object of the target device.

2. The method according to claim 1, characterized in that, After detecting the insertion of a new target device into the Linux system, the method further includes: The second device list is obtained by calling the first function of the USB device access library. The second device list contains device information of all USB devices connected in the Linux system. The second device list is compared with the preset conversion list to determine the target device that matches the target device and whose device type is a general USB device. The target device is opened by calling the second function of the USB device access library, and the device handle of the target device is obtained.

3. The method according to claim 1, characterized in that, The method further includes: Receive a first input / output request packet sent by the Wine kernel; the first input / output request packet carries a first main function code and the device object; the first main function code instructs the target device to be opened; The first main function processing function is executed. The first main function processing function is used to set a success status code in the first input / output request packet and return the processed first input / output request packet to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

4. The method according to claim 3, characterized in that, The method further includes: The Wine kernel sends a second input / output request packet; the second input / output request packet carries a second main function code and the device object; the second main function code instructs the target device to be operated according to the type of the second main function code. Query the first device list based on the device identifier in the device object to obtain the device handle corresponding to the device object; The second main function is executed, which is used to call the interface corresponding to the type of the second main function code in the USB device access library using the acquired device handle.

5. The method according to claim 4, characterized in that, The second main function code includes one of the following types: reading data, writing data, kernel internal device control, application device control, and shutting down the device.

6. The method according to claim 1, characterized in that, The method further includes: The Wine kernel sends the registration information of the target device to the Wine kernel so that the Wine kernel registers the target device in the registry based on the registration information.

7. The method according to claim 1, characterized in that, The pre-built driver module provides a driver entry function so that the Wine kernel can load the pre-built driver module by calling the driver entry function after Wine starts. The driver entry function is used to initialize the pre-built driver module, register the main function processing function provided by the pre-built driver module, and set the device types supported by the pre-built driver module.

8. A pre-set driver module, characterized in that, Wine, a compatibility layer for Linux systems, runs a pre-built driver module as a kernel driver. This pre-built driver module implements a device addition interface and the main function processing functions for pre-built devices. The pre-built driver module includes: An insertion monitoring module is used to obtain the device identifier of the target device and query the preset conversion list when a new target device is detected inserted into the Linux system. The preset conversion list includes the device identifier of the preset device. The device adding module is used to save the device handle and device information of the target device in the first device list if the device identifier of the target device is found in the preset conversion list; the device information includes the device identifier and device type of the target device, and the device type is modified from the general USB device type to the target device type; The first creation module is used to create a device object corresponding to the target device, the device object containing the device identifier of the target device, and to send a notification message to the Wine kernel, the notification message carrying the device object; The second creation module is used to receive the Wine kernel's call request to add an interface to the device, the call request carrying the device object; based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

9. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the steps of the device driving method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device driving method as described in any one of claims 1 to 7.

Images