1 |
On Mon, 30 Dec 2013, Duncan wrote: |
2 |
|
3 |
> First to address randr. I believe a lot there depends upon the |
4 |
> flexibility and configurability of your window manager. I qualify the |
5 |
> claim with "I believe", because I've not run anything but kwin for |
6 |
> quite some time, so I actually don't know how flexible/configurable |
7 |
> other WMs are, but what I DO know is how well kwin works for me in |
8 |
> this regard. =:^) |
9 |
|
10 |
I did read about a window manager called Awesome that's supposed to be |
11 |
more multihead-aware than any other, including specific support for |
12 |
Zaphod mode (if you can get your card's video driver to do it at all). |
13 |
|
14 |
> (cli/ncurses/qt4). If the switch to kde frameworks 5 with qt5 is |
15 |
> anything like the kde4 upgrade, they'll probably lose me for the |
16 |
> desktop too, but so far signs are good that they've seen some sense |
17 |
> and don't intend to go thru /that/ again.) |
18 |
|
19 |
That's a great example of the sort of thing I was ranting about -- the |
20 |
KDE developers decided nobody really likes KDE as we knew it and decided |
21 |
to give us a whole new product. They even put us through five or six |
22 |
releases of beta quality software while they tried to stabilize the new |
23 |
desktop that we never asked for. I never posted a rant about that |
24 |
before though because on Unix, if you don't like a desktop, don't run |
25 |
it. If you start taking away basic features of X11 though, that's |
26 |
really annoying, which is why the Zaphod and Wayland issues bother me |
27 |
much more. |
28 |
|
29 |
> So anyway, at least kwin can be configured to see the entire desktop |
30 |
> as a single "screen" (USE=-xinerama for qt-gui), or to treat each one |
31 |
> separately (USE=xinerama). When kwin is in separate screens mode, |
32 |
> which is what I use, full-screen and maximizing work to just the |
33 |
> single randr monitor (formerly xinerama/X screen) and the default |
34 |
> smart-window- placement can be set to either put windows on the |
35 |
> "active" screen as defined by where the mouse pointer is, or as |
36 |
> defined by the parent or active window. (I use pointer-active since |
37 |
> it allows me to for instance click a link and quickly point at a |
38 |
> different monitor if I want firefox to open there instead.) |
39 |
|
40 |
That brings up an interesting possibility: Since I'd heard everywhere |
41 |
that basically RandR has supplanted Xinerama, I have my system compiled |
42 |
globally with USE=-xinerama. Does this mean that if I turn USE=xinerama |
43 |
on, I may be able to get window placement to behave? I'm still facing |
44 |
driver issues with the open source radeon driver, but this could at |
45 |
least be an answer to the window/desktop management problem (e.g., |
46 |
maximizing windows fullscreen to just one monitor). |
47 |
|
48 |
> There's an old DOS-based game (Master of Orion, original, now 20 years |
49 |
> old... and the only non-freedomware app I still run) I run in dosbox, |
50 |
> that I have set very specifically not only to size, but to position, |
51 |
> so it always opens up in the same place on the same monitor, basically |
52 |
> so the game is full monitor height, but not full monitor width as that |
53 |
> would distort it. I also have that particular window set to no-border |
54 |
> since that would only be a distraction, but it's also possible to keep |
55 |
> the title bar but force position and size such that only the titlebar |
56 |
> appears on one screen, while the game in the client window appears |
57 |
> vertically maximized in the screen below, and sometimes when I'm |
58 |
> tweaking things, I'll switch it to that mode so I can see the |
59 |
> parameters dosbox puts in the titlebar, without losing the full-height |
60 |
> game display. |
61 |
|
62 |
Yes, this is the type of configuration tricks I'm going to have to start |
63 |
learning a lot of I think. Having two monitors is nice, but it's going |
64 |
to make life complicated. :) |
65 |
|
66 |
> There's two that I know of. Which one you choose will depend on your |
67 |
> needs and neither one is exactly like single-X-session zaphod mode as |
68 |
> both involve multiple X sessions, but with some tweaking, hopefully |
69 |
> one or the other will do what you want. |
70 |
|
71 |
I have a feeling I'm probably just going with RandR, just because that's |
72 |
the direction the wind is blowing. You can only fight upstream for so |
73 |
long. |
74 |
|
75 |
> 1) Xorg can handle multiple X sessions on the same hardware, each |
76 |
> using its own VT. This is sometimes referred to as |
77 |
> fast-user-switching, particularly when it's handled via GUI at the XDM |
78 |
> login level, but the same thing can be done using CLI login and |
79 |
> running startx multiple times, as the same user or different users. |
80 |
> I actually do this accidentally on occasion if I forget that I already |
81 |
> have an X session running, which is how I know it works, but a script |
82 |
> that sets the XSESSION variable and switches out a few other things |
83 |
> appropriately would be easily setup. |
84 |
|
85 |
I've thought about doing this too... The fast user switching applets |
86 |
all assume you want to switch between two X servers on the same monitor. |
87 |
If I go this route, I'd imagine it will be more like just using |
88 |
Ctrl-Alt-F<n> to switch the mouse and keyboard back and forth between |
89 |
two monitors. |
90 |
|
91 |
> 2) It's also possible to do "multi-seat X", where each "seat" has its |
92 |
> own entirely separate configuration, each talking to its own graphics |
93 |
> card with its own displays attached and using its own input hardware, |
94 |
> as configured. |
95 |
|
96 |
Yes, that sounds really cool, though that's more than I'm wanting. |
97 |
|
98 |
-- |
99 |
+ Brent A. Busby + "We've all heard that a million monkeys |
100 |
+ Sr. UNIX Systems Admin + banging on a million typewriters will |
101 |
+ University of Chicago + eventually reproduce the entire works of |
102 |
+ James Franck Institute + Shakespeare. Now, thanks to the Internet, |
103 |
+ Materials Research Ctr + we know this is not true." -Robert Wilensky |