Category: Wayland

  • November 3, 2017 - Mike Blumenkrantz

    New Features in Enlightenment 22

    The E22 development cycle has been underway for over a year, and it has included over 1,500 patches to address nearly 200 tickets on our issue tracker. With this has come a number of new features and improvements. Greatly Improved Wayland Support The majority of development for this cycle has gone towards improving Wayland support. This covers, but is not limited to: adding support for xdg-shell v6, pointer constraints, and relative pointer motion protocols. These additions improve XWayland support and increase stability across all components running under Wayland. Continued Improvements to New Gadget Infrastructure As previous posts have indicated, a lot of work is being done in this area. The goal is to create a more robust infrastructure with a simpler and more intuitive EFL-based API, moving away from the legacy “gadcon” interface, which has its own API and currently only functions due to mountains of gadget-specific workarounds that make […]

    Read More
  • October 5, 2017 - Mike Blumenkrantz

    How to Create an EFL Gadget Sandbox

    The new gadget API and infrastructure for Enlightenment continue to undergo heavy development. In addition to improving and extending the base gadget UI, work has recently begun on creating a gadget provider with the new API to provide sandboxing and allow gadgets to be written as regular applications that don’t have or require access to compositor internals. The primary enabler of the new sandboxing system is the efl-wl compositor widget. This allows the compositor to launch applications in isolation, and also provides the ability to add protocol extensions for only that specific instance of the compositor widget. Using these features, it becomes possible to add gadget-specific protocols and utilities on the compositor side that are passed through transparently to the client gadget application. Currently, there is one base protocol in use: the e-gadget protocol, which looks like this:

    The purpose of this is to mimic the gadget API. Applications […]

    Read More
  • Wayland: there have been many blog posts, articles, and news items about the new Linux display protocol. There have been developers working to extend the protocol for new and extremely helpful use cases, but new frontiers continue to be explored: putting a multiseat Wayland compositor into a toolkit widget. Due to Wayland’s philosophy of “build your own compositor,” there is no de-facto implementation of a Wayland display server that is analogous to Xorg for X11. Wayland implementations are written using the libwayland server API, and this is flexible enough to be used even in the case of a widget. Overall, the only noteworthy difference between putting a compositor in a widget and a normal nested compositor is that the output size is set to the size of the widget instead of the size of the window. With this in mind, a compositor widget can be manipulated just like any other […]

    Read More
  • Recent development in Enlightenment’s Wayland compositor has focused on implementing cross-desktop protocols and improving stability. One of the recently handled protocol series has been relative and constrained pointers. Relative pointer motion is a method for providing pointer movement deltas directly to applications. This is useful for a number of cases, though the easiest to imagine might be first person shooter games. In this case, the application receives movement deltas, allowing the player to endlessly scroll the screen in one direction without hitting the boundaries of the screen. Under Enlightenment, this is handled in different ways depending on the output backend being used. For backends using libinput, e.g., DRM, it’s possible to get relative motion deltas directly from the events and then emit them for compositor use. Other backends, however, such as nested Wayland compositors, have no access to libinput’s hardware events. In this case, Enlightenment must manually calculate the deltas […]

    Read More
  • February 2, 2017 - Derek Foreman

    A Curious Wayland Bug

    Enlightenment has a slightly unconventional architecture. For many of its internal dialogues (settings, the file manager, etc.) it uses what we call “internal windows.” These are simply regular toolkit windows that use regular rendering back-ends; in the good ol’ days, this meant a connection to the X server which resulted in a render to a standard X window. In this scenario, the compositor gets the result back the same way as all X client windows, and it composites all internal and external windows together. Under Wayland, things get a bit scarier because now the compositor is the display server. Enlightenment makes a Wayland connection to itself; this gives us all manner of game winning capabilities we never had before. For example, let’s say the internal window wants to sleep and wait for a reply from the compositor (such as a released buffer to render the next frame into). We deadlock and fall down […]

    Read More
  • While there are some developers who are familiar with using Ecore_Evas to create a canvas for applications, we often find that new EFL users face some confusion when first trying to create an application. This article aims to provide a simple example of how to create your first EFL Wayland application. For those not familiar with the Ecore_Evas library, it is a set of functions that make it easy to tie together Ecore’s main loop and input handling to Evas; as such, it’s a natural base for EFL applications. While this combination makes it easy to create the basic aspects all applications need, for normal applications (those that use buttons, checkboxes and layouts) one should consider using Elementary. Ecore_Evas is extremely well suited for applications that are not based on widgets. It has a main loop that delivers events, does basic window handling, and leaves all of the drawing up […]

    Read More
  • November 4, 2016 - Chris Michael

    Ecore_Wl2: An EFL Library for Wayland Applications

    Throughout the years of developing Wayland support for EFL, few EFL libraries have had as much impact on EFL Wayland applications as the Ecore_Wayland library has. This library was one of the first to make it possible to truly run EFL applications in a Wayland environment. As the years progressed, it became apparent that Ecore_Wayland had some shortcomings; this blog post will introduce you to the replacement for Ecore_Wayland, called Ecore_Wl2. Ecore_Wayland’s Shortcomings While testing our first Wayland implementation, it became apparent that the initial implementation of the Ecore_Wayland library had some drawbacks. Publicly exposed structures could not be changed easily without breaking existing applications, and any changes to existing Wayland protocols would require significant changes to our Ecore_Wayland library. It was also discovered that when an EFL Wayland application creates a new window, the backend library also creates an entirely new display and connection to the Wayland server. This […]

    Read More
  • November 3, 2016 - Bryce Harrington

    Compose Key Support in Weston

    I recently added support to Weston for compose sequences via the configured compose key. This is now available in all of the Weston clients. What are “compose sequences”? Let’s say I need to write to someone named Zoë, but I don’t have an “ë” key on my keyboard. I can create the letter using separate key strokes:

    The first key, RAlt (the Alt key on the right side of the keyboard), is the compose key (also called the Multi-key). It signals that a compose sequence is beginning. The next key is double-quote, constructed by holding one of the Shift keys while pressing the single-quote key. Third we type the letter e. This completes the sequence. Or, more correctly, the system finds a match for this sequence in a table of available sequences, and thus considers it finished. The entry in the table indicates that the ‘ë’ symbol should be […]

    Read More
  • October 27, 2016 - Bryce Harrington

    The Basics of Input Methods in Weston

    Wayland provides an optional protocol, zwp_input_method, for defining alternate ways of sending keystrokes and mouse activity to clients. This could be things such as an onscreen keyboard or a popup for building Korean characters. The design of the protocol allows for different kinds of input methods to be made available via modular plugins, allowing them to be coded as discrete client applications, separate from the compositor’s core. The Wayland project maintains a reference compositor named Weston that provides implementations of the various protocols for demonstrative purposes, including two implementations of the zwp_input_method protocol. One input method, weston-keyboard, manages an on-screen keyboard that pops up at the bottom of the screen, similar to on-screen keyboards typically seen on touch-based mobile devices. The other input method, weston-simple-im, enables a compose key functionality. The user can configure which input method to use via their weston.ini file. No more than one input method can […]

    Read More
  • October 26, 2016 - Chris Michael

    Ecore_Drm2: How to Use Atomic Modesetting

    In a previous article, I briefly discussed how the Ecore_Drm2 library came into being. This article will expand on that article and provide a brief introduction to the Atomic Modesetting and Nuclear Pageflip features inside the new Ecore_Drm2 library. What Makes Atomic Modesetting and Nuclear Pageflip so Great? For those that are unaware of what “modesetting” is, you may read more about it here. Atomic Modesetting is a feature that allows for output modes (resolutions, refresh rate, etc) to be tested in advance on a single screen or on multiple outputs. A benefit of this feature is that the given mode may be tested prior to being applied. If the test of a given output mode fails, the screen image doesn’t need to be changed to confirm a given mode works or not, thus reducing screen flickering. Atomic/Nuclear Pageflipping allows for a given scanout framebuffer object and/or one or more hardware […]

    Read More