11/30/2018
Month 2, Week 2
Author: Devin Wright
This last week was mostly spent writing the interface shell, I also spent some time looking into how to simulate a Xbox controller on Windows for the use with the unit test in the future. The time spent on the shell was to transfer the interface from the API document while making any necessary changes, writing out the Doxygen comments, creating the .cpp file, and defining the input codes for use with the interface. For the unit test it appears we will have to use a driver in order to simulate a virtual controller that can be detected by Xinput. There are a few options to do this currently I plan to look into using something like ViGEm or Vbox as possible options.
With the shell of the interface written out I can now begin writing the simple form of unit tests that won't require the virtual controller. The virtual controller won't be worried about until around the fourth mouth after everything else has been fleshed out. After, creating unit tests for both the regular function calls and the events it will then be time to begin implementing the functions of the interface so that they can pass the unit tests.
Friday, November 30, 2018
Monday, November 26, 2018
Finishing up my first month on Gateware
11/26/2018
Month 1, Week 4.5
Author: Devin Wright
With most of last week being Thanksgiving break, well also having a delay in receiving feedback on the first draft of my API document. The week was mainly spent re-writing and finalizing the document in order to wrap up the month's work. During, the break I spent some time looking into possible leads for controller implementation on Mac. However, I have not made much progress towards figuring out how to use Run Loops with the HIDManager, yet I still believe the Run Loops to be a possible fix.
Since this week will be the first real week of month two, I have begun writing out the shell of my interface so that later this month I can add my test cases and my Windows implementation. The plan is to transfer the interface that was planed in the API document, making changes as needed to adhere to Gateware's standards. I also need to decide on how I want to set up my input code, as Lari had the idea to have them use a multi-byte code so that they can identify more than just what button/axis is being polled. This will be helpful since the interface will provide separate support for certain controllers, and this will provide an easy way to tell if the code is supported by the current function. The bytes in the code can also be used to provide any other information I may need from the input codes.
Month 1, Week 4.5
Author: Devin Wright
With most of last week being Thanksgiving break, well also having a delay in receiving feedback on the first draft of my API document. The week was mainly spent re-writing and finalizing the document in order to wrap up the month's work. During, the break I spent some time looking into possible leads for controller implementation on Mac. However, I have not made much progress towards figuring out how to use Run Loops with the HIDManager, yet I still believe the Run Loops to be a possible fix.
Since this week will be the first real week of month two, I have begun writing out the shell of my interface so that later this month I can add my test cases and my Windows implementation. The plan is to transfer the interface that was planed in the API document, making changes as needed to adhere to Gateware's standards. I also need to decide on how I want to set up my input code, as Lari had the idea to have them use a multi-byte code so that they can identify more than just what button/axis is being polled. This will be helpful since the interface will provide separate support for certain controllers, and this will provide an easy way to tell if the code is supported by the current function. The bytes in the code can also be used to provide any other information I may need from the input codes.
Friday, November 16, 2018
Third week on Gateware Linux research
11/16/2018
Month 1, Week 4
Author: Devin Wright
This week was spent researching and implementing Linux controller support, as well as writing up the first draft of my API document. Having done some initial research on Linux back in week one I had a pretty good idea of where to start. My original lead was to look into the use of evdev for reading event devices created in /dev/input, however when testing the PS4 controller I found that it does not create a event for button/axes input(it does create an event but it is for the touch pad which it treated like a mouse) it does create a joystick though. At first I tried to read from the /dev/input/js files using evdev to no avail. So, I began looking into how to read data from js files and found that Linux has a Joystick API for reading from them. After, creating a demo using the Joystick API I looked into finding a way to detect when new js files were created and deleted and found the inotify API which can be used to get events when new files are added or deleted from a directory. I also created a small demo to test and see if I could create a file directory from using inotify which was a success.
At this point I have started writing up the final draft for my API documentation, and I am also continuing my research into Mac controller support. After, I finish my API documentation if I time before the start of next month I will spend some time going back and looking into controller support on Mac. One thing I want to look at is the proper use of Run Loops which I believe might be one of the keys to fixing my HIDManager implementation.
Month 1, Week 4
Author: Devin Wright
This week was spent researching and implementing Linux controller support, as well as writing up the first draft of my API document. Having done some initial research on Linux back in week one I had a pretty good idea of where to start. My original lead was to look into the use of evdev for reading event devices created in /dev/input, however when testing the PS4 controller I found that it does not create a event for button/axes input(it does create an event but it is for the touch pad which it treated like a mouse) it does create a joystick though. At first I tried to read from the /dev/input/js files using evdev to no avail. So, I began looking into how to read data from js files and found that Linux has a Joystick API for reading from them. After, creating a demo using the Joystick API I looked into finding a way to detect when new js files were created and deleted and found the inotify API which can be used to get events when new files are added or deleted from a directory. I also created a small demo to test and see if I could create a file directory from using inotify which was a success.
At this point I have started writing up the final draft for my API documentation, and I am also continuing my research into Mac controller support. After, I finish my API documentation if I time before the start of next month I will spend some time going back and looking into controller support on Mac. One thing I want to look at is the proper use of Run Loops which I believe might be one of the keys to fixing my HIDManager implementation.
Friday, November 9, 2018
Second week on Gateware, researching Mac controller support
11/9/2018
Month 1, Week3
Author: Devin Wright
This last week I spent looking into implementing controller support for the Xbox 360 controller on Mac OS X. After, discovering last week that Mac's Game Controller framework does not support them I had began to look into IOHIDManager as a potential work around. However, for the IOHIDManager to work the device being detected has to registered to belong in one of the categories available for creating a matching dictionary used for searching for connected devices. The problem being that since the Xbox 360 controller is not detected as a controller by the OS, it is unclear how to search for the controller using the IOHIDManager ( or if it is possible at all). I am tipped in the direction that the IOHIDManager is not usable for reading input from a Xbox 360 controller, as none of the sources I have found have incorporated it. Instead all of them use a different part of the IOKIT framework to read the bytes sent by the controller and then interoperate the results. However, as these sources are attached to drivers designed to implement Xbox 360 controller support, I might risk making my Implementation depended on a driver if I follow their implementation, as it is unclear how much they affect the output from the controller.
As of right now I am currently testing available controllers to see if I can find one that work as a MFI controller. So, that I can use the Game Controller framework for proving it as a reliable backup, and if needed move Xbox 360 controller support to a B-Level feature to be implemented when I have more time to look into it. Since, I still have to look into and implement my demo of controller support on Linux, as well as write up my API documentation. For Linux I am looking into using the edev library, or a library that wraps up its complexities as it is a fairly low level library. However, no testing has been done yet to see what the library will support, and Linux documentation is scarce.
Month 1, Week3
Author: Devin Wright
This last week I spent looking into implementing controller support for the Xbox 360 controller on Mac OS X. After, discovering last week that Mac's Game Controller framework does not support them I had began to look into IOHIDManager as a potential work around. However, for the IOHIDManager to work the device being detected has to registered to belong in one of the categories available for creating a matching dictionary used for searching for connected devices. The problem being that since the Xbox 360 controller is not detected as a controller by the OS, it is unclear how to search for the controller using the IOHIDManager ( or if it is possible at all). I am tipped in the direction that the IOHIDManager is not usable for reading input from a Xbox 360 controller, as none of the sources I have found have incorporated it. Instead all of them use a different part of the IOKIT framework to read the bytes sent by the controller and then interoperate the results. However, as these sources are attached to drivers designed to implement Xbox 360 controller support, I might risk making my Implementation depended on a driver if I follow their implementation, as it is unclear how much they affect the output from the controller.
As of right now I am currently testing available controllers to see if I can find one that work as a MFI controller. So, that I can use the Game Controller framework for proving it as a reliable backup, and if needed move Xbox 360 controller support to a B-Level feature to be implemented when I have more time to look into it. Since, I still have to look into and implement my demo of controller support on Linux, as well as write up my API documentation. For Linux I am looking into using the edev library, or a library that wraps up its complexities as it is a fairly low level library. However, no testing has been done yet to see what the library will support, and Linux documentation is scarce.
Thursday, November 1, 2018
First week on Gateware and Researching controller input
11/1/2018
Month 1, Week 2
Author: Devin Wright
I spent the first week reading through the documents and source code of the Gateware project. Also, I started my research into implementing controller support library for Gateware. I found that on the Windows OS there are three APIs for controller support; Xinput, Directinput, and RawController(which has a child class called Gamepad for handling hand-held controllers). RawController will not be a viable option as it is only available to UWP apps, and Gateware currently runs as a win32. For now Xinput seems like the best choice for windows as of right now since, Directinput is harder to set up and even though it works with more controllers than Xinput it is unsure yet if the other OSs will be capable of the same. With this knowledge I made a small demo to test Xinput, it worked as expected and was very easy to set up meaning that Xinput will be a viable way to implement controller support on Windows.
This week I continued looking into controller support on Mac OS X. At First I believed that It could be implemented quite easily using the Mac Game Controller framework. However, when I went to implement the demo for it I discovered that the framework only works for MFI(Made for IPhone) controllers which our targeted controller(Xbox 360) is not supported as one. With that dead end I began looking for an alternative approach, and with what I have found so far it appears I can use the Mac's IOKIT/HIDManager framework to read input from the controller as a HID device, and then translate it into the values representing the state of each button on the controller. Currently I do not know a lot about this framework, however it seem like a viable way to get the input that I need.
Month 1, Week 2
Author: Devin Wright
I spent the first week reading through the documents and source code of the Gateware project. Also, I started my research into implementing controller support library for Gateware. I found that on the Windows OS there are three APIs for controller support; Xinput, Directinput, and RawController(which has a child class called Gamepad for handling hand-held controllers). RawController will not be a viable option as it is only available to UWP apps, and Gateware currently runs as a win32. For now Xinput seems like the best choice for windows as of right now since, Directinput is harder to set up and even though it works with more controllers than Xinput it is unsure yet if the other OSs will be capable of the same. With this knowledge I made a small demo to test Xinput, it worked as expected and was very easy to set up meaning that Xinput will be a viable way to implement controller support on Windows.
This week I continued looking into controller support on Mac OS X. At First I believed that It could be implemented quite easily using the Mac Game Controller framework. However, when I went to implement the demo for it I discovered that the framework only works for MFI(Made for IPhone) controllers which our targeted controller(Xbox 360) is not supported as one. With that dead end I began looking for an alternative approach, and with what I have found so far it appears I can use the Mac's IOKIT/HIDManager framework to read input from the controller as a HID device, and then translate it into the values representing the state of each button on the controller. Currently I do not know a lot about this framework, however it seem like a viable way to get the input that I need.
Subscribe to:
Posts (Atom)