On 16/12/2018 23:46, Carsten Haitzler (The Rasterman) wrote:
> On Sat, 15 Dec 2018 21:04:45 -0500 Conrad Knight <iestynap...@gmail.com> said:
>> Hi,
>> I recently upgraded from EFL 1.20.7 to 1.21.1. At the same time i also
>> enabled wayland support, however i'm still running Enlightenment under
>> Xorg. I also ugraded E itself from 0.22.3 to 0.22.4. There were no
>> other changes to my set up.
>> Since this upgrade i've been running into this problem: every now and
>> then, when opening a new window, enlightenment will "freeze". It's not
>> reproducible as far as i can tell... sometimes E will be running for
>> days, and suddenly stop when opening up one more window, sometimes it
>> will freeze the moment i open up the first window afer logging in.
>> The symptoms are that the mouse cursor still moves, but will not give
>> focus to any window under it. If i click the mouse button, the cusor
>> blinks, but nothing else happens. The exception seems to be that the
> actually you may be surprised that focus may be getting set.. you just don't
> SEE the results. if you have something that produces sounds when u type... 
> e.g.
> you have speakers or headphones set up and volume up and maybe a terminology
> terminal (and you haven't disabled the visual bell) and you have a prompt - 
> hit
> "ctrl+g" and you'll get a "bing" sound as well as the red bell. if you mouse
> over a terminal in this state and do that and u hear the bing... focus is
> working. apps are working. the problem is the compositor updates are not being
> displayed somehow. also if you have a music or video player and it has kbd
> controls - focus it (dont wait to see it be focused" and use the kbd to make 
> it
> do something with audio you will recognise (pause, play, fw/rw etc.)
>> un-hiding of the IBar at the bottom of my screen still works, as do
>> the buttons in it, allowing me to at least cleanly log out.
>> One other thing that does allow me to recover is switching to a text
>> termial and running:
>> DISPLAY=:0 enlightenment_remote -restart
> FYI e is unaware of vt switches (in x11). it doesn't look, know or care and in
> fact there isn't any X11 way to do this.
> i have seen this before and what you describe smells to me of "driver just
> stopped swapping buffers".
> the way to verify if e (and well efl) is rendering is to get e attached to gdb
> and set breakpoints for the buffer swapping. set a breakpoint for
> eng_outbuf_flush (function name - gdb commant: b eng_outbuf_flush). the best
> way to do this is ssh in from somewhere else as you will need e to keep 
> running
> normally without it having screenblacked etc. if the breakpoint keeps being
> triggered the flush function for the gl engine is being called. if you step
> through you'll see some if's that may skip the ultimate swap and then
> eventually a call to glXSwapBuffers() and beyond this point it's the driver
> stack dealing with displaying things.
> now the reason i say this or point you to checking is to double check/confirm
> it is what i suspect. and because a vt switch "fixes it" ... i suspect the
> driver stack because... it is actually the xorg server that is in charge of
> doing the swap. a swapbuffer call above should simply be sending protocol to
> the server to go do this. in theory the driver could have an internal "back
> door" to the xorg side driver where when you switch away from the vt, the
> xserver tells the gl stack to "update a flag" that basically makes this swap a
> NOOP so the client just sends NOTHING to the server while this is set. depends
> on driver stack and internals, but this is not really relevant. at the end of
> the day i am pointing here because IF e is still swapping buffers, (and the
> fact the pointer blinks when u click says to me e is alive, kicking, 
> processing
> events and trying to render - pointers go via a different path to the rest of
> the display and pointers are sw rendered client-side in x and the pixels
> blasted across on updates and then the cursor updated from this). so e is
> alive and doing it's normal stuff.
> if it's an efl/e problem then the swapbuffer may not be called (something
> blocking it) or preventing updates. now - this could ALSO be driver related.
> depending on the driver, efl will request animation updates from the drm 
> driver
> as vsync events. i know i expanded the whitelist so it could be that your card
> went from not on the white list to on it. this leads to animation perfectly
> timed with screen refresh, and in this case efl will be talking to the dm
> driver stack saying "send me vblank events". oddly your pointer updates so...
> some animator is ticking somewhere i think. perhaps e stops getting vsync
> events for some reason (or some hiccup stops it from requesting them as this 
> is
> turned on and off on the fly depending on animation needs so we don't tick 
> over
> unnecessarily when everything is idle). so there is a possibility there is
> something over there causing it. let's explore this path if the swapbuffers 
> are
> not being called. if they are then... unfortunately we've found a bug in your
> driver stack. :( yes - i know.they are the only changes you made thus you go
> "bug must be there". you are only looking at one dimension in that case. the
> other dimensions are the stack and who is responsible for what. changes we 
> made
> may have now changed code paths in the driver and now triggered that bug 9it
> could be us asking for vsync events at the same time as rendering and now with
> rendering being more "synchronised" it's finding some race condition in the
> driver). but again - this all depends if the swapbuffers is being called as i
> indicated. you can set a breakpoint for it too: b glXSwapBuffers
> so have a look in that direction. if you need more details, please ask. i'm
> kind of hand-wavy pointing in the direction of what i would do. the only place
> i ever saw this was on my laptop... and every time it happened... i was not in
> any position to use a network to ssh in... :)

I'm pretty sure there was a phab issue for this but I can't find it I
can replicate it 100% by going Main -> Applications -> [Some other menu]
and messing around.

The issue seems to be Mesa related, I can replicate it under Mesa 18.1.7
but not 18.0.2 if that helps. I haven't had time to look at it further,
but now things are getting quieter I can probably provide more, I hit it
everytime on my laptop.

When the issue occurs you can restart E from a keybinding and it will go
back to normal.


Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

enlightenment-users mailing list

Reply via email to