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... :) > However.... this sometimes causes a whole other problem (again, not > reproducible, but about 40% of the time) -- the windows get redrawn > without any content. There is the faint outline of the window itself, > and the top window bar for windows that have one, but the windows > themselves are all empty. Minimizing, resizing the windows has no > effect. I have to guess where the pull-down menus are (which DO get > drawn, if i happen to find them) to exit the programs. > > Any clues? :) > > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
