X windows started on newly defined monitor doesn't accept focus #16
Comments
|
Hi, Yes, I've sometimes seen this but have had trouble reproducing it. Your observations will help, thanks! Is there anything printed to stderr which might help? |
|
Of course. I have repeated all now and watched stderr. Notice: happens for sure on the fresh Xorg process after initial login. Maybe you can reproduce this in that way. For mate-terminal and xterm, it is like that. Gvim works even without Restart. Strange.
Monitor: eDP1 (PRIMARY) (x: 0, y: 0, w: 1920, h: 1080)
Monitor: eDP1 (x: 0, y: 0, w: 1920, h: 1080) While moving to the new monitor or calling terminal from the menu: monitor_by_name: couldn't find monitor: (c) While trying to focus terminal window on the new monitor, and suceeding only if pointer is on decoration and not touching inside window, there is no any new output on stderr. |
|
Thanks -- I'll take a look later. In your config, are you using any |
|
Indeed. It is defined among other options in default (*) Style with "c" option. StartsOnScreen c |
Right -- this won't work now. Previously, |
|
Ok, removed StartsOnScreen while testing fvwm3. If your intention was to inspect if behaviour described in this issue will gone if I remove this option, I have tested fvwm3 ta/desktops again without StartsOnScreen and strange focus behaviour remains until fvwm3 Restart from menu/console/etc ... after restart, everything is ok - every time I tested. |
Not at all -- your observations are valid and correct. I was more informing you about an incompatability from fvwm2 which isn't going to work in fvwm3, hence the suggestion on how to fix that. It doesn't impact or have anything to do with the focus problems you've described. :) |
|
Hi, Please can you: and retest. I've changed how FVWM is tracking RandR event subtypes, so I'm hoping this situation fixes this issue. |
|
Hi Thomas, Segfaults the same moment I turn on secondary screen with xrandr --right-of ... Core was generated by `/opt/fvwm3/bin/fvwm3 -f /opt/NsCDE/config/NsCDE-Main.conf'. (gdb) bt (gdb) print m->Desktops->next |
|
Hmm, I'm still unable to reproduce this after my latest commit. Can you please set: At the top of your Thanks for your help and patience! |
|
I didn't know for that BugOpts option. I have put it directly before any other directive. No need thank me, I'm a great fun of FVWM and I'm glad if I can help. If you need some testing or similar, just ask, no problem. About configuration: I'm using FVWM as a framework for my diabolic project of modern CDE-ish desktop called NsCDE (Not so Common Desktop Environment). All FVWM configuration is in config/ subdirectory. NsCDE-Main.conf is core part, and other parts are included/read from it. User part of the configuration is in ~/.NsCDE and it is default in my virtual machines for testing. It doesn't interfere with standard FVWM paths such is ~/.fvwm. Here it is: https://github.com/NsCDE/NsCDE Here are the outputs (stderr and gdb): 1. Stderr from the moment of "xrandr --output Virtual-1 --mode 1400x1050 --right-of Virtual-0 --auto" till the logout after segfault. [fvwm][My_XNextEvent]: <> executing module comand queue Monitor: Virtual-1 (x: 1400, y: 0, w: 1400, h: 1050) XIO: fatal IO error 4 (Interrupted system call) on X server ":0" python3: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" 2. gdb full trace, including print of m->Desktops Core was generated by `/opt/fvwm3/bin/fvwm3 -f /opt/NsCDE/config/NsCDE-Main.conf'. |
|
I'm adding video instructions of how to reproduce this bug. View->Display 2 is equivalent of hardware monitor connecting with cable |
|
Update: I was able to reproduce this with vanilla FVWM configuration. If spice-vdagent is turned on, it presents 3 more additional virtual screens to the Xorg and driver. If FVWM is started with all but first screen off and then second screen is plugged on, it is blank until I enable it with xrandr from xterm. FVWM background is visible for a part of a second on new screen, and then sigsegv comes. Backtrace is the same as always - m->Desktops is 0x0. Also, when using FVWM 2.6.9 I'm not triggering this bug. Neither with vanilla not with my setup. After logout, scrondary screen remains turned on (see video) and if I log in again with such pre-defined setup, bug is not manifesting again itsel, so I can at least confirm that focus problems from the subject of this bug are fixed. |
|
Hi, Perfect. I have now spent wayyyy too long understanding what's happening. Thanks for the video, BTW, that was useful.
Because the existing connection to the XServer is open. the use of So, I've tried to fix this in a few ways:
So, @NsCDE -- can you please update your git repo per the following: and try and see what you get this time? There's going to be a few extra bugs here, I'm sure of it, as it's quite a big change (770aab7) -- so we'll tackle those one-by-one. #17 is definitely going to bite us -- so if you can test the behaviour with Thanks again for your help! |
|
Hi, I have checked out ta/desktops but it is the same as 2 days ago, which I tested during the weekend. You probably meant to checkout ta/fix-gh-16 from 770aab7 right? EDIT: I started to type this in the morning, but had work to do. Now I see you edited and clarified that. It doesn't segfault anymore on new monitor plug + xrandr. Focus on the new screen is working ok without Restart. So you did it on this bug. Interesting part of the stderr output (see below). But, as you said, there is more bugs here. So my observations are further this:
Stderr output in the moment of xrandr adding screen: ... monitor_output_change: changed output: 68, mon output: 67 HandleRRScreenChangeNotify: refreshing monitor Virtual-1 |
Yes, sorry. All of this work is happening on
:). I realised this morning it was ambiguous.
Good -- and thanks. But, as you said, there is more bugs here. So my observations are further this:
Interesting. I've not seen this yet, and I've been testing both on two physical monitors, and three virtual monitors where I can assign them weird/different sizes from one another (most physical screens tend to have the same dimensions). If you could capture either a screenshot or video, that would help me.
I think it might be better if we split this up. I understand why the original focus problem existed, and have fixed that, although it has uncovered other problems, so I would suggest you split out your observations.
BTW, you don't need to use Thanks for the output, I'll keep that in mind! |
|
Hi, I've just pushed an additional fix (120a225) which might help with areas of the screen still not being able to focus windows -- do please: make and build as usual, and try again. This removes a |
|
HEAD is now at 120a225 WIP: RandR: track subtypes for outputs At DesktopSize 1x1: MUCH more consistent, Except Scroll 100 goes some noware, even at 1x1. BTW, about xrefresh need when turning screen off/on: |
|
At DesktopSize 3x3 wherever I go or move, "Echo At DesktopSize 1x1, while walking through desktops with "GotoDesk 0 0" to 0 3, all seems to be ok. I have opened 2x4 terminals and wrote screen name and desk number in prompt, and make walk. Seems legit, except $[screen] is uninitialized. [fvwm][Echo]: DEBUG-DSK: Screen: $[screen], Desk: 1, Page X: 0, Page Y: 0 Additionaly, if I try to print desktop name with "Echo $[desk.nameX]" I get segmentation fault and express logout.
|
|
Ooh nice! Two things to note here (more detail in commit message (ea81cc1)):
I'm hoping that point 2 above also helps to go further when handling desks/pages when the Do please take a look and check I've not broken anything else! |
|
Hi,
Now about With I'm sending you visual preview of this. For the sake of being a bit shorter, I worked with DesktopSize 2x2 while capturing this, but behaviour is the same. Working desk ("One") was not changed during this, just pages. 4 and half minutes with stderr on tail -f. Hope this helps. |
Hello,
Good.
Good.
Yeah -- it's something to consider. I'll add it to the TODO list, but at least there's a mechanism for ascertaining the RandR output. I probably made
This is related to #17 -- essentially, to work out which monitor a given window is on, we're only comparing the physical dimensions of the output. For The maths will be tricky to do. This will also fix dragging windows around in FvwmPager. (On that note, with the changes I've made recently on
It does help me a lot -- thank you! I'll see what I can! |
|
Ok, looks like #19 is solved by activities on this (#16) issue, and problems with window/page addressing in per-monitor conditions can be continued on #17 right. This #16 also looks as solved. |
When a given output changes size, or is disabled, ensure FVWM is better informed so that it can adjust its view of which outputs are available and what their sizes are. FVWM uses rectangle calculations to determine if a window should receive focus. When monitors come and go, FVWM needs to reinstate its view of these outputs and their rectangles, based on the screen size at the time. It's more complicated with `DesktopConfiguration per-monitor` due to the width/height of the screen being different from one another, potentially. This change is big, and is littered with debug. Goes a long way to fixing Github Issue #16.
When a given output changes size, or is disabled, ensure FVWM is better informed so that it can adjust its view of which outputs are available and what their sizes are. FVWM uses rectangle calculations to determine if a window should receive focus. When monitors come and go, FVWM needs to reinstate its view of these outputs and their rectangles, based on the screen size at the time. It's more complicated with `DesktopConfiguration per-monitor` due to the width/height of the screen being different from one another, potentially. This change is big, and is littered with debug. Goes a long way to fixing Github Issue #16, #19.
When a given output changes size, or is disabled, ensure FVWM is better informed so that it can adjust its view of which outputs are available and what their sizes are. FVWM uses rectangle calculations to determine if a window should receive focus. When monitors come and go, FVWM needs to reinstate its view of these outputs and their rectangles, based on the screen size at the time. It's more complicated with `DesktopConfiguration per-monitor` due to the width/height of the screen being different from one another, potentially. This change is big, and is littered with debug. Goes a long way to fixing Github Issue #16, #19.
It was said on the fvwm list that after turning new monitor everything should work without restart of fvwm3, but ...
Either windows moved (with mouse) from primary monitor to the new one, or started there, most of them doesn't have a keyboard/mouse focus. I can move them around, but that's it. Strangely, gvim doesn't have this problem, while Okular (Qt PDF viewer) even doesn't show drop down menu when I click on "File" or "View" etc ... When moved to the old display, they have a focus.
Another interesting behaviour is when I move from old monitor, from focused window to the new one, I can focus window on the new monitor, but only if I position mouse on the titlebar, borders or corners. The moment mouse pointer is moved further in the window - out of decoration, focus is lost.
Workaround: FVWM Restart solves all this.
Tried with the master and ta/desktops branch - same behaviour.
CentOS 7 x86_64
Xorg X.Org X Server 1.20.4
The text was updated successfully, but these errors were encountered: