<div dir="ltr">Nope still not working<div> </div><div>Intel DDX didn't launch, Modesetting did however compositing was disabled due to the previous failure. Upon reenabling the screen went blank, however things were still running, when I went to the top left corner I could see the window titles, then the outline of the kicker menu too</div></div> <div class="gmail_quote"><div dir="ltr">On Thu, 5 Apr 2018 at 11:07 Mike Lothian <<a href="mailto:mike@fireburn.co.uk">mike@fireburn.co.uk</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There's also some journalctl output in the bug report On 5 April 2018 at 11:06, Mike Lothian <<a href="mailto:mike@fireburn.co.uk" target="_blank">mike@fireburn.co.uk</a>> wrote: > Hi > > I'm attaching the core dumps (4GB uncompressed, 7MB XZ compressed) > > Might still be too big for the list > > Cheers > > Mike > > On 5 April 2018 at 09:33, Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> wrote: >> Hi Mike, >> >> On 5 April 2018 at 09:03, Mike Lothian <<a href="mailto:mike@fireburn.co.uk" target="_blank">mike@fireburn.co.uk</a>> 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 </blockquote></div>