Hi Aric,
thanks for your reply.
On 02/15/2016 03:09 AM, Aric Stewart wrote:
Hi Juan,
Awesome thanks for this work. Know I am sure that to get this into wine will require a bit of work so hopefully you are will to go through the process of revisions with us to see things through.
Sure, I was expecting that, and I'll gladly help getting this through. One thing that should help is the fact that, as long as you don't add any backends, the code behaves like the previous stubs, so there's little risk for regressions.
Yeah, we will want to target the HID architecture and I can totally help you on that. I think it should be pretty straight forward. Looking at your back end interface code it all looks really pretty easy. There are parts you have around the mapping that I almost wonder if we want to move into that back end, or maybe a middle layer. I will have to spend more time reading the code before I can come up with anything concrete there.
I was thinking of two different stages for mappings. The first one maps whatever devices a backend speaks to to xinput buttons and axes and transforms the values to a common value range. That stage is backend-specific and should be embedded there. This is the type of mapping I was talking about below. The second stage is where the common value ranges are transformed to the value range of the target xinput button or axis. That is common to all backends, which is why I put it in the core. But we could look into moving that out of the core if you think that it doesn't belong there.
A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think.
The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet:
- How can we find new devices? The current work for the HID
architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar?
There are 2 bits here, hotplugging and device detection. They are 2 separate processes. Speaking on device detection, I think the best thing for us to do would be the process of enumerating the devices via setupapi and selecting the appropriate ones, as you have pointed out with the SetupDi functions. I have code that does this for winejoystick.dev implementation of HID that I have been working on, not sent anywhere yet, and it is not a difficult process. I will attach my winejoystick.drv module for inspiration/example but it is clearly not ready to actually be submitted as a patch, if for no other reason that all the supporting HID work is not in place yet.
Thanks for the attachment. In your code you seem to enumerate the available devices only once when you load the driver. XInput does not have any methods to open and close devices, it just provides methods to listen for key events and to poll the state of individial device slots. Therefore, the detection of newly connected controllers must be done by the backend continuously in order to be able to "connect" new slots as soon as devices become available. In the evdev backend I was listening for newly connected input devices, so RegisterDeviceNotification is, as you said, the way to go for the HID backend. Until that is ready, what do you think of running your detection code periodically in a separate thread, for example every 2s? Do you think that would cause a lot of overhead?
As for hot plugging that will come through plug and play processes that are still on the drawing board. Probably something eventually involving RegisterDeviceNotification once that gets some love.
I agree that mapping should be allowed for any appropriate controller and not restricting us to particular vendors. (Microsoft)
With HID we get Usages for all our elements. So what we will want to do is probably figure out what usages map to what control elements on an Xbox controller and have that be default mappings. (Here is the HID USB spec for usages http://www.usb.org/developers/hidpage/Hut1_12v2.pdf, windows HID matches these) so if the A button is page 0x9 Usage 0x1 then by default the element of 0x9 0x1 would be the A button. We would then want to be able to have a way to map other controllers. I am sure that existing controller maps exist, it would be nice if we could load/use them.
Xbox controllers aren't HID devices (bInterfaceClass = 0xff, vendor specific), so you probably won't find a HID usage map. We'll have to emulate the descriptors in the corresponding HID minidriver, so we are going to have to define mappings there as well. As a linux user I'd be inclined to use the codes from the uapi/linux/input-event-codes.h header (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/in...), where for example BTN_A is 0x130, as the usages for emulated HID devices. However, I don't know the input interfaces of other OSs, so that may not be the best idea.
Juan