Hmm... I would say we need to figure out the intention behind force temporarily and whether this concept can be mapped to Wayland.

Could you please add a test case

Could you please add this to the test case. IIRC we have already a few tests for force temporary.

In D18453#398379, @davidedmundson wrote:

Could this be our firefox issue?

That would be nice, but I'm afraid not. It's nothing in the rendering code, we can see they just stop sending us frames.

Keep in mind that the Nvidia driver triggered endless loops in checkglerror.

Could this be our firefox issue?

Cool stuff! I assume you want to push together with a patch fixing this?

Do the tests pass without the change?

That's an evil twist. Idea: make the windows panels with windows go below?

The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.

Stays on top is wrong. The window needs to be in the dock layer, not in the above layer. With keep above other keep above windows can still go on top of it.

Stupid question: the popups are transient to the panel? If yes we can fix in layer. A panel transient should be in panel layer and thus above the windows without any client side tricks.

Suggestion: we take this for stable branches and switch to doing it ourselves in master.

I'm not totally happy with calling it popup behavior. In X speak this is not a popup.

For done code this warning is pointless and negative. I invite you to work with a code base like KWin where it is more important to have a working git blame than protection for theoretical problems. Nobody will be able to guarantee that a 500+ change to add override won't break. Human errors happen, nobody will be able to review something like that. Addressing this warning by adding override all over our legacy code base has a serious risk.

This causes in KWin 500+ new warnings. Do you really think it's a good idea to spam all of KDE with new compiler warnings. KDE has an old code base. We cannot enable warnings for the way you developed C++ for 20 years.

In D18406#396909, @zzag wrote:

I don't see any warnings. Could you please provide the warning message?

I guess the idea of the old code was to get a possibility to see which one fails to unload.

Given that it compiles, it looks fine to me

Maybe we shouldn't rely on Qt doing that for us, but just do it ourselves.

This does not take into account: A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.

Can't we simplify by connecting once to rowsChanged signal?

make findWindow(QWindow*) also work for X11 by looking through Unmanaged

In D18228#393160, @zzag wrote:

Generally speaking, it would be great to have protocol-agnostic internal clients, but tbh I haven't thought too much about this.

• Add EffectsHandler::findWindow(QWindow*) -> EffectWindow*
• Fix coding style

I wouldn't start porting away from foreach before Qt 6 has it removed. Quite simply I don't think it will be removed. foreach and extended for behave differently as the qAsConst things show. Using extended for on Qt container is extremely expensive (let's ignore the fact that we know that stuff, think of the average developer with hardly any Qt background).

In D17884#389993, @davidedmundson wrote:

I used this for a week, and tried to poke my laptop screen more.

It didn't bother me, but I can't say I really gained anything as my finger was always in the way of the small circle.

In D18198#391797, @davidedmundson wrote:

That's due to change in Qt6.

Oh, I wasn't aware of that. Where do you have that information from? I'd love to read up about it.

For the Udev case I would prefer if FreeBSD would provide a shim udev KWin can link against and which provides the hack deviceFromSyspath("/dev/dri/card0");

Looks good to me

Well I always kept such old code as it was. I faced this problem a lot during the port to Wayland and introducing the AbstractClient. In the end I decided to not change anything that's in Client or Toplevel, but AbstractClient introduces the more "modern" approach.

Personal opinion: this is X11, let's not risk breaking it.

Maybe also add the AA_UseHighDpiPixmaps to the integration test app?

Actually if we want to improve this I would go for:

• std::vector
• reserve
• emplace_back

In D18157#391138, @romangg wrote:

In D18157#390707, @graesslin wrote:

For safety I suggest to push after 5.15 has been branched off. That gives us more time to test that nobody still has that key around. Though it's unlikely.

Thanks for the feedback. If you also think this hack can be removed, then I'm not so worried about removing used functionality.

For safety I suggest to push after 5.15 has been branched off. That gives us more time to test that nobody still has that key around. Though it's unlikely.

@mart this change broke a unit test: https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.11/288/testReport/projectroot/autotests/kwin_testScreenEdges/

Fix condig style (uups) and add comment

In D17659#389728, @volkov wrote:

I mean this plugin: https://cgit.kde.org/kwin.git/tree/plugins/qpa

I'm the author of this interface and I consider it nowadays as a mistake to have added it. If I would restart I would do the whole thing differently: input events need to be injected through a kernel module in a dedicated input device. It would need a user space component which processes can talk to and that would need to be secured though e.g. polkit. Thus we could properly authenticate. This protocol does not support it and KWin does not even try to authenticate. Overall from security perspective this is a mess.

I don't want to have key press/release in it. It has a reason that I didn't add key press/release from the start. The problem is the mismatch of key events and keysyms. Especially the kdeconnect use case for which this interface was developed has this problem. Android composes text, not key codes. Thus it would not be possible to inject key events.

If there are no objections I would push it, so that we have it in the upcoming beta.

In D17900#389925, @mart wrote:

+1 for the idea,
shouldn't dynamic rather be default? any drawback?

I'm not sure whether KWin should carry this patch. No developer will be able to test it or ensure it works. It makes changes more difficult, it basically turns this into a don't touch me area.

In D17985#387512, @romangg wrote:

But all Wayland-native clients crash on disconnect of the display including Plasmashell.

Hmmm, difficult. I think it would be wrong to delete the Deleted just because a desktop is destroyed. I don't see a problem with the deleted ending up on all desktops. No effect would start an animation and those animating the window will continue to do so.

@bcooksley I think we can remove vgem now from the CI system

Thanks everyone for the help

The spec file: https://build.opensuse.org/package/view_file/X11:XOrg/Mesa/Mesa.spec?expand=1 - no surfacless

Some further hint: https://build.opensuse.org/public/build/X11:XOrg/openSUSE_Tumbleweed/x86_64/Mesa/_log shows --with-platforms=x11,drm,wayland while on https://sources.debian.org/src/mesa/18.2.8-2/debian/rules/ and https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa we see additional surfaceless enabled. This explains why the change for sufaceless did not work. Looks like an openSUSE packaging issue to me.

I don't think that removing vgem will help. The next code path is then using default platform and that will certainly fail. What I would like to see is strace of a failing test.

More results from playing with strace and reading mesa code: @bcooksley please add LIBGL_ALWAYS_SOFTWARE=true to the environment variables for running the test. With that env variable set I got the test to use the kms_swrast device instead of the intel device

I played a little bit with strace to see what is used.

Unfortunately this didn't work - we now have: Failed to create surfaceless platform, trying with vgem device