http://bugs.winehq.org/show_bug.cgi?id=7229
Gawain Lynch <gawain.lynch(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gawain.lynch(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.
http://bugs.winehq.org/show_bug.cgi?id=7675
--- Comment #16 from Dan Kegel <dank(a)kegel.com> 2008-03-14 20:04:12 ---
winetricks cc580 doesn't seem to change "save as" much;
either way it works sometimes, but is flaky.
winetricks dcom98 seems to let the app start without crashing.
Oddly, it seems you only need that the first time;
after that, you can remove all overrides and run ok.
I didn't have to remove the problem plugin this run, either!
Without dcom98, the first run crashes like this:
fixme:typelib2:ICreateTypeInfo2_fnSetVarDocString (0x59d1b50,64,L"White"),
stub!
fixme:typelib2:ICreateTypeInfo2_fnSetVarHelpContext (0x59d1b50,0,0), stub!
trace:typelib2:ICreateTypeInfo2_fnLayOut (0x59d1b50), stub!
trace:typelib2:ICreateTypeInfo2_fnRelease (0x59d1b50)->(1)
trace:typelib2:ICreateTypeLib2_fnCreateTypeInfo
(0x58395e8,L"idCursorTypes",0,0x33fa68)
trace:typelib2:ICreateTypeInfo2_Constructor Constructing ICreateTypeInfo2 for
L"idCursorTypes" with tkind 0
wine: Unhandled page fault on write access to 0x0000039c at address 0x7ef9e94a
(thread 0009), starting debugger...
but no stack dump is shown.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #69 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-03-14 19:34:18 ---
(In reply to comment #68)
> using events device would be linux specific, the bug would still remain for
> freebsd, solaris, etc etc.
>
Correct, so the only available options is getting these events from the X
server (pretty much where Wine gets them now).
But the problem with that - it's the absolute coords of the pointer (not the
actual mouse movements). These coordinates don't change if the pointer on the
edge of the screen and doesn't move past it. While mouse can still move.
Which means Wine have to get actual hardware mouse events from X server. The
only way to do that is via XInput extension. However core pointer and core
keyboard can not be opened this way.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #68 from Dean Hamstead <dean(a)bong.com.au> 2008-03-14 19:23:02 ---
using events device would be linux specific, the bug would still remain for
freebsd, solaris, etc etc.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #67 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-03-14 19:17:16 ---
Capturing mouse is not a problem - see XGrabPointer. Reading any mouse
movements _ON THE EDGE_ of the window/display _IS_ the problem. The only way to
do that is:
1. Warp the mouse
2. Read mouse events directly from the device. Be it xevents from XInput (via
the X server - the right way), the evdev events from the device itself. Or some
other source of events (dunno what else is left).
This bug is about consequence of doing 1) because 2) is not available (X server
won't allow to open primary pointer device as an XInput device) or is the wrong
way to do it (reading evdev events directly from the mouse device).
--
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.
http://bugs.winehq.org/show_bug.cgi?id=6071
--- Comment #6 from Austin English <austinenglish(a)gmail.com> 2008-03-14 18:33:04 ---
Still present in wine 0.9.57. Native dcom98 works around the issue.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=6971
Victor <ErV2005(a)rambler.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ErV2005(a)rambler.ru
--- Comment #66 from Victor <ErV2005(a)rambler.ru> 2008-03-14 18:32:17 ---
An idea for possible workaround.
What about using Wine's virtual desktop (if enabled and available) for tracking
mouse outside the window? I mean - comments say, that without a window tracking
mouse position is impossible. But virtual desktop has it's own window, so (as
I understand) this window can be made fullscreen (without decorations, etc) and
used for tracking mouse.
Will this help?
--
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.
http://bugs.winehq.org/show_bug.cgi?id=312
Odair Trujillo <haldrik(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |haldrik(a)gmail.com
--- Comment #10 from Odair Trujillo <haldrik(a)gmail.com> 2008-03-14 17:51:00 ---
Audio record is an important part of audio edit with comercial software like
Adobe Audition, Sondforge, CoolEdit, etc.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=8630
--- Comment #8 from Jonas Aaberg <cja(a)gmx.net> 2008-03-14 16:20:36 ---
Thanks for the explanation!
However I couldn't find any settings like that. I even ran the "Video Setup"
utility that came along the game, but no changes in behaviour.
During the weekend I'll install the game as a different user and see
if it helps.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=8630
--- Comment #7 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2008-03-14 15:31:50 ---
0 hz update frequency means default or selection what the OS prefers. The
interesting thing here is the @24. Since a few wine revisions Wine only
advertises and accepts 8, 16 and 32 bpp, like every video card on Windows that
is newer than 10 years does. We do not accept 24 bpp any longer. This was
needed to clean up the 24 vs 32 bpp mess, and it seems that no Windows card
supports both 24 and 32 bpp.
To add to this confusion, 24 bpp and 32 bpp are the same, except that 32 bpp
has 8 unused bits which are used for alignment padding so the GPU can access
the memory much faster. For 3D games this can be used as alpha information. X11
only advertises bit depth 24, it swallows the 8 unused channels, even though
the driver internally works in 32 bpp mode and has support for framebuffer
alpha.
Could it be that the game has some outdated settings stored from old Wine
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.