September 2016 - Wine-Devel

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Matteo Bruni

2016-09-13 22:28 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: >> I don't think this is acceptable. It should be done in a way that >> doesn't introduce mess like this. > > I split the patches but I didn't know how to do it . For not breaking > compilation, I added these temporary defines. The later patch removes those > again. Yeah, that's certainly not acceptable. Also in general introducing dead code (i.e. code that's unused until a later patch) is not okay. You can probably start from a simple implementation of D3DX11CreateTextureFromMemory(), without any scaling or format conversion and without DDS support. Something like 258dba1a521cff3226db523b012ef3de2599e578 but for d3dx11. Notice how that calls D3DXGetImageInfoFromFileInMemory(); similarly it might make sense to implement D3DX11GetImageInfoFromMemory() first. Then you should introduce the various other pieces incrementally, as they become necessary. You don't want to actually duplicate the code keeping all the d3d9-isms, you'll have to rewrite those helpers in a way that makes sense for d3d11 (incidentally, that's what I meant with this being a useful step before figuring out how generic helpers would look like). Most importantly, you need to write some tests for all the functions you are implementing. The related d3dx9 tests are probably a decent starting point, although there are a few new bits that should be tested as well (e.g. it would be interesting to test various combinations of BindFlags, CpuAccessFlags and MiscFlags). You want to do that even before starting to work on the implementation, there might be some surprising results.

Sept. 19, 2016

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects

by Matteo Bruni

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.

Sept. 19, 2016

Re: Problems with the tooltip controls.

by John Found

On Mon, 19 Sep 2016 14:01:21 -0500 Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Wrote a quick test and they seem to be 0x28 and 0x2c respectively, so > I guess that's not your problem. > > Andrew BTW, I tested with pointer set to 0 and still have return value of FALSE, so according to the source you posted, it seems that `infoPtr->nCurrentTool == -1` for this tooltip control. The control is created automatically by the toolbar. Here is the code that create the toolbar (some labels are arguments of the whole function): ; Create toolbar xor esi,esi invoke GetModuleHandleW,esi mov edi, eax invoke CreateWindowExW, esi, cToolbarClassName, NULL, \ WS_CHILD or \ WS_VISIBLE or \ WS_CLIPSIBLINGS or \ WS_CLIPCHILDREN or \ TBSTYLE_TRANSPARENT or \ TBSTYLE_FLAT or \ TBSTYLE_TOOLTIPS or \ TBSTYLE_WRAPABLE, \ esi, esi, esi, esi, \ [.ParentWindow], [.ToolbarID], \ edi, NULL mov ebx,eax stdcall SubclassWindow, ebx, CoolToolbarProc invoke SetPropW, ebx, [propAutoSize], TRUE invoke SendMessageW, ebx, TB_BUTTONSTRUCTSIZE, TToolbarButton.size, esi ; make arrows for dropdown buttons invoke SendMessageW, ebx, TB_GETEXTENDEDSTYLE, esi, esi or eax,TBSTYLE_EX_DRAWDDARROWS invoke SendMessageW, ebx, TB_SETEXTENDEDSTYLE, esi, eax ; Set image lists invoke SendMessageW, ebx, TB_SETIMAGELIST, esi, [.ImagesNormal] invoke SendMessageW, ebx, TB_SETDISABLEDIMAGELIST, esi, [.ImagesDisabled] ; make tooltip to appear on not active main window. invoke SendMessageW, ebx, TB_GETTOOLTIPS, 0, 0 mov esi, eax invoke GetWindowLongW, esi, GWL_STYLE or eax, TTS_ALWAYSTIP or TTS_NOPREFIX invoke SetWindowLongW, esi, GWL_STYLE, eax ; Set tooltip delay time. invoke SendMessageW, esi, TTM_SETDELAYTIME, TTDT_AUTOMATIC, 600 -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Sept. 19, 2016

Re: Problems with the tooltip controls.

by Andrew Eikum

On Mon, Sep 19, 2016 at 09:56:59PM +0300, John Found wrote: > On Mon, 19 Sep 2016 13:39:27 -0500 > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > On Mon, Sep 19, 2016 at 09:30:20PM +0300, John Found wrote: > > > 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. > > > > That message in Wine should only return FALSE in a few scenarios: > > > > http://source.winehq.org/git/wine.git/blob/5a9f7ef06df15e26acf46b0210dd7697… > > > > Check that your cbSize member is valid, and if so, maybe look into why > > Wine doesn't think there is a tool currently selected. > > > > Andrew > > What is the values of TTTOOLINFOW_V1_SIZE and TTTOOLINFOW_V2_SIZE? I tried to search for them, but there is some very > obfuscated C code... :'( > > I am using a structure with size = 28h = 40 bytes > Wrote a quick test and they seem to be 0x28 and 0x2c respectively, so I guess that's not your problem. Andrew

Sept. 19, 2016

Re: Problems with the tooltip controls.

by John Found

On Mon, 19 Sep 2016 13:39:27 -0500 Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Mon, Sep 19, 2016 at 09:30:20PM +0300, John Found wrote: > > 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. > > That message in Wine should only return FALSE in a few scenarios: > > http://source.winehq.org/git/wine.git/blob/5a9f7ef06df15e26acf46b0210dd7697… > > Check that your cbSize member is valid, and if so, maybe look into why > Wine doesn't think there is a tool currently selected. > > Andrew What is the values of TTTOOLINFOW_V1_SIZE and TTTOOLINFOW_V2_SIZE? I tried to search for them, but there is some very obfuscated C code... :'( I am using a structure with size = 28h = 40 bytes struct TOOLINFO .cbSize dd ? .uFlags dd ? .hwnd dd ? .uId dd ? .Rect RECT .hInst dd ? .lpszText dd ? ends It seems that Windows accepts it, but WINE not. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Sept. 19, 2016

Re: Problems with the tooltip controls.

by Nikolay Sivov

On Monday, 19 September 2016, John Found <johnfound(a)asm32.info> wrote: > 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? > > Hi, John. Please open a bug report and attach sample application code there or at least a relevant part of it, so we can turn it into a test. Workarounds are not interesting for Wine. > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound(a)asm32.info <javascript:;>> > > >

Sept. 19, 2016

Re: Problems with the tooltip controls.

by Andrew Eikum

On Mon, Sep 19, 2016 at 09:30:20PM +0300, John Found wrote: > 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. That message in Wine should only return FALSE in a few scenarios: http://source.winehq.org/git/wine.git/blob/5a9f7ef06df15e26acf46b0210dd7697… Check that your cbSize member is valid, and if so, maybe look into why Wine doesn't think there is a tool currently selected. Andrew

Sept. 19, 2016

Problems with the tooltip controls.

by John Found

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>

Sept. 19, 2016

Re: [PATCH v2] hid: Stub HidP_TranslateUsagesToI8042ScanCodes

by Sebastian Lackner

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

Sept. 19, 2016

Re: [PATCH] wined3d: Add id for Broadwell Xeon E3 GPU

by Henri Verbeet

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.

Sept. 19, 2016