<ajax>
i take it the wsi thread is stuck waiting for a present event that's not coming?
<zmike>
no
<zmike>
uhh
<zmike>
maybe
<zmike>
let me check
<zmike>
no
<zmike>
looking at this, the driver is just drawing more frames endlessly but has nothing to draw to
<ajax>
well. for glx that error condition is called GLXBadCurrentDrawable and you can get it from any of WaitX WaitGL or most likely SwapBuffers
<ajax>
do we just not raise that ever?
<zmike>
seems not?
<zmike>
you should be able to repro it with glxgears on zink+nv
<ajax>
woof no we do not.
<zmike>
but you have to actually close the window
<ajax>
oh good. we only generate that error's deprecated cousin BadCurrentWindow, in the "i'm running on osx and pointed at X11.app" accel path
<ajax>
so that's excellent.
<zmike>
useful
<ajax>
my nv machine is not easily powered on atm, happen to have a backtrace handy?
<zmike>
uhh
<zmike>
backtrace for what?
<ajax>
gears, when it's refusing to die.
<zmike>
just fire up my MR and click the close button on glxgears
<zmike>
#13 0x0000555555557735 in draw ()
<zmike>
#14 0x0000555555557148 in main ()
<zmike>
then it's inside mesa
<zmike>
spinning away in futility
<ajax>
datura:~/git/zink% zink glxgears
<ajax>
MESA: error: zink: failed to update swapchain capabilities
<ajax>
X connection to :0 broken (explicit kill or server shutdown).
<ajax>
KILL 0x562792597c40
<ajax>
and then back to the prompt
<zmike>
that's on nv?
<ajax>
no, like i said, not easily accessible right now
<zmike>
oh I misread
<zmike>
yeah that's what happens on every other driver
<zmike>
I guess different x11 wsi
<ajax>
yeah
<zmike>
maybe we want something in the kopper frontend that can notice when the swapchain is killed and simulate an x error?
<ajax>
yeah, killed swapchains should no-op for everything but actual wsi drawable action, whichever one we hit from SwapBuffers needs to thread an error return back up
<ajax>
s/action/inter&/
<zmike>
zink_kopper_update is actively returning false with my MR
<zmike>
so then it's up to the frontend to handle that