For the past few days, I’ve been banging my head against a wall trying to sort out how to make the Enlightenment restart experience better when running under Direct Rendering. There are a lot of issues with this, a lot of mountains to climb, and it’s caused much brain pain trying to sort it out so I’ve decided to step back and think on it a bit more.
While taking a step back, I decided to implement a few missing features for the Direct Rendering backend. One of those features is Screen Rotation support. In order to support screen rotation, we needed support for Hardware Planes inside Ecore_Drm. While this is not overly difficult to expose (set a bit in the driver via a libdrm function call), utilizing the hardware planes is a bit more involved. The purpose of utilizing these hardware planes would be to put cursor images inside the hardware Cursor plane, video surfaces in the Overlay plane, etc. This would save on redraws and potentially speed up rendering.
So in the process of implementing Screen Rotation, I’ve started some initial work on exposing these hardware planes (via Ecore_Drm library) for use in EFL rendering. Now that the hardware planes are available, I am able to start down the path of getting proper objects onto the proper layer. This will take some time, but I am hoping that all this will be available for the 1.18 release of EFL. In the meantime, I leave you with a Screen Rotation shot (rotated 180 degrees)
Those who are familiar with early Enlightenment development will likely remember the White Box Of Death that would appear in the event of a segfault or other major issue. Well, I’ve decided to bring back the nostalgia of the gold years and implement this feature when using Enlightenment Wayland. Now if (for some strange reason) you get a segfault or other major issue when running Enlightenment via Wayland, you will get a nice WBOD displayed 🙂 This will give you the option to gdb attach to the process, the option to restart your session, or the option to logout. Hopefully this feature finds some usuage somewhere down the line…
Despite my lack of posts here, please be aware that I’ve not been resting on my laurels. In fact, I’ve actually been “nesting” 😉 As you can see from the below screenshots, Nested Compositors are starting to work with the newly created Ecore_Wl2 library. We can also create Nested Compositors while running inside Weston.
It’s been a while since my last post and it is long overdue.
Some of you may have noticed a lot of changes in the Ecore_Drm library lately. These changes are all part of a master plan to get RandR support working for Enlightenment so that users can configure their monitors when running via drm in a Wayland-Only environment.
So, what has been going on ?? Well, I’ve been knee deep in DRM & RandR hell basically 🙂 Hell you ask ? Why yes ! For anyone who has never worked with the libdrm API, it is not a direct one-to-one translation when trying to implement RandR support and the libdrm API has about Zero documentation. This makes finding the proper libdrm functions to perform a RandR function Very difficult.
As an example, there is no libdrm API function for rotation support on a given output/crtc. Rotation is basically Not supported on a per-output/per-crtc basis. The only way to actually rotate something using libdrm is via rotating the hardware Plane. This took ages to find and figure out mostly due to the extreme lack of documentation.
You may be asking “Ok, so does this mean I can use the Enlightenment RandR dialog to configure my screens now?”. The short answer is: partially. Using the dialog, there is support now for listing the available outputs, their available modes, for enabling/disabling a given output, and for changing the mode of an output. It should be noted tho that there are some “gotchas” involved with this. Due to the nature of the way Enlightenment creates a giant Ecore_Evas to spread across both outputs, any resolution that you set on One output MUST be set on any other outputs also. This means that if you configure One output to be 1600×900, then all other outputs MUST be set at that same resolution. This is “hopefully” only a temporary limitation as more things are flushed out in the backend Ecore_Drm code. It should also be noted that Rotation is not possible just yet. Having only recently figured out that rotation only works with Planes in libdrm, I have yet to implement Plane support in Ecore_Drm. This is currently “in progress” and I am hoping to land it before I leave for vacation.
There is actually some good news to report tho 🙂 For those who have tested/tried running Enlightenment Wayland-Only (via drm), you will be happy to hear that this week I have GREATLY improved the rendering speed of the Evas Drm engine. This means that when running Enlightenment Wayland-Only, you will find that the rendering and interaction with dialogs is MUCH faster & smoother now. This provides a much more pleasant experience when testing things.
Well, since my last post there has been a LOT of changes going on in the Ecore_Drm library. We now have the ability to use the drm card without need for systemd (haters rejoice). I’ve also ported the input code inside our Ecore_Drm library to make use of libinput now. This greatly simplifies the input code and makes things much easier. I’ve also added support for Touchscreens now.
Also getting some attention was the eldbus library. I’ve added some new API functions which were necessary to work with the new non-systemd drm code, and the new libinput code.
In other news, there was a hotfix which was backported to the 1.12.2 branch which fixed an issue with rendering Elementary applications in a wayland compositor if the ELM_PROFILE was set to mobile.
Back again with some more news. Recently we have been working hard toward getting Enlightenment to run as a Wayland-only Desktop Environment. I am happy to report that those efforts are starting to bear some real fruit ! 🙂 Toward that end, we have been working hard on getting the Ecore_Drm library completed and have added many new additions to the library lately. We now have output hotplugging support, along with a new Evas GL engine which can render using OpenGL ES on DRM (Direct Rendering Manager). In other news, the reworked wayland compositor inside Enlightenment has seen many improvements over the past few weeks (although these improvements are not upstreamed yet). The issues with resizing and closing dialogs has now been sorted out, along with other various show-stopper issues. Look for this code to land soon, which will mean we should be able to have a working (as in actually usable) wayland-only desktop shortly.
Spent the better part of the day trying to fix a problem due to an Arch upgrade 😦 After that was fixed & cleaned up, I was in a house cleaning mood so I decided to remove some compiler warnings in Enlightenment that were driving me crazy. One thing I cannot stand is compiling software and having to see a million warning messages spitting out, so I took a broom to the Enlightenment codebase and removed a bunch of warnings about missing initializers for Eldbus Messages & Signals. All said and done, things are running well now and compiler output is much cleaner…so I’m happy 🙂