01/23/2019
Month 3, Week 3
Author: Devin Wright
At this time, I have finally gotten the IOHIDManager to work so that I can detect connected controllers and receive input. The big piece I was missing to get it working was that I had to launch a separate thread that had to both create and init the IOHIDManagerRef, and then call CFRunLoopRun() which blocks the current thread and uses it to process the messages for the IOHIDManager. I also did all of this within a class which seemed to be a necessary step as I had another demo beforehand that was implemented in a similar fashion but did not use classes, however, I am not 100% certain of this. The working demo was also created as a command line tool (Macs version of a console app) rather than a Cocoa App which may have had an impact as well but this is untested.
Now that I can detect the controllers I have to find out how to properly read input events from the controllers. As of right now, I know how to register to receive the events from the controllers, however, I do not have a way to tell what button is sending the event. Also, currently I am not receiving axis events from the PS4 controller. So, I am looking to see if I can get the information from the IOHIDElement received in the input event function. Otherwise, I may have to look into reading the output reports from the controller, the problem with that is they will most likely be unique for both the PS4 and Xbox controllers making a general implementation more difficult.
Monday, January 28, 2019
Wednesday, January 23, 2019
Finishing the Linux implementation for GController
01/23/2019
Month 3, Week 2
Author: Devin Wright
This last week was spent implementing GController on Linux. I ended up running into a few roadblocks while adapting the code from my Linux demos. First, the js files that were planned to be used to read input from the controllers change formats between the different Linux distributions. This wasn't too much of a problem as I had already looked into using evdev to read from event files instead. The reason I planned to go with the js files was that I originally thought that the PS4 controller did not create a usable event file, however, with further testing, I proved that I was wrong. The other major roadblock I ran into was that evdev didn't have an obvious way to check if an event file belonged to a controller. I ended up looking through the libevdev wrapper library for an example of how to do this. It turns out one of the ioctl request (EVOCGBIT) in the linux/input.h is caple of returning an array of long bits that holds what type of events the device is capable of.
With the Linux implementation being almost completely finished, these next two weeks will be spent on the Mac implementation. Mac will definitely be the hardest to implement as I still do not have a working demo to start from. Currently, I am looking through the apple demos to see why their work and my do not.
Month 3, Week 2
Author: Devin Wright
This last week was spent implementing GController on Linux. I ended up running into a few roadblocks while adapting the code from my Linux demos. First, the js files that were planned to be used to read input from the controllers change formats between the different Linux distributions. This wasn't too much of a problem as I had already looked into using evdev to read from event files instead. The reason I planned to go with the js files was that I originally thought that the PS4 controller did not create a usable event file, however, with further testing, I proved that I was wrong. The other major roadblock I ran into was that evdev didn't have an obvious way to check if an event file belonged to a controller. I ended up looking through the libevdev wrapper library for an example of how to do this. It turns out one of the ioctl request (EVOCGBIT) in the linux/input.h is caple of returning an array of long bits that holds what type of events the device is capable of.
With the Linux implementation being almost completely finished, these next two weeks will be spent on the Mac implementation. Mac will definitely be the hardest to implement as I still do not have a working demo to start from. Currently, I am looking through the apple demos to see why their work and my do not.
Friday, January 11, 2019
Begining the Linux implementaion of Gateware
01/11/2019
Month 3, Week1
Author: Devin Wright
This week was spent writing out the implementation for handling Xbox controller vibration on Windows, removing 32-bit from support from our cmake files, and starting on the Linux implementation of GController. I had previously added the interface for the vibration support before the break, then I spent the first two days back writing out its unit test, implementing the Xbox version of the methods, and tested it to make sure everything works. After, that I began removing 32-bit support from the cmake files. This had to be done since as of the Mojave update for Mac Os 32-bit is no longer supported, and the cmake was unable to create a solution for Gateware on Mac. This was done by removing the calls to create 32-bit files from the "command line" files (.bat, .command, and a unix executable for Windows, Mac, and Linux respectively).
When it comes to implementing Linux there is a lot less work compared to implementing Windows since most of the groundwork has now been laid. For Linux, I mainly just need to integrate the code from my Linux demos, and then just make whatever changes are needed to get them properly running. The idea is to have a thread for each controller being processed and have these threads handled by the loop running the inotify events. The controllers will then be handled in their own event loops where their input will be processed and stored in the controllers' array.
Month 3, Week1
Author: Devin Wright
This week was spent writing out the implementation for handling Xbox controller vibration on Windows, removing 32-bit from support from our cmake files, and starting on the Linux implementation of GController. I had previously added the interface for the vibration support before the break, then I spent the first two days back writing out its unit test, implementing the Xbox version of the methods, and tested it to make sure everything works. After, that I began removing 32-bit support from the cmake files. This had to be done since as of the Mojave update for Mac Os 32-bit is no longer supported, and the cmake was unable to create a solution for Gateware on Mac. This was done by removing the calls to create 32-bit files from the "command line" files (.bat, .command, and a unix executable for Windows, Mac, and Linux respectively).
When it comes to implementing Linux there is a lot less work compared to implementing Windows since most of the groundwork has now been laid. For Linux, I mainly just need to integrate the code from my Linux demos, and then just make whatever changes are needed to get them properly running. The idea is to have a thread for each controller being processed and have these threads handled by the loop running the inotify events. The controllers will then be handled in their own event loops where their input will be processed and stored in the controllers' array.
Subscribe to:
Posts (Atom)