Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Tue, 25 Dec 2018 18:02:32 -0500 Conrad Knight said: > On Mon, Dec 24, 2018 at 4:54 AM Carsten Haitzler wrote: > > https://www.enlightenment.org/contrib/enlightenment_debugging > > > > if you want to attach without there being a crash.. first tell > > enlightenment_start to stop monitoring: > > > > killall -USR1 enlightenment_start > > Well that was easier than i had thought it might be :) > > I set the breakpoint, and stepped through after, with and without the > freeze-up, but couldn't see any difference. After not seeing much of > anything useful, i recompiled EFL and E with debugging info and... the > problem's gone! I suspect left over old versions of EFL libraries may > have been the problem. The "make install" and "ldconfig" don't always > seem to work as expected. yargh! heisenbug! :( -- - 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
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Mon, Dec 24, 2018 at 4:54 AM Carsten Haitzler wrote: > https://www.enlightenment.org/contrib/enlightenment_debugging > > if you want to attach without there being a crash.. first tell > enlightenment_start to stop monitoring: > > killall -USR1 enlightenment_start Well that was easier than i had thought it might be :) I set the breakpoint, and stepped through after, with and without the freeze-up, but couldn't see any difference. After not seeing much of anything useful, i recompiled EFL and E with debugging info and... the problem's gone! I suspect left over old versions of EFL libraries may have been the problem. The "make install" and "ldconfig" don't always seem to work as expected. Thanks for your patience. -Conrad. -- Shine like thunder Cry like rain ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Sat, 22 Dec 2018 11:01:28 -0500 Conrad Knight said: > On Wed, Dec 19, 2018 at 4:39 AM Carsten Haitzler wrote: > > oh - mouse pointer didn't change e.g. when over chrome? (when things froze). > > zero changes to pointer? in your previous mail you said the pointer changed > > when you clicked ... did it still do this? > > The cursor remains the default E cursor, as if the mouse was not > hovering over any window. When clicking, the outline of the cursor > blinks with a blue outline, just as it does when clicking on the > desktop, except no menu appears. This happens no matter which window > (or the desktop) the cursor is over. > > > nothing that leaps out at me... - try mousing over chrome - does the pointer > > change? > > Nope, as mentioned above. This is part of the reason i thought it > looked like no windows were getting focus. odd but e's pointer is there and does thing when u click - that means e is getting that mouse click and doing the pointer animations... it's alive. > > the fact the restart request works means e's event loop is working and > > processing events. you didn't try the gdb thing i mentioned right? > > No, i'm not sure how to do this: https://www.enlightenment.org/contrib/enlightenment_debugging if you want to attach without there being a crash.. first tell enlightenment_start to stop monitoring: killall -USR1 enlightenment_start then as the above - atach to the enlightenment process (don't send e a SEGV signal - that'll force an artificial crash) > > 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. > > I do have access to a Windows laptop with Putty to ssh in. Should the > "attach" part happen before or during a freeze-up? And how do i > actually attach a running E process to gdb and set the breakpoint? > > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > -- - 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
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Wed, Dec 19, 2018 at 4:39 AM Carsten Haitzler wrote: > oh - mouse pointer didn't change e.g. when over chrome? (when things froze). > zero changes to pointer? in your previous mail you said the pointer changed > when you clicked ... did it still do this? The cursor remains the default E cursor, as if the mouse was not hovering over any window. When clicking, the outline of the cursor blinks with a blue outline, just as it does when clicking on the desktop, except no menu appears. This happens no matter which window (or the desktop) the cursor is over. > nothing that leaps out at me... - try mousing over chrome - does the pointer > change? Nope, as mentioned above. This is part of the reason i thought it looked like no windows were getting focus. > the fact the restart request works means e's event loop is working and > processing events. you didn't try the gdb thing i mentioned right? No, i'm not sure how to do this: > 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. I do have access to a Windows laptop with Putty to ssh in. Should the "attach" part happen before or during a freeze-up? And how do i actually attach a running E process to gdb and set the breakpoint? 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
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Tue, 18 Dec 2018 14:46:32 -0500 Conrad Knight said: > On Sun, Dec 16, 2018 at 8:31 AM Carsten Haitzler wrote: > > 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. > > It just happened again, so i was able to test this. There's definitely > no focus -- i had just opened a terminal window with a password > prompt, and no amount of clicking in that window would allow me to > enter the password. I also had a terminology window open on the same > virtual desktop, and there was no "bing" or visual bell. I used the > miniature pager in the i-bar to switch to the desktop with Chrome > open, and clicking on different tabs had no effect. The whole time, > the mouse cursor never changed from its shape on the desktop, where it > would normally change to a different shape when hovering over > different windows. oh - mouse pointer didn't change e.g. when over chrome? (when things froze). zero changes to pointer? in your previous mail you said the pointer changed when you clicked ... did it still do this? chrome sets its own pointer so pointer should hang to whatever chrome drives when over its window > > 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. > > Oh, i realise this, it's just that i was able to issue the restart > command from a different vt, and that (sometimes, it did i this most > recent instance) recovers. The vt switch itself doesn't do anything > (if i switch back immediately, E is still mostly frozen). oh - i thought the vt switch did the fix. never mind then. > I'm including some syslog entries in case they're related... These are > from immediately before i switched to a text vt to restart E, and as i > mentioned, i did use the pager to attempt focussing other windows > first. The freeze-up happened on opening a gnome-terminal window with > a password prompt, so i've included the errors right before the > terminal opened at Dec 18 13:57:23, which is followed by fprintd > asking me to swipe the finger print reader. nothing that leaps out at me... - try mousing over chrome - does the pointer change? the fact the restart request works means e's event loop is working and processing events. you didn't try the gdb thing i mentioned right? > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > ERR<3009>:eina_safety src/bin/e_pixmap.c:613 e_pixmap_size_get() > safety check failed: cp == NULL > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: ## Copy & > Paste the below (until EOF) into a terminal, then hit Enter > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: eina_btlog << EOF > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/libeina.so.1#011 0x7fdd9fe101bc 0x7fdd9fde5000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/libeina.so.1#011 0x7fdd9fe10f51 0x7fdd9fde5000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/libeina.so.1#011 0x7fdd9fe1257b 0x7fdd9fde5000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/libeina.so.1#011 0x7fdd9fe29c60 0x7fdd9fde5000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/bin/enlightenment#011 0x55693cb0a3c3 0x55693ca01000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/bin/enlightenment#011 0x55693ca7b9a6 0x55693ca01000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/bin/enlightenment#011 0x55693ca9026b 0x55693ca01000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/bin/enlightenment#011 0x55693ca9094b 0x55693ca01000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 > 0x7fdd8cc9865c 0x7fdd8cc9 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 > 0x7fdd8cc9887b 0x7fdd8cc9 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 > 0x7fdd8cc988f9 0x7fdd8cc9 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 > 0x7fdd8cc9900e 0x7fdd8cc9 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/libecore.so.1#011 0x7fdd9fea1399 0x7fdd9fe7d000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib/libecore.so.1#011 0x7fdd9fea8adf 0x7fdd9fe7d000 > Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: > /usr/local/lib
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Sun, Dec 16, 2018 at 8:31 AM Carsten Haitzler wrote: > 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. It just happened again, so i was able to test this. There's definitely no focus -- i had just opened a terminal window with a password prompt, and no amount of clicking in that window would allow me to enter the password. I also had a terminology window open on the same virtual desktop, and there was no "bing" or visual bell. I used the miniature pager in the i-bar to switch to the desktop with Chrome open, and clicking on different tabs had no effect. The whole time, the mouse cursor never changed from its shape on the desktop, where it would normally change to a different shape when hovering over different windows. > 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. Oh, i realise this, it's just that i was able to issue the restart command from a different vt, and that (sometimes, it did i this most recent instance) recovers. The vt switch itself doesn't do anything (if i switch back immediately, E is still mostly frozen). I'm including some syslog entries in case they're related... These are from immediately before i switched to a text vt to restart E, and as i mentioned, i did use the pager to attempt focussing other windows first. The freeze-up happened on opening a gnome-terminal window with a password prompt, so i've included the errors right before the terminal opened at Dec 18 13:57:23, which is followed by fprintd asking me to swipe the finger print reader. Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: ERR<3009>:eina_safety src/bin/e_pixmap.c:613 e_pixmap_size_get() safety check failed: cp == NULL Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: ## Copy & Paste the below (until EOF) into a terminal, then hit Enter Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: eina_btlog << EOF Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libeina.so.1#011 0x7fdd9fe101bc 0x7fdd9fde5000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libeina.so.1#011 0x7fdd9fe10f51 0x7fdd9fde5000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libeina.so.1#011 0x7fdd9fe1257b 0x7fdd9fde5000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libeina.so.1#011 0x7fdd9fe29c60 0x7fdd9fde5000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/bin/enlightenment#011 0x55693cb0a3c3 0x55693ca01000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/bin/enlightenment#011 0x55693ca7b9a6 0x55693ca01000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/bin/enlightenment#011 0x55693ca9026b 0x55693ca01000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/bin/enlightenment#011 0x55693ca9094b 0x55693ca01000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 0x7fdd8cc9865c 0x7fdd8cc9 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 0x7fdd8cc9887b 0x7fdd8cc9 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 0x7fdd8cc988f9 0x7fdd8cc9 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/enlightenment/modules/pager/linux-gnu-x86_64-0.22/module.so#011 0x7fdd8cc9900e 0x7fdd8cc9 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fea1399 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fea8adf 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fea43d9 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fea3017 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fe9d962 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fe9ddab 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fea4309 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fea32c7 0x7fdd9fe7d000 Dec 18 13:56:24 inanna /usr/lib/gdm3/gdm-x-session[2832]: /usr/local/lib/libecore.so.1#011 0x7fdd9fe9de47 0x7fdd9fe7d000 D
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
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 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 the
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On 16/12/2018 23:46, Carsten Haitzler (The Rasterman) wrote: > On Sat, 15 Dec 2018 21:04:45 -0500 Conrad Knight 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 caus
Re: [e-users] enlightenment "freezing" when opening a new window... sometimes
On Sat, 15 Dec 2018 21:04:45 -0500 Conrad Knight 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 t
[e-users] enlightenment "freezing" when opening a new window... sometimes
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 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 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
