-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Original X11 screens #68
Comments
This is old but open & I'm just chiming in as I run on several XScreens. I just launch an instance per. DISPLAY=:0.0 alttab (args) ; DISPLAY=:0.1 alttab (args) ; DISPLAY=:0.2 alttab (args) |
Does it work as you expected? Don't you need alttab to show a unified switcher for all screens? |
All screens? (XScreens or monitors assigned to an XScreen?) Alttab shows all windows on the current workspace on the current XScreen for all monitors assigned to that XScreen. So yes it works as expected. If by all screens you mean all XScreens that would be nifty but my xorg.conf is set up so that each XScreen has it's own GPU so I'm used to things being "locked" to the specific XScreen | DISPLAY | GPU I'm on. There is unfortunately a lot of potential for misunderstanding with some of this and my setup seems to be a mystery to most but "back in the day" (like 1990's up to when GTK decided to break XScreens enumeration) alt tab in say gnome or xfce worked just the same, I just didn't have to run an instance per XScreen. So really the only issue is the overhead of extra instances which is negligible. Might have been an issue on my 1990's hardware heh. As everything is pushing for "Waylandification" the more things are broken on inconvenienced for proper multi GPU setups like mine. I know there are a few people out there who run separate XScreens on a single GPU so perhaps they might want it to "jump ship" across each XScreen when triggered but for me things are "normal." |
Based on what you wrote and what I remembered, cross-screen functionality would be overkill for alt-tab today. And yes, around the early 2000s, the mainstream spoiled "non-standard" setups. If you don't need complete isolation of screens, you could try RANDR, as it is better supported today. |
randr is a death sentence for my setup heh. Trust me I played with the new "providers" functions (my god the documentation was / is (maybe still) terrible. It might be OK if you have matched GPU's but on my setup using xrandr means all GPU's at idle sit at 50% load churning heat and power for nothing. Watching a video feels more like setting my machine on fire with my fans screaming and video stuttering, never mind play a game. Keeping the GPU's separated with my xorg.conf everything runs flawless. Watch videos on one while blender churns away on another while I play a fancy high end game on another with zero hitches or hindrance. At this rate I'll die with X unless someone pulls their heads out of their butts and makes a single GPU that will run 12 screens. It's mind boggling I could waste $15000+ on the Radeon WD/WX or Quadro cards and still have to run multi GPU. Always makes me crook my head that the "wall of screens" use case is always ignored over "per-seat" or ML "compute" workloads. I suppose the alternate possibility would be if Wayland fixes the "dump all the work on one GPU and turn the others into worthless output splitters doing zero rendering work while drawing power and creating heat" issue. To be more on point yeah I don't think alttab needs to implement cross XScreen stuff. Most people still running segregated XScreen set ups to denote DISPLAY=:X.X do so because they want the compartmentalization for their workflow/hardware. There is on legitimate issue where alttab requires you to click before you trigger when changing XScreens. So better mouse tracking might be a valid thing to look into. |
Considering that a wall of screens is used only at nuclear stations and in action movies, and in both cases, there's no need to run heavy 3D accelerated applications, I think they use a lot of separate raspberry pi's. (just kidding) I'm not sure I understand what you mean by "alttab requires you to click." When alttab sees keyboard events, you're already interacting with a specific screen. How do you switch between screens, and why is a mouse click necessary for that? It seems like some window managers switch the screen without a click, just by moving the cursor. |
A few years ago (when you could still get a Pi for $30-$40 dollaroo) I'd be down with running more screens off them. ;p To further rebuff jokes with jokes my life is the most BORING action movie imaginable...except when the cats get frisky. ;) I just move my mouse between XScreens but if I move from one to another then alt tab it opens on the screen that had a previous click. I have a few things I've written over time as GTK destroyed things that do the old fake click before triggering bit. I'd wager it would behave as expected if I enabled focus follows mouse.
xdotool is potentially broken these days too but this is a muddy topic. By which I mean I used to run a Debian distro. Slowly things were breaking and I had no idea why because the release cycles are so slow on Debian distros. By the time you notice something it's buried by a hundred newer items in the change notes. It took years of digging and experimenting why my hardware that ran fine "out of the box" for years suddenly didn't. So xdotool is no longer able to track the mouse correctly (itself also requiring the click in the new XScreen) or previously my WM (xfwm back then) was helping it out giving it the false appearance it was tracking correctly. Also walls-o-screens is the best! My "big" vesa mount died a few years back and I'm down from 12 to 8 and it feels cramped. I'd love a VR/AR style headset that gives me an infinite 240-360 degree workspace so I don't have to care about mounts and space. I know there are 2 on market now but they both el-suck heh not to mention they make my GPU array look cheap they are so insanely over priced (and under powered compared to my now aged rig). |
I suppose xdotool doesn't track the mouse. Just like alttab, it operates on a specific screen that it recognizes, not multiple ones. Perhaps you need to release keys on the old screen and then click on the new one, like this:
Honestly, I almost didn't understand anything, especially how alttab could be of help here. Unfortunately, I can't set up a multiscreen configuration to check this because my action movie revolves around a disaster, adventures, and an old laptop. In short, not boring) |
I don't need to "release" things on the previous screen, there is nothing to release, it's just a matter of activating the "change" of XScreen since unless focus follows mouse is active nothing "understands" where the mouse is until it's actively focused something to make the change, i.e. my above snip. (now also below, and note that it's a tad overkill as all you really need is to trigger a click but there was a period where I had some modifiers stick so I went nuclear heh)
Years ago changing Xscreens required some tom foolery, back before Xinerama. You couldn't just move your mouse from one to another. However today you can, without Xinerama. As for understanding seems not many know how to set up my type of config anymore. A dark art soon lost to time. It's also mired in a lot of complexity where words get interchanged making more difficult to put into text where an info graphic would be best...up until you mix in behaviors which then almost demands video. People often assume/mistake that I'm using some "DRI_PRIME" or Xinerama setup which causes all kinds of frustration if there is "tech support" in the mix (glaring at the idiots at Valve). |
Should alttab support them?
Not xinerama/xrandr outputs, but THOSE screens denoted after point in DISPLAY=:0.1
Each such screen has its own root window, which impose complexity.
For now, we just set single global variable:
scr = DefaultScreen(dpy)
, there is alsoScreenCount
debug output from gui.cThe text was updated successfully, but these errors were encountered: