http://bugs.winehq.org/show_bug.cgi?id=13683
Summary: Ultima IX: Mouse pointer missing when reading books, under inventory Product: Wine Version: 1.0-rc3 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: rixa@cs.tut.fi
When opening an in-game book for reading, there is nothing to work as a mouse pointer to help clicking the page corners or other clickable elements with. The books do work, but finding the correct spot to click without any pointer is quite hard. Saving and loading the game as well as selecting spells are also implemented by an in-game book, so these functions are likewise affected.
A similar issue affects using the inventories and toolbelt, though the pointer is not so much missing as being drawn under instead of over the inventory panel. Otherwise the game seems to work well.
I'm running wine 1.0rc3 on a CentOS 5 system with a GeForce4 Ti 4800 graphics card and nVidia proprietary drivers version 96.43.05.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #1 from Rixa rixa@cs.tut.fi 2008-07-21 10:24:59 --- Details of screenshots illustrating how the pointer is drawn under the backpack and utility belt: http://www.cs.tut.fi/~rixa/u9bug.png
http://bugs.winehq.org/show_bug.cgi?id=13683
Lorenzo Miniero rainmaker@icgag.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from Lorenzo Miniero rainmaker@icgag.it 2008-08-03 03:47:58 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=13683
soulmata soulmata@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |soulmata@gmail.com
--- Comment #3 from soulmata soulmata@gmail.com 2008-10-21 01:06:49 --- *** Bug 15697 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #4 from Austin English austinenglish@gmail.com 2009-04-20 12:28:38 --- Is this still an issue in current (1.1.19 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #5 from Rixa rixa@cs.tut.fi 2009-04-22 14:13:24 --- Yes. I just updated to 1.1.19 and it behaves the same as before.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #6 from Austin English austinenglish@gmail.com 2009-10-29 15:25:38 --- Is this still an issue in current (1.1.32 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #7 from Rixa rixa@cs.tut.fi 2009-10-31 15:48:26 --- Yes. I just updated to 1.1.32 and it behaves the same as before.
http://bugs.winehq.org/show_bug.cgi?id=13683
Michelle D'israeli michelle_disraeli@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michelle_disraeli@hotmail.c | |om
--- Comment #8 from Michelle D'israeli michelle_disraeli@hotmail.com 2010-03-07 10:26:40 --- I've just tested under Wine 1.1.40, and this issue still persists. As, for me, this prevents interaction with the Journal (the in-game menu), this makes the game not really playable.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #9 from Rixa rixa@cs.tut.fi 2010-05-22 11:14:59 --- I wouldn't otherwise spam this bug since there is nothing new to say, but since it was requested to give wine 1.2-rc1 a good testing, I thought I'd report that this issue still remains.
http://bugs.winehq.org/show_bug.cgi?id=13683
johnniewaves@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnniewaves@hotmail.com
--- Comment #10 from johnniewaves@hotmail.com 2011-02-01 12:16:27 CST --- It has been another 7 months since last post - this bug is still here as of February 2011 - on Mac Os X Snow Leo.
Same issues - tested with Wine 1.3.12
http://bugs.winehq.org/show_bug.cgi?id=13683
Ruei-Yuan Lu RueiYuan.Lu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |RueiYuan.Lu@gmail.com
--- Comment #11 from Ruei-Yuan Lu RueiYuan.Lu@gmail.com 2012-11-04 01:25:21 CST --- This bug still exists in 1.5.16
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #12 from Rixa rixa@cs.tut.fi 2013-06-12 09:21:19 CDT --- Still a problem with wine 1.6-rc1.
Having looked at a few youtube videos, there should be a mouse pointer in the shape of a gauntlet that appears for inventory management, books and such whenever there's clicking to be done. It's separate from the green in-scene pointer, which I suppose is drawn as it should be.
http://bugs.winehq.org/show_bug.cgi?id=13683
Christopher Thielen christopher@thielen.co changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christopher@thielen.co
--- Comment #13 from Christopher Thielen christopher@thielen.co --- I can confirm as of Wine 1.7.8, this bug still persists.
gog.com has a DRM-free version of this game for $5. If a proven Direct3D Wine contributor would like, I'd be glad to buy the game for them in exchange for fixing this bug!
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #14 from Christopher Thielen christopher@thielen.co --- For anybody trying to play the game in the meantime, Ctrl+J brings up the journal, Ctrl+S flips to the Save game screen and you can get away with some interactions by moving the mouse around and guessing. Text, for example, highlights if the 'cursor' (which really should be visible!) is over it.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #15 from Christopher Thielen christopher@thielen.co --- To expand on Rixa's comment: the game essentially has two cursors. When you exit the perspective mode by hitting 'q' or by opening a book, the gauntlet cursor appears alongside the regular cursor (in some books it is only the gauntlet cursor). This 'gauntlet' cursor never appears at all, so, to anybody trying to squash this bug, it isn't some Z-index type bug (I don't imagine) but rather that the resource for that gauntlet cursor is simply not being drawn at all, under any circumstance, for whatever reason.
http://bugs.winehq.org/show_bug.cgi?id=13683
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #16 from Stefan Dösinger stefan@codeweavers.com --- It is possible that the game is using an overlay. Or at least trying to use one, but not actually doing it because we do not set overlay capability flags.
Does the second pointer work on Windows 7 with Aero enabled? If not, it's quite certainly an overlay. (If it works it can still be an overlay. Win7 still supports them, but with some limitations compared to WinXP.)
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #17 from Christopher Thielen christopher@thielen.co --- I can do the Windows 7 with Aero enabled-test if absolutely necessary but do not readily have access to Windows 7. I think it is a safe bet that it _does_ work as gog.com is actively selling this game and cites it as being compatible with "Windows XP, Vista, 7, and 8" (http://www.gog.com/game/ultima_9_ascension).
To test the overlay theory, is the problem that Wine does not support DirectX 7-style overlays or that Wine merely does not report the flags correctly?
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #18 from Stefan Dösinger stefan@codeweavers.com --- It does not support them. It once had hacky code that made VLC's ddraw renderer happy, which I used to implement the YUV shader code. I removed this code since it was poorly designed and in the way. Even with that code in place Wine did not report the necessary caps.
Note that the lack of overlay support is just a theory. It's in no way certain that this is the cause.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #19 from Rixa rixa@cs.tut.fi --- I'll gladly pitch in with another gifted copy of the game from gog.com for a proven Direct3D Wine contributor, if that gets them interested in looking into the bug.
http://bugs.winehq.org/show_bug.cgi?id=13683
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #20 from Christopher Thielen christopher@thielen.co --- Created attachment 47558 --> http://bugs.winehq.org/attachment.cgi?id=47558 Log of WINEDEBUG=warn+ddraw,warn+d3d,warn+d3d_surface for a ~20s gameplay which includes the case where the missing second cursor should show/hide
The attachment is gzipp'ed as the original log is ~ 35 MB. The gzipped version is considerably smaller.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #21 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #20)
Created attachment 47558 [details] Log of WINEDEBUG=warn+ddraw,warn+d3d,warn+d3d_surface for a ~20s gameplay which includes the case where the missing second cursor should show/hide
The attachment is gzipp'ed as the original log is ~ 35 MB. The gzipped version is considerably smaller.
Based on the wine-devel emails not seeing anything really obvious... Have you tried running a WINEDEBUG=+cursor,+icon,+resource log? It's possible that the application is trying to use a "traditional" cursor.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #22 from Christopher Thielen christopher@thielen.co --- I haven't tried +cursor,+icon,+resource yet but will now.
I've been trying to figure out through what mechanism the game draws a cursor - I placed some TRACE statements in the d3d9_device "ShowCursor" code and saw no change in the output. I'm now trying to identify exactly what code paths cause the X cursor to appear/disappear with the hopes that I can figure out _how_ the u9.exe binary is polling for the cursor position and, hopefully, if it's drawing the cursor by itself (e.g. not with DX's ShowCursor), determine the particular resource that is failing to draw.
I'll post my findings here and follow-up questions on wine-devel.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #23 from Christopher Thielen christopher@thielen.co --- This bug persists under Wine 1.7.12.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #24 from Christopher Thielen christopher@thielen.co --- Created attachment 47562 --> http://bugs.winehq.org/attachment.cgi?id=47562 Brief gameplay with WINEDEBUG=+cursor,+icon,+resource including toggling 'Q' a few times to attempt to get the second cursor to show up
As per Erich Hoover's suggestion, here is the beginnings 20 seconds of the game with WINEDEBUG=+cursor,+icon,+resource, attempting to figure out how the game draws a cursor in the first place.
TRACE lines for cursor and icon do show up, though I cannot say whether they're significant:
trace:icon:ICO_LoadIcon 0x360000 0x360086 trace:cursor:CreateIconFromResourceEx 0x37dc22 (1128 bytes), ver 00030000, 32x32 icon trace:cursor:ungrab_clipping_window no longer clipping trace:icon:DrawIconEx (hdc=0x2002d,pos=23.4,hicon=0x10044,extend=32.32,istep=0,br=(nil),flags=0x0000000b) trace:resource:LdrFindResource_U module 0x7e920000 type #0018 name #0002 lang 0000 level 3 trace:resource:find_entry_by_id root 0x7e93f3b4 dir 0x7e93f3b4 id 0018 not found trace:cursor:LoadCursorW (nil), #7f00 trace:resource:LoadImageW ((nil),#7f00,2,0,0,0x00008040) trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040
In particular, this line may correlate to my pressing 'Q' (i.e. when the cursor should switch):
trace:cursor:LoadIconW (nil), #7f05
Is there a way to patch the code quickly to dump the cursor resource being used by the LoadIconW in order to confirm its the missing cursor?
Here are the total cursor:LoadIconW, which should at least toggle between two cursors:
trace:cursor:LoadIconW (nil), #7f05 trace:cursor:LoadIconW (nil), #7f05 trace:cursor:LoadIconW 0x7edb0000, L"" trace:cursor:LoadIconW (nil), L"" trace:cursor:LoadIconW (nil), #7f05 trace:cursor:LoadIconW 0x7edf0000, #0001 trace:cursor:LoadIconW 0x7edb0000, #0001 trace:cursor:LoadIconW (nil), #7f05 trace:cursor:LoadIconW (nil), #7f00 trace:cursor:LoadIconW (nil), #7f00
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #25 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #24)
... In particular, this line may correlate to my pressing 'Q' (i.e. when the cursor should switch):
trace:cursor:LoadIconW (nil), #7f05
Unlikely, "(nil), #7f05" corresponds to IDI_WINLOGO (default application icon).
Is there a way to patch the code quickly to dump the cursor resource being used by the LoadIconW in order to confirm its the missing cursor?
Yes, it's a little complicated though.
Here are the total cursor:LoadIconW, which should at least toggle between two cursors: ... trace:cursor:LoadIconW (nil), #7f05
Load default cursor.
trace:cursor:LoadIconW 0x7edb0000, L"" trace:cursor:LoadIconW (nil), L""
This is unusual, but it probably corresponds to resource #0000.
... trace:cursor:LoadIconW 0x7edf0000, #0001 trace:cursor:LoadIconW 0x7edb0000, #0001 ...
Load icon resource ID #0001 from the given module/application. So, if you open the application EXE with one of the many icon viewing applications then you will probably find the cursor embedded in the application.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #26 from Christopher Thielen christopher@thielen.co --- I could be wrong but using two different apps found while Googling, the main .exe appears to only have one icon (the desktop icon) and no cursors. But the code is referencing at least two resources, right?
I used WINEDEBUG=+cursor,+icon,+resource and did a few tests: the first launching the game, pressing 'Q' to attempt to toggle the missing cursor on then off, then quitting the game (1), the second launching the game, pressing the toggle twice then quitting the game (2), and the last test trying to toggle the hidden cursor 10 times then quitting. I made three logs from these three tests and tried to find any cursor-related API calls which increased due to the difference in testing but at least looking at:
TRACE counts found using grep:
cursor:SetCursor 1: 7 2: 7 3: 5
cursor:LoadCursorW 1: 23 2: 23 3: 23
cursor:LoadIconW 1: 4 2: 4 3: 4
So, it looks like whatever the game is doing where it should be showing that cursor, it's not related to those three calls.
Is it possible the cursor is set and then a property is used to show/hide it that I could look for? I think finding an API call that corresponds to that 'Q' command toggle would be really helpful.
(FYI for documentation, there's some technical information on the game's file formats here but nothing about cursors: http://wiki.ultimacodex.com/wiki/Ultima_IX_Internal_Formats)
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #27 from Christopher Thielen christopher@thielen.co --- Some kind person wrote tools for examining the data files: http://bursik.de/ultima/tools/downloads/u9tools.zip.
I'll try later to figure out at least where the missing cursor image/resource/icon is kept in the data files (maybe the bitmap*.* files) and see if I can't trace where it gets loaded and what happens to it from there, e.g. used as a cursor, turned into a D3D surface, etc.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #28 from Christopher Thielen christopher@thielen.co --- I believe I've found the resource at least. I wrote a sloppy port of the linked u9tools.zip's u9bmp to run under Linux with SDL and simply dump all the resources as .bmp files (there are around 8,000).
The file static/bitmap* contain textures but also 2D items like what appears in the backpack as well as the missing cursor!
So in the very least, I now know which file is opened to load this missing cursor resource from. Perhaps I can trace from the fopen() call and see what happens to these resources - I'll try first and see if they end up as regular cursors, else I imagine they're just D3D surfaces. Either way, you'd think they'd show up.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #29 from Christopher Thielen christopher@thielen.co --- I'm wondering if maybe the game is using the regular user32 cursor stuff.
Looking at the dumped resources, the game actually has dozens of different bitmaps depending on what the cursor is "holding" (the missing cursor is shaped like a hand that can drag items around).
I re-ran the WINEDEBUG output but added +timestamp to help make sense of some of it. Here's what I found, searching for and excluding certain strings to bring down the log noise:
(Timestamps start at 708 and end at 1100 - I take it those units are seconds?)
In particular, there are calls to CopyImage and I added some TRACEs to the codepath to see that it follows the IMAGE_ICON,IMAGE_CURSOR case and, in particular, hits a case where somebody left a FIXME:
if (icon->rsrc && (flags & LR_COPYFROMRESOURCE)) res = CURSORICON_Load( icon->module, icon->resname, desiredx, desiredy, depth, !icon->is_icon, flags ); else { // GAME HITS THIS CODE PATH res = CopyIcon( hnd ); /* FIXME: change size if necessary */ }
Does this mean anything to anyone? Am I correct in assuming its building cursors using CopyIcon and CreateBitmap?
I tried Googling around for some code to dump these bitmaps to a file to confirm but haven't been able to write anything yet.
$ cat ./maybe_multiple_cursors.log | grep -i "cursor:" | grep -v "X11" | grep -vi "clip" | grep -vi "xinput"
715.053:trace:cursor:LoadCursorA (nil), #7f00 715.132:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.133:trace:cursor:LoadCursorA (nil), #7f00 715.133:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.133:trace:cursor:LoadCursorA (nil), #7f00 715.133:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.133:trace:cursor:LoadCursorA (nil), #7f00 715.133:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.133:trace:cursor:LoadCursorA (nil), #7f01 715.133:trace:cursor:CURSORICON_Load (nil), #7f01, 0x0, depth 32, fCursor 1, flags 0x8040 715.134:trace:cursor:LoadCursorA (nil), #7f00 715.134:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.134:trace:cursor:LoadCursorA (nil), #7f00 715.134:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.134:trace:cursor:LoadCursorA (nil), #7f00 715.134:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.134:trace:cursor:LoadCursorA (nil), #7f00 715.134:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.134:trace:cursor:LoadCursorA (nil), #7f00 715.134:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.134:trace:cursor:LoadCursorA (nil), #7f00 715.134:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.516:trace:cursor:LoadCursorW (nil), #7f00 715.516:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.606:trace:cursor:LoadIconA (nil), #7f05 715.612:trace:cursor:LoadIconW (nil), #7f05 715.612:trace:cursor:CURSORICON_Load (nil), #7f05, 0x0, depth 32, fCursor 0, flags 0x8040 715.613:trace:cursor:GetIconInfoExW 0x10028 => 32x32 715.618:trace:cursor:LoadIconW (nil), #7f05 715.618:trace:cursor:CURSORICON_Load (nil), #7f05, 0x0, depth 32, fCursor 0, flags 0x8040 715.618:trace:cursor:LoadCursorW (nil), #7f00 715.618:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.619:trace:cursor:CopyImage hnd=0x10028, type=1, desiredx=16, desiredy=16, flags=0 715.622:trace:cursor:LoadCursorA (nil), #7f00 715.649:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.649:trace:cursor:LoadCursorA (nil), #7f00 715.649:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f00 715.650:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f00 715.650:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f01 715.650:trace:cursor:CURSORICON_Load (nil), #7f01, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f00 715.650:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f00 715.650:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f00 715.650:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.650:trace:cursor:LoadCursorA (nil), #7f00 715.650:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.651:trace:cursor:LoadCursorA (nil), #7f00 715.651:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.651:trace:cursor:LoadCursorA (nil), #7f00 715.651:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.651:trace:cursor:CURSORICON_Load (nil), #7f05, 0x0, depth 32, fCursor 0, flags 0x8040 715.651:trace:cursor:LoadCursorA (nil), #7f00 715.651:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.710:trace:cursor:CopyImage hnd=0x10036, type=1, desiredx=16, desiredy=16, flags=0 715.801:trace:cursor:LoadCursorW (nil), #7f00 715.801:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.801:trace:cursor:LoadCursorW (nil), #7f00 715.801:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.832:trace:cursor:LoadCursorW (nil), #7f00 715.832:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.832:trace:cursor:LoadCursorW (nil), #7f00 715.832:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.833:trace:cursor:LoadCursorW (nil), #7f00 715.833:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.877:trace:cursor:LoadCursorW (nil), #7f01 715.877:trace:cursor:CURSORICON_Load (nil), #7f01, 0x0, depth 32, fCursor 1, flags 0x8040 715.929:trace:cursor:LoadCursorW (nil), #7f00 715.929:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.929:trace:cursor:LoadCursorW (nil), #7f00 715.952:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.952:trace:cursor:LoadCursorW (nil), #7f00 715.952:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.952:trace:cursor:LoadCursorW (nil), #7f00 715.952:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 715.952:trace:cursor:LoadCursorW (nil), #7f00 715.952:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.008:trace:cursor:LoadCursorW (nil), #7f00 716.009:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.009:trace:cursor:LoadCursorW (nil), #7f00 716.009:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.009:trace:cursor:LoadCursorW (nil), #7f00 716.009:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.037:trace:cursor:LoadCursorW (nil), #7f00 716.037:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.037:trace:cursor:LoadCursorW (nil), #7f00 716.037:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.037:trace:cursor:CURSORICON_Load 0x7e330000, #0016, 0x0, depth 32, fCursor 0, flags 0x0000 716.037:trace:cursor:CURSORICON_Load 0x7e330000, #0019, 0x0, depth 32, fCursor 0, flags 0x0000 716.038:trace:cursor:CURSORICON_Load 0x7e330000, #001c, 0x0, depth 32, fCursor 0, flags 0x0000 716.038:trace:cursor:LoadCursorW (nil), #7f00 716.038:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.038:trace:cursor:LoadCursorW (nil), #7f00 716.038:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.038:trace:cursor:LoadCursorW (nil), #7f00 716.038:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 716.835:trace:cursor:CreateIconFromResourceEx 0x37dc22 (1128 bytes), ver 00030000, 32x32 icon 717.048:trace:cursor:LoadCursorA (nil), #7f00 717.048:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.048:trace:cursor:SetCursor 0x10022 717.048:trace:cursor:GetIconInfoExW 0x10022 => 32x32 717.223:trace:cursor:set_window_cursor cursor 0x10022 created 1200034 717.242:trace:cursor:LoadCursorA (nil), #7f00 717.243:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.243:trace:cursor:LoadCursorA (nil), #7f00 717.243:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.243:trace:cursor:LoadCursorA (nil), #7f00 717.243:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.243:trace:cursor:LoadCursorA (nil), #7f00 717.243:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.244:trace:cursor:LoadCursorA (nil), #7f01 717.244:trace:cursor:CURSORICON_Load (nil), #7f01, 0x0, depth 32, fCursor 1, flags 0x8040 717.244:trace:cursor:LoadCursorA (nil), #7f00 717.244:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.244:trace:cursor:LoadCursorA (nil), #7f00 717.244:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.244:trace:cursor:LoadCursorA (nil), #7f00 717.244:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.244:trace:cursor:LoadCursorA (nil), #7f00 717.244:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.244:trace:cursor:LoadCursorA (nil), #7f00 717.244:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 717.245:trace:cursor:LoadCursorA (nil), #7f00 717.245:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.386:trace:cursor:LoadIconA 0x400000, (null) 718.386:trace:cursor:CURSORICON_Load 0x400000, (null), 0x0, depth 32, fCursor 0, flags 0x8040 718.387:trace:cursor:LoadCursorA (nil), #7f00 718.387:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.387:trace:cursor:LoadCursorA (nil), #7f00 718.387:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.387:trace:cursor:LoadCursorA (nil), #7f00 718.387:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.388:trace:cursor:LoadCursorA (nil), #7f00 718.388:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.388:trace:cursor:LoadCursorA (nil), #7f00 718.388:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.388:trace:cursor:LoadCursorA (nil), #7f00 718.388:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 718.389:trace:cursor:LoadCursorA (nil), #7f00 718.389:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 719.203:trace:cursor:LoadCursorA (nil), #7f00 719.203:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 719.203:trace:cursor:SetCursor 0x10032 719.255:trace:cursor:LoadCursorW (nil), #7f00 719.255:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 719.256:trace:cursor:GetIconInfoExW 0x10032 => 32x32 719.257:trace:cursor:set_window_cursor cursor 0x10032 created 1600019 719.259:trace:cursor:LoadCursorA (nil), #7f00 719.259:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 719.259:trace:cursor:SetCursor 0x10022 719.274:trace:cursor:LoadIconW (nil), #7f05 719.274:trace:cursor:CURSORICON_Load (nil), #7f05, 0x0, depth 32, fCursor 0, flags 0x8040 719.275:trace:cursor:GetIconInfoExW 0x10036 => 32x32 720.599:trace:cursor:ShowCursor 0, count=-1 728.763:trace:cursor:SetCursor 0x10032 750.856:trace:cursor:LoadCursorW (nil), #7f00 750.856:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 750.857:trace:cursor:LoadIconW (nil), #7f00 750.857:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 0, flags 0x8040 750.885:trace:cursor:CopyImage hnd=0x4004e, type=1, desiredx=16, desiredy=16, flags=0 1091.390:trace:cursor:SetCursor (nil) 1091.392:trace:cursor:LoadCursorA (nil), #7f00 1091.392:trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, flags 0x8040 1091.392:trace:cursor:SetCursor 0x10022
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #30 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to comment #29)
... Looking at the dumped resources, the game actually has dozens of different bitmaps depending on what the cursor is "holding" (the missing cursor is shaped like a hand that can drag items around).
What format is the bitmap data in? If it's not a cursor or icon then it is unlikely that the game is converting it into one before displaying it on the screen (unless Windows does this for you and I'm just not aware of it).
... 1091.390:trace:cursor:SetCursor (nil) ...
SetCursor on "(nil)" is going to disable the user32 cursor. This might be done because the application is switching over to drawing the cursor itself, or it might just do this when it stops using a cursor and before it sets the new cursor. If that's what it is doing (and the timing is screwed up in some way such that it occurs _after_ it sets the new cursor) then that might explain why your cursor disappears. You could test this by having SetCursor not actually do anything (thought it will obviously break other behaviors). It's worth noting that SetCursor returns the old cursor, so some applications use this behavior to "flip" between cursors.
... 1091.392:trace:cursor:LoadCursorA (nil), #7f00 ...
LoadIcon/LoadCursor on "(nil), <anything>" is not going to be an application cursor, this can _only_ be windows cursors. It is worth noting that in your full log you posted a little while ago that you have one LoadCursor call that it is not this way: $ cat output.txt | grep LoadCursor | grep -v '(nil)' trace:cursor:LoadCursorW 0x7edb0000, L""
It's unlikely that that is the cursor you're looking for if the game uses other cursors, but if you have only one cursor that is not working then it is possible (you only need to load the cursor once).
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #31 from Christopher Thielen christopher@thielen.co --- Thanks Erich - I ended up learning quite a bit about User32 cursor stuff reading the docs and disabling bits of Wine's code.
Most of the User32 cursor calls come during initialization; using various cursors during gameplay didn't seem to elicit any calls so I'm somewhat confident that the cursors are not drawn using the User32 stuff.
I believe the only other viable option would be for them to be D3D surfaces which unfortunately is a lot harder to debug.
Using the fan-made tools I found I was able to dump the contents of the major "bitmaps" file, which contained the various enumerations of the missing cursor (by itself, holding one object, holding another object), as well as textures clearly used in 3D models. I dumped them as .BMP files and they open just fine, though it should be noted the color is incorrect on the cursors when I open them in Gimp but the bitmaps used as textures on 3D objects look correct. Perhaps this is a clue to what's wrong - incorrect parameters being set on a D3D surface which is supposed to represent the cursor?
I looked through some of the load_texture calls made in WineD3D - there's a few hundred for the initial scene I'm loading - including about 8 that are 32x32 which is roughly the size of the cursor (Wine/OpenGL code modifies the texture sizes to be squares with power-of-two lengths as is required by many 3D drivers).
I'm looking into figuring out how to dump texture data to a file as its loaded so I can confirm the missing cursor is a D3D surface and not anything else (what else could it be?). If that works, perhaps it will be easier to see what flags are being set on the surface by Wine that might make it invisible or behind the rest of the scene.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #32 from Stefan Dösinger stefan@codeweavers.com --- I recommend to run the game on Windows and take a screenshot when a mouse pointer that's not working on Wine is shown. If the mouse pointer shows up on the screen, you have a software (i.e., glide / d3d9) rendered cursor. If it does not show up you have a user32 cursor (since you already ruled out overlays). That should limit your search for the problem somewhat.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #33 from Christopher Thielen christopher@thielen.co --- Hm, that settles that question then. In Windows XP SP3, running the game and hitting Print Screen with the missing cursor on-screen, it _does_ show up in the screenshot.
I guess it's a D3D surface then.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #34 from Christopher Thielen christopher@thielen.co --- Just keeping this bug updated with some more results:
Cross-compiling Wine's D3D9 implementation and running it on Windows XP does _not_ exhibit the missing cursor bug, so the cursor is missing under Wine for reasons not strictly related to Wine's D3D implementation.
For whatever reason yet to be investigated, the code paths between WinXP and Wine differ such that Ultima IX's resource loader is not working correctly.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #35 from Christopher Thielen christopher@thielen.co --- Some more results:
The cursor is loaded from bitmap16.flx (0x1020eb4 bytes into the file) into a heap right before the call to CreateWindow. This is the same method all game texture data is loaded from file (though most are loaded after the CreateWindow call).
The cursor texture does not exist when it is not on screen - you must hit 'Q', 'Control+X' or other dialog-introducing command for it to appear. It is drawn toward the very end of the frame as a 128x128 D3DFMT_A8R8G8B8 8-Mips formatted texture with the actual glove image in the upper-left. It is drawn using two calls to DrawPrimitiveUP.
Given that nGlide is really issuing those commands and doing more or less the same thing for all other game textures, I have not yet been able to determine whether or not this draw command is missing from the Wine rendition.
My hunch is that it is given that this bug shows up both when u9.exe is rendering Glide (->D3D9 via nGlide) or rendering D3D7, it is likely unrelated to render errors. However, it appears the texture is a normal texture loaded just like the others, so it being a texture loading error also doesn't seem likely. Other 2D elements (like the backpack image) are also loaded from bitmap16.flx and appear fine in both renderings.
I'm trying now to confirm that Wine is indeed missing this texture entirely either via dumping texture data with a monkey-patch of wined3d or using apitrace. I can confirm Wine is issuing the same ReadFile command, so the cursor is at least making it off the disk and into a heap.
Note: this is definitely unrelated to the user32 SetCursor stuff.
Any other ideas about what this could be would be appreciated.
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #36 from Christopher Thielen christopher@thielen.co --- I believe I misread the apitrace GL commands. I'm fairly certain the mouse cursor is missing entirely (the texture is not created, or if it is, it is never bound to the GL context).
http://bugs.winehq.org/show_bug.cgi?id=13683
Christopher Thielen cthielen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cthielen@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #37 from Christopher Thielen cthielen@gmail.com --- Some references for future's sake (showing correct Windows behavior, in Wine, the 'hand' cursor never displays and the '3D' one always goes on/off as it should): http://gigi.nullneuron.net/ultima/u9/walk/sit.jpg (hand only, no 3D cursor) http://lparchive.org/Ultima-9/Update%202-1/1c53c0a5442fc16bb51d7ef60f3f36965... (hand and 3D cursor) http://www.pcgameshardware.de/screenshots/662x/2011/09/Ultima-IX.jpg (3D cursor only)
http://bugs.winehq.org/show_bug.cgi?id=13683
Xodetaetl dev@xod.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dev@xod.me
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #38 from Christopher Thielen cthielen@gmail.com --- I can confirm this bug still exists in Wine 1.7.31.
https://bugs.winehq.org/show_bug.cgi?id=13683
Tristan Miller psychonaut@nothingisreal.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |psychonaut@nothingisreal.co | |m
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #39 from Christopher Thielen cthielen@gmail.com --- I can confirm this bug still exists on 1.7.49.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #40 from Christopher Thielen cthielen@gmail.com --- I've confirmed this bug is due to a missing WM_CAPTURECHANGED message that Wine fails to send near the beginning of execution. The lParam of the message matches the HWND of u9.exe's window.
Windows XP (and likely others) send this message while Wine does not. Forcing Wine to send this message causes the cursor to appear correctly during gameplay.
I'm currently investigating where Wine is supposed to be sending this message. Simple WM_CAPTURECHANGED test examples don't seem to exhibit any incorrect behavior so far.
Note the WM_CAPTURECHANGED message does _not_ happen everytime the cursor is supposed to be shown - it's simply fired off once toward the beginning of execution and this apparently tells u9.exe to load or use the missing cursor.
https://bugs.winehq.org/show_bug.cgi?id=13683
tblodt@icloud.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tblodt@icloud.com
--- Comment #41 from tblodt@icloud.com --- I'm curious: What window is being sent the missing WM_CAPTURECHANGED message, and what window is pointed to by the lparam?
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #42 from Christopher Thielen cthielen@gmail.com --- Using API Monitor, it appears u9.exe is calling SetCapture which ends up calling DDRAW.DLL's DDGetAttachedSurfaceLd which is calling d3d9.dll's CheckFullscreen which is sending WM_CAPTURECHANGED to u9.exe referencing u9.exe's hWnd and setting lParam to the exact same value. In this case it's 0x000d0102 but that's surely specific to my instance of Windows.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #43 from Christopher Thielen cthielen@gmail.com --- I should note the parameter being set to in SetCapture is also u9.exe's HWND.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #44 from Christopher Thielen cthielen@gmail.com --- I'm not sure if this is the relevant difference but I found one difference between Wine and Windows XP regarding a WM_CAPTURECHANGED message where lParam == hWnd.
If you compile a basic Win32 app and call SetCapture() before the main message processing loop, Windows will send you a WM_CAPTURECHANGED message with your own hwnd as the lParam while Wine will send nothing.
I'll attach an example.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #45 from Christopher Thielen cthielen@gmail.com --- Created attachment 52710 --> https://bugs.winehq.org/attachment.cgi?id=52710 Win32 sample which demonstrates the behavioral differences
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #46 from Christopher Thielen cthielen@gmail.com --- Compiling the attached mouseylines.cpp (apologies for the name), Windows produces this:
WM_LBUTTONDOWN: setting capture WM_CAPTURECHANGED: lParam is 590262, hWnd is 590262, equal? = 1 WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 590262, equal? = 0 WM_CAPTURECHANGED: lParam is 0, hWnd is 590262, equal? = 0
while Wine produces this:
WM_LBUTTONDOWN: setting capture WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 65616, equal? = 0 WM_CAPTURECHANGED: lParam is 0, hWnd is 65616, equal? = 0
Note: All I do is launch the application then click the 'X' button to close.
I believe the missing WM_CAPTURECHANGED where lParam == hWnd is significant to tihs bug.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #47 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Christopher Thielen from comment #46)
Compiling the attached mouseylines.cpp (apologies for the name), Windows produces this:
WM_LBUTTONDOWN: setting capture WM_CAPTURECHANGED: lParam is 590262, hWnd is 590262, equal? = 1 WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 590262, equal? = 0 WM_CAPTURECHANGED: lParam is 0, hWnd is 590262, equal? = 0
while Wine produces this:
WM_LBUTTONDOWN: setting capture WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 65616, equal? = 0 WM_CAPTURECHANGED: lParam is 0, hWnd is 65616, equal? = 0
Note: All I do is launch the application then click the 'X' button to close.
I believe the missing WM_CAPTURECHANGED where lParam == hWnd is significant to tihs bug.
What you are observing with your test app (btw, it doesn't compile because of missing stdafx.h which has to be commented out) under Windows is completely the result of clicking on the close button on the caption, and that obviously have nothing to do neither with Wine (WM doesn't send events for mouse clicks on the caption to an X client app), nor with reproducing the source of this bug.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #48 from Christopher Thielen cthielen@gmail.com --- Sorry about the missing include file. There is no code in it fortunately.
I re-performed my test and drew a couple of lines to confirm that the missing WM_CAPTURECHANGED is not the result of closing the window but is actually the result of the SetCapture() call on line 194.
If you comment out that unnecessary SetCapture(), Wine and Windows match in their WM_CAPTURECHANGED messages. With that SetCapture() call however, Windows will immediately send a WM_CAPTURECHANGED call where the lParam argument equals the hWnd of the demo application's window. Wine sends nothing.
u9.exe seems to be repeatedly calling SetCapture() in order to get such a message back from the environment, but as Wine is currently not sending this message, it fails to enable the in-game mouse cursor.
It appears that the MSDN documentation for WM_CAPTURECHANGED is incomplete (https://msdn.microsoft.com/en-us/library/windows/desktop/ms645605%28v=vs.85%...) and that WM_CAPTURECHANGED is not only sent to windows losing focus but can be sent to a window which already has focus if that application calls SetCapture() on its own window.
If this sounds like the appropriate behavior, I'd be glad to submit a patch.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #49 from Christopher Thielen cthielen@gmail.com --- Hm, what I said above does not appear to be the complete behavior of WM_CAPTURECHANGED. Still investigating ...
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #50 from Christopher Thielen cthielen@gmail.com --- Here's another result: take the given test and duplicate the SetCapture() line in WM_LBUTTONDOWN so it simply calls SetCapture() twice in a row. Wine and Windows differ a lot in that case (for this output I drew three lines and then clicked the window close button):
Windows: WM_LBUTTONDOWN: setting capture WM_CAPTURECHANGED: lParam is 459306, hWnd is 459306, equal? = 1 WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 459306, equal? = 0 WM_LBUTTONDOWN: setting capture WM_CAPTURECHANGED: lParam is 459306, hWnd is 459306, equal? = 1 WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 459306, equal? = 0 WM_LBUTTONDOWN: setting capture WM_CAPTURECHANGED: lParam is 459306, hWnd is 459306, equal? = 1 WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 459306, equal? = 0 WM_CAPTURECHANGED: lParam is 0, hWnd is 459306, equal? = 0 Received WM_DESTROY
Wine: WM_LBUTTONDOWN: setting capture WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 65596, equal? = 0 WM_LBUTTONDOWN: setting capture WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 65596, equal? = 0 WM_LBUTTONDOWN: setting capture WM_LBUTTONUP: releasing capture WM_CAPTURECHANGED: lParam is 0, hWnd is 65596, equal? = 0 WM_CAPTURECHANGED: lParam is 0, hWnd is 65596, equal? = 0 Received WM_DESTROY
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #51 from Christopher Thielen cthielen@gmail.com --- My guess at what Windows is doing is taking the second SetCapture() command and simply sending the WM_CAPTURECHANGED message to the "old" window which just happens to also be the new window.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #52 from Christopher Thielen cthielen@gmail.com --- I can confirm the following patch resolves this bug.
It also causes Wine to correctly mimic Windows' behavior in my demo. I am not sure why the original author of user32.dll was making the check I removed. Is there a good way to determine who has solid knowledge of user32.dll to ensure I'm not removing behavior erroneously?
(Generated against wine.git on 11/15/15 at 19:28 PST):
diff --git a/dlls/user32/input.c b/dlls/user32/input.c index 40e35a9..63fae67 100644 --- a/dlls/user32/input.c +++ b/dlls/user32/input.c @@ -108,7 +108,7 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret ) { USER_Driver->pSetCapture( hwnd, gui_flags );
- if (previous && previous != hwnd) + if (previous) SendMessageW( previous, WM_CAPTURECHANGED, 0, (LPARAM)hwnd );
if (prev_ret) *prev_ret = previous;
https://bugs.winehq.org/show_bug.cgi?id=13683
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #53 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Christopher Thielen from comment #52)
I can confirm the following patch resolves this bug.
It also causes Wine to correctly mimic Windows' behavior in my demo. I am not sure why the original author of user32.dll was making the check I removed. Is there a good way to determine who has solid knowledge of user32.dll to ensure I'm not removing behavior erroneously?
Its rather unlikely that someone immediately knows if this is correct or not. The code you refer to exists since at least 2002, and is probably even older. Most of the time the Windows behavior is not well-documented, so it is indeed possible, that the code was written based on some assumptions which are not true in practice - or also that this implementation was true on ancient versions of Windows but doesn't match modern operating systems.
To check if your changes are correct, you should try to add your test into the Wine testsuite (dlls/user32/tests), and run the existing tests (if you didn't do that already). Afterwards you should submit your suggested patch for further discussion and reviewing to the wine-patches mailing list (see http://wiki.winehq.org/SubmittingPatches ). Thanks for all your effort to fix this bug by the way! :)
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #54 from Christopher Thielen cthielen@gmail.com --- Thank you Sebastian, I appreciate your knowledge on this.
I'll get the user32 tests working (many of them fail on my machine right now - not sure if that's normal), add a test of my own for this behavior, and get in touch with the patches mailing list.
Thanks again!
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #55 from Rixa rixa@cs.tut.fi --- Confirming that the patch fixes the issue for me. Thank you for your hard work on this, Christopher.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #56 from Christopher Thielen cthielen@gmail.com --- A patch with a messaging test has been submitted for this.
Thanks again for everyone's help and kind words.
https://bugs.winehq.org/show_bug.cgi?id=13683
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/user32-WM_CAPT | |URECHANGE
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #57 from johnniewaves@hotmail.com --- Thanks all for looking into this.
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #58 from Ruei-Yuan Lu RueiYuan.Lu@gmail.com --- Thanks all for looking into this. +1
https://bugs.winehq.org/show_bug.cgi?id=13683
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=13683
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=13683
--- Comment #59 from Christopher Thielen christopher@thielen.co --- FYI This fix is in Wine as of 1.9.3.
https://bugs.winehq.org/show_bug.cgi?id=13683
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |9bb87cc71c95f45cd6111b28b68 | |7bd753380a4c7 Status|STAGED |RESOLVED Component|-unknown |user32 Resolution|--- |FIXED
--- Comment #60 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Christopher Thielen from comment #59)
FYI This fix is in Wine as of 1.9.3.
Hi, Christopher.
Thanks for fixing this, 9bb87cc71c95f45cd6111b28b687bd753380a4c7.
https://bugs.winehq.org/show_bug.cgi?id=13683
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@redhat.com Target Milestone|--- |1.8.x
https://bugs.winehq.org/show_bug.cgi?id=13683
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #61 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.4.
https://bugs.winehq.org/show_bug.cgi?id=13683
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |---
--- Comment #62 from Michael Stefaniuc mstefani@redhat.com --- Removing 1.8.x milestone from bugs included in 1.8.2.
-
wine-bugs＠winehq.org