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

Re: [PATCH 3/5] user32: Implement GetRawInputDeviceList 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=15691 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

Nov. 29, 2011

Re: [PATCH 2/5] user32: Add initial input parameter validations to RawInput functions. (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=15690 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

Nov. 29, 2011

Re: [PATCH 1/5] user32/tests: Initial tests for RawInput functions. (try 2)

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

Nov. 29, 2011

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

by Stefan Dösinger

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 16 bit per channel textures(although GL 1.2 already requires support for that). MESA_texture_signed_rgba will probably work for r300g. WINED3DFMT_R8G8_SNORM_L8X8_UNORM can't be supported with this extension, but I assume that games do not depend on this format. > 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. However, it's not clear to me what we'd gain from dropping signed texture conversion support. Yes, it makes P8 a bit easier because you can ignore the fact that the load-time conversion selection in d3dfmt_get_conv is broken(The entire function is questionable imo. Fixing the color keying parts of it will be harder). If you go the separate RGBA8 surface way you could e.g. move the P8 unpacking to the software blitter and always store P8 surfaces as GL_ALPHA8 and keep them in software if shaders aren't supported. (There's not much point in doing HW blits on older GPUs anyway. Also the unpacked P8 textures are based on a broken design and use e.g. the wrong palette) It won't fix blitting from surfaces that need non-complex fixups. E.g. GL_R32F also needs this. It won't eliminate load-time fixups. The Bumpmap-Luminance formats will still need it.

Nov. 29, 2011

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

by Henri Verbeet

On 28 November 2011 21:37, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> The original NV_texture_shader extension is over 10 years old. > But it has a lot of things beyond signed textures that are specific to Nvidia > hardware. It is unreasonable to expect other vendors to support it. > GL_EXT_texture_snorm requires GL 3.0. 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. > We're on pretty shaky ground if we > demand support for one of those extensions on generic d3d8/9 hardware. 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.

Nov. 28, 2011

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

by Stefan Dösinger

Am Montag, 28. November 2011, 19:00:25 schrieb Henri Verbeet: > I don't suppose you have a link to a public bug tracker for that by any > chance? Unfortunately not, Apple considers such bug reports private. I don't think the efforts to create a public mirror on a voluntary basis went anywhere. > The original NV_texture_shader extension is over 10 years old. But it has a lot of things beyond signed textures that are specific to Nvidia hardware. It is unreasonable to expect other vendors to support it. GL_EXT_texture_snorm requires GL 3.0. We're on pretty shaky ground if we demand support for one of those extensions on generic d3d8/9 hardware.

Nov. 28, 2011

Re: user32: Fix 64-bit 'msg' test hang in test_timers (try 2).

by Erich E. Hoover

On Tue, Nov 22, 2011 at 2:28 PM, Erich E. Hoover <ehoover(a)mines.edu> wrote: > On Mon, Nov 21, 2011 at 10:08 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > ... > > kernel32.RaiseException is just a wrapper around an ntdll one. I'd expect > > the kernel32 API be always available despite what MSDN claims. > > For some reason that causes the crash function to be called twice on > the 64-bit VM, thoughts?: > ... Ok, I've modified the test a little and it appears that on the 64-bit VMs that there is new behavior with the way an exception is handled within a timer routine. A continuable exception will just drop straight back to the timer routine whereas a non-continuable exception will abort the process. Previously both types of exceptions would cause the timer routine to bail. I'm thinking that maybe a "broken()" should be in order, but I would appreciate some feedback before proceeding. https://testbot.winehq.org/JobDetails.pl?Key=15683 Erich Hoover ehoover(a)mines.edu

Nov. 28, 2011

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

by Henri Verbeet

On 28 November 2011 17:57, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > It probably doesn't help that Wine is (partially intentionally, and partially > unintentionally) crippled on this platform and most users have to use third > party tools to use it(which we rightfully don't support). Telling users that > their platform isn't good enough isn't good marketing either, and I doubt that > it makes Apple more likely to be cooperative. > I think Apple's opinion on Free Software and the GPL is pretty well known by now. At this point it's probably about as likely we'll get help from Microsoft as from Apple. >> So it should be easy to convince Apple to implement EXT_texture_snorm, >> right? > I filed a feature request, Bug ID 10490831. The most likely problem is that > this extension requires OpenGL 3.0 on paper. > I don't suppose you have a link to a public bug tracker for that by any chance? >> I don't think it's unreasonable to require some features from >> the underlying OS when you want certain features to work in Wine. It >> certainly works like that for the BSDs and OpenSolaris, and probably >> would for e.g. Haiku if they wanted to run Wine as well. I don't see >> why OS X should be different. > Call it hyprocricy from a technical point of view, but I think user numbers > and market share matter. It certainly does on Linux where we spend quite some > time debugging and working around troubles various distros cause. > It's probably a good thing that Wine doesn't have a lot of OS X users then. I suspect "various distros" above means "mostly Ubuntu". While I don't necessarily always agree with those kinds of workarounds either, it's certainly not on the level of the amount of hacks we have for OS X in CrossOver. >> Yeah well, hacking something together is easy. Doing it properly you >> should also be able to blit to those formats, render to them (you can >> render to e.g. Q8W8V8U8 even in d3d9, d3d10 can render to all kinds of >> formats), read them back, and probably do clears on them. > My DirectX9 GPUs can't render to Q8W8V8U8. Blitting from those formats is > easy, it's not implemented because no app needed it yet. Blitting to those > formats is harder, but requires render target support. I'm fine with not > supporting d3d10 features without this specific extension or GL 3.0-level > driver support. But I think it's a bad idea to disable d3d8 support because a > driver doesn't support some GL 3.0 extension. > The original NV_texture_shader extension is over 10 years old.

Nov. 28, 2011

Re: [1/2] kernel32: Add a test for protections accepted by CreateFileMapping, make it pass under Wine.

by Dmitry Timoshkov

Francois Gouget <fgouget(a)free.fr> wrote: > Heer is the adjusted patch and corresponding log (still on Windows > Millenium). > virtual.c:1744: Test failed: 0: CreateFileMapping should fail > virtual.c:1745: Test failed: 0: expected ERROR_INVALID_PARAMETER, got 0 Thanks. Apparently CreateFileMapping never fails under Win9x, but Wine has a workaround only for protect == 0 at the moment, and there are not much complaints about that. I'll add a workaround for the test with protect = 0 being running with emulated version set to win9x, hopefully that will be enough. Thanks once again. -- Dmitry.

Nov. 28, 2011

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

by Stefan Dösinger

Am Montag, 28. November 2011, 15:21:11 schrieb Henri Verbeet: > My point was pretty much that I care only marginally about that > argument. Nevertheless, I'm not all that convinced that Wine even has > a lot of OS X users. If it does, that's certainly not reflected in the > number of active developers It probably doesn't help that Wine is (partially intentionally, and partially unintentionally) crippled on this platform and most users have to use third party tools to use it(which we rightfully don't support). Telling users that their platform isn't good enough isn't good marketing either, and I doubt that it makes Apple more likely to be cooperative. > So it should be easy to convince Apple to implement EXT_texture_snorm, > right? I filed a feature request, Bug ID 10490831. The most likely problem is that this extension requires OpenGL 3.0 on paper. > I don't think it's unreasonable to require some features from > the underlying OS when you want certain features to work in Wine. It > certainly works like that for the BSDs and OpenSolaris, and probably > would for e.g. Haiku if they wanted to run Wine as well. I don't see > why OS X should be different. Call it hyprocricy from a technical point of view, but I think user numbers and market share matter. It certainly does on Linux where we spend quite some time debugging and working around troubles various distros cause. > Yeah well, hacking something together is easy. Doing it properly you > should also be able to blit to those formats, render to them (you can > render to e.g. Q8W8V8U8 even in d3d9, d3d10 can render to all kinds of > formats), read them back, and probably do clears on them. My DirectX9 GPUs can't render to Q8W8V8U8. Blitting from those formats is easy, it's not implemented because no app needed it yet. Blitting to those formats is harder, but requires render target support. I'm fine with not supporting d3d10 features without this specific extension or GL 3.0-level driver support. But I think it's a bad idea to disable d3d8 support because a driver doesn't support some GL 3.0 extension.

Nov. 28, 2011