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

Reply via email to