Hi,
please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Some things can be dropped I think, OpenMP maybe?
Thanks!
On 10.02.2016 22:04, André Hentschel wrote:
Hi,
please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Some things can be dropped I think, OpenMP maybe?
Thanks!
For OpenMP there are a couple of minor tasks left, but probably not enough for GSoC project. I've removed it from the wiki.
Direct3DRM can still be continued. There's still quite some things left before actual rendering is shown on the screen.
On Thu, Feb 11, 2016 at 2:39 AM, Sebastian Lackner sebastian@fds-team.de wrote:
On 10.02.2016 22:04, André Hentschel wrote:
Hi,
please update https://wiki.winehq.org/Summer_Of_Code with your Ideas
and mention yourself as possible mentor where appropriate.
Some things can be dropped I think, OpenMP maybe?
Thanks!
For OpenMP there are a couple of minor tasks left, but probably not enough for GSoC project. I've removed it from the wiki.
Hi,
I saw the XInput (Xbox controller input) entry on the SoC site and was wondering what the requirements are.
Context: I implemented XInput (Input + Rumble) a few months ago and have been using it to play XInput-only games since. My implementation allows for different backends, but I've only implemented an evdev backend for linux. I also started working on editable controller mappings through registry entries. I didn't try to submit any patches or finish the mapping config, since by the time I had polished my code enough, the hidclass development had gained steam and it seemed that that was what wine was supposed to use for XInput.
Another option, and in my opinion the cleanest, would be to directly access XBox controllers through USB, possibly using code from the xboxdrv project.
What are your thoughts on this? Should the XInput driver be based on hidclass, xboxdrv, or should it be able to use different backends? If it's just supposed to use hidclass, my implementation is pretty much useless, since splitting backend and driver seems like unnecessary overhead when hidclass already uses different backends.
On 02/10/2016 10:04 PM, André Hentschel wrote:
Hi,
please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Some things can be dropped I think, OpenMP maybe?
Thanks!
On 2/11/16 1:51 AM, Juan Jose Gonzalez wrote:
Hi,
Hello!
I saw the XInput (Xbox controller input) entry on the SoC site and was wondering what the requirements are.
Context: I implemented XInput (Input + Rumble) a few months ago and have been using it to play XInput-only games since. My implementation allows for different backends, but I've only implemented an evdev backend for linux. I also started working on editable controller mappings through registry entries. I didn't try to submit any patches or finish the mapping config, since by the time I had polished my code enough, the hidclass development had gained steam and it seemed that that was what wine was supposed to use for XInput.
Another option, and in my opinion the cleanest, would be to directly access XBox controllers through USB, possibly using code from the xboxdrv project.
What are your thoughts on this? Should the XInput driver be based on hidclass, xboxdrv, or should it be able to use different backends? If it's just supposed to use hidclass, my implementation is pretty much useless, since splitting backend and driver seems like unnecessary overhead when hidclass already uses different backends.
As the primary author working on the HID support I feel pretty strongly that we should be using the HID back-end for Xinput. Xinput support is actually a large part of why I have been working on it. I feel like yet another controller implementation that has its own back ends is really not what wine needs.
I doubt that all your work would be useless. There is still a lot of Xinput work that happens above the backend. I am sure there is a lot there you have done that would be extremely valuable. Maybe you could start by using your existing code and think if HID as another back end to your code. I would recommend looking that the hid.dll functions for Xinput. It is likely there are hid.dll functions that are missing that you need. Those are additional opportunities for things to implement.
If we work together on this then it also gives some more weight to the HID infrastructure.
Your back end work is also probably still useful also. I assume it was using linux input, as opposed to hidraw or something, We still need someone to help with the back ends for HID and HidClass around linux input.
Both of that expertise would be extremely valuable!
-aric
On 02/10/2016 10:04 PM, André Hentschel wrote:
Hi,
please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Some things can be dropped I think, OpenMP maybe?
Thanks!
Hi,
Thank you for your answer. As soon as I have a little time I'll take a look at the HID infrastructure and try to create a backend for my code with it. Right now I'm pretty busy, but in a month or so I should have a little more free time.
I'll also post a patch for the "front-end" of my xinput implementation as soon as I find a little time to look over it, since it's been a while since I last touched it and I don't know if it's in a good enough state to be published.
Regards, Juan
On 02/11/2016 02:07 PM, Aric Stewart wrote:
On 2/11/16 1:51 AM, Juan Jose Gonzalez wrote:
Hi,
Hello!
I saw the XInput (Xbox controller input) entry on the SoC site and was wondering what the requirements are.
Context: I implemented XInput (Input + Rumble) a few months ago and have been using it to play XInput-only games since. My implementation allows for different backends, but I've only implemented an evdev backend for linux. I also started working on editable controller mappings through registry entries. I didn't try to submit any patches or finish the mapping config, since by the time I had polished my code enough, the hidclass development had gained steam and it seemed that that was what wine was supposed to use for XInput.
Another option, and in my opinion the cleanest, would be to directly access XBox controllers through USB, possibly using code from the xboxdrv project.
What are your thoughts on this? Should the XInput driver be based on hidclass, xboxdrv, or should it be able to use different backends? If it's just supposed to use hidclass, my implementation is pretty much useless, since splitting backend and driver seems like unnecessary overhead when hidclass already uses different backends.
As the primary author working on the HID support I feel pretty strongly that we should be using the HID back-end for Xinput. Xinput support is actually a large part of why I have been working on it. I feel like yet another controller implementation that has its own back ends is really not what wine needs.
I doubt that all your work would be useless. There is still a lot of Xinput work that happens above the backend. I am sure there is a lot there you have done that would be extremely valuable. Maybe you could start by using your existing code and think if HID as another back end to your code. I would recommend looking that the hid.dll functions for Xinput. It is likely there are hid.dll functions that are missing that you need. Those are additional opportunities for things to implement.
If we work together on this then it also gives some more weight to the HID infrastructure.
Your back end work is also probably still useful also. I assume it was using linux input, as opposed to hidraw or something, We still need someone to help with the back ends for HID and HidClass around linux input.
Both of that expertise would be extremely valuable!
-aric
On 02/10/2016 10:04 PM, André Hentschel wrote:
Hi,
please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Some things can be dropped I think, OpenMP maybe?
Thanks!