Input is ignored on other XScreens #26
Comments
|
I'm on Manjaro with three screens and never experienced issue like the one your describe. That is weird. Could you describe your setup with more details please (how many GPUs do you have, which Desktop Environment are you using ?) |
|
Three screens or three XScreens? BIG difference. ATM just 2 GPU's because I just re-added the second attempting to cobble what was a working system together. The tl;dr is everything worked great in Xubuntu 18.04...then it went EOL and I had to upgrade to where nothing worked. Had to go single GPU and jerry rig other machines to run the other screens. Moved to Garuda (noted in the initial report), still XFCE but downgraded to the last build of 4.12 because anything newer is 100% unstable or unusable for multi GPU/XScreen. Virtually all DE/WM are now completely broken when it comes to multi XScreen set ups. Every GPU runs 3-4 screens. Not much else to tell. Even with a single GPU the issue persists so long as each screen had it's own XScreen. Reinstalled and made 2 entries. One just shoots date, XScreen and XY coords to a text file the other launches a file manager. While it flakes out here and there the text file is updated no matter what XScreen I'm on. The file manager macro only works on the initial XScreen. I also tried combining the two and when I added the filemanager to the first one it doesn't work at all when on Xscreen 1/2/3+. |
|
I see. I only have one XScreen with all my screens on it. I'll try to reproduce the issue but I'm not sure I'll be able to do so easily. By any chance : do you know how to have multiple XScreens on a VM ? |
|
Multi XScreens on a VM doesn't work at all. At least not with Virtualbox (trust me I spent a ton of time on this so I could test things without butchering my workstation). You will have to actually write a local/native xorg.conf where each of your screens has its own XScreen to get the "real effect." VMWare might work for this but I haven't touched that since the 1990's. I'd almost wager you don't need to test so much just look at how you pass args to an acted macro. Just ensure you always get/pass the correct XScreen to the application so if it's an X application it will launch correctly. |
|
I think that the problems comes essentially from the app listening to keyboard events the might be causing this. This is electron code, so maybe their is some issue on their side ? 🤔 |
|
Well like I said I dare say it's simply the XScreen is not being passed. You'd want to simply find out how with electron to query the XScreen the cursor is on then pass to the macro command. If Electron can't find the cursor position correctly due to a bug or flat limitation then I guess this is at an end. For my launch scripts I just use xdotool to query the XScreen and cursor position. Perhaps if Electron has a bug or simply lacks the capability you could leverage that as well for systems running X. |
|
Could you run Hyperkeys in a terminal with this command : Like I said earlier, since I don't have an environment with multiple XScreens, I can't test it myself easily. Thanks in advance 🙂 |
|
Well I ran the debug and I was wrong about passing the XS to the XApplication. HK does NOTHING once you're off the originating XScreen. I did try running a second instance with DISPLAY=:0.1 HyperKeys-1.1.10.AppImage which works for that XScreen. |
|
That is what I was afraid of 😕 I made a new version of HyperKeys with the latest Electron (16.0.1). Could you check if it solves it ? This is a long shot though. |
|
Doesn't make any sense to me. Input is input, everything else on the system accepts it. It's not like if I move to the other screen and type it doesn't work. Something is whack with how/where Electron is getting it's input. Tested 1.2.0 and it's exactly the same. Once my mouse moves to the other screen input is completely ignored, at least in so far as the debug output does/displays nothing. |
|
Damn. Was worth trying... |
|
There is nothing to share, nothing unique. Anyone with a multihead GPU (which is every GPU anymore), running X11 and two or more screens can reproduce this issue. Just give each head => monitor it's own XScreen. Or alternatively if someone had an IGP + GPU run them both (if their mobo allows) giving each their own XScreen for the monitors attached to them. However that's only for testing. I'd wager again testing isn't needed and they just need to ensure they are enumerating/passing/listening to all XScreens and not just the root. |
|
Please share them anyways. BTW I start to wonder if the multiple XScreens is actually not the root cause 🤔 |
|
Root cause of what? Input is accepted system wide no matter what XScreen. However electron is listening for input is attaching to only the XScreen it was launched on causing it to "blackout" once the mouse/focus is no longer within those bounds. My configs won't help anyone else unless they have my hardware config. Any xorg.conf will do so long as each screen has it's own XScreen rather than grouping all screens to a single XScreen. i.e. ServerLayout Section "ServerLayout" Section "Files" Section "InputDevice" Section "InputDevice" Section "Monitor" Section "Monitor" Section "Monitor" Section "Device" Section "Device" Section "Device" Section "Screen" Section "Screen" Section "Screen" |
Environment
Describe the bug and how to reproduce
Ignores input if focus is on another XScreen. Start Hyperkeys move your mouse to another XScreen and trigger a defined macro...note nothing happens. Move mouse back to the XScreen HK was launched on, trigger macro, note it works.
Expected behavior
I expect input to be tracked system wide. No matter what GPU, Monitor, Workspace, input is input (- something Johny 5 would say.) HK needs to track this to ensure triggered actions are carried out/launched on the correct GPU, XScreen, Monitor etc.
Config file
[{"config":{"command":"~/Scripts/pillar/xy_launch.sh f"},"name":"RUN_COMMAND","shortcuts":{"RUN_COMMAND":"alt+meta+z"},"id":"08f1faad-f018-4262-8689-44f25c0e3cb1","enabled":true}]
The text was updated successfully, but these errors were encountered: