http://bugs.winehq.org/show_bug.cgi?id=4745
------- Additional Comments From ivg2(a)cornell.edu 2006-09-03 02:08 -------
Running with oss does not help.
I also got an error that said I should use Emulation instead of Full for audio
acceleration... did that, but the bug remains.
=====================
Attached is a trace with oss, emulation, pixel shaders on.
+d3d, +d3d9, +seh. I don't like the texture errors I see right before the crash.
=====================
Note the
wine client error:ffffffff: write: Bad file descriptor
at the end - sometimes I get many of those...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4778
------- Additional Comments From ivg2(a)cornell.edu 2006-09-03 01:46 -------
I should note that Desktop mode has completely different behavior in the
following ways:
- at the beginning I only see background window and message box, and I am able
to see the background window's background [ but maybe the wizard window is just
covered up? ]. Anyway, the message box is correctly on top.
- the same redraw problems are visible as in Managed mode
- once the wizard window becomes visible, any new message boxes will be modal,
and not allow moving the wizard window around, unlike Managed mode.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4778
Summary: Message box prevents redraw/focus of background window
Product: Wine
Version: 0.9.9.
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-x11driver
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ivg2(a)cornell.edu
This is a clean install of Wine 0.9.9.
Upon launching BattleField Demo 2 installer, the following things show up:
- large background window
- medium wizard window
- message box telling me that "This game has been tested only on WinXP"
However, the large and medium windows will not refresh/redraw at all - the
message box has focus. Moving the message box around leaves draws garbage over
the other two windows.
Worse, however, the message box is not on top of all other windows!
The wizard/medium window is on top, and will stay on top when other windows are
clicked or workspace is changed - it will remain inactive and unable to get
focus until the message box is clicked. Meanwhile, the box is partially covered
by this wizard window. In the GTA installer I've seen a box that is completely
hidden behind such a window, and the user has no way of clicking it.
When I finally manage to click OK, the Wizard box gains focus, and the install
proceeds. If I move around the wizard window, the background window now won't
redraw, and garbage shows up on the screen. If I do something to trigger another
message box (like click Cancel), the box behaves properly and will no longer
prevent redraw/refocus of the wizard window.
Error output includes:
[ the errors at the end are already in bugzilla as a separate bug against
wine-ole component, since they prevent the instll - this bug isn't about those
errors ].
fixme:ole:ITypeInfo_fnRelease destroy child objects
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7d4fe624,0x7d4fe628), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7d4fe620,0x7d4fe624), stub!
fixme:win:SetWindowTextA setting text "TITLE_CAPTIONBAR" of other process window
(nil) should not use SendMessage
fixme:win:SetWindowTextA setting text "Battlefield 2(TM) Demo - InstallShield
Wizard" of other process window (nil) should not use SendMessage
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd3d4,0x7fabd3d8), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd294,0x7fabd298), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd358,0x7fabd35c), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd8c0,0x7fabd8c4), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd780,0x7fabd784), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd844,0x7fabd848), stub!
fixme:win:SetWindowTextA setting text "TITLE_CAPTIONBAR" of other process window
(nil) should not use SendMessage
fixme:win:SetWindowTextA setting text "Battlefield 2(TM) Demo - InstallShield
Wizard" of other process window (nil) should not use SendMessage
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd5a4,0x7fabd5a8), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd464,0x7fabd468), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fabd528,0x7fabd52c), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fab12d8,0x7fab12dc), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fab1198,0x7fab119c), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fab125c,0x7fab1260), stub!
fixme:x11drv:X11DRV_SetWindowRgn not supported on other thread window 0x20022
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fab12d8,0x7fab12dc), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fab1198,0x7fab119c), stub!
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fab125c,0x7fab1260), stub!
fixme:x11drv:X11DRV_SetWindowRgn not supported on other thread window 0x20022
fixme:ole:RpcChannelBuffer_GetDestCtx (0x7d4fe630,0x7d4fe634), stub!
err:ole:dispatch_rpc no apartment found for ipid
{ffffffff-ffff-ffff-0d00-00000a000000}
err:rpc:I_RpcReceive we got fault packet with status 6be
err:ole:dispatch_rpc no apartment found for ipid
{ffffffff-ffff-ffff-0d00-00000a000000}
err:rpc:I_RpcReceive we got fault packet with status 6be
err:ole:dispatch_rpc no apartment found for ipid
{ffffffff-ffff-ffff-0d00-00000a000000}
err:rpc:I_RpcReceive we got fault packet with status 6be
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4353
ivg2(a)cornell.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ivg2(a)cornell.edu
------- Additional Comments From ivg2(a)cornell.edu 2006-09-03 01:23 -------
Confirming bug on clean install of Wine 0.9.9.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4707
------- Additional Comments From cnbiz850(a)sohu.com 2006-09-03 01:18 -------
It works as of today for some reason. This bug can be closed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=1410
------- Additional Comments From myrd(a)projectmagma.net 2006-08-03 23:44 -------
Okay, cross-posting what I posted for Bug #4777:
The source code I'm talking about is in:
http://source.winehq.org/source/dlls/dinput/mouse.c
So...
The bug occurs when Acquire is called, but Unacquire is never called (until the app is about to close).
Furthermore, Acquire gets called multiple times, so the mouse keeps getting recentered, without
unacquire getting a chance to put the cursor back where it was.
While one can argue that this is bad practice from the application programmer's point of view, I think
that's irrelevant - and what's relevant is how Windows behaves: it doesn't center the cursor in such a
case!
So the question is, why does the cursor need to be centered in the first place, and can it be avoided
with a work around?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4777
------- Additional Comments From myrd(a)projectmagma.net 2006-08-03 23:32 -------
Actually, the problem is the exact opposite of my previous post, I believe.
The bug occurs when Acquire is called, but Unacquire is never called (until the app is about to close).
Furthermore, Acquire gets called multiple times, so the mouse keeps getting recentered, without
unacquire getting a chance to put the cursor back where it was.
While one can argue that this is bad practice from the application programmer's point of view, I think
that's irrelevant - and what's relevant is how Windows behaves: it doesn't center the cursor in such a case!
So the question is, why does the cursor need to be centered in the first place, and can it be avoided with a
work around?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4777
------- Additional Comments From myrd(a)projectmagma.net 2006-08-03 23:24 -------
Also, I think WINE assumes that the app will only call Acquire once when it starts, so its okay to center the
mouse then. However, its perfectly okay (though perhaps not very efficient) to call Acquire whenever you
want to get information from the mouse device (such as its current coordinates - oops!).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.