While the DRM backend works fine with virtio now, kwin_wayland crashes straight away when using the DRM backend with the cirrus card. m_image of m_blackBuffer is zero because drmModeAddFB fails, like in bug 364740. While the cirrus DRM driver itself is in a bad shape (many recommend to disable it in the kernel config), it's the current default in virt-manager and the model that openQA uses... #0 0x00007fffee74e71a in QImage::fill(QColor const&) () from /usr/lib64/libQt5Gui.so.5 #1 0x00007fffee74e9ec in QImage::fill(Qt::GlobalColor) () from /usr/lib64/libQt5Gui.so.5 #2 0x00007fffde79f0ec in KWin::DrmOutput::blank (this=this@entry=0x6924a0) at /usr/src/debug/kwin-5.6.90git~20160704T143735~2b5747d/plugins/platforms/drm/drm_output.cpp:326 #3 0x00007fffde7a09d6 in KWin::DrmOutput::init (this=0x6924a0, connector=connector@entry=0x6813c0) at /usr/src/debug/kwin-5.6.90git~20160704T143735~2b5747d/plugins/platforms/drm/drm_output.cpp:189 #4 0x00007fffde79d110 in KWin::DrmBackend::queryResources (this=this@entry=0x6557e0) at /usr/src/debug/kwin-5.6.90git~20160704T143735~2b5747d/plugins/platforms/drm/drm_backend.cpp:318 #5 0x00007fffde79d4e5 in KWin::DrmBackend::openDrm (this=0x6557e0) at /usr/src/debug/kwin-5.6.90git~20160704T143735~2b5747d/plugins/platforms/drm/drm_backend.cpp:239 #6 0x00007ffff5e7544e in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5 (gdb) frame 2 #2 0x00007fffde79f0ec in KWin::DrmOutput::blank (this=this@entry=0x6924a0) at /usr/src/debug/kwin-5.6.90git~20160704T143735~2b5747d/plugins/platforms/drm/drm_output.cpp:326 326 m_blackBuffer->image()->fill(Qt::black); (gdb) print *m_blackBuffer $2 = {m_backend = 0x6557e0, m_surface = 0x0, m_bo = 0x0, m_size = {wd = 1024, ht = 768}, m_handle = 1, m_bufferId = 0, m_stride = 4096, m_bufferSize = 3145728, m_memory = 0x0, m_image = 0x0} Reproducible: Always
Looks like the same general problem (just looked at the code, it calls map without verifying). Though in that case I don't think we can do anything useful except to terminate. If we cannot create a buffer to render to it's pointless.
Overall I think the main problem here is that the DRM backend doesn't handle different formats properly yet. It only supports RGB32. Given the fbdev bug on the same hardware I assume that it's also an BGR/24 case. So we have to do two things here: fix the crash and handle that condition properly and add support for more formats.
Possible patch for the crash: https://phabricator.kde.org/D2135 - untested as I don't have a VM setup for it (need to fix that).
(In reply to Martin Gräßlin from comment #3) > Possible patch for the crash: https://phabricator.kde.org/D2135 - untested > as I don't have a VM setup for it (need to fix that). Looks like it's working: FATAL ERROR: backend failed to initialize, exiting now However, it crashes with a segfault after that, in a global destructor: Thread 1 "kwin_wayland" received signal SIGSEGV, Segmentation fault. 0x00007ffff5e815a3 in QSocketNotifier::setEnabled(bool) () from /usr/lib64/libQt5Core.so.5 (gdb) bt #0 0x00007ffff5e815a3 in QSocketNotifier::setEnabled(bool) () from /usr/lib64/libQt5Core.so.5 #1 0x00007ffff5e81629 in QSocketNotifier::~QSocketNotifier() () from /usr/lib64/libQt5Core.so.5 #2 0x00007ffff5e81649 in QSocketNotifier::~QSocketNotifier() () from /usr/lib64/libQt5Core.so.5 #3 0x00007ffff5e738f1 in QObjectPrivate::deleteChildren() () from /usr/lib64/libQt5Core.so.5 #4 0x00007ffff5e7cc8f in QObject::~QObject() () from /usr/lib64/libQt5Core.so.5 #5 0x00007fffde79ade9 in KWin::DrmBackend::~DrmBackend() () from /usr/lib64/qt5/plugins/org.kde.kwin.waylandbackends/KWinWaylandDrmBackend.so #6 0x00007ffff5e3e279 in ?? () from /usr/lib64/libQt5Core.so.5 #7 0x00007ffff5e3f66f in ?? () from /usr/lib64/libQt5Core.so.5 #8 0x00007ffff52a85df in __cxa_finalize () from /lib64/libc.so.6 #9 0x00007ffff5c49763 in ?? () from /usr/lib64/libQt5Core.so.5 #10 0x00007fffffffcfb0 in ?? () #11 0x00007ffff7de7c5a in _dl_fini () from /lib64/ld-linux-x86-64.so.2
> However, it crashes with a segfault after that, in a global destructor: meh, but a different bug. Have an idea for it ;-)
(In reply to Martin Gräßlin from comment #5) > > However, it crashes with a segfault after that, in a global destructor: > > meh, but a different bug. Have an idea for it ;-) And put into code: https://phabricator.kde.org/D2136
(In reply to Martin Gräßlin from comment #6) > (In reply to Martin Gräßlin from comment #5) > > > However, it crashes with a segfault after that, in a global destructor: > > > > meh, but a different bug. Have an idea for it ;-) > > And put into code: https://phabricator.kde.org/D2136 Confirmed to work!
Git commit cd9a0afafa56bd251ef48022b82dd2c037e4f3ea by Martin Gräßlin. Committed on 13/07/2016 at 07:37. Pushed by graesslin into branch 'Plasma/5.7'. [platforms/drm] Properly handle case that mapping the blank buffer fails Summary: If it's not possible to create a buffer to blank the output, KWin won't be able to render to the output. In that case the output should not be added to the list of outputs. To support this DrmOutput::blank and DrmOutput::init return bool to indicate whether they succeeded. DrmBackend handles this situation and doesn't add the output to the list of outputs if init failed. If after init there are no outputs KWin is in a state where it won't be functional. Thus the platform emits the initFailed signal to terminate. FIXED-IN: 5.7.2 Test Plan: No hardware to reproduce the condition Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2135 M +13 -2 plugins/platforms/drm/drm_backend.cpp M +11 -5 plugins/platforms/drm/drm_output.cpp M +2 -2 plugins/platforms/drm/drm_output.h http://commits.kde.org/kwin/cd9a0afafa56bd251ef48022b82dd2c037e4f3ea