[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@winehq.org Reporter: i30817@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.
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #1 from paulo i30817@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).
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #2 from paulo i30817@gmail.com --- here is the output of a run with
WINEDEBUG="+seh,+tid,+ddraw,+d3d" wine ./EoCApp.exe >>log2.txt 2>&1
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #3 from paulo i30817@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #4 from paulo i30817@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).
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #5 from paulo i30817@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
https://bugs.winehq.org/show_bug.cgi?id=36854
paulo i30817@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #48947|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=36854
gulain@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gulain@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=36854
unsuspicious.fakename+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |unsuspicious.fakename+wine@ | |gmail.com
--- Comment #6 from unsuspicious.fakename+wine@gmail.com --- Does this happen with US keymap? ( http://appdb.winehq.org/commentview.php?iAppId=16210&iVersionId=30610&am... )
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #7 from gulain@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.
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #8 from paulo i30817@gmail.com --- Created attachment 49008 --> http://bugs.winehq.org/attachment.cgi?id=49008 operf
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #9 from paulo i30817@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.
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #10 from paulo i30817@gmail.com --- Ok, with the us keymap it DOES get into the menu reliably.
http://bugs.winehq.org/show_bug.cgi?id=36854
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #11 from Béla Gyebrószki gyebro69@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
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #12 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 49037 --> http://bugs.winehq.org/attachment.cgi?id=49037 winedbg backtrace(s) while EoCApp.exe is hung after starting
http://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #13 from Ken Thomases ken@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
Karol Herbst wine@karolherbst.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@karolherbst.de
--- Comment #14 from Karol Herbst wine@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #15 from Karol Herbst wine@karolherbst.de --- seems like I was wrong, but the X11DRV_ToUnicodeEx function is also entered with a key code wich results into bufW = "
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #16 from Karol Herbst wine@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?
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #17 from Karol Herbst wine@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #18 from Karol Herbst wine@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #19 from Ken Thomases ken@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #20 from Karol Herbst wine@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #21 from Karol Herbst wine@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)?
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #22 from Ken Thomases ken@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #23 from Karol Herbst wine@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #24 from Karol Herbst wine@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).
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #25 from Ken Thomases ken@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:
- 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.
- 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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #26 from Karol Herbst wine@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:
- 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.
- 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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #27 from Karol Herbst wine@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).
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #28 from Karol Herbst wine@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #29 from paulo i30817@gmail.com --- This is uncomfirmed but comment 14 confirms it (and there is even a workaround and patch linked).
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #30 from Karol Herbst wine@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?
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #31 from paulo i30817@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #32 from paulo i30817@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #33 from paulo i30817@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?
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #34 from paulo i30817@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #35 from paulo i30817@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #36 from Karol Herbst wine@karolherbst.de --- I am sure you have to build a 32bit version of wine for divinity.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #37 from Karol Herbst wine@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #38 from paulo i30817@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #39 from paulo i30817@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #40 from Karol Herbst wine@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #41 from paulo i30817@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
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #42 from Karol Herbst wine@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?
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #43 from paulo i30817@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #44 from Karol Herbst wine@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #45 from joaopa jeremielapuree@yahoo.fr --- Is still a bug with current wine (wine-3.19)?
https://bugs.winehq.org/show_bug.cgi?id=36854
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=36854
leestrobel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leestrobel@gmail.com
--- Comment #46 from leestrobel@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.
https://bugs.winehq.org/show_bug.cgi?id=36854
qsniyg qsniyg@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg@mail.com
--- Comment #47 from qsniyg qsniyg@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...
-
wine-bugs＠winehq.org -
WineHQ Bugzilla