With Qt5.8 plasmashell windows are not marked as Desktop windows which results in funny setups like this : http://imgur.com/a/VLzfI
From what I investigated Surface::fromWindow is not returning wl_surface and returns nullptr because that is what gets handed by Qt to it. I believe this might be Qt window, but then given kwin internal windows get proper type so I don't know if its Qt bug.
I also believe that this can be as well kwayland regression?
As kwayland didn't change it is not a kwayland regression. The problem must be in the native interface of QtWayland.
KWin's internal windows don't use QtWayland which explains why they still work.
I don't have Qt 5.8 yet, so I cannot really investigate.
I don't see any change in the native interface. Maybe the platform window is not yet created or or plugins might need to be recorded against 5.8?
What do you mean by plugins might need to recorded against 5.8?
Found it: https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandwindow.cpp#n126
No idea what we can do about this. This we need to create a critical bug to Qt.
Am 25. Januar 2017 16:23:08 MEZ schrieb Bhushan Shah <email@example.com>:
>--- Comment #4 from Bhushan Shah <firstname.lastname@example.org> ---
>What do you mean by plugins might need to recorded against 5.8?
Stupid auto correction. That should have been recompiled.
Uhm, but that commit was for Qt5.6?
(In reply to Martin Gräßlin from comment #5)
> Found it:
> No idea what we can do about this. This we need to create a critical bug to
doesn't seem to be, that commit is much older and removing that line doesn't solve the issue
Hmm, I think we have an auto test for the in kwayland. Does it still work? Let's figure out whether it is a general issue or an issue just with desktop windows.
All autotests in kwayland passes for me :-(
Also, problem is not only for desktop windows, as you see panel window is also not "tagged" correctly..
here desktopview seems to be hidden when setupwaylandintegration is called, which is a problem.
calling show just before getting the surface seems to solve that problem, but just uncovers other ones
all tests working here as well
OK, so the fromWindow seems to work and the problem is somewhere else. That we get a null pointer must be a side effect of the root problem.
that's a crash it gets uncovered when i "fix" the desktop window, don't know if related:
#0 0x00007ffff0aaaa29 in wl_proxy_marshal () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#1 0x00007fffe4ee912f in wl_surface_destroy (wl_surface=0x0)
#2 0x00007fffe4eebab2 in QtWayland::wl_surface::destroy (this=0x156dd88) at qwayland-wayland.cpp:1107
#3 0x00007fffe4ec6156 in QtWaylandClient::QWaylandWindow::reset (this=0x156dd60)
#4 0x00007fffe4ec69b5 in QtWaylandClient::QWaylandWindow::setVisible (this=0x156dd60, visible=false)
#5 0x00007fffe017571f in QtWaylandClient::QWaylandEglWindow::setVisible (this=0x156dd60, visible=false)
#6 0x00007ffff2749135 in QWindow::setVisible (this=0x157b250, visible=false) at kernel/qwindow.cpp:552
#7 0x00007ffff7981a5b in PlasmaQuick::Dialog::componentComplete (this=0x157b250)
#8 0x00007ffff4e226fe in QQmlObjectCreator::finalize (this=0x15643f0, interrupt=...)
#9 0x00007ffff4d82961 in QQmlIncubatorPrivate::incubate (this=0x155b080, i=...)
#10 0x00007ffff4d8249a in QQmlIncubatorPrivate::forceCompletion (this=0x155b080, i=...)
#11 0x00007ffff4d83206 in QQmlIncubator::forceCompletion (this=0x7fffffffcb00)
#12 0x00007ffff5e75d79 in KDeclarative::QmlObject::createObjectFromComponent (this=0x9026f0,
One more datapoint, all other windows for example Konsole doesn't have titlebar at all..
Am 25. Januar 2017 17:15:42 MEZ schrieb Marco Martin <email@example.com>:
>--- Comment #15 from Marco Martin <firstname.lastname@example.org> ---
>that's a crash it gets uncovered when i "fix" the desktop window, don't
>#0 0x00007ffff0aaaa29 in wl_proxy_marshal () from
>#1 0x00007fffe4ee912f in wl_surface_destroy (wl_surface=0x0)
Pretty sure it is related: the surface is null
i tried to bisect as back as qtwayland still builds on top of Qt 5.8, but didn't conclude much, as it stops compiling correctly pretty soon (and the 5.7 version doesn't build on 5.8 at all)
That crash is fixed it seems upstream..
But still doesn't explain surface being null :S
Could someone report a regression bug at Qt? I think it's pretty major if they break or Wayland desktop. Maybe they have ideas...
Created attachment 103639 [details]
I am writing bug report, also attaching the plasmashell log with WAYLAND_DEBUG env var..
(Ignore the debugging lines with BSHAH though :p)
that qt code review seems to fix the crash for me, even tough the panel is still misplaced, the desktop still the wrong type, and terminating plasmashell kills kwin too
(ASSERT: "source" in file /home/diau/git/kf5/frameworks/kwayland/src/server/dataoffer_interface.cpp, line 96
so looks like they are two separate issues
Reported : https://bugreports.qt.io/browse/QTBUG-58423
*** Bug 375559 has been marked as a duplicate of this bug. ***
what happens: QPlatformSurfaceEvent(surfacecreated) arrives,
but trying to get the surface, it's a nullptr, not created yet
to me, the problem is just that qwindow::create, always sends a surfacecreatedevent, *but* qwayland does not (anymore?) create the surface in qwaylandintegration::createplatformwindow
so in the end.. does that event is actually supposed to guarantee a wayland surface has been created, or were we doing it wrong all along?
Am 26. Januar 2017 14:24:16 MEZ schrieb Marco Martin <email@example.com>:
>--- Comment #27 from Marco Martin <firstname.lastname@example.org> ---
>to me, the problem is just that qwindow::create, always sends a
>surfacecreatedevent, *but* qwayland does not (anymore?) create the
>so in the end.. does that event is actually supposed to guarantee a
>surface has been created, or were we doing it wrong all along?
The event is called platform surface created. If our code was wrong that would be highly unexpected and a very misleading naming.
is the current state, "fixed" enough?