Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
Simon Lipp slo...@gmail.com wrote: + * Moreover, let dead chars be processed or we will never have + * WM_DEADCHAR events That's how it's supposed to work. Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch. -- Dmitry.
Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
That's how it's supposed to work. But it doesn’t work that way under Windows. Shouldn’t Wine try to stick to Windows behavior as close as possible ? Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence. X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch. Are you speaking about XCompose or things like ibus ? Both still looks like OK with this patch (tested with wine’s notepad, ibus-anthy and XCompose keys from http://bepo.fr/).
Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
On Apr 16, 2013, at 3:43 AM, Simon Lipp wrote: That's how it's supposed to work. But it doesn’t work that way under Windows. Shouldn’t Wine try to stick to Windows behavior as close as possible ? Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence. For what it's worth, that agrees with my understanding, too. The Mac driver supports dead keys in the manner that Simon suggests. It generates WM_KEYDOWN for dead keys and returns -1 from ToUnicodeEx() for them, which causes TranslateMessage() to post WM_DEADCHAR. When a subsequent key completes the sequence, ToUnicodeEx() returns the completed character(s) as indicated by the Mac keyboard layout. It all seems to work fine. (It also doesn't interfere with some local, in-progress work to support input methods.) Nothing about posting WM_DEADCHAR takes control over the ultimate translation of keys into characters away from the driver or the windowing/input system with which it interfaces. -Ken
Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
Simon Lipp slo...@gmail.com wrote: That's how it's supposed to work. But it doesn’t work that way under Windows. Shouldn’t Wine try to stick to Windows behavior as close as possible ? It depends. Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence. You never know which events are supposed to be part of dead code sequencies, so trying to interpret them or inject some events may lead to unpredictable results. X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch. Are you speaking about XCompose or things like ibus ? Both still looks like OK with this patch (tested with wine’s notepad, ibus-anthy and XCompose keys from http://bepo.fr/). Something like that, usually ~/.Xkbmap makes it easy to play with. -- Dmitry.
Re: [PATCH 6/6] ieframe: Added DISPID_WINDOWCLOSING tests.
On 04/15/13 18:08, 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 http://testbot.winehq.org/JobDetails.pl?Key=25086 Your paranoid android. The patch was rejected due to those failures, but: === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2631: Test failed: expected GetOverridesKeyPath webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3076: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402F21 This one is TestBot's fault. The whole test should be skipped on that machine (and is skipped by WineTest). === WVISTAX64 (64 bit webbrowser) === webbrowser.c:978: Test failed: unexpected dispIdMember 271 webbrowser.c:1604: Test failed: unexpected call TranslateUrl webbrowser.c:454: Test failed: unexpected nCmdID 14 Timeout This one seems like rare random unrelated failure. Here is a clean run of the same patch: https://testbot.winehq.org/JobDetails.pl?Key=25094 I will resend the patch. Cheers, Jacek
Re: kernel32: Add a test to check event and mutex states during process termination.
Dmitry Timoshkov dmi...@baikal.ru writes: --- dlls/kernel32/tests/loader.c | 40 +--- 1 file changed, 33 insertions(+), 7 deletions(-) That's not a very meaningful test if nobody holds the mutex. -- Alexandre Julliard julli...@winehq.org
Re: ieframe: Added DISPID_WINDOWCLOSING tests.
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=25096 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2631: Test failed: expected GetOverridesKeyPath webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3076: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402F21
Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence. You never know which events are supposed to be part of dead code sequencies, so trying to interpret them or inject some events may lead to unpredictable results. This patch does not let pass every single dead sequence without check. It only let pass events which are really dead keys, that is, for keysyms that are dead keys for XKB (before any interpretation by the IM) ; for example if you type ha with anthy neither h nor a events will pass, only the final one for は.Same with Xcompose: Compose+ss will not generate any message outside the final WM_CHAR ß (because s is not a dead key for XKB, even if it is for XIM in combinaison with Multi_key). The only change is for things like ^+e = ê (which will add a WM_DEADCHAR for dead_circumflex), where an additional WM_DEADCHAR will be sent. It’s very unlikely that applications will get troubled by this additional message since they already receive it when running on Windows. X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch. Are you speaking about XCompose or things like ibus ? Both still looks like OK with this patch (tested with wine’s notepad, ibus-anthy and XCompose keys from http://bepo.fr/). Something like that, usually ~/.Xkbmap makes it easy to play with. Well, I use XCompose on a daily basis with wine + this patch without any issue. Can’t tell for other IMs (XCompose works only with XIM so I stick to it), but basic tests with ibus+anthy shows no issue as well.
Re: d3dx9: Implement D3DXSHMultilpy5
2013/4/15 Nozomi Kodama nozomi.kod...@yahoo.com: Hello thanks for the review. I don't think that calling defines is the way to go. Indeed, I tested my patch and yours. Yours is about 12% slower than mine in my computer. And now, we try to take care of efficiency of this dll. So, it is not the time to increase latency. I used 10 digits since there are a lot of computation, I want to avoid as much as possible big rounding errors. If we want to uniformize, then we should uniformize d3dxshmultiply 2,3,4 with 10 digits. But that is for an another patch. Just to chip in about float precision. As already discussed, 32-bit float constants have about 7 decimals digits of precision, so extending these constants from 8 to 10 digits should not change anything. You would have to use doubles if you want more accurate values (but I don't think we should use doubles in d3dx9 dlls anyway). What you can do to ensure numeric accuracy is reviewing computations: the order of the operations (e.g. how you resolve operators associativity, etc) and storing/reusing intermediate results can make a difference. I wouldn't care about this stuff unless we get significantly different results compared to native. Nozomi. Looks pretty much ok, but isn't there a way to reduce the size a bit? Just see the dirty hack which is attached. D3DXSHMultiply6 will add a lot of lines too... Also is there a reason why we use constants with different accuracy (e.g. 0.28209479f in D3DXSHMultiply4 and 0.2820948064f)? Cheers Rico
Re: [PATCH 5/5] wined3d: Enable GL_ARB_texture_rectangle in GLSL ffp fragment shaders
On 16 April 2013 14:48, Stefan Dösinger ste...@codeweavers.com wrote: +if (gl_info-supported[ARB_TEXTURE_RECTANGLE]) +shader_addline(buffer, #extension GL_ARB_texture_rectangle : enable\n); + This may be a good idea anyway, but is this strictly required? IIRC ARB_texture_rectangle is the one special extension that's always implicitly enabled in GLSL if it's supported.
Re: [PATCH 2/5] d3d9/tests: Test NPOT texture creation
On 16 April 2013 14:48, Stefan Dösinger ste...@codeweavers.com wrote: - * Copyright (C) 2006 Chris Robinson + * Copyright (C) 2006 Chris Robinsontes This looks unintentional. +UINT refcount; Technically refcounts are ULONGs, although I suppose it doesn't matter a whole lot.
Re: [PATCH 5/5] wined3d: Enable GL_ARB_texture_rectangle in GLSL ffp fragment shaders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-16 17:01, schrieb Henri Verbeet: On 16 April 2013 14:48, Stefan Dösinger ste...@codeweavers.com wrote: +if (gl_info-supported[ARB_TEXTURE_RECTANGLE]) + shader_addline(buffer, #extension GL_ARB_texture_rectangle : enable\n); + This may be a good idea anyway, but is this strictly required? IIRC ARB_texture_rectangle is the one special extension that's always implicitly enabled in GLSL if it's supported. Yes, I get a compile error on Nvidia otherwise: fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #21: fixme:d3d_shader:print_glsl_info_log Fragment info fixme:d3d_shader:print_glsl_info_log - fixme:d3d_shader:print_glsl_info_log 0(5) : error C7532: global type sampler2DRect requires #version 140 or later fixme:d3d_shader:print_glsl_info_log 0(5) : error C: ... or #extension GL_ARB_texture_rectangle : enable fixme:d3d_shader:print_glsl_info_log 0(10) : error C7531: global function texture2DRect requires #extension GL_ARB_texture_rectangle : enable before use This is on Nvidia 319.12, with ARB_texture_non_power_of_two disabled to test the RECT codepath. The d3d9 visual test uncovers this problem. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRbWnQAAoJEN0/YqbEcdMw0U8P/0XUFynxe2xQY3E+clFHgFs7 MyzXcAJMTi0kCxNHsOCiTtP/wzVVpbRAL3MZFrouAXtMIEuJ/Mtt7JRB7PrwsQPV qgl0CtjGXB0e6ftgi3shnXprcq5XVxl74R4CV14//VcGRfHPzczDd0qvrRlKFFv9 I9fgABVboPDtezq2JrxNmIemMU6D90eOx5MSjqJyf1ZoqfCpUKW0e4UrmRUiwm5k HGquu0b33iCvyJ+oZt1szItyQqLK6p5gERKfEvCTLr17mawrO4Q//T8D3zFVBdaZ e1xls0euAtks/he8x/ZYxmC8mrEYS+TpwWDwr6MDth+w0cxw218Z/B2vwbH95hmQ +Ah7Ky6xFfwtUsFXe8Ry48FFE29s1iPvijvuZZh04BKa1rmrMP2sog66VbStDxhT gg1D3PCKJ18fNT396TkJL68Oq1VrikliEExkYXf+xI/TWwDin5Ucp7Qy+cHqZnnG UBpV2jM+WNDDI4j1D6Sr+Q/d9h0d412fObJC0L8DWkN9f8lob2oUvF0kjYMc029z NPsjtIllLUVRwOuu3Iwp05Z553f5A5HdhUnzZTyvgyQ8yo1tVS1doh+ErjocP9ls xxkV6W282z78lVuOk8iVTadxVMhfupmZ7v2eEXSoxf5w/DNszt++ejR33ot2sQgA S8p0wgrYDz1YBd5Pv7rz =ZHz0 -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Enable GL_ARB_texture_rectangle in GLSL ffp fragment shaders
On 16 April 2013 17:10, Stefan Dösinger ste...@codeweavers.com wrote: fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #21: fixme:d3d_shader:print_glsl_info_log Fragment info fixme:d3d_shader:print_glsl_info_log - fixme:d3d_shader:print_glsl_info_log 0(5) : error C7532: global type sampler2DRect requires #version 140 or later fixme:d3d_shader:print_glsl_info_log 0(5) : error C: ... or #extension GL_ARB_texture_rectangle : enable fixme:d3d_shader:print_glsl_info_log 0(10) : error C7531: global function texture2DRect requires #extension GL_ARB_texture_rectangle : enable before use This is on Nvidia 319.12, with ARB_texture_non_power_of_two disabled to test the RECT codepath. The d3d9 visual test uncovers this problem. I think technically that's a bug in the driver (see issue 15 in the extension spec), but I suppose it makes sense for us to handle this like any other extension. (And actually it looks like there's already a comment about this in shader_glsl_generate_pshader(), originally added by 3fd0916654906d2e4d0091322ea3162c18848cd4, although it only mentions a warning.)
Re: testbot: Default set of VMs to run the tests
Francois Gouget fgou...@codeweavers.com wrote: On Sat, 13 Apr 2013, Dmitry Timoshkov wrote: [...] As I've pointed out, 64-bit XP and Vista VMs do exist and work just fine, please include at least them in the default VM set. I see. I have moved WXPX64 and WVISTAX64 to the base set of VMs. I still need to manually enable WXPX64 and WXPPROSP2 when I send a test to testbot. -- Dmitry.
