wine-bugs December 2009

wine-bugs@winehq.org

1 participants
6346 discussions

[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 #296 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-12-08 21:38:31 --- (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. > 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. > 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. 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) -- 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 20967] New: World of Warcraft v3.3.0 login fails with C runtime library load error
by wine-bugs＠winehq.org 09 Dec '09

09 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20967 Summary: World of Warcraft v3.3.0 login fails with C runtime library load error Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: ranguvar(a)archlinux.us Upon login to World of Warcraft 3.3.0 (the first time worked fine, but now the problem is reliably encountered), an error dialog appears with the following text, and login does not occur. Previous versions of WoW appear to work fine. "Runtime Error! Program: C:\Program Files\World of Warcraft\Wow.exe R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information." The Wine output when the error is hit is as follows: "fixme:actctx:parse_assembly_elem wrong version for assembly manifest: 8.0.50727.762 / 8.0.50727.4053 fixme:actctx:parse_manifest_buffer failed to parse manifest L"C:\\Program Files\\World of Warcraft\\Microsoft.VC80.CRT.manifest" fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" (8.0.50727.762)" This is without any Winetricks installed. This problem appears to only exist in Wine with WoW 3.3.0 (latest version). Others have confirmed this error on forums, etc: http://forums.worldofwarcraft.com/thread.html?topicId=21626505372 http://forums.worldofwarcraft.com/thread.html?topicId=21626505378 Upon advice I found via Googling, I ran 'touch' on the named file in the World of Warcraft directory, but this did not help. The program continues to function, with an in-game message containing HTML code as text advising the user to go to a Blizzard support page, but login does not occur. -- 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 3

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

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=8394 Bug 8394 depends on bug 16299, which changed state. Bug 16299 Summary: IMVU 3D Instant Messenger installer crashes http://bugs.winehq.org/show_bug.cgi?id=16299 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |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 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #295 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-12-08 11:24:43 --- (In reply to comment #294) > Though, with KMS/DRI2, DGA is finally killed for good. It's not enabled by > default yet, but it's going to happen sometime soon. > > Maybe Intel had KMS enabled for Ubuntu 9.10? Radeon is still a little behind. > > DGA would not be even a good short term solution. > > But on (radeon) KMS/DRI2 I didn't even need DGA in native Quake 2 to keep my > cursor inside the window, I don't know what else has changed or is my > sensitivity just too slow. > > My two cents. I highly doubt that KMS/DRI2 has killed DGA mouse, please do not confuse DGA mouse with DGA video (which has been dead for some time already, as it required root access). DGA mouse is a useful and usable extension. The citation of native Quake2 is irrelevant, because it has an invisible mouse pointer and thus can do whatever warping it pleases, hence it can work without DGA (but DGA has the advantage of disabling mouse acceleration). The topic is DI cooperative mouse, where the mouse must both be visible and report deltas (even when hitting borders of the clipping area), and mouse emulation is necessary at some level, utilizing the existing mouse pointer sprite via DGA mouse is the easiest option until XInput2. Also, I do not think that the politics of xorg regarding DGA mouse and XInput2 are even relevant to the topic at hand: users want to be able to play their games properly, they do not care for the specifics, only the results. A basic list of possible approaches: DGA Mouse - warp pointer to emulate real mouse movement. XInput2 - not relevant yet. 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). The solution is not any one of these approaches but all of them, for broadest xserver compatibility. -- 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 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #294 from Toni Spets <toni.spets(a)iki.fi> 2009-12-08 10:53:59 --- (In reply to comment #291) > The simple fact is, this bug matters to a great many people, the pile of hacks > dispersed here added value to the many gamers who needed them to be able to > play their favorite games, regardless of any technical review process, opinion, > or conflict issues. > > I am all for openness, reasoned discourse, and solving bugs that matter to > people. > > While I do not agree with the hacks either, I do see a strong need for a > solution to this problem, I look forward to the supposed XInput2 solution, but > for many users this problem can not wait. > > For this reason I must bring up the topic of DGA mouse grab again, so here is a > proposal for pre-XInput2 xorg versions: > > Lock the mouse using DGA to grab raw mouse deltas, provide the illusion of > normal mouse movement using XWarpPointer, release grab whenever a mouse click > occurs outside the game window or the application focus changes (due to window > manager shortcuts). > > DGA disables mouse movement and grabs the raw deltas, so this satisfies both > aspects of the cooperative mode (mouse moves around with XWarpPointer, while > deltas are captured even at borders), there might be a one-refresh pointer lag > involved but this is not perceptible, no keyboard grab is used so the standard > window manager shortcuts work (alt-tab and so on) to defocus the application, > and it might eat a mouse click when clicking outside the game window to defocus > the application but this is not a critical problem. > > I can confirm that DGA works on OpenSUSE 11.2 and Ubuntu 9.10 (both current > distributions), and this seems far more robust than any of the hacks released > thus far. > > It's clear that this discussion will only end when users can play their games > without game-specific hacks. Though, with KMS/DRI2, DGA is finally killed for good. It's not enabled by default yet, but it's going to happen sometime soon. Maybe Intel had KMS enabled for Ubuntu 9.10? Radeon is still a little behind. DGA would not be even a good short term solution. But on (radeon) KMS/DRI2 I didn't even need DGA in native Quake 2 to keep my cursor inside the window, I don't know what else has changed or is my sensitivity just too slow. My two cents. -- 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 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 Robert Munteanu <robert.munteanu(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robert.munteanu(a)gmail.com --- Comment #293 from Robert Munteanu <robert.munteanu(a)gmail.com> 2009-12-08 09:40:03 --- On one hand, the developers are correct when asking not to be spammed with dozens of emails which are not related to the final resolution of the bug. On the other hand, the users are correct in saying that for them this problem is solved with such patches. My suggestion would be for one the patch submitters or another commenter to create a git ( GitHub? ) repo where this patch is to be hosted. Judging from the comments it's relatively easy to rebase it on each wine release and this way a place for retrieving the patch can be indicated, perhaps in the issue description: "Unsupported patch at ... , use at your own risk". -- 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 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #292 from Jouni Järvinen <jounijarvis(a)gmail.com> 2009-12-08 09:35:33 --- (In reply to comment #291) > The simple fact is, this bug matters to a great many people, the pile of hacks > dispersed here added value to the many gamers who needed them to be able to > play their favorite games, regardless of any technical review process, opinion, > or conflict issues. > > I am all for openness, reasoned discourse, and solving bugs that matter to > people. > > While I do not agree with the hacks either, I do see a strong need for a > solution to this problem, I look forward to the supposed XInput2 solution, but > for many users this problem can not wait. > > For this reason I must bring up the topic of DGA mouse grab again, so here is a > proposal for pre-XInput2 xorg versions: > > Lock the mouse using DGA to grab raw mouse deltas, provide the illusion of > normal mouse movement using XWarpPointer, release grab whenever a mouse click > occurs outside the game window or the application focus changes (due to window > manager shortcuts). > > DGA disables mouse movement and grabs the raw deltas, so this satisfies both > aspects of the cooperative mode (mouse moves around with XWarpPointer, while > deltas are captured even at borders), there might be a one-refresh pointer lag > involved but this is not perceptible, no keyboard grab is used so the standard > window manager shortcuts work (alt-tab and so on) to defocus the application, > and it might eat a mouse click when clicking outside the game window to defocus > the application but this is not a critical problem. > > I can confirm that DGA works on OpenSUSE 11.2 and Ubuntu 9.10 (both current > distributions), and this seems far more robust than any of the hacks released > thus far. > > It's clear that this discussion will only end when users can play their games > without game-specific hacks. Brilliant idea ! That's what I call being serious with resolving the 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 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #291 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-12-08 09:12:59 --- The simple fact is, this bug matters to a great many people, the pile of hacks dispersed here added value to the many gamers who needed them to be able to play their favorite games, regardless of any technical review process, opinion, or conflict issues. I am all for openness, reasoned discourse, and solving bugs that matter to people. While I do not agree with the hacks either, I do see a strong need for a solution to this problem, I look forward to the supposed XInput2 solution, but for many users this problem can not wait. For this reason I must bring up the topic of DGA mouse grab again, so here is a proposal for pre-XInput2 xorg versions: Lock the mouse using DGA to grab raw mouse deltas, provide the illusion of normal mouse movement using XWarpPointer, release grab whenever a mouse click occurs outside the game window or the application focus changes (due to window manager shortcuts). DGA disables mouse movement and grabs the raw deltas, so this satisfies both aspects of the cooperative mode (mouse moves around with XWarpPointer, while deltas are captured even at borders), there might be a one-refresh pointer lag involved but this is not perceptible, no keyboard grab is used so the standard window manager shortcuts work (alt-tab and so on) to defocus the application, and it might eat a mouse click when clicking outside the game window to defocus the application but this is not a critical problem. I can confirm that DGA works on OpenSUSE 11.2 and Ubuntu 9.10 (both current distributions), and this seems far more robust than any of the hacks released thus far. It's clear that this discussion will only end when users can play their games without game-specific hacks. -- 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 6955] Graphical glitches in NOLF2 demo
by wine-bugs＠winehq.org 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6955 Jonathan <agentc0re(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|agentc0re(a)gmail.com | -- 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 6955] Graphical glitches in NOLF2 demo
by wine-bugs＠winehq.org 08 Dec '09

08 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=6955 --- Comment #26 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-12-08 06:39:20 --- (In reply to comment #25) > However there is an however, rendering suddenly gets everything awfully slow. > Which isn't that nice when you have a decent graphics card > (a GeForce 9600GT in my case). That's because the software vertex blending implementation is doing on the CPU work that should normally be done on the GPU. -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs December 2009