Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Daniel Stone]

Hi Mike,

On 5 April 2018 at 09:03, Mike Lothian <mike at fireburn.co.uk> wrote:
> I got different behavior with modesetting and the intel ddx

I can try with the Intel DDX later on today.

> Both didn't render anything, but I think one was crashing over and
> over (I think systemd kept restarting it in quick succession)

systemd should log core files to coredumpctl and maintain any output
from services it's started itself in journalctl, so it would be great
to see any output and segfaults if possible.

> I only remember that because when I switched VTs it made it almost
> impossible to type anything as it kept modesetting back to VT1 for a
> moment
>
> That didn't happen with the latest patches (which all seem to be in
> master now) but I did get the freeze that you saw

Right, they are in master now. Which freeze do you mean? If you attach
to the kwin process and see it blocked forever waiting on a reply in
libICE/libSM, this seems to be related to KDE's session management
getting itself tangled, and _not_ anything to do with the rendering
path. For me, the hang inside libICE/libSM was caused by wiping out
all the ksmserver processes still running, as well as my .ICE-unix
directory.

If you are seeing KWin and all the KDE session helper programs alive
and _not_ blocked inside libICE/libSM, a black screen and a KDE mouse
cursor, that's far more interesting and I'd also like to see the X
server's log file as well as any output from KDE in journalctl.

> Be aware that kwin detects when there have been rendering crashes or
> incomplete starts and disables compositing. With compositing disabled
> or set to Xrender everything starts fine

I'm _extremely_ sure that I was using GL compositing, because I was
seeing debug prints that I'd added to Mesa (and the X server DRI3
requests called by Mesa) from a session running only KDE and nothing
else. These debug prints were only ever called when you are an X11
compositing manager.

Cheers,
Daniel