http://bugs.winehq.org/show_bug.cgi?id=28467
Summary: Chromium Browser restore button doesn't work
Product: Wine
Version: 1.3.28
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fracting(a)gmail.com
1. Download chromium from
http://build.chromium.org/f/chromium/snapshots/Win/95816/chrome-win32.zip
unpack chrome-win32.zip, cd to the directory.
2. start chrome.exe with --no-sandbox, works around Bug 21232
$ wine chrome.exe --no-sandbox
Notice that the chrome window is decorated by the Linux native window manager.
Is it a bug? On windows, chrome have no traditional "window bar".
Now there is two "Maximal" button: one is drawn by Linux native window manager,
the other is drawed by wine chrome browser it self.
3. Click on the "Maximal" button which is drawn by Linux native window manager,
then chrome browser switch to maximal mode as expect.
This time, the Linux native window bar is disappear.
4. Click on the "Restore" button of wine chrome browser. However it doesn't
work. Wine chrome switch to normal mode for a second, then switch back to
maximal mode automatically.
I use ubuntu 11.04 , with traditional gnome desktop, gnome 2.32.1 .
There is some ways to work around:
I. Instead of clicking on the native "Maximal" button in step 3, try to click
the wine chrome "Maximal" button, then everything works as expect.
II. Do not set "Allow the window manager to decorate the windows" in winecfg,
then everything works as expect.
III. Do not set "Allow the window manager to control the windows" in winecfg,
then everything works as expect.
--
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=24182
Summary: Memory Access Violation
Product: Wine
Version: 1.3.1
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: bremm(a)vtnc.org
Created an attachment (id=30442)
--> (http://bugs.winehq.org/attachment.cgi?id=30442)
Console output dumped in a text file
Hi, it's my 1st submission of a bug here, so I don't know exactly if I'm doing
the right procedure. I'm trying to run a game which works fine in Windows with
dx8.
The way I used to get a debug output was too simple:
$ winedbg NFR.exe 2>&1 | tee debug.txt
The result follows attached, and I'm waiting for instructions. I'm able to do
any kind of test once I get directions from someone more experient, since I'm
not a skilled programmer.
Thanks in advance
--
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=32301
Bug #: 32301
Summary: Magicka plain attack rendered incorrectly
Product: Wine
Version: 1.5.17
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: adys.wh(a)gmail.com
Classification: Unclassified
Screenshot 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.
http://bugs.winehq.org/show_bug.cgi?id=23653
Summary: gmax crashes if you select opengl, wgl complains
glBufferRegionEnabled missing from linux opengl?
Product: Wine
Version: 1.2-rc7
Platform: x86
URL: http://www.turbosquid.com/gmax
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
http://forum.winehq.org/viewtopic.php?t=8984 mentioned that gmax
crashes if you select opengl. Sure enough, after doing 'winetricks vcrun6'
to work around bug 23652, the app runs unless you choose opengl.
(I think you can choose opengl after the fact by editing gmax.ini to say
GFXType=OpenGL
but I'm not sure what else you might need to edit.)
WINEDEBUG=+seh,+wgl shows
trace:wgl:is_extension_supported Checking for extension 'GL_KTX_buffer_region'
trace:wgl:wglGetProcAddress func: 'glBufferRegionEnabled'
trace:wgl:wglGetProcAddress extension not found in the Linux OpenGL library,
checking against libGL bug with glBufferRegionEnab..
warn:wgl:wglGetProcAddress Did not find function glBufferRegionEnabled
(glBufferRegionEnabled) in your OpenGL library !
trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=002b
This is on a system with current nvidia hardware and proprietary drivers.
--
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=25412
Summary: Shareaza does not save certain preferences [RE: Bug
14269]
Product: Wine
Version: 1.3.8
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: trapdoor6(a)gmail.com
This is a similar issue as described in bug #14269 [still open] but it's
related to different Wine versions: 1.3.8. I also noticed it on a few earlier
developer and stable versions, I guess it's been never fixed in Wine. Please
find details below:
------------------
Software: Shareaza
project page: http://shareaza.sourceforge.net/
version: 2.5.3.0
Problem details:
1) Under 'Tools > Shareaza Settings > General > Library'
option: 'Quick hashing (Uses more CPU)'
Enabling it works only for one session. After restarting Shareaza it's disabled
again.
2) Under 'Tools > Shareaza Settings > Networks > Gnutella' and '~ > eDonkey'
option: 'Always connect to Gnutella / eDonkey'
Enabling these won't be saved. After restarting Shareaza both are disabled
again (which means that Shareaza connects only to Gnutella1 and I need to
connect to the other networks manually in the 'Network' tab in the main
window).
--
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=32326
Bug #: 32326
Summary: DirectSound output in SNES9x gives crackling/glitchy
audio
Product: Wine
Version: 1.5.18
Platform: x86-64
URL: http://files.ipherswipsite.com/snes9x/snes9x-1.53-win3
2.zip
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: directx-dsound
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: markk(a)clara.co.uk
Classification: Unclassified
This bug applies to the SNES9x Super NES emulator. I'm testing with Wine
1.5.18-72-g0c0b229, Lubuntu 11.10 x86-64, Nvidia driver 304.64, SNES9x 1.53.
(I set the bug component to directx-dsound, but that might not be correct.)
Sound output using DirectSound is very CPU-intensive, and the sound
crackles/glitches. Or rather, something about the sound output takes a
relatively long time. According to "top" the CPU usage of SNES9x itself doesn't
go through the roof with sound enabled.
Emulation speed easily reaches 60fps with sound output disabled. On native
Windows that's the case with DirectSound output (as opposed to the default is
enabled too. CPU usage with sound disabled is ~26%.
However on Wine with 48kHz DirectSound output the frame rate I see drops to
~45fps, CPU usage in top ~24% (lower usage because fewer frames per second are
being emulated). If I disable the "Sync Sound" option frame rate returns to
60fps, ~30% CPU, but the sound still crackles.
That's with the default buffer length of 64ms. Increasing that to 210ms helps a
bit; I get 60fps even with Sync Sound enabled, though the sound still crackles.
Decreasing buffer length to 16ms I get about 10fps with Sync Sound enabled.
I don't think this problem is due to my hardware; other sound-producing
programs like Audacious, flash plugin etc. seem to be fine. And by comparison,
the Nestopia NES emulator in Wine produces (almost) glitch-free sound
regardless of the program's latency setting.
$ lspci -vv -s00:1b.0
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
Subsystem: Lenovo Device 384e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 47
Region 0: Memory at fc300000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
To hopefully reproduce the issue:
- Download and unzip SNES9x
- Download a ROM image, e.g. from
http://pdroms.de/files/supernintendoentertainmentsystem/skipp-and-friends-p…
- Run SNES9x. Choose Sound->Settings... and change Sound Driver to Snes9x
DirectSound and Playback Rate to 48 KHz. (Selecting any other rate causes a
crash for me, see bug 32312.)
- Select Video->Display Configuration... and change Output Method to
DirectDraw. (The default Direct3D just gives a blank screen, see bug 32319.)
- Select File->Load Game... and choose the ROM image.
- You should see graphics in the window and hear crackling/glitching sound.
- In the sound settings, you can experiment with changing the buffer length and
toggling the "Synchronize with sound core" option. I couldn't find any
combination which gave artifact-free sound.
For a +dsound log see the one I uploaded for bug 32312 at
http://bugs.winehq.org/attachment.cgi?id=42668
--
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=17836
Summary: Motocross Madness 2 crashes at start
Product: Wine
Version: 1.1.17
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
Created an attachment (id=20098)
--> (http://bugs.winehq.org/attachment.cgi?id=20098)
trace and disassembly of crash location
In AppDB, people have reported Motocross Madness 2 (mcm2) crashing in the intro
but nobody had filed a bug yet. The backtrace makes it look like mcm2 crashes
in, or immediately after, quartz.dll or amstream, after accessing ui\events.avi
at the start of the program, after displaying for some seconds the stunt &
warnings picture also known from the demo.
The demo is not affected and proceeds from the intro picture to the menu.
A log extract (+almost-all,-relay,-nls) from around the exception is attached.
The processed file UI/events.avi is an Intel Indeo v5 video. The installer did
not complain that Indeo is mising! Replacing it with a Cinepak avi, with an
empty file, deleting it or installing iv5 still produces crashes at the same
location in mcm2. Same with clicking to skip the intro picture or disabling
quartz.dll.
MCM2 suffers from SafeDisk 1.41.000 protection so it would not run as is in
wine (or rather, it crashes much earlier). I tried 2 different cracks, both
produced the same exception.
--
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=24320
Summary: Unexpected DetectEnvStatus.exe crash with Cisco Quick
VPN Client (QVPN 1.4.1.2)
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ethanfharris(a)gmail.com
Cisco QVPN v1.4.1.2 does not work under Wine. QVPN is used to establish an
IPSec Virtual Private Network tunnel from a client computer to a Cisco
Router/Gateway to facilitate secure communication over the internet.
There appear to be 3 errors when running the Cisco QVPN application under Wine:
(a) an apparent crash / closure of DetectEnvStatus.exe
(b) a failure to resolve a DDNS domain name, and
(c) QVPN is not able to ping the gateway router, and all data transfer over the
VPN fails.
In all cases a popup box appears (see attached screenshot) indicating that
DectectEnvStatus.exe has a serious problem and has closed.
If anyone wants to debug this, I can supply a copy of QVPN, and I can set up a
temporary guest account on my WRVS4400N small business router for testing
purposes. QVPN works fine under Windows Vista SP2, and works fine on a Ununtu
10.04LTS host with a Vista guest running under Oracle VirtualBox. So the QVPN
application itself is OK, and the problem is related somehow to Wine or various
underlying services.
On the attached screenshot the DetectEnvStatus popup appears immediately when I
attempt to connect the VPN. If I use the IP address of the gateway router I am
connecting to in lieu of the DDNS domain name, QVPN will create the VPN, but
the tunnel verification ping test fails and the tunnel will not transmit data,
which is why the "remote gateway not responding" message also appears on the
screenshot. If I specify the DDNS domain name of the remote gateway router,
the VPN tunnel is not established (not shown), suggesting a dynamic DNS
name-to-IP address resolution related problem in Wine.
Any help would be appreciated.
--
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=23950
Summary: MPQEdit: Opening a folder results in the wrong error
message
Product: Wine
Version: 1.3.0
Platform: x86
URL: http://zezula.net/download/mpqediten32_beta.zip
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: adys.wh(a)gmail.com
Attachment #30066 showcases the expected error message ("The system cannot find
the path specified"). Instead, running wine mpqedit c:\\ results in "Access
denied" error message.
--
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=30853
Bug #: 30853
Summary: Wine doesn’t always handle "right alt" properly
Product: Wine
Version: 1.5.5
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: sloonz(a)gmail.com
Classification: Unclassified
Created attachment 40410
--> http://bugs.winehq.org/attachment.cgi?id=40410
workaround/quick and dirty fix
I’m trying to get World of Warcraft working under Wine. However, I have huge
trouble with key bindings (I use unusual key bindings : I use the right half of
my keyboard, whereas most players use the left half).
After investigation, I found 3 bugs (different behaviors between Wine and my
Windows installation). The first one is the management of the right "Alt" key
(labeled "Alt-Gr" on my keyboard). When I press AltGr+l under Windows with
Spy++, I get the followings events :
<03637> 0007045A P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D
fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<03638> 0007045A P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38
fExtended:1 fAltDown:1 fRepeat:0 fUp:0
<03639> 0007045A P WM_KEYDOWN nVirtKey:'L' cRepeat:1 ScanCode:18
fExtended:0 fAltDown:1 fRepeat:0 fUp:0
<03640> 0007045A P WM_DEADCHAR chCharCode:'002F' (47) cRepeat:1 ScanCode:18
fExtended:0 fAltDown:1 fRepeat:0 fUp:0
<03641> 0007045A P WM_KEYUP nVirtKey:'L' cRepeat:1 ScanCode:18 fExtended:0
fAltDown:1 fRepeat:1 fUp:1
<03642> 0007045A P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D
fExtended:0 fAltDown:1 fRepeat:1 fUp:1
<03643> 0007045A P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38
fExtended:1 fAltDown:0 fRepeat:1 fUp:1
Under Wine 1.5.5 however (WINEDEBUG=+msg), I get those :
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x6007e wp eb
lp 760001 [note: wp = VK_OEM_PA2]
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp 4c lp
c0260001 [note: wp = 'L']
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp eb lp
c0760001 [note: wp = VK_OEM_PA2]
With xev, I get :
KeyPress event, serial 93, synthetic NO, window 0x4000001,
root 0xbc, subw 0x0, time 5086996, (1585,410), root:(2578,425),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 93, synthetic NO, window 0x4000001,
root 0xbc, subw 0x0, time 5087052, (1585,410), root:(2578,425),
state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XFilterEvent returns: False
After "setxkbmap us", AltGr is bound to Alt_R under X (checked with xev), and I
get this under Wine :
trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp
a5 lp 21380001 [wp = VK_RMENU]
trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp
4c lp 20260001 [wp = 'L']
trace:msg:peek_message got type 6 msg 106 (WM_SYSCHAR) hwnd 0x10046 wp 6c
lp 20260001 [wp = 'l']
trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10046 wp 4c
lp e0260001 [wp = 'L']
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10046 wp a5 lp
c1380001 [wp = VK_RMENU]
(yes, I have a KEYUP without KEYDOWN)
Wich is still not the same as Windows. So I think there is two problems here :
- ISO_Level3_Shift is not properly recognized by Wine
- "AltGr" doesn't have the same behavior under Wine and Windows
FYI, attached patch is a workaround to have the same behavior than Windows.
With it, I get this under Wine :
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a2
lp 1d0001 [note: wp = VK_LCONTROL]
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a4
lp 20380001 [note: wp = VK_LMENU]
trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp 4c
lp 20260001 [note: wp = 'L']
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp 4c lp
e0260001
trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10062 wp a2
lp e01d0001
trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp a4 lp
c0380001
Which is still not the same as Windows :
- Windows uses (right) control + menu (with fExtended flag for menu) whereas
Wine uses left control + left menu. Not investigated if this is related to
TranslateMessage.
- AltGr+L is a dead symbol on my keymap. Windows send a DEADCHAR message,
wheras Wine send nothing. Note that I had to disable the XFilterEvent test in
event.c to have those messages, otherwise nothing is sent to the program (but
that’s another story for another bug report)
But it suffice for my use case (WoW key bindings with right alt)
--
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.