Closed star-buck closed 6 years ago
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.
Given that
Next step, I'll just go for old fashioned debug statements in Qt and kwin and attack the specific problem that way.
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.
@adriaandegroot : i get this on latest 29 and previous 24 img on pinebook with the kickoff-menu...
Some small debugging notes:
The problem could be located either in:
src/plasmaquick
or src/scriptengines/qml/plasmoid/
),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 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.
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
Regarding 1.: I tried to disable window sliding in p-f. Didn't fix the issue.
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.
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.
(sorry for labeling mess.. I restored previous state of ticket)
seems fixed!
also happens with main menu, and outside of pinebook context