January 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 1/5] wined3d: Regenerate FFP replacement VS on changes to the normal attribute in the vertex declaration.

by Henri Verbeet

On 15 December 2015 at 11:58, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > I signed of on this (117257) a while ago, but notice it's still marked as "Assigned".

Jan. 3, 2016

Re: [PATCH 3/6] d3d11/tests: Add test for SM4 sample_l instruction.

by Henri Verbeet

There seems to be a good amount of overlap between this test and test_texture(). Would it make sense to merge them? Also, I assume you'll add a d3d10core version of the test as well? On 1 January 2016 at 18:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + float miplevel[4] = {0}; A struct vec4 would perhaps be more appropriate. IIRC MSVC gets a bit unhappy about initializing floating-point variables with anything other than floating-point constants, so it would perhaps be better to use 0.0f here. However, ... > + buffer_desc.ByteWidth = sizeof(miplevel); > + buffer_desc.BindFlags = D3D11_BIND_CONSTANT_BUFFER; > + > + resource_data[0].pSysMem = &miplevel; > + > + hr = ID3D11Device_CreateBuffer(device, &buffer_desc, resource_data, &cb); > + ok(SUCCEEDED(hr), "Failed to create constant buffer, hr %#x.\n", hr); ... > + *miplevel = test->miplevel; > + ID3D11DeviceContext_UpdateSubresource(context, (ID3D11Resource *)cb, 0, NULL, miplevel, 0, 0); ... I don't think you should need to pass in initial data in the first place.

Jan. 3, 2016

Re: [PATCH 1/6] wined3d: Add support for buffers in wined3d_device_update_sub_resource().

by Henri Verbeet

On 1 January 2016 at 18:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3989,6 +3989,17 @@ void CDECL wined3d_device_update_sub_resource(struct wined3d_device *device, str > TRACE("device %p, resource %p, sub_resource_idx %u, box %p, data %p, row_pitch %u, depth_pitch %u.\n", > device, resource, sub_resource_idx, box, data, row_pitch, depth_pitch); > > + if (resource->type == WINED3D_RTYPE_BUFFER) > + { > + struct wined3d_buffer *buffer = buffer_from_resource(resource); > + HRESULT hr; > + > + if (FAILED(hr = wined3d_buffer_upload_data(buffer, box, data))) > + WARN("Failed to update buffer data, hr %#x.\n", hr); > + > + return; > + } Are the sub_resource_idx and row_pitch/depth_pitch parameters validated in any way for buffer resources?

Jan. 3, 2016

Re: [resend v2 4/4] ddraw: Do refcounting only through wined3d_texture_{inc, dec}ref().

by Henri Verbeet

On 22 December 2015 at 22:43, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > @@ -1227,6 +1221,7 @@ static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 > struct wined3d_texture *texture; > IDirectDrawSurface7 *current; > struct wined3d_surface *tmp; > + unsigned int tmp_idx; You shouldn't need that. Flippable surfaces aren't supposed to be textures, and only textures should have mip-levels. It should be enough to validate the sub-resource index is 0 and print an ERR if it somehow isn't. I don't think we enforce that DDSCAPS_MIPMAP needs DDSCAPS_TEXTURE. That would be a bug and needs tests. > @@ -6286,8 +6287,10 @@ void ddraw_surface_init(struct ddraw_surface *surface, struct ddraw *ddraw, stru > } > desc->lpSurface = NULL; > > - wined3d_surface_incref(wined3d_surface); > + wined3d_texture_incref(wined3d_texture); > surface->wined3d_surface = wined3d_surface; > + surface->wined3d_texture = wined3d_texture; The reference counting here is odd. You'd normally increment the reference count right before or after storing the pointer. You also store wined3d_surface without increasing the reference count, although that's probably ok because it's protected by the one from the texture. Still, it would probably be nicer to just get rid of the wined3d_surface field first.

Jan. 3, 2016

Re: [PATCH v3] user32: Add MOUSEHOOKSTRUCTEX to fix mouse wheel support for JA2 1.13 and other apps which use it

by Kira Backes

Okay, I've looked at the win10 SDK and made MOUSEHOOKSTRUCTEX compatible with it using DUMMYSTRUCTNAME and submitted a new patch version kind regards, Kira On Wed, Dec 30, 2015 at 5:00 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Kira Backes <kira.backes(a)nrwsoft.de> writes: > >> On Tue, Dec 22, 2015 at 11:32 PM, Kira Backes <kira.backes(a)nrwsoft.de> wrote: >>> Hello @André and @Nikolay, >>> >>> please note that I defined the struct this exact way because of this >>> MSDN article: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms644969%28v=vs.85… >>> >>> So if you think it's a bad idea to follow the definition of the MSDN >>> article then please tell me what I should change so I can improve the >>> patch. >>> >>> kind regards, Kira >>> >>> On Tue, Dec 22, 2015 at 8:13 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >>>> Hello again. >>>> >>>>> +typedef struct >>>>> +{ >>>>> + MOUSEHOOKSTRUCT MOUSEHOOKSTRUCT; >>>>> + DWORD mouseData; >>>>> +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; >>>> >>>> Apparently that's not how Windows SDK defines it. For some obscure >>>> reason they didn't define EX struct simply as non-EX + extra field, >>>> but used cpp style, kind of. Older versions don't even have field name >>>> for MOUSEHOOKSTRUCT portion, only type, but this won't work, not with >>>> gcc at least. SDK 10 uses DUMMYSTRUCTNAME as a field name, which >>>> resolves to 's', if NONAMELESSSTRUCT is defined. I guess we have to >>>> follow version 10 definition. >> >> How should we proceed here? One suggestion that came up was to just >> add the fields of MOUSEHOOKSTRUCT to the ..EX struct, and I'm fine >> with that solution. > > If the latest SDK is using DUMMYSTRUCTNAME that's what we should use > too. > > -- > Alexandre Julliard > julliard(a)winehq.org

Jan. 3, 2016

RE: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes (v2)

by Hugh McMaster

On Saturday, 2 Jan 2016 06:07:14 -0600, Marvin 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 > https://testbot.winehq.org/JobDetails.pl?Key=19336 > > Your paranoid android. > > > === w7u (32 bit msg) === > msg.c:4644: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 > > === w1064 (32 bit msg) === > msg.c:6290: Test failed: Update region shouldn't be empty > msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 > msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 > msg.c:6296: Test failed: Regions are different > msg.c:6296: Test failed: Regions are different > msg.c:6296: Test failed: Regions are different These are all pre-existing failures. -- Hugh McMaster

Jan. 3, 2016

Re: Fedora source packages

by Michael Müller

Am 02.01.2016 um 19:08 schrieb Jeffrey Smith: > One more question: where is the Fedora spec file used for creating the > winehq binary packages. That should be available somewhere, but I > haven't found it. You can find all packaging files at: https://github.com/wine-compholio/wine-packaging (we should change the name of the github team at some point) If you want to generate the build files for all targets: ./generate.py --out some_dir If you also want the script to download all required files (i.e. the wine source code), you can use: ./generate.py --out some_dir --boot Just ignore the created boot.sh file. This file is executed in our build VMs and contains the instructions on how to build packages on this system. For Fedora it basically just tells the VM to install the build dependencies and build the spec file. In case you only want to get the files for fedora, you can use: ./generate.py --out some_dir --skip-name (--boot) \ fedora-any-development The --skip-name parameter prevents the script from creating subdirectories for each distribution. Regards, Michael

Jan. 2, 2016

Shared WoW64 on Mac OS X via Homebrew

by kaazoo

Hello, I modified the existing Homebrew formular for Wine in order to make shared WoW64 (32bit and 64bit Wine together) possible: https://github.com/kaazoo/homebrew/commit/cd0f1db42e0a8228740fce347604d1cfe… The changes are not yet upstream, so you'll need to overwrite /usr/local/Library/Formula/wine.rb with my version. The upcoming LLVM 3.8 release is a dependency for the 64bit build: brew install llvm --with-clang --with-clang-extra-tools --with-compiler-rt --with-libcxx --with-lld --with-rtti --HEAD After that Wine 1.9.0 can be installed via: brew install wine --with-win64 --without-x11 --devel Regards, kaazoo

Jan. 2, 2016

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 7).

by Aaryaman Vasishta

On Sun, Jan 3, 2016 at 2:54 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > This is different from earlier patch versions afair. Whats the reason for > the change? > Using i % 251 didn't give > 256 colors on larger images. So I just came up with a random way of getting it done without needing to use a random number generator. I'll change it to look less awkward though. Cheers, Aaryaman

Jan. 2, 2016

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 7).

by Stefan Dösinger

> Am 02.01.2016 um 07:24 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + size = w * h * (bpp / 8); > + /* Saving pixels by directly accessing bitmap buffer is faster than using SetPixel */ > + for (i = 0, j = 0; i < size;) > + { > + if (palettized) > + { > + buffer[i++] = j; > + buffer[i++] = j; > + buffer[i++] = j++; > + j %= 256; > + } > + else > + { > + buffer[i] = i % 256; > + i++; > + buffer[i] = j % 256; > + i++; > + j = (j % w) + 1; > + } > + } This is different from earlier patch versions afair. Whats the reason for the change? I guess this gets the job done, but it feels a bit odd to initialize 2/3rds of a rgb pixel or 3 palletized pixels per iteration. It can also cause trouble with writing past the end if size isn't a multiple of 2 or 3 respectively. (with 24 bit rgb even a multiple of 2 isn't guaranteed) Also I think you can get rid of the DIB section and just use a HeapAlloced blob.

Jan. 2, 2016