Computing desk
< September 28	<< Aug \| September \| Oct >>	September 30 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

September 29

Why does windows not effectively give smart "Multi-monitor" support yet?!?

Okay simple question here, but i'm not sure how complicated the answer is.

Multi-monitor environments have been out for a long time now. It is quite common to find setups that involve 2 monitors, although i know more is also possible. In all this time of multi-monitor PCs, im really surprised at Windows. I use Windows 8.1, and when i have a video game in full screen mode on monitor 1, it will tend to "Shift" over some of my windows so far that they are only half way on Monitor 2, with the other half of the window not being rendered. Also, if i go click something on monitor 2, it forces my game on monitor 1 to stop running until i click its icon again. It effectively has to choke, stop what its doing, and minimize just so a window can gain focus!

Why does fullscreen mode mess up my window placement, and why cant windows be made so that when you click things in monitor 2, a fullscreen game simply "loses focus" (and pause if the programmer of the game makes it that way), just like a windowed game? Am i missing some technical reason why this cant happen? Is there something really special about fullscreen rendering that makes interacting seamlessly with a second monitor impossible?!

Edit: I found this webpage where someone is asking the same question, with no good answer.

216.173.144.188 (talk) 17:25, 29 September 2014 (UTC)[reply]

If you want to know "why," you'll have to ask Microsoft. I can tell you that other popular operating systems (e.g. Linux, OSX) manage multiple displays just fine though... I'm not sure, but I suspect it has to do with the fact that *NIX systems have semi-interchangeable Windowing_systems, while the Windows family of OSs do not. Our article on Multi-monitor systems indicates that the graphics card can also be a limitation in some cases. SemanticMantis (talk) 19:14, 29 September 2014 (UTC)[reply]

Have you run full-screen games on those platforms? I haven't, but I'm not sure it's any less annoying than on Windows. -- BenRG (talk) 22:50, 29 September 2014 (UTC)[reply]

I have run full-screen games on multi-monitor OSX, and used multi-monitor Linux for normal applications, both of which gave me no problems. I think your answer below about weird resolutions was not a problem for me because I had set the games in question to run at the appropriate full-screen resolution for the TV I was using as a secondary display. SemanticMantis (talk) 20:22, 30 September 2014 (UTC)[reply]

Based on your symptoms, I think the game is running at a non-native resolution. When it gets focus, it changes the resolution, which also shrinks that portion of the desktop, and that's why the windows are shifting. Setting it to run at native resolution should fix that problem.

I don't know whether there's any way to prevent a fullscreen game hiding itself (and restoring the desktop) when it loses focus. I think this is a deliberate design feature, as you couldn't see whatever's on the desktop "behind" the game otherwise. When a game runs in full screen it has exclusive access to that screen and its frame buffer, which means that other windows can't appear above it. Even if the system could access the frame buffer to draw the other windows in the first place, they would disappear when the game painted over them or flicker when it swapped buffers.

The best solution is to run the game in windowed mode, which leaves the window manager in control of the display (at some cost to performance, but probably not much). Most games support this natively, though it's not always accessible through the GUI—you may have to edit a configuration file or pass a command-line parameter—and you may need a third-party tool to get rid of the window border. Borderless Gaming (latest release here) looks like it might work well, but I have no experience with it. -- BenRG (talk) 22:50, 29 September 2014 (UTC)[reply]

I have only limited experience with multi monitors and Windows (and basically none with *nix) mostly recently on a TV and a seperate monitor (which I've been using for a long time, but most of the time I don't use the second monitor for much, heck sometimes it isn't even on) but while I've found some quirks, I'm not sure I'd agree with Semanticmantis, I have doubts *nix are definitely better in this, just different (i.e. better in some areas, worse in others). For example, while I don't know why the problem described by the OP also occured on native resolutions for Semanticmantis on Windows, my experience is with BenRG, and the problem described by the OP generally only occurs when you're running a nonnative resolution (which I've found on most games is fine except occasionally for UI elements, and sometime preferable to having to reduce graphical settings to the minimal when my computer can't handle it), or more precisely when your game is running at a different resolution to the desktop resolution.

I'm not really sure how *nix avoid this as Semanticmantis suggests they do, I guess they make a different decision on how to handle the desktop resolution change. On Windows, it seems that the windowing manager treats the resolution change of one of the monitors for the full screen game as a normal resolution change so tries to adjust the windows accordingly to fit in with the new paradigm. In particular, in a case where one monitor is at least partially below (or I guess above) another monitor, this sometimes results in windows from the game monitor being pushed in to the other monitor/s as well as windows in the other monitor being pushed down. (There's often no change if the monitor is just to the side, although this may be related the old and new resolutions of gaming monitor and the resolution of the other monitor/s.) You could probably legitimately argue this isn't the best decision since the windows on the full screen game monitor aren't accessible and Windows will nearly always change back to the set desktop resolution when you alt tab out of the game (or quit) so it's better just to keep things as they were. (Although very occasionally you can end up with the monitor desktop resolution not changing back.) I guess the other thing that *nix may handle better is Windows seems to occasionally lose the original window positions when it switches back to the original resolution. I'm not sure why, but I since they are treating the new resolution as the new desktop resolution, I would guess there are design decisions about where the windows should be if their position have changed in the interim (and possibly Windows may get confused about whether they have).

Getting back to the other point with the problem occuring without resolution changes (which with full screen mode, probably includes DPI scaling changes), again Semanticmantis's experience not withstanding, I'm not sure this is common with Windows. It would be interesting to here which applies to the OP. I can't particularly say why it occured to Semanticmantis, as I said, I rarely care so it's possible it happened to me, and it isn't uncommon I use nonnative resolutions. (Other than for performance reasons, it's often necessary for AGS games and I never be able to decide if my GPU or TV scaling is better.) One factor may be there's often difference between DX10/11, DX9 and OpenGL. Also some games may use fullscreen windows without telling you (although as per BenRG's point, this should generally be better not worse) and some games let you select such options. Plus the multitude of possible hardware config, compatibility options etc mean that I'm sure Semanticmantis is right and it did occur without resolution changes for them. But it's also difficult to say why. (In terms of why *nix handles this better, well they obviously have a lot less games than Windows. And as I understand it, the way stuff like Wine and other such compatibility layers and also hardware interactions work on *nix os often more standardised compared to Windows, particularly when it comes to the legacy stuff on Windows.)

Speaking of different quirks, I know Windows 8.1 handles per monitor DPI scaling although I'm not sure how well applications, even Microsoft ones support it. (Windows of course has had some degree of DPI awareness since XP or before, albeit with very few applications supporting it, even Microsoft ones until Vista. Heck Firefox and Chrome either still didn't ave proper DPI support last time I checked about a year or so ago, although the sudden rise of high DPI displays, including the Surface etc seemed to finally be providing some impetus. Meanwhile IE had okay support since 8. Vista's new method DPI virtualisations helped at the expense of blurry windows and also some bugs with mouse movement. But as more applications began to say they were DPI aware, but weren't really, things haven't always gotten better and many applications still have spotty support.) I presume Linux has supported some degree of per monitor DPI scaling if you knew what you were doing and had the right stuff, but of specific Linux distros, it sounds like Ubuntu only got it this year [1] so they aren't that far ahead (presuming the native application support is better than Windows). For that matter, it sounds like this is true for Gnome as well Resolution independence. I presume OS X may have had per monitor DPI scaling after they went Retina nuts but didn't find anything with a quick search.

And since we're talking gaming and multi monitor. In PC gaming, even more so in 2009 than now Windows was fairly dominant over OS X and *nix. So AMD Eyefinity and Nvidia Surround were heavilg concentrated on Windows in the early days. Even now, from a quick read I'm not sure how good Linux support is although I think OS X support is okay. Of course that may be reflective of the state of PC gaming.

Nil Einne (talk) 23:24, 3 October 2014 (UTC)[reply]

Suppress tap-to-click on Elan touchpad (Toshiba laptop)

I have a new Toshiba laptop (Satellite C55 series) with a touchpad that is apparently either made by Elan or has an Elan driver. In Ubuntu 14.04 I was able to turn off tap-to-click quite easily, so from a hardware POV I know it can be done.

But I haven't been able to figure out how to turn it off when running Windows 8.1. If I go to Control Panel->Mouse and choose the Elan tab and the "Options" button, I see a list of items and check boxes. However, the "Tapping" item has no check box next to it, just a question mark, that when clicked vouchsafes the information that "One-Finger tapping always performs Point/Click/Select function...".

My takeaway is that, for whatever reason, Elan has chosen to make tap-to-click (possibly the worst idea in the history of pointing interfaces, or at least the worst one that survives to the present day) mandatory.

Has anyone a workaround for this situation? Is there perhaps an alternative to the Elan driver for this hardware? The driver is apparently "ETDWare PS/2_SMBus-X64 11.8.20.3_WHQL". --Trovatore (talk) 18:36, 29 September 2014 (UTC)[reply]

Try setting HKEY_CURRENT_USER\Software\Elantech\SmartPad\Tap_Enable to 0 and logging out and back in, as suggested here. Or uninstall the Elan touchpad software and see if the default Windows driver has the option, as suggested here. -- BenRG (talk) 20:52, 29 September 2014 (UTC)[reply]

Thanks much! I'll try the regkey idea, I think. The second suggestion sort of sounds as though it worked by accident (Windows found a different version of the Elan driver somewhere, or something like that, and it was three years ago). I don't know whether I would be able to get the driver re-installed if Windows didn't come up with a usable default. (Risk is somewhat limited because I mostly use Linux, but still, it's convenient to have Windows around for certain things.) --Trovatore (talk) 21:23, 29 September 2014 (UTC)[reply]

Excellent! The regkey worked. Thanks, Ben. --Trovatore (talk) 21:30, 29 September 2014 (UTC)[reply]

Resolved

(By the way, I have pinged Elan Microelectronics' customer service about this rather horrible decision-or-bug as the case may be. Who knows whether the complaint will get escalated to the right people, or whether it will be taken seriously. But if enough people complain about it, perhaps something will be done.) --Trovatore (talk) 21:37, 29 September 2014 (UTC)[reply]

Invalid process attach attempt

I just had an invalid process attach attempt on my Windows 8.1 computer, so after things restarted normally, I searched for the phrase and understand it well enough to know what's happened. I don't know, however, if we have an article that discusses this kind of situation. Is there something for which invalid process attach attempt would be a good redirect? Nyttend (talk) 22:38, 29 September 2014 (UTC)[reply]

It could redirect to Blue Screen of Death, but it's just one of many bug check codes, and a rare one at that. There's probably nothing useful you could say about it in Wikipedia except "if you figure out which kernel module caused the error and report it to the author of that module, it might help them to fix the bug." -- BenRG (talk) 23:30, 29 September 2014 (UTC)[reply]