Jim Henderson posted on Fri, 15 Aug 2014 17:56:23 +0000 as excerpted: > Running 0.140 git d447f7c built locally. > > I've just upgraded to a new system and have dual monitors - they're > arranged as follows (output taken from xrandr, unnecessary lines > removed): > > Screen 0: minimum 320 x 200, current 3840 x 2174, maximum 16384 x 16384 > > DFP5 connected primary 2560x1440+0+0 CRT1 connected 1280x1024+2560+1150 > > So my main WHQD display is to the left and slightly above the CRT. > > The preferences window spans both monitors, but because the virtual > screen is 3840x2174, the bottom of the preferences window is off the > bottom of the screen, and the OK button appears on the secondary display > near the bottom of its space. > > This makes the window almost entirely unviewable - it's simply too big > to use effectively. The shortcuts end up going past the bottom of the > left- hand screen, so I can't edit the ones that are at the bottom of > the list unless I drag the window over to the right-hand monitor, but > then the top of the window is off the top of the right-hand screen, so I > have to drag it back and forth.
Welcome to the modern multi-monitor world. =:^) Two answers here, one pan-specific, one a general observation based on long-time multi-monitor experience as I've been running multiple monitors on my main machine since back before the turn of the century on MS. I still remember adding in a second one, then a third one, shortly after MS Windows 98 first introduced multi-monitor feature support, and in fact one of the big deal factors in my switch to Linux back in 2001 was figuring out how to get then XFree86 configured not just to support multiple monitors on multiple graphics cards but to get the layout the way I wanted it -- it wasn't so easy back then and I had a lot of learning about manual configuration to do before I got it working. But I did! =:^) First the pan specific answer. As I've long had this configured I forgot it was a problem and indeed didn't know it still was, but I guess so since it seems to be the issue you're dealing with now, and indeed, I just adjusted my configuration not to match and got the huge pan-prefs once again when I tested, so it does still seem to be a problem. I'm not sure what desktop environment and window manager you run, but here it's kde and kwin, which are of course hugely configurable. Of course kwin's window rules have all sorts of options to limit what's matched (a full tab full) to either all windows of a specific app or a specific window, and there's even more options (three tabs worth) on what behavior to either apply initially or force, for anything that matches. What I ended up doing is setting up a kwin window rule that exact-matches (whole) window class "pan pan", exact-matches window role pan-preferences- dialog, and exact-matches window title Pan: Preferences. That limits that rule to matching /just/ pan-prefs (I have another for the main pan window, FWIW). The only option my rule actually applies to that window is, size and position tab, size, force, 932,800. Which does what I need it to do. =:^) Hopefully whatever window manager you run is equally configurable. As I said, I just tried modifying the rule so it wouldn't match (adding an x to one of the exact-match criteria), and launching pan prefs gave me a *HUGE* window again, so unfortunately I can confirm your problem, as you observed, apparently due to the long list of shortcuts in the shortcuts tab, but the good news is, assuming your window manager is appropriately configurable, there's a confirmed work-around as well -- setup a window rule to enforce the behavior you want. =:^) Meanwhile, here's the more general xorg multi-monitor desktop observation. In general, I've found things work /much/ better if you have access to the full area of the bounding rectangle of your desktop. It's not absolutely necessary, but some windows simply don't behave reasonably and try to ignore the window manager and appear partially or fully offscreen. While it's certainly possible to setup window rules for each one just as I did above, it's generally easier to simply ensure that I can reach all areas of the bounded desktop rectangle. That can be accomplished two ways. Over a longer term and thus thru multiple monitor (and for laptops, full machine since the monitor's built- in) procurement cycles, the easiest way is to simply purchase monitors all of the same resolution in at least one dimension, and either logically stack them or line them up side by side (of course with 4+, you can also 2x2 them, etc), so that the full desktop bounding area is fully displayed. With the advent of digital displays (plasma/lcd/led) TVs and computer monitors are now strongly standardizing on similar resolutions and that becomes far easier. This is what I've done here. Three monitors, all standard full-HD 1920x1080 resolution, in logically stacked config. Two of them are actually a pair of same-model 42-inch (1067 mm) TVs since at that size, the magic of market dynamics prices TVs under monitors-only, despite the additional electronics included. These are my main monitors, mounted on the wall in front of me, one over the other, basically sized as big as I could fit on that wall. The third monitor is a 21-inch (533 mm) monitor from my previous generation. Originally I simply replaced the pair of 21-inch with the pair of 42-inch, but since my graphics card has a third output and I still had the older generation monitor, I decided to buy an appropriate cable (display-port to DVI) and attach it too. It's actually mounted on the side wall beside me, but in ordered to fully display my bounding rectangle, I have it configured as logically stacked on top of the others. Since it's much smaller than the others and mainly serves as my full-monitor system status dashboard[1], such that I don't normally interact with anything on that monitor, the fact that it's logically stacked but physically to the side isn't a big disruption and is actually easier to deal with than would be a bounding rectangle with a missing quadrant, even if I configured panning. Which brings me to full bounding rectangle coverage method #2, panning, which works even without same-size monitors. If you operate at a single primary resolution and don't switch resolutions much, what seems to work best here is constraining panning to one dimension either vertically or horizontally, while making the other a fixed size. In your case, a primarily horizontal layout, you'd make that fixed size and constrain panning to vertical. As a special case of single-dimension panning you can set the desktop's bounding rectangle panned dimension (vertical in this case) to the same size as the largest monitor, so only the lower resolution ones pan. If you would otherwise prefer no panning and are only using it to get full desktop bounding rectangle access, this works reasonably well even for people that find full panning uncomfortable (like motion sickness) and I used it myself for some time. If you want a larger virtual desktop bounding rectangle and don't find full panning uncomfortable or nausea inducing as I used to, of course you can remove the one-dimension restraint and make the desktop as big as you want in both directions, with full panning in each. If you like, you can still constrain the viewports to be "glued together" so they are next to each other in one dimension, or not. While I don't use it with the 42-inch monitors[2], back when I had only the two 21-inch monitors setup, I had xrandr-based zoom-and-panning configured as well. I setup a script and configured hotkeys for it so I could switch to for instance 960x540 per-monitor half-resolution instead of the full 1920x1080, while keeping the 1920x2160 full desktop resolution. Panning was configured such that they panned together vertically, but I could pan them separately horizontally, so while they were always one above the other in the vertical plane, horizontally, they could be one on top of the other as if a single viewport, or on opposite sides of the desktop. Anyway, if you'd like to compare xrandr panning notes or would like a copy of my xrandr script to hack on (some values are still hard-coded and would thus need hacked, which is why I don't use it at all these days as I don't really need it so it hasn't been worth the trouble worrying about, and I already scripted it once so I know how to do it and there's not the challenge of the first time, either), ask, and I can post the script and/or compare notes on the panning stuff as necessary. --- [1] Full-monitor system-status dashboard, superkaramba: Here's a screenshot of the full 1920x3240 desktop, showing the superkaramba dashboard on top, pan on the middle monitor, claws-mail feeds instance and firefox/aurora on the bottom, with translucent windows, etc... http://wstaw.org/m/2013/05/11/duncan-fullscreen.png (I had a full description of each graph in my first draft, but decided that was too much, too far OT. If someone's interested tho, I can post it.) [2] Don't use: While I no longer use xrandr based resolution-zooming and panning, kwin has a similar opengl-based zoom/pan feature which I still use. With the smaller monitors I'd use either kwin/opengl zooming or xrandr/resolution zooming depending on the situation, as resolution zooming wasn't quite as CPU/graphics intensive but of course resulted in larger logical pixels so could look blocky, while opengl based zooming eliminated the blockiness but used more CPU/GPU and could blur. But Mesa/ OpenGL and the in-kernel radeon drm drivers have progressed since then so the CPU/GPU usage isn't a big issue any more, and with the bigger monitors at the same resolution, blockiness is a bigger problem, so kwin's opengl-based zooming tends to be the better option now, and I pretty much only use native resolution these days, only switching to non- native when experimenting or to verify functionality for a post. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
