GFX: border shadow remains when opening and closing systray (or kickoff menu) 2xtimes

[star-buck]

also happens with main menu, and outside of pinebook context

[davidedmundson]

To give an update on what I've been working on: Summary, no results yet. But I have been working, and I have plenty of plans.

• I rebuilt everything on my desktop with EGL and GLESv2 to try and see if the problem was reproducible there (which would narrow it down significantly). It was not reproducible there.

Given that

• The other approach (and this is going for a "quick fix to this and the accelerated video" all in one rather than proper investigating) was to go back to the old FBTurbo driver but also install a stub DRM driver that allows X to not be accelerated but clients to be accelerated. without conflict. A halfway point of the two drivers, giving us the best of both worlds. There was some code for doing this against an old 2.x kernel and some forum posts on other hardware doing this. It seemed a good idea, but I've sunk way too many hours in and not getting worthwhile progress.

Next step, I'll just go for old fashioned debug statements in Qt and kwin and attack the specific problem that way.

[adriaandegroot]

We talked about this on IRC monday when I was testing on sebas's pinebook. I claimed I couldn't reproduce the problem, but I was clicking on the K-menu, not on systray menus. Here's a case where a video of the problem would make a big difference in debugging the issue.

[star-buck]

@adriaandegroot : i get this on latest 29 and previous 24 img on pinebook with the kickoff-menu...

[subdiff]

Some small debugging notes:

• this happens only with active compositing,
• with GL (ES) and Xrender backend, somewhat different in extent, but not with any clear rule to it,
• no error messages in KWin or Plasmashell output, that could be directly linked to the occurrence.

The problem could be located either in:

• Plasma-Frameworks (maybe src/plasmaquick or src/scriptengines/qml/plasmoid/),
• Qt (qtbase, no idea where to look exactly),
• KWin (Sliding popups effect --> was already deactivated, or graphics/effect pipeline),
• the DDX (no idea where to look exactly).

[notmart]

i feel it may be connected with a similar bug we already had in the past that was damage events not arriving for which iirc David did a patch in Qt?

[davidedmundson]

i feel it may be connected with a similar bug we already had in the past that was damage events not arriving for which iirc David did a patch in Qt?

I did a patch for NET_WM_SYNC not being sent as a patch in Qt.

It was subtly different. KWin knew the window wasn't ready and didn't map it, whereas kwin is trying to map something as we get the shadow.

[davidedmundson]

RE: I don't know where I should start looking

Initial steps I would take:

1) Disable window sliding in p-f, see if that makes a difference. Play with window hints see if you can find something that acts as a trigger. If that guides you somewhere, follow it. Failing that:

2) put debug in qxcbwindow and look for differences between when it works vs when it doesn't work (or maybe run xtrace)

3) run apitrace trace -a egl on plasmashell, when replayed, do you have a frame that is entirely alpha? Or is the bug past the client side. If you can get a side by side frame of systray's first frame good vs bad, you'll have some leads (or maybe put debug in qxcbeglintegration, whichever is easier)

4) do the same but approaching from the kwin side of it receiving an EGLImage

[subdiff]

Regarding 1.: I tried to disable window sliding in p-f. Didn't fix the issue.

[davidedmundson]

Found a new very relevant place:

armsoc_dri2.c in the xf86-video-armsoc repo

It's responsible for communicating all the EGL swap buffers and stuff to X.

I'm in that code as it's my source of video slowdown. I just broke all scheduleSwap whilst testing something, and then all my plasma windows behaved like they do in the bug.

It might not be related, but it looks like a good place to look to flood with debug and try and spot a difference there.

[subdiff]

Thanks to @davidedmundson's hint I discovered a fix by not doing Pixmap exchanges in the xf86-video-armsoc driver and instead just blit the update. This can be done by disabling the branch starting from here: https://github.com/shadeslayer/xf86-video-armsoc/blob/master/src/armsoc_dri2.c#L930

I did further tests, to pinpoint the issue more exactly, but these gave no results. In general the deeper issue with this path might be in Qt or the Xserver DIX code itself.

Just not trying to exchange Pixmaps could degrade performance since blits are expected to be more expensive to my knowledge, but in my tests I didn't saw a difference. As a simple solution for now I would therefore recommend to just disable the code path.

[bhush9]

Fixed in http://weegie.edinburghlinux.co.uk/~neon/images/pinebook-remix/20180212-1552/

[bhush9]

(sorry for labeling mess.. I restored previous state of ticket)

[star-buck]

seems fixed!