Biweekly report #4

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.


Biweekly report #3

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.

Biweekly report #2

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.

Shifting priorities

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.

Both repositories are available on GitHub – GNOME Settings Daemon and GNOME System Settings.

Biweekly report #1

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 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.

Hi all,

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 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!