March 2011 - Wine-Bugs - list.winehq.org

[Bug 8871] No text displayed in Bloodrayne2
by wine-bugs＠winehq.org March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=8871 zimmemic25(a)yahoo.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zimmemic25(a)yahoo.de --- Comment #25 from zimmemic25(a)yahoo.de 2011-03-09 12:50:12 CST --- running wine-1.3.15 on ubuntu maverick (uname 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux), i can play bloodrayne 1 fine, but without the videos (had to rename the video folder so the game doesn't show error dialogs for each). but in bloodrayne 2, I have no videos (again), and no textures. e.g. first level: black window, a few red curtains/whatever, and a few white stars or flames (i think flames from these candles) on the floor. can't see Rayne, can't see enemies, but blade effects and blood. and as said, everything that's not a particle effect or animated cloth is just black. fonts also don't show up, but the menu borders show. oh and stdout repeats following message about every second: fixme:d3d:IWineD3DSwapChainImpl_Present Render-to-fbo with WINED3DSWAPEFFECT_FLIP tell me if you want more information. -- 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 14627] New: regedit broken due to locale settings
by wine-bugs＠winehq.org March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=14627 Summary: regedit broken due to locale settings Product: Wine Version: unspecified Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: galtgendo(a)o2.pl I'm not sure I can describe this correctly. I've got a few registry keys that contain Japanese signs (in values). Regedit can't export those keys correctly, when I run in my own locale (pl_PL.UTF-8). They also fail to be displayed then. (The key names are ASCII, the values are not). But when I run as LANG=ja_JP.UTF-8, something strange happens, while regkey can be exported (as CP932, which sucks a bit, IMHO), it can't be viewed. The treeview of the key shows a plus beside it, but the key values are not shown and clicking that plus doesn't expand the subkey (in my standard locale, at least subkey got expanded). (I'll just ignore for now the fact, that in my locale, if keyname is Japanese, it's shown as question signs.) -- 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 38

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #443 from Jouni Järvinen <jounijarvis(a)gmail.com> 2011-03-09 09:35:15 CST --- (In reply to comment #442) > (In reply to comment #441) > > (In reply to comment #440) > > > Is it possible for this patch to be modified so that the mouse is warped back > > > into the application window, at least when the application thinks it's running > > > full screen? > > I guess that mouse warping is not failproof and moreover it's breaking apps > > that do not need it at all. Vitaliy commented before that "any real solution > > should not warp mouse". > > The problem only arises, I guess, when the application thinks it's full screen > but is being run in a virtual desktop. Is there some way for the application > to gain exclusive capture of mouse events so that mouse clicks don't get sent > to other applications? Of course, this would mean that it's *impossible* to > click away from the application, you'd have to use a desktop manager key > binding (eg Alt-Tab). Ain't that the purpose ? -- 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 March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #442 from Michael Abbott <michael(a)araneidae.co.uk> 2011-03-09 08:54:42 CST --- (In reply to comment #441) > (In reply to comment #440) > > Is it possible for this patch to be modified so that the mouse is warped back > > into the application window, at least when the application thinks it's running > > full screen? > I guess that mouse warping is not failproof and moreover it's breaking apps > that do not need it at all. Vitaliy commented before that "any real solution > should not warp mouse". I've no good idea how to solve this problem. The mouse goes wandering all over the screen, and it's very easy to end up giving the focus away. The problem only arises, I guess, when the application thinks it's full screen but is being run in a virtual desktop. Is there some way for the application to gain exclusive capture of mouse events so that mouse clicks don't get sent to other applications? Of course, this would mean that it's *impossible* to click away from the application, you'd have to use a desktop manager key binding (eg Alt-Tab). -- 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 March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #441 from Valeriy Malov <jazzvoid(a)gmail.com> 2011-03-09 06:45:26 CST --- (In reply to comment #440) > Is it possible for this patch to be modified so that the mouse is warped back > into the application window, at least when the application thinks it's running > full screen? I guess that mouse warping is not failproof and moreover it's breaking apps that do not need it at all. Vitaliy commented before that "any real solution should not warp mouse". -- 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 March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #440 from Michael Abbott <michael(a)araneidae.co.uk> 2011-03-09 06:13:43 CST --- Is it possible for this patch to be modified so that the mouse is warped back into the application window, at least when the application thinks it's running full screen? If you run a program with this patch which relies on the current behaviour in a virtual desktop which doesn't cover the entire Linux desktop then while the cursor is outside the application window mouse key presses are being sent to outside windows or the desktop. This can end up triggering all sorts of accidents if you're not paying attention! -- 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 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #78 from Saulius K. <saulius2(a)gmail.com> 2011-03-09 00:24:22 CST --- Hello folks. Lets transfer talks on the hacky patch to the AppDB. This is bugreport and only technical details _related to the bug directly_ are interesting here. So please stop talking about workarounds. There are only 20 usefull comments (at most) in this report. Please keep the noise lower :) Thank you :) Now the tech-details. Vincent Povirk and Jesse Allen have investigated on the bug. Jesse has made a standalone and interactive test-case: http://bugs.winehq.org/show_bug.cgi?id=4009#c27 It would be nice to transform it into autonomous WRT block. Though I am not sure about the way to read and interpret the resulting image (to make difference between bug and normal case). -- 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 26227] New: GetClipboardFormatName() / RegisterWindowsMessage(): thoroughly incompatible implementation
by wine-bugs＠winehq.org March 9, 2011

March 9, 2011

http://bugs.winehq.org/show_bug.cgi?id=26227 Summary: GetClipboardFormatName() / RegisterWindowsMessage(): thoroughly incompatible implementation Product: Wine Version: 1.3.14 Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: andi(a)rhlx01.fht-esslingen.de GetClipboardFormatName() / RegisterWindowsMessage() and related APIs are said to map to identical functions (RVAs) in Windows. In Wine, we have individual USER drivers (winex11.drv etc), and they do their _own_ (even non-ATOM) clipboard format handling. And RegisterWindowsMessage() uses GlobalAddAtom() which is said to be WRONG, too. "Registered Window Message String", http://www.eggheadcafe.com/software/aspnet/30695961/registered-window-messa… clarifies it: both APIs are _identical_, and they make use of _another_ _internal_ ATOM table. I.e., there's the application-global (NULL HINSTANCE?) atom table, application-local (per-HINSTANCE?), and this _system-internal_ table _common_ to both clipboard/messages. Conclusion: incompatibilities abound (and that in a situation where Google "RegisterWindowMessage GetClipboardFormatName" shows 1850 results, IOW a very widely known undocumented Windows behaviour). If correcting the implementation is deemed less urgent, then perhaps it's useful to add a corresponding comment at a prominent place, hinting at these implementation specifics (should probably reference this bug#). HTH, Andreas -- 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 4

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org March 8, 2011

March 8, 2011

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #439 from Dan Kegel <dank(a)kegel.com> 2011-03-08 15:41:24 CST --- Created an attachment (id=33574) --> (http://bugs.winehq.org/attachment.cgi?id=33574) Rediffed to apply to today's git -- 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 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org March 8, 2011

March 8, 2011

http://bugs.winehq.org/show_bug.cgi?id=2082 Manuel Soukup <linuxuser-sky(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxuser-sky(a)gmx.de --- Comment #77 from Manuel Soukup <linuxuser-sky(a)gmx.de> 2011-03-08 15:18:14 CST --- This is still an issue with Diablo 1 and wine 1.3.15 Using the Worms World Party fix for wine 1.2 (2.90 KB, patch) and the wine source od 1.2.2 does fix it but you have to change the stuff manualy cause because of version mismatch patch does not work. The patch does not work on recent wine source (1.3.15) -- 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