Re: [e-users] problem with input focus and window layering in E 0.21.11 [solved, kinda]

[Carsten H. <ra...@ra...>]

On Thu, 10 May 2018 13:18:03 -0700 Marc MERLIN <mar...@me...> 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 - ra...@ra...