July 2008 - Wine-Devel - list.winehq.org

Re: [resent] [WideChar conversion improvements - 5/5] Add a lot ofWideCharToMultiByte tests

by Colin Finck

Jeff Latimer wrote: > Are you planning to move on to MultiByteToWideChar tests? No, feel free to go ahead with them. I mainly wanted to fix http://bugs.winehq.org/show_bug.cgi?id=8598 and a fix for this bug required a working wide-character to multibyte conversion in the CRT and Win32. This is the only reason why I cared about all this stuff ;-) Best regards, Colin

July 31, 2008

Re: New valgrind warnings in kernel32/tests/codepage.c

by Colin Finck

Dan Kegel wrote: > your change [...] seems to have triggered some valgrind warnings, Thanks for providing the valgrind output! Indeed, I was passing a wrong length to a WideCharToMultiByte call, which led to the use of uninitialized stack memory. Fixed here: http://www.winehq.org/pipermail/wine-patches/2008-July/058951.html Best regards, Colin

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Aric Stewart

Here is a revised patch which builds the scancode->DIK table on initialization making no xserver round trips required on lookup. How does this look? -aric Aric Stewart wrote: > Yes, I have verified those vkeys in windows. > the VK_OEM_* keys are specificaly VK codes that vary from keyboard to > keyboard. VK_OEM_3 is just one example. > > -aric > > Vitaliy Margolen wrote: >> Aric Stewart wrote: >>> vkey codes similarly do not produce a clean 1 to 1 correspondance. >>> the '@' key (0x1a) is vkey (VK_OEM_3) which is the vkey of the '`' >>> key on the us keyboard. >> This is needs to be fixed in x11drv then. Not in dinput. Have you >> verified what v_keys you getting from windows for these keys? >> >> Vitaliy. >> > commit f32b8b281a5df115881f2c5c6dd2f273d5b2b657 Author: Aric Stewart <aric(a)codeweavers.com> Date: Fri Jul 25 16:07:30 2008 +0900 dinput: the DIK_ keycode is not the same as the scancode. It is mapped with the keyboard mapping to the resulting character. so the key 'A' is DIK_A nomatter what its scancode or vkey would be. This is relevent to Japanese keymapping where the '@' key is in the '[' location the scancode for both is 0x22 but dinput generates DIK_AT in japanese and DIK_LBRACKET in us_qwerty reworked to remove the giant case statement and hopefully be more clear. remove japan specific stuff diff --git a/dlls/dinput/keyboard.c b/dlls/dinput/keyboard.c index b2c4942..f4918b0 100644 --- a/dlls/dinput/keyboard.c +++ b/dlls/dinput/keyboard.c @@ -48,8 +48,32 @@ struct SysKeyboardImpl { struct IDirectInputDevice2AImpl base; BYTE DInputKeyState[WINE_DINPUT_KEYBOARD_MAX_KEYS]; + BYTE ScanCodemap[WINE_DINPUT_KEYBOARD_MAX_KEYS]; }; +static int map_dik_code(DWORD scanCode) +{ + static const int asciiCodes[] = + {/*32*/ DIK_SPACE,0,0,0,0,0,0,DIK_APOSTROPHE,0,0,0,0, DIK_COMMA, /*44*/ \ + /*45*/ DIK_MINUS, DIK_PERIOD, DIK_SLASH,DIK_0,DIK_1,DIK_2,DIK_3, /*51*/ \ + /*52*/ DIK_4,DIK_5,DIK_6,DIK_7,DIK_8,DIK_9,DIK_COLON,DIK_SEMICOLON,0, /*60*/ \ + /*61*/ DIK_EQUALS, 0,0,DIK_AT,DIK_A,DIK_B,DIK_C,DIK_D,DIK_E,DIK_F, /*70*/ \ + /*71*/ DIK_G,DIK_H,DIK_I,DIK_J,DIK_K,DIK_L,DIK_M,DIK_N,DIK_O,DIK_P, /*80*/ \ + /*81*/ DIK_Q,DIK_R,DIK_S,DIK_T,DIK_U,DIK_V,DIK_W,DIK_X,DIK_Y,DIK_Z, /*90*/ \ + /*91*/ DIK_LBRACKET,0,DIK_RBRACKET,DIK_CIRCUMFLEX,DIK_UNDERLINE} /*95*/ ; + int out_code = 0; + DWORD vkCode = MapVirtualKeyA(scanCode,MAPVK_VSC_TO_VK); + CHAR c = MapVirtualKeyA(vkCode,MAPVK_VK_TO_CHAR); + + if (c && c >31 && c < 96) + out_code = asciiCodes[c - 32]; + + if (out_code == 0) + out_code = scanCode; + + return out_code; +} + static void KeyboardCallback( LPDIRECTINPUTDEVICE8A iface, WPARAM wparam, LPARAM lparam ) { SysKeyboardImpl *This = (SysKeyboardImpl *)iface; @@ -63,7 +87,7 @@ static void KeyboardCallback( LPDIRECTINPUTDEVICE8A iface, WPARAM wparam, LPARAM TRACE("(%p) %ld,%ld\n", iface, wparam, lparam); - dik_code = hook->scanCode & 0xff; + dik_code = This->ScanCodemap[hook->scanCode]; /* R-Shift is special - it is an extended key with separate scan code */ if (hook->flags & LLKHF_EXTENDED && dik_code != 0x36) dik_code |= 0x80; @@ -205,6 +229,10 @@ static SysKeyboardImpl *alloc_device(REFGUID rguid, const void *kvt, IDirectInpu newDevice->base.data_format.wine_df = df; IDirectInput_AddRef((LPDIRECTINPUTDEVICE8A)newDevice->base.dinput); + /* Initialize scancode lookup */ + for (i = 0; i < WINE_DINPUT_KEYBOARD_MAX_KEYS; i++) + newDevice->ScanCodemap[i] = map_dik_code(i); + return newDevice; failed:

July 31, 2008

New valgrind warnings in wined3d/arb_program_shader.c

by Dan Kegel

Hi Stefan, your recent round of changes (circa http://www.winehq.org/pipermail/wine-cvs/2008-July/045946.html) seems to have triggered a whole bunch of valgrind warnings, e.g. http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-d3d9_visual-diff.txt + Use of uninitialised value of size 4 + at hash_table_get_by_idx (utils.c:1600) + by hash_table_get (utils.c:1750) + by find_ffp_shader (utils.c:1961) + by fragment_prog_arbfp (arb_program_shader.c:2761) + by ActivateContext (context.c:1169) + by drawPrimitive (drawprim.c:950) + by IWineD3DDeviceImpl_DrawIndexedPrimitiveUP (device.c:5350) + by IDirect3DDevice9Impl_DrawIndexedPrimitiveUP (device.c:1227) + by lighting_test (visual.c:300) + by func_visual (visual.c:9234) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at fragment_prog_arbfp (arb_program_shader.c:2745) http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-ddraw_visual-diff.t… + Use of uninitialised value of size 4 + at hash_table_get_by_idx (utils.c:1600) + by hash_table_get (utils.c:1750) + by find_ffp_shader (utils.c:1961) + by fragment_prog_arbfp (arb_program_shader.c:2761) + by ActivateContext (context.c:1169) + by drawPrimitive (drawprim.c:950) + by IWineD3DDeviceImpl_DrawIndexedPrimitiveUP (device.c:5350) + by IDirect3DDeviceImpl_7_DrawIndexedPrimitive (device.c:3731) + by IDirect3DDeviceImpl_7_DrawIndexedPrimitive_FPUSetup (device.c:3754) + by lighting_test (visual.c:276) + by func_visual (visual.c:2649) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at fragment_prog_arbfp (arb_program_shader.c:2745) Could you have a look? Thanks, Dan

July 31, 2008

New valgrind warnings in kernel32/tests/codepage.c

by Dan Kegel

Hi Colin, your change http://source.winehq.org/git/wine.git/?a=commitdiff;h=c2c1a55f1c08f35ae02b8… seems to have triggered some valgrind warnings, http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-kernel32_codepage-d… e.g. + Use of uninitialised value of size 4 + at wcstombs_sbcs (wctomb.c:186) + by wine_cp_wcstombs (wctomb.c:457) + by WideCharToMultiByte (locale.c:1936) + by test_string_conversion (codepage.c:288) + by func_codepage (codepage.c:351) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at test_string_conversion (codepage.c:216) + Use of uninitialised value of size 4 + at wcstombs_sbcs_slow (wctomb.c:246) + by wine_cp_wcstombs (wctomb.c:453) + by WideCharToMultiByte (locale.c:1936) + by test_string_conversion (codepage.c:288) + by func_codepage (codepage.c:352) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at test_string_conversion (codepage.c:216) Could you have a look?

July 31, 2008

Re: xinput implementation

by chourmovs

If i've understood what i read before, i think i've found a sort of xinput's conformance test suite writen by windows coder what do you think of that ? http://www.codeproject.com/KB/directx/xbox360_cont_xinput.aspx We've got the source code for a test and even binaries !! I've to test its behaviour under windows XP and after use it under wine to test new code and patches, isn't it ? I'm not sure to understand the conformance test guide well Thank you Le Thu, 31 Jul 2008 16:04:11 +0200, Dan Kegel <dank(a)kegel.com> a écrit: > chourmovs wrote: >> I'd like to participate to wine improvement instead of >> always requesting for new features >> >> .. xinput support lack for new games and its >> implementation is maybe not the hardest thing to do > > Please start by writing conformance tests. > See > http://www.winehq.org/site/docs/winedev-guide/testing > - Dan > > > > -- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/

July 31, 2008

Re: [1/2] user32: Add a test for ToUnicode (try 5)

by Paul Vriens

Andre Wisplinghoff wrote: > Wrapping was still wrong. Sorry for that. Just using attachments now. > > dlls/user32/tests/input.c | 37 +++++++++++++++++++++++++++++++++++++ > 1 files changed, 37 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Just some things that caught my attention: Could you trim the length for some of the lines somewhat? I also don't think you need all those comments in the first call to ToUnicode. There is a C++ comment in the patch, should be avoided. And as a last one, is it possible to use names instead of magic constants? -- Cheers, Paul.

July 31, 2008

Re: [5/7] WineD3D: Only set D3D caps when GL was loaded successfully

by H. Verbeet

2008/7/31 Stefan Dösinger <stefan(a)codeweavers.com>: > + if(Adapters[0].opengl) { Shouldn't you be checking the adapter for which the caps are requested instead?

July 31, 2008

Re: [3/7] WineD3D: Beware of the frontbuffer coordinate system difference

by H. Verbeet

You'll need to modify stretch_rect_fbo() as well.

July 31, 2008

RE: xinput implementation

by Stefan Dösinger

Hi, I looked up the XInput documentation a while ago, and the DLL seemed rather small and simple to me. My quick uneducated guess is that it should be pretty streightforward to wrap it to the standard joystick API. What I recommend you as a start is to boot Windows, get some Windows development tools and experiment with the XInput API to understand how it works and get some test cases. This may require you to buy an Xbox 360 gamepad, since XInput only talks to this hardware. Once you understand how to use xinput.dll, you'll have a much easier task implementing it for Wine.

July 31, 2008