September 2012 - Wine-Devel

Re: Wine, fullscreen applications, and RandR 1.2

by Andy Ritger

On Thu, Sep 06, 2012 at 01:05:42AM -0700, Henri Verbeet wrote: > On 5 September 2012 22:45, Andy Ritger <aritger(a)nvidia.com> wrote: > > On Wed, Sep 05, 2012 at 11:26:23AM -0700, Henri Verbeet wrote: > >> From Wine's point of view, we'd just get a bunch of extra code to maintain > >> because nvidia does things differently from everyone else. > > > > Eventually, I hope NVIDIA isn't unique about this approach to viewport > > configuration. The drawbacks aren't NVIDIA-specific. > > > > The concern about added code maintenance to Wine is fair; is that concern > > lessened if the details of viewport configuration are abstracted by a new > > standard library? > > > A little, but adding extra dependencies isn't without its costs > either. You'd also have to wait a fair bit before it ends up in common > distributions. (And that means things like "Debian stable" or "RHEL", > not "Ubuntu & Fedora".) Yes; understood. > >> Perhaps there's a use case for a "big screen" setup, but that too is > >> something that's probably best handled on the RandR / X server level > >> instead of Wine. > > > > I don't think we can have it both ways: > > > > * RandR 1.1 gives you one "big screen" per X screen; the user can > > configure what is within that big screen via NVIDIA's MetaModes. > > > > * RandR 1.2 gives applications control of each individual CRTC/output. > > > > Are you suggesting we go back to something more like RandR 1.1? > > > I imagine you could configure things in e.g. xorg.conf so that the > displays show up as a single CRTC / output instead of individual > CRTCs, perhaps depending on how the MetaModes are setup. Or perhaps > there's some way to make this fit it with some of the new > functionality in RandR 1.5. The main point though is that there's no > reasonable way for Wine to decide to do one or the other > automatically. We could of course add a configuration option for that, > but at that point it makes more sense to do it globally for all > applications in RandR or the X server. RandR 1.2+ intentionally gives control of the individual CRTCs/outputs to client applications, with the goal of moving display configuration policy out of the X server. But I agree it is a burden for every fullscreen application to have to decide for itself how to configure the available CRTCs/outputs. Here again maybe some helper library can help bridge the gap. > >> I don't think you can actually do "immersive gaming" > >> properly without support from the application though, you'll get > >> fairly significant distortion at the edges if you just render to such > >> a setup as if it was a single very wide display. > > > > I'm sorry; I don't understand the distortion concern. Are you referring > > to the bezel of the monitor occupying physical space, but not pixel space > > in the X screen? I believe people often address that by configuring > > "dead space" in the X screen between their monitors. > > > No, I mean the distortion caused by perspective projection, because > you're essentially projecting a spherical "world" onto a flat screen. > An application that is aware of this could e.g. use a separate camera > for each display to mitigate this, or perhaps adjust the projection > matrix. Maybe there is a distortion concern in theory (though it may depend on whether the monitors are all in the same plane or tilted to "wrap around" the user), but in practice it seems to normally work out well enough. I suppose maybe users use side displays for peripheral vision, and then move their viewport such that the content they care about is in the center display. In any case, there is an enthusiast community around immersive gaming; e.g., http://www.nvidia.com/object/3d-vision-surround-technology.html In those cases, the content across the monitors is rendered as one big screen, rather than rendered separately per display with different view frustums. With RandR 1.1 + NVIDIA MetaModes, users could achieve that sort of configuration with Wine. They can't really do that now with Wine and RandR 1.2. > > Since we have some differing viewpoints that won't be quickly resolved, > > how about as a compromise we add a way for users to force Wine from > > RandR 1.2 back to RandR 1.1? That would at least let users achieve > > some of the configurations they cannot configure with top of tree. > > If that seems fair, what is the preferred configuration mechanism to > > do that? Just a simple environment variable? > > > You could perhaps extend the existing "UseXRandR" registry setting > (see dlls/winex11.drv/x11drv_main.c) to take a version number. It's > not something we've heard a lot of users about though. Sounds good; I'll look into that. Thanks, - Andy

Sept. 7, 2012

Re: [PATCH 6/9] mshtml: Use first script host's GUID as default script guid

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > dlls/mshtml/htmlwindow.c | 1 - > dlls/mshtml/mshtml_private.h | 1 - > dlls/mshtml/script.c | 18 ++++++++++-------- > dlls/mshtml/tests/vbtest.html | 15 +++++++++++++-- > 4 files changed, 23 insertions(+), 12 deletions(-) It doesn't work here on 64-bit: ../../../../wine/tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so ../../../../wine/dlls/mshtml/tests/script.c && touch script.ok script.c:620: Test failed: L"got an exception" script.c:620: Test failed: L"counter = 3" make: *** [script.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2012

Re: [2/5] vcomp: add better stub for _vcomp_fork (resend)

by Dan Kegel

On Fri, Sep 7, 2012 at 7:21 AM, Dan Kegel <dank(a)kegel.com> wrote: > As I mentioned earlier, the testbot can't handle vcomp.dll tests > until a fix for http://bugs.winehq.org/show_bug.cgi?id=31609 > is deployed. > > It can handle vcomp100.dll tests, though (no manifest). I guess I can submit > the series again with the vcomp100 forwarding and tests > in a sixth patch, that would show things are working. > > In my earlier testing with testbot and vcomp100, IIRC, the tests did pass. > But double-checking isn't a bad idea. Here's a run with the current tests: https://testbot.winehq.org/JobDetails.pl?Key=21451 showing them passing on all platforms that have vcomp100 installed. I think I need to resend the patch series without private stuff in omp.h, though, so the tests can build with mingw and native headers. And it might be good for the tests to skip if the dll they need doesn't exist. - Dan

Sept. 7, 2012

Re: [2/5] vcomp: add better stub for _vcomp_fork (resend)

by Dan Kegel

As I mentioned earlier, the testbot can't handle vcomp.dll tests until a fix for http://bugs.winehq.org/show_bug.cgi?id=31609 is deployed. It can handle vcomp100.dll tests, though (no manifest). I guess I can submit the series again with the vcomp100 forwarding and tests in a sixth patch, that would show things are working. In my earlier testing with testbot and vcomp100, IIRC, the tests did pass. But double-checking isn't a bad idea. On Thu, Sep 6, 2012 at 9:14 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=21417 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit main) === > Timeout

Sept. 7, 2012

Re: [PATCH 2/2] user32: Correct class small icons behavior (try 2).

by Sergey Guralnik

On 2012-09-07 15:24, Sergey Guralnik wrote: > This patch based on MSDN's description of WNDCLASSEX structure: ... hIconSm: Handle to a small icon that is associated with the window class. If this member is NULL, the system searches the icon resource specified by the hIcon member for an icon of the appropriate size to use as the small icon. ... -- Sergey

Sept. 7, 2012

Re: [PATCH 9/9] vbscript: Added support for VT_NULL in stack_pop_bool

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21447 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 7, 2012

Re: [PATCH 8/9] vbscript: Added support for comparing to null

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21446 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 7, 2012

Re: [PATCH 7/9] mshtml: Check if value is function only when it needs to be in invoke_builtin_prop

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21445 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 7, 2012

Re: [PATCH 6/9] mshtml: Use first script host's GUID as default script guid

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21444 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 7, 2012

Re: [PATCH 2/2] user32: Correct class small icons behavior.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21433 Your paranoid android. === WINEBUILD (build) === Make failed

Sept. 7, 2012