On Monday, 17 December 2018 04:24:51 GMT Simon Lees wrote:
> 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> 
> >> 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.

It still freezes here on a mesa-18.2.7, e-0.22.4, efl-1.20.7-r1, with radeon 
card: RV730/M96-XT [Mobility Radeon HD 4670].  It also freezes on an old 
laptop with 'Mobile 4 Series Chipset Integrated Graphics Controller' and i915 
driver (same mesa version).

The freezing occurs when some windows are launched (which may be a bit heavy 
on hardware acceleration?) like Libreoffice, Filezilla, etc., but typically 
the first time only.  Ctrl+Alt+End gets me out of this.

It also occurs when I try to switch between windows with Alt+tab.  Again 
Ctrl+Alt+End gets back to my desktop.

Pressing keys on the dead window/desktop actually receives and processes 
signals, but it is not visible at the time.

Finally, if I Right Click and navigate to Applications, System, the desktop 
restarts as if I pressed Ctrl+Alt+End.  This also occurs when trying to edit 
the contents of menus, e.g. Favorites, or when I go to any settings which 
contain a desktop menu.

This has been happening for years now, but I hoped a later mesa version will 
eventually fix things.

enlightenment-users mailing list

Reply via email to