On Thu, 10 May 2018 13:18:03 -0700 Marc MERLIN <marc_...@merlins.org> said:
> On Thu, May 10, 2018 at 12:00:13PM +0900, Carsten Haitzler wrote: > > when mouse enters or exits the window (events from the xserver). that is > > how e decides to focus it or not. > > Right, that's how it normally works. > If you look at my video again you'll see focus is lost without me > leaving the window I was in, just because I enter a region occupied by > the window underneath (not visible), and that window is a special one > (there is a hierachy where chrome steals from gnome-terminal, and the > arduino gui also steals from gnome-terminal, but not the other way > around. yeah. it was hard to tell that. i saw the more general one as i described and thought it was that. :) > > > In what I'm seeing, some windows have higher priority and steal input even > > > if they're below the window on top that I'm trying to write in. > > > > either mouse is entering and exiting... or an app is explicitly setting or > > stealing the focus. apps can do this. the enter/exit may be happening due to > > "fake invisible" windows/rectangles being used to cover areas not covered by > > windows to direct input to the one big canvas that is the screen for e's > > compositor. there may have been a bug in it that messed up these rects OR > > perhaps there were stray "0 0 0 0" rectangles (transparent rects but > > visible to input, so color rgba is 0 0 0 0). if it was this then the bug > > has since been fixed in 0.22 for sure. > > Can't say, but this never ever happened to me with any E version before, > including older ones. it could also be that the evas object stacking is not perfectly mirroring the window stacking (or vice-versa) thus the visual stacking is different in the canvas to the stacking in the x window tree. i don't know... :( > So, I thought going back to 0.21.5 would fix it, but it did not. > I then did more digging and I found it's an unrelated problem where if > you play with window stacking, things break and stay broken. you might find it easiest to check out the stable branch (enlightenment-0.21) and the git bisect your way there as it'll do it in log n steps :) you will also find the exact commit that did it too... > You've already seen my video, what you didn't see is that all my > gnome-terminal windows have a stacking of none. I didn't ask for this, I > have no idea how you get into that state. > If I go to window stacking, nothing is checked. i have no idea how that could happen... i certainly don't see that where - but i don't use gnome-terminal ... but my terminology terminals don't seem to have this... this might be where the window layer value has gone totally out of scope/range? maybe? but how? it's not something i can find out without reproducing and adding lots of debug printfs to trace down where the stacking changes and how... > To fix my problem, selecting window stacking normal to get the radio box > is not enough. > I need to do window stacking, on top. Then focus stays on my window that > was already on top anyway. > Then, I can reset it to stacking normal. > After that input works ok and doesn't get stolen by the window > underneath. that doesn't help - need to know what the stacking layer value is internally and how it got to there... i need a reproduction case. gnome-terminal won't do as gnome-terminal is broken for me. it just sleeps doing nothing for like 30 sec and never shows any window. and exits with: # Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: # Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached *shrug*. broken. :( > I need to do this for every single gnome-terminal I have, one by one, > all 24 of them, and hope the settings get saved. > This is an E bug, is it not? this probably is, but i don't see it day to day on any of my windows i can find... and it may be a symptom of stacking issues where stack in canvas doesn't match stack in x ... and that may have been cleared up by now in layer e's or improved to have fewer holes. > How or in which version the bug was created, I have no idea. I only > managed to find a way out of it, not what I did to create it. well to really get into it i'd need to reproduce on a current git master e so i can work on something with the current state of play and then find any holes or problems there. going back in time 1, 2, 3 etc. years is not very productive. ... but as an aside this whole conversation got me to heavily suspend and resume test on my laptop yesterday and today... and i have yet to have e hang. i have opened and closed that lid so many times ... like at least 100 in the past day. i did find some interesting things though. 1. kernel resume seems sluggish. or more specifically it does its resume work then tries to get userspace started, it allows tasks to run again and then it still takes about 2 seconds before any userspace process runs. i set a timer to poll every 0.1 sec during suspend and resume and it barely ticks at all i think i get 1 or 2, even though it seems there are multiple seconds of possible execution time... 2. other than this sluggishness e was being additionally sluggish because it was doing monitor plug/unplug handling and reconfiguring screens which has artificial delays put into it to allow monitors to power on etc. and to hide the screen reconfig with blackness... so this added maybe 2 or 3 seconds to resume which shouldn't have been there. i now fixed this and removed the reconfigure UNLESS during suspend you plugged in or unplugged an external monitor. 3. i also tested plug and unplug of external monitor ans something in e's randr code broke. it used to properly disable the internal screen and keep the external on if that was the situation on lid close. it actually would migrate the primary screen from internal to external if that was the case (internal was primary with highest priority). it is now fixed that and it does that again. 4. i also noted that e did the right thing - if not on ac AND you had a external screen plugged in lid close won't suspend (if you use "suspend intelligently"). but then a small catch - you unplug the external screen while lid still closed and on battery and e wouldn't decide to go suspend your laptop ... i fixed that now and it does. overall i fixed a few nigglies with external + internal screen and combinations of them plugged in or not and lid open or not as well as power plugged or unplugged. i also sped up resume time significantly to the point where e gets a notification that it has resumed (either from systemd or it's own little timer checker that examines the wall clock while suspending and if wall clock jumps > 0.5 sec even though it's polling every 0.1 sec, then it assumes this is across a sleep/wake cycle and it then assumes a resume). there is a 0.6 sec delay from here to starting the screen fade in (this could become a config value and be adjustable but i put this in just to let the system settle a little on resume) ... and e fades in over about 0.5 sec then and presto. so basically screen is on about 1 sec after e can execute (nicely smoothly faded in). the other 2-3 seconds are all kernel delay unfortunately now (see #1 above). the 0.6 sec could be nuked as i said and the fade is a theme effect that can be determined by theme. so at best i could speed up the multiple seconds of resume by 0.6 .. and this is maybe where your bugs might come in - that e is doing things during resume when things haven't settled yet and your drivers are not liking it at all... it's a guess. which is why i suggested pushing out that value to be higher. i don't know if that is an issue but if it is then it might warrant the extra effort to expose it in the gui and config as a config val to twiddle, but just making it slower for everyone because some systems are bad is punishing others, so i absolutely don't want to do that. we're already punishing somewhat (0.6 sec) and i have a mind to drop that right down to like 0.1 ... -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
