September 2016 - Wine-Devel

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.
by Matteo Bruni Sept. 20, 2016

Sept. 20, 2016

2016-09-13 22:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> It was already mentioned but, at the cost of being annoying, let me reiterate: d3dx* DLLs can't directly use wined3d data types or APIs. They have to go through the respective d3d* client library functions. I suspect that code sharing between d3dx* versions will eventually happen in a somewhat different fashion and trying to build the "final solution" from the ground up is going to be hard. Porting the various pieces of code to d3d[x]11 as necessary, even at the cost of "duplication" in the short term, is probably a better plan.

2 3

Problems with the tooltip controls.
by John Found Sept. 20, 2016

Sept. 20, 2016

In my program I have window with several toolbars that have to show tooltips on its buttons. As long as the tooltips are dynamical, I am handling the TTN_NEEDTEXTW following way: 1. Send message TTM_GETCURRENTTOOLW to the tooltip control in NMHDR.hwndFrom reveived. 2. Determine from which toolbar the notification comes by using TOOLINFO.hwnd returned. 3. Generate the tooltip text and set the TOOLTIPTEXTW.lpszText to point to the generated text. 4. Return This procedure works in Windows, but not in WINE. In WINE, TTM_GETCURRENTTOOLW always returns FALSE. And there is no other way to determine which of the toolbars generated this message. (or at least I don't know it). Any ideas about some workaround? -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

3 6

Re: oleaut32: Handle xbuf_get erroring out in deserialize_param (and avoid uninitialized read).
by Dmitry Timoshkov Sept. 20, 2016

Sept. 20, 2016

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > --- a/dlls/oleaut32/tmarshal.c > +++ b/dlls/oleaut32/tmarshal.c > @@ -1078,7 +1078,10 @@ deserialize_param( > if (readit) { > DWORD x; > hres = xbuf_get(buf,(LPBYTE)&x,sizeof(DWORD)); > - if (hres) ERR("Failed to read integer 4 byte\n"); > + if (hres) { > + ERR("Failed to read integer 4 byte\n"); > + x = 0; > + } > memcpy(arg,&x,2); > } > if (debugout) TRACE_(olerelay)("%04x",*arg & 0xffff); > @@ -1088,7 +1091,10 @@ deserialize_param( > if (readit) { > DWORD x; > hres = xbuf_get(buf,(LPBYTE)&x,sizeof(DWORD)); > - if (hres) ERR("Failed to read integer 4 byte\n"); > + if (hres) { > + ERR("Failed to read integer 4 byte\n"); > + x = 0; > + } > memcpy(arg,&x,1); A proper fix would be to avoid a memcpy() if xbuf_get() fails instead of creating bogus input data. -- Dmitry.

1 0

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading
by Nikolay Sivov Sept. 20, 2016

Sept. 20, 2016

On 13.09.2016 23:11, Fabian Maurer wrote: > +/* temporary defines to not break compilation */ > + > +#define IDirect3DSurface9_GetDesc(p,a) (p)->lpVtbl->GetDesc(p,a) > +#define IDirect3DSurface9_LockRect(p,a,b,c) (p)->lpVtbl->LockRect(p,a,b,c) > +#define IDirect3DSurface9_UnlockRect(p) (p)->lpVtbl->UnlockRect(p) > + ... > +#define INTERFACE IDirect3DSurface9 > +DECLARE_INTERFACE_(IDirect3DSurface9,IDirect3DResource9) I don't think this is acceptable. It should be done in a way that doesn't introduce mess like this.

4 5

Getting backtraces from services without crash dialog
by Austin English Sept. 19, 2016

Sept. 19, 2016

Howdy all, I asked this in #winehackers, but got no reply. I have a program: http://www.cressi.com/software http://www.cressi.com/easyUp/software/CressiPcInterface_2_0_1_37_Installer.… that installs some device drivers that crash when it is starting up. If I have the crash dialog enabled, I can save their backtraces. If I disable it, all I see is something like: wine: Unhandled page fault on write access to 0x0078d000 at address 0x7bc55e7f (thread 00a1), starting debugger... Is there some way for me to get the backtraces to print to a console (either of the first wine process or of the later running programs? If the dialog is enabled, there are several crashes, which makes that inconvenient. Thanks! -- -Austin GPG: 14FB D7EA A041 937B

2 3

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects
by Matteo Bruni Sept. 19, 2016

Sept. 19, 2016

2016-09-14 7:25 GMT+02:00 Bruno Jesus <00cpxxx(a)gmail.com>: > Based on idea by Elias Vanderstuyft. > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/dinput/effect_linuxinput.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Thanks for giving dinput and force feedback some love and care lately. I'm going to be a nag though... > diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c > index 9205c9c..bb45792 100644 > --- a/dlls/dinput/effect_linuxinput.c > +++ b/dlls/dinput/effect_linuxinput.c > @@ -632,7 +632,8 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( > > This->effect.u.periodic.magnitude = (tsp->dwMagnitude / 10) * 32; > This->effect.u.periodic.offset = (tsp->lOffset / 10) * 32; > - This->effect.u.periodic.phase = (tsp->dwPhase / 9) * 8; /* == (/ 36 * 32) */ > + /* phase ranges from 0 - 35999 in dinput and 0 - 65535 on linux */ > + This->effect.u.periodic.phase = (tsp->dwPhase / 36) * 65; Probably I'm missing something but... Why don't you actually use 35999 and 65535 in the expression? Relatedly, why not do the multiplication before the division instead of throwing bits of precision away? Maybe phase can go over 35999? If that's the only reason, I'd adjust the phase before doing this computation instead. I guess these points apply to the other effect parameters too. BTW, you didn't change the corresponding piece of code in GetParameters (which, for some reason, uses 33 and 36 as scaling constants...) so that's probably broken now. Or at least more broken than it was before.

2 3

Re: [PATCH 5/5] d3dx11: Implemented D3DX11CompileFromFileW
by Matteo Bruni Sept. 19, 2016

Sept. 19, 2016

2016-09-13 22:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/d3dx11_43/async.c | 24 ++++++++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3dx11_43/async.c b/dlls/d3dx11_43/async.c > index 90c60fa..1e3042b 100644 > --- a/dlls/d3dx11_43/async.c > +++ b/dlls/d3dx11_43/async.c > @@ -1989,16 +1989,36 @@ HRESULT WINAPI D3DX11CompileFromFileA(const char *filename, const D3D10_SHADER_M > return E_NOTIMPL; > } > > + Stray newline. > HRESULT WINAPI D3DX11CompileFromFileW(const WCHAR *filename, const D3D10_SHADER_MACRO *defines, > ID3D10Include *include, const char *entry_point, const char *target, UINT sflags, UINT eflags, > ID3DX11ThreadPump *pump, ID3D10Blob **shader, ID3D10Blob **error_messages, HRESULT *hresult) > { > - FIXME("filename %s, defines %p, include %p, entry_point %s, target %s, sflags %#x, " > + void *file_buffer; > + HRESULT hr; > + DWORD file_size; > + LPSTR filename_converted; Please use "char *" instead. > + UINT filename_converted_len; Probably you can call it just "size". > + > + TRACE("filename %s, defines %p, include %p, entry_point %s, target %s, sflags %#x, " > "eflags %#x, pump %p, shader %p, error_messages %p, hresult %p stub.\n", The "stub" part should go away. > debugstr_w(filename), defines, include, debugstr_a(entry_point), debugstr_a(target), > sflags, eflags, pump, shader, error_messages, hresult); > > - return E_NOTIMPL; > + if (FAILED(hr = map_view_of_file(filename, &file_buffer, &file_size))) > + return hr; > + > + filename_converted_len = WideCharToMultiByte(CP_ACP, 0, filename, -1, NULL, 0, NULL, NULL); > + filename_converted = HeapAlloc(GetProcessHeap(), 0, filename_converted_len); > + WideCharToMultiByte(CP_ACP, 0, filename, -1, filename_converted, filename_converted_len, NULL, NULL); > + > + hr = D3DX11CompileFromMemory(file_buffer, file_size, filename_converted, defines, include, entry_point, target, > + sflags, eflags, pump, shader, error_messages, hresult); > + > + HeapFree(GetProcessHeap(), 0, filename_converted); > + UnmapViewOfFile(file_buffer); > + > + return hr; > } This would be okay otherwise but, as mentioned for patch [4/5], maybe it's a good idea to implement and make use of D3DX11CreateAsyncFileLoaderW() here too.

2 2

Re: [PATCH 4/5] d3dx11: Implemented D3DX11CreateShaderResourceViewFromFileW
by Nikolay Sivov Sept. 19, 2016

Sept. 19, 2016

On 13.09.2016 23:11, Fabian Maurer wrote: > +HRESULT WINAPI D3DX11CreateShaderResourceViewFromFileW(ID3D11Device *iface, > + WCHAR *filename, D3DX11_IMAGE_LOAD_INFO *load_info_original, ID3DX11ThreadPump *pump, ID3D11ShaderResourceView **view, HRESULT *hresult) > +{ > + D3DX11_IMAGE_LOAD_INFO load_info; > + D3D11_SHADER_RESOURCE_VIEW_DESC desc_view; > + D3D11_TEXTURE2D_DESC desc_texture; > + D3D11_SUBRESOURCE_DATA data_texture; > + ID3D11Texture2D *texture; > + enum wined3d_format_id dst_format; > + UINT dst_pitch; > + D3DXIMAGE_INFO image_info; > + void *file_buffer = NULL; > + DWORD file_size; > + void *image_data = NULL; > + RECT rectSize; > + HRESULT hr; > + > + TRACE("iface %p, filename %s, load_info_original %p, pump %p, view %p, hresult %p.\n", > + iface, debugstr_w(filename), load_info_original, pump, view, hresult); > + > + if (pump) > + FIXME("Unimplemented ID3DX11ThreadPump handling.\n"); Personally I think this function should use D3DX11CreateAsyncFileLoaderW() and D3DX11CreateAsyncShaderResourceViewProcessor() internally, for both async and synchronous cases. This will make support for a thread pump trivial, and will consolidate things like map_view_of_file() in one place.

2 1

Re: [PATCH v2] hid: Stub HidP_TranslateUsagesToI8042ScanCodes
by Sebastian Lackner Sept. 19, 2016

Sept. 19, 2016

On 15.09.2016 14:08, Aric Stewart wrote: > v2: Corrections pointed out by Sebastian Lackner > > Resolves Bug 39447 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hid/hid.spec | 2 +- > dlls/hid/hidp.c | 9 +++++++++ > include/ddk/hidpi.h | 29 +++++++++++++++++++++++++++++ > 3 files changed, 39 insertions(+), 1 deletion(-) > > > > 0003-hid-Stub-HidP_TranslateUsagesToI8042ScanCodes.txt > > > diff --git a/dlls/hid/hid.spec b/dlls/hid/hid.spec > index 4c5e505..2131af2 100644 > --- a/dlls/hid/hid.spec > +++ b/dlls/hid/hid.spec > @@ -39,6 +39,6 @@ > @ stub HidP_SetUsageValue > @ stub HidP_SetUsageValueArray > @ stub HidP_SetUsages > -@ stub HidP_TranslateUsagesToI8042ScanCodes > +@ stdcall HidP_TranslateUsagesToI8042ScanCodes(ptr long long ptr ptr ptr) > @ stub HidP_UnsetUsages > @ stub HidP_UsageListDifference > diff --git a/dlls/hid/hidp.c b/dlls/hid/hidp.c > index 3d7a12e..c7bfb72 100644 > --- a/dlls/hid/hidp.c > +++ b/dlls/hid/hidp.c > @@ -23,6 +23,7 @@ > #include <stdarg.h> > > #define NONAMELESSUNION > +#include "ntstatus.h" > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > @@ -519,3 +520,11 @@ ULONG WINAPI HidP_MaxUsageListLength(HIDP_REPORT_TYPE ReportType, USAGE UsagePag > } > return count; > } > + > +NTSTATUS WINAPI HidP_TranslateUsagesToI8042ScanCodes(USAGE *ChangedUsageList, ULONG UsageListLength, HIDP_KEYBOARD_DIRECTION KeyAction, HIDP_KEYBOARD_MODIFIER_STATE *ModifierState, PHIDP_INSERT_SCANCODES InsertCodesProcedure, VOID *InsertCodesContext) It wouldn't really hurt to split this extremely long line. Also please note that VOID should usually be avoided in new Wine source, but I will leave that up to you since its your area. The same also applies to the function declaration. > +{ > + FIXME("stub: %p, %i, %i, %p, %p, %p\n", ChangedUsageList, UsageListLength, > + KeyAction, ModifierState, InsertCodesProcedure, InsertCodesContext); > + > + return STATUS_NOT_IMPLEMENTED; > +} > diff --git a/include/ddk/hidpi.h b/include/ddk/hidpi.h > index 4cfac61..833387e 100644 > --- a/include/ddk/hidpi.h > +++ b/include/ddk/hidpi.h > @@ -136,6 +136,34 @@ typedef struct _HIDP_CAPS > USHORT NumberFeatureDataIndices; > } HIDP_CAPS, *PHIDP_CAPS; > > +typedef enum _HIDP_KEYBOARD_DIRECTION { > + HidP_Keyboard_Break, > + HidP_Keyboard_Make > +} HIDP_KEYBOARD_DIRECTION; > + > +typedef struct _HIDP_KEYBOARD_MODIFIER_STATE { > + union { > + struct { > + ULONG LeftControl: 1; > + ULONG LeftShift: 1; > + ULONG LeftAlt: 1; > + ULONG LeftGUI: 1; > + ULONG RightControl: 1; > + ULONG RightShift: 1; > + ULONG RightAlt: 1; > + ULONG RigthGUI: 1; > + ULONG CapsLock: 1; > + ULONG ScollLock: 1; > + ULONG NumLock: 1; > + ULONG Reserved: 21; > + } DUMMYSTRUCTNAME; > + ULONG ul; > + } DUMMYUNIONNAME; It looks like you accidentically used three space indentation here. > +} HIDP_KEYBOARD_MODIFIER_STATE, *PHIDP_KEYBOARD_MODIFIER_STATE; > + > +typedef BOOLEAN NTAPI (*PHIDP_INSERT_SCANCODES) (VOID *Context, CHAR *NewScanCodes, ULONG Length); For GCC it does not seem to matter, but usually the NTAPI should be inside of the brackets. > + > + > NTSTATUS WINAPI HidP_GetButtonCaps(HIDP_REPORT_TYPE ReportType, PHIDP_BUTTON_CAPS ButtonCaps, PUSHORT ButtonCapsLength, PHIDP_PREPARSED_DATA PreparsedData); > NTSTATUS WINAPI HidP_GetCaps(PHIDP_PREPARSED_DATA PreparsedData, PHIDP_CAPS Capabilities); > NTSTATUS WINAPI HidP_GetUsages(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, USHORT LinkCollection, PUSAGE UsageList, PULONG UsageLength, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > @@ -144,6 +172,7 @@ NTSTATUS WINAPI HidP_GetValueCaps(HIDP_REPORT_TYPE ReportType, PHIDP_VALUE_CAPS > NTSTATUS WINAPI HidP_InitializeReportForID(HIDP_REPORT_TYPE ReportType, UCHAR ReportID, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > ULONG WINAPI HidP_MaxUsageListLength(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, PHIDP_PREPARSED_DATA PreparsedData); > NTSTATUS WINAPI HidP_GetScaledUsageValue(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, USHORT LinkCollection, USAGE Usage, PLONG UsageValue, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > +NTSTATUS WINAPI HidP_TranslateUsagesToI8042ScanCodes(USAGE *ChangedUsageList, ULONG UsageListLength, HIDP_KEYBOARD_DIRECTION KeyAction, HIDP_KEYBOARD_MODIFIER_STATE *ModifierState, PHIDP_INSERT_SCANCODES InsertCodesProcedure, VOID *InsertCodesContext); > > #ifndef FACILITY_HID_ERROR_CODE > #define FACILITY_HID_ERROR_CODE 0x11 > > >

1 0

Re: [PATCH] wined3d: Add id for Broadwell Xeon E3 GPU
by Henri Verbeet Sept. 19, 2016

Sept. 19, 2016

On 16 September 2016 at 15:54, Andrew Kanaber <akanaber(a)chiark.greenend.org.uk> wrote: > "Iris Pro Graphics P6300" on all the Xeon E3-1200v4 chips > (except the E3-1258L v4) This is missing a "Signed-off-by:" line, but seems fine otherwise.

1 0