September 2012 - Wine-Devel

Re: Wine, fullscreen applications, and RandR 1.2

by Andy Ritger

On Wed, Sep 05, 2012 at 11:26:23AM -0700, Henri Verbeet wrote: > On 5 September 2012 18:52, Andy Ritger <aritger(a)nvidia.com> wrote: > > At first glance, I agree that would be easier for applications, but that > > approach has some drawbacks: > > > > * lies to the user/application about what timings are actually being > > driven to the monitor > > * the above bullet causes confusion: the timings reported in the monitor's > > on screen display don't match what is reported by the X server > > * user/application doesn't get complete control over what actual timings > > are being sent to the monitor > > * does not provide the full flexibility of the hardware to configure, > > e.g., arbitrary position of the ViewPortOut within the active raster > > > Perhaps, but none of that changes, as far as Win32 applications are > concerned, if we generate modes in Wine instead of in the kernel. Agreed. > 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? > > I imagine counter arguments include: > > > > * we already have the "scaling mode" output property in most drivers; > > that is good enough > > * Transformation matrix and Border are too low level for most applications > > > > For the first counter argument: I'm trying to make the case that > > providing the full flexibility, and being truthful about modetimings to > > users/applications, is valuable enough to merit a change (hopefully even > > in the drivers that currently expose a "scaling mode" output property). > > > I must say that I'm having some trouble imagining what not generating > standard modes will allow someone to do that they couldn't do before. > In terms of figuring out the "real" timings, the RandR "preferred" > mode is probably close enough, but I suppose it should be fairly easy > to extend RandR to explicitly mark specific modes as "native". I > imagine that for most applications it's just an implementation detail > whether the display panel has a scaler itself, or if that's done by > the GPU though. Either way, that seems like a discussion more > appropriate for e.g. dri-devel. Fair enough; I'll discuss with the other drivers, first. > 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 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. In any case, my impression is that multi-monitor fullscreen gaming is not an uncommon use case. > (Also, uneven numbers > of displays are probably more useful for such a thing than even > numbers of displays.) Agreed. 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? Thanks, - Andy

Sept. 5, 2012

Re: Wine, fullscreen applications, and RandR 1.2

by Henri Verbeet

On 5 September 2012 18:52, Andy Ritger <aritger(a)nvidia.com> wrote: > At first glance, I agree that would be easier for applications, but that > approach has some drawbacks: > > * lies to the user/application about what timings are actually being > driven to the monitor > * the above bullet causes confusion: the timings reported in the monitor's > on screen display don't match what is reported by the X server > * user/application doesn't get complete control over what actual timings > are being sent to the monitor > * does not provide the full flexibility of the hardware to configure, > e.g., arbitrary position of the ViewPortOut within the active raster > Perhaps, but none of that changes, as far as Win32 applications are concerned, if we generate modes in Wine instead of in the kernel. 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. > I imagine counter arguments include: > > * we already have the "scaling mode" output property in most drivers; > that is good enough > * Transformation matrix and Border are too low level for most applications > > For the first counter argument: I'm trying to make the case that > providing the full flexibility, and being truthful about modetimings to > users/applications, is valuable enough to merit a change (hopefully even > in the drivers that currently expose a "scaling mode" output property). > I must say that I'm having some trouble imagining what not generating standard modes will allow someone to do that they couldn't do before. In terms of figuring out the "real" timings, the RandR "preferred" mode is probably close enough, but I suppose it should be fairly easy to extend RandR to explicitly mark specific modes as "native". I imagine that for most applications it's just an implementation detail whether the display panel has a scaler itself, or if that's done by the GPU though. Either way, that seems like a discussion more appropriate for e.g. dri-devel. > When the RandR primary output (as queried/set by RR[SG]etOutputPrimary) > is non-None, then its CRTC will be sorted to the front of the CRTCs > list reported by RRGetScreenResources{,Current}. However, None is a > valid value for the primary output, in which case all bets are off wrt > CRTC/output sorting order in the RRGetScreenResources{,Current} reply. > Yes, as I said this is something we'll probably address at some point. > Further, while RandR primary output seems like a reasonable default, > the spec spells out a focus on window manager (e.g., "primary" is where > the menu bar should be placed). It seems like a valid use case would > be for the user to have his window manager primary output on one monitor, > but run his full screen Wine application on another monitor. Given that, > would it be reasonable for the user to specify the RandR output he wants > Wine to use? > We can probably add an override if there's a lot of demand. It doesn't strike me as a very common use case though. > I can definitely believe that plumbing RandR outputs to multiple objects > in Win32 is not an important/compelling use case, since not many Win32 > applications would do useful things with that. What seems more useful, > though, is driving multiple RandR outputs and presenting that to Win32 as > a single big screen. E.g., "immersive gaming" where your Wine application > spans two, three, or more RandR outputs (NVIDIA Kepler GPUs can have up > to four heads). > 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 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. (Also, uneven numbers of displays are probably more useful for such a thing than even numbers of displays.)

Sept. 5, 2012

Re: Wine, fullscreen applications, and RandR 1.2

by Andy Ritger

Thanks, Henri. On Wed, Sep 05, 2012 at 01:34:47AM -0700, Henri Verbeet wrote: > On 5 September 2012 08:07, Andy Ritger <aritger(a)nvidia.com> wrote: > > Questions: > > > > * Looking at dlls/winex11.drv/xrandr.c, the first RandR CRTC/output's > > modelist is used to populate Wine's list of available modes. Is the > > data flow between Wine and Windows applications always such that you > > need to advertise a list of (width, height, refreshRate)s? Or would > > an application ever tell Wine what resolution it wants? > > > Windows applications use EnumDisplaySettingsEx() to query supported > modes, and ChangeDisplaySettingsEx() to set one. Applications can't > make up modes on their own. Thanks for clarifying. > > * Would you be open to patches to make dlls/winex11.drv/xrandr.c generate > > a larger set of (width, height, refreshRate)s, and then have > > xrandr12_set_current_mode() use RandR transformation matrix and Border > > property to satisfy those? I was envisioning something where we take > > the "preferred" mode for the RandR output, and create all of the > > following resolutions using ViewPort{In,Out}: > > > > 1920 x 1200 > > 1920 x 1080 > > 1600 x 1200 > > 1280 x 1024 > > 1280 x 720 > > 1024 x 768 > > 800 x 600 > > 640 x 480 > > > It's ultimately not up to me whether such a patch would be accepted, > but it's not something I would be particularly happy about. I think > the preferred way to handle this would be to generate the standard DMT > etc. modes in the kernel, and use the "scaling mode" output property > to control the scaling mode, pretty much like all the other drivers. At first glance, I agree that would be easier for applications, but that approach has some drawbacks: * lies to the user/application about what timings are actually being driven to the monitor * the above bullet causes confusion: the timings reported in the monitor's on screen display don't match what is reported by the X server * user/application doesn't get complete control over what actual timings are being sent to the monitor * does not provide the full flexibility of the hardware to configure, e.g., arbitrary position of the ViewPortOut within the active raster I imagine counter arguments include: * we already have the "scaling mode" output property in most drivers; that is good enough * Transformation matrix and Border are too low level for most applications For the first counter argument: I'm trying to make the case that providing the full flexibility, and being truthful about modetimings to users/applications, is valuable enough to merit a change (hopefully even in the drivers that currently expose a "scaling mode" output property). For the second counter argument: maybe the viewport configuration belongs in a library rather than directly in applications like Wine. In that case, I'd like to build a better understanding of Wine's needs so that I could properly design the API to such a library. > > * The current xrandr.c code picks the first CRTC/output, which may not > > be currently active. At the least, it should scan for an active > > CRTC+output. I imagine it would be even better if the user could > > configure which RandR output they want. Would that be reasonable? What > > mechanisms are available in Wine for users to provide runtime configuration? > > > The RandR primary display should be CRTC 0, output 0. That is true most of the time, but I don't believe it is strictly mandated by the RandR specification: http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt When the RandR primary output (as queried/set by RR[SG]etOutputPrimary) is non-None, then its CRTC will be sorted to the front of the CRTCs list reported by RRGetScreenResources{,Current}. However, None is a valid value for the primary output, in which case all bets are off wrt CRTC/output sorting order in the RRGetScreenResources{,Current} reply. Further, while RandR primary output seems like a reasonable default, the spec spells out a focus on window manager (e.g., "primary" is where the menu bar should be placed). It seems like a valid use case would be for the user to have his window manager primary output on one monitor, but run his full screen Wine application on another monitor. Given that, would it be reasonable for the user to specify the RandR output he wants Wine to use? > Users can > typically change this through xrandr or xorg.conf. Unfortunately not > all drivers do something reasonable by default here, so we'll probably > add code to pick the first connected display as Win32 primary instead > if no primary is defined through RandR. For the moment we end up > falling back to the older RandR version though, so at least the > behaviour isn't any worse than before. > > > * From the current code, it does not look like Wine's RandR support tries > > to do anything with multiple simultaneous RandR outputs. > > > Yes, proper multihead support is something we still need to implement. > There aren't a lot of Win32 applications that do something useful with > multiple displays though, so it's not something that has a very high > priority at the moment. I can definitely believe that plumbing RandR outputs to multiple objects in Win32 is not an important/compelling use case, since not many Win32 applications would do useful things with that. What seems more useful, though, is driving multiple RandR outputs and presenting that to Win32 as a single big screen. E.g., "immersive gaming" where your Wine application spans two, three, or more RandR outputs (NVIDIA Kepler GPUs can have up to four heads). > > Ironically: > > this actually works better with RandR 1.1 + NVIDIA: users can configure > > their MetaModes to describe what mode (plus viewport configuration) > > they want on each monitor, and then RandR 1.1 chooses the MetaMode. > > > No. With RandR 1.1 you get one big screen, and you can choose between > getting fullscreen applications stretched across all your displays, or > turning off all displays except one. There were plenty of deficiencies in RandR 1.1 and NVIDIA's implementation of it, but with MetaModes the user could configure whatever combinations of displays he wanted. You are right, though, that any displays not in the MetaMode would get turned off when RandR 1.1 switches to it. > What you actually want is for the > application to be fullscreen on a specific display, or multiple > displays if the application supports that, and leave everything else > alone. I agree that displays not used by Wine should be left alone, not turned off. But you said above that most Win32 applications don't natively take advantage of multiple displays themselves. I expect some users are interested in having their Wine application fullscreen across multiple displays. Does that seem reasonable? > As an aside, the fake refresh rates generated by "DynamicTwinView" > aren't very helpful either. Some Win32 applications expect modes like > 800x600(a)60Hz or 1024x768(a)60Hz to always exist, and just die if they > don't. Yes, the fake refresh rate reporting in DynamicTwinView was unfortunate, but was necessary in RandR to distinguish between MetaModes of the same size. Now that we have RandR 1.2, hopefully we can move past that. Thanks, - Andy

Sept. 5, 2012

Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > @@ -266,7 +266,7 @@ void MergeChmProperties(HH_WINTYPEW *src, HHInfo *info) > if (merge & HHWIN_PARAM_PROPERTIES) dst->fsWinProperties = src->fsWinProperties; > if (merge & HHWIN_PARAM_STYLES) dst->dwStyles = src->dwStyles; > if (merge & HHWIN_PARAM_EXSTYLES) dst->dwExStyles = src->dwExStyles; > - if (merge & HHWIN_PARAM_RECT) dst->rcWindowPos = src->rcWindowPos; > + if (merge & HHWIN_PARAM_RECT || override) dst->rcWindowPos = src->rcWindowPos; > if (merge & HHWIN_PARAM_NAV_WIDTH) dst->iNavWidth = src->iNavWidth; > if (merge & HHWIN_PARAM_SHOWSTATE) dst->nShowState = src->nShowState; > if (merge & HHWIN_PARAM_INFOTYPES) dst->paInfoTypes = src->paInfoTypes; You still need to check the source flags. -- Alexandre Julliard julliard(a)winehq.org

Sept. 5, 2012

Re: Building winetest-latest.exe?

by Francois Gouget

On Tue, 4 Sep 2012, Dan Kegel wrote: > On Tue, Sep 4, 2012 at 3:18 PM, Francois Gouget <fgouget(a)codeweavers.com> wrote: > >> (But as it turns out, the code I needed to fix was in buildbot, > >> not winetest.) > > > > Maybe the WineTestBot code needs a similar fix? > > In testbot/src/TestLauncher/TestLauncher.c? > > Yeah, um, ^buildbot^testbot > I have a patch at > http://bugs.winehq.org/show_bug.cgi?id=31609 > for your review. Sorry about that. I forgot about you other email when replying to this one. From the bug report (so others may comment): You're calling the functions directly instead of using the function pointers. Also it might be worth splitting the patch in two parts: one to introduce the 'goto done' which I feel is worth it on its own and the other for the activation context stuff. But then others might say this is overkill. Otherwise I can't test the patch right now but it looks good. -- Francois Gouget <fgouget(a)codeweavers.com>,

Sept. 5, 2012

Re: Wine, fullscreen applications, and RandR 1.2

by Henri Verbeet

On 5 September 2012 08:07, Andy Ritger <aritger(a)nvidia.com> wrote: > Questions: > > * Looking at dlls/winex11.drv/xrandr.c, the first RandR CRTC/output's > modelist is used to populate Wine's list of available modes. Is the > data flow between Wine and Windows applications always such that you > need to advertise a list of (width, height, refreshRate)s? Or would > an application ever tell Wine what resolution it wants? > Windows applications use EnumDisplaySettingsEx() to query supported modes, and ChangeDisplaySettingsEx() to set one. Applications can't make up modes on their own. > * Would you be open to patches to make dlls/winex11.drv/xrandr.c generate > a larger set of (width, height, refreshRate)s, and then have > xrandr12_set_current_mode() use RandR transformation matrix and Border > property to satisfy those? I was envisioning something where we take > the "preferred" mode for the RandR output, and create all of the > following resolutions using ViewPort{In,Out}: > > 1920 x 1200 > 1920 x 1080 > 1600 x 1200 > 1280 x 1024 > 1280 x 720 > 1024 x 768 > 800 x 600 > 640 x 480 > It's ultimately not up to me whether such a patch would be accepted, but it's not something I would be particularly happy about. I think the preferred way to handle this would be to generate the standard DMT etc. modes in the kernel, and use the "scaling mode" output property to control the scaling mode, pretty much like all the other drivers. > * The current xrandr.c code picks the first CRTC/output, which may not > be currently active. At the least, it should scan for an active > CRTC+output. I imagine it would be even better if the user could > configure which RandR output they want. Would that be reasonable? What > mechanisms are available in Wine for users to provide runtime configuration? > The RandR primary display should be CRTC 0, output 0. Users can typically change this through xrandr or xorg.conf. Unfortunately not all drivers do something reasonable by default here, so we'll probably add code to pick the first connected display as Win32 primary instead if no primary is defined through RandR. For the moment we end up falling back to the older RandR version though, so at least the behaviour isn't any worse than before. > * From the current code, it does not look like Wine's RandR support tries > to do anything with multiple simultaneous RandR outputs. > Yes, proper multihead support is something we still need to implement. There aren't a lot of Win32 applications that do something useful with multiple displays though, so it's not something that has a very high priority at the moment. > Ironically: > this actually works better with RandR 1.1 + NVIDIA: users can configure > their MetaModes to describe what mode (plus viewport configuration) > they want on each monitor, and then RandR 1.1 chooses the MetaMode. > No. With RandR 1.1 you get one big screen, and you can choose between getting fullscreen applications stretched across all your displays, or turning off all displays except one. What you actually want is for the application to be fullscreen on a specific display, or multiple displays if the application supports that, and leave everything else alone. As an aside, the fake refresh rates generated by "DynamicTwinView" aren't very helpful either. Some Win32 applications expect modes like 800x600(a)60Hz or 1024x768(a)60Hz to always exist, and just die if they don't.

Sept. 5, 2012

Re: d3dx9_36 [try 4 ]: Implement D3DXSHRotate

by Rico Schüller

On 05.09.2012 08:02, Nozomi Kodama wrote: + out[15] = -0.9682458639f * in[13] + 0.25f * in[15]; ! You didn't find all trailing white spaces. I made a !, so it could be seen. You could easily get around that by changing your editors preference. Most editors are able to remove that automatically (see e.g. for vim http://vim.wikia.com/wiki/Remove_unwanted_spaces) You may also have a look at http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 . Both are really easy to use. Be warned, that's not the only occurrence, so please look carefully if you remove them by hand. What you get from a comment to a patch are only hints. But you may check for all mentioned hints to the specific patch (even to previous tries), if you have fulfilled them or you may add a comment why you think the hint is bad. If you don't understand a hint, please ask - before sending another try, sometimes the hints could be wrong and sometimes they are worth to think about it. That's all I have to say, there won't be any more comments from my side to this patch. I need my time to get my own screwed up patches into wine. :-) Cheers Rico

Sept. 5, 2012

Wine, fullscreen applications, and RandR 1.2

by Andy Ritger

Hello wine developers, I work on NVIDIA's Linux graphics driver team, and have a few questions about how Wine should interact with X driver mode lists. Sorry if this isn't the correct forum for these questions. Starting in release 302.xx, we finally added RandR 1.2 support to NVIDIA's X driver. At the same time, we reworked some things about how modetimings are validated and configured by the NVIDIA X driver. For the following, the important part is that we eliminated implicit flat panel scaling, and instead made it explicitly configurability through NVIDIA's MetaMode syntax and through RandR 1.2. The user-visible change is that only modes reported by a digital flat panel's EDID are in the mode list for an RandR output. A little background: modern GPUs (at least NVIDIA, and I expect other vendors) have a flexible display scaling pipeline that consists of: * A "RasterSize": this is the resolution of pixels that will be sent to the monitor; this is what people normally think of as the size of the "mode". * A "ViewPortIn": this is the resolution of pixels that the display engine will fetch from the X screen. * A "ViewPortOut": this is the region _within_ the RasterSize to which the pixels of ViewPortIn should be sent. The pixels fetched in ViewPortIn can be scaled up or down by specifying different sizes for ViewPortIn and ViewPortOut. Also, letterboxing and overscan compensation can be configured by making ViewPortOut smaller than RasterSize. For example, if your monitor accepts a mode of 1920x1200, and you want a desktop resolution of 1280x720 aspect-scaled to fill 1920x1200 (i.e., 1280x720 scaled to 1920x1080, with 60 blank scanlines above and below it in a 1920x1200 mode), then in NVIDIA MetaMode syntax you could do: "1920x1200 { ViewPortIn = 1280x720, ViewPortOut = 1920x1080+0+60 }" While the MetaMode syntax is NVIDIA-specific, the same can be configured through RandR: * The RandR transformation matrix can be used to describe the scaling between ViewPortOut and ViewPortIn. * The RandR "Border" output property can be used, when available, to describe a ViewPortOut that is smaller than the RasterSize. Note: most RandR X drivers, including NVIDIA, don't yet provide this property, though I'm in the process of adding it for NVIDIA. In practice this means that most resolutions (i.e., not just a fixed modelist), from the perspective of desktop size, are achievable with RandR. Questions: * Looking at dlls/winex11.drv/xrandr.c, the first RandR CRTC/output's modelist is used to populate Wine's list of available modes. Is the data flow between Wine and Windows applications always such that you need to advertise a list of (width, height, refreshRate)s? Or would an application ever tell Wine what resolution it wants? * Would you be open to patches to make dlls/winex11.drv/xrandr.c generate a larger set of (width, height, refreshRate)s, and then have xrandr12_set_current_mode() use RandR transformation matrix and Border property to satisfy those? I was envisioning something where we take the "preferred" mode for the RandR output, and create all of the following resolutions using ViewPort{In,Out}: 1920 x 1200 1920 x 1080 1600 x 1200 1280 x 1024 1280 x 720 1024 x 768 800 x 600 640 x 480 * The current xrandr.c code picks the first CRTC/output, which may not be currently active. At the least, it should scan for an active CRTC+output. I imagine it would be even better if the user could configure which RandR output they want. Would that be reasonable? What mechanisms are available in Wine for users to provide runtime configuration? * From the current code, it does not look like Wine's RandR support tries to do anything with multiple simultaneous RandR outputs. Ironically: this actually works better with RandR 1.1 + NVIDIA: users can configure their MetaModes to describe what mode (plus viewport configuration) they want on each monitor, and then RandR 1.1 chooses the MetaMode. Would it make sense for the user to be able to specify to Wine the RandR configuration (spanning all of the RandR outputs on the X screen)? I guess that depends on what runtime configuration mechanisms are possible. I'm curious what you guys think, before I code up any patches to propose. Thanks, - Andy Ritger

Sept. 5, 2012

Re: [PATCH 1/3] [cmd] "PATH=value" fails whereas "PATH value" works

by Ann and Jason Edmeades

> > > === WVISTAADM (32 bit) === > Failure running script in VM: The specified guest user must be logged in > interactively to perform this operation > I dont think this is related to my patch, especially when the tests run and pass on patch 2

Sept. 4, 2012

Re: [PATCH 1/3] [cmd] "PATH=value" fails whereas "PATH value" works

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=21386 Your paranoid android. === WVISTAADM (32 bit) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Sept. 4, 2012