BY YOUR POWERS COMBINED

Full Wayland support, based on DRM, has landed from Chris “devilhorns” Michael’s private store of E features. He has helpfully added a README.wayland file which provides suitable amounts of warnings and documentation to prepare the average user for a brand new type of crashing. I’ve helpfully inlined the README here:

 

Wayland support in Enlightenment 0.19.0

Caution: Support for running Enlightenment in a Wayland-Only
configuration is considered Highly Experimental !! Use at your own
risk !! We are not responsible if it nukes your files, burns up your cpu,
kills your cat, sells your house, divorces you, or otherwise messes
Anything up !

Use at your own risk !! You have been warned !!

Requirements:
————-

Aside from the normal requirements that Enlightenment needs, there are
a few things to note in order to get Enlightenment to build without
X11 support.

Firstly, you MUST have EFL built with the following options:

–enable-drm
–enable-wayland

This Readme does not address the dependencies needed to enable Wayland
in EFL. If you require any information for that, please see:

https://phab.enlightenment.org/w/wayland/

If you would like support for EGL in Wayland, then also build EFL with:

–enable-egl
–with-opengl=es

The above options can be enabled for EFL without any adverse effects to
existing applications.

Next, you will need to adjust the options that you pass to
Enlightenment during the compile phase.

Please note, we recommend installing This version of Enlightenment into it’s
own separate prefix so that you can still safely fallback to the X11 version.

This can be done by passing:

–prefix=<some_other_install_location>

Now, on to the magic bits ;)

In order for Enlightenment to be compiled without X11, using Wayland
only, you will need to pass a few more options to the configure stage
of Enlightenment:

–enable-wayland-only
–enable-wayland-clients
–enable-wl-drm

Since this is all still a work-in-progress, there are a few
Enlightenment modules that have not been “fixed” to work without X11
yet. Those will need to be disabled:

–disable-shot
–disable-xkbswitch
–disable-conf-randr
–disable-everything (don’t worry, this is just the everything module)

At this stage, you should have EFL properly built, and Enlightenment
properly built. Let’s move on to running it…

Usage:
————-

Hopefully at this stage you have successfully built EFL and
Enlightenment in preparation for a Wayland-only setup. Congratulations
!! Now, let’s get it running…

The following steps assume you are currently at a Virtual Terminal
without anything else running (ie: no other window managers, X11, etc).

In order for Enlightenment to function without X11, we need to setup
the environment. In your current tty, do:

export E_WL_FORCE=drm
export ELM_ENGINE=wayland_shm (or wayland_egl)

This will make sure that Enlightenment renders using DRM, and any
Elementary applications use a Wayland engine.

At this point, you should just be able ‘cd’ to the Enlightenment
prefix where you installed, and issue:

./enlightenment_start

Please Note: It is suggested that you create a separate configuration
profile with only a Minimum of modules loaded. Due to the experimental
(and ongoing) status of Wayland-Only support in Enlightenment, Many
modules May Not Work. Very few have actually been tested yet !!

If you have a separate configuration profile (as suggested) that you
would like to use, you can tell Enlightenment to use that when you
start it:

./enlightenment_start -profile <my_profile>

Notes:
————-

Please Note: There is currently NO support for running X11
applications with this !! So basically, your web browsers won’t work,
don’t expect to be able to run Firefox, Thunderbird, or practically
Any Other X11 application yet. About the only things “known” to work
so far are EFL/Elementary applications.

Bugs:
————-

Yes, there are Lots of them !!
Yes, I am already aware of 99.9% of them.
No, you do not need to start reporting them yet !!

When we feel that the work is reaching a “finalizing” stage, we will
put out a request for actual testers and bug reports !

You are here because you want to play…because you want to
experiment…because you want to be “cool” ;) You are not hear to nag
me with complaints & reports about things I am already well aware of
;) Save yourself some time, and me some stress !! ;)

The Iceman Cometh

Just a quick update today, the EFL 1.9 release freeze has begun. The release is scheduled to happen in 2 weeks, so hopefully Stefan Schmidt returns from his glacier tours before then.

 

Our wiki┬áreceived some hacks last night which should allow reading without being logged in. A big thanks to Carsten “Widget Wrangler” Haitzler for that.

 

Most E19 commits recently have been related to fixing shadow display. Not very exciting. Stay tuned, however: there’s more announcements in the works!

Tiling In The Name Of

I don’t have anything worthwhile of my own to blog about, so I’ll keep the postcount increasing with a quote from the mailing list:

 

From: Tom Hacohen <tom.hacohen@samsung.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] Enlightenment Tiling v2.0
Date: Tue, 04 Feb 2014 16:01:42 +0000

Hey guys,

I have a few updates regarding Tiling2:

Due to popular demand, the module is now external and in it’s own repo.
You can now easily compile it with your existing e19. It’s still e19
only, no e18 support.
Get it from:

https://git.enlightenment.org/devs/tasn/e19_tiling2.git/

A lot has been done since I’ve started it. There’s now a documentation
page on phab that lists what’s there, what’s not and how to use:

https://phab.enlightenment.org/w/emodules/tiling2/

Only thing that I still need to do before considering it “1.0″ is
finding a way to easily promote/demote. I still haven’t found a proper
UX way of doing it. By that I mean, moving items up/down the tiling
tree. If you have an idea, please let me know.


Tom.

Anatomy Of A “Hard” Bug: A Brief, Yet Boring Interlude

I was finally able to reproduce an interesting/annoying issue today, and it turned out that I remembered my intent to blog about it from last time. Here’s the result.

The Problem:

Some windows would fail to render until they either resized or changed their visuals (damages).

Initial Thoughts:

It was difficult to pin down exactly what triggered this issue since I had only heard of it from others without actually experiencing the issue first hand. In general, rendering issues are impossible for me to fix unless I can get them under a gdb scope, so I wasn’t spending too much time trying to figure it out; in most cases, these types of issues are the ones that I fall face first into at some point. As expected, that point was today while working on yet another Yakuake-related issue (fuck you, shaped windows, even though it was unrelated to shapes).

When I did discover a way to reproduce this, I was a bit confused since it only happened in this one particular case (Yakuake menus in Xephyr after restarting E, and only after the menu had already been shown once). Something like a sacrifice to the rendering daemons to get the app to break, I guess? Anyway, I buckled in for a long debugging session which ended up not being very long at all.

Here’s a shot of my workspace upon encountering the problem:

Starting Point:

Immediately after examining my rendering debug output, I spotted the problem, which I’ve cut out into a smaller image:

The compositor was rejecting the render updates! I added this functionality during the rewrite to avoid rendering before objects got sized initially, so it was obvious to me what was occurring in the pipeline at this point:

  1. Client appears
  2. Client resizes
  3. Client runs its render update
  4. Client attempts to trigger rendering on itself
  5. Client fails to trigger rendering on itself
  6. Client shows
  7. Idle

No further render updates were pending, so the rendering never occurred even though all the information for the render was available. As proof, here’s what would happen when I moved the cursor over the area occupied by the non-rendered window:

Tada, the menu appears because it received damages and triggered more render updates:

Lots of render updates, in fact; there may be some overdraw here which can be eliminated at some point.

The STUNNING Conclusion:

After checking on a few things internally, I confirmed that events were occurring as I previously hypothesized, which meant that I just had to add in a flag to track when a client was ready for rendering and then add a render update when that client was shown if the flag was set. The entire commit was ~10 lines of changed code, and now things render as expected.

Afterthoughts:

This ended up being a relatively easy “hard” bug since render debugging is very informative, but it may give some insight as to how the process works.

Buffering

As anyone who is subscribed to the development mailing list already may have seen, today is almost a noteworthy day in E world. Why’s that?

 

E19 is going into feature freeze at the end of next month. Read more about it on the mailing list if you aren’t lazy.

 

FAQ (let’s be honest, there’s only one)

  • Q: When will E19 be released?
  • A:┬áThere is currently no set date or estimated date for E19. My only goal with regard to time is to release before July 2023, though I may be forced to delay until September 2026 depending on celestial alignments.

Resistance

I was going to say something clever, but then I added another feature after writing the title and forgot what I was going to say. Suffice to say, nothing of value was lost. Let’s git log it up:

  • Iconify animations are now even more themeable thanks to some work by Carsten “Canvas Commander” Haitzler
  • Pager popups once again delete themselves after the configured delay
  • Compositor effect signals are now extensible
  • Some crashes may or may not have been added or removed
  • Focus no longer resets to iconic clients (except on startup because I haven’t fixed that yet)
  • Menu placement improved thanks to Daniel “I like Quake” Kolesa
  • Pager16 popups now have shadows
  • Internal canvas objects with compositor hooks can now be matched for themes like windows and popups
  • Compositor theme matching is now more accurate
  • Compositor theme matching dialog no longer crashes after an edit
  • X window stacking is now more accurate
  • First draws of X windows are now more complete
  • Internal windows now show their compositor visibility animations
  • New option for active hint policy to only activate windows on a visible desktop

 

I also spent some time on the second category of the config option docs today. Unfortunately, this page cannot be edited by mere mortals, and it truncates itself when people try; I apparently can’t even revert to a previous working version after someone broke it yesterday, so it’ll have to wait for ┬ásomeone with more internet powers to fix it with the updates.

 

Tomorrow is going to be an announcement day, so stay tuned!