<ajax>
where by "posted it a while ago" we apparently mean 2013
<zmike>
that's practically yesterday in x11 terms
<ajax>
first of all, how dare you
<zmike>
go on
<ajax>
<ajax>
i got nothin
<zmike>
I've got at least one outstanding libX11 patchset on the list
<zmike>
I know how it goes
<zmike>
ajax: you're not gonna believe this
<zmike>
BadWindow isn't enough to take down nvidia wsi
<zmike>
oh wait
<zmike>
here we go
<zmike>
forgot I needed to not check it for nv to crash into it
<zmike>
blam
<zmike>
ajax: swapinterval is done and awaiting review?
<zmike>
reviewed anyway
<zmike>
I think with my latest MRs the only remaining issue is the xserver disconnects
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #zink
Akari has quit [Read error: Connection reset by peer]
Akari has joined #zink
<ajax>
kinda wondering if we shouldn't treat swapinterval 0 with wayland as mailbox instead of fio
<ajax>
zmike: so xserver disconnects. what am i looking for for a reproducer here?
<zmike>
ajax: glmark?
<ajax>
hm
<zmike>
or at least that's the one I've seen it with myself
<zmike>
don't remember if kusma filed a specific ticket or just commented here
<kusma>
If you're talking about the crash I ranted about, I triggered that consistently with glxgears
<kusma>
Let me know if I should retest
<ajax>
was there any error message from libX11 or did it just exit
<ajax>
grr, swapinterval patches make glmark2 throw an assert before ever drawing
<ajax>
ah yeah there we are, just says X connection broken for no clear reason
<zmike>
yep that's the one
<ajax>
so i'm pretty convinced that we need to just demand thread-safe libX11
<zmike>
sounds familiar
<zmike>
new lib release time?
<ajax>
probs
<zmike>
nice and easy
<ajax>
here's how this works, i think
<ajax>
(just trying to justify the change as something xcb compels us to do here)
<ajax>
the way thread safety works is xcb owns the write side of the socket, normally, but you can call xcb_take_socket to take it over to write your own requests
<ajax>
which has a parameter to call back to the taker to have it flush out any written data and return the most recent request's seqno
<ajax>
that callback in libX11 starts by doing InternalLockDisplay(dpy), which if you didn't XInitThreads before XOpenDisplay will be a no-op.
<ajax>
so thread A is in the middle of emitting an xlib request, thread B does some xcb call, xcb unsafely takes back the write side of the socket, and either you write garbage requests or you desync xlib's idea of the most recently written request
<ajax>
which is then sanity-checked when dequeueing events, which is where you handle ConfigureNotify for resizing gears (or just mapping the window at all? i think?)
<ajax>
point is ILD() needs to be thread safe if more than one thread is doing to touch the display, which is sort of xcb's whole deal
<zmike>
sounds like a valid explanation
<ajax>
so imma polish the libX11 patch for that, first
<ajax>
and then i'm going to see if i can still repro the glmark2 disconnect
<ajax>
and if i'm lucky, the answer is no
<zmike>
I'm going to take out an early bet on "no"
<ajax>
looking like a savvy bet so far
<ajax>
next q: does this mean we need to bump libX11 in the ci images
<zmike>
yes
<zmike>
it exhibits in piglit glx tests
<ajax>
yeah, looks like that cures glmark
<zmike>
hooray
<ajax>
holy cow that xerror patch
<zmike>
great, right?
<ajax>
it's inspired i'll give you that
<zmike>
if you can think of a simpler way to do it, I'm all ears, but that one seemed obvious