August 19, 2012
So, the hard-pencils-down date is now just around the corner, and there were only a few small things left to be done.
Nothing radical happened since the last report just a few days ago. A couple of you left some comments that I haven’t yet had time to get to, but I sure will, hopefully soon.
The code for the GNOME Settings Daemon plugin and GNOME Control Center panel was refined a bit and documented where I felt it was required, and pushed into the GitHub forks (GSD – GCC) I’ve been using during this period. To mark the end point of the GSoC coding period I’ve created the GSOC_PENCILS_DOWN tags in both repositories (GSD – GCC) – there might still be some commits due to the merging of both components into their corresponding repositories at git.gnome.org. Two bugs were created to cover that effort, one for the GSD plugin and another for the GCC panel.
The design proposal was also updated to reflect the latest intention of the panel functionality. The design itself will most likely be quite important when merging the panel into the main trunk and enabling it.
Keeping it short this time, and covering pretty much everything I had in mind. You’re welcome to check out the project page to see more about how I spent this summer. But do note that the timeline there was at the end not really followed as closely as one would like.
August 16, 2012
The GSoC period is swiftly coming to its end, with the ‘soft pencils-down’ date already passed. While I’m not yet completely finished with my project I am very close, though, with only some small bits of functionality left to implement and with a quick walk through all the code to sort out the code styling issues and possible memory leaks.
Quite some time has passed since the last report and the work has progressed quite a lot in that time. The Gamepad API support in WebKitGTK+ was already complete and pretty polished so the only thing remaining was the implementation of the GNOME Settings Daemon plugin and GNOME System Settings panel. The former’s task would be to recognize supported devices as they are connected and apply to them the correct buttons and axes mappings and previously-stored calibration data. The latter would be used by the users to see if their device is supported and, if the device was well enough supported by the Linux kernel itself, the user could calibrate the device him- or herself.
What changed from the original idea
The most significant change is that originally, I was thinking of giving the users the complete control over the buttons and axes mappings. That would mean that each user would go through an annoying and long process of manually configuring the device. But such processes immediately require the user to understand more about his device and the general gamepad/joystick button and axis layout than it is either required or productive for everyday life. Rather than that the decision was made to spare the user all the hassle around the configuration and rather use preset buttons and axes mappings for specific devices.
This would of course mean that some users might connect a device that the system does not yet recognize as supported. The user could still interact with the device (the system would not block the device’s usage) but could also request that device is awarded the supported status with appropriate mappings assigned to its unique ID. Rather than waiting 6 months for the new release, the data about all the supported devices is stored on the Web and is cached locally and updated whenever a new device is given the supported status and the list of supported devices is expanded. While the Web-located list of supported devices is already working well in the current daemon plugin, the ‘support request’ is, at this moment, only an idea that needs more discussion about approach and implementation.
The GNOME Settings Daemon plugin was already described in quite some detail. The update of the supported devices list is done when a mismatch in the checksums of the local and Web-located list occurs. The checksums are compared when the daemon starts, and that’s normally when the session begins (at login). The devices list is written in JSON, so the plugin uses JSON-GLib to parse the list. The device is updated with proper mappings and current calibration through the Linux kernel driver. As much as convenient, these drivers are not quite the holy grail, but more on this later.
The GNOME System Settings panel, as already told, shows the connected devices, their support status, and provides calibration dialog if the device can handle it. The current design is my own, so it’s nothing extra (hopefully in either extreme, good or bad :>), but it has the functionality that it should provide. Here are the two screenshots, first shows the device listing, the second the calibration dialog.
The functionality of both the GNOME Settings Daemon plugin and the GNOME System Settings panel is there, all that remains to do in the time left in the GSoC period (three days :>) is to polish the code, document it and start the effort of merging back into the main repositories. The work was done in the mirror repositories I’ve set up on GitHub (the project page has more info on this), with all the work contained in the master branches.
I’ll open two separate bugs for each project in which I’ll upload the merge patches up for review. My mentor Carlos has already volunteered to do some reviewing while the two projects’ maintainers will have a thorough look as well, of course. The design proposal will be updated as well, based on the current panel design. GNOME designers will be invited to have a look, comment on the various approaches and present any design ideas in sketch form.
Hopefully, with a proper design and a couple of devices being supported, the maintainers will give the thumbs-up to enable both the daemon plugin and the control panel in trunk, so they’d make it into GNOME 3.6. If not, there will be enough time to polish both components to near-perfection for the 3.8 release. And talking of polishing things, the device drivers in the Linux kernel need some of that too.
The devices agony
Truth be told, this is partly a rant. And it’s only based on two devices that don’t work properly. I’ve invested into a Wii Remote and a Sony Playstation DualShock3 gamepad to see how they behave with GNOME. They’re both Bluetooth devices, with the DualShock being also connectable through a mini USB cable. Unfortunately, while I’ve had to put quite some effort into connecting the Wiimote, the DualShock stayed reluctant to connect via Bluetooth. But even when connected, the Wiimote wasn’t presented well as a joystick device (the /dev/input/js* file was there, but pretty much useless), neither was the accelerometer propagated as such through GUdev.
The DualShock, when connected through the USB cable, was picked up as a joystick device by the joydev driver, the generic joystick device driver in the kernel. But you’d think it’s quite a special device when it popped out with 27 axes and (if I remember correctly) 18 buttons. A normal gamepad has 6 axes (two of those are the D-pads) and 12 buttons. The DualShock has these neat pressure-sensitive buttons, but the sensor data is exposed as an axis instead of the button value being regulated between 0 and 1 based on that pressure. Also exported as device axes is the accelerometer data, which could (well, should) be exposed as what it is – an accelerometer. There are also a couple of axes that I wasn’t able to locate at all, so I guess that’s sort of a bonus.
While the inability to connect via Bluetooth probably falls under Bluez, it’s obvious DualShock should have a custom driver to handle all its features. There’s a Wiimote-specific driver but I’m not entirely sure of its status in the Linux 3.2 kernel (used when testing), this driver looks OK in Git master, exporting accelerometer data as well, but I haven’t had time yet to test it properly. The Xbox controllers have a specific driver, so they should work in theory but I haven’t tested them really (well, I should buy one first). But it’s the DualShock annoyance that bothers me the most, the device is expensive and advanced as well, but with the current support it turns out to be nothing more than a toy. The device driver wasn’t a planned goal of this GSoC project but it might as well be a late collateral damage.
This blog post has gotten a bit lengthy, so let’s end it. I’ll post another, final report on Sunday just to explain what was left undone and what was actually completed, along with the status of the merge, and where this project could still improve outside of the GSoC scope.
July 17, 2012
Weeks #7 and #8 contained the mid-term evaluation, which I passed (yay!). This event also signaling the mid-point of the project, there are still changes in the approach of the gamepad configuration panel implementation in GNOME Control Center.
The current idea
Currently the design proposal suggests the user could reconfigure the device’s buttons and axes if he or she finds them incorrectly configured (mapped). The mappings would then be saved via GSettings and loaded every time the device would connect to the system. Ideally the user would be able to report to the GNOME Bugzilla that he or she had to go through the configuration process and add to that report the data about the device and its new configuration.
These configurations would then be stored in some kind of a device list that would group the devices based on their axes and buttons layout. If the user would connect an unrecognized device, he or she could search through the different types of devices to find a layout that would suit his or hers device and report that to the GNOME Bugzilla. That device would then be added to the appropriate layout group.
Axis calibration would also be available for those more advanced users.
‘Stupid configuration … WTH?! … That’s it, I’m done with this!’
That’s exactly what some user that’s not that deep into technology and gamepad reconfiguration might think when he or she is forced into something not only time-consuming, but also completely unnecessary.
The new idea is to maintain a list of ‘supported devices’, that is a list of all the axes and buttons mappings for devices that have been tested and should work out-of-the-box. These mappings would then be applied to corresponding devices when they are connected.
In the case of an unsupported device the proper mapping would be reported to the GNOME Bugzilla and the list of supported devices expanded (the first part still needs some planning and work). That would basically mean that no reconfiguration would be either required or available for any gamepad device. The axis calibration would still be possible.
TODO in the second half of the GSOC period
With the Gamepad API support in WebKitGTK+ pretty much complete (by the way, the 1.9.5 release is out and you can test the feature there), the only thing to do is the GNOME Control Center panel implementation. The GNOME Settings Daemon plugin might become redundant in implementing the current idea, but that’s still to see.
The design proposal will be updated and represented to the GNOME designers, hopefully discussed and started being implemented. I’ll try to do the implementation in the tip-of-tree (jhbuild here I come) instead of doing it in the 3.4 branch and the porting it forward.
July 4, 2012
Weeks #5 and #6 were quite fun and productive. Here’s what was happening.
Support for Gamepad API landed
The support for Gamepad API for the Gtk port has landed in WebKit. The feature is currently disabled at compile-time due to the specification still being a work in progress. This might change in the future if API for enabling experimental features at run-time is introduced for WebKitGTK+. Currently there’s no release version (stable or unstable) available that includes the support, but the next unstable release (1.9.5) will have it as well as the next stable release series. Build instructions for the impatient are found on the project’s page in the Wiki (will be updated soon).
GNOME Settings Daemon plugin almost done
The GNOME Settings Daemon plugin is pretty much finished. The code (available on GitHub) is based on the 3.4 branch and will go through a review by my mentor, Carlos, and will eventually be rebased on the master branch. The plugin’s task is to apply any previously saved configurations to the device on its connection. Currently the axes and buttons mappings are applied, but the axes calibration data will be applied as well (support for this will be added parallel with support in the Control Center panel). Currently saving the configuration data is only available through the command line, using the gsettings application’s capabilities. This is extremely hacky approach though, and not a pleasant user experience.
Next two weeks
The next two weeks will be mostly focused on implementing the panel in GNOME Control Center. The code is available on GitHub. Also in this timespan is the mid-term evaluation.
June 19, 2012
Weeks #3 and #4 have flown past, and again more could have been done. Student finals are currently getting in the way of productivity. Studying is no fun when you could be spending the time on a really cool project, and unfortunately I have a few more exams in the next two weeks, meaning I won’t be able to commit much more time to getting things done compared to these last two weeks.
It’s because of that I’ve decided to shuffle the expected timeline a bit, focusing for the next two weeks on getting the Gamepad API support finally landed in WebKit and implement the GNOME Settings Daemon plugin for storing the configured gamepad data. The GNOME System Settings panel will have to wait a bit, but hopefully I’ll still make some progress on its design in the next two weeks.
Review of the last two weeks
Patch for adding Gamepad API support was updated and now requires only some minor details to be polished before it can be landed.
Basic infrastructure implementations for the GNOME Settings Daemon plugin and GNOME System Settings panel have been created. Currently, the implementations are based on the ‘gnome-3-4’ branches – this makes it simple for pretty much anyone with the latest stable GNOME system to try them out. It also aids me as I don’t have to deal with the mess that can result when using JHBuild. This is of course just temporary, the implementations will move onto a 3.6 codebase once there are some decent GNOME 3.5 releases (I’m currently bound to Ubuntu and therefor would wait for some later 12.10 Alpha releases). Again, this is simply just to avoid the JHBuild – both Settings Daemon and System Settings (the Control Center) are large enough projects to require some extraordinary dependencies, making a successful compilation a matter of luck.
June 4, 2012
Yesterday marked the end of the first two weeks of working on the project. A notable progress has been made, but still not as much as I had hoped.
The focus of this two-week period was adding Gamepad API support to WebKitGTK+. The bug entry (at bugs.webkit.org) covering adding the support holds the current work-in-progress patch. The patch already contains a working implementation, it just needs polishing (mostly in the approach this implementation is done infrastructure-wise), with each version going through a thorough review by my mentor, Carlos. Each WIP patch contains the complete implementation, but the bug is still marked as depending on two more bugs – one is enhancing the build rules to include the necessary files while the other is working on properly handling WebIDL types required by the Gamepad API specification. Both bugs are near of being resolved so I hope they won’t hold up landing the feature support once it is complete and reviewed.
To test the current implementation I went on and created a small HTML app that displays the current gamepads connected and button and axis events currently being fired as the device is interacted with. The app is called ‘Gamepads, Gamepads Everywhere’ (meme) and its source code is freely available on GitHub.
Just as a side note, Carlos (the mentor) tested the implementation himself and notified me about an interesting problem he encountered when using the DualShock 3 controller. The DualShock device also has motion sensing capability, sensing motions of the device on 6 axes. Funny enough, the Linux driver reports these axes in the same way the axes for analog sticks and the D-Pad are reported. Some might think the usual ‘It’s not a bug, it’s a feature’, but I’m not, honestly. The specification doesn’t currently cover such axes, and this is causing Chromium to ship an implementation that overrides this driver behavior by using hardcoded mappings for specific devices. I’m planning to acquire the device (possibly with the Xbox controller as well) to test this out.
While working on the Gamepad API support in WebKitGTK+, the design process of the GNOME System Settings panel has fallen behind a bit. I’ve sketched some ideas about how the panel might look like and how the configuration process might work, but all that is still in paper form. The panel proposal is more or less finished and I’ll be seeking for some opinion as well as advice about the panel implementation and design approach from the senior GNOME designers. Because of that the focus for the next two weeks will be to get the design far ahead of the current state and to put the basics of the panel into a public place for the interested to try it out. Along the way the support in WebKitGTK+ will hopefully be complete and perhaps landed in the source repository.
May 6, 2012
I’ve been accepted as a Google Summer of Code 2012 participant to work on the proposed project titled “Support for Gamepad API in WebKitGTK+ and general gamepad configuration options in System Settings” (abstract on google-melange.com). The wiki page for the project will be located here. The project will cover three notable additions to GNOME-related projects:
- Gamepad API specification support for the GTK+ port of the WebKit rendering engine
- Gaming devices panel in the GNOME Control Center for advanced gamepad and joystick configuration
- Plugin in GNOME Settings Daemon to load configuration for previously configured devices when they’re connected
My mentor will be Carlos Garcia Campos.
Looking forward to a productive summer!