November 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 2/6] appwiz.cpl: Add Catalan translation

by André Hentschel

Am 30.11.2011 08:39, schrieb Alex Henrie: > --- > dlls/appwiz.cpl/Ca.rc | 85 +++++++++++++++++++++++++++++++++++++++++++ > dlls/appwiz.cpl/Makefile.in | 1 + > 2 files changed, 86 insertions(+), 0 deletions(-) > create mode 100644 dlls/appwiz.cpl/Ca.rc > > diff --git a/dlls/appwiz.cpl/Ca.rc b/dlls/appwiz.cpl/Ca.rc > new file mode 100644 > index 0000000..e411bf0 > --- /dev/null > +++ b/dlls/appwiz.cpl/Ca.rc > @@ -0,0 +1,85 @@ > +/* > +* Add/Remove Programs English resources > +* > +* Copyright 2001-2002, 2008 Owen Rudge > +* Copyright 2005-2006 Jacek Caban really? :) -- Best Regards, André Hentschel

Nov. 30, 2011

Re: [PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.

by Stefan Dösinger

Am Dienstag, 29. November 2011, 12:40:42 schrieb Henri Verbeet: > Oh, I completely forgot this quartz driver we have in Wine is really > just a quick hack on top of the X11 driver. I must have been wrong > about this code quality crap all along, feel free to add any hacks you > like, as long as it makes something work for someone. > > These are of course not nearly the same thing. I think I've explained > my position well enough, feel free to ignore or misinterpret at your > own risk. Yeah, I guess the opinions have been expressed and we'll have to agree to disagree on the amount of effort we're willing to spend to work properly on OSX and other drivers. I'll keep pointing out when a specific patch will break a specific configuration, and then I guess it's up to Alexandre to voice his opinion. Or, if he doesn't have one, I'll yield to you since you're far more active at the moment. Although I think it's a good idea to have somewhat of an agreement project- wide. With Coreaudio, disk arbitration for mountmgr.sys, a OSX schannel backend and wineqtdecoder a considerable amount of work has been done for this system. It would be a pity if that goes to waste because of oppinion differences. It might at least be a good flamewar subject for the next Wineconf.

Nov. 30, 2011

Re: [PATCH 3/5] ddraw: Keep the primary surface mapped at the same address for early ddraw versions.

by Stefan Dösinger

Am Mittwoch, 30. November 2011, 06:01:46 schrieb Henri Verbeet: > + if (flags & WINED3D_SURFACE_PIN_SYSMEM) > + surface->flags |= SFLAG_PIN_SYSMEM; The address will still change when GetDC is called. Is this intentional? > + /* Some applications assume that the primary surface will always be > + * mapped at the same address. Some of those also assume that this > + * address is valid even when the surface isn't mapped, and that > + * updates done this way will be visible on the screen. The game Nox > + * is such an application. */ I've seen ddraw applications that create systemmem primaries, and we currently allow this. What surface caps does Nox use? Does Nox expect us to magically pick up the new data, or does it map and unmap the surface to get the data onto the screen?

Nov. 30, 2011

Re: [PATCH 2/4] jscript: Use bytecode for delete on array expression implementation

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=15711 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

Nov. 30, 2011

Re: [PATCH 1/5] ddraw: Resize the swapchain window on mode changes in exclusive mode.

by Henri Verbeet

On 30 November 2011 06:11, Marvin <testbot(a)testbot.winehq.org> wrote: > === WVISTAADM (32 bit d3d) === > Failure running script in VM: The specified guest user must be logged in interactively to perform this operation > That doesn't look like a failure caused by the (trivial) change in the test.

Nov. 30, 2011

Re: [PATCH 1/5] ddraw: Resize the swapchain window on mode changes in exclusive mode.

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

Nov. 30, 2011

Re: [PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.

by Henri Verbeet

On 29 November 2011 11:47, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Dienstag, 29. November 2011, 06:30:30 schrieb Henri Verbeet: >> The (fairly general) issue is about how >> much we should go out of our way to support features on obscure or >> broken configurations. > Considering that we're willing to write a quartz driver instead of blaming the > OSX X server or maintain the OSS audio backend for various BSDs or support for > gcc 2.9x I'd say the bar for Wine as a whole is quite high. > Oh, I completely forgot this quartz driver we have in Wine is really just a quick hack on top of the X11 driver. I must have been wrong about this code quality crap all along, feel free to add any hacks you like, as long as it makes something work for someone. These are of course not nearly the same thing. I think I've explained my position well enough, feel free to ignore or misinterpret at your own risk.

Nov. 29, 2011

Re: [PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.

by Stefan Dösinger

Am Dienstag, 29. November 2011, 06:30:30 schrieb Henri Verbeet: > The (fairly general) issue is about how > much we should go out of our way to support features on obscure or > broken configurations. Considering that we're willing to write a quartz driver instead of blaming the OSX X server or maintain the OSS audio backend for various BSDs or support for gcc 2.9x I'd say the bar for Wine as a whole is quite high.

Nov. 29, 2011

Re: [PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.

by Henri Verbeet

On 29 November 2011 01:23, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag, 28. November 2011, 22:05:31 schrieb Henri Verbeet: >> That's probably more a case of laziness by the spec writers than a >> real requirement for anything that's in there. I suppose there's >> MESA_texture_signed_rgba for hardware that couldn't possibly support >> either of those extensions. > It's probably because of the implied support for GL_RED and GL_RG textures and > Well yes, writing the spec against e.g. 2.1 would require specifying interactions like that, along the lines of the R/RG formats not being available without ARB_texture_rg. You can't write negative values without disabling color clamping either, so there's somewhat of an interaction with ARB_color_buffer_float as well. But that's all more on the level of "the spec writers couldn't be bothered to specify interactions" than "this can't possibly be implemented without GL3". > MESA_texture_signed_rgba will probably work for r300g. r300g should support EXT_texture_snorm, IIRC. >> We wouldn't demand support, signed textures simply aren't going to be >> supported if the underlying GL implementation doesn't support them. >> Sounds reasonable enough to me. > Which will break many d3d8/9 games that work fine right now. Pixel shader 1 > kinda implies signed texture format support with the texbem instruction. > > However, I must say that fewer games use it than I expected. Out of the games > I checked here, Sims 3 takes the format for granted and has rendering issues > otherwise(texture creation rejected). Trackmania and the settlers 2 remake > check for support and lower graphics quality. C&C3 checks for it, but I see no > negative effect. 3DMark2001 crashes when Pixel Shaders are supported but V8U8 > is not. That's about one third of the d3d8/9 games I checked, the others don't > use signed textures. > Well yeah, if nothing used those formats there wouldn't be much of a point supporting them at all. The (fairly general) issue is about how much we should go out of our way to support features on obscure or broken configurations. There are of course various factors involved there, like e.g. how common such a configuration is or how invasive the workaround would be. I'd argue that if we were adding support for signed textures today, we shouldn't add this kind of workaround just for OS X. Similarly, I think that if this code causes problems because of interactions with other code, getting rid of it is a valid option. > However, it's not clear to me what we'd gain from dropping signed texture > conversion support. Reduced complexity, mostly. > It won't fix blitting from surfaces that need non-complex fixups. E.g. GL_R32F > also needs this. Sure, but we'd just use ARB_texture_swizzle for that if we didn't already have the fixup code for signed formats. (Incidentally, using ARB_texture_swizzle may be slightly better in terms of performance anyway. At least on Radeons you can specify these kinds of swizzles as part of the texture format setup, instead of using up shader instructions.) With those all gone, the only formats that would have fixups would P8 and the YUV formats. Since I don't think you can necessarily texture from YUV formats either, that could then probably be something entirely local to specific blitters.

Nov. 29, 2011

Re: [PATCH 5/5] user32: Implement GetRawInputDeviceInfoW completely on user side. (resend)

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=15692 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

Nov. 29, 2011