[Bug 36854] New: Divinity Original Sin Gog version does not display graphics after patch
https://bugs.winehq.org/show_bug.cgi?id=36854 Bug ID: 36854 Summary: Divinity Original Sin Gog version does not display graphics after patch Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: i30817(a)gmail.com The only thing that happens is that the cursor changes shape to the game cursor and then the game surface hangs forever with the image of whatever happened to be in the background of the screen before executing the game. Without the patch, but with the game removed from it's prefix, the prefix deleted, the game always crashes because of the missing d3dcompiler. Installing d3dx9_36 with wine tricks leads me to the same result as with the patch (cursor hanging forever), which is leading me to suspect the patch is 'helpfully' dumping some stuff in the windows dir. The original setup exe comes with redistributables it tries to install at the end for directx9, dotnet3.5 and vcrun2008, which i obviously cancelled before they could hose the install. It still gave a popup error but appears to have installed. I have no idea why that would run, and not run if i extracted from the prefix, reset it and ran it again (d3dcompiler error). If you tell me which logging channels you want i can do a log of the install, the patch, and trying to run it. This gog game is affected by http://bugs.winehq.org/show_bug.cgi?id=32451 the workaround /nogui doesn't work, the popup error that happens at the end happens much earlier, before the game files are copied. So i had to build a biarch wine git version patched to increase the contant mentioned in one of the posts. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #1 from paulo <i30817(a)gmail.com> --- Now i can't even enter the game without the patch after deleting the prefix and reinstalling. Seems to be essentially random (and unlikely). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #2 from paulo <i30817(a)gmail.com> --- here is the output of a run with WINEDEBUG="+seh,+tid,+ddraw,+d3d" wine ./EoCApp.exe >>log2.txt 2>&1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #3 from paulo <i30817(a)gmail.com> --- Created attachment 48947 --> https://bugs.winehq.org/attachment.cgi?id=48947 WINEDEBUG="+seh,+tid,+ddraw,+d3d" wine ./EoCApp.exe >>log2.txt 2>&1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #4 from paulo <i30817(a)gmail.com> --- Uh, i forgot this was a dx9 game, here is a trace including it. It's smaller than the other, possibly because i killed it faster (after all the problem manifests very quickly, so i don't see the point of waiting). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #5 from paulo <i30817(a)gmail.com> --- Created attachment 48948 --> https://bugs.winehq.org/attachment.cgi?id=48948 WINEDUG="+seh,+tid,+ddraw,+d3d,+d3d9" wine ./EoCApp.exe >>log2.txt 2>&1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 paulo <i30817(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #48947|0 |1 is obsolete| | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 gulain(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gulain(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 unsuspicious.fakename+wine(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |unsuspicious.fakename+wine@ | |gmail.com --- Comment #6 from unsuspicious.fakename+wine(a)gmail.com --- Does this happen with US keymap? ( http://appdb.winehq.org/commentview.php?iAppId=16210&iVersionId=30610&iThrea... ) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #7 from gulain(a)gmail.com --- (In reply to unsuspicious.fakename+wine from comment #6)
Does this happen with US keymap?
Indeed, with US keymap, I can access the menu, launch a new game or load a game. Moving characters around is OK. The game crashes when I try to access the inventory though. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #8 from paulo <i30817(a)gmail.com> --- Created attachment 49008 --> http://bugs.winehq.org/attachment.cgi?id=49008 operf -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #9 from paulo <i30817(a)gmail.com> --- output of operf --vmlinux /usr/lib/debug/boot/vmlinux-$(uname -r) -t -g wine EoCApp.exe opreport --merge tgid Using /home/i30817/Desktop/DOS/Shipping/oprofile_data/samples/ for samples directory. WARNING: Lost samples detected! See /home/i30817/Desktop/DOS/Shipping/oprofile_data/samples/operf.log for details. CPU: Core 2, speed 2.2e+06 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 90000 CPU_CLK_UNHALT...| samples| %| ------------------ 284 62.5551 unknown CPU_CLK_UNHALT...| samples| %| ------------------ 161 56.6901 vmlinux-3.16.0-3-generic 73 25.7042 libexpat.so.1.6.0 49 17.2535 libfontconfig.so.1.8.0 1 0.3521 gdi32.dll.so 128 28.1938 wine-preloader CPU_CLK_UNHALT...| samples| %| ------------------ 97 75.7812 vmlinux-3.16.0-3-generic 10 7.8125 ld-2.19.so 7 5.4688 libc-2.19.so 6 4.6875 kernel32.dll.so 6 4.6875 ntdll.dll.so 1 0.7812 libpthread-2.19.so 1 0.7812 libwine.so.1.0 30 6.6079 wine64-preloader CPU_CLK_UNHALT...| samples| %| ------------------ 26 86.6667 vmlinux-3.16.0-3-generic 3 10.0000 ld-2.19.so 1 3.3333 libc-2.19.so 12 2.6432 wine CPU_CLK_UNHALT...| samples| %| ------------------ 12 100.000 vmlinux-3.16.0-3-generic I think that time spent on libexpat looks suspicious. That one is a xml parser and there is a winetricks for a xml parser too. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #10 from paulo <i30817(a)gmail.com> --- Ok, with the us keymap it DOES get into the menu reliably. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69(a)gmail.com --- Comment #11 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 49036 --> http://bugs.winehq.org/attachment.cgi?id=49036 +key,+keyboard debug log (German keyboard layout) I also have the reported problem on Fedora 20 when certain keyboard layout is set: Wine comes to an infinite loop when starting the game. Some keyboard layouts that trigger the bug: German(de), French(fr), Dutch(nl), Spanish(es), Brazilian(br), Norwegian(no), Czech(cz). On the other hand English(us), Hungarian(hu), Ukrainian(uk), Polish(pl), Romanian(ro), Italian(it) layouts have no such problem and the game starts fine with them. Fedora 20 X.Org X Server 1.14.4 XFCE 4.10 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #12 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 49037 --> http://bugs.winehq.org/attachment.cgi?id=49037 winedbg backtrace(s) while EoCApp.exe is hung after starting -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #13 from Ken Thomases <ken(a)codeweavers.com> --- That tight loop looks like something I've encountered before with the Mac driver. I fixed it with <http://source.winehq.org/git/wine.git/?a=commit;h=ae2ce18fd669efb797e11ef0e614be309e83fd3f>. The program is basically trying to build an internal model of the keyboard layout. It runs every vkey through ToUnicodeEx(). For keys whose first press produces a dead key, it tries every possible sequence of subsequent keys to see how the dead key modifies those keys. It relies on every sequence eventually clearing the dead state to terminate the search. Some keyboard layouts on the Mac, and apparently X11, can perpetuate the dead key state indefinitely. So, the search loops infinitely. My fix was to detect the dead key state being perpetuated and to manually clear it. It's not clear to me if the X11 APIs allow direct access to the dead key state to compare it like I do in the Mac driver. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 Karol Herbst <wine(a)karolherbst.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine(a)karolherbst.de --- Comment #14 from Karol Herbst <wine(a)karolherbst.de> --- I have the same problem and it seems like the application is looping inside dlls/winex11.drv/keyboard.c:2518 without exiting the loop -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #15 from Karol Herbst <wine(a)karolherbst.de> --- seems like I was wrong, but the X11DRV_ToUnicodeEx function is also entered with a key code wich results into bufW = " -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #16 from Karol Herbst <wine(a)karolherbst.de> --- ^". I also found a "FIXME : should do the above (return 2 for non matching deadchar+char combinations)" comment above the function. Could it be that this missing feature is causing this? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #17 from Karol Herbst <wine(a)karolherbst.de> --- Created attachment 49452 --> https://bugs.winehq.org/attachment.cgi?id=49452 overview of X11DRV_ToUnicodeEx calls I did a nice overview over all calls to X11DRV_ToUnicodeEx. Here we see, that after the first call to X11DRV_ToUnicodeEx with a result of -1 the loop starts. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #18 from Karol Herbst <wine(a)karolherbst.de> --- Created attachment 49453 --> https://bugs.winehq.org/attachment.cgi?id=49453 little patch to fix this issue this fixed it for me, but I don't know if this is right. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #19 from Ken Thomases <ken(a)codeweavers.com> --- (In reply to Karol Herbst from comment #18)
Created attachment 49453 [details] little patch to fix this issue
this fixed it for me, but I don't know if this is right.
It's not right. It turns dead keys into normal keys that just produce a character. Of course, that breaks an important feature of keyboard layouts. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #20 from Karol Herbst <wine(a)karolherbst.de> --- yeah, I already guessed that, but I think the original part isn't right either. At least my hack does start the game for me now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #21 from Karol Herbst <wine(a)karolherbst.de> --- so if I understand this correctly, divinity calls ToUnicodeEx in a loop until it stops returning -1, which means the dead key state vanish. So in the end, there should be something like "X11DRV_ToUnicodeEx IN virtKey 192 scanCode 41 lpKeyState bufW_size 64 flags 0 OUT -1 bufW X11DRV_ToUnicodeEx IN virtKey 192 scanCode 41 lpKeyState bufW_size 64 flags 0 OUT 1 bufW ^" where maybe the data of lpKeyState is different between calls (didn't check this so far)? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #22 from Ken Thomases <ken(a)codeweavers.com> --- I guess that's right. I assume those are logging message that you've hacked in. You could try an approach where the you store information about the last dead key result in the thread data. If you see a repeat (same inputs and same output), then turn the dead key into a normal character. Of course, getting a non-dead key should clear the remembered last dead key state. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #23 from Karol Herbst <wine(a)karolherbst.de> --- Yeah, the wine trace is too verbose for me and I wanted a clear list of function entries. I was thinking about simulating two key presses and check what X11 is doing out of it. I don't found any way how to get the current dead-key state out of the X server, so I already thought about such an approach, too. It won't be perfect, but I guess this should be better than the current state. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #24 from Karol Herbst <wine(a)karolherbst.de> --- currently I try to understand the ToUnicodeEx function a bit more: example ^^: IN ^ OUT -1 "^" IN ^ OUT 1 "^" (though windows prints ^^) example ^a: IN ^ OUT -1 "^" IN a OUT 1 "â" example ^p: IN ^ OUT -1 "^" IN p OUT 2 "^p" I have some questions here: 1. should the first call produce a "^" translation? If not, are there special characters, which should be used for X11? 2. should in the ^p example the second call return "^p", if the first question answer is yes? For me 1. is special dead-key character should be written if there are any and 2. is yes. In the first version I would only care about the first example and use the third one also for ^a (this can be changed later I guess). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #25 from Ken Thomases <ken(a)codeweavers.com> --- (In reply to Karol Herbst from comment #24)
currently I try to understand the ToUnicodeEx function a bit more:
example ^^: IN ^ OUT -1 "^" IN ^ OUT 1 "^" (though windows prints ^^)
example ^a: IN ^ OUT -1 "^" IN a OUT 1 "â"
example ^p: IN ^ OUT -1 "^" IN p OUT 2 "^p"
I'm not entirely sure what the above means. In particular, the input to ToUnicodeEx() is a keystroke along with the key state, but you show a character.
I have some questions here: 1. should the first call produce a "^" translation? If not, are there special characters, which should be used for X11?
I'm not sure what you're asking. First, nothing X11-specific should be returned to the caller of ToUnicodeEx(). It's a Win32 function, so the behavior should be as close as possible to the behavior on Windows (except that the user's keyboard layout may differ on the two platforms). When ToUnicodeEx() returns -1, it indicates that the key was a dead key. The buffer should contain the (non-dead) character which corresponds to the dead key. For example, the app may display that character (perhaps with a special color or style) to indicate the pending dead-key state.
2. should in the ^p example the second call return "^p", if the first question answer is yes?
I believe so, yes. The first keystroke was a dead key. The second keystroke does not combine meaningfully with that dead key. So, the dead key becomes just a normal character. Plus the second keystroke produces a normal character. So, the call returns both characters.
In the first version I would only care about the first example and use the third one also for ^a (this can be changed later I guess).
I didn't understand this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #26 from Karol Herbst <wine(a)karolherbst.de> --- (In reply to Ken Thomases from comment #25)
(In reply to Karol Herbst from comment #24)
currently I try to understand the ToUnicodeEx function a bit more:
example ^^: IN ^ OUT -1 "^" IN ^ OUT 1 "^" (though windows prints ^^)
example ^a: IN ^ OUT -1 "^" IN a OUT 1 "â"
example ^p: IN ^ OUT -1 "^" IN p OUT 2 "^p"
I'm not entirely sure what the above means. In particular, the input to ToUnicodeEx() is a keystroke along with the key state, but you show a character.
yeah, I know. I just meant the virtual keys, which are translated to the characters.
I have some questions here: 1. should the first call produce a "^" translation? If not, are there special characters, which should be used for X11?
I'm not sure what you're asking. First, nothing X11-specific should be returned to the caller of ToUnicodeEx(). It's a Win32 function, so the behavior should be as close as possible to the behavior on Windows (except that the user's keyboard layout may differ on the two platforms).
When ToUnicodeEx() returns -1, it indicates that the key was a dead key. The buffer should contain the (non-dead) character which corresponds to the dead key. For example, the app may display that character (perhaps with a special color or style) to indicate the pending dead-key state.
I see.
2. should in the ^p example the second call return "^p", if the first question answer is yes?
I believe so, yes. The first keystroke was a dead key. The second keystroke does not combine meaningfully with that dead key. So, the dead key becomes just a normal character. Plus the second keystroke produces a normal character. So, the call returns both characters.
In the first version I would only care about the first example and use the third one also for ^a (this can be changed later I guess).
I didn't understand this.
I meant, that I will ignore the "â" case and just put "^a" into the out buffer for now. If this works I will add support for the "â" case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #27 from Karol Herbst <wine(a)karolherbst.de> --- Created attachment 49499 --> https://bugs.winehq.org/attachment.cgi?id=49499 handle two consecutive virtual dead keys This patch handles only cases, where two virtual keys get resolved to dead-keys in consecutive calls. This is enough for fixing the bug without harming other applications (I hope so). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #28 from Karol Herbst <wine(a)karolherbst.de> --- I don't think I will find more time to work on a better patch, but I might be able to improve the latest one if I know what the problems are. I want to keep it rather simple. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #29 from paulo <i30817(a)gmail.com> --- This is uncomfirmed but comment 14 confirms it (and there is even a workaround and patch linked). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #30 from Karol Herbst <wine(a)karolherbst.de> --- (In reply to paulo from comment #29)
This is uncomfirmed but comment 14 confirms it (and there is even a workaround and patch linked).
does the patch work for you, too? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #31 from paulo <i30817(a)gmail.com> --- Didnt work, was it supposed to be in addition to the previous one? By didn't work i mean that changing from english to pt portuguese locks it at start and the opposite still makes it run. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #32 from paulo <i30817(a)gmail.com> --- If you write a patch version that outputs some kind of test and info it might allow you to figure out what's happening different in the pt locale. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #33 from paulo <i30817(a)gmail.com> --- I now tested: 0001-winex11-keyboard-store-dead-key-state-inside-thread-.patch - doesn't work for pt locale 0001-winex11-hack-or-real-fix-for-36854.patch - doesn't work for pt locale Maybe i'm compiling the wine64 'wrong'? The application is a 64 bit program and i have a 64 bit machine so i just did: ~/Downloads/wine-git$ patch -p1 < 0001-winex11-keyboard-store-dead-key-state-inside-thread-.patch ~/Downloads/wine64$ ../wine-git/configure --enable-win64 && make -j2 and ran with that wine. Maybe the 64 bit needs the win32-tools dir and that code is actually used there? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #34 from paulo <i30817(a)gmail.com> --- My wine debug log is stuck on ~ : fixme:console:CONSOLE_DefaultHandler Terminating process 22 on event 0 trace:key:X11DRV_ToUnicodeEx returning -1 with L"~" trace:key:X11DRV_ToUnicodeEx AltGrMask = 0000 fixme:msvcrt:__clean_type_info_names_internal (0x3aa380) stub fixme:msvcrt:__clean_type_info_names_internal (0x6578aca0) stub fixme:msvcrt:__clean_type_info_names_internal (0x67257230) stub -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #35 from paulo <i30817(a)gmail.com> --- Sorry, that comment was not useful because it caught the CTRL+C: I meant the WINEDEBUG=+key,+keyboard ~/Downloads/wine64/wine64 EoCApp.exe indicated like on the German log above that the game was stuck on: trace:key:X11DRV_ToUnicodeEx returning -1 with L"~" trace:key:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:key:X11DRV_ToUnicodeEx (00DC, 002B) : faked state = 0x0000 trace:key:EVENT_event_to_vkey e->keycode = 51 trace:key:X11DRV_ToUnicodeEx Found keycode 51 trace:key:X11DRV_ToUnicodeEx type 2, window 360000c, state 0x0000, keycode 51 trace:key:X11DRV_ToUnicodeEx XmbLookupString needs 0 byte(s) trace:key:X11DRV_ToUnicodeEx nbyte = 0, status 0x3 trace:key:X11DRV_ToUnicodeEx KeyPress : keysym=fe53 (dead_tilde), # of chars=0 / "" trace:key:X11DRV_ToUnicodeEx returning -1 with L"~" trace:key:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:key:X11DRV_ToUnicodeEx (00DC, 002B) : faked state = 0x0000 trace:key:EVENT_event_to_vkey e->keycode = 51 trace:key:X11DRV_ToUnicodeEx Found keycode 51 trace:key:X11DRV_ToUnicodeEx type 2, window 360000c, state 0x0000, keycode 51 trace:key:X11DRV_ToUnicodeEx XmbLookupString needs 0 byte(s) trace:key:X11DRV_ToUnicodeEx nbyte = 0, status 0x3 trace:key:X11DRV_ToUnicodeEx KeyPress : keysym=fe53 (dead_tilde), # of chars=0 / "" trace:key:X11DRV_ToUnicodeEx returning -1 with L"~" trace:key:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:key:X11DRV_ToUnicodeEx (00DC, 002B) : faked state = 0x0000 trace:key:EVENT_event_to_vkey e->keycode = 51 trace:key:X11DRV_ToUnicodeEx Found keycode 51 trace:key:X11DRV_ToUnicodeEx type 2, window 360000c, state 0x0000, keycode 51 trace:key:X11DRV_ToUnicodeEx XmbLookupString needs 0 byte(s) trace:key:X11DRV_ToUnicodeEx nbyte = 0, status 0x3 trace:key:X11DRV_ToUnicodeEx KeyPress : keysym=fe53 (dead_tilde), # of chars=0 / "" etc -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #36 from Karol Herbst <wine(a)karolherbst.de> --- I am sure you have to build a 32bit version of wine for divinity. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #37 from Karol Herbst <wine(a)karolherbst.de> --- Created attachment 50633 --> https://bugs.winehq.org/attachment.cgi?id=50633 updated patch with two TRACE messages @paulo I've added two TRACE messages to verify the correct version is used -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #38 from paulo <i30817(a)gmail.com> --- (In reply to Karol Herbst from comment #36)
I am sure you have to build a 32bit version of wine for divinity.
Oh, i know what happened. It needs 32 bits, but i had a 64 bits prefix so it fell back to using the system wine. I didn't pay enough attention when testing with 32 bits so i thought this message: wine: '/home/i30817/.wine' is a 64-bit installation, it cannot be used with a 32-bit wineserver. was about the executable not the prefix So i need to test again, sorry and wait a moment. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #39 from paulo <i30817(a)gmail.com> --- Yeah, that fixed it. I used the last patch you posted with traces and it didn't trigger a trace, just some stuff that happens in ubuntu/the game thats 'normal' It runs (with winetricks -q d3d9x_36 vcrun2008 ) ~/Downloads/wine32/wine EoCApp.exe p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory fixme:iphlpapi:NotifyAddrChange (Handle 0x17be7e0, overlapped 0x17be7ec): stub wine: configuration in '/home/i30817/.wine' has been updated. p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory fixme:win:EnumDisplayDevicesW ((null),0,0x18df2d8,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x18de4a8,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x18de7a8,0x00000000), stub! fixme:ddraw:ddraw7_Initialize Ignoring guid {aeb2cdd4-6e41-43ea-941c-8361cc760781}. fixme:d3d9:Direct3DShaderValidatorCreate9 stub fixme:xinput:XInputGetState (0 0x18defd4) err:ole:CoGetClassObject class {5a508685-a254-4fba-9b82-9a24b00306af} not registered err:ole:CoGetClassObject no class object {5a508685-a254-4fba-9b82-9a24b00306af} could be created for context 0x1 err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded fixme:thread:SetThreadIdealProcessor (0x1e4): stub -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #40 from Karol Herbst <wine(a)karolherbst.de> --- (In reply to paulo from comment #39)
Yeah, that fixed it. I used the last patch you posted with traces and it didn't trigger a trace, just some stuff that happens in ubuntu/the game thats 'normal'
you still need to add WINEDEBUG=+key,+keyboard to get those -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #41 from paulo <i30817(a)gmail.com> --- Created attachment 50643 --> https://bugs.winehq.org/attachment.cgi?id=50643 log of last patch with pt locale run with WINEDEBUG=+key,+keyboard ~/Downloads/wine32/wine EoCApp.exe 2&> log.txt The requested pt locale log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #42 from Karol Herbst <wine(a)karolherbst.de> --- (In reply to paulo from comment #41)
Created attachment 50643 [details] log of last patch with pt locale run with WINEDEBUG=+key,+keyboard ~/Downloads/wine32/wine EoCApp.exe 2&> log.txt
The requested pt locale log
It looks like to hit a different error. In your log file is stated, that two dead keys are handled correctly: "~" and "`", allthough the latter one is recognized as L"\0000". Maybe this is another bug, that "`" isn't mapped right. But I think this looks alright. Does the game work for you as expected? Character input in text fields fine and such? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #43 from paulo <i30817(a)gmail.com> --- In the game i tried to create a new profile (which pops a text input box for the name), and some punctuation marks don't register, but that may be the game itself forbidding them (mostly compound letters with accent like é, ã etc but also <, >, ' and i'm sure others). I tried notepad and they work there so i'm not worried, i think the game never intended these to be legal names. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 --- Comment #44 from Karol Herbst <wine(a)karolherbst.de> --- (In reply to paulo from comment #43)
In the game i tried to create a new profile (which pops a text input box for the name), and some punctuation marks don't register, but that may be the game itself forbidding them (mostly compound letters with accent like é, ã etc but also <, >, ' and i'm sure others).
and I thought it was working for me :/ or maybe only some of them. I could retry if you want, but its good to now, that my patch also works for others and not only me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #45 from joaopa <jeremielapuree(a)yahoo.fr> --- Is still a bug with current wine (wine-3.19)? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 pattietreutel <katyaberezyaka(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 leestrobel(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leestrobel(a)gmail.com --- Comment #46 from leestrobel(a)gmail.com --- I am seeing what seems to be a similar bug when trying to run the 64-bit version of Divinity: Original Sin - Enhanced Edition from GOG with Wine version 5.7. The game hangs when trying to create the initial window. I have a US PC though, with (I presume) a US keymap, which according to the previous comments should work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36854 qsniyg <qsniyg(a)mail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg(a)mail.com --- Comment #47 from qsniyg <qsniyg(a)mail.com> --- (In reply to leestrobel from comment #46)
I am seeing what seems to be a similar bug when trying to run the 64-bit version of Divinity: Original Sin - Enhanced Edition from GOG with Wine version 5.7. The game hangs when trying to create the initial window. I have a US PC though, with (I presume) a US keymap, which according to the previous comments should work.
Try wine 5.12, I believe the issue you're reporting should be fixed by https://source.winehq.org/git/wine.git/commit/1dc3383389da636617bfa7d9570e7d... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla