Getting Wayland Input handling ready

I noticed an article on Phoronix today about libinput which made me think I should post a little Wayland update again. So Libinput is developed by Peter Hutterer who is part of the Graphics team here at Red Hat, and our resident input expert. He is developing libinput as part of our work to get Fedora Wayland ready.

That said input is a complex area and if we do end up not having a Wayland option with feature parity with the X.org option in Fedora 21, then not having gotten input sorted in time is the most likely scenario. That said we are still charging ahead with the goal of getting things ready for Fedora 21, but in our last status meeting we did flag input as our biggest risk. Luckily Peter is not alone in his efforts on libinput, there are a healthy amount of community contributions and at Red Hat we have recently had Hans de Goede join Peter on input. So we are doing our utmost to make sure the pieces fall into place.

Our minimum todo list for input that will enable Wayland to be on parity with X for at least 90% of our users is as follows:

  • keyboard works as-is
  • mouse supports left/right-handed button mapping
  • mouse/touchpad middle mouse button emulation
  • touchpad scrolling and tapping
  • touchpad software-emulated buttons work on clickpads
  • touchpad disable-while-typing

But there are of course other items on here too, like Wacom tablet support, which is of interest to a much smaller segment of our users, but still important to get done. We might have to push some of these more niche items onto the F22 timescale.

Also if anyone is wondering about game pads and such, we don’t have any concrete plans around them currently in the context of Wayland, as when we spoke to Valve and the SDL team they currently access game controllers directly through the kernel interfaces, and preferred to keep doing that. So we decided not to try to second guess them on this considering they been doing game development for years and we haven’t :)

Integrating Chrome Applications into your desktop

With the growing popularity of ChromeOS and Chrome applications we have been doing a little research project inside Red Hat to make such applications a bit more integrated into your Fedora desktop. As you might know if you go into the ‘Tools’ menu in Chrome/Chromium there is an option called ‘Create Applications Shortcut’. If you choose that you can turn any web page or chrome application into something easily reached directly from the desktop, and especially with a lot of ChromeApps now working offline this is a quite nice feature. But there are some issues with this setup. First of all it uses the appicon as the application icon, which looks really ugly compared to the other icons on your desktop, secondly it is a little cumbersome to have to go into that menu to set up your application and lastly there is no way of uninstalling it again save from manually deleting the generated .desktop file.

Well our resident Webkit developer, Tomas Popela, has created a Chrome/Chromium extension which you can download from using this link.
To install it you need to go to the extensions page (chrome://extensions/) and enable ‘developer mode’. Once you have done that you can for instance drag and drop the created extension onto the Chrome extension page to install it. Once it is installed it will automatically create a desktop entry for any application you install from the Chrome store, using a nice looking icon. It will also remove the entry again once you uninstall the application.

Some screenshots of this feature in in action.

As you can see the ChromeApp is using its own image in the Shell activity menu and is session managed separately from a 'normal' Chrome window.

As you can see the ChromeApp is using its own image in the Shell activity menu and is session managed separately from a ‘normal’ Chrome window.

angrybird-activity

And you can search and find your Chrome Apps in the GNOME Shell activity overview just like any other application.

Unfortunately the shelf life of this extension is limited as its relying on Chrome supporting npapi, which it will stop doing in April according to current plans. But we are trying to work with Google to see if we can make this standard functionality going forward.

For those interested you can find the source code here on github.

Enjoy!