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> 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.
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. -- Regards, Mick _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
