LWN.net Weekly Edition for October 30, 2014

A Wayland full-screen shell

There are a number of features that users are used to in X that are not simple to handle in Wayland, such as screen sharing and recording. Jason Ekstrand gave a talk at the 2014 X.Org Developers Conference on some ideas he has to make those easier. Instead of teaching each and every Wayland compositor to handle various protocols for screen sharing and other features, he proposed using compositor nesting to hand the problem off to a dedicated process.

Ekstrand introduced himself as a PhD student in mathematics at Iowa State University. He got involved in the Wayland project in early 2013. Since June, he has also been working for Intel on the i965 graphics driver.

The Wayland model is quite different from that of X, he said. Instead of an X server, Wayland has compositors that serve many of the same functions. Clients talk to a Wayland compositor, which in turn talks to the hardware.

The X server handled a lot of different functions that now fall to Wayland compositors to implement. The solution to that has been libraries and subsystems to deal with different portions of the compositor's job: KMS for mode setting, DRM for buffer handling, OpenGL for accelerated graphics, libinput for input handling, and so on. Some of these are starting to be incorporated into the X server, which is nice, he said, because it means that Wayland compositors and X servers can share code.

So, he asked, why not just use X? It is a fine display server, so long as you are willing to let it handle input and compositing. Most modern desktops (e.g. GNOME and KDE) want to handle input and compositing themselves, so the X model doesn't work so well.

In addition, X has a common global namespace for everything. Any client can resize and reposition any window, get the contents of any window, and send input to any window. Window managers are just X clients that manage other clients' windows.

In Wayland, things are different. Every client has its own namespace and gets input directly from the compositor. In general, clients are not aware of the existence of other clients, and the contents of surfaces are only shared between a client and the compositor. All of that has many security benefits, Ekstrand said.

But there are features X provides that Wayland doesn't, including a common, user-space I/O layer. All that needs to be done is to implement a device-dependent X (DDX) driver for the X.Org server (or implement a full X server) and clients will just run on it. On the other hand, DRM, KMS, and OpenGL, which are used by Wayland, are focused on getting images to hardware—but some output mechanisms are not hardware (e.g. screen sharing or remote sessions).

Virtual network computing (VNC) and remote desktop protocol (RDP) sessions are often implemented using an X.Org DDX. That server runs in user space and does not require root privileges. Clients and window managers talk to that server like any other X server; there is no graphics acceleration, but otherwise it all works the same. FreeRDP and x11vnc have taken this approach, for example.

But doing that poses some problems for Wayland. Its I/O abstractions assume hardware. KMS and DRM require a kernel driver, for example. There are external libraries to implement protocols like VNC/RDP, but they require every compositor to add support for each library, which leads to a combinatorial explosion of compositors and protocols. Weston currently has an RDP backend that works pretty well, Ekstrand said, but it doesn't make sense to add a backend for every protocol.

Another use case that is problematic for Wayland is screen recording and sharing. On X, these are implemented as clients that grab the frame buffer and store it or send it. Input is faked as needed. That raises "huge security concerns", he said. Sensitive information can be grabbed, other clients can be controlled, and malicious input can be sent to clients.

In Wayland, though, clients are isolated, so any screen capturing must be done by the compositor. The output could be passed to a trusted client or handled by the compositor itself. There is some support for that in Weston already, via the weston-screenshooter client that will write to a PNG file. There is also the ability to record the screen, outputting H.264. All of that is both Weston and format specific, so if you wanted to support those features for GNOME or KDE, they would need to be implemented in their compositors.

Some have suggested writing a "trusted" protocol that is only accessible to trusted clients. It would be able to capture the screen and provide input to other clients. That would mean that compositors only need to implement that one protocol, and that multiple different sharing/recording clients can be written to use it, but it turns out that is a lot of protocol, Ekstrand said.

So his suggestion is to use what we have already: the Wayland protocol. In this model, a VNC or RDP server would implement a Wayland compositor. It would be launched as a trusted compositor by the main compositor. The main compositor would send its screen contents to the trusted compositor as a surface, which would then get sent across the network. Likewise, input would come from the network to the trusted compositor which would pass it to the main compositor. That leaves the main compositor in control of who gets screen contents and input. And, for the most part, that protocol is already written.

Ekstrand has proposed the wl_fullscreen_shell as the way forward to solve these problems (he also described the motivations and ideas for it in an earlier message). It would add two requests: present_surface, which would provide the trusted compositor with a surface (and possible scaling mode) to output, and present_surface_for_mode, which is similar, but would allow the main compositor to do some rudimentary mode setting for the output. Once that surface is established, the standard Wayland protocol is used to do input and output.

Originally, he wanted to demonstrate the full-screen shell, but he ran into some technical problems on the laptop he was using. Instead he described what he has working: a modified Weston compositor that, when ctrl-alt-s is pressed, will spawn a second Weston compositor with an RDP backend as a trusted compositor. One can then connect to that RDP server from the network to view the screen and send input to it. The "demo" is also a good example of the multi-seat capabilities of Wayland, since there are separate cursors and input devices (e.g., mouse and keyboard) for the main system and those connected over RDP.

Screen recording and sharing are "just the beginning", he said. For one thing, the ideas behind the full-screen shell will make it easier to write compositors. Those who want a simple compositor can write it as a Wayland client and let Weston handle the input and output. It could also be used as the basis of a user-space Miracast (for wireless screen-casting).

There is some discussion of Ekstrand's patches going on in the wayland-devel mailing list, but there don't seem to be any major objections. Those looking for more information can check out the slides [PDF] and video [WebM] from the talk.

[ I would like to thank the X.Org Foundation for travel assistance to Bordeaux for XDC. ]

Comments (8 posted)

A look at Emacs 24.4

Emacs 24.4 is the newest release of the venerable editor, released on October 20. Despite being a point release and not a major version-number bump, there are quite a few significant changes rolled into the update. Among them are user-interface improvements, security features, several enhancements to various editing modes, and the addition of a new built-in web browser. Even if the thought of browsing the web from entirely within Emacs does not sound revolutionary, there appears to be something new for just about every Emacs user.

Editing

For general text-editing purposes, arguably the most significant change in the new release is the default activation of "electric" indentation. This is an auto-indentation mode that indents or re-indents lines whenever certain trigger characters are types—namely, Enter, Return, and closing parentheses. It was first added in Emacs 24.1; the new release simply makes it the default behavior. This is a somewhat controversial change, mainly because some third-party language modes (such as YAML and Ruby modes) require some additional tweaks to produce proper results.

Another wide-ranging (albeit small) change is the addition of superword-mode, which alters how Emacs treats certain characters within words. In previous releases, Emacs would treat hyphens, underscores, and similar characters as word breaks, which is not how they should be treated when editing code. superword-mode corrects this, so that word-by-word navigation and commands function correctly. Also in the code-editing vein is an improved show-paren-mode, the function responsible for highlighting paired delimiters. In previous releases, only simple matches like [ to ] and ( to ) were supported. The new update also matches programming language control constructs like do to end.

Users that work with bidirectional text documents (that is, mixing left-to-right with right-to-left text in one file) may also appreciate the new visual-order-cursor-movement setting. When set to a non-nil value, this option makes the cursor always move in the "arrow" direction when navigating with the keyboard, regardless of which direction the text is oriented. So hitting the left arrow moves the cursor to the left, whether Latin, Arabic, Hebrew, or other text happens to be beneath it. There is also a new rectangle-mark-mode, with which the user can highlight a rectangular block of text (to cut or copy), rather than making only line-oriented selections. Users should be forewarned, however, that while basic kill/yank functionality supports rectangle selection, various other commands may not understand it yet.

Interfaces

Quite a few improvements in 24.4 affect the various Emacs user interfaces, rather than editing itself. For example, while the GUI interface has supported menus for many years, 24.4 is the first to add menu support to the text-mode interface as well. When using Emacs in a terminal, all of the same menus are now available; on mouse-less systems one can open the first menu by hitting F10.

GUI users also gain several enhancements, including support for multiple monitors (in particular, the ability to query the sizes and properties of multiple monitors, which is likely to affect extension developers most immediately), improved full-screen support, and support for saving and restoring window and frame layout between sessions. "Frames," in Emacs lingo, are what most operating systems call windows, it should be noted, but whatever one calls them, Emacs can now save and restore their configuration. Full-screen support can be activated with F11, and a frame can be maximized with Meta-F10 (or, in traditional Emacs parlance, M-F10). Although X-based systems have behaved correctly for quite some time, the new release also fixes several outstanding bugs related to pixel-based window sizing and resizing; users can now rest assured that their frames and windows will be the proper dimensions on any OS.

A new prettify-symbols-mode has been added that will substitute a text representation of a character name with the proper Unicode character. Being a Lisp-centric project, of course, Emacs's canonical example of this is replacing the string lambda with the Greek letter λ, but there are certainly other possibilities. Another potentially controversial change is that cursors will now stop blinking after 10 blinks if there is no activity. As Mickey Petersen quipped in his blog post about the 24.4 release, "I wonder how many surveys, usability studies, committee meetings and research went into deciding it must be ten blinks and not nine or eleven." The number is, however, configurable with the blink-cursor-blinks variable.

Finally, there is also a new remember-notes command in this release. It creates a buffer akin to the "scratch" buffer (an Emacs mainstay), but which is saved when exiting the editor. Since many people, rightly or wrongly, use "scratch" to save notes and snippets of text, apparently the development team determined that a significant number of them were frustrated by the fact that "scratch" is destroyed on exit.

Security

A handful of security-related improvements were also added in this release. Emacs now supports checking digital signatures on Emacs Lisp packages. This ties in to another recent feature: the built-in package manager, which connects to the official Emacs Lisp Package Archive (ELPA) run by the GNU project. While ELPA and the other large package archive sites may not add signatures for many packages in any kind of short time frame, it is certainly a welcome feature for anyone who occasionally installs a third-party package from a somewhat less-familiar source.

Emacs can also be compiled with support for access control lists (ACLs), both on local and remote files. This feature requires operating-system support; on Linux this means the presence of libacl. Finally, there is a new option available to require SSL/TLS certificate verification; if GnuTLS determines that a certificate is invalid, the gnutls-verify-error setting will cause Emacs to reject the SSL/TLS certificate and stop the connection. It is important to note, though, that gnutls-verify-error is currently set to nil by default—but that default will likely change in some future release.

...And the rest

With a project as large and as modular as Emacs, there are clearly too many changes to describe adequately in anything close to readable brevity. But among the many other updates found in 24.4, perhaps the most oft-discussed is the new web browser module, Emacs Web Wowser or eww.

There have been several other browser modules in the past, but the previous one (W3) had fallen out of active development. Eww is implemented almost entirely in Emacs Lisp (though it requires the presence of libxml2), and supports HTML5 and CSS. The documentation is lacking, so it is not clear what portions of HTML and CSS are supported at present (and JavaScript appears to be off the table entirely), but it will certainly be a project worth watching.

Among the other Emacs modes and packages, some additional noteworthy developments include support for file notifications and improvements to image-mode. On Linux, the file-notification support requires Emacs to be compiled with inotify.c; it lets Emacs report changes to files: deletions, renames, and modifications. image-mode gains new commands for stepping through the files in a directory, stepping through individual frames of an animated image, and new magnification features like fit-to-frame.

The Emacs 24.4 release is available as in source-code bundles from GNU mirrors, but packages for a variety of Linux distributions have already started to appear.

Comments (28 posted)

The Google Summer of Code Reunion

Google Summer of Code (GSoC) 2014 is over and the 2015 edition has been announced. A record number of 1307 students from 73 countries participated in 2014, working on 190 open-source projects. One of the traditions of Google Summer of Code is to host a Mentor Summit in the fall, which is an unconference that two mentors from each organization participating in GSoC can attend.

In celebration of the 10th year of Google Summer of Code, Google held a GSoC Reunion. Breaking tradition with the Mentor Summit, the GSoC Reunion was open not just to mentors, but also to students. Google allowed each of the 190 projects that participated in this year's GSoC to send two delegates. Additionally, Google held a lottery for additional places, bringing the total attendance to around 500. I was fortunate to attend as one of the representatives of Software Freedom Conservancy, which handles GSoC payments for multiple projects and also worked with a GSoC student of its own in 2014. We will look at some highlights from the dinner reception and cover two of the unconference sessions.

Musings on the history of GSoC and some surprise speakers

Friday started with a visit to California's Great America, which is an amusement park with roller coasters and other attractions. The park was only open to GSoC Reunion attendees, which meant that people got to enjoy the rides without any queues. In the evening, Google hosted a dinner reception at The Tech Museum of Innovation in San Jose. The dinner reception provided an interesting exhibition, food, and some surprise speakers.

The first speaker was hardly a surprise. Chris DiBona, director of open source at Google, talked about the history and significance of Google Summer of Code. He recounted a meeting with Google co-founder Larry Page, who lamented that computer science students spend the academic year learning about computers but often regress with their learning during the summer holidays because they cannot focus on coding. Page gave DiBona a simple mission: fix this problem.

DiBona thought it would be a great idea to get students to work on open source over the summer and asked several projects if they would be able to do anything with some students. The response was generally positive, as long as projects were not forced to integrate the code from a student if it didn't meet the project's criteria for inclusion, and this this is how Google Summer of Code was born. Thanking everyone for their work and contributions, DiBona stated that "we're all here for a reason"—people were not selected by chance, but because of the work they have done.

After two more speakers from Google, two GSoC mentors were introduced. They turned out to be Linus Torvalds and Dirk Hohndel. While Torvalds may be known for popular projects like Git and the Linux kernel, they were invited to the GSoC Reunion as mentors representing Subsurface, a piece of software for planning and logging dives. Torvalds was quick to point out that he was, in fact, not a GSoC mentor because he would only scare students away, but Hohndel confirmed his own role as mentor and organization administrator for Subsurface.

In a Q&A-style session, Torvalds was asked to give his insights on what it takes to become a good programmer. One of the key characteristics, according to Torvalds, is perseverance. Debugging is a good example because you have to drill down until you get to the bottom of the problem and understand what's going on.

Another key requirement is taste. Torvalds said that he couldn't describe what he means by taste, but that it's something he knows when he sees it. Taste allows you to make the right decisions. The good taste shown by certain developers enables Torvalds to trust them completely because he knows that they will do the right thing. It allowed him to hand the maintainership of Git over to Junio Hamano and to accept pull requests from certain Linux developers without looking at the code.

Torvalds argued that experience makes you faster, but is often overrated. He can frequently judge patches in seconds these days because of experience, but experience doesn't replace taste. Unfortunately, Torvalds didn't know how people can develop taste.

Hohndel also chimed in with his insights, recommending that students "think small". Instead of planning to design a completely new system, they should focus on their immediate needs—fixing bugs in software they use is usually how people get started.

Paid and unpaid contributors

The first unconference session I attended was on paid and unpaid FLOSS contributors. This session was suggested by Thorsten Behrens, chairman of the board of The Document Foundation. He observed that LibreOffice has a lot of volunteers as well as a lot of paid developers, and that the Document Foundation recently published a tender for paid development work.

While many developers are paid to work on open-source software these days, paying people as well as mixing volunteers and paid developers in a project can be delicate issues. There was a general feeling in the session that projects comprising both paid and unpaid contributors treat all contributors equally. The only exception are projects sponsored by a single company in which priority is often given to developers from that company, for example when it comes to reviewing patches.

Robert Kaye from the MusicBrainz project explained that its development process is driven by the community through a bug tracker. While companies cannot tell the project what to do, they can participate in the development process—just like anyone else. The MetaBrainz Foundation (which sponsors MusicBrainz) has a steady flow of income from companies such as Google and Last.fm that use MusicBrainz data; it uses that money to employ people. A key here is transparency, something that was echoed by others in the room. Perl, for example, has a grant process that allows developers to apply for funding. What works well is that the process of applying for grants is well described and open to anyone.

Someone in the audience suggested that paying people who have been long-term volunteers works well. However, when money goes to newcomers, it can lead to distortions because these people may come in with a different motivation compared to people who started out as unpaid volunteers. Someone noted that only paying people who have a history of unpaid contributions makes it hard for certain groups to get started. She acknowledged that many people start doing open source as their second shift (meaning work done at home in their spare time), but creating more opportunities to work on open source on the first shift (i.e. as paid work) can have a positive impact on diversity.

When a project wants to pay developers, the big questions are how much and what for. The salary question can be complex since many projects are global. If you have a fixed budget of $60K, this salary figure means something completely different to someone living in San Francisco than it does to someone in a low-cost location. In answer to the question of what to pay for, someone from FreeBSD suggested that paying for activities that are extremely complex and hard to perform in someone's spare time works well, such as legacy build systems and kernel video drivers. These tasks are "almost impossible if people don't get paid". Similarly, paying people for tasks considered boring, such as code review or documentation, has worked well.

There are some issues with paying people, though. One is that other people often avoid a particular area when they see that someone is getting paid to work on it, even though the activity could benefit from more contributors. There's also the phenomenon of "cookie licking"—marking a particular area as yours and getting offended when other people want to work on it.

There was a general agreement in the room that paying students through GSoC works well, although some noted that there can be resentment when the work of a student who gets paid to work on a project doesn't meet the project's quality standard—why is the student paid for something an existing volunteer could have done better? However, this is generally not a big deal since it's not the organization's money that is being spent on the student.

As open source is getting increasingly popular, the majority of projects will consist of both unpaid and paid contributors. Projects have to ensure that all participants can co-exist without resentment, particularly if the project itself starts paying certain developers. Projects are increasingly gaining experience with questions related to paying developers and we can all benefit from sharing those experiences.

Making your project more approachable to new contributors

Another session I attended was on making projects more approachable to new contributors. This session was led by Angela Byron, a former GSoC student, and Chandan Singh, a GSoC 2014 student working on Drupal. Together, they presented several blockers that contributors often face. Byron explained that she installed Debian many years ago, but that she never considered contributing to the project at that time because she thought that she wasn't skilled enough.

When GSoC was launched, Byron applied as a student, thinking that you're not expected to already know how everything works as a student. This worked out really well and Byron is now a Drupal core committer. Another assumption that stops potential contributions is that you have to be a developer in order to contribute. There are many other ways to make significant contributions and projects should offer tasks that require diverse skill sets.

Singh observed that newcomers are often overwhelmed by the scale of a project and don't know where to start. When you find a problem, it's hard to know where to begin if you want to fix the problem. A representative from Eclipse in the audience noted that people often don't even know that they can contribute.

A good way to make things easier for new contributors is to post clear signs on how to get started. A LibreOffice developer mentioned LibreOffice Easy Hacks, which highlights bugs and tasks that are easy to tackle, as a good initiative that made it easier to get started. Other projects have similar initiatives, such as Drupal's Novice tags; a student in the audience confirmed that highlighting easy tasks "really helps".

There was general agreement that it's important to make it as easy as possible to get started. Someone suggested providing a complete environment, such as a VM image, that includes the tools required to hack on a project. Byron mentioned the Drupal Ladder, which breaks down the tasks required to get started into simple steps, such as installing Git, getting familiar with the issue tracker, and eventually submitting patches. Each step is accompanied by a tutorial, which makes it easy to take the step and advance on the ladder. It's important to think about the steps required to become proficient at something; in the process you should try to eliminate as many steps as possible. After all, "nobody wants a 27-step ladder", Byron said.

Good mentoring can make a real difference to newcomers. Drupal has taken mentoring to its heart, according to Byron. The project offers core mentoring hour—twice a week, mentors are available on IRC to help new contributors get started. Mentors curate lists of issues that newcomers can work on and guide them through the steps required. A representative from Ceph noted that they host quarterly online developer meetings through video chat, which allow new contributors to interact with developers. He observed that the "human element is huge".

Overall, many good ideas were discussed in this session and there was an understanding that projects can drive many activities to make it easier to get started.

Conclusions

I found the GSoC Reunion to be quite a stimulating event. What's unique about the event is the diverse nature of attendees. I cannot think of another event that brings contributors from so many different projects together. Open-source communities are different, but at the end of the day we often face similar issues. We can all benefit from sharing experiences—positive as well as negative—with each other and the Google Summer of Code gathering is an excellent venue for this.

Comments (none posted)