Re: D3D command stream patches for testing
Stefan, are these patches already present in the wine 1.7.2 release? Now that the official 1.7.2 Ubuntu packages have been published, I'm trying to figure out how to get your CSMT changes into the PPA that I maintain.
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-15 21:47, schrieb Forest: >> In the past months I have been working on a command stream / >> worker thread for wined3d. It moves most OpenGL calls into a >> separate thread to improve performance (bug 11674) and fix some >> bugs that are otherwise hard to fix (24684). > > Thank you, Stefan! > > I applied your patches to the Ubuntu PPA that I maintain for Guild > Wars 2 players: You are fairly lucky with Guild Wars 2. I didn't see any improvement in this game myself. But as Henri said, it depends a lot on the game and your GPU and CPU. Afair GW2 uses dynamic surfaces, so the patchset doesn't achieve its full potential yet. Even if it does, it removes fixes one potential performance issue. It doesn't magically fix everything. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSNhVlAAoJEN0/YqbEcdMwDFsP/iAUFAosFIGjlfPkEKm8n+n4 NSdwb9C53mHBQM8zYyFfwAgAGVxuH9HMF0g12+xpSaS2YSTZtzlZO7/4lswZ2uM4 IDVSYALYyy4gEfMb4YEC0c0qJBvm2qiJhPZPo0FGrw26H+yGfEPDmW01+PI+scbU krlwtKlxJtOcIBhxpcO7lCMyi1ALJ2ir7w9RE5CBvwf2sMo0QrtHvd6TuClKhEbJ PpIWcJn24Feu14CutDk2dVwvCeIccuRzWH7ATcPhYk44FSyZjm83GA1wvZH4NEwP jjuq1H8hIgFSyJQkfGnsCrHLQGVgiAYuhE3KSa0eEebaicfhlIrCz9Ts0cjnhCoq Wka4L+lHIBYGy32y24q256B+M/MB2/k80FXVBOCFkqV5HQetYe033B7AVHew6HCV g3n7LLfZXQO2h8+OCwGwopyE6ltTpqvB/Y64/tR3yKzacbGH9xiI+WfF+LFZIod9 q5Vl3bbT3rgnqfkMJki+uEGYK9xtNcFZRnz7eb4bsAD7XX6VGVLW8p71a9nUeUvE TW1YMbPU2ZRDFL7X0MWS4HE1pgGX7gIASQiPSdUWtcYmco5xSTWmrnCkh+B6zuA/ XKvVdc+cCE4IXaxxJiINmUnCnqKumwZudqF2vqqxdpHIvXhFodIhxaYPKW1lh6yB kV+hKqlEroLRsheS7KP/ =jcSo -END PGP SIGNATURE-
Re: D3D command stream patches for testing
>In general, this patchset helps more for mostly CPU limited >applications than for mostly GPU limited applications. That roughly >means that in general you'll see a larger difference on lower >resolutions or with less demanding applications / graphics settings, >and that you'll see a larger difference in cases where the GPU is >relatively fast compared to the CPU. In applications that are mostly >GPU limited, performance tends to depend mostly on the quality of the >GL driver's GLSL compiler, or lack thereof. Understood. Guild Wars 2 is widely acknowledged to be CPU-bound, and generally gets awful frame rates when running on wine/linux compared to the same hardware on windows. I look forward to seeing results from more GW2 players using these patches. For anyone interested, a few players have begun to post their results in the AppDB comments: http://appdb.winehq.org/objectManager.php?sClass=version&iId=26558#Comment-87382
Re: D3D command stream patches for testing
On 15 September 2013 21:47, Forest wrote: > I wonder if the 80%+ gains reported in other games are not to be seen in > Guild Wars 2, or if they're heavily dependent on CPU, GPU, graphics driver, > and screen resolution. > > For the record, I'm using an Intel i5-3570K (stock speeds), GeForce GTX > 660Ti (factory overclocked), nVidia driver 313.30, and a 1920x1200 display. > I'm running Xubuntu 64-bit. My in-game options are: > > Resolution: Full Screen - 1920x1200 > Refresh Rate: Default > Frame Limiter: Unlimited > Interface Size: Normal > Animation: High > Anti-Aliasing: FXAA > Environment: High > LOD Distance: High > Reflections: Terrain & Sky > Textures: Medium > Render Sampling: Native > Shadows: Medium > Shaders: Medium > Post-Processing: High > Character Model Limit: High > Character Model Quality: High > + Best Texture Filtering > + Depth Blur > + Effect LOD > + High-Res Character Textures > - Vertical Sync > In general, this patchset helps more for mostly CPU limited applications than for mostly GPU limited applications. That roughly means that in general you'll see a larger difference on lower resolutions or with less demanding applications / graphics settings, and that you'll see a larger difference in cases where the GPU is relatively fast compared to the CPU. In applications that are mostly GPU limited, performance tends to depend mostly on the quality of the GL driver's GLSL compiler, or lack thereof.
Re: D3D command stream patches for testing
>In the past months I have been working on a command stream / worker >thread for wined3d. It moves most OpenGL calls into a separate thread >to improve performance (bug 11674) and fix some bugs that are >otherwise hard to fix (24684). Thank you, Stefan! I applied your patches to the Ubuntu PPA that I maintain for Guild Wars 2 players: https://launchpad.net/~foresto/+archive/winepatched/ I'm not seeing a spectacular difference with the CSMT patches, but I am seeing a difference. I ran some quick tests in Guild Wars 2 while standing still outside the Lion's Arch bank, looking down at the forge with a moderate number of players milling about and fireworks being launched. Pierre Franco said (earlier in this discussion) that he gets better results when running with the -dx9single command line switch, so I tested with and without it. Note that I play with the WINEDEBUG=-all environment variable. Here are my results: CSMT="disabled", running with -dx9single: 15-16 fps CSMT="enabled" running without -dx9single: 19-21 fps CSMT="enabled", running with -dx9single: 22-23 fps So, almost 50% improvement for me, which is not what I remember when running natively under Windows, but is still a very welcome improvement. I wonder if the 80%+ gains reported in other games are not to be seen in Guild Wars 2, or if they're heavily dependent on CPU, GPU, graphics driver, and screen resolution. For the record, I'm using an Intel i5-3570K (stock speeds), GeForce GTX 660Ti (factory overclocked), nVidia driver 313.30, and a 1920x1200 display. I'm running Xubuntu 64-bit. My in-game options are: Resolution: Full Screen - 1920x1200 Refresh Rate: Default Frame Limiter: Unlimited Interface Size: Normal Animation: High Anti-Aliasing: FXAA Environment: High LOD Distance: High Reflections: Terrain & Sky Textures: Medium Render Sampling: Native Shadows: Medium Shaders: Medium Post-Processing: High Character Model Limit: High Character Model Quality: High + Best Texture Filtering + Depth Blur + Effect LOD + High-Res Character Textures - Vertical Sync
Re: D3D command stream patches for testing
Hi Stefan,
I've tested two games "FarCry3" and "Splinter Cell Blacklist" with :
- Wine 1.7.1 + CS patch + CSMT On/Off
- Wine 1.7.1 clean
- CSMT On = CSMT enabled + StrictDrawOrdering disabled
- CSMT Off = CSMT disabled + StrictDrawOrdering enabled
I run the game by *WINEDEBUG=fps,err-all,fixme-all primusrun
/home/berillions/Desktop/Build/32/wine-1.7.1-{clean/csmt}/wine "$1" 2>&1 |
tee /dev/stderr | grep --line-buffered "^trace:fps:" | osd_cat -c white -s
1 -l2;*
## My Laptop ##
- Nvidia GTX670MX
- Intel I5-3230M
- Debian Sid 64-bits
- Nvidia drivers 325.15
## FarCry 3 tests ##
Graphic options :
- Texture : High
- Ambient Lighting : High
- Shadow : Ultra
- Post Fx : Ultra
- Geometry : Ultra
- Vegetation : Very High
- Terrain : High
- Water : Very High
- Environment : High
Wine 1.7.1 clean :
- Main Menu : ~35 fps
- In-game (move or static camera) : ~12 fps average
Wine 1.7.1 + CS patch + CSMT Off :
- Main Menu : ~45fps
- In-game : ~14 fps average
Wine 1.7.1 + CS patch + CSMT On :
- Main Menu : ~45fps
- In-game : ~18 fps average
## Splinter Cell Blacklist ##
Graphic Options :
- Texture detail : Ultra
- Shadow Quality : High
- Parallax : On
- Tesselation : Off
- Texture Filtering : Anisotropic 4x
- V-Sync : On
- Dynamic ambient Occlusion : Field AO
- Anti-Aliasing : FXAA
- Directx : Dx9
Wine 1.7.1 clean :
- In-game : ~15 fps average
Wine 1.7.1 + CS patch + CSMT Off :
- In-game : ~15 fps average
Wine 1.7.1 + CS patch + CSMT On :
- In-game : ~3 fps average
In resume, CS patch works for FarCry 3, +6fps but cause a very low fps for
SC Blacklist, divide by 5 the fps in game.
Max
RFC: Completely revised SIO_ADDRESS_LIST_CHANGE patches
As some of you know I've been working on fixing SIO_ADDRESS_LIST_CHANGE in order to fix some problems with Silverlight on a variety of streaming sites. Due to some feedback I've received I've gone to the effort to completely revise these patches to work inside of the server instead of using iphlpapi. Any and all feedback is appreciated, special thanks go to Sebastian Lackner for looking over these patches ahead of time. Design considerations: 0001) This patch was modeled after similar behavior for unimplemented ioctl() calls in ntdll 0002) The implementation uses a per-socket queue so that when a socket is destroyed prior to a notification event then that socket's async operations are all appropriately woken up. Only one interface change notification object exists at a time, so the object is destroyed whenever there are no sockets expecting events and is then re-created as needed. 0003) This patch is a simple test case with the rest of the socket tests #ifdef'd out for your convenience Looking forward to hearing back! Best, Erich 0001-ws2_32-Ask-the-server-to-process-unsupported-WSAIoct.patch Description: Binary data 0002-server-Implement-an-interface-change-notification-ob.patch Description: Binary data 0003-ws2_32-Add-an-interactive-test-for-interface-change-.patch Description: Binary data
D3D command stream patches for testing
I've tested some games (wine 1.7.1 64-bit for Guild Wars 2 and SCII, 32-bit for Skyrim, no wined3d/d3d patch except the patchset for CSMT). I have a GTX660 (slightly overclocked, +10 Mhz or so) with the 325.15 Nvidia blob and an Intel i5 2500K (overclocked to 4.2 Ghz). #Guild Wars 2(in the Lion's Arch with ~75-100 players, always from the same spot): Quality Options: -Fullscreen Mode -1600x1200 -Animation: High -Anti-aliasing: FXAA -Environment: High -LOD: Excellent -Textures: High -Reflections: Land and Sky(causes high frame rate drops when moving the camera) -Render Sampling: Supersampling -Shadows: High -Shaders: High -Post-processing: High(absolutely doesn't influence frame rate) -No High Res Character Textures -Character model limit/Character model quality: Medium -VSyng: Off -Optimal Texture Filtering: Off(no real effect except reducing the FPS) Without -dx9single(it should use more than one core and DX10 then): -With __GL_THREADED_OPTIMIZATIONS: 30-45 FPS in the login screen, 8-10 FPS when not moving the camera, 3-5 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: 60 FPS in the login screen, 18-20 FPS when not moving the camera, 5-10 FPS when moving it. With -dx9single(the game is far more quicker to load with it): -With __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 5-20 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 20 FPS when moving it. Conclusion: -dx9single is GOOD and __GL_THREADED_OPTIMIZATIONS is BAD. #Starcraft II Quality Options: Ultra(default mode, also for the textures). The game claims 50-70 FPS, but it seems to lag when moving the camera and the output is only trash (I need to change a graphical setting to be able to see anything). With __GL_THREADED_OPTIMIZATIONS, it's even more laggy and the FPS drop below 40. #Skyrim Quality Options: Very High. I can't see the FPS of the game, but it was running smoothly and is still running smoothly with the patchset. I didn't tried with __GL_THREADED_OPTIMIZATIONS(well, I tried long ago, and that was horribly slow). I also want to say that wine is spamming "Waiting for the cs" in the console (I assume it's nothing really important as the project seems to be WIP, why asking for tester otherwise?) and wgl errors (err:wgl:wglFlush wglFlush). Cordially. P.S. : Sorry for my English, I am still learning it. -- Pierre Franco nob.dir.i...@gmail.com
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-04 20:11, schrieb Prot Secret: > Hi, I am interested in your work, but after patching wine171 of > this patch and enabled csmt, i have seen this in SC2 > http://postimg.org/gallery/1w8y6jbg I use nvidia GTX 680 with > proprietary i386 nvidia driver 319.49. > > Where I could be wrong, or what else can be set that would be > normalized image using the patch? Not your fault, there is a race condition in the surface code that was recently introduced. I will post an updated patchset in the next few days. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKDfBAAoJEN0/YqbEcdMw8WgP/RoPby9sd8BrVCeCU6MpjNYf 5belZtZir82BWGbR5EyO0bUq6gjVUaIMRK1daeoMLbv3TXKTGc8H9NdbZNZKldjl b2WIXHWTNC0wS6xuEeNNasCuX9TvAzpMUOuLtdUBzaGSYqpW2hHW4h6weTL/ytfO moQrbL0C3KZb/K6nPJiwDAbFR+gHk8C+aog0NUFJDj/kvRXHif+6yMyDzFsK8FX0 U5pnVa9/eyoAV2Qc42gruD3PP/VLulua9xk0nB4sDp+hBlqYtOv8IULY0D0J7nTd XwEvDczy4tf60lhoivcIajDxP2CvTAbQSlM+nbPN7kJua6S/5CRlHzaI+cyWiWII za6I3UKcMJP6J8aPg7Rbt/lVhN4xGwYQrSih5cZg3iIzFvuXPbDwg1ZjSzdyK6ya xzd3t2BrOt4yrq3scGw3BcbMOKCvnq5/PiNgw2HGhnkISIAzv1vHcizMQDTHmu97 znlRJ/ynYxXuOinSBqM7Y44mKXx+IwgQBQjBI1TZLHIJYB7MN9+YIuDT7GvGY8r0 20cOS9pkdaYVXNyjRZ8bQkoQ14lCnsHaZ1Kre3fQzhNCuWRcCxq0jKFORnFZ+A+w 8axUENqD1frASvVtFQ0uKMiRXRmk5bIJZ1uJscupAGRWQbV4yflEiQ9eTODH+1Uc NMTqvTumhE5/CdB3mJmF =dIov -END PGP SIGNATURE-
Re: D3D command stream patches for testing
Hi, I am interested in your work, but after patching wine171 of this patch and enabled csmt, i have seen this in SC2 http://postimg.org/gallery/1w8y6jbg I use nvidia GTX 680 with proprietary i386 nvidia driver 319.49. Where I could be wrong, or what else can be set that would be normalized image using the patch? Thanks!
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-04 16:30, schrieb Vedran Rodic: > Using a blit copy to avoid stalling on 12b glBufferSubData() to a > busy buffer object. The long term plan is to use GL_ARB_buffer_storage to create buffers that can be used for rendering while mapped. That avoids the doublebuffered buffer thing and glBufferSubData calls. I don't know exactly what the driver means with "blit copy", but I guess it creates an additional copy of the new data rather than writing it to the mmap()ed GPU memory directly. It shouldn't hurt too much. > I'm not sure how much this really impacts performance, but even > with my Dota 2 wine perf hacks [1] it's not faster than current > Wine git (performance is very similar). Mostly the nvidia blob on Linux, but also some testing on OSX. I got a lot of reports of crashes on Mesa. I think there are race conditions in the driver that won't go away until I've moved all GL calls into the worker thread. Are you GPU or CPU limited? If you're GPU limited, those patches won't change anything. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJ74YAAoJEN0/YqbEcdMwtOEP/R70M0MDrQcwwYVfE6JO5oqN ilBs6sWjcYing2ynTwD7jjHjEK9HuO89gOmVW1khD/gBEPAwSomrCW9AHQKhDUra ycx9smrE9zqejBvpXSPYQQDgy9u2D6o9pY243+veAhNcuk+27GmsLBnZOWs2ggAP P93pNPCS3KTqd2aGSILqZ0fmHipommvA08ftNKfVTC7eqY7p+w6gatuJVKtjBDBd ZVo5Em4x+UCwjv0Vm/qIHiA2iaspl3aZr+TKIlmU8KuBoO/O9z4iDhHwa70YlBss mATg9yrh9eFhtIX5aIolS62GfpbmFApjzllULjJzJ0PYz51oknBAlVEG2emKvqmg JrINQJrv/u4OPBU5rOTH8A4XdAgFjN5nVVrF2Yhw6su6z7tyy2xS11kcOQiTTs9R U2s/EaqiKIrK9wu1Sq2Vwb8afoBgGB6eBTOJJTaxi7+IkbRh9KBy5EN5s38LyvMe JtxUS4zMeaIDIePM76nBYZAulo62p2vDDtrlTIigt1FZEpth3oCV9WT1l23SUV3C 8dniiSZoxOh8G2I88J3FjbWd3CaBktS6zsAUuw3r8kL/TzeOwXXVIQeZSZxd5TsN 64GmvFm7RpOncnOb09EQmlgx150jRBi9kTfDfokryfnHdNVAhamIuPxX6P8QY4bP IJL8AEIU9lLa/z4DVzWU =vcwM -END PGP SIGNATURE-
RE: D3D command stream patches for testing
Hello, I was not subscribed to wine-devel, so I can't reply to Stefan's mail directly, but here are some of my observations with Dota 2 on an Intel HD4000 GPU. Intel Mesa driver doesn't seem to like glBufferSubData in a way this patchset uses it. I get many many messages like these per frame when I enable INTEL_DEBUG=perf performance feedback of the Intel Mesa driver: Using a blit copy to avoid stalling on 588b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 480b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 480b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 1104b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 252b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 204b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 192b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 192b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. I'm not sure how much this really impacts performance, but even with my Dota 2 wine perf hacks [1] it's not faster than current Wine git (performance is very similar). On what hardware did you test this patchset? [1]: http://vrodic.blogspot.com/2013/08/dota-2-wine-optimization-for-intel-gpus.html
Re: D3D command stream patches for testing
On Tue, 3 Sep 2013 08:57:48 -0500 Rosanne DiMesio wrote: > Third patch doesn't apply: Nevermind. I figured out my mistake (overlooked the part about applying to 1.7.1). -- Rosanne DiMesio
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 15:57, schrieb Rosanne DiMesio: > On Mon, 02 Sep 2013 15:55:18 +0200 Stefan Dösinger > wrote: > > >> You can test the attached patches by applying them (git am >> /path/to/patches/*) > > Third patch doesn't apply: They are against Wine 1.7.1, not yesterday's git. I haven't rebased them yet. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJexEAAoJEN0/YqbEcdMwGk8P/0Q8N0OWjO0PfdmiQjfJDE8x 4Uqw+om97nE9TCl4gyT32iQgh2bzmd4+FYXJnJ1aFL995iYO/Vmqxy62chmnD9uq 4wH0T4PlHQDn2gA9nWqhrTWCjVEwkhJCM0I7+SD8jzCELgtIS6Ggb6BBNh6Bt6nZ xC97uvejM4ann466I2lii86kNN8zGQwyenZXaimLc8RJptqmTz0xV4adr8WDGINO 2eVV2YwGWBZo8RCQXCQdw2fneCIL325JxlZ3l1PX+tVUhLKRcg2AxkcnL5TsYuRV ZzlQ5bpt+aaFAoqqGpy2vrBwiaJjidXnwVNitzfdKDU2QN5Z513COJF0nmPi737z U+sgDh1Sl231KPlVMrkbQvRujyNlmf//ufvBYPYuFrBys1EFSGht7zCS8tpKG4+L oFR+K651bA8T4nJZuNGmOk5E21Xfzy+H+W3IyyrXbskka6CJEpvfTH3EL03iaadW xXzQ1+H4FKvewDYG2bVmDs/6SX7S8voA6gdg2mNLZzYkHh2PTh1j0Zq4FThV9STt I5KriTDxR9ZBBJIJC0C2YgY4qkZ0sIWyHhJ/gX1I2g6Um+DJfhlARYDYp1IEN4/I SjUQePGKdQKPzNjcVGilvf304Cz3cHe2MHZx6NN+LZ/0Hec3QGGUtuOndd+Q++mb Q5uh8m0TrRJXM70BPrmg =LGn/ -END PGP SIGNATURE-
Re: D3D command stream patches for testing
On Mon, 02 Sep 2013 15:55:18 +0200 Stefan Dösinger wrote: > You can test the attached patches by applying them (git am > /path/to/patches/*) Third patch doesn't apply: Applying: wined3d: Don't mess with the device in buffer_create_buffer_object Applying: wined3d: Don't mess with the device in buffer_get_sysmem Applying: wined3d: Pass the context to the main buffer preload function error: patch failed: dlls/wined3d/buffer.c:732 error: dlls/wined3d/buffer.c: patch does not apply Patch failed at 0003 wined3d: Pass the context to the main buffer preload function The copy of the patch that failed is found in: /home/dimesio/wine-git/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -- Rosanne DiMesio
Re: Synchronization-patches of widl
Am 08.08.2013 10:56, schrieb Kai Tietz: > All these changes were necessary to support the VLC-people to begin > with their WinRT port. By this we began on mingw-w64 to improve - > thanks to Jacek - our IDL-generated header-sources. So you are on a good way with WinRT, nice. What about Windows RT, was there already some ARM work? > A general note I would like to make about the use of sizeof(void*) in > widl to make out what type-library-variant to be choosen. That seems > to be a bit wacky variant, as it makes widl non-useable as cross-tool > on host with different pointer-size. isn't that controled by command line arguments?
Wine 1.6 list of deferred patches
This is the list of (hopefully) all deferred patches for wine 1.6, all authors are in bcc. I hope it's useful for developers. 97187 DeferredDmitry Timoshkov[3/3] kernel32: GetShortPathName for a non-existent short file name should fail. 97131 DeferredRosen Diankov [ole32] Bugfix for implicit MTA apartment initialization 97130 DeferredRosen Diankov [oleaut32] Bugfix patches for marshaling VT_UNKNOWN in SAFEARRAYS 97124 DeferredMaarten Lankhorst [RFC PATCH] loader: allow overriding pthread_create correctly on linux 97119 DeferredFabian Ebner[PATCH] dinput: Check the message queue in GetDeviceState * 97085 DeferredDmitry Timoshkovntdll: NtAllocateVirtualMemory should fail to commit if an address range is already committed for a memory mapped file. 96974 DeferredStefan Dösinger [PATCH 2/2] wined3d: Avoid calculating 1 / (fog_end - fog_start) in the shader 96961 DeferredMathis Beer ntdll: make msync() call asynchronous in NtFlushVirtualMemory (try 3.5, alternate version) 96925 DeferredHans Leidekker server: The token user SID must be present in the default DACL. 96899 DeferredStefan Dösinger [PATCH 1/5] wined3d: Consolidate d3d_info BOOLs into a flags field 96855 DeferredAlistair Leslie-Hughes oledb32: Add IErrorInfo Support OK 96854 DeferredAlistair Leslie-Hughes msdaps: Add support for ISourcesRowset (try 2) 96831 DeferredChristian Costa [PATCH] d3dxof: Remove LP stuff and rename variables for IDirectXFile methods. 96819 DeferredNikolay Sivov comctl32: Properly handle repainting for HDF_OWNERDRAW items 96797 DeferredAndré Hentschel ntdll: Add stub for LdrResolveDelayLoadedAPI and reference it in kernel32 (try 2) 96793 DeferredChristian Costa [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests. 96791 Deferredmorphiend msvcrt: add support for _chsize_s 96765 DeferredChristian Costa [PATCH 2/4] d3dxof: Handle float in binary mode and remove code that becomes useless. * this patch was already commited.
Re: Patches I maintain
Hello for this one, I have a patch in my tree. I will send it after my patches for the spherical harmonics. Nozomi >Hi Roland, > >I'm not exactly sure what your goal is... but there is a rule one patch per >mail only! There is likely no chance to get something like that mixture >committed. > >You may have a look here: >http://wiki.winehq.org/SubmittingPatches > > >On 18.07.2013 01:23, Roland Haeder wrote: > >+HRESULT D3DXCreatePolygon(LPDIRECT3DDEVICE9 device, float length, UINT > >sides, LPD3DXMESH *mesh, LPD3DXBUFFER adjacency) > >Well this looks a little bit wrong. You may have a look here >http://msdn.microsoft.com/en-us/library/windows/desktop/bb172785%28v=vs.85%29.aspx > . Don't copy and paste it. A patch which by accident works, is not something >which should be applied at all. There are several issues alone in that line. > >Cheers >Rico
Re: Patches I maintain
Hi Roland, I'm not exactly sure what your goal is... but there is a rule one patch per mail only! There is likely no chance to get something like that mixture committed. You may have a look here: http://wiki.winehq.org/SubmittingPatches On 18.07.2013 01:23, Roland Haeder wrote: +HRESULT D3DXCreatePolygon(LPDIRECT3DDEVICE9 device, float length, UINT sides, LPD3DXMESH *mesh, LPD3DXBUFFER adjacency) Well this looks a little bit wrong. You may have a look here http://msdn.microsoft.com/en-us/library/windows/desktop/bb172785%28v=vs.85%29.aspx . Don't copy and paste it. A patch which by accident works, is not something which should be applied at all. There are several issues alone in that line. Cheers Rico
Re: [wbemprox] Patches for adding currentclockspeed in record_processor
On Tue, 2013-07-02 at 20:34 +0900, Rosen Diankov wrote:
> you are right again, i'll be more careful. now, i've addressed every
> problem except creating the patches with git. any help would be
> appreciated.
See http://wiki.winehq.org/GitWine
> --- wine-1.6-rc4-old/dlls/wbemprox/builtin.c2013-06-29 04:53:55.0
> +0900
> +++ wine-1.6-rc4/dlls/wbemprox/builtin.c2013-07-02 19:30:39.157916619
> +0900
> @@ -168,6 +168,8 @@
> {'M','a','n','u','f','a','c','t','u','r','e','r',0};
> static const WCHAR prop_maxclockspeedW[] =
> {'M','a','x','C','l','o','c','k','S','p','e','e','d',0};
> +static const WCHAR prop_currentclockspeedW[] =
> +{'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0};
> static const WCHAR prop_memberW[] =
> {'M','e','m','b','e','r',0};
> static const WCHAR prop_methodW[] =
> @@ -381,6 +383,7 @@
> { prop_familyW, CIM_UINT16, VT_I4 },
> { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC },
> { prop_maxclockspeedW,CIM_UINT32, VT_I4 },
> +{ prop_currentclockspeedW,CIM_UINT32, VT_I4 },
> { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC },
> { prop_numcoresW, CIM_UINT32, VT_I4 },
> { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 },
> @@ -633,6 +636,7 @@
> UINT16 family;
> const WCHAR *manufacturer;
> UINT32 maxclockspeed;
> +UINT32 currentclockspeed;
> const WCHAR *name;
> UINT32 num_cores;
> UINT32 num_logical_processors;
> @@ -1690,20 +1694,30 @@
> regs_to_str( regs, 16, name + 32 );
> }
> }
Please keep properties sorted alphabetically.
> -static UINT get_processor_maxclockspeed( void )
> +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT*
> currentclockspeed )
> {
> PROCESSOR_POWER_INFORMATION *info;
> -UINT ret = 1000, size = get_processor_count() *
> sizeof(PROCESSOR_POWER_INFORMATION);
> +UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION);
> NTSTATUS status;
> -
> +UINT valueswritten=0;
> if ((info = heap_alloc( size )))
> {
> status = NtPowerInformation( ProcessorInformation, NULL, 0, info,
> size );
> -if (!status) ret = info[0].MaxMhz;
> +if (!status)
> +{
> +*maxclockspeed = info[0].MaxMhz;
> +*currentclockspeed = info[0].CurrentMhz;
> +valueswritten = 1;
> +}
> heap_free( info );
> }
> -return ret;
> +if( valueswritten == 0 )
> +{
> +*maxclockspeed = 1000;
> +*currentclockspeed = 1000;
> +}
> }
You don't need an extra variable, just return early.
Re: [wbemprox] Patches for adding currentclockspeed in record_processor
you are right again, i'll be more careful. now, i've addressed every
problem except creating the patches with git. any help would be
appreciated.
.
2013/7/2 Hans Leidekker :
> On Mon, 2013-07-01 at 18:08 +0900, Rosen Diankov wrote:
>> you are right, i'm attaching a new patch.
>
> You didn't address all comments.
>
>
--- wine-1.6-rc4-old/dlls/wbemprox/builtin.c2013-06-29 04:53:55.0
+0900
+++ wine-1.6-rc4/dlls/wbemprox/builtin.c2013-07-02 19:30:39.157916619
+0900
@@ -168,6 +168,8 @@
{'M','a','n','u','f','a','c','t','u','r','e','r',0};
static const WCHAR prop_maxclockspeedW[] =
{'M','a','x','C','l','o','c','k','S','p','e','e','d',0};
+static const WCHAR prop_currentclockspeedW[] =
+{'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0};
static const WCHAR prop_memberW[] =
{'M','e','m','b','e','r',0};
static const WCHAR prop_methodW[] =
@@ -381,6 +383,7 @@
{ prop_familyW, CIM_UINT16, VT_I4 },
{ prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC },
{ prop_maxclockspeedW,CIM_UINT32, VT_I4 },
+{ prop_currentclockspeedW,CIM_UINT32, VT_I4 },
{ prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC },
{ prop_numcoresW, CIM_UINT32, VT_I4 },
{ prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 },
@@ -633,6 +636,7 @@
UINT16 family;
const WCHAR *manufacturer;
UINT32 maxclockspeed;
+UINT32 currentclockspeed;
const WCHAR *name;
UINT32 num_cores;
UINT32 num_logical_processors;
@@ -1690,20 +1694,30 @@
regs_to_str( regs, 16, name + 32 );
}
}
-static UINT get_processor_maxclockspeed( void )
+static void get_processor_clockspeeds( UINT* maxclockspeed, UINT*
currentclockspeed )
{
PROCESSOR_POWER_INFORMATION *info;
-UINT ret = 1000, size = get_processor_count() *
sizeof(PROCESSOR_POWER_INFORMATION);
+UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION);
NTSTATUS status;
-
+UINT valueswritten=0;
if ((info = heap_alloc( size )))
{
status = NtPowerInformation( ProcessorInformation, NULL, 0, info, size
);
-if (!status) ret = info[0].MaxMhz;
+if (!status)
+{
+*maxclockspeed = info[0].MaxMhz;
+*currentclockspeed = info[0].CurrentMhz;
+valueswritten = 1;
+}
heap_free( info );
}
-return ret;
+if( valueswritten == 0 )
+{
+*maxclockspeed = 1000;
+*currentclockspeed = 1000;
+}
}
+
static const WCHAR *get_osarchitecture(void)
{
SYSTEM_INFO info;
@@ -1717,7 +1731,7 @@
static const WCHAR fmtW[] = {'C','P','U','%','u',0};
WCHAR device_id[14], processor_id[17], manufacturer[13], name[49] = {0};
struct record_processor *rec;
-UINT i, offset = 0, maxclockspeed, num_cores, num_logical_processors,
count = get_processor_count();
+UINT i, offset = 0, maxclockspeed = 0, currentclockspeed = 0, num_cores,
num_logical_processors, count = get_processor_count();
enum fill_status status = FILL_STATUS_UNFILTERED;
if (!resize_table( table, count, sizeof(*rec) )) return FILL_STATUS_FAILED;
@@ -1725,8 +1739,8 @@
get_processor_id( processor_id );
get_processor_manufacturer( manufacturer );
get_processor_name( name );
-
-maxclockspeed = get_processor_maxclockspeed();
+
+get_processor_clockspeeds(&maxclockspeed, ¤tclockspeed);
num_logical_processors = get_logical_processor_count( &num_cores ) / count;
num_cores /= count;
@@ -1740,6 +1754,7 @@
rec->family = 2; /* Unknown */
rec->manufacturer = heap_strdupW( manufacturer );
rec->maxclockspeed = maxclockspeed;
+rec->currentclockspeed = currentclockspeed;
rec->name = heap_strdupW( name );
rec->num_cores = num_cores;
rec->num_logical_processors = num_logical_processors;
Re: [wbemprox] Patches for adding currentclockspeed in record_processor
On Mon, 2013-07-01 at 18:08 +0900, Rosen Diankov wrote: > you are right, i'm attaching a new patch. You didn't address all comments.
Re: [wbemprox] Patches for adding currentclockspeed in record_processor
you are right, i'm attaching a new patch.
2013/7/1 Hans Leidekker :
> On Mon, 2013-07-01 at 08:56 +0900, Rosen Diankov wrote:
>
>> diff -ru wine-1.6-rc3-old/dlls/wbemprox/builtin.c
>> wine-1.6-rc3/dlls/wbemprox/builtin.c
>> --- wine-1.6-rc3-old/dlls/wbemprox/builtin.c2013-06-22
>> 03:24:01.0 +0900
>> +++ wine-1.6-rc3/dlls/wbemprox/builtin.c2013-06-27
>> 23:04:20.170154454 +0900
>
> Please use git to generate patches.
>
>> @@ -168,6 +168,8 @@
>> {'M','a','n','u','f','a','c','t','u','r','e','r',0};
>> static const WCHAR prop_maxclockspeedW[] =
>> {'M','a','x','C','l','o','c','k','S','p','e','e','d',0};
>> +static const WCHAR prop_currentclockspeedW[] =
>> +{'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0};
>
> Please keep properties sorted here and below.
>
>> static const WCHAR prop_memberW[] =
>> {'M','e','m','b','e','r',0};
>> static const WCHAR prop_methodW[] =
>> @@ -381,6 +383,7 @@
>> { prop_familyW, CIM_UINT16, VT_I4 },
>> { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC },
>> { prop_maxclockspeedW,CIM_UINT32, VT_I4 },
>> +{ prop_currentclockspeedW,CIM_UINT32, VT_I4 },
>> { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC },
>> { prop_numcoresW, CIM_UINT32, VT_I4 },
>> { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 },
>> @@ -633,6 +636,7 @@
>> UINT16 family;
>> const WCHAR *manufacturer;
>> UINT32 maxclockspeed;
>> +UINT32 currentclockspeed;
>> const WCHAR *name;
>> UINT32 num_cores;
>> UINT32 num_logical_processors;
>> @@ -1690,7 +1694,33 @@
>> regs_to_str( regs, 16, name + 32 );
>> }
>> }
>> -static UINT get_processor_maxclockspeed( void )
>> +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT*
>> currentclockspeed )
>> +{
>> +PROCESSOR_POWER_INFORMATION *info;
>> +UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION);
>> +NTSTATUS status;
>> +
>> +if ((info = heap_alloc( size )))
>> +{
>> +status = NtPowerInformation( ProcessorInformation, NULL, 0, info,
>> size );
>> +if (!status)
>> +{
>> +*maxclockspeed = info[0].MaxMhz;
>> +*currentclockspeed = info[0].CurrentMhz;
>> +}
>> +heap_free( info );
>> +}
>> +if( !!maxclockspeed )
>> +{
>> +*maxclockspeed = 1000;
>> +}
>> +if( !!currentclockspeed )
>> +{
>> +*currentclockspeed = 1000;
>> +}
>> +}
>
> You probably didn't mean to query the clock speeds and then overwrite them
> with static values.
> NULL checks are not needed in helpers like this.
>
>> +/*static UINT get_processor_maxclockspeed( void )
>> {
>> PROCESSOR_POWER_INFORMATION *info;
>> UINT ret = 1000, size = get_processor_count() *
>> sizeof(PROCESSOR_POWER_INFORMATION);
>> @@ -1703,7 +1733,8 @@
>> heap_free( info );
>> }
>> return ret;
>> -}
>> +}*/
>
> Don't comment out code. Remove it.
>
>> static const WCHAR *get_osarchitecture(void)
>> {
>> SYSTEM_INFO info;
>> @@ -1717,7 +1748,7 @@
>> static const WCHAR fmtW[] = {'C','P','U','%','u',0};
>> WCHAR device_id[14], processor_id[17], manufacturer[13], name[49] = {0};
>> struct record_processor *rec;
>> -UINT i, offset = 0, maxclockspeed, num_cores, num_logical_processors,
>> count = get_processor_count();
>> +UINT i, offset = 0, maxclockspeed = 0, currentclockspeed = 0,
>> num_cores, num_logical_processors, count = get_processor_count();
>> enum fill_status status = FILL_STATUS_UNFILTERED;
>>
>> if (!resize_table( table, count, sizeof(*rec) )) return
>> FILL_STATUS_FAILED;
>> @@ -1726,7 +1757,7 @@
>> get_processor_manufacturer( manufacturer );
>> get_processor_name( name );
>>
>> -maxclockspeed = get_processor_maxclockspeed();
>> +get_processor_clockspeeds(&maxclockspeed, ¤tclockspeed);
>> num_logical_processors = get_logical_processor_count( &num_cores ) /
>> count;
>> num_cores /= count;
>
> You're not using currentclockspeed.
>
>
wbemproxaddition2.wine-1.6-rc4.patch
Description: Binary data
Re: [wbemprox] Patches for adding currentclockspeed in record_processor
On Mon, 2013-07-01 at 08:56 +0900, Rosen Diankov wrote:
> diff -ru wine-1.6-rc3-old/dlls/wbemprox/builtin.c
> wine-1.6-rc3/dlls/wbemprox/builtin.c
> --- wine-1.6-rc3-old/dlls/wbemprox/builtin.c2013-06-22 03:24:01.0
> +0900
> +++ wine-1.6-rc3/dlls/wbemprox/builtin.c2013-06-27 23:04:20.170154454
> +0900
Please use git to generate patches.
> @@ -168,6 +168,8 @@
> {'M','a','n','u','f','a','c','t','u','r','e','r',0};
> static const WCHAR prop_maxclockspeedW[] =
> {'M','a','x','C','l','o','c','k','S','p','e','e','d',0};
> +static const WCHAR prop_currentclockspeedW[] =
> +{'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0};
Please keep properties sorted here and below.
> static const WCHAR prop_memberW[] =
> {'M','e','m','b','e','r',0};
> static const WCHAR prop_methodW[] =
> @@ -381,6 +383,7 @@
> { prop_familyW, CIM_UINT16, VT_I4 },
> { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC },
> { prop_maxclockspeedW,CIM_UINT32, VT_I4 },
> +{ prop_currentclockspeedW,CIM_UINT32, VT_I4 },
> { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC },
> { prop_numcoresW, CIM_UINT32, VT_I4 },
> { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 },
> @@ -633,6 +636,7 @@
> UINT16 family;
> const WCHAR *manufacturer;
> UINT32 maxclockspeed;
> +UINT32 currentclockspeed;
> const WCHAR *name;
> UINT32 num_cores;
> UINT32 num_logical_processors;
> @@ -1690,7 +1694,33 @@
> regs_to_str( regs, 16, name + 32 );
> }
> }
> -static UINT get_processor_maxclockspeed( void )
> +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT*
> currentclockspeed )
> +{
> +PROCESSOR_POWER_INFORMATION *info;
> +UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION);
> +NTSTATUS status;
> +
> +if ((info = heap_alloc( size )))
> +{
> +status = NtPowerInformation( ProcessorInformation, NULL, 0, info,
> size );
> +if (!status)
> +{
> +*maxclockspeed = info[0].MaxMhz;
> +*currentclockspeed = info[0].CurrentMhz;
> +}
> +heap_free( info );
> +}
> +if( !!maxclockspeed )
> +{
> +*maxclockspeed = 1000;
> +}
> +if( !!currentclockspeed )
> +{
> +*currentclockspeed = 1000;
> +}
> +}
You probably didn't mean to query the clock speeds and then overwrite them with
static values.
NULL checks are not needed in helpers like this.
> +/*static UINT get_processor_maxclockspeed( void )
> {
> PROCESSOR_POWER_INFORMATION *info;
> UINT ret = 1000, size = get_processor_count() *
> sizeof(PROCESSOR_POWER_INFORMATION);
> @@ -1703,7 +1733,8 @@
> heap_free( info );
> }
> return ret;
> -}
> +}*/
Don't comment out code. Remove it.
> static const WCHAR *get_osarchitecture(void)
> {
> SYSTEM_INFO info;
> @@ -1717,7 +1748,7 @@
> static const WCHAR fmtW[] = {'C','P','U','%','u',0};
> WCHAR device_id[14], processor_id[17], manufacturer[13], name[49] = {0};
> struct record_processor *rec;
> -UINT i, offset = 0, maxclockspeed, num_cores, num_logical_processors,
> count = get_processor_count();
> +UINT i, offset = 0, maxclockspeed = 0, currentclockspeed = 0, num_cores,
> num_logical_processors, count = get_processor_count();
> enum fill_status status = FILL_STATUS_UNFILTERED;
>
> if (!resize_table( table, count, sizeof(*rec) )) return
> FILL_STATUS_FAILED;
> @@ -1726,7 +1757,7 @@
> get_processor_manufacturer( manufacturer );
> get_processor_name( name );
>
> -maxclockspeed = get_processor_maxclockspeed();
> +get_processor_clockspeeds(&maxclockspeed, ¤tclockspeed);
> num_logical_processors = get_logical_processor_count( &num_cores ) /
> count;
> num_cores /= count;
You're not using currentclockspeed.
Patches 96314 & 96328
Hi, Is there any problem with these patches? http://source.winehq.org/patches/data/96314 http://source.winehq.org/patches/data/96328 Christian
Patches 96113 & 96114
Hi, Is there anything wrong with these patches? http://source.winehq.org/patches/data/96113 http://source.winehq.org/patches/data/96114 Christian
Re: wine-patches
On Thu, May 02, 2013 at 08:12:53AM +0200, Daniel Jeliński wrote: > Hello, > I sent a ~200KB patch to wine-patches last night and it disappeared without > a trace. I'm wondering if it got lost or just went to moderation. > Regards, > Daniel > > PS.I just resent it, still no luck. If you are subscribed, the list size trigger will probably have happened and it is waiting for moderation. What is in the 200KB patch? If its sourcecode, it is too large even without looking at it. :) Ciao, Marcus
wine-patches
Hello, I sent a ~200KB patch to wine-patches last night and it disappeared without a trace. I'm wondering if it got lost or just went to moderation. Regards, Daniel PS.I just resent it, still no luck.
kernel32/path: tests and patches
Any comments on my copyfileexW patches ?
Patches for winspool.drv and other locations
Hi Tatyana
Welcome to Wine.
Wine has a test suite to make sure, that new code is correct.
Example, what you never tested:
> -if(!pDeviceName) {
> +if(!pDeviceName && !*pDeviceName) {
Your code will crash, when pDeviceName is NULL.
I expect, you want to use a logical OR, but i did not test such a code change.
--
By by ... Detlef
Re: Mail problems for wine-patches
> I also unsubscribed and subscribed again to the wine-patches list. > > Any ideas? > > Has wine-patches a whitelist? We use an exim rule to screen out IP addresses flagged in the SORBS database. Unfortunately, the outbound mailer for your domain is listed; here is the exim error report: 212.227.17.11 is listed at dnsbl.sorbs.net (127.0.0.6: Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?212.227.17.11) I have temporarily added *.web.de to the whitelist which should, in theory, allow these emails through. I'll allow Jeremy Newman to comment on what he thinks would be a better long term solution. (It looks like it's touch and go, because you go this email through somehow :-/). Cheers, Jeremy
Re: Help Splitting Patches
Le 30/12/2012 22:52, Adam Martinson a écrit : Looking for some help splitting patch 3, not sure how I can cut it down any more without breaking stuff. I'm guessing patch 9 will need splitting too, same problem. I haven't checked whether it's really possible, but one way to go would be to: - create a dedicated structure like server_end for the server end-point (instead of directly reusing the existing pipe_end) - then patch by patch move elements from pipe_instance to server_end + options + fd + ... - finally, when server_end and pipe_end have the same fields, just drop server_end for pipe_end HTH A+
Help Splitting Patches
Looking for some help splitting patch 3, not sure how I can cut it down any more without breaking stuff. I'm guessing patch 9 will need splitting too, same problem. ~Adam patches.tar.gz Description: GNU Zip compressed data
Mail problems for wine-patches
I send several patches the last days with git and with the webmail interface from web.de, but nothing arrived at the wine-patches archive or the patches queue page. I also unsubscribed and subscribed again to the wine-patches list. Any ideas? Has wine-patches a whitelist? -- By by ... Detlef
cmd patches - please ignore them
Dont know what's happened, need to investigate further - Had 100% pass rate in job 23438 only to fail on submission... Needs some investigation so will work on it later in the week Jason
wine-patches mailinglist problem
Hi, The wine-patches mailing list seems to stopped working. As you can see at http://www.winehq.org/pipermail/wine-patches/ there's no December 2012, but i sent a patch hours ago. I'm not aware of a "mailing list memberships reminder" from that list. -- Best Regards, André Hentschel
Re: some patches to read files faster (especially for baldur's gate and infinity engine games)
On Mon, Jul 9, 2012 at 2:06 PM, Emmanuel Anne wrote: > Hello, I installed baldur's gate lately and noticed it was still slow in > wine, especially if I install a few mods. > See the description of the bug here : > http://bugs.winehq.org/show_bug.cgi?id=17956 > > So after reading the page about case insensitive filesystems there > http://wiki.winehq.org/CaseInsensitiveFilenames > I decided that one possible solution was to have everything in lower case. > So I made a 1st patch (see attachement). > After this, installing a weidu mod in baldur's gate becomes faster, but > loading a savegame is still very slow compared to windows. > > After some more investigation using strace, it's because the program uses > NtQueryDirectoryFile to check if a file is present in the override directory > instead of trying to open it directly, which produces a getdents call in > linux, which is extremely unefficient. So I just added a short cut for this > function : if the filename argument has no wildcard, then just use stat to > return wether the file exists or not. This is in the 2nd patch. > After this, loading savegames was extremely fast, comparable to windows > speed, finally, and there are no more slowdowns in game, it runs smoothly > all the time ! > > Well I am sure you'll find I didn't make them the right way, but I hope the > ideas will be useful to you and that you'll merge them in one form or > another into wine. > Oh yes, after applying them, all the new files created by wine will be in > lower case, but you'll eventually have to convert all the files to lower > case in the wine directories (it's required at least in the baldur's gate 2 > directory). > Also having a wineprefix with mixed lower and upper case characters would > create problems. > But except that, it works excessively well ! :) > So maybe you'll want this enabled only if the user explecitely chooses to > enable it. > For me I know I'll keep it ! > I attach the simple perl script I used to convert everything to lower case. It would be great to document this patch at http://wiki.winehq.org/InterestingPatches. -- -Austin
App bundle patches for OS X
Hi, I think I've reached a committable stage for the application bundle code I took over from Steven Edwards last summer. But there are some controversial parts so I figured I'd ask the list first. The patch extracts all XDG specific parts of winemenubuilder into a separate file, and there is also a new file for app bundles. Which one is used is controlled by a dispatch table and is choosable in the registry. The new code reacts to the same events but instead of a .desktop file an app bundle is created, start menu is replicated at ~/Applications/Wine/. Associations are handled by modifying start.exe to make it able to receive the file to open using AppleEvent, and an app bundle execing start.exe is put in ~/Library/Wine/Associations/. The actual file name contains the associated extension but the display name is modified to be the application that will be launched. It should work out of the box, after you've installed this patch and run winemenubuilder -a you should be able to right click a text file and choose "Open with notepad" (there's a cache involved as well so you might also need to remove the wine fileassociations key in the registry). Commits can be found at https://github.com/morth/wine/commits/appbundle-proper (original commits are on the master branch). The major controversity is in the start.exe code (commit < https://github.com/morth/wine/commit/ec68ac2b2abc0a1d4559eb5490b1f12b21000e59>). It uses a private API to access the AppleEvent containing the file to open. I choose this way because: 1. The only official way to access this information is by using Objective-C, building a proper Mac application. 2. Another option was to use the deprecated Carbon, but would also take a lot of code to finish. IMO neither of the two are good options, which leaves either doing it this way or to ask Apple to open up the API. Unfortunately I don't think Apple will respond quickly to such a request. Now that 10.8 is close (maybe even GMed) it's very unlikely to happen before 10.9, and perhaps not even then without backing from a major developer (I suppose the wine project might count as a such). I've made sure to check with configure if the functions exist before calling, but it is of course not safe in case they change the signature. OTOH, I don't think that is overly likely to happen. Another thing to note is that the app bundle script will copy some environment variables when created (commit https://github.com/morth/wine/commit/58773927eb7da431ba47923d66768cd129e4daffgenerate_bundle_script function). The ones copied are: PATH, DYLD_FALLBACK_LIBRARY_PATH and WINEPREFIX. DYLD_FALLBACK_LIBRARY_PATH is needed or wine won't work much at all. PATH is copied because the default one is only /bin and /usr/bin, and on OS X wine is rarely in one of those locations but rather installed with MacPorts of fink or similar, which use non-default paths. Anyway, if I don't hear anything from the list I'll likely send in the commits. I suppose that will be a second chance to review them. Once again I'd like to mention that Steven Edwards did a major part of this code, thanks goes to him and also to the wine project as a whole, I really enjoy using it. Finally, I only work on this code once every few months or so, so if it's deemed that there's too many problems, anyone should feel free to pick up this code and make it done (it'd be nice if you notified me though). Regards, -- Per Johansson
Re: League of Legends patches
On Tue, Jul 3, 2012 at 3:45 PM, Dan Kegel wrote: > On Tue, Jul 3, 2012 at 1:08 AM, Andrea Canciani wrote: >> I tried to follow the http://wiki.winehq.org/SubmittingPatches >> guidelines, but this is my first submission to wine, so I guess the >> patches might need further improvement. >> Please point out any issues that need fixing. > > On an administrivial note, you should send one patch per > email to wine-patches. Oops, sorry! Will do next time (which might be soon enough, given the regression in ieframe and the missing deadlock test) > > Do you think you could write a test that (semi-)reliably > causes the deadlock you're fixing? Yes, I guess it should be possible. Could you point me to a test which triggers a deadlock (in particular, how should the deadlock be handled?) I tried git-grep'ing for deadlock in the tests, but I only found checks for deadlock-named constants/values. > >> The patches have been tested by Dan Kegel (in CC) and are currently >> being used by many MacOSX and Linux users to run LoL. > > Our emails may have crossed - with these patches applied, > dlls/ieframe/tests/webbrowser.ok seems to crash here: > > Unhandled exception: privileged instruction in 32-bit code (0x02786624). > Backtrace: > =>0 0x02786624 (0x0032fcd8) > 1 0x688e22db func_webbrowser+0x3ca() [dlls/ieframe/tests/webbrowser.c:3382] > Yes, I sent the e-mail just before finding out about this issue. I will probably need to set up a proper wine development environment to find out more about it (I have a ubuntu 12.04 x86 vm, but even wine/master fails the testsuite on it). > Otherwise the tests seem to pass. > > Thanks, > Dan
Re: League of Legends patches
Dan Kegel wrote on Wed, 04 Jul 2012: (https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_blacklist.txt has a list of all the tests that the buildbot failed on while it was running The ones annotated with http://xquartz.macosforge.org/trac/ticket/512 should work with the latest XQuartz, as that bug has been fixed. Jonas
Re: League of Legends patches
On Wed, Jul 4, 2012 at 12:15 AM, Andrea Canciani wrote: >> Do you think you could write a test that (semi-)reliably >> causes the deadlock you're fixing? > > Yes, I guess it should be possible. > Could you point me to a test which triggers a deadlock (in particular, > how should the deadlock be handled?) http://bugs.winehq.org/show_bug.cgi?id=28362 says that the mshtml tests hang occasionally. The testsuite handles them by, well, hanging :-) Scripts that care about this add their own timeout. > Yes, I sent the e-mail just before finding out about this issue. > I will probably need to set up a proper wine development environment > to find out more about it (I have a ubuntu 12.04 x86 vm, but even > wine/master fails the testsuite on it). The testsuite does not, in general, fully pass on any machine but Alexandre's, so just generate a baseline by running the tests several times with "make -k test" without your patch, and saving the logs. Then repeat after applying your patch. (https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_blacklist.txt has a list of all the tests that the buildbot failed on while it was running, and you can run just the known good or known bad tests with https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests.sh but that's overkill (or underkill) for you, and slightly out of date anyway.) - Dan
Re: League of Legends patches
On Tue, Jul 3, 2012 at 1:08 AM, Andrea Canciani wrote: > I tried to follow the http://wiki.winehq.org/SubmittingPatches > guidelines, but this is my first submission to wine, so I guess the > patches might need further improvement. > Please point out any issues that need fixing. On an administrivial note, you should send one patch per email to wine-patches. Do you think you could write a test that (semi-)reliably causes the deadlock you're fixing? > The patches have been tested by Dan Kegel (in CC) and are currently > being used by many MacOSX and Linux users to run LoL. Our emails may have crossed - with these patches applied, dlls/ieframe/tests/webbrowser.ok seems to crash here: Unhandled exception: privileged instruction in 32-bit code (0x02786624). Backtrace: =>0 0x02786624 (0x0032fcd8) 1 0x688e22db func_webbrowser+0x3ca() [dlls/ieframe/tests/webbrowser.c:3382] Otherwise the tests seem to pass. Thanks, Dan
Re: Examples of AJ silently improving patches?
Hi, Here's another one where AJ implemented a suggestion I sent 3 days later: http://source.winehq.org/git/wine.git/commitdiff/5523820b810d16fd17da86fcf7930fd3f27acdf4 http://www.winehq.org/pipermail/wine-patches/2012-June/115180.html Am Mittwoch, 20. Juni 2012, 17:52:31 schrieb Daniel Lehman: > Another example: > http://www.winehq.org/pipermail/wine-patches/2012-January/110398.html > http://source.winehq.org/git/wine.git/commit/b1f04e23bf361e06d239e03693c904a > 597b9a32d > > I had added a redundant null check in both A and W paths. he simplified it > by making just the W path handle the null signature.asc Description: This is a digitally signed message part.
RE: Examples of AJ silently improving patches?
Another example: http://www.winehq.org/pipermail/wine-patches/2012-January/110398.html http://source.winehq.org/git/wine.git/commit/b1f04e23bf361e06d239e03693c904a597b9a32d I had added a redundant null check in both A and W paths. he simplified it by making just the W path handle the null
Re: Examples of AJ silently improving patches?
Here is an example: http://www.winehq.org/pipermail/wine-patches/2011-December/109805.html http://www.winehq.org/pipermail/wine-devel/2011-December/093517.html http://source.winehq.org/git/wine.git/commitdiff/6e5bba1b60f97fce34415ea30ebecd5bd20dae20 -Alex
Examples of AJ silently improving patches?
AJ sometimes kindly fixes problems in patches while committing them (I guess it's easier than rejecting the patch for small issues). I wonder if these silent improvements would be worth collecting as a sort of style-guide-by-example. Anyone remember any good examples? I've started a list at http://wiki.winehq.org/StyleExamples
Patches 85862 & 85862
What's wrong with these patches : - http://source.winehq.org/patches/data/85862 - http://source.winehq.org/patches/data/85862 There are marked as pending but can't see anything wrong. Maybe I'm missing something. Christian
Re: 'Pending' patches state
Marcus Meissner wrote: > Also Alexandre to some parts comments on bad patches these days. :) If by 'bad patches' you mean patches in the rejected state that's not the subject of this thread. -- Dmitry.
Re: 'Pending' patches state
On Tue, Apr 10, 2012 at 04:52:42PM +0900, Dmitry Timoshkov wrote: > Jeff Latimer wrote: > > > I agree a lot of developers would benefit from feedback, however that > > does not appear to be the Wine way of doing business. Maybe a halfway > > measure would be to automatically notify the developer that their patch > > has been marked as pending and then the developer can ask. > > Something like "Your patch is pending, you have to ask to get an answer why."? > But the answer known, and it is > * The patch is not obviously correct at first glance. Making a more > convincing argument, preferably in the form of a test case, may help. > * Waiting for feedback from the main developer in that area. > > And how is that better than current situation when in order to get > a feedback a developer have to ask? > > Q: What's wrong with my patch xxx? > A: The patch is not obviously correct at first glance... > Q: What can I do? > A: Making a more convincing argument, preferably in the form of a test case, > may help. > > ... or may not help. > > http://wiki.winehq.org/SubmittingPatches suggests > "If your patch disappears from http://source.winehq.org/patches/ without > being committed, improve it (perhaps by adding more tests) and resend." > > The patch disappears from the patch tracker in a month. You have plenty time > for 11 resends in an year, don't you? Also Alexandre to some parts comments on bad patches these days. :) Ciao, Marcus
Re: 'Pending' patches state
Jeff Latimer wrote: > I agree a lot of developers would benefit from feedback, however that > does not appear to be the Wine way of doing business. Maybe a halfway > measure would be to automatically notify the developer that their patch > has been marked as pending and then the developer can ask. Something like "Your patch is pending, you have to ask to get an answer why."? But the answer known, and it is * The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help. * Waiting for feedback from the main developer in that area. And how is that better than current situation when in order to get a feedback a developer have to ask? Q: What's wrong with my patch xxx? A: The patch is not obviously correct at first glance... Q: What can I do? A: Making a more convincing argument, preferably in the form of a test case, may help. ... or may not help. http://wiki.winehq.org/SubmittingPatches suggests "If your patch disappears from http://source.winehq.org/patches/ without being committed, improve it (perhaps by adding more tests) and resend." The patch disappears from the patch tracker in a month. You have plenty time for 11 resends in an year, don't you? -- Dmitry.
Re: 'Pending' patches state
On 09/04/12 16:50, Dmitry Timoshkov wrote: > It should be in the best ineterests of the project to provide as much > feedback as possible, and should improve not only amount of accepted > code (by encouraging developers provide more > comments/explanations/tests/etc. and more actively discuss possible > ways to fix a particular bug), but also code quality and help > developers better understand what could be improved in future > submissions. Silently marking a patch as 'pending' doesn't help with > that at all. Consider that if two my patches for SetParent would be > accepted one year ago but not one year later (without a single change > but just afer asking once again what's wrong with them), that > fundamental SetParent bug could be already fixed long time ago. I agree a lot of developers would benefit from feedback, however that does not appear to be the Wine way of doing business. Maybe a halfway measure would be to automatically notify the developer that their patch has been marked as pending and then the developer can ask.
Re: 'Pending' patches state
Jerome Leclanche wrote: > I think the general feeling is that Pending should be renamed to "Decision > pending" and that more feedback is needed at least in the form of "this is > the wrong approach" or "this may be the right approach, explain yourself > better". But the general feeling is that "Pending" currently means "Not > good enough" and never gets looked at again. I agree it's very confusing. It should be in the best ineterests of the project to provide as much feedback as possible, and should improve not only amount of accepted code (by encouraging developers provide more comments/explanations/tests/etc. and more actively discuss possible ways to fix a particular bug), but also code quality and help developers better understand what could be improved in future submissions. Silently marking a patch as 'pending' doesn't help with that at all. Consider that if two my patches for SetParent would be accepted one year ago but not one year later (without a single change but just afer asking once again what's wrong with them), that fundamental SetParent bug could be already fixed long time ago. -- Dmitry.
Re: 'Pending' patches state
Alexandre Julliard wrote: > > WM_SHOWWINDOW at the start and at the end of every message sequence > > means that ShowWindow() should be used to hide and show the window > > during SetParent call processing. > > That's the sort of explanation you should have included in your > patch, instead of expecting me to dig through the source or the list > archive to find it. Plus of course some explanation as to why the test > can't be marked as succeeding despite the change. Alexandre, do I need to provide more clarifications? -- Dmitry.
Re: 'Pending' patches state
On Wed, Mar 28, 2012 at 12:01 PM, Alexandre Julliard wrote: > Michael Stefaniuc writes: > > >> The pending state is feedback. It means that the patch is not clearly > > yes, but the worst possible feedback. > > > > New people assume you or the area maintainer need to still make up their > > mind on the patch but that's not the case, it is a done deal. > > Not necessarily. Patches are automatically marked pending as soon as I > look at them, until they get a more permanent resolution. There can be > many different reasons why they don't get one. > > > Iff one knows you and knows to read in between the lines then the above > > can be reworded as: > > "Current implementation rejected; idea might have some merit." > > > > That's what "Pending" means most of the times. > > Sometimes, yes. > > > Now for the other meanings of "Pending": > > - "Waiting for feedback from the main developer in that area." > > Don't remember to have ever seen that. Those patches stay normally in > > "New" as you don't look at them before the area developer ACKs. > > No, I usually do look at them. Sometimes I go back and mark them as New > again, but not always. > > > - "preferably in the form of a test case" > > That should be "Needs tests". > > It would be, in cases where tests are clearly the right way. There are > cases where it's not clear whether a test is feasible, and using "Needs > tests" may lead the submitter down the wrong path. > > > - With the two (minor) other meanings of "Pending" handled by other > > patch states we can rename "Pending" to "Convince me" or "Needs work". > > That would make it more obvious what is meant. > > I can certainly rename "pending" to "convince me" if it helps, but I > think it's important to have some sort of open-ended resolution to leave > room for developer's judgement. There are many cases where I'm genuinely > undecided about the right resolution, and I feel it's preferable to show > the undecision and leave it to the developer to try to address one way > or the other, even if that's of course harder than being told exactly > what to do. > > -- > Alexandre Julliard > julli...@winehq.org > I think the general feeling is that Pending should be renamed to "Decision pending" and that more feedback is needed at least in the form of "this is the wrong approach" or "this may be the right approach, explain yourself better". But the general feeling is that "Pending" currently means "Not good enough" and never gets looked at again. I agree it's very confusing. J. Leclanche
Re: 'Pending' patches state
Michael Stefaniuc writes: >> The pending state is feedback. It means that the patch is not clearly > yes, but the worst possible feedback. > > New people assume you or the area maintainer need to still make up their > mind on the patch but that's not the case, it is a done deal. Not necessarily. Patches are automatically marked pending as soon as I look at them, until they get a more permanent resolution. There can be many different reasons why they don't get one. > Iff one knows you and knows to read in between the lines then the above > can be reworded as: > "Current implementation rejected; idea might have some merit." > > That's what "Pending" means most of the times. Sometimes, yes. > Now for the other meanings of "Pending": > - "Waiting for feedback from the main developer in that area." > Don't remember to have ever seen that. Those patches stay normally in > "New" as you don't look at them before the area developer ACKs. No, I usually do look at them. Sometimes I go back and mark them as New again, but not always. > - "preferably in the form of a test case" > That should be "Needs tests". It would be, in cases where tests are clearly the right way. There are cases where it's not clear whether a test is feasible, and using "Needs tests" may lead the submitter down the wrong path. > - With the two (minor) other meanings of "Pending" handled by other > patch states we can rename "Pending" to "Convince me" or "Needs work". > That would make it more obvious what is meant. I can certainly rename "pending" to "convince me" if it helps, but I think it's important to have some sort of open-ended resolution to leave room for developer's judgement. There are many cases where I'm genuinely undecided about the right resolution, and I feel it's preferable to show the undecision and leave it to the developer to try to address one way or the other, even if that's of course harder than being told exactly what to do. -- Alexandre Julliard julli...@winehq.org
Re: 'Pending' patches state
Alexandre Julliard wrote: > > WM_SHOWWINDOW at the start and at the end of every message sequence > > means that ShowWindow() should be used to hide and show the window > > during SetParent call processing. > > That's the sort of explanation you should have included in your > patch, instead of expecting me to dig through the source or the list > archive to find it. Plus of course some explanation as to why the test > can't be marked as succeeding despite the change. There are other things inside of SetParent that break message sequences, that's why the patches were prepended with a comment explaining what's wrong with Setparent and saying that it's the first step. > > Taking an opportunity to discuss other my patches :) I'd like to get > > a comment to 84685 as well. > > Try making it simpler. Thanks. -- Dmitry.
Re: 'Pending' patches state
Alexandre, On 03/28/2012 10:17 AM, Alexandre Julliard wrote: > Dmitry Timoshkov writes: > >> It's very confusing, and absolutely not clear what is required from the >> patch submitter, especially since *there is no any feedback on the patch*. >> 'Rejected' at least requies some sort of feedback, while 'Pending' doesn't. >> To me 'Pending' looks like a silent case of 'Reject', but without any >> obligation to explain why. >> >> I find myself on somewhat shaky ground when I see a bunch of my patches >> in the pending state, especially if they already contain the tests and >> main developer in the area I'm changing is Alexandre :). >> >> Is it possible to get at least some feedback for pending patches? Pretty >> please? > > The pending state is feedback. It means that the patch is not clearly yes, but the worst possible feedback. New people assume you or the area maintainer need to still make up their mind on the patch but that's not the case, it is a done deal. > correct, but that it's complicated to articulate exactly why. Like it > says, you should try to make it more convincing, either by simplifying > the patch, or writing a test case. Iff one knows you and knows to read in between the lines then the above can be reworded as: "Current implementation rejected; idea might have some merit." That's what "Pending" means most of the times. Now for the other meanings of "Pending": - "Waiting for feedback from the main developer in that area." Don't remember to have ever seen that. Those patches stay normally in "New" as you don't look at them before the area developer ACKs. - "preferably in the form of a test case" That should be "Needs tests". - With the two (minor) other meanings of "Pending" handled by other patch states we can rename "Pending" to "Convince me" or "Needs work". That would make it more obvious what is meant. > For instance your patch 84692 says that "tests confirm that", but you > don't say which tests, and there are no new tests or fixed todos in the > patch, so it looks suspicious. Yes, I could dig out the tests myself and > investigate it in detail, but when it gets to that point I usually just > move on to the next patch, hence "pending". IMHO that should have been "Needs tests"; that would have forced Dmitry to point you to the tests. bye michael
Re: 'Pending' patches state
Dmitry Timoshkov writes: > I'm sorry, but that's not a feedback, and casual contributors may even > not be aware of that patch tracking page. And as I mentioned if the patch > already contains the tests it's not really obvious what should be added > in addition. In the light of recent discussions about friendliness to > users in bugzilla, I think that developers deserve at least small fraction > of friendliness as well (Alexandre, you are nice and friendly all the time, > but at least I sometimes feel like sending the patches to a blackwhole). If you want to write a script that sends a nice friendly mail every time a patch changes status I'd be happy to use it. > There is not much tests for SetParent, and 84692 suggests to look at > the tests added by > http://www.winehq.org/pipermail/wine-patches/2011-February/098711.html > > WM_SHOWWINDOW at the start and at the end of every message sequence > means that ShowWindow() should be used to hide and show the window > during SetParent call processing. That's the sort of explanation you should have included in your patch, instead of expecting me to dig through the source or the list archive to find it. Plus of course some explanation as to why the test can't be marked as succeeding despite the change. > Taking an opportunity to discuss other my patches :) I'd like to get > a comment to 84685 as well. Try making it simpler. -- Alexandre Julliard julli...@winehq.org
Re: 'Pending' patches state
Alexandre Julliard wrote: > The pending state is feedback. It means that the patch is not clearly > correct, but that it's complicated to articulate exactly why. Like it > says, you should try to make it more convincing, either by simplifying > the patch, or writing a test case. I'm sorry, but that's not a feedback, and casual contributors may even not be aware of that patch tracking page. And as I mentioned if the patch already contains the tests it's not really obvious what should be added in addition. In the light of recent discussions about friendliness to users in bugzilla, I think that developers deserve at least small fraction of friendliness as well (Alexandre, you are nice and friendly all the time, but at least I sometimes feel like sending the patches to a blackwhole). > For instance your patch 84692 says that "tests confirm that", but you > don't say which tests, and there are no new tests or fixed todos in the > patch, so it looks suspicious. Yes, I could dig out the tests myself and > investigate it in detail, but when it gets to that point I usually just > move on to the next patch, hence "pending". There is not much tests for SetParent, and 84692 suggests to look at the tests added by http://www.winehq.org/pipermail/wine-patches/2011-February/098711.html WM_SHOWWINDOW at the start and at the end of every message sequence means that ShowWindow() should be used to hide and show the window during SetParent call processing. But even the same patch sent another day after the tests http://www.winehq.org/pipermail/wine-patches/2011-February/098748.html didn't get any feedback and died in the pending state. Taking an opportunity to discuss other my patches :) I'd like to get a comment to 84685 as well. Thanks. -- Dmitry.
Re: 'Pending' patches state
Dmitry Timoshkov writes: > It's very confusing, and absolutely not clear what is required from the > patch submitter, especially since *there is no any feedback on the patch*. > 'Rejected' at least requies some sort of feedback, while 'Pending' doesn't. > To me 'Pending' looks like a silent case of 'Reject', but without any > obligation to explain why. > > I find myself on somewhat shaky ground when I see a bunch of my patches > in the pending state, especially if they already contain the tests and > main developer in the area I'm changing is Alexandre :). > > Is it possible to get at least some feedback for pending patches? Pretty > please? The pending state is feedback. It means that the patch is not clearly correct, but that it's complicated to articulate exactly why. Like it says, you should try to make it more convincing, either by simplifying the patch, or writing a test case. For instance your patch 84692 says that "tests confirm that", but you don't say which tests, and there are no new tests or fixed todos in the patch, so it looks suspicious. Yes, I could dig out the tests myself and investigate it in detail, but when it gets to that point I usually just move on to the next patch, hence "pending". -- Alexandre Julliard julli...@winehq.org
'Pending' patches state
Hello, http://source.winehq.org/patches has the following legend for the Pending patch status: Pending * The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help. * Waiting for feedback from the main developer in that area. It's very confusing, and absolutely not clear what is required from the patch submitter, especially since *there is no any feedback on the patch*. 'Rejected' at least requies some sort of feedback, while 'Pending' doesn't. To me 'Pending' looks like a silent case of 'Reject', but without any obligation to explain why. I find myself on somewhat shaky ground when I see a bunch of my patches in the pending state, especially if they already contain the tests and main developer in the area I'm changing is Alexandre :). Is it possible to get at least some feedback for pending patches? Pretty please? -- Dmitry.
Re: po: Spanish translation update (this patch supersedes previous patches fixing fuzzies)
On Wed, Mar 14, 2012 at 22:57, Eduardo García wrote: > This patch fixes fuzzies and remove obsolete comments. > > With regards. > > Eduardo You may also remove the "#| msgid ..." lines: these only indicate the former msgid, so you can see the difference quickly. Also, add "(try N)" suffix when you submit a new version of a patch (that's a bit more concise than your "this patch... fuzzies") Frédéric
Re: Regarding my dinput patches
On 01/17/2012 11:19 AM, Lucas Zawacki wrote:
I want to get my dinput patches in before the code freeze, and besides
the ones that I tried to commit last week I have some patches touching
EnumDevicesBySemantics and ConfigureDevices, but I can't commit them
before the DIPROP_USERNAME and configuration file patches are in too.
Even thou we are not officially "frozen" I doubt AJ will accept anything
that significantly alters functionality. Unless you trying to fix some big
number of programs that don't work of course. Do you have bug # that talks
about program(s) not working?
Seeing that I'll have to change a lot of things in the patches to get
them in I want to ask some questions:
* Is %APPDATA%\DirectInput\User Maps a better place to store the
configuration files?
Much better place IMHO.
* Should I use the registry to persist the usernames in the dinput
devices instead of relying on the filename and filetimes like windows
seems to do? Where in the registry does this information belong?
Not sure what you mean here.
Just assume that Wine is being run by one user and one user only. Especially
that you storing files under a particular user's profile directory. And
since Wine doesn't allow multiple users to use the same wineprefix, it makes
sense to assume that all configuration will be generated by one user.
* Any suggestions on how to format all these W strings? I could use
just strcatW, but since I have to convert integers to strings I think
I'll have to look at sprintf variation...
Few things I can think of:
- Store all string constants as "static const WCHAR fooW[] = {'f','o','o',0}".
- Just make your heap_printfW() work with provided buffer and size (both
passed by ref). And enlarge that buffer if needed. So the next call will use
the new bigger buffer. This is not speed critical so should be fine with
heap buffer. Unless of course someone else have some objections.
* I'll drop the _ in front the functions from now on. Should I send
patches to remove it in the other functions that already use it?
Yes please, but it can wait.
Vitaliy.
Regarding my dinput patches
I want to get my dinput patches in before the code freeze, and besides the ones that I tried to commit last week I have some patches touching EnumDevicesBySemantics and ConfigureDevices, but I can't commit them before the DIPROP_USERNAME and configuration file patches are in too. Seeing that I'll have to change a lot of things in the patches to get them in I want to ask some questions: * Is %APPDATA%\DirectInput\User Maps a better place to store the configuration files? * Should I use the registry to persist the usernames in the dinput devices instead of relying on the filename and filetimes like windows seems to do? Where in the registry does this information belong? * Any suggestions on how to format all these W strings? I could use just strcatW, but since I have to convert integers to strings I think I'll have to look at sprintf variation... * I'll drop the _ in front the functions from now on. Should I send patches to remove it in the other functions that already use it?
Palettized ddraw surface patches
Hi, I'll start sending my patches for blitting palettized surfaces with opengl. There are quite a few patches and I won't send them all in one, so this mail shows where I am headed. Palettized surfaces are in a bad shape right now, both in terms of code quality and functionality. My patches will not fix all issues because this would require a shadow frontbuffer in wined3d, and Henri and I agreed that this should wait until after Wine 1.4. However, my patches fix a number of issues and eliminate a lot of dead code and hacks. Other work that needs to be done, but is separate from those patches: *) Emulate color keying in the ARBfp fragment pipeline. That way the upload- time color keying conversion can be limited to situations where shaders are not available and the alpha = 0.0 hack in patch 20 removed. *) Finish the blit infrastructure cleanup. Mainly, get rid of the hardcoded arbfp_blit backend in wined3d_surface_blt, get rid of arbfp_blit_surface and the remains of IWineD3DSurfaceImpl_BltOverride. *) Investigate if there's any point in P8 blitting with ATIfs and nvrc. The fixed function pipeline replacements would profit from proper 3D color keying, but that only works if we have blitters that can blit without color keying during texture upload. *) Make overlays work properly again. The overlay tests work, but the d3d7 sdk samples refuse to run for some reason. With the GL ddraw renderer as default we can also look into games like Settlers 3 that use overlays to draw the mouse pointer. @Henri and Matteo: The difference between this patchset and the one I sent you a few days ago is that my old patchset made onscreen surfaces as a whole a special case, while this one only has special handling for blits to onscreen surfaces. The new way needs less infrastructure changes, works better with palette changes and is a lot closer to how things should work with a shadow frontbuffer in wined3d. Stefan p8.tar.bz2 Description: application/bzip-compressed-tar signature.asc Description: This is a digitally signed message part.
Re: Old imagehlp patches
On 19 September 2011 03:37, Juan Lang wrote: > weren't good enough in 2004-5, they're not any better now. You'd want > someone who has an active interest in this area to have a go at them, > I believe, unless you can convince the original author to take them up > again. AFAIK we're still not accepting ReactOS code.
Re: Old imagehlp patches
On 19 September 2011 02:37, Juan Lang wrote: > I wouldn't > hold your breath expecting these patches to go in as-is: if they > weren't good enough in 2004-5, they're not any better now. You'd want > someone who has an active interest in this area to have a go at them, > I believe, unless you can convince the original author to take them up > again. > Thanks, Juan. I had a feeling that would be the case. I'll leave them be. Best wishes, Thomas
Re: Old imagehlp patches
Hi Thomas, wrong mailing list. You wanted wine-devel instead (now cc'ed.) > I don't know about wine development, but are these patches still likely to > work? What would need to happen for them to be merged in? To your first question, try them and see! To your second question, a lot. They're much too large to be merged at a single go, they lack tests, and they should be sent by their original author. I wouldn't hold your breath expecting these patches to go in as-is: if they weren't good enough in 2004-5, they're not any better now. You'd want someone who has an active interest in this area to have a go at them, I believe, unless you can convince the original author to take them up again. --Juan
Re: About cmd patches
On Fri, Aug 19, 2011 at 2:15 AM, Nowres Rafid wrote: >> That means that your patch series >> [1/2] cmd: fixing an error with redirection operators >> [2/2] cmd/tests: fixing an error with redirection operators (updating >> test results) >> >> is incorrect, since tests marked todo_wine will fail after the first >> patch. > > i queued these patch in my email client, but when I sent them they were sent > in bad order. It doesn't matter what order they were sent in, I think. There's no way that applying one of those patches would yield working tests. If you want to do a two patch series, you can, but every patch in the series has to pass tests on its own. That may mean sending new tests first with extra todo's, then removing the todo's in the second patch which fixes them. In this case, you weren't adding any new tests, so there's no first test patch in the series; you really should just send a single merged patch. - Dan
Re: About cmd patches
On 19/08/2011 03:14, Dan Kegel wrote: Hi Nowres, it's awesome that you're digging into cmd like this! The rule with Wine is that Each patch you submit shall pass tests. That means that your patch series [1/2] cmd: fixing an error with redirection operators [2/2] cmd/tests: fixing an error with redirection operators (updating test results) is incorrect, since tests marked todo_wine will fail after the first patch. Better to send things like that as a single merged patch in the future. Thanks, Dan Ok Dan, i queued these patch in my email client, but when I sent them they were sent in bad order. Nowres,
Re: [PATCH 2/8] ntdll: rework the handling of server ioctls a little bit to avoid a crash with later patches
Bernhard Loos writes:
> On Thu, Jul 28, 2011 at 7:46 PM, Alexandre Julliard
> wrote:
>> Bernhard Loos writes:
>>
>>> @@ -1273,10 +1282,16 @@ static NTSTATUS server_ioctl_file( HANDLE handle,
>>> HANDLE event,
>>>
>>> if (wait_handle)
>>> {
>>> - NtWaitForSingleObject( wait_handle, (options &
>>> FILE_SYNCHRONOUS_IO_ALERT), NULL );
>>> - status = io->u.Status;
>>> + status = NtWaitForSingleObject( wait_handle, (options &
>>> FILE_SYNCHRONOUS_IO_ALERT), NULL );
>>> + if (status == STATUS_USER_APC)
>>> + {
>>> + async->interrupted = TRUE;
>>> + status = STATUS_CANCELLED; /* not really, the ioctl completes
>>> and event and the handle
>>> + itself get signaled */
>>> + }
>>
>> This looks wrong. You can't claim it was cancelled if it's still
>> running.
>>
>> --
>> Alexandre Julliard
>> julli...@winehq.org
>>
>
> I'm not really sure, what to do at this point. I can't exactly return
> ERROR_SUCCESS because the operation is not completed yet. At best, I
> can reenter the wait, but this will break in places, where the caller
> depends on DeviceIoControl returning in case of a scheduled user apc.
If the operation is supposed to be cancelled, then it should be
cancelled properly. This probably needs to be done server-side.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 2/8] ntdll: rework the handling of server ioctls a little bit to avoid a crash with later patches
On Thu, Jul 28, 2011 at 7:46 PM, Alexandre Julliard wrote:
> Bernhard Loos writes:
>
>> @@ -1273,10 +1282,16 @@ static NTSTATUS server_ioctl_file( HANDLE handle,
>> HANDLE event,
>>
>> if (wait_handle)
>> {
>> - NtWaitForSingleObject( wait_handle, (options &
>> FILE_SYNCHRONOUS_IO_ALERT), NULL );
>> - status = io->u.Status;
>> + status = NtWaitForSingleObject( wait_handle, (options &
>> FILE_SYNCHRONOUS_IO_ALERT), NULL );
>> + if (status == STATUS_USER_APC)
>> + {
>> + async->interrupted = TRUE;
>> + status = STATUS_CANCELLED; /* not really, the ioctl completes
>> and event and the handle
>> + itself get signaled */
>> + }
>
> This looks wrong. You can't claim it was cancelled if it's still
> running.
>
> --
> Alexandre Julliard
> julli...@winehq.org
>
I'm not really sure, what to do at this point. I can't exactly return
ERROR_SUCCESS because the operation is not completed yet. At best, I
can reenter the wait, but this will break in places, where the caller
depends on DeviceIoControl returning in case of a scheduled user apc.
Bernhard Loos
Re: [PATCH 2/8] ntdll: rework the handling of server ioctls a little bit to avoid a crash with later patches
Bernhard Loos writes:
> @@ -1273,10 +1282,16 @@ static NTSTATUS server_ioctl_file( HANDLE handle,
> HANDLE event,
>
> if (wait_handle)
> {
> -NtWaitForSingleObject( wait_handle, (options &
> FILE_SYNCHRONOUS_IO_ALERT), NULL );
> -status = io->u.Status;
> +status = NtWaitForSingleObject( wait_handle, (options &
> FILE_SYNCHRONOUS_IO_ALERT), NULL );
> +if (status == STATUS_USER_APC)
> +{
> +async->interrupted = TRUE;
> +status = STATUS_CANCELLED; /* not really, the ioctl completes
> and event and the handle
> + itself get signaled */
> +}
This looks wrong. You can't claim it was cancelled if it's still
running.
--
Alexandre Julliard
julli...@winehq.org
Re: wined3d performance patches
On Tuesday 14 June 2011 16:15:35 Henri Verbeet wrote: > Yes, but I think that by now GF7 GPUs are marginal enough that it's > not worth keeping the code around for. The Steam HW survey for example > reports over 90% D3D10+ cards. Even if it does regress something, I > think it makes more sense to tell people to either file a bug with > NVIDIA for that or help improve the nouveau driver for that card. Fair enough. Note that Matteo found a similar bug with GL_TEXTURE_BASE_LEVEL on newer cards, but I encouraged him to report it to Nvidia rather than adding a hack to this function. > I'm not so sure. E.g. the docs for the INTZ format say you can have an > INTZ texture bound as both depth buffer and texture as long as depth > writes are disabled. (This makes some sense, since in that case there > aren't any read/write conflicts.) Yeah, although Aras Pranckevičius d3d hacks page claims that it doesn't work well(slow). Still, there are corner cases where the sampler states of a current render target may be changed on the d3d side and applied to the GL texture. > I'm not sure that can actually happen. wined3d_surface_set_format() > insists the format must be WINED3DFMT_UNKNOWN, so it can't be part of > a working FBO entry before the format is changed. That probably also > means clearing the allocation flags there is a bit silly. Hmm, I think I should reinvestigate those ddraw apps that call SetSurfaceDesc with strange parameters. Unfortunately I haven't documented which apps do that. I remember Windows Media Player 9 which sets the lpSurface field and expects subsequent Lock() calls to return this pointer :-O > > It shouldn't be. RTs must be in the default pool, which can't be > > unloaded. > > Even in ddraw? We need more tests for the DDSCAPS* mess, but the Direct3D7 docs say DDSCAPS2_TEXTUREMANAGE is incompatible with DDSCAPS_VIDEOMEMORY. I believe that DDSCAPS_3DDEVICE mandates DDSCAPS_VIDEOMEMORY, but atm I can't find the proper place in the docs to back this up. The d3d7 docs also say that TEXTUREMANAGE surfaces can be blitted to, and suggests that this is done in software and the result is then uploaded to the video memory copy. signature.asc Description: This is a digitally signed message part.
Re: wined3d performance patches
On 14 June 2011 15:26, Stefan Dösinger wrote:
>> As far as I'm concerned you can just submit this. I was going to do
>> this myself, looks like you got there first.
> Still didn't get around to test this on geforce 7 GPUs. It's possible that the
> bug this was supposed to fix is still around.
>
Yes, but I think that by now GF7 GPUs are marginal enough that it's
not worth keeping the code around for. The Steam HW survey for example
reports over 90% D3D10+ cards. Even if it does regress something, I
think it makes more sense to tell people to either file a bug with
NVIDIA for that or help improve the nouveau driver for that card.
> Besides, it is probably not necessary for the other patches. The consideration
> was that we'd have to verify the filter each draw, but I don't think setting a
> texture as sampler and render target simultaneously is allowed in d3d.
>
I'm not so sure. E.g. the docs for the INTZ format say you can have an
INTZ texture bound as both depth buffer and texture as long as depth
writes are disabled. (This makes some sense, since in that case there
aren't any read/write conflicts.)
>> > @@ -1913,6 +1928,10 @@ void surface_set_texture_name(struct
>> > ...
>> > + if (surface_is_framebuffer(surface))
>> > + {
>> > + IWineD3DDeviceImpl_MarkStateDirty(surface->resource.device,
>> > STATE_FRAMEBUFFER); + }
>> > ...
>> What are these for?
> The texture name one is not needed, I've removed that from the patch already.
> The allocate_surface check is needed in case a ddraw app changes the
> pixelformat via SetSurfaceDesc.
>
I'm not sure that can actually happen. wined3d_surface_set_format()
insists the format must be WINED3DFMT_UNKNOWN, so it can't be part of
a working FBO entry before the format is changed. That probably also
means clearing the allocation flags there is a bit silly.
>> You may also have to handle an active RT getting unloaded, though I'm
>> not entirely sure if that's allowed or not.
> It shouldn't be. RTs must be in the default pool, which can't be unloaded.
Even in ddraw?
>> I wonder if
>> the speedup is mostly for load_location(), modify_location() or both
>> though? Maybe we can improve those functions themselves.
> It's caused by both, I think it's plain call overhead. I'll double check that
> though. It may also be hyper-sensitivity of the draw overhead test. 260->270
> fps isn't a lot when you consider that native gets ~1100 fps. But right now I
> have to take what I can get.
>
Maybe surface_load_location() could do an initial location check a bit
earlier. (And some of the code before the current check could also be
removed when we get rid of texture == drawable.) For
surface_modify_location(), the overlay code probably doesn't belong in
there, we could do a similar early check if the flags already match,
and maybe we should split it in two functions.
Re: wined3d performance patches
Hi,
Thanks for the comments, I've some replies inlined below. The bigger concern I
have is that the patches don't improvement by a lot yet, about 1% on AMD GPUs
and 1.5% to 2.5% on Nvidia GPUs(in real apps, my benchmarks are a different
issue). Because of that my plan is to do more testing and experiment with
things like separating the vdecl-streamsrc-vshader states et cetera and see
how much impact this has.
All in all I am not yet convinced that my approach with lots of very targeted
tests is the way to salvation, and I want to wait a bit before I start
screwing up the code. Unfortunately it is still the best way I have.
I'm sending in some of the patches that make sense even without performance
improvements. The MINFILTER stuff is a case like that, but I want to test it
on pre-dx10 GPUs first.
On Tuesday 14 June 2011 14:20:12 Henri Verbeet wrote:
> I only looked over about half of this, doesn't look too crazy. You do
> have trailing spaces in a couple of places though. Here are some
Ya, I spotted them myself a while later, and didn't look for style issues
before sending them to wine-devel. Though maybe I should look for better tools
to watch out for slopiness like this.
> As far as I'm concerned you can just submit this. I was going to do
> this myself, looks like you got there first.
Still didn't get around to test this on geforce 7 GPUs. It's possible that the
bug this was supposed to fix is still around.
Besides, it is probably not necessary for the other patches. The consideration
was that we'd have to verify the filter each draw, but I don't think setting a
texture as sampler and render target simultaneously is allowed in d3d.
> > @@ -1913,6 +1928,10 @@ void surface_set_texture_name(struct
> > ...
> > +if (surface_is_framebuffer(surface))
> > +{
> > +IWineD3DDeviceImpl_MarkStateDirty(surface->resource.device,
> > STATE_FRAMEBUFFER); +}
> > ...
> What are these for?
The texture name one is not needed, I've removed that from the patch already.
The allocate_surface check is needed in case a ddraw app changes the
pixelformat via SetSurfaceDesc.
> You may also have to handle an active RT getting unloaded, though I'm
> not entirely sure if that's allowed or not.
It shouldn't be. RTs must be in the default pool, which can't be unloaded. Of
course that doesn't stop our broken location management from screwing up, but
that would be a separate issue.
> > Subject: [PATCH 09/14] wined3d: Make render target dirtification in draws
> > cheaper
> I've been thinking about getting rid of the texture == drawable stuff
> for FBOs, and instead just making texture <-> drawable loads a nop in
> load_location(). At the very least this would allow the check to
> always be against SFLAG_INDRAWABLE instead of
> surface->rt_location_flags, which IMHO looks more sane.
Yes, this sounds much better.
> I wonder if
> the speedup is mostly for load_location(), modify_location() or both
> though? Maybe we can improve those functions themselves.
It's caused by both, I think it's plain call overhead. I'll double check that
though. It may also be hyper-sensitivity of the draw overhead test. 260->270
fps isn't a lot when you consider that native gets ~1100 fps. But right now I
have to take what I can get.
signature.asc
Description: This is a digitally signed message part.
Re: wined3d performance patches
I only looked over about half of this, doesn't look too crazy. You do
have trailing spaces in a couple of places though. Here are some
comments:
> Subject: [PATCH 04/14] wined3d: Don't set FBO attachment filtering to
> GL_NEAREST
As far as I'm concerned you can just submit this. I was going to do
this myself, looks like you got there first.
> Subject: [PATCH 05/14] wined3d: Move FBO application into a state handler
This needs an update to debug_d3dstate() as well.
> +static BOOL surface_is_framebuffer(struct wined3d_surface *surface)
> +{
> +struct wined3d_device *device = surface->resource.device;
> +unsigned int i;
> +const struct wined3d_gl_info *gl_info = &device->adapter->gl_info;
> +
> +if (surface == device->fb.depth_stencil) return TRUE;
> +if (!device->fb.render_targets) return FALSE;
> +for (i = 0; i < gl_info->limits.buffers; i++)
> +{
> +if (surface == device->fb.render_targets[i]) return TRUE;
> +}
> +return FALSE;
> +}
I don't know how much this actually hurts, but we could introduce
something along the lines of "SFLAG_ACTIVE_RT" to keep track of this.
We may have to worry about surfaces being bound to more than one RT
attachment point, in which case we'd need a count instead of a flag
though.
> @@ -1913,6 +1928,10 @@ void surface_set_texture_name(struct wined3d_surface
> *surface, GLuint new_name,
> ·
> *name = new_name;
> surface_force_reload(surface);
> +if (surface_is_framebuffer(surface))
> +{
> +IWineD3DDeviceImpl_MarkStateDirty(surface->resource.device,
> STATE_FRAMEBUFFER);
> +}
> }
> ·
> void surface_set_texture_target(struct wined3d_surface *surface, GLenum
> target)
> @@ -2317,6 +2336,10 @@ static void surface_allocate_surface(struct
> wined3d_surface *surface, const stru
> checkGLcall("glPixelStorei(GL_UNPACK_CLIENT_STORAGE_APPLE,
> GL_TRUE)");
> }
> LEAVE_GL();
> +if (surface_is_framebuffer(surface))
> +{
> +IWineD3DDeviceImpl_MarkStateDirty(surface->resource.device,
> STATE_FRAMEBUFFER);
> +}
> }
What are these for?
You may also have to handle an active RT getting unloaded, though I'm
not entirely sure if that's allowed or not.
> +BOOL all_samplers_mapped = TRUE;
...
> +all_samplers_mapped = FALSE;
This looks unused.
> +for(i = 0; i < swapchain->presentParms.BackBufferCount; i++)
Style.
> Subject: [PATCH 09/14] wined3d: Make render target dirtification in draws
> cheaper
I'm not sure about this one. My first impression is that it looks
fragile. The rt_location_flags setup makes assumptions about
load_location() internals, which will likely change at some point. In
particular, now that most of the location management goes through the
appropriate functions instead of messing with the flags themselves,
I've been thinking about getting rid of the texture == drawable stuff
for FBOs, and instead just making texture <-> drawable loads a nop in
load_location(). At the very least this would allow the check to
always be against SFLAG_INDRAWABLE instead of
surface->rt_location_flags, which IMHO looks more sane. I wonder if
the speedup is mostly for load_location(), modify_location() or both
though? Maybe we can improve those functions themselves.
Re: wined3d performance patches
2011/6/6 Stefan Dösinger : ... > Furthermore, Matteo says that not calling context_apply_draw_buffers every > time framebuffer() is run is a noticeable performance improvement too. Matteo, > did you test this with just patch 0005, or both 0005 and 0006? > Actually that was with your FBO dirty patches from your previous wined3d performance wine-devel email, so it should more or less match what happens with your current 0005 + 0006 patches (I didn't recheck with the newer ones though). I got a small but measurable (1 - 1.5%) overall improvement in d3d9 performances, so it looked to me like it is something worth optimizing.
wined3d performance patches
Hi, This is intended mostly for the other d3d developers, but since we have quite a number of them now so individual CCs are a lot of work :-) I attached the patches I currently have in my tree to give an update on what I've been working on recently. The main aim of those patches is to reduce draw overhead a bit, thus improving game performance. The patches need some cleanup, but for that I first need a patch Matteo is working on. Feedback is welcome. I'm also interested in test results, e.g. if the changes break a game, or the performance impact. If those patches cause a 5% performance increase I am happy. Patches 1-3: Mostly unrelated. I haven't sent them yet because patch 3 breaks Unigine Heaven, and patches 1 and 2 make little sense without 3. Patch 4: This removes a hack for a driver bug workaround. I have to do more testing on my old machines to find out if the bug is really fixed in newer nvidia drivers. Patches 5, 6: They keep track of changes to the framebuffer setup so we don't have to run through the code that figures out which FBO to bind every draw. Patch 5 gets rid of the ordering assumption. Patch 6 applies the FBO only when needed. They aren't ready yet. In patch 6 the FBO may have to be reapplied when the pixelshader changes. To implement that I need some draw buffer tracking infrastructure Matteo is working on. Also clears can be integrated. fbo- clear.diff is a half-baked attempt to do this. I dropped it when I realized I was duplicating Matteos work. After that I have to double-check that I took care of all situations where the FBO may have to be updated. Furthermore, Matteo says that not calling context_apply_draw_buffers every time framebuffer() is run is a noticeable performance improvement too. Matteo, did you test this with just patch 0005, or both 0005 and 0006? Patch 0007: Sampler map optimization, it has a lengthy description in the patch file Patch 0008: A tiny fix, it results in a pretty small improvement on OSX. On Linux+Nvidia it is not noticeable. Patch 0009: At first I tried to skip the render target dirtification entirely via a flag in the d3ddevice, but it was pretty tricky and ugly. Just making it cheaper gets us ~2/3rd of the way too. (Draw overhead tester performance without this: 259 fps. Complete disabling of the dirtification calls via a hack: 275. With this patch: 269) 0010: An unrelated cleanup Patches 11, 12: Preparation for including clears in the fbo dirtification patches. See fbo-clear.diff. More work on performance is obviously required, for example *) Separate vertex declaration, vertex shader and pixel shader states *) Speed up sampler preloading. This will be easier once we have a tree-like state structure. *) Write more tests for other common operations, like clears, blits, shader changes, texture changes, vertex buffer changes, dynamic resource loading *) Test our shader's GPU-side execution performance *) See if we can do something about locking *) Isolate bottlenecks in the GPU drivers and get them fixed. patches.tar.bz2 Description: application/bzip-compressed-tar signature.asc Description: This is a digitally signed message part.
Style updates for source.winehq/patches
Attached patch to tools.git/patches/patches.css adds the necessary
styling for a WineHQ-style patch status page:
http://i.imgur.com/5ToSc.png
The div class="main" needs to be replaced by the html attached in the
other file. I can write a patch for it if it's to be included, but I
cannot test it. Is it worth doing?
J. Leclanche
http://winehq.org/images/winehq_logo_glass_sm.png"; alt="">
http://winehq.org/images/winehq_logo_text.png"; alt="WineHQ"
title="WineHQ">
http://www.winehq.org/";>WineHQ
http://wiki.winehq.org/";>Wiki
http://appdb.winehq.org/";>AppDB
http://bugs.winehq.org/";>Bugzilla
http://forums.winehq.org/";>Forums
Wine source repository – Patch status
(main table)
Legend
(legend table)
diff --git a/patches/patches.css b/patches/patches.css
index 6e0e206..b94aee6 100644
--- a/patches/patches.css
+++ b/patches/patches.css
@@ -1,29 +1,121 @@
/* WineHQ-ish look */
+
body {
-background-color: #E2E2E2;
-color: black;
+background-color: #00;
+color: #00;
+background-image: url("http://winehq.org/images/bg.jpg";);
+background-repeat: no-repeat;
font-family: "bitstream vera sans", "verdana", "arial", "helvetica", sans-serif;
-margin: 10px;
-font-size: small;
+margin: 0;
+font-size: 10pt;
}
a:link{ text-decoration: none; }
a:visited { text-decoration: none; }
a:hover { text-decoration: underline; }
-div.main, div.legend {
-margin: 10px 0 0 0;
+/* wine logo image */
+#logo_glass_big {
+position: absolute;
+z-index: 2;
+top: 0px;
+left: 0px;
+width: 200px;
+height: 313px;
+}
+
+#logo_glass {
+position: absolute;
+z-index: 2;
+top: 20px;
+left: 50px;
+width: 100px;
+height: 157px;
+}
+
+#logo_text {
+position: absolute;
+z-index: 3;
+top: 40px;
+left: 110px;
+width: 186px;
+height: 58px;
+}
+
+#logo_blurb {
+position: absolute;
+z-index: 4;
+top: 92px;
+left: 130px;
+font-size: 12px;
+color: #99;
+}
+
+#tabs {
+position: absolute;
+z-index: 6;
+top: 0px;
+right: 10px;
+margin: 0px;
+padding: 0px;
+}
+
+#tabs ul {
+list-style: none;
+padding: 0;
+margin: 0;
+}
+
+#tabs li{
+float: left;
+width: 112px;
+height: 28px;
+margin: 0px 2px 0px 2px;
+padding: 0;
+text-align: center;
+background-image: url("http://winehq.org/images/tab_u.png";);
+background-repeat: no-repeat;
+}
+
+#tabs li.s {
+background-image: url("http://winehq.org/images/tab_s.png";);
+}
+
+#tabs li.s a {
+font-weight: bold;
+}
+
+#tabs li:hover {
+background-image: url("http://winehq.org/images/tab_h.png";);
+}
+
+#tabs a {
+display: block;
+width: 108px;
+height: 23px;
+padding-top: 3px;
+font-size: 16px; color: white; text-decoration: none;
+}
+
+#main_content {
+padding: 85px 10px 10px 100px;
+}
+#content {
background-color: white;
-width: 100%;
-border: 1px solid #601919;
+border-radius: 7px;
+padding: 20px 20px 10px 80px;
}
+
h1, h2 {
text-align: center;
-background-color: #601919;
-color: #ff;
-padding: 4px;
-margin: 0;
+}
+
+table {
+border: 1px solid black;
+}
+table.main {
+margin-top: 30px;
}
table th {
@@ -34,9 +126,10 @@ table th {
margin: 0;
}
-table.main, table.legend { width: 100%; }
+table { width: 100%; }
+
+#legend ul { margin: 2px 0; }
-table.legend ul { margin: 2px 0; }
tr.even { background-color: #fff8f8; }
tr.odd { background-color: #f8e8e8; }
Sorry about the duplicate patches.
When trying to submit my first patch I did not do it correctly, and on http://source.winehq.org/patches/ it shows up 5 times. The correct patch is http://www.winehq.org/pipermail/wine-patches/2011-April/100677.html Thanks for your patience. Joel Teichroeb
Patches to fix GetDIBits for top down destination bitmaps
Please ignore the patches http://source.winehq.org/patches/data/71716 and http://source.winehq.org/patches/data/71711. I was having trouble with my mail client and accidentally sent the same code 3 times.
Re: the patches around ok()
Am 04.02.2011 20:00, schrieb Joris Huizer: > Hello Henri Verbeet, and André Hentschel > > I wasn't (actively) on the mailing list, that's why I couldn't reply directly > to your messages. > I will try and make sure I have better titles for such patches in future! > > Regards, > Joris > Great, but you should also resend them this time. I guess something like that would be ok: "imagehlp/tests/integrity.c: Don't test function directly when reporting GetLastError() (resend)" -- Best Regards, André Hentschel
the patches around ok()
Hello Henri Verbeet, and André Hentschel I wasn't (actively) on the mailing list, that's why I couldn't reply directly to your messages. I will try and make sure I have better titles for such patches in future! Regards, Joris
Re: wine-patches
Hi Vincent,
> I sent this email on wine-patch but... nothing.
>
> Am I doing something wrong ?
Sorry, I should have replied earlier. The patch doesn't appear to fix
anything, so it's unclear where you're going with it. It'd be better
to send a more complete patch series.
For example,
+static BOOL PCSCLite_loadfunctions(void)
+{
+FIXME("%s\n", SONAME_LIBPCSCLITE);
+return TRUE;
+}
this just adds spam to the console. Also, why do you return BOOL,
when the return value is never checked?
More nitpicking:
+static void *g_pcscliteHandle = NULL;
The initialization is unnecessary, statics are implicitly initialized to 0.
+if (g_pcscliteHandle)
+{
+wine_dlclose(g_pcscliteHandle, NULL, 0);
+g_pcscliteHandle = NULL;
The assignment of NULL is unneeded, the process is being unloaded.
+if (g_pcscliteHandle)
+return TRUE;/* already loaded */
+else
This check is unneeded, the function is only called at process load,
i.e. only once.
--Juan
wine-patches
Hi,
I sent this email on wine-patch but... nothing.
Am I doing something wrong ?
Am I blacklisted ?
Vincent
--- Begin Message ---
>From bdf47b42a1560e9e097770f54d8f36a234f6d686 Mon Sep 17 00:00:00 2001
From: Vincent Hardy
Date: Mon, 24 Jan 2011 10:33:36 +0100
Subject: Loading PCSC-lite library
---
configure.ac |3 +++
dlls/winscard/winscard.c | 42 ++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4d049b6..c6a1714 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1638,6 +1638,9 @@ fi
dnl Check for libodbc
WINE_CHECK_SONAME(odbc,SQLConnect,,[AC_DEFINE_UNQUOTED(SONAME_LIBODBC,["libodbc.$LIBEXT"])])
+dnl Check for libpcsclite
+WINE_CHECK_SONAME(pcsclite,SCardEstablishContext,,[AC_DEFINE_UNQUOTED(SONAME_LIBPCSCLITE,["libpcsclite.$LIBEXT"])])
+
dnl Check for any sound system
if test "x$ALSALIBS$COREAUDIO$NASLIBS$ESDLIBS$ac_cv_lib_soname_jack" = "x" -a \
"$ac_cv_header_sys_soundcard_h" != "yes" -a \
diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c
index 412299c..f2e4454 100644
--- a/dlls/winscard/winscard.c
+++ b/dlls/winscard/winscard.c
@@ -17,16 +17,22 @@
*/
#include "config.h"
+#include "wine/port.h"
#include
#include "windef.h"
#include "winbase.h"
#include "wine/debug.h"
+#include "wine/library.h"
#include "winscard.h"
#include "winternl.h"
+static BOOL PCSCLite_loadlib(void);
+static BOOL PCSCLite_loadfunctions(void);
+
WINE_DEFAULT_DEBUG_CHANNEL(winscard);
static HMODULE WINSCARD_hModule;
+static void *g_pcscliteHandle = NULL;
static HANDLE g_startedEvent = NULL;
const SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 };
@@ -44,6 +50,10 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
DisableThreadLibraryCalls(hinstDLL);
WINSCARD_hModule = hinstDLL;
+
+if (PCSCLite_loadlib())
+PCSCLite_loadfunctions();
+
/* FIXME: for now, we act as if the pcsc daemon is always started */
g_startedEvent = CreateEventA(NULL,TRUE,TRUE,NULL);
break;
@@ -51,6 +61,13 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
case DLL_PROCESS_DETACH:
{
CloseHandle(g_startedEvent);
+
+if (g_pcscliteHandle)
+{
+wine_dlclose(g_pcscliteHandle, NULL, 0);
+g_pcscliteHandle = NULL;
+}
+
break;
}
}
@@ -58,6 +75,31 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
return TRUE;
}
+static BOOL PCSCLite_loadlib(void)
+{
+char error[256];
+
+if (g_pcscliteHandle)
+return TRUE;/* already loaded */
+else
+{
+g_pcscliteHandle = wine_dlopen(SONAME_LIBPCSCLITE, RTLD_LAZY | RTLD_GLOBAL, error, sizeof(error));
+if (g_pcscliteHandle)
+return TRUE;
+else
+{
+WARN("Failed to open library %s : %s\n", debugstr_a(SONAME_LIBPCSCLITE), error);
+return FALSE;
+}
+}
+}
+
+static BOOL PCSCLite_loadfunctions(void)
+{
+FIXME("%s\n", SONAME_LIBPCSCLITE);
+return TRUE;
+}
+
HANDLE WINAPI SCardAccessStartedEvent(void)
{
return g_startedEvent;
--
1.7.3.4
--- End Message ---
RE: TestBot messing up patches
> From: Andrew Nguyen > On 01/11/2011 05:32 AM, Marvin wrote: > > === WINEBUILD (build) === > > Patch failed to apply > > Patch failed to apply > > Again, the bot seems to screw up patch application for some reason. > Greg, could you take a look at the situation? Should be fixed now. Greg.
TestBot messing up patches
> From: Andrew Nguyen > On 01/11/2011 05:32 AM, Marvin wrote: > > === WINEBUILD (build) === > > Patch failed to apply > > Patch failed to apply > > Again, the bot seems to screw up patch application for some reason. > Greg, could you take a look at the situation? Yeah, sorry about that. It appears that under some circumstances the bot schedules two jobs to run on the same VM at the same time (if you look at the WINEBUILD steps in job 8232 and 8233 you'll note that both of them start at the same time). Having two jobs apply their patch simultaneously kind of messes things up. I expect to have a fix for this tomorrow. Greg.
Translation patches for wine-1.2.2
Hello Alexandre, attached is the list of translation patches for wine-1.2.2. This time I manually checked the changes to the En.rc files if they are indeed a wine-1.2 incompatible change. Thus there are some patches in the list that I missed for wine-1.2.1 with the automatic "stop at first En.rc file change". Some other things to note: - There are 4 of my janitorial patches in; you can skip them like the last time and fix up the patches that don't cherry-pick cleanly. - "winhlp32: Use a standard About dialog, with the proper icon" seemed inconspicuous enough to include and thus allow translation patches for winhlp32 after that commit. - Does it make sense to include the Arab and Hebrew translations? Support for mirroring is only in wine-1.3.x. bye michael 6301f6553427e478672a799a905be3fd367f31cc winmm: Move from a per resource to a global LANGUAGE setting. cd8e1f8e7597cc398c2367d5e82b698643796268 notepad: Move from a per resource to a global LANGUAGE setting. 94e3e8b8b8a31bd9de2d3643f48043a2f762dc02 notepad: Remove the ignored common resource attributes. ed7d82f19482a46e7c6729635e5f3118c2e46ad1 taskmgr: Remove the ignored common resource attributes. e8994599dcebb948d5c219bf7dda13546e70a0dc cryptui: Fix typos in English resources. 2ebe732453a6477dd8e5fcc209b297c7e2cf5b67 winmm: Fix typo in English, Slovak resources. c625e95af15222a002fb69b8051b02e7e7196d71 winmm: Update Korean resource. 59296b7f0c4006edd2c41b181ea6ec03250402ce mpr: Fix translations. 8ecf937c10cd6de49a6df046fdad9e48f56103e4 winmm: Add Swedish translation. 1848ae8d3ad34c4aeb2fa9f6aa794216e9e7e3fc shlwapi: Fix translations. 4069da56249dc546861d8a7a20dfbeafa4188d58 shlwapi: Update Korean resource. 5e87eacb1426f2510b150842de032f11d609eb30 cryptui: Update Italian translation. b1beec24d908ad640839f420e969ccd85cfe62a7 cryptui: Update Italian translation. 4985b464a8caeaf5bf9e7605f3cba19b8a01b76f shlwapi: Update Italian translation. 842c5693cf8ab56d0b57eaa5d08fdf8726b5ce42 shlwapi: Update Finnish translation. 672b2ff59f863daab9297fa033acd134de7c3aa0 winmm: Update Italian translation. 3c77b1b976e0faa681db275b3708105dfd6e6e18 mpr: Update Italian translation. a3fcddc55981c35c00f2d74e3d666d195db52318 crypt32: Fix German translation. 4a69fa34e9e6d85d08af0785348d010c31f80f88 cryptui: Fix German translation. ef88584afa83187603bb81f5100c98be274ed6d1 xcopy: Fix translations. 140f08bd420676b7a9abf5846855cf6ace4078df kernel32: Update Korean resource. 5c8ed1493641627712ad62e5372cf4626b2e992d winhlp32: Add Hebrew translation. 3f27cedabf659f8c6f33b29bcf09dd85e24c34a9 appwiz.cpl: Added Hebrew translation. d298ec1944a08998126cdd3fe23096bee01ea06b comctl32: Added Hebrew translation. 93324dadddf9f9d100c781894a8343037b406f09 browseui: Added Hebrew translation. 2f7f135f291cf08f9bedc7385288fefee11b8b86 regedit: Hebrew translation fix. b66e6d5cc437921c57bdac79694b5e2e58cffbfa notepad: Add WS_EX_LAYOUTRTL to some RTL resources. 17d8c5fbee26d403a0e8e81f97ae020aebbe010e wininet: Added Hebrew translation. 5019592070a8aa61c9f730d01d67f99c2aee6647 credui: Added Hebrew translation. 510d2bf6826b3f6ee6a405f9221e0807b140b8e7 taskmgr: Added Hebrew translation. bbceba94458bd5c6111f0ba2e5f2871535d34491 uninstaller: Added Hebrew translation. 338b7edcedd043f2d2629ee948448ebeec039210 winhlp32: Hebrew translation fixed. b1dbd845470302879e2fd9168c6b9889fba77f89 setupapi: Added Hebrew translation. feb0e0820d7f411382c568ac21f65fbf1919c0dc winspool: Added Hebrew translation. b15c015a2ee5e39f2df28e0c5fc024250dc5f16b localui: Added Hebrew translation. 6cbb8fc200e925420ff5673ca8df860b486fc40c regedit: Updated Hebrew translation. 73805ced316919a4bf24a611b7a4fdcad8e0eb63 kernel32: heb.nls: Made some corrections. 2c4b2b792af625d7f357d09ce4f88c9d6f3f2757 mapi32: Added Hebrew translation. 0d4c5c87761975cdb6b310f07179429625167947 taskmgr: Remove a useless commented line. 89845fc9e80d2d06693b781bb975bc992c14e66b cryptdlg: Add Swedish translation. d80db876113217ea9ce7201688b02f58fdcedd99 uninstaller: Remove unneeded carriage return in resource string. b3b64fdf5eafd5aea62b470e2467e0ad11578a0c cryptui: Add Japanese translation. 4d5a851ca88b6b15b33a1813740be7969956d40b crypt32: Add Japanese translation. 5d69141014d698497a5427a6ce16ebbed09bc852 winhlp32: Use a standard About dialog, with the proper icon. fe8a5ac44d744288589d14203ee4f80cafb12daa crypt32: Updated Norwegian translation. 6bf2875c6ed28bea03fbc27a88ec7851e2f2ab1f cryptdlg: Updated Norwegian translation. 293fc4cd28afa49e2445b0ffaafb930af83e2205 user32: Updated Norwegian translation. a211cef818ba8061b7545222d39ac1cbe544288d wineboot: Updated Norwegian translation. 399e955a7e9cee9063054af8a822b210a2de1013 wineps.drv: Updated Norwegian translation. 6cb9f6ff2bca114fd282e46583f7fa5b76680cf5 msi: Updated Norwegian translation. 6f5502bed1123bd9cad2e9e5595609c1e27b9d58 wineconsole: Updated Norwegian translation. fa485ccd12f94dc880bbb5e0652472e03cfa7f40 oledlg: Upda
Re: Translation patches for wine-1.2.1
On 10/06/2010 10:29 PM, Sven Baars wrote: Michael Stefaniuc wrote: Hello Alexandre, attached is the list with the translation patches to cherry-pick for wine-1.2.1. The list was generated with the attached crud patch (modified from the version I used for 1.0.1) and then I have manually removed all my janitorial patches that didn't produce conflicts. Though the removal of the unneeded "Remove the ignored common resource attributes" patches makes "wrc --verify-translation" produce DIFF lines for resources that were added at a later time as those don't have the ignored common resource attributes. bye michael This script doesn't check for updated mc files, so the kernel32 translation patches didn't get in. This includes for example 7fe8c7202345ba04425e3dfefb534bcad8fe76fa which was the first commit after wine 1.2 and is a translation update. Just thought you might want to know this. I know, I already pulled the list of mc file changes. Was busy with work and had no time to test and submit that list. bye michael
Re: Translation patches for wine-1.2.1
Michael Stefaniuc wrote: Hello Alexandre, attached is the list with the translation patches to cherry-pick for wine-1.2.1. The list was generated with the attached crud patch (modified from the version I used for 1.0.1) and then I have manually removed all my janitorial patches that didn't produce conflicts. Though the removal of the unneeded "Remove the ignored common resource attributes" patches makes "wrc --verify-translation" produce DIFF lines for resources that were added at a later time as those don't have the ignored common resource attributes. bye michael This script doesn't check for updated mc files, so the kernel32 translation patches didn't get in. This includes for example 7fe8c7202345ba04425e3dfefb534bcad8fe76fa which was the first commit after wine 1.2 and is a translation update. Just thought you might want to know this. Sven
Translation patches for wine-1.2.1
Hello Alexandre, attached is the list with the translation patches to cherry-pick for wine-1.2.1. The list was generated with the attached crud patch (modified from the version I used for 1.0.1) and then I have manually removed all my janitorial patches that didn't produce conflicts. Though the removal of the unneeded "Remove the ignored common resource attributes" patches makes "wrc --verify-translation" produce DIFF lines for resources that were added at a later time as those don't have the ignored common resource attributes. bye michael 04678d955d56bda8f9f05a47d6179df51329a1bf comctl32: Add the Serbian (Latin) translation. 4662e12164a1e1e66bcabef96441c8799f15bd4f msi: Add the Serbian (Latin) translation. cb07a59a805b6d55636fce02da0a6b0d8ed360e8 user32: Fix the Dutch translation. 15f36468de04c66703b9808fa079386b842b95fc appwiz.cpl: Add Ukrainian translation. 23c627af26d6d8dd377ec2df241f0e6981d8a14a winecfg: Add Ukrainian translation. 32e6007010a8bf7ef201a3530676148b72eb0a63 regedit: Add Ukrainian translation. 86603e52eb67ab8a8c1d6d1f39f6e71fe231c5e9 oleview: Add Ukrainian translation. 91d6f4951158873ce2b6cc02eeb7f0b58a3f shell32: Update Ukrainian translation. c22e1299ecdbb42788631ff36d9d70f444b525dc taskmgr: Add Ukrainian translation. efe7fbd20b49109963695158db24b2aea0d9fafb notepad: Add Ukrainian translation. dbdedefe71908d7a8618301f0bb0f8f7f607f637 cmd: Remove stray ';' from the resource files. 117a436bbf562f37ddf7293ce857864f148a820a winecfg: Improve German view. 35b65ca550c04c51c640afc50e1fb35b8dc97091 cryptui: Add Ukrainian translation. f2135efe4823dd5a035526fcc5e400b6046d04a1 msi: Add the Serbian (Cyrillic) translation. 1fbb96f89a337f8f79dbc67748ba8f9e61929c75 winedbg: Add Ukrainian translation. 638aa31476c5a3a61c916a5a553290aaf2861dd5 net: Add Ukrainian translation. 86c5fef097d94ad11b37787311ce6d024d72477c progman: Add Ukrainian translation. e736284b466b305846d7961cbe2a24fcce4bb46b wineboot: Add Ukrainian translation. bd16a7225d3bdbb71099e6ee7431156597143721 comctl32: Add the Serbian (Cyrillic) translation. 5de86f4db2c918b6c754358840b3068b5b79dd64 appwiz.cpl: Add the Serbian (Latin) translation. 2d5a6231c0bfe401f159e5ee743861392b93 browseui: Add Ukrainian translation. 516e8a3b601070e67d77f986af6baf8a3837677c notepad: Ukrainian translation fix. 5440dfb8dc5a0042842189d8dbcd0b2ccb9a6922 gphoto2.ds: Add Ukrainian translation. a57e06aac8c2ac725fe8b5281257fab9ca40d473 jscript: Add Ukrainian translation. ffe0ac817cb42fdc7d39c2d135e5620c7c9d71ac progman: Ukrainian translation fix. 04af975d91cd3905168fe84b705da1615cf44f4a sane.ds: Add Ukrainian translation. 2c35fccf4d06cc43cc161a5424df5a2ae83b139d winspool.drv: Add Ukrainian translation. 6e8c900d1960e804227e83826a529f075e09443e winhlp32: Move from a per resource to a global LANGUAGE setting. 0a3f093fe4ab2407fa68a224afd85bb33f9fb496 wineconsole: Add Ukrainian translation. 36b595e69cd08bd90edfed22ec743b204f29435a comctl32: Use the Cyrillic 'O' in the Serbian translation. d3a5242c971df897aea0d5462a15558f79a50e56 appwiz.cpl: Add the Serbian (Cyrillic) translation. 53db2df4b1513ad0882d9a846a21157dbca2c7f3 winecfg: Italian translation update. cf96f89ef0a1e680b01cbc26acb3c423e7641343 winedbg: Italian translation update. fb4bb588808ff82fb7d348af0d1b13d75eb1aced xcopy: Italian translation update. 03a4c6445794f339ba37a9f1bdecb42fb82cf428 comdlg32: Add the Serbian (Latin) translation. 545322999dac2fd050370db7948f9e2d61593824 comdlg32: Remove the ignored common resource attributes. 276f8eaf5986468d4fa01dab589bbf7768596672 wininet: Remove the ignored common resource attributes. 5fbf1b23bfe9c41289d633b5cf9b4a0e6bd1ee6e winecfg: Remove the ignored common resource attributes. 767fecf1d9174ed3e6c448e9d939ca2b6032198c shell32: Remove the ignored common resource attributes. 93d04bd400f8248a7403f97e75bd80c95dd1f66e setupapi: Remove the ignored common resource attributes. 566ac55eee4dc240e5f8624831b4e6e35d8bfec6 uninstaller: Remove the ignored common resource attributes. 70ef03208fa6f9ebad9be66731655ef3e7e135b8 cmdlgtst: Add Ukrainian translation. ce405b7125e427d136101e78b2691333e7709425 shell32: Add the Serbian (Latin) translation. 664e3e3f4ad98d8eac90dc9f8be66da8e0d3af71 user32: Add the Serbian (Latin) translation. 8411535875049c82861bf2ccb9c428066575 winhlp32: Add the Serbian (Latin) translation. f784998bfab11725121602a25bf0e31886d69588 start: Add Ukrainian translation. 1ed27712c153f0b1fb98e9f27e6f11da723238f4 shell32: Add the Serbian (Cyrillic) translation. 5d6baf644d191c1e80049a477ff0114ebf41c31c cmd: Add Ukrainian translation. 653a64e60b1844ca947d2656f3264a7ce8bd9568 shell32: Fix the Serbian (Latin) translation. 4b48480340391ba7102b7538bb559bc86fe5d4a4 winecfg: Add the Serbian (Latin) translation. c2d722e3ee96457de12e46440625bcf21a0da468 user32: Add the Serbian (Cyrillic) translation. 0379acc27d23d485bcd6715b00398124479fe0b9 start: Update Korean resource. aa252
[tools PATCH] patches: Mention Windows test failures as a cause for 'Test failure' status
The current 'Test failure' description implies (to me, at least) that
it's only Wine failures that cause the status. It might be obvious, but
it seems worth explicitly mentioning that Windows failures can cause it
as well.
---
On 10/01/2010 09:45 AM, Alexandre Julliard wrote:
On 09/24/2010 02:59 PM, Andrew Eikum wrote:
These tests don't fail for me. What failures are you seeing?
The testbot is complaining.
Okay, I'll look into it. Thanks.
diff --git a/patches/update b/patches/update
index e18d32d..4b2532e 100755
--- a/patches/update
+++ b/patches/update
@@ -77,7 +77,8 @@ my @legend =
"The patch is simply too large for review, you need to find a way to split it." ],
[ "testfail", "You didn't run 'make test' before submitting." .
"The patch requires a Wine fix but doesn't use todo_wine." .
- "The patch fixes a failure but doesn't remove the corresponding todo_wine." ],
+ "The patch fixes a failure but doesn't remove the corresponding todo_wine." .
+ "The patch introduces test failures on Windows. Use the http://testbot.winehq.org/\";>testbot." ],
);
my $dir = "$ENV{HOME}/patches";
Re: Specifying Reply-To header in patches email using git-send-email?
2010/8/21 Octavian Voicu : > 2010/8/21 GOUJON Alexandre : >> [format] >> headers = "To: wine-patches \nReply-To: >> wine-devel \n" > > As the name of the section suggests, this adds header lines to files > generated with `git format-patch'. If you then send those files with > `git send-email', it should work. If you `git send-email' files > generated before configuring that, then it wouldn't have any effect. > > Initially I thought the mailing list software was configured to add > the Reply-To header automagically, guess I was wrong. > > Octavian OK. By using [format] headers = "Reply-To: wine-devel \n" [sendemail] to = wine-patches I manage to get fully automated sending (yeah!). OTOH, using headers = "wine-patches \nReply-To: wine-devel \n" doesn't work since you're asked to provide the "To:" and you end up with two different "To" headers. I'll update the wiki. Thanks guys for your help. Frédéric
Re: Specifying Reply-To header in patches email using git-send-email?
On 08/21/2010 03:35 PM, Frédéric Delanoy wrote: This is used for git imap-send, and does not work for git-send-email (I checked). Following the relevant git send-email section (http://wiki.winehq.org/GitWine#head-f09f3498e5910648468960a60ecf0f51b0fd4815 - Sending the patches using smtp), I set "thread" to true, but this doesn't change anything/has nothing to do with the "Reply-To" header, rather the "In-Reply-To" header. I'm using git 1.7.2.1 I attached the script I use to send patches to wine + my .git/config file The only drawback is that the "wine-patches <>" is added twice. But it works for me. send_patch.sh Description: Bourne shell script [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = git://source.winehq.org/git/wine.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master ; user identity [user] name = "Alexandre Goujon" email = "ale.gou...@gmail.com" [format] headers = "To: wine-patches \nReply-To: wine-devel \n" [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = ale.gou...@gmail.com smtpserverport = 587 from = Alexandre Goujon to = wine-patches chainreplyto = false thead = true
Re: Specifying Reply-To header in patches email using git-send-email?
2010/8/21 GOUJON Alexandre : > [format] > headers = "To: wine-patches \nReply-To: > wine-devel \n" As the name of the section suggests, this adds header lines to files generated with `git format-patch'. If you then send those files with `git send-email', it should work. If you `git send-email' files generated before configuring that, then it wouldn't have any effect. Initially I thought the mailing list software was configured to add the Reply-To header automagically, guess I was wrong. Octavian
Re: Specifying Reply-To header in patches email using git-send-email?
2010/8/21 GOUJON Alexandre : > On 08/21/2010 09:34 AM, Frédéric Delanoy wrote: >> >> Here's how my git config looks like: >> [sendemail] >> >> from = user >> to = wine-patches >> assume8bitEncoding = UTF-8 >> >> suppresscc = self >> chainreplyto = false >> thread = false >> suppressfrom = true >> > > From > http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 > and according to my .git/config, I think you're missing > > [format] > headers = "To: wine-patches \nReply-To: > wine-devel \n" > This is used for git imap-send, and does not work for git-send-email (I checked). Following the relevant git send-email section (http://wiki.winehq.org/GitWine#head-f09f3498e5910648468960a60ecf0f51b0fd4815 - Sending the patches using smtp), I set "thread" to true, but this doesn't change anything/has nothing to do with the "Reply-To" header, rather the "In-Reply-To" header. I'm using git 1.7.2.1 Frédéric
Re: Specifying Reply-To header in patches email using git-send-email?
On 08/21/2010 09:34 AM, Frédéric Delanoy wrote: Here's how my git config looks like: [sendemail] from = user to = wine-patches assume8bitEncoding = UTF-8 suppresscc = self chainreplyto = false thread = false suppressfrom = true From http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 and according to my .git/config, I think you're missing [format] headers = "To: wine-patches \nReply-To: wine-devel \n"
Specifying Reply-To header in patches email using git-send-email?
I've tried for some time to specify the wine-devel Reply-To using git-send-email, with little success so far Any idea how this might be done? Here's how my git config looks like: [sendemail] from = user to = wine-patches assume8bitEncoding = UTF-8 suppresscc = self chainreplyto = false thread = false suppressfrom = true Frédéric
Re: Sending patches for bug #22918
On Sat, 2010-07-17 at 15:39 +0200, Frédéric Delanoy wrote: > On Sat, Jul 17, 2010 at 14:43, Misha Koshelev wrote: > > On Fri, 2010-07-16 at 20:08 -0700, James McKenzie wrote: > >> Misha Koshelev wrote: > > p.s. Do I remember correctly AJ does not commit on weekends? > > Exactly. 5 times a week should be sufficient ;) Thanks guys, I used the following scripts to send the patches (attached). Just out of curiosity - is there a way to automatically append the (try #) to the patches... I seem to remember having this functionality... Thank you! Misha docount Description: application/shellscript patchesnotupstream-send Description: application/shellscript
