Ok, I found something and implemented in D17980. @zzag can you please test it?

I investigated a little bit on what changed in the new mesa version. It introduces a EGL_MESA_device_software which seems to support what we do with vgem without needing vgem. So it might be that we need to adjust our code to support this new extension in addition to vgem.

In T10245#171947, @bcooksley wrote:

Note that per the investigation by @zzag above, it looks like this is only triggered in scenarios where VGem is present, so it's likely most environments wouldn't see this.

Pulling in @fvogt - our unit tests found a regression in Mesa shipped in Tumbleweed. Could you please trigger an investigation inside openSUSE how it could happen that this was not discovered prior to shipping the update.

So what should we do? We cannot keep the tests failing till Mesa got that fixed - if at all. Can we get another CI base system which is not constantly rolling and introducing issues?

Could you downgrade Mesa please on the CI system?

In D17967#386458, @zzag wrote:

It works on X11, though only after restart.

In D17884#386601, @rooty wrote:

In D17884#384535, @graesslin wrote:

In D17884#384500, @ngraham wrote:

In D17884#384439, @graesslin wrote:

I'd like to try it out, but the effect does not seem to have any effect on my system (a 2-in-1 convertible). Is this a known issue?

You are using X11. The effect only supports Wayland.

Oh ok. We should not even display it on X11 then since it gives the impression of just being broken, which doesn't make a great impression on the user.

It had been like that for several years and nobody cares so far. Let's not make a fuzz about nothing.

Well it used to cause Latte to break a few months ago but they fixed it.
Considering that it doesn't work, I think it should be disabled and unavailable in the menu (or removed entirely).

In T10245#171815, @bcooksley wrote:

When you try to reproduce locally, are you using the docker images we ship at Dockerhub, or a SUSE VM?

Neither, nor. I just use my normal system.

On another note - does KWin's test infrastructure start it's own display services or anything along those lines by any chance? (I wonder if the issue is because the CI Tooling starts Xvfb and then KWin does some additional stuff, and DRM/GBM/Mesa freaks out as a result)

In T10245#171768, @bcooksley wrote:

So it's not liking connecting to our Xvfb instance?

According to the documentation: EGL_NOT_INITIALIZED is generated if display cannot be initialized.

New additional output:
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglDestroyContext

There is one additional env variable which could be set: EGL_LOG_LEVEL=debug

With test coverage I found that we fail in: https://phabricator.kde.org/source/kwin/browse/master/platformsupport/scenes/opengl/abstract_egl_backend.cpp$99

For comparison: on my system the debug output is

It's a possibility

Afaik there are some Mesa env variables which might provide more information. They are documented on mesa's web page

What we have from the tests is:

Fix coding style

In D17898#384616, @zzag wrote:

Off-topic: what should we prefer

auto foo = qobject_cast<Foo*>(bar);

or

auto foo = qobject_cast<Foo *>(bar);

?

In D17884#384500, @ngraham wrote:

In D17884#384439, @graesslin wrote:

I'd like to try it out, but the effect does not seem to have any effect on my system (a 2-in-1 convertible). Is this a known issue?

You are using X11. The effect only supports Wayland.

Oh ok. We should not even display it on X11 then since it gives the impression of just being broken, which doesn't make a great impression on the user.

In D17884#384306, @ngraham wrote:

In principle this might be acceptable, but I'd like to make sure we don't regress anything like we did with the Screen Edge effect when that got turned on by default for all users (not just those with touch hardware): https://bugs.kde.org/show_bug.cgi?id=387775

In D17832#383276, @zzag wrote:

Huh, it looks like we follow neither https://community.kde.org/Policies/KDE4_Library_Documentation_Policy nor https://community.kde.org/Frameworks/Frameworks_Documentation_Policy in KWin and KWayland. E.g. we prefer

Very nice idea with the unit test.

In D17826#382852, @zzag wrote:

Off-topic: regarding the subject line, what's more preferable

Something Wayland related

or

[wayland] Some text

?

In D17659#379912, @volkov wrote:

Is it possible to implement support for foreign windows in KWin QPA plugin?

Use toLower - for X11 windows it worked now

Use signalspy instead of blocking wait for process start

In D17750#381419, @zzag wrote:

Also, it looks like some rules are not working with wayland clients(e.g. Position, Size, etc). Nothing looks suspicious in ~/.config/kwinrulesrc, so that's probably a bug in KWin core.

I still have Qt 5.11, so I'll try to compile the change and give it a try.

Hmm, if it blocks, this won't help. But it gives me another idea: KWin blocks too long and the helper fails to connect to the Wayland socket and terminates.

The code generates warnings:

• Fix typo
• added Wayland and X11

Do you have commit rights?

Move GeEventMemMover into dedicated header

Recently I extended our test to verify dbus properties, see ba0cf19286bcbe731786e33bc96f62830e4ebcfc. Would be cool, if your test could also include these tests.

In D17712#380131, @zzag wrote:

README references this file. Could you please delete that reference?

Also, README has some DCOP stuff as well.

Nice

In D17265#380071, @hein wrote:

unrelated addition of empty line

Hot take: KWin code is nigh-unreadable at times because it tends to be a dense blob devoid of sensible whitespace. Contending with that and then having improvements rejected in review makes KWin extra-despiriting to contribute to.

In D17655#379802, @zzag wrote:

In D17655#379660, @graesslin wrote:

I rather think it's a fallout from switching to dbus.

Not aware of that switch. Could you please provide hash(es) of related commit(s)?

In D17265#380040, @mart wrote:

In D17265#380034, @graesslin wrote:

I have problems following what this change does. All of it has nothing to do with the title. Could you please split this into three commits and reviews for each of the addressed points.

well, the thing the patch does is really one, making setting rows work when done via the dbus protocol, i don't think is really splittable

I have problems following what this change does. All of it has nothing to do with the title. Could you please split this into three commits and reviews for each of the addressed points.

This definately used to work in the past. I rather think it's a fallout from switching to dbus.

In D17659#379007, @apol wrote:

LGTM, I also missed this!

Maybe it would make sense to add a TODO about implementing it for Wayland?