https://bugs.winehq.org/show_bug.cgi?id=48269
Bug ID: 48269
Summary: Tray icon (XEMBED) moves when (0,0) coordinate is
outside of the drawing area
Product: Wine
Version: 4.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: materka(a)gmail.com
Distribution: ---
Created attachment 65934
--> https://bugs.winehq.org/attachment.cgi?id=65934
Monitor layouts
For some uncommon monitor layouts wine tray icon is not working correctly.
When XEMBED is used X11 window should never move, because it is managed by the
system tray. KDE positions all tray icons in (0,0) position and renders them
off-screen (XComposite + XDamage). When screens are configured in a way, that
(0,0) is not is the first screen (?) area (attachment), wine icon tray window
tries to move itself. This repeats, window is moved further and further with
each event (not sure how it is triggered).
For example, primary screen has size 1440x900, second screen 900x1600 (vertical
position) and is positioned right of the primary screen, bottoms aligned. Check
attached picture for reference (second "NOT OK" example). It this scenario
(0,0) is 700 px above the primary screen (1600 - 900 = 700). Wine will move
tray icon to the position (0, 700). This should not happen, because tray icon
window is embedded, so it is managed by parent window.
I *suspect* the move is performed "UpdateLayeredWindowIndirect" in
dlls/user32/win.c. It calls set_window_pos which then moves the window using
X11 functions. I'm not that familiar with X11 to trace it correctly.
I tested mainly with wine-4.21 (Staging), but it also reproducible with old
wine 3.6.
Originally reported on KDE bug tracker:
https://bugs.kde.org/show_bug.cgi?id=414667
--
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=34859
Bug #: 34859
Summary: Serious Sam Classic: the game's world is closed in a
giant cube (Mac OS X only bug)
Product: Wine
Version: 1.7.5
Platform: x86
OS/Version: Mac OS X
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: winebugs140(a)gmail.com
Classification: Unclassified
Created attachment 46460
--> http://bugs.winehq.org/attachment.cgi?id=46460
Serious Sam Classic Log
You can see this especially when looking at the sky, there are also some lines
visible in the ground. I've attatched a screenshot. The bug seems to be GPU
independent.
On Ubuntu everything looks fine.
The problem can be reproduced in the demo (check out the link).
Tested with:
Mac OS X 10.7 and 10.9, ATI HD 2600 Pro, ATI HD 6970M, Geforce 320M, Mac
Driver/X11
--
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.
https://bugs.winehq.org/show_bug.cgi?id=47596
Bug ID: 47596
Summary: Invision Studio installer don't work
Product: Wine
Version: 4.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ieframe
Assignee: wine-bugs(a)winehq.org
Reporter: wiiu3dsxl13127(a)gmail.com
Distribution: ---
Created attachment 65010
--> https://bugs.winehq.org/attachment.cgi?id=65010
Log
The app launch but due to a bug in wine with the ieframe.dll and tzres.dll, the
app make an error
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48262
Bug ID: 48262
Summary: DirectX 9 SDK "lightingvs.exe" fails
Product: Wine
Version: 4.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: yurikazakov9184(a)gmail.com
Distribution: ---
Created attachment 65928
--> https://bugs.winehq.org/attachment.cgi?id=65928
Screenshot
When I try to run the LightingVS demo using WineD3D, I see a blue screen and a
lot of errors in the terminal. Errors occur regardless of the driver used.
Binary file placed in C++/Direct3D/Bin/LightingVS.exe
Source placed in C++/Direct3D/LightingVS
This is Samples folder from other DirectX9 SDK.
This demo is not available in the DirectX 9.29 sdk; it is only available in
older versions of the DirectX 9 SDK.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48243
Bug ID: 48243
Summary: Could not find any compatible 3D devices in RTPatch
sample
Product: Wine
Version: 4.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: yurikazakov9184(a)gmail.com
Distribution: ---
This sample works on Windows, but not working with WineD3D. Error "Could not
find any compatible Direct3D devices. This sample will now exit.".
Binary file placed in C++/Direct3D/Bin/RTPatch.exe
Source placed in C++/Direct3D/RTPatch
This is Samples folder from other DirectX9 SDK.
https://archive.org/download/dx9sdk
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48260
Bug ID: 48260
Summary: DrawText with len -1 returns a different height under
WINE than in Windows
Product: Wine
Version: 3.6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: ryampolsky(a)yahoo.com
Distribution: ---
The following 2 lines of code return different values for 'height' on WINE and
Windows when p points to a null string, but the differences are different.
height = DrawText(hDC, p, -1, &rc, dt_options|DT_WORDBREAK|DT_NOPREFIX);
height = DrawText(hDC, p, strlen(p), &rc,
dt_options|DT_WORDBREAK|DT_NOPREFIX);
On Windows, the first case (length -1 : telling Windows to calculate the string
length) returns a height of 1.
On WINE it returns a height of 14 - i.e. the height of an actual row of text
using the currently selected font.
On both Windows and WINE, the second case (where I pass in the length of 0)
returns a height of 0.
I don't know why Windows doesn't return a 0 height for a null string when you
pass in a -1 length, but both Windows and WINE do this. Except that WINE
returns the height of a row of text, and Windows returns 1 pixel - which ends
up producing no visible different in my code - where this issue shows up.
I changed my code to pass in the length instead of counting on -1 to get
Windows to do it, but I guess any difference between Windows and WINE is a
'bug', huh?
--
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.
https://bugs.winehq.org/show_bug.cgi?id=38921
Bug ID: 38921
Summary: Bionare XT GPUs incorrectly recognized
Product: Wine
Version: 1.7.46
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: linards.liepins(a)gmail.com
Distribution: ---
Recently I had seen this bug in these Applications:
- Crysis 2 ( Non-supported VGA Error on launching )
- Counter-Strike Global Offense ( Engine error on launching )
All these games recognize my Radeon 7790 as Radeon 8770.
I guess this could be somewhat related / duped to this report:
https://bugs.winehq.org/show_bug.cgi?id=33364
--
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.
https://bugs.winehq.org/show_bug.cgi?id=46100
Bug ID: 46100
Summary: GRLevel3 2.52 radar refresh timer is obscenely long
Product: Wine
Version: 3.19
Hardware: x86-64
URL: http://grlevelx.com/downloads/grlevel3_2_setup.exe
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mazecraze96(a)gmail.com
Distribution: ---
"winetricks windowscodecs" is required to start the application.
Radar refresh timer (lower right corner) is obscenely long. Normally about 1-5
minutes (depending on weather in the area), it seems to be offset by the
timezone. It's 300 minutes in UTC-5 but the timer is normal with UTC/GMT.
Looks like GRLevel3 is getting time from two different sources that disagree
with each other, for its countdown, and the time it's counting down to. I
haven't tested UTC+ timezones.
Windows does not keep the RTC in UTC.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=40591
Bug ID: 40591
Summary: a program doesn´t run it begin but in a few time it
crash
Product: Wine
Version: 1.9.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jhony.ardila03(a)gmail.com
Distribution: ---
Created attachment 54442
--> https://bugs.winehq.org/attachment.cgi?id=54442
the game start, then when the game begin it stop and show this report
the game is darksiders 2, im using ubuntu 14.04 lts, the game show the intro,
then it crash and say, we have a serious prooblem.
--
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=27036
Summary: League of Legends store crashes with an assertion
Product: Wine
Version: 1.3.19
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: secur32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mm-meissner(a)gmx.de
Created an attachment (id=34474)
--> (http://bugs.winehq.org/attachment.cgi?id=34474)
libgcrypt threading patch for schannel_gnutls.c
The League of Legends client crashes when one tries to open the store, the
assertion printed to the console is:
ient.exe: ath.c:193: _gcry_ath_mutex_lock: Zusicherung »*lock == ath_mutex_t)
0)« nicht erfüllt.
Translated to english:
ient.exe: ath.c:193: _gcry_ath_mutex_lock: Assurance of »*lock == ath_mutex_t)
0)« not fulfilled.
I'd attach a backtrace if anyone could tell me how to actually create one, but
it's highly possible that this crash is caused by the lack of threading support
in the schannel implementation of wine.
libgcrypt.so.11.5.3
Using the attached patch somehow seems to make these crashes more rare, however
they still occur and the shop is incredible slow.
I'm using libgnutls-26.14.12 and libgcrypt-11.5.3
--
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.