December 2009 - Wine-bugs - list.winehq.org

[Bug 20974] New: Setting drive as Local disk in winecfg does not work
by wine-bugs＠winehq.org 10 Dec '09

10 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20974 Summary: Setting drive as Local disk in winecfg does not work Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gore(a)projectpontiac.com In winecfg, setting a drive as "Local disk" does not work. For example: - I have a drive called X:\ that resides at ~/.wine/drive_x - ~/ is a network share that gets auto-mounted from the server when I log in - I use winecfg to set X:\ to a "Local disk" (under the "Show Advanced" parameters of the "Drives" tab) - Windows applications still see X:\ as a Network share This prevents certain applications from installing. For example, Photoshop CS2, a Platinum-level application, refuses to install to a network share. This can be repeated easily by trying to install the Photoshop CS2 trial onto a drive that is hosted on a network share. http://download.adobe.com/pub/adobe/photoshop/win/cs2/Photoshop_CS2_tryout.… So far I've seen this behaviour in Wine version 1.1.28, 1.1.32 and 1.1.34. I did not try any other versions. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 10 Dec '09

10 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #300 from Warren Dumortier <nwarrenfl(a)gmail.com> 2009-12-10 06:45:25 --- I'm very happy to see this bug is being discusses to find a solution, however i have a question, not really important to post in this bur report, but i ask! ;) Vitaliy Margolen: Do you already have a prototype using XInput 2 or not? But if you have something beginning to work i would really like to test it out. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 9087] Sound in wow breaks when leaving window
by wine-bugs＠winehq.org 10 Dec '09

10 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=9087 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #25 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-12-09 22:19:05 --- > I wonder why it is so difficult to revert a buggy patch if it is clearly > identified! Because the patch is not buggy. DInput has tests that validate this change was correct. What happened is this change uncovered another bug somewhere else (d3d/dsound)? And that's where you should be concentrating. Confirming per comment 23. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 10 Dec '09

10 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #299 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-12-09 22:13:11 --- (In reply to comment #297) If you so want to have DGA mouse - why don't you actually look at what it is, how it works, and if it meats the DInput requirements? If it's freezing pointer in place - it's automatically won't work for Wine. that mode already works just fine. It's the non-exclusive background coop level that's needed by soo many apps that doesn't work. Also you seems to totally ignore what I said here numerous times - warping mouse is out of the question period end of story. You can not make all applications work this way. You will fix one type and break another type. The best example are all Quake 2+ engine based games that use dinput (Half-Life even tho based on Q2 engine doesn't use dinput at all). These games incorrectly acquire mouse in game mode as non-exclusive background coop. If you start warping mouse in this coop mode you'll break all programs that show system cursor in the menu for example. XInput2 does exactly what Wine needs and that's what Wine will use to fix this bug no matter if you like it or not. This means you'll be getting XOrg 7.5 sooner then you wanted. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 20973] New: Windows Live Essentials installer fails
by wine-bugs＠winehq.org 10 Dec '09

10 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20973 Summary: Windows Live Essentials installer fails Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: leighmanthegreat(a)hotmail.com Created an attachment (id=25139) --> (http://bugs.winehq.org/attachment.cgi?id=25139) terminal output Both wlsetup-web.exe and wlsetup-all.exe available at http://download.live.com/ exit silently. Terminal output attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 10 Dec '09

10 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Vincent <weber.vincent(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |weber.vincent(a)gmail.com --- Comment #298 from Vincent <weber.vincent(a)gmail.com> 2009-12-09 19:13:14 --- I once had this very strange bug with Doom3 on Windows XP (not Wine). From that very bug I came to understand how Windows XP handles the mouse in FPS games: It keeps track of the position of the mouse cursor but simplay doesn't display it and reads out the movement of the mouse too. So when I played doom, the mouse cursor was displayed. When I moved my mouse to the right, the camera turned right. When I turn it left, the camera turned left, etc, etc.. When the mouse hit the side of the screen, the camera kept going in the direction I moved the mouse. So... Mouse movement used by DirectInput and also by whatever handles the cursor, but the cursor just isn't displayed and can't focus... I am not an experienced programmer but this should be extremely easy to implement correctly, in a non ugly manner... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 9087] Sound in wow breaks when leaving window
by wine-bugs＠winehq.org 09 Dec '09

09 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=9087 --- Comment #24 from Klaus Ethgen <Klaus+wine(a)Ethgen.de> 2009-12-09 14:59:09 --- Yes, the problem still exists. Even with newer versions. I wonder why it is so difficult to revert a buggy patch if it is clearly identified! However, some people seems to not see the problem. Might it be that the problem only occurs on window managers which have no desktop window? Might it be that this GetDesktopWindow() give a undefined value back or something like that? Please, please, please, please revert this buggy patch which raised this problem! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 8394] IMVU 3D Instant Messenger not visible in wine's uninstaller
by wine-bugs＠winehq.org 09 Dec '09

09 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=8394 Juan Lang <juan_lang(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #8 from Juan Lang <juan_lang(a)yahoo.com> 2009-12-09 14:46:07 --- Reported fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 8394] IMVU 3D Instant Messenger not visible in wine's uninstaller
by wine-bugs＠winehq.org 09 Dec '09

09 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=8394 Niko Sandschneider <nsandschn(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nsandschn(a)gmx.de --- Comment #7 from Niko Sandschneider <nsandschn(a)gmx.de> 2009-12-09 14:17:54 --- This has been fixed in git. IMVU is listed by the uninstaller. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 09 Dec '09

09 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #297 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-12-09 12:09:07 --- (In reply to comment #296) > (In reply to comment #295) > > A basic list of possible approaches: > > XInput2 - not relevant yet. > > To whom? Ubuntu's pulled Xorg 7.5 for Lucid, Fedora 12 shipped with Xorg 7.5. > Gentoo has it available, to the best of my limited knowledge. Debian only has > it in experimental, but it's pretty danged close to hitting unstable from what > I've seen. This assumes that everyone runs the very latest and chooses their distribution based on how recently the latest release occurred (switching distribution according to the whims of release cycles), an inappropriate assumption in my view. > > DGA Mouse - warp pointer to emulate real mouse movement. > > If _I_ was writing the patch, I'd do the XInput 2 version, because it's the > least work in Wine and also cleans up the somewhat messy DInput exclusive-mode > handling, and then see if I could implement a DGA fallback usefully under the > resulting structure. If neither of those was available, I'd suggest Wine just > refuse to provide whatever mode the application is asking for. To require XInput2 is unreasonable for the above reason, but to implement support for it before implementing fallbacks is perfectly reasonable. > > Hidden Mouse - hide real mouse pointer, capture mouse movement and display a > > fake mouse pointer using additional drawing commands before glXSwapBuffers each > > frame (this is okay because cooperative mouse is chiefly used by games which > > continuously refresh the window). > > This one sounds like a DInput/WineD3D-specific hack, which relies on certain > features ("capture mouse movement" for example), the lack of which prompted us > to focus on XInput2 in the first place. The key for spotting a hack is the > parenthetical qualification which addresses the chief use only. It is extremely common for any game to use DirectInput, and it is always in cooperative mode unless the game is fullscreen. This affects nearly all games that have a mouse-controlled view turning behavior. > What games use co-operative mouse, anyway? I thought co-operative mouse would > generally be used by non-game things that want to read the mouse while > something else is nominally in charge (VoIP software, things like that program > with the cat chasing your mouse cursor around the screen) I do not know of very many applications that use DirectInput, but I know of many games, I do not need to list the many affected games as they should all be linked to this bug already. Here is the usage pattern in question: 1. Open a window. 2. Attach D3D context. 3. Activate DI cooperative mode. 4. Each frame, poll DI events and utilize either the current mouse position (for a mouse-driven user interface such as in RTS and RPG games, as well as in menus of all games) or the delta (to look around) - wine is not notified of which information is desired. 5. The mouse pointer is hidden or shown according to the whims of the game, Wine does not reliably know which behavior the game is using at any given moment, and both pieces of data (position and delta) must be valid at all times. When operating with plain X11 input, the only data that can be obtained is the current mouse position, and measuring deltas from this causes border problems. When I do ports of games to Linux, I have to replace the DI cooperative mode mechanism used in the game with two different modes of operation in X11 - show mouse pointer and behave normally like an application, or hide pointer and warp it back to center frequently frame to get deltas (or use DGA to get the deltas directly without acceleration). The problem I mentioned is that Wine may have to show the mouse pointer and report deltas at the same time on plain X11 (no DGA, no XInput2), and to this end it might have to draw a mouse pointer before the glXSwapBuffers occurs (in both D3D and GL cases), however this does not help regular applications. With DGA the mouse movement can be reliably faked based on the deltas. I do not know if XInput2 will live up to the promises and solve this bug, I certainly hope so and I fully support the idea of implementing an XInput2 solution first - but I still see a need to solve this bug with DGA and plain X11 as well, for users who do not have XInput2 yet. Note for implementors of delta reading on plain X11: Each time a mouse move is parsed, it produces a delta from the previous position, however if the mouse position is getting dangerously near the borders (typically whenever it's out of the middle area of the window) a warp is needed to re-center it, this warp produces a move as well and must be ignored - to do this, XSendEvent is used to produce a fake mouse move event in the X11 stream, which updates the "last known" position variables but does not produce a delta (by checking the .send_event flag on the event these fake moves can be filtered out, it is always True if the event is produced by XSendEvent), then when the real mouse move from XWarpPointer comes in immediately after the fake one, it produces no delta because the "last known" position is already the same. This is the basic mode of operation of all Linux games that require delta movement when DGA is not available. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0