Method and device for processing winrt handle input in windows multi-session environment

Abstract

The application provides a WinRT handle input processing method and device in a Windows multi-session environment, the method comprising: when a target program enumerates a handle through a WinRT interface on a cloud host, determining a device instance identifier, a virtual slot and a connection state of a virtual handle device corresponding to a user session to which the target program belongs by querying a pre-established session mapping relationship, generating a device object according to the device instance identifier, the virtual slot and the connection state and returning the device object to the target program; after the cloud host receives user handle input, determining a user session to which the handle input belongs by querying the session mapping relationship, and writing the handle input into a corresponding input cache; when the target program reads a target virtual handle device state through the WinRT interface, determining the corresponding input cache by querying the session mapping relationship, obtaining a handle input state from the input cache, and generating state data and returning the state data to the target program, so that the program can effectively access the handle through the WinRT interface.

Description

Technical Field

[0001] This invention relates to the field of cloud computing, and in particular to a WinRT gamepad input processing method and apparatus in a Windows multi-session environment. Background Technology

[0002] With the rapid development of cloud gaming and cloud desktop technologies, a single Windows cloud server may simultaneously host multiple user sessions. Each user connects to the cloud server via the network and runs games or applications independently. Gamepads are crucial input devices in cloud gaming scenarios. Existing technologies can create virtual gamepad devices within the system, making the operating system recognize the existence of a gamepad, and then writing gamepad input received from the cloud to this virtual gamepad device. However, some games or applications access gamepads through WinRT (Windows Runtime, a cross-platform application architecture introduced by Microsoft) game input interfaces such as Windows.Gaming.Input. The underlying implementation of gamepad access via the WinRT interface relies on the Windows operating system's global device enumeration link, which is not designed for user session isolation. In other words, the WinRT interface returns a globally visible list of gamepads. Programs in different user sessions will see the same set of gamepads, making it impossible to distinguish which gamepad belongs to which session. This leads to issues such as different sessions seeing the same gamepad or the current session seeing gamepads from other sessions. Consequently, gamepad input sent from the user terminal to the cloud cannot be written to the correct virtual gamepad device, and programs cannot obtain correct gamepad input through the WinRT interface.

[0003] Therefore, how to enable the program to effectively access the gamepad through the WinRT interface has become a pressing technical problem that needs to be solved. Summary of the Invention

[0004] To address the technical problems existing in the prior art, this application provides a WinRT gamepad input processing method and apparatus in a Windows multi-session environment.

[0005] In a first aspect, embodiments of this application provide a WinRT gamepad input processing method in a Windows multi-session environment, including: When the target program enumerates the gamepad through the WinRT interface on the Windows cloud host, it determines the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying the pre-established session mapping relationship. Based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, a device object is generated and returned to the target program. The virtual gamepad driver is deployed on the Windows cloud host. The virtual gamepad driver is used to provide the operating system with virtual gamepad devices that can be identified by the Windows device enumeration link, and to allocate a device instance identifier and virtual slot for each virtual gamepad device. The session mapping relationship includes user session, input channel, device instance identifier of virtual gamepad device, virtual slot of virtual gamepad device, connection status of virtual gamepad device, and input buffer. After the Windows cloud host receives user gamepad input, it determines the user session to which the gamepad input belongs by querying the session mapping relationship based on the input channel to which the gamepad input belongs, and writes the gamepad input into the input cache corresponding to the target virtual gamepad device in that user session; When the target program reads the target virtual gamepad device status through the WinRT interface, it determines the input buffer corresponding to the target virtual gamepad device by querying the session mapping relationship, obtains the gamepad input status from the input buffer corresponding to the target virtual gamepad device, generates the status data corresponding to the target virtual gamepad device based on the gamepad input status, and returns the status data to the target program.

[0006] Secondly, embodiments of this application also provide a WinRT gamepad input processing device in a Windows multi-session environment, comprising: The first return unit is used to determine the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying the pre-established session mapping relationship when the target program enumerates the gamepad through the WinRT interface on the Windows cloud host. It generates a device object based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, and returns the device object to the target program. The virtual gamepad driver is deployed on the Windows cloud host. The virtual gamepad driver is used to provide the operating system with virtual gamepad devices that can be identified by the Windows device enumeration link, and to allocate a device instance identifier and virtual slot for each virtual gamepad device. The session mapping relationship includes user session, input channel, device instance identifier of virtual gamepad device, virtual slot of virtual gamepad device, connection status of virtual gamepad device, and input buffer. The writing unit is used to determine the user session to which the gamepad input belongs by querying the session mapping relationship after the Windows cloud host receives the user's gamepad input, based on the input channel to which the gamepad input belongs, and write the gamepad input into the input buffer corresponding to the target virtual gamepad device in the user session; The second return unit is used to determine the input buffer corresponding to the target virtual gamepad device by querying the session mapping relationship when the target program reads the target virtual gamepad device status through the WinRT interface, obtain the gamepad input status from the input buffer corresponding to the target virtual gamepad device, generate the status data corresponding to the target virtual gamepad device based on the gamepad input status, and return the status data to the target program.

[0007] The WinRT gamepad input processing method and apparatus provided in this application for a Windows multi-session environment, in the first aspect, when a target program on a Windows cloud host enumerates gamepads through the WinRT interface, it determines the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying a pre-established session mapping relationship. A device object is generated based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, and the device object is returned to the target program. This ensures that the target program sees the virtual gamepad device of its own session and not the virtual gamepad devices of other sessions. In the second aspect, after the Windows cloud host receives user gamepad input, it determines the input channel to which the gamepad input belongs. By querying the session mapping relationship, the user session to which the gamepad input belongs is determined, and the gamepad input is written to the input buffer corresponding to the target virtual gamepad device in that user session. This ensures that the gamepad input sent from the user terminal to the cloud is written to the correct virtual gamepad device. Thirdly, when the target program reads the status of the target virtual gamepad device through the WinRT interface, the input buffer corresponding to the target virtual gamepad device is determined by querying the session mapping relationship, the gamepad input status is obtained from the input buffer corresponding to the target virtual gamepad device, and the status data corresponding to the target virtual gamepad device is generated based on the gamepad input status. The status data is then returned to the target program, ensuring that the target program obtains the correct gamepad input through the WinRT interface. In summary, the entire solution enables the program to effectively access the gamepad through the WinRT interface. Attached Figure Description

[0008] Figure 1 This application provides a flowchart illustrating an embodiment of a WinRT gamepad input processing method in a Windows multi-session environment. Figure 2 This is a schematic diagram of an embodiment of a WinRT gamepad input processing device in a Windows multi-session environment, provided in this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0010] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0011] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0012] Reference Figure 1 The diagram shown is a flowchart illustrating a WinRT gamepad input processing method in a Windows multi-session environment according to an embodiment of this application. The method includes: S10. When the target program enumerates the gamepad through the WinRT interface on the Windows cloud host, it determines the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying the pre-established session mapping relationship. Based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, a device object is generated and returned to the target program. Here, a virtual gamepad driver is deployed on the Windows cloud host. The virtual gamepad driver is used to provide the operating system with virtual gamepad devices that can be identified by the Windows device enumeration link, and to allocate a device instance identifier and virtual slot for each virtual gamepad device. The session mapping relationship includes user session, input channel, device instance identifier of virtual gamepad device, virtual slot of virtual gamepad device, connection status of virtual gamepad device, and input buffer. In this embodiment, it should be noted that the virtual gamepad driver creates several virtual gamepad devices in the system, assigns a stable Device Instance ID and VirtualSlot to each virtual gamepad device, and maintains the basic state of each virtual gamepad device, including: connection status (Connected / Disconnected), device instance ID, virtual slot, most recent valid input status (used to store the complete gamepad state of the last successfully received input by the virtual gamepad device), and timestamp (used to record the time when the most recent gamepad input was updated). The virtual gamepad devices exist in the Windows gamepad device stack and can be found by WinRT enumeration links.

[0013] After a user enters a cloud desktop or cloud gaming session, a mapping relationship needs to be established on the session side between the user session, input channel, device instance identifier, virtual slot, connection status, and input cache—that is, the session mapping relationship. Specifically, a correspondence can be established between user sessions and input channels, and one or more virtual gamepad devices can be assigned or bound to that session (each virtual gamepad device corresponds to a gamepad device on the user side entity). The corresponding device instance identifier, virtual slot, and connection status are recorded. Simultaneously, an independent input cache is created for that session to store the most recent valid gamepad input status and timestamp (this timestamp has the same meaning as the timestamp in the basic status). This session mapping relationship is the data foundation for all subsequent session isolation operations. When the target program enumerates gamepads through the WinRT interface, it first obtains the underlying gamepad device enumeration results from the Windows system, then queries the session mapping relationship to find all virtual gamepad devices belonging to the user session of the target program in the enumeration results, thus achieving session isolation of the gamepad enumeration results from the WinRT interface.

[0014] S11. After the Windows cloud host receives the user's gamepad input, it determines the user session to which the gamepad input belongs by querying the session mapping relationship based on the input channel to which the gamepad input belongs, and writes the gamepad input into the input cache corresponding to the target virtual gamepad device in the user session. In this embodiment, it should be noted that the target virtual controller device is the virtual controller device corresponding to the user's physical controller device. By writing the user's controller input into the input buffer of the target virtual controller device in the corresponding user session, session-based isolation of controller input writing can be achieved. In addition to writing the controller input into the corresponding input buffer, the most recent valid input status and timestamp of the corresponding virtual controller device can also be updated.

[0015] S12. When the target program reads the target virtual gamepad device status through the WinRT interface, it determines the input buffer corresponding to the target virtual gamepad device by querying the session mapping relationship, obtains the gamepad input status from the input buffer corresponding to the target virtual gamepad device, generates the status data corresponding to the target virtual gamepad device based on the gamepad input status, and returns the status data to the target program.

[0016] In this embodiment, it should be noted that when the target program reads the target virtual gamepad device status through the WinRT interface, it determines the corresponding input cache by querying the session mapping relationship, then obtains the gamepad input status, generates status data and returns it to the target program, thus achieving session-based isolation of gamepad input status reading.

[0017] The WinRT gamepad input processing method provided in this application embodiment for a Windows multi-session environment has two aspects. First, when a target program on a Windows cloud host enumerates gamepads through the WinRT interface, it determines the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying a pre-established session mapping relationship. A device object is generated based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, and the device object is returned to the target program. This ensures that the target program sees the virtual gamepad device of its own session and not the virtual gamepad devices of other sessions. Second, after the Windows cloud host receives user gamepad input, it processes the input through the input channel to which the gamepad input belongs. First, by querying the session mapping relationship to determine the user session to which the gamepad input belongs, the gamepad input is written to the input buffer corresponding to the target virtual gamepad device in that user session. This ensures that the gamepad input sent from the user terminal to the cloud is written to the correct virtual gamepad device. Second, when the target program reads the status of the target virtual gamepad device through the WinRT interface, the session mapping relationship is queried to determine the input buffer corresponding to the target virtual gamepad device. The gamepad input status is obtained from the input buffer corresponding to the target virtual gamepad device, and the status data corresponding to the target virtual gamepad device is generated based on the gamepad input status. The status data is then returned to the target program, ensuring that the target program obtains the correct gamepad input through the WinRT interface. In summary, the entire solution enables the program to effectively access the gamepad through the WinRT interface.

[0018] Based on the foregoing method embodiments, the step of generating state data corresponding to the target virtual controller device according to the controller input state may include: Convert the controller input state into a data object in the corresponding format according to the WinRT input path used by the target program.

[0019] In this embodiment, it should be noted that the controller input state needs to be translated into a corresponding data object format based on the WinRT path used by the target program. Specifically, for the Gamepad path, the controller input state needs to be filled into a GamepadReading structure; for the RawGameController path, a corresponding data object format needs to be generated based on the controller input state. The data object includes an array of buttons, an array of switches, an array of axes, and a timestamp, where the timestamp is the timestamp recorded in the input buffer; for the custom controller factory path, state data needs to be generated according to the format defined by the custom controller factory based on the controller input state, the virtual slot and connection status of the target virtual controller device. Specifically, for the custom controller factory path, the custom controller object created by the factory needs to be bound to the session mapping relationship during the factory query phase (i.e., when the target program obtains the custom controller object corresponding to the target virtual controller device) to find the correct controller input state during subsequent readings. Because the session mapping relationship can also include the controller object corresponding to the target virtual controller device (different types of controller objects correspond to different WinRT input paths), when the target program reads the state of the target virtual controller device through the controller object, it can query the session mapping relationship to determine the input buffer corresponding to the controller object of the target virtual controller device. This embodiment can adapt to various WinRT input paths, ensuring that the target program can obtain the correct controller status when accessing the controller.

[0020] Based on the foregoing method embodiments, the method may further include: Intercept the gamepad events triggered during WinRT runtime, determine the user session to which the gamepad events belong, and if it is determined that the user session to which the gamepad events belong is the user session to which the target program belongs, then send the gamepad events to the target program. The target program has registered gamepad events, which include connection events and disconnect events.

[0021] In this embodiment, a filter is essentially implemented at the WinRT event layer. When a user session experiences login / logout / screen lock / unlock / device refresh / handset change, the WinRT runtime triggers a handset event (connection event / disconnection event). The filter intercepts this handset event, determines its user session by querying the session mapping relationship based on the device instance identifier of the handset device object carried by the event, and then sends the handset event to the target program in the user session that has registered the handset event. This achieves filtering of handset events by user session, so when other sessions experience login / logout / screen lock / unlock / device refresh / handset change, the handset connection status seen by the target program in the current session will not be directly changed.

[0022] Based on the foregoing method embodiments, the method may further include: When the operating system enumerates handles and the result is empty, the enumeration fails, or the number of handles enumerated decreases compared to the previous enumeration, a cache snapshot of the handle list from the most recently successfully enumerated handles is obtained as the enumeration result.

[0023] In this embodiment, when the operating system's controller enumeration results fluctuate—that is, when the controller enumeration result is empty, fails, or the number of controllers enumerated decreases compared to the previous enumeration—it needs to obtain a cached snapshot of the most recently successfully enumerated controller list as the enumeration result. Thus, when the target program actively queries the controller list, the system does not directly return the original result of the underlying enumeration corresponding to the user session to which the target program belongs to the game. Instead, it returns the previous normal cached snapshot corresponding to the user session to which the target program belongs, ensuring that the controller list seen by the game remains unchanged. In other words, events in other sessions cause fluctuations in the underlying enumeration, but the game always receives a stable snapshot of the controllers from the current session and is unaware of the fluctuations.

[0024] Based on the foregoing method embodiments, the method may further include: If it fails to retrieve the controller input state from the input buffer corresponding to the target virtual controller device, then retrieve the zero state or the controller input state that was successfully read last time as the result.

[0025] In this embodiment, when the input source of the user session is temporarily unavailable, a zero state can be obtained or the original virtual slot state can be maintained to prevent the target program from mistakenly judging that the handle is disconnected, switched or malfunctioned due to a single reading failure.

[0026] Based on the foregoing method embodiments, the method may further include: After the virtual controller device is rebuilt, the device instance identifier and virtual slot of the original virtual controller device are determined by querying the session mapping relationship. The device instance identifier and virtual slot of the rebuilt virtual controller device are then updated using the original virtual controller device's device instance identifier and virtual slot.

[0027] In this embodiment, after the virtual controller device is rebuilt, the original virtual slot can be restored according to the session mapping relationship, and connection or status events can be resent if necessary, allowing the target program to continue to obtain WinRT controller input for the current session. Furthermore, the original virtual slot can still be restored after the user disconnects and reconnects or the target program restarts, thus maintaining the continuity of the current session controller.

[0028] Reference Figure 2 The diagram shown is a structural schematic of a WinRT gamepad input processing device in a Windows multi-session environment provided in an embodiment of this application. The device includes: The first return unit 20 is used to determine the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying the pre-established session mapping relationship when the target program enumerates the gamepad through the WinRT interface on the Windows cloud host. It generates a device object based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, and returns the device object to the target program. The virtual gamepad driver is deployed on the Windows cloud host. The virtual gamepad driver is used to provide the operating system with virtual gamepad devices that can be identified by the Windows device enumeration link, and to allocate a device instance identifier and virtual slot for each virtual gamepad device. The session mapping relationship includes user session, input channel, device instance identifier of virtual gamepad device, virtual slot of virtual gamepad device, connection status of virtual gamepad device, and input buffer. The writing unit 21 is used to determine the user session to which the handle input belongs by querying the session mapping relationship after the Windows cloud host receives the user's handle input, based on the input channel to which the handle input belongs, and write the handle input into the input cache corresponding to the target virtual handle device in the user session; The second return unit 22 is used to determine the input buffer corresponding to the target virtual gamepad device by querying the session mapping relationship when the target program reads the target virtual gamepad device status through the WinRT interface, obtain the gamepad input status from the input buffer corresponding to the target virtual gamepad device, generate the status data corresponding to the target virtual gamepad device based on the gamepad input status, and return the status data to the target program.

[0029] The WinRT gamepad input processing device provided in this application embodiment for a Windows multi-session environment, in the first aspect, when a target program on a Windows cloud host enumerates gamepads through the WinRT interface, it determines the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying a pre-established session mapping relationship. A device object is generated based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, and the device object is returned to the target program. This ensures that the target program sees the virtual gamepad device of its own session and not the virtual gamepad devices of other sessions. In the second aspect, after the Windows cloud host receives user gamepad input, it processes the input according to the input channel to which the gamepad input belongs, through... First, by querying the session mapping relationship to determine the user session to which the gamepad input belongs, the gamepad input is written to the input buffer corresponding to the target virtual gamepad device in that user session. This ensures that the gamepad input sent from the user terminal to the cloud is written to the correct virtual gamepad device. Second, when the target program reads the status of the target virtual gamepad device through the WinRT interface, the session mapping relationship is queried to determine the input buffer corresponding to the target virtual gamepad device. The gamepad input status is obtained from the input buffer corresponding to the target virtual gamepad device, and the status data corresponding to the target virtual gamepad device is generated based on the gamepad input status. The status data is then returned to the target program, ensuring that the target program obtains the correct gamepad input through the WinRT interface. In summary, the entire solution enables the program to effectively access the gamepad through the WinRT interface.

[0030] The WinRT gamepad input processing device in the Windows multi-session environment provided in this application embodiment is implemented in the same way as the WinRT gamepad input processing method in the Windows multi-session environment provided in this application embodiment, and the effect it achieves is also the same as the WinRT gamepad input processing method in the Windows multi-session environment provided in this application embodiment, so it will not be described again here.

[0031] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing WinRT gamepad input in a Windows multi-session environment, characterized in that, include: When the target program enumerates the gamepad through the WinRT interface on the Windows cloud host, it determines the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying the pre-established session mapping relationship. Based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, a device object is generated and returned to the target program. The virtual gamepad driver is deployed on the Windows cloud host. The virtual gamepad driver is used to provide the operating system with virtual gamepad devices that can be identified by the Windows device enumeration link, and to allocate a device instance identifier and virtual slot for each virtual gamepad device. The session mapping relationship includes user session, input channel, device instance identifier of virtual gamepad device, virtual slot of virtual gamepad device, connection status of virtual gamepad device, and input buffer. After the Windows cloud host receives user gamepad input, it determines the user session to which the gamepad input belongs by querying the session mapping relationship based on the input channel to which the gamepad input belongs, and writes the gamepad input into the input cache corresponding to the target virtual gamepad device in that user session; When the target program reads the target virtual gamepad device status through the WinRT interface, it determines the input buffer corresponding to the target virtual gamepad device by querying the session mapping relationship, obtains the gamepad input status from the input buffer corresponding to the target virtual gamepad device, generates the status data corresponding to the target virtual gamepad device based on the gamepad input status, and returns the status data to the target program.

2. The method as described in claim 1, characterized in that, The step of generating status data corresponding to the target virtual controller device based on the controller input status includes: Convert the controller input state into a data object in the corresponding format according to the WinRT input path used by the target program.

3. The method as described in claim 2, characterized in that, The step of converting the handle input state into a data object in the corresponding format according to the WinRT input path used by the target program includes: If the target program uses the WinRT input path as the Gamepad path, then populate the gamepad input state into a GamepadReading structure; or If the target program uses the RawGameController path as its WinRT input path, then a data object in the corresponding format is generated based on the controller input state. This data object includes an array of buttons, an array of switches, an array of axes, and a timestamp. Alternatively... If the WinRT input path used by the target program is a custom controller factory path, then based on the gamepad input status, the virtual slot and connection status of the target virtual gamepad device, status data is generated according to the format defined by the custom controller factory.

4. The method as described in claim 3, characterized in that, If the target program uses a WinRT input path that is a custom controller factory path, then before determining the input cache corresponding to the target virtual gamepad device by querying the session mapping relationship, the following steps are also included: When the target program obtains the custom controller object corresponding to the target virtual gamepad device, it binds the custom controller object to the session mapping relationship.

5. The method as described in claim 1, characterized in that, Also includes: Intercept the gamepad events triggered during WinRT runtime, determine the user session to which the gamepad events belong, and if it is determined that the user session to which the gamepad events belong is the user session to which the target program belongs, then send the gamepad events to the target program. The target program has registered gamepad events, which include connection events and disconnect events.

6. The method as described in claim 1, characterized in that, Also includes: When the operating system enumerates handles and the result is empty, the enumeration fails, or the number of handles enumerated decreases compared to the previous enumeration, a cache snapshot of the handle list from the most recently successfully enumerated handles is obtained as the enumeration result.

7. The method as described in claim 1, characterized in that, Also includes: If it fails to retrieve the controller input state from the input buffer corresponding to the target virtual controller device, then retrieve the zero state or the controller input state that was successfully read last time as the result.

8. The method as described in claim 1, characterized in that, Also includes: After the virtual controller device is rebuilt, the device instance identifier and virtual slot of the original virtual controller device are determined by querying the session mapping relationship. The device instance identifier and virtual slot of the rebuilt virtual controller device are then updated using the original virtual controller device's device instance identifier and virtual slot.

9. A WinRT gamepad input processing device for a Windows multi-session environment, characterized in that, include: The first return unit is used to determine the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs by querying the pre-established session mapping relationship when the target program enumerates the gamepad through the WinRT interface on the Windows cloud host. It generates a device object based on the device instance identifier, virtual slot, and connection status of the virtual gamepad device corresponding to the user session to which the target program belongs, and returns the device object to the target program. The virtual gamepad driver is deployed on the Windows cloud host. The virtual gamepad driver is used to provide the operating system with virtual gamepad devices that can be identified by the Windows device enumeration link, and to allocate a device instance identifier and virtual slot for each virtual gamepad device. The session mapping relationship includes user session, input channel, device instance identifier of virtual gamepad device, virtual slot of virtual gamepad device, connection status of virtual gamepad device, and input buffer. The writing unit is used to determine the user session to which the gamepad input belongs by querying the session mapping relationship after the Windows cloud host receives the user's gamepad input, based on the input channel to which the gamepad input belongs, and write the gamepad input into the input buffer corresponding to the target virtual gamepad device in the user session; The second return unit is used to determine the input buffer corresponding to the target virtual gamepad device by querying the session mapping relationship when the target program reads the target virtual gamepad device status through the WinRT interface, obtain the gamepad input status from the input buffer corresponding to the target virtual gamepad device, generate the status data corresponding to the target virtual gamepad device based on the gamepad input status, and return the status data to the target program.

Images