Bug 355569

please try to also
export KWIN_COMPOSE=Q

Seems to do the same thing with
export KWIN_COMPOSE=Q

reverting those commits did nothing. It must be something I'm doing wrong, or I haven't tested using the framebuffer in a while, so I'm not sure when it stopped working...

maybe it's trying to use the DRM backend? It does the same thing when I do --drm instead of --framebuffer, 
which doesn't work properly in QEMU

Hi

After more testing it seems the framebuffer backend IS being used, and that a recentish version of kwin, the framebuffer backend IS working on my laptop, that does have a /dev/dri/* . My VM does NOT have a /dev/dri/* and it's failing.... Could it be trying to use KMS to switch the mode or something?

No, the fbdev backend doesn't do anything with /dev/dri/*

Any other things I can do to test why the Framebuffer backend fails on QEMU?

It seems comparing the strace output around the time kwin tries to access /dev/fb0 is similar, so I'm not sure where it is failing... ...how do I get kwin to output the debug output for the framebuffer backend, with qcdebug lines, I think it was an environment variable?

and I meant the qemu where nothing draws (the text in the TTY freezes), vs the physical Intel box where I force it to use the framebuffer, and it works. Sorry about the lack of clarity in the first comment

> how do I get kwin to output the debug output for the framebuffer backend, with qcdebug lines,

you need to modify: ~/.config/QtProject/qtlogging.ini

It should look something like:

[Rules]
kwin_core=true
kwineffects=true
libkwineffects=true
libkwinglutils=true
libkwinxrenderutils=true
kwin_wayland_drm=true
kwin_wayland_framebuffer=true
kwin_wayland_hwcomposer=true
kwin_wayland_backend=true
kwin_wayland_x11windowed=true
kwin_libinput=true
kwin_tabbox=true
kwin_decorations=true
kwin_scripting=true
aurorae.debug=true

This will enable all debug output for KWin.

OK, Seems on the qemu box, the framebuffer backend behaves the same trying to access /dev/fb0, according to the log,
It tries to access the Framebuffer device with logind, fails, but then is successful in accessing it directly, because I have the UACCESS attrib set for framebuffer devices...


Only line that is different, and it doesn't seem to be logged by framebuffer backend itself:

QPainter::begin Paint device returned engine == 0, type 3

I tried to add the lines
    qCWarning(KWIN_FB) << "Alpha Length: " << m_alpha.length;    
    qCWarning(KWIN_FB) << "Alpha Offset: " << m_alpha.offset;    
    qCWarning(KWIN_FB) << "Red Length: "   << m_red.length;    
    qCWarning(KWIN_FB) << "Red Offset: "   << m_red.offset;
    qCWarning(KWIN_FB) << "Green Length: " << m_green.length;    
    qCWarning(KWIN_FB) << "Green Offset: " << m_green.offset;
    qCWarning(KWIN_FB) << "Blue Length: "  << m_blue.length;    
    qCWarning(KWIN_FB) << "Blue Offset: "  << m_blue.offset;
in FramebufferBackend::queryScreenInfo()

to see if a difference there could be the cause of the late:
   QPainter::begin Paint device returned engine == 0, type 3
which occurs sometime after Xwayland starts, which that line does not appear on my physical box when using the framebuffer at least. (if that even is related to the issue)

and they all seem to be correct for what FramebufferBackend::imageFormat() tries to match for in QEMU...
Alpha Length:0
Alpha Offset:0
Red Length: 8
Red Offset: 16
Green Length: 8
Green Offset: 8
Blue Length: 8
Blue Offset :0

hmm, maybe the memory mapping to a QImage fails?

How should I go about testing that? I have realized that there are some issues with the way libvirt is passing CPU features, but It seems that kwin is working under the Wayland backend under Weston on QEMU...   
...It's usually breaking some things with LLVM, causing apps to crash, so it could be unrelated...  
So how's a good way for me to test why (or if) memory mapping for the qimage would be failing under just QEMU, only when using the framebuffer backend

The QImage is created in scene_qpainter_fb_backend.cpp in the ctor directly. Maybe try add debug output there. What striked me as odd is the debug message about the paint device which could indicate that something with the QImage is wrong.

I added lines
+    qWarning() << "Bytes Per Line: " << backend->bytesPerLine();
+    qWarning() << "Buffer Size: " << backend->bufferSize();
+    qWarning() << "Bits Per Pixel: " << backend->bitsPerPixel();


in QEMU:
Bytes Per Line: 3072
Buffer Size: 2359296
Bits Per Pixel: 24

It also seems that that qpainter debug message happens with:
QPainter p(&m_backBuffer);
judging by the debug lines I threw into it.

On intel box
Bytes Per Line: 5120
Buffer Size: 4096000
Bits Per Pixel: 32

...and now for some reason this time after realizing I should set my Framebuffer to be 32 bits, it worked in QEMU too (I must have been mistaken somewhere, as I thought setting the framebuffer to 32 bits in QEMU still failed the first time...

For this I attempted to create https://git.reviewboard.kde.org/r/126262/

Well, I know why that patch fixed it on QEMU, but broke it on Intel, the virtual framebuffer device reports itself as 32 bits, but the alpha length, and the alpha offset are both 0, so with the tests I had it doing, it was selecting the 24 bit format...
...Is this a possible bug in the Intel driver?...

Git commit 3247382752071f77b78fb714572f7d31f148e47a by Martin Gräßlin, on behalf of Nerdopolis Turfwalker.
Committed on 15/12/2015 at 12:05.
Pushed by graesslin into branch 'Plasma/5.5'.

[backends/fbdev] Support framebuffers with different color depths

Support more framebuffer color depths

REVIEW: 126262
FIXED-IN: 5.5.1

M  +34   -1    backends/fbdev/fb_backend.cpp

http://commits.kde.org/kwin/3247382752071f77b78fb714572f7d31f148e47a