https://bugs.winehq.org/show_bug.cgi?id=47386
Bug ID: 47386 Summary: Not tracked mouse cursor in the game Product: Wine-staging Version: 4.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: duponamk@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 64719 --> https://bugs.winehq.org/attachment.cgi?id=64719 File with bug
Drakensang Online: Good day. In the online game Drakensang Online has long observed the following bug: when you start the game is not visible the cursor of the mouse, i.e. the cursor appears, but does not move. And in the background you can see that it is still moving, but it is not displayed correctly. As a result, there is no way to play the game normally. This is also evident in the stable wine.
Thank you.
https://bugs.winehq.org/show_bug.cgi?id=47386
Sergey duponamk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=47386
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW URL| |https://www.drakensang.com/ | |en Keywords| |download Product|Wine-staging |Wine Component|-unknown |-unknown Summary|Not tracked mouse cursor in |Drakensang Online |the game |incorrectly renders the | |cursor while in fullscreen Ever confirmed|0 |1
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Confirming. The game can be freely downloaded and played. Be warned that it requires an email-based account to be created, and takes up 1.6 GB on disk.
https://bugs.winehq.org/show_bug.cgi?id=47386
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- The application creates a 64x64 texture and sets it as the cursor using IDirect3DDevice9::SetCursorProperties(). This results in wined3d creating a "software" cursor. It never updates the cursor position, and wined3d never does of its own volition, so the cursor never moves on the screen.
I tested on a native Windows machine. Setting a 64x64 cursor using SetCursor() succeeds, and switching the texture size to 64x64 in test_cursor() in d3d9:device has no effect on the test (i.e. GetCursorInfo() does not report that the cursor has been replaced). So that's interesting. Either native d3d9 is using a "hardware" cursor in that case (despite the documentation), or its "software" cursor involves updating the cursor position (somehow). I'm not sure how to test this, however, since I'm unable to get SetCursor() to refuse anything on native Windows.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #3 from Sergey duponamk@gmail.com --- Hello. You are right. The game requires a lot of space on the hard drive (and the resources are stored in the user's time folder, which is not good). Yes, under Windows the game works well both in full-screen mode and in the window. I would like to see the same reaction Of Drakensang Online and in Linux under the vine (no matter what branch is used).
I must assume that there is no such problem in window mode (I proceed from your words)?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #4 from Sergey duponamk@gmail.com --- Wine (not vine :)) Sorry
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sergey from comment #3)
I must assume that there is no such problem in window mode (I proceed from your words)?
I don't know; I haven't been able to get it in windowed mode due to bug 47392. I would guess it's similarly broken, however.
https://bugs.winehq.org/show_bug.cgi?id=47386
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Drakensang Online |Drakensang Online |incorrectly renders the |incorrectly renders the |cursor while in fullscreen |cursor
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #6 from Sergey duponamk@gmail.com --- Hello. Yesterday I checked for the sake of interest at home - in window mode also does not work, the cursor is also not tracked. Checked in CrossOver Linux. From under the wine (as well as in PlayOnLinux) the game crashes with a mistake (forgot to save the error log, so that there was something to see). If necessary - I will put the game again in the wine and write down the error log.
https://bugs.winehq.org/show_bug.cgi?id=47386
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|leslie_alistair@hotmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- With https://source.winehq.org/patches/data/167302 this is improved; i.e. the cursor actually moves. However, it flickers badly for me. I think this is because the applications is repeatedly (once per WM_SETCURSOR message? I didn't check) calling SetCursorProperties() with the same properties, and we destroy and recreate the cursor each time.
I think the right thing to do is to check if the cursor texture and hotspot are the same, and skip setting it if so, but wined3d_device_set_cursor_properties() contains a warning not to hold a reference to the cursor texture, for fear of creating a circular reference. That warning dates back to 2006 (65e5ed60ae02), though, so I'm not sure if it's still salient. D3D refcounting is not exactly trivial...
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #8 from Sergey duponamk@gmail.com --- Hello. I’m a programmer, of course, but I’m programming for databases, but what you’re talking about is, in theory, logical to process only one message about setting the mouse cursor to a specific point on the screen (if there are several sent from one position).
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #9 from Sergey duponamk@gmail.com --- Hello. You'll laugh, but: I checked the behavior of the game on the extreme version of Vine (4.12.1) and found that the error is not going anywhere - the cursor flickers and stands still, and in the background it moves. You can catch it only in the game itself, pressing the space key. Then in the place where it is, appear for a few seconds "circles on the water" red. Tested on two computers using open and closed (NVidia) drivers - all the same. Previously, they stood Vindows - everything worked well. So the bug has not been fixed. Excuse me.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- No, unfortunately the patch has not been reviewed or committed yet. I can only offer my apologies that the process is slower than ideal.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #11 from Sergey duponamk@gmail.com --- Good day. I see. And I've already "rolled my lip" to play :). We'll wait for the patch to be made.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #12 from Sergey duponamk@gmail.com --- Hello. In the version of wine (4.13) patch that corrects the situation with the cursor, I see, and not included?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #13 from Zebediah Figura z.figura12@gmail.com --- The main problem with the patch is that we don't know whether the behaviour tested is unique to Windows 10 or not. I unfortunately don't have access to any real Windows hardware older than Windows 10 (real hardware being necessary to run D3D tests), so I can't test this myself right now.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #14 from Sergey duponamk@gmail.com --- Hello. Maybe I'm misunderstanding something, but what does windows have to do with it? A patch for a wine that works in Linux, no? The mouse cursor also flickers for me, and quite strong, but it stands still, and moves in the background. I agree I will put up with flicker if it moves as it should. The main thing for me is that the client works, and the mouse pointer flickers or not - you can close your eyes to it (at least I can close my eyes to it).
https://bugs.winehq.org/show_bug.cgi?id=47386
erkankarabulut erkankkarabulut@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erkankkarabulut@gmail.com
--- Comment #15 from erkankarabulut erkankkarabulut@gmail.com --- Hello,
I am still having the same problem. Mouse cursore is visible but I can't move it graphically, although it actually moves in the background. Because I can see that buttons are highlighted when I blindly move the mouse and I am also able to click on them and everything works normally.
Is there any solution to this problem?
Kind regards, Erkan
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #16 from Sergey duponamk@gmail.com --- Hello. I will also duplicate here, in addition to the letter to the mailbox: yes, the problem remains unsolved. I'll try again to apply the patch, the link to which is located above in the discussion thread. I already tried to use it with version 4.18, but nothing came of it. The assembly stopped with errors (I don't remember which ones). I'll check it - I'll post the log.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #17 from Sergey duponamk@gmail.com --- Hello. Here is the result of applying the wine patch to version 5.20:
-patching tools/widl/parser.l -1 out of 4 hunks FAILED -- saving rejects to file tools/widl/parser.l.rej -[PATCH] ERR: Textual patch did not apply, aborting. -ERROR: Failed to apply patch, aborting!
there are much fewer mistakes in comparison with previous experience. I have no idea what this might be related to and how to edit it. What is this error?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #18 from Sergey duponamk@gmail.com --- Created attachment 68529 --> https://bugs.winehq.org/attachment.cgi?id=68529 Log-file
Here is the file it links to (attached).
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #19 from Zebediah Figura z.figura12@gmail.com --- That patch seems to be unrelated to this bug; are you sure you applied the right patch?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #20 from erkankarabulut erkankkarabulut@gmail.com --- (In reply to Zebediah Figura from comment #19)
That patch seems to be unrelated to this bug; are you sure you applied the right patch?
Hello,
Do you know if there is a patch for this cursor problem or not?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #21 from Sergey duponamk@gmail.com --- (In reply to Zebediah Figura from comment #19)
That patch seems to be unrelated to this bug; are you sure you applied the right patch?
Hello. Quite sure of myself. I put it in the wine patch folder. When they were applied, there were no errors that something was wrong in the file. So yeah, pretty sure.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #22 from Sergey duponamk@gmail.com --- (In reply to erkankarabulut from comment #20)
(In reply to Zebediah Figura from comment #19)
That patch seems to be unrelated to this bug; are you sure you applied the right patch?
Hello,
Do you know if there is a patch for this cursor problem or not?
Hello. Look at the correspondence from the bottom up. Comment # 7 provides a link to a patch that should fix the problem, but doesn't ... yet.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #23 from erkankarabulut erkankkarabulut@gmail.com --- (In reply to Sergey from comment #22)
(In reply to erkankarabulut from comment #20)
(In reply to Zebediah Figura from comment #19)
That patch seems to be unrelated to this bug; are you sure you applied the right patch?
Hello,
Do you know if there is a patch for this cursor problem or not?
Hello. Look at the correspondence from the bottom up. Comment # 7 provides a link to a patch that should fix the problem, but doesn't ... yet.
Thank you for the answer. But that patch is quite old, and it doesn't solve it properly, am I right? I am also not familiar with the source code of wine. Is there a way to put this bug into next sprint or something?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #24 from Zebediah Figura z.figura12@gmail.com --- (In reply to erkankarabulut from comment #23)
Thank you for the answer. But that patch is quite old, and it doesn't solve it properly, am I right? I am also not familiar with the source code of wine. Is there a way to put this bug into next sprint or something?
It may be correct, but it also may not. Unfortunately I'd need access to a real windows 7 machine to test, and I haven't been able to get access to one recently.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #25 from Sergey duponamk@gmail.com --- (In reply to erkankarabulut from comment #23)
(In reply to Sergey from comment #22)
(In reply to erkankarabulut from comment #20)
(In reply to Zebediah Figura from comment #19)
That patch seems to be unrelated to this bug; are you sure you applied the right patch?
Hello,
Do you know if there is a patch for this cursor problem or not?
Hello. Look at the correspondence from the bottom up. Comment # 7 provides a link to a patch that should fix the problem, but doesn't ... yet.
Thank you for the answer. But that patch is quite old, and it doesn't solve it properly, am I right? I am also not familiar with the source code of wine. Is there a way to put this bug into next sprint or something?
Good afternoon. The patch might be old, but I was given a link to it, and the WINE changelog indicated that a mouse cursor bug was fixed. I assume this is the exact patch. But in fact, nothing has changed. I'm not familiar with the WINE source code either :)
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #26 from Sergey duponamk@gmail.com --- (In reply to Zebediah Figura from comment #24)
(In reply to erkankarabulut from comment #23)
Thank you for the answer. But that patch is quite old, and it doesn't solve it properly, am I right? I am also not familiar with the source code of wine. Is there a way to put this bug into next sprint or something?
It may be correct, but it also may not. Unfortunately I'd need access to a real windows 7 machine to test, and I haven't been able to get access to one recently.
Good afternoon. I tried the patch on my home laptop. The application ended with an error. But already different:
-error: error applying changes: dlls / mfplat / tests / mfplat.c: 603 -error: dlls / mfplat / tests / mfplat.c: failed to apply patch -ERROR: Failed to apply patch, aborting!
But I don’t understand why you need a real machine with Windows 7. The game runs perfectly in Internet Explorer 10-11. But that's not an option for me. Or do you want to build Wine for Windows and check how everything works?
https://bugs.winehq.org/show_bug.cgi?id=47386
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #27 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Sergey from comment #26)
But I don’t understand why you need a real machine with Windows 7. The game runs perfectly in Internet Explorer 10-11. But that's not an option for me. Or do you want to build Wine for Windows and check how everything works?
Hello,
Patches are tested on real Windows for API conformance.
The game is not used for that. The Wine source code has tests that are cross-compiled to run on real Windows.
The tests call Windows API functions and check the expected results.
On real Windows, the Windows functions are called. On Linux, the Wine functions are called.
If they both give the same results, the Wine functions are conformant to the Windows API (for the tested parts at least).
https://wiki.winehq.org/Conformance_Tests
Regards.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #28 from Sergey duponamk@gmail.com --- (In reply to Olivier F. R. Dierick from comment #27)
On real Windows, the Windows functions are called. On Linux, the Wine functions are called.
If they both give the same results, the Wine functions are conformant to the Windows API (for the tested parts at least).
https://wiki.winehq.org/Conformance_Tests
Regards.
Hello. A virtual machine with Windows installed in it will not work? To conduct tests, in theory, it should be no matter where Windows is installed, in a virtual machine, or on a real machine. Is not it so? Or are there some fundamental differences that will not allow such tests to be carried out?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #29 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sergey from comment #26)
Good afternoon. I tried the patch on my home laptop. The application ended with an error. But already different:
-error: error applying changes: dlls / mfplat / tests / mfplat.c: 603 -error: dlls / mfplat / tests / mfplat.c: failed to apply patch -ERROR: Failed to apply patch, aborting!
What exact series of commands are you using to apply the patch? You shouldn't get any messages like those either.
(In reply to Sergey from comment #28)
Hello. A virtual machine with Windows installed in it will not work? To conduct tests, in theory, it should be no matter where Windows is installed, in a virtual machine, or on a real machine. Is not it so? Or are there some fundamental differences that will not allow such tests to be carried out?
Broadly speaking, yes. Most hardware needs to be virtualized. Virtual machines usually have only rudimentary GPU support, and can't pass through the host driver.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #30 from Sergey duponamk@gmail.com --- (In reply to Zebediah Figura from comment #29)
What exact series of commands are you using to apply the patch? You shouldn't get any messages like those either.
Good afternoon. What commands do I use? Yes, all the same from the instructions for applying patches for WIME. At work, one set of mistakes, at home - another. A laptop at home, a desktop at work.
Broadly speaking, yes. Most hardware needs to be virtualized. Virtual machines usually have only rudimentary GPU support, and can't pass through the host driver.
I have a Windows 7 PC on board. How can you try to check the patches? How?
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #31 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sergey from comment #30)
(In reply to Zebediah Figura from comment #29)
What exact series of commands are you using to apply the patch? You shouldn't get any messages like those either.
Good afternoon. What commands do I use? Yes, all the same from the instructions for applying patches for WIME. At work, one set of mistakes, at home - another. A laptop at home, a desktop at work.
Please paste the exact series of commands you're running.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #32 from Sergey duponamk@gmail.com --- (In reply to Zebediah Figura from comment #31)
(In reply to Sergey from comment #30)
Please paste the exact series of commands you're running.
Hello. The sequence of actions is as follows: - from the WINE site I download the source code of WINE and WINE Staging extreme versions; - copy them to the selected folder; - I unpack them there; - in the folder with WINE Staging open the console; - according to the instructions from the readme file, I apply patches with the command: ./patches/patchinstall.sh DESTDIR = "/ path / to / wine" --all, where I change the path to the folder to the one where WINE is located.
I get different results as described above.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #33 from Zebediah Figura z.figura12@gmail.com --- I would recommend not using wine-staging, as it's probably not going to provide any benefit, but if you do, the contents of 'staging/upstream-commit' (or `./staging/patchinstall.py --upstream-commit`) should match the tag printed by `git show --no-patch` in the wine directory.
https://bugs.winehq.org/show_bug.cgi?id=47386
--- Comment #34 from Sergey duponamk@gmail.com --- (In reply to Zebediah Figura from comment #33)
I would recommend not using wine-staging, as it's probably not going to provide any benefit, but if you do, the contents of 'staging/upstream-commit' (or `./staging/patchinstall.py --upstream-commit`) should match the tag printed by `git show --no-patch` in the wine directory.
Hello. The hash sums coincided after the proposed script was processed. And yes, I prefer the staging branch.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla