July 2010 - Wine-bugs - list.winehq.org

[Bug 1158] Hebrew menus are displayed on the left
by wine-bugs＠winehq.org 13 Jul '10

13 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=1158 elad <el.il(a)doom.co.il> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |el.il(a)doom.co.il --- Comment #9 from elad <el.il(a)doom.co.il> 2010-07-13 04:20:00 --- it is still a problem in wine 1.2-rc6. -- 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 1163] Accelerator underscore appears in the wrong place for Hebrew menus
by wine-bugs＠winehq.org 13 Jul '10

13 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=1163 --- Comment #23 from elad <el.il(a)doom.co.il> 2010-07-13 04:18:16 --- i think this bug should be reopened. -- 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 23630] New: do not scan all font metrics on application startup
by wine-bugs＠winehq.org 13 Jul '10

13 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=23630 Summary: do not scan all font metrics on application startup Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: jstpierre(a)mecheye.net With a good set of fonts, about 800-1200 families, wine is not very good at starting up fast, and it doesn't even respond to signals. The only way I've found to kill it is with a wineserver -k. I was told that wine currently scans font metrics on each application startup. I feel that this could be improved, either by scanning the information needed from the font file lazily or once, on wineserver start. Approximate time, it takes around 3-4 minutes for a cold start of winecfg before effects are visible. -- 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 3

[Bug 23599] New: Texture problems in Deus Ex 2: invisible war
by wine-bugs＠winehq.org 13 Jul '10

13 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=23599 Summary: Texture problems in Deus Ex 2: invisible war Product: Wine Version: 1.2-rc7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: duck(a)duckcorp.org Created an attachment (id=29510) --> (http://bugs.winehq.org/attachment.cgi?id=29510) log (+d3d,+seh) I can launch the game, view the intro scene, the rest of the game loads fine and the loading screen is proper, but then the display is incomplete, both in the menu and in the game: only part of the interface is displayed well, no background and images in menu, no objects in game. It is absolutely unplayable. I'm using Debian unstable on i386, with a Mobility Radeon X300 and the Free driver (v6.13.1), and opengl+fbo (but other combinations of opengl/gdi and backbuffer/fbo didn't help). As can be seen in the log, the problem seems related to: fixme:d3d:state_wrap (WINED3DRS_WRAP0) Texture wrapping not yet supported which is supposed to have been fixed in #8176 (but opening a new report as requested). -- 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 7

[Bug 23624] New: Streets of Moscow completely ignores keyboard and mouse input
by wine-bugs＠winehq.org 13 Jul '10

13 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=23624 Summary: Streets of Moscow completely ignores keyboard and mouse input Product: Wine Version: 1.2-rc7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com Created an attachment (id=29556) --> (http://bugs.winehq.org/attachment.cgi?id=29556) console log Streets of Moscow (a car racing game) doesn't accept any keyboard or mouse input after starting, thus it's unplayable. The issue exists both in fullscreen and virtual desktop mode. So far I've tried the following but none of them worked: - setting the win version to W2k - the XI2_input patch from bug #6971 (my X.Org version is 1.8.2) - the patch from bug #8854 - the rawinput3 patch from bug #10318 > the game crashed on startup in RegisterRawInputDevices() - installing native dinput/dinput8.dlls Unfortunately, no demo is available. Fedora 13 x86 X.Org 1.8.2 -- 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 2

[Bug 20160] New: ieplore: automatic gecko installer crashes
by wine-bugs＠winehq.org 13 Jul '10

13 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=20160 Summary: ieplore: automatic gecko installer crashes Product: Wine Version: 1.1.30 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jsims2359(a)gmail.com Created an attachment (id=23759) --> (http://bugs.winehq.org/attachment.cgi?id=23759) terminal output of wine iexplore In wine-1.1.30, with a clean wine prefix, run "wine iexplore" and the automatic wine_gecko installer will crash while downloading. -- 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 19

[Bug 23607] New: High CPU usage with idle NewsLeecher
by wine-bugs＠winehq.org 12 Jul '10

12 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=23607 Summary: High CPU usage with idle NewsLeecher Product: Wine Version: 1.0-rc5 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: patrick_stokman(a)hotmail.com Since the last two, maybe three RCs, NewsLeecher uses a lot of CPU when it starts and sits idle. No matter what you do, it keeps using one core completely. This wasn't the case with rc1 and rc2 for sure (and before). Sending NL to tray reduces CPU to a better level, but still above normal. Average use on my 2.8 GHz AMD dual core: Tray: ~20% Normal: ~40%-80%, changing every second or so (up/down) Due to this 'abuse', the GUI updates are very slowly, repaints are clearly visible and scrolling is very slow because of that. -- 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 7

[Bug 3028] EVE-Online fails to create the MachoNet cache (FindFirstFile and directory/file names)
by wine-bugs＠winehq.org 12 Jul '10

12 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=3028 --- Comment #20 from Austin English <austinenglish(a)gmail.com> 2010-07-12 10:54:38 --- Created an attachment (id=29555) --> (http://bugs.winehq.org/attachment.cgi?id=29555) precompiled testcase -- 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 3028] EVE-Online fails to create the MachoNet cache (FindFirstFile and directory/file names)
by wine-bugs＠winehq.org 12 Jul '10

12 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=3028 --- Comment #19 from Austin English <austinenglish(a)gmail.com> 2010-07-12 10:52:22 --- The testcase still fails: austin(a)midna:~$ wine ./a.exe FindFirstFile cache/*.* failed with error 3: Path not found FindFirstFile cache/Browser/*.* failed with error 3: Path not found FindFirstFile cache/foo.bar failed with error 3: Path not found CreateFile c:\foo\bar.txt failed with error 3: Path not found CreateFile c:\foo\ failed with error 2: File not found CreateFile c:\foo\*.* failed with error 123: Invalid name -- 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 9030] army men hangs on black screen
by wine-bugs＠winehq.org 12 Jul '10

12 Jul '10

http://bugs.winehq.org/show_bug.cgi?id=9030 --- Comment #30 from Boran Car <boran.car(a)gmail.com> 2010-07-12 07:50:03 --- (In reply to comment #28) > Created an attachment (id=29544) --> (http://bugs.winehq.org/attachment.cgi?id=29544) [details] > Armymen menu - with faked palette > > I had created a simple faked palette just in CreatePalette, so I recieved some > usable pictures. I had stepped through army men initialization process and i > had discovered that this program gives a pretty odd palette to CreatePalette > call - 256-times R:0 G:0 B:0. Maybe Armymen relies on a default palette, maybe > not. Once more interesting article i found is that army men does all the > rendering through GetDC and ReleaseDC, so the palette is not probably needed. > Then the problem is in X11DRV_DIB_MapColor, because the search for acceptable > color fails and the function returns zero index - allways black color. This is > probably more general problem with translating colors between palette and DC. Yes, you are completely right. I had abandoned this for a while, promising to return to it later. I remember using hw breakpoints to see if anything gets copied to the surface memory, and indeed, zeros were copied all the time so I dismissed it as no copying. This might prove the fact that all rendering is done through GetDC and ReleaseDC which in fact call Lock and Unlock and do the translation themselves, hence, we get 24-bit RGB (0,0,0) = 0. Maybe this palette gets input as a result of another function call and game logic. I was planning to make a proxy ddraw.dll on windows and trace the calls to ddraw to get more insight. Can you please provide me with that article? It's possible to obtain the correct default palette from windows and use it in wine. One more thing that might prove this is an odd result while playing Air Tactics on Windows XP. Sometimes, the screen turns into a color noise (probably as a result of a palette change). If we can fix this on Wine, we might provide a ddraw.dll that will make the game (and similar games to it) runnable once more on Windows. -- 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