April 2010 - Wine-Devel - list.winehq.org

X11 keyboard detection bitrot on Linux?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Perhaps there's some bitrot that affects the handling of alt/altGr keys on Linux? Using WINEDEBUG=+keyboard on Macos yields exepected results. The 3rd and 4th characters (|\ etc.) below show what's obtained when pressing the alt key: trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 34, got 7/|\ trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 36, got 8({ trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 58, got <>?? trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 73, got ,,.. On Linux instead: warn:keyboard:X11DRV_KEYBOARD_DetectLayout 7 keysyms per keycode not supported, set to 4 trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 16, got 7/7/ trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 17, got 8(8( None of the {[]}\ keys reached via AltGr-7/8/9/0 on the German keyboard is printed by the keyboard detection code. This causes warnings for all keyboards (not printed by default) because none matches, which presumably was not the case back when that code was written. What has changed? Regards, Jörg Höhle

April 28, 2010

Re: [PATCH 4/4] wined3d: use stretch_rect_fbo for swapchainless blits

by Henri Verbeet

On 28 April 2010 14:29, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > + /* Early sort out of cases where no render target is used */ > + if (!dstSwapchain && !srcSwapchain > + && src_surface != device->render_targets[0] > + && dst_surface != device->render_targets[0]) > + { > + if (fbo_blit_supported(&device->adapter->gl_info, BLIT_OP_BLIT, > + &src_rect, src_surface->resource.usage, src_surface->resource.pool, src_surface->resource.format_desc, > + &dst_rect, dst_surface->resource.usage, dst_surface->resource.pool, dst_surface->resource.format_desc)) > + { > + stretch_rect_fbo(device, src_surface, &src_rect, dst_surface, &dst_rect, Filter); > + return WINED3D_OK; > + } > + > + TRACE("No surface is render target, not using hardware blit.\n"); > + return WINED3DERR_INVALIDCALL; > + } > + You might as well try FBO blits first, before doing most of the other checks. That's how it's eventually supposed to work anyway, and you could remove the other strecth_rect_fbo() calls in that case. That does depend on fbo_blit_supported() working properly, of course.

April 28, 2010

Re: [PATCH 3/4] wined3d: fix texm3x3spec coordinate mask bug

by Henri Verbeet

On 28 April 2010 14:29, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > This patch fixes an issue in "King's Bounty: The Legend" for which a shader of the form: > 'texture2D(sampler2D, tmp0.xyz)' was generated. The nvidia GLSL compiler wants to have tmp0.xyz. We talked about this on IRC yesterday, the reason this happens is that the sampler type is wrong.

April 28, 2010

Re: [PATCH 1/4] wined3d: fix flip_surface flag copying bug

by Roderick Colenbrander

Ignore patch 1/4 and 2/4 for now. I missed a reply from Henri to the bug report. Roderick On Wed, Apr 28, 2010 at 2:29 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > This patch fixes a part of bug 22356. The issue is that Jedi Knight performs a full surface copy > from the back to the front buffer which in the end uses flip_surface. flip_surface swaps > the surface flags which causes an issue in this case because only one of the buffers > ever had SFLAG_CONVERTED set. This means that SFLAG_CONVERTED is set for the odd frame > and unset for the even frame. > --- > dlls/wined3d/surface.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index fcdfec8..d14dbd0 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -2917,10 +2917,13 @@ void flip_surface(IWineD3DSurfaceImpl *front, IWineD3DSurfaceImpl *back) { > front->texture_name_srgb = tmp; > } > > + /* Copy location flags */ > { > DWORD tmp_flags = back->Flags; > - back->Flags = front->Flags; > - front->Flags = tmp_flags; > + back->Flags &= ~SFLAG_LOCATIONS; > + back->Flags |= front->Flags & SFLAG_LOCATIONS; > + front->Flags &= ~SFLAG_LOCATIONS; > + front->Flags |= tmp_flags & SFLAG_LOCATIONS; > } > } > > -- > 1.6.3.3 > >

April 28, 2010

Re: Minor dlls/mshtml/htmlbody.c simplification (RESEND)

by Nikolay Sivov

On 4/28/2010 14:02, Gerald Pfeifer wrote: > ChangeLog: > Remove variable hres which is not really used from HTMLBodyElement_get_text. > > diff --git a/dlls/mshtml/htmlbody.c b/dlls/mshtml/htmlbody.c > index 5c66e65..c6b202b 100644 > --- a/dlls/mshtml/htmlbody.c > +++ b/dlls/mshtml/htmlbody.c > @@ -443,7 +443,6 @@ static HRESULT WINAPI HTMLBodyElement_get_text(IHTMLBodyElement *iface, VARIANT > HTMLBodyElement *This = HTMLBODY_THIS(iface); > nsAString text; > nsresult nsres; > - HRESULT hres; > > TRACE("(%p)->(%p)\n", This, p); > > @@ -454,10 +453,8 @@ static HRESULT WINAPI HTMLBodyElement_get_text(IHTMLBodyElement *iface, VARIANT > > nsAString_GetData(&text,&color); > V_VT(p) = VT_BSTR; > - hres = nscolor_to_str(color,&V_BSTR(p)); > }else { > ERR("GetText failed: %08x\n", nsres); > - hres = E_FAIL; > } > > nsAString_Finish(&text); > Please follow wine-devel comments: http://www.winehq.org/pipermail/wine-devel/2010-April/083175.html

April 28, 2010

new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven

by wylda＠volny.cz

> I'm ripping it now, but it's pretty slow, comparatively. Tons of: > Found L-EC error at sector 1589216 - ignored. Good luck and hopefully your DVD drive will survive it ;) After long tests, i choosed (year ago) Alcohol 120% as the ripping tool, because it produced most number of working backup copies and makes them fast. However, if the safedisc image will work most depends on DVD drive. Again from personal test of 5 bought drives Samsung SH-S223F is winner for me. And for loading such image under linux i use http://www.cdemu.org so mounting an image is done by: cdemu load 0 my_image.mds cdemu unload 0 my_image.mds This SW need a kernel module, so it's not easy as other tools, but the reward is, you can SafeDisc/SecuROM working without needing a crack (of course the image have to firstly work under WinXP and wine have to support such protection like SecuROM v7.30.0014). Unfortunately SecuROM v7.27.0014 doen't work in wine, because of "Unsupported ioctl 2d0c04", but bug 20935 Anastasius how to overcome, but i don't know where to put the heck 0. So if wisotool would support "cdemu load", that would be tool even for me ;)

April 28, 2010

Re: New SCSI Driver for Mac OS X

by Stefan Dösinger

Am 27.04.2010 um 22:10 schrieb Charles Davis: > tar jxf ExtMediaBSDClient.tar.bz2 > cd ExtMediaBSDClient Do you have the sourcecode somewhere with instructions on how to compile it?

April 28, 2010

Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven

by Austin English

On Wed, Apr 28, 2010 at 2:13 AM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > On the iso & copy protection topic: It is possible to generate bin + toc > images from cds with cdrdao[1] and to mount them with fuseiso[2]. This *might* > improve copy protection support. No idea on how portable nor how efficient it > can be. > > [1] Something along the lines of > cdrdao read-cd --driver generic-mmc-raw --read-raw --device /dev/xxx \ > foo.toc > Maybe with --read-subchan too. > [2] http://fuse.sourceforge.net/wiki/index.php/FuseIso I'm working on this now, actually. So far we've lucked out and all games tested installed fine from ISO's, but Bioshock refuses to install without the real DVD in the drive. I'm ripping it now, but it's pretty slow, comparatively. Tons of: Found L-EC error at sector 1589216 - ignored. Found L-EC error at sector 1589217 - ignored. Found L-EC error at sector 1589218 - ignored. Found L-EC error at sector 1589219 - ignored. -- -Austin

April 28, 2010

Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven

by Vincent Pelletier

Le dimanche 25 avril 2010 01:44:03, Dan Kegel a écrit : > You can read more about it at > http://wiki.winehq.org/wisotool Nice tool. I'm trying to add support for GOG.com installers. At the moment, I can install setup_duke3d.exe unattended (I only used it as it is the smallest installer I have from GOG). I have problems supporting GOG installers which install Adobe Reader (aside from the reported crash, I'm still trying to find an elegant way to disable its installation). I should send a patch soon. On the iso & copy protection topic: It is possible to generate bin + toc images from cds with cdrdao[1] and to mount them with fuseiso[2]. This *might* improve copy protection support. No idea on how portable nor how efficient it can be. [1] Something along the lines of cdrdao read-cd --driver generic-mmc-raw --read-raw --device /dev/xxx \ foo.toc Maybe with --read-subchan too. [2] http://fuse.sourceforge.net/wiki/index.php/FuseIso -- Vincent Pelletier

April 28, 2010

Re: bt all broken? Bisect result.

by Peter Urbanec

I did a git bisect to test the "bt all" issue and narrowed down the issue: d29c6ead9280a174fa07ec7d5cd07293c3f7832d is the first bad commit commit d29c6ead9280a174fa07ec7d5cd07293c3f7832d Author: Eric Pouech <eric.pouech(a)orange.fr> Date: Tue Mar 30 21:37:01 2010 +0200 winedbg: Store the CONTEXT in each stack frame to enable register access in the non topmost frames. I used the multithreaded test program from bug 20617 http://bugs.winehq.org/show_bug.cgi?id=20617 to test this problem. This is what a failure looks like: $ ./wine winedbg MultipleThreads.exe ... Wine-dbg>bt all ... Backtracing for thread 0020 in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) Backtracing for thread 001f in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) Backtracing for thread 001e in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) Backtracing for thread 0019 in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) 0xf776b42e: jmp 0xf776b423 ... A proper backtrace should look something like this: ... Backtracing for thread 002e in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0xf7711430 (0x0081ea04) 1 0x7ee155f4 SleepEx+0x2a(timeout=0x00c8, alertable=0) [/source/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0081ea34) 2 0x7ee155c0 Sleep+0x25(timeout=0x00c8) [/source/wine/dlls/kernel32/sync.c:97] in kernel32 (0x0081ea54) 3 0x0040103a Boom::crash_func+0x3a(void_ptr=0x33fdb0) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:25] in multiplethreads (0x0081ea68) 4 0x7efbad44 call_thread_func+0xc() in ntdll (0x0081ea78) 5 0x7efbad82 call_thread_entry_point+0x34(entry=0x401000, arg=0x33fdb0) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0081eb58) 6 0x7efc19ea RtlCreateUserThread(process=0x33fdb0, descr=(nil), suspended=10, stack_addr=0x0(nil), stack_reserve=0x81eb7c, stack_commit=0x81ef7c, start=(nil), param=0x0(nil), handle_ptr=(nil), id=(nil)) [/source/wine/dlls/ntdll/thread.c:411] in ntdll (0x0081f398) 7 0xf756f92f start_thread+0xbf() in libpthread.so.0 (0x0081f498) Backtracing for thread 002d in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0xf7711430 (0x0071ea04) 1 0x7ee155f4 SleepEx+0x2a(timeout=0x00c8, alertable=0) [/source/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0071ea34) 2 0x7ee155c0 Sleep+0x25(timeout=0x00c8) [/source/wine/dlls/kernel32/sync.c:97] in kernel32 (0x0071ea54) 3 0x0040103a Boom::crash_func+0x3a(void_ptr=0x33fda4) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:25] in multiplethreads (0x0071ea68) 4 0x7efbad44 call_thread_func+0xc() in ntdll (0x0071ea78) 5 0x7efbad82 call_thread_entry_point+0x34(entry=0x401000, arg=0x33fda4) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0071eb58) 6 0x7efc19ea RtlCreateUserThread(process=0x33fda4, descr=(nil), suspended=10, stack_addr=0x0(nil), stack_reserve=0x71eb7c, stack_commit=0x71ef7c, start=(nil), param=0x0(nil), handle_ptr=(nil), id=(nil)) [/source/wine/dlls/ntdll/thread.c:411] in ntdll (0x0071f398) 7 0xf756f92f start_thread+0xbf() in libpthread.so.0 (0x0071f498) Backtracing for thread 002c in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0x0040105b Boom::crash_func+0x5b(void_ptr=0x33fd98) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:29] in multiplethreads (0x0061ea68) 1 0x7efbad44 call_thread_func+0xc() in ntdll (0x0061ea78) 2 0x7efbad82 call_thread_entry_point+0x34(entry=0x401000, arg=0x33fd98) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0061eb58) 3 0x7efc19ea RtlCreateUserThread(process=0x33fd98, descr=(nil), suspended=0, stack_addr=0x0(nil), stack_reserve=0x61eb7c, stack_commit=0x61ef7c, start=(nil), param=0x0(nil), handle_ptr=(nil), id=(nil)) [/source/wine/dlls/ntdll/thread.c:411] in ntdll (0x0061f398) 4 0xf756f92f start_thread+0xbf() in libpthread.so.0 (0x0061f498) Backtracing for thread 0029 in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0xf7711430 (0x0033fcfc) 1 0x7ee155f4 SleepEx+0x2a(timeout=0x00f0, alertable=0) [/source/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0033fd2c) 2 0x7ee155c0 Sleep+0x25(timeout=0x00f0) [/source/wine/dlls/kernel32/sync.c:97] in kernel32 (0x0033fd4c) 3 0x0040103a Boom::crash_func+0x3a(void_ptr=0x33fd8c) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:25] in multiplethreads (0x0033fd60) 4 0x0040112e main+0xae(argc=0x0001, argv=0x40c338) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:65] in multiplethreads (0x0033fdbc) 5 0x0040139c mainCRTStartup+0x173() [f:\vs70builds\6030\vc\crtbld\crt\src\crt0.c:259] in multiplethreads (0x0033fe98) 6 0x7ee05b3c start_process+0x137(peb=0x7ffdf000) [/source/wine/dlls/kernel32/process.c:988] in kernel32 (0x0033fed8) 7 0x7efbad44 call_thread_func+0xc() in ntdll (0x0033fee8) 8 0x7efbad82 call_thread_entry_point+0x34(entry=0x7ee05a05, arg=0x7ffdf000) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0033ffc8) 9 0x7ef93ecf LdrInitializeThunk(kernel_start=0x7ffdf000, unknown2=0, unknown3=0, unknown4=0) [/source/wine/dlls/ntdll/loader.c:2621] in ntdll (0x0033ffe8) 0xf779b42e: jmp 0xf779b423 ...

April 28, 2010