Proton-GE-Custom项目中的游戏控制器工作原理深度解析

Proton-GE-Custom项目中的游戏控制器工作原理深度解析

proton-ge-custom 项目地址: https://gitcode.com/gh_mirrors/pr/proton-ge-custom

控制器API概述

在Windows游戏环境中，开发者可以通过五种主要API与游戏控制器交互：

1. RawInput：提供对游戏控制器硬件的直接访问，需要应用程序了解HID协议或特定设备协议（如Xbox控制器）

2. HID：位于RawInput之上的抽象层，Windows代表游戏与控制器进行HID通信，将原始HID协议数据转换为可用的按钮和摇杆信号

3. DirectInput (dinput)：传统API，支持所有类型的游戏杆设备，在现代Windows上基于HID实现。尽管被标记为"传统"，但因其广泛的兼容性仍被现代游戏使用

4. XInput：专为Xbox控制器设计的新API，在Windows上可能基于RawInput实现

5. WinMM：非常传统的API，最初用于通过声卡连接的操纵杆，现代Windows上基于DirectInput实现

Proton中的控制器处理架构

Proton采用分层架构处理控制器输入，以下是完整的处理流程：

游戏层
├─ 游戏应用程序(game.exe)
   ├─ XInput API
   ├─ WinMM API
   ├─ DirectInput API
   └─ HID API
      └─ RawInput API
         └─ Wine总线驱动(winebus.sys)
            ├─ SDL2输入处理
            │  ├─ HIDRAW设备访问
            │  └─ Linux输入事件
            └─ 直接HIDRAW访问
               └─ 物理硬件设备

关键组件解析

1. SDL2集成：

   • 提供Steam客户端的控制器映射功能
   • 未通过SDL2的输入将无法使用映射功能
   • winebus.sys需要将SDL2事件转换为可用的winebus数据(HID协议)

2. Xbox控制器特殊处理：

   • 原生不支持标准HID协议
   • Windows提供HID兼容层使DirectInput能识别Xbox控制器
   • Proton需要精确模拟Windows的这一行为

3. 多API支持策略：

   • 现代游戏可能直接支持特定控制器(如PS4手柄)
   • 不应将所有控制器都通过XInput呈现
   • XInput应仅用于Xbox控制器

控制器兼容性解决方案

Steam控制器映射

1. 功能实现：

   • 将任何控制器映射为虚拟Steam控制器
   • 虚拟Steam控制器再转换为XInput设备
   • 映射后的控制器对游戏表现为XInput设备

2. 优势：

   • 使仅支持XInput的游戏能使用任意控制器
   • 未映射的控制器保持原生设备特性

设备访问权限问题

1. 现实挑战：

   • 多数Linux发行版默认限制用户对hidraw设备的访问
   • Steam提供udev规则解决常见控制器的访问问题

2. 备用方案：

   • 当无法直接访问hidraw时，通过SDL2的Linux js后端访问
   • 尝试将设备视为Xbox控制器处理
   • 即使未使用Steam客户端映射功能也能工作

开发者注意事项

1. API选择影响：

   • 使用XInput会限制控制器类型识别
   • 直接使用RawInput/HID可获得更精确的设备信息

2. 兼容性考量：

   • 现代游戏应同时支持XInput和DirectInput
   • 特殊控制器支持(如PS4)需要直接HID访问

3. Linux环境适配：

   • 确保系统配置允许hidraw设备访问
   • 考虑备用输入路径(SDL2)的兼容性

通过这种精心设计的架构，Proton能够在Linux上为Windows游戏提供与原生环境几乎相同的控制器支持体验，同时解决了跨平台环境下的各种兼容性挑战。

proton-ge-custom 项目地址: https://gitcode.com/gh_mirrors/pr/proton-ge-custom