Re: Another machine passing tests
Michael Stefaniuc wrote: > Hi Alasdair, > > Alasdair Sinclair wrote: > >>> Would you mind sharing what hardware that's on? You're using Fedora 10, >>> right? >>> >>> >>> >> Sure, Its a Dell XPS1530 laptop (core 2 duo T8100), 4GB Ram, GeForce >> 8600M GT. >> Running fedora 10 x86-64 (recently upgraded from 9) all latest patches >> applied, desktop is Gnome. >> > do you have SELinux enabled? I figure no as the default F10 SELinux > "breaks" Wine. Hmm ... you might have inherited the sane boolean setting > from F9 and thus aren't affected. > > Yes SELinux is enabled. I eventually managed to get it configured to allow wine to run. I think with something like the following. $ setsebool -P allow_execmod 1 $ chcon -t execmem_exec_t /home/ams/wine/bin/wine-preloader Which is a bit hackish, but seems to work, and it's possible there's settings I've forgotten about when I installed F9. >> bye >> michael >> Alasdair
Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.
Since I value your input in imm32 and i do a lot of work there. If you would like to send me that high level overview then I can see if it works into wine. That way you can continue to contribute and we do not compromise the source code. I have not looked at these patches yet so just send me an e-mail describing what they do. -aric James Hawkins wrote: > On Wed, Dec 17, 2008 at 2:51 PM, ByeongSik Jeon wrote: >> By an analysis of the ImmIsUIMessageA/W disassemble code, >> 1. checked msg : >> WM_IME_STARTCOMPOSITION <= msg <= WM_IME_KEYLAST, >> WM_IME_SETCONTEXT, WM_IME_NOTIFY, >> WM_IME_COMPOSITIONFULL, WM_IME_SELECT. >> 2. SendMessageA/W is used. >> > > Writing code for Wine based directly off of disassembled code is not > allowed. The only way disassembly can be used is clean-room reverse > engineering where person A disassembles the code and writes up a very > high-level spec file for person B to implement. Unfortunately, this > patch cannot be committed and you won't be able to submit patches for > the imm32 module anymore. >
Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.
On Wed, Dec 17, 2008 at 2:51 PM, ByeongSik Jeon wrote: > By an analysis of the ImmIsUIMessageA/W disassemble code, > 1. checked msg : > WM_IME_STARTCOMPOSITION <= msg <= WM_IME_KEYLAST, > WM_IME_SETCONTEXT, WM_IME_NOTIFY, > WM_IME_COMPOSITIONFULL, WM_IME_SELECT. > 2. SendMessageA/W is used. > Writing code for Wine based directly off of disassembled code is not allowed. The only way disassembly can be used is clean-room reverse engineering where person A disassembles the code and writes up a very high-level spec file for person B to implement. Unfortunately, this patch cannot be committed and you won't be able to submit patches for the imm32 module anymore. -- James Hawkins
Re: Wine t-shirts?
On Wed, Dec 17, 2008 at 4:49 PM, Andrew Fenn wrote: > Thinking about me walking down the street again I have to say I prefer > Remco's suggestion the best because it describes best what wine does. > I like the idea of a witty shirt however the lines suggested requires > that you already understand what wine and open source is about to get > the joke. Well, I personally tend to prefer T-shirts that not everybody understands, but that cause some good laughs on the chosen ones that do :P We'll select one kind of T-shirt depending on the poll, but if the store works find we should be able to offer alternative kinds of design soon. > Perhaps it would be best to have a combination of a funny picture, the > project name, Remco's suggestion for the text and possibly the wine > logo? Just my opinion, perhaps if you're doing voting you could make > up some witty and non-witty shirts and see which people like the most. I updated the poll ( http://spreadsheets.google.com/viewform?key=pFqhThgtfGxo3OxU8pe8ZDg ) with slogan options. I hope it still works for the ones who had already voted (which should answer only the last question, not all three)
WineD3D: add some new GL extensions
Hi,
Add some new GL extensions which are needed for better d3d9 floating point
support for R32F/RG32F and friends.
Roderick
--
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
>From 73b14244008b5541c7f92f290c4b4e4e51bb6f50 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Wed, 17 Dec 2008 23:20:02 +0100
Subject: [PATCH] Add GL_ARB_texture_rg / GL_EXT_texture_swizzle support. These extensions are needed for more efficient R32F/RG32F support.
---
dlls/wined3d/directx.c|2 ++
dlls/wined3d/wined3d_gl.h | 35 +++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index d8ec3ef..2394a4d 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -82,6 +82,7 @@ static const struct {
{"GL_ARB_texture_mirrored_repeat", ARB_TEXTURE_MIRRORED_REPEAT,0 },
{"GL_ARB_texture_non_power_of_two", ARB_TEXTURE_NON_POWER_OF_TWO, MAKEDWORD_VERSION(2, 0) },
{"GL_ARB_texture_rectangle",ARB_TEXTURE_RECTANGLE, 0 },
+{"GL_ARB_texture_rg", ARB_TEXTURE_RG, 0 },
{"GL_ARB_vertex_blend", ARB_VERTEX_BLEND, 0 },
{"GL_ARB_vertex_buffer_object", ARB_VERTEX_BUFFER_OBJECT, 0 },
{"GL_ARB_vertex_program", ARB_VERTEX_PROGRAM, 0 },
@@ -109,6 +110,7 @@ static const struct {
{"GL_EXT_texture_env_combine", EXT_TEXTURE_ENV_COMBINE,0 },
{"GL_EXT_texture_env_dot3", EXT_TEXTURE_ENV_DOT3, 0 },
{"GL_EXT_texture_sRGB", EXT_TEXTURE_SRGB, 0 },
+{"GL_EXT_texture_swizzle", EXT_TEXTURE_SWIZZLE,0 },
{"GL_EXT_texture_filter_anisotropic", EXT_TEXTURE_FILTER_ANISOTROPIC, 0 },
{"GL_EXT_texture_lod", EXT_TEXTURE_LOD,0 },
{"GL_EXT_texture_lod_bias", EXT_TEXTURE_LOD_BIAS, 0 },
diff --git a/dlls/wined3d/wined3d_gl.h b/dlls/wined3d/wined3d_gl.h
index bca828d..2d9c18a 100644
--- a/dlls/wined3d/wined3d_gl.h
+++ b/dlls/wined3d/wined3d_gl.h
@@ -2037,6 +2037,39 @@ typedef void (WINE_GLAPI * PGLFNGLTEXSUBIMAGE3DEXTPROC) (GLenum target, GLint le
#define GL_RGBA16F_ARB0x881A
#define GL_RGB16F_ARB 0x881B
#endif
+/* GL_ARB_texture_rg */
+#ifndef GL_ARB_texture_rg
+#define GL_RG 0x8227
+#define GL_RG_INTEGER 0x8228
+#define GL_R8 0x8229
+#define GL_R160x822A
+#define GL_RG80x822B
+#define GL_RG16 0x822C
+#define GL_R16F 0x822D
+#define GL_R32F 0x822E
+#define GL_RG16F 0x822F
+#define GL_RG32F 0x8230
+#define GL_R8I0x8231
+#define GL_R8UI 0x8232
+#define GL_R16I 0x8233
+#define GL_R16UI 0x8234
+#define GL_R32I 0x8235
+#define GL_R32UI 0x8236
+#define GL_RG8I 0x8237
+#define GL_RG8UI 0x8238
+#define GL_RG16I 0x8239
+#define GL_RG16UI 0x823A
+#define GL_RG32I 0x823B
+#define GL_RG32UI 0x823C
+#endif
+/* GL_EXT_texture_swizzle */
+#ifndef GL_EXT_texture_swizzle
+#define GL_TEXTURE_SWIZZLE_R_EXT 0x8E42
+#define GL_TEXTURE_SWIZZLE_G_EXT 0x8E43
+#define GL_TEXTURE_SWIZZLE_B_EXT 0x8E44
+#define GL_TEXTURE_SWIZZLE_A_EXT 0x8E45
+#define GL_TEXTURE_SWIZZLE_RGBA_EXT 0x8E46
+#endif
/* GL_ARB_half_float_pixel */
#ifndef GL_ARB_half_float_pixel
#define GL_ARB_half_float_pixel
@@ -3317,6 +3350,7 @@ typedef enum _GL_SupportedExt {
ARB_TEXTURE_MIRRORED_REPEAT,
ARB_TEXTURE_NON_POWER_OF_TWO,
ARB_TEXTURE_RECTANGLE,
+ ARB_TEXTURE_RG,
ARB_VERTEX_PROGRAM,
ARB_VERTEX_BLEND,
ARB_VERTEX_BUFFER_OBJECT,
@@ -3347,6 +3381,7 @@ typedef enum _GL_SupportedExt {
EXT_TEXTURE_ENV_COMBINE,
EXT_TEXTURE_ENV_DOT3,
EXT_TEXTURE_SRGB,
+ EXT_TEXTURE_SWIZZLE,
EXT_GPU_PROGRAM_PARAMETERS,
/* NVIDIA */
NV_HALF_FLOAT,
--
1.5.3.4
Re: Better user feedback and better user experience (idea)
2008/12/17 Austin English : > On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze wrote: >> 2008/12/17 Scott Ritchie : >> >>> If it's that users blame the distro when it's a Wine problem, then we >>> can present them with some sort of information before installing (or >>> perhaps running) Wine. After that we should get out of the way and let >>> them use Wine as normal. >> >> Wine should go out of way when the Windows application is known to run >> very well under Wine or when the user submitted feedback for this >> application in the past. Also, the user easily can skip the dialog. >> >>> If the problem is that we're not getting enough feedback, then a default >>> feedback nag might not be the best answer either. >> >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. > > It would take developer time and effort to analyze all these logs, and > that time is better spent actually implementing those features and > fixing bugs. Any logs like this would only be useful if they were automatically processed. For example, a list of top crashers could be produced, or something like the Kernel Oops report statistics. > In a few years when Wine is more developed and has most the API > implemented, this may be useful, but there's still a lot to do, and we > don't need more reports to tell us this. The use in statistics here would be to know what crashes are most frequent (via automated tools). If these could be given an id (e.g. a sha1 hash) they could be associated with a bug report to show which crashes (that have a bug report) are more active. This could help with retesting a bug and testing if a bug is still active in the latest version of wine. Taking a step back... there was a patch a few days ago to add a winewatson application similar to the drwatson program in Windows. This is a better way to go (at least initially) as it serves several purposes: 1. it shows people running wine applications directly instead of going via a command shell that something went wrong; 2. it allows wine to gather information such as terminal output and stack trace that the user can copy and paste in a bug report; 3. it allows the user to be pointed at the wine bugzilla page to report a bug if one does not already exist (including the terminal outbut and stack trace captured by winewatson), or confirm that the bug is still valid. I think that this is all that is necessary and should satisfy the needs outlined here without being a burden to developers and fitting into the current way that bugs are triaged and processed. It should also help the more novice users create better bug reports. - Reece
Re: Better user feedback and better user experience (idea)
2008/12/17 Austin English : >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. >> >> I guess this kind of feedback can be very powerful to Wine coders to >> create statistics like these: >> * Most popular API calls >> * Least popular API calls >> * Most common API calls that make applications fail >> * Unimplemented features used by very uncommon software (e.g. >> custom-built applications within companies) >> * Predicting the likelihood that a specific API call will be used when >> another API call is used in an application >> >> Maybe this information can be useful to detect which applications are >> affected by a bug in Wine. When this is known, testers can verify in >> multiple applications if the bug really is fixed in all applications. > > It would take developer time and effort to analyze all these logs, and > that time is better spent actually implementing those features and > fixing bugs. Everything takes time and time also can be invested to save time in the long run. > In a few years when Wine is more developed and has most the API > implemented, this may be useful, It's better to already start gathering this information even if you don't want to look at it as it is like website statistics: it becomes more valuable when you have more data. > but there's still a lot to do, and we > don't need more reports to tell us this. A database is no report. It is something you can consult at any time, for example when you want to see if the bug that just has been reported also can be tested in other applications. I guess this can become very interesting when the bug reported found problem in a very expensive proprietary application and the database indicates the same bug may also cause a similar problem in another freely available application. This would make it easier for a developer without the very expensive application of the bug reporter to fix the bug. -- Mvg, Sander Devrieze.
Re: Better user feedback and better user experience (idea)
On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze wrote: > 2008/12/17 Scott Ritchie : > >> If it's that users blame the distro when it's a Wine problem, then we >> can present them with some sort of information before installing (or >> perhaps running) Wine. After that we should get out of the way and let >> them use Wine as normal. > > Wine should go out of way when the Windows application is known to run > very well under Wine or when the user submitted feedback for this > application in the past. Also, the user easily can skip the dialog. > >> If the problem is that we're not getting enough feedback, then a default >> feedback nag might not be the best answer either. > >> Writing an elaborate >> system to tell us about known problems isn't particularly helpful; > > It shouldn't be an elaborate system: it can be as easy as asking the > user to click on a button to send a list of API calls, used DLLs, a > hash of the .exe binary, some critical information of his system, > amongst others to the Wine project. User based input in the feedback > form may or may not be a good thing; I just gave this as an example; > it is no necessary element in what I am proposing. > > I guess this kind of feedback can be very powerful to Wine coders to > create statistics like these: > * Most popular API calls > * Least popular API calls > * Most common API calls that make applications fail > * Unimplemented features used by very uncommon software (e.g. > custom-built applications within companies) > * Predicting the likelihood that a specific API call will be used when > another API call is used in an application > > Maybe this information can be useful to detect which applications are > affected by a bug in Wine. When this is known, testers can verify in > multiple applications if the bug really is fixed in all applications. It would take developer time and effort to analyze all these logs, and that time is better spent actually implementing those features and fixing bugs. In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this. -- -Austin
Re: Better user feedback and better user experience (idea)
2008/12/17 Scott Ritchie : > If it's that users blame the distro when it's a Wine problem, then we > can present them with some sort of information before installing (or > perhaps running) Wine. After that we should get out of the way and let > them use Wine as normal. Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog. > If the problem is that we're not getting enough feedback, then a default > feedback nag might not be the best answer either. > Writing an elaborate > system to tell us about known problems isn't particularly helpful; It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing. I guess this kind of feedback can be very powerful to Wine coders to create statistics like these: * Most popular API calls * Least popular API calls * Most common API calls that make applications fail * Unimplemented features used by very uncommon software (e.g. custom-built applications within companies) * Predicting the likelihood that a specific API call will be used when another API call is used in an application Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications. > reports from stable or nonlatest versions would be largely ignored, and > users of the latest beta can be asked to contribute in other ways, such > as on the download page itself. > > Remember, it doesn't take much work for us to know that an application > doesn't work - a single bug report can do that. Once we have that, we > don't need to ask a million other users (literally) for confirmation. Only geeks file good bug reports. Normal people don't care and will not spend energy on this. -- Mvg, Sander Devrieze.
Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb
On Wed, Dec 17, 2008 at 2:48 PM, Rosanne DiMesio wrote: > On Wed, 17 Dec 2008 14:13:31 +0100 > Alexander Nicolaysen Sørnes wrote: > >> On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: >> > Since the change to the new design, AppDB entries have been displaying >> > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) >> > in place of a variety of special characters, including anything with an >> > umlaut (bug 16514). I've played around with it a bit, and the entries can >> > be fixed by manually editing them, but before I undertake the task, I >> > figured I'd better ask if this is something that could be fixed more easily >> > (e.g., changing a setting on the server). >> >> Could you provide a link to a page where this problem is shown? >> > > http://appdb.winehq.org/objectManager.php?sClass=application&iId=5651 > http://appdb.winehq.org/objectManager.php?sClass=application&iId=6764 > > It would appear that the new template says: , but those pages actually contain text encoded in ISO-8859-1. Possibly some kind of bulk conversion would be in order? -Nye
Re: winewtsn: add a new program that shows a dialog to inform about a crash
Mikołaj Zalewski writes: > Currently, when a program is started from the KDE or Gnome menu and > it crashes, it simply disappears from the screen without any > explanation what happened - the information that goes to the console > is not visible. This program uses a similar technique as Windows' dr > Watson to register itself as a debugger and show a dialog about a > crash. It then calls winedbg, so, if the program is run from a > terminal, the dump will be still visible. As a bonus feature, one can > Shift+right click on the dialog to start an interactive session of > winedbg. The patch has an effect only on new wineprefixes, as the > debugger setting is not overwritten after a Wine upgrade. I'd suggest to do that in winedbg, there's no need to add another Wine-specific program for that. -- Alexandre Julliard julli...@winehq.org
Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl
Hi Dmitry, Dmitry Timoshkov schreef: > "Maarten Lankhorst" wrote: > >> Needed to get +relay working in wine64 > > You should have used CDECL instead of __cdecl, have a look how it's > done in msvcrt.dll. In msvcrt both were used, so that doesn't really help. I guess that confused me a little. sed to the rescue!! ;) Cheers, Maarten.
Re: Wine t-shirts?
On Wed, Dec 17, 2008 at 3:17 PM, Ismael Barros² wrote: >> "Windows translation layer" >> "Run Windows applications on Linux, BSD and Mac OS X." > > It doesn't really sound very T-shirt-y to me. I think I'd rather wear > a T-shirt with a short, witty slogan than being a walking banner :) > > Something like "Releasing your computer of Windows since 1993" or > "Closing your Windows since 1993" or "Putting the Win in Windows(TM) > since 1993" (okay that last one was more stupid than it should be) > would do the work, enough to avoid alcoholic confussions yet not that > boring. If someone is that interested in what are the windows you're > so interested in closing, they may ask. > Thinking about me walking down the street again I have to say I prefer Remco's suggestion the best because it describes best what wine does. I like the idea of a witty shirt however the lines suggested requires that you already understand what wine and open source is about to get the joke. Perhaps it would be best to have a combination of a funny picture, the project name, Remco's suggestion for the text and possibly the wine logo? Just my opinion, perhaps if you're doing voting you could make up some witty and non-witty shirts and see which people like the most. Regards, Andrew
Re: Wine t-shirts?
> "Windows translation layer" > "Run Windows applications on Linux, BSD and Mac OS X." It doesn't really sound very T-shirt-y to me. I think I'd rather wear a T-shirt with a short, witty slogan than being a walking banner :) Something like "Releasing your computer of Windows since 1993" or "Closing your Windows since 1993" or "Putting the Win in Windows(TM) since 1993" (okay that last one was more stupid than it should be) would do the work, enough to avoid alcoholic confussions yet not that boring. If someone is that interested in what are the windows you're so interested in closing, they may ask.
Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl
Maarten Lankhorst writes: > @@ -33,9 +33,9 @@ > WINE_DEFAULT_DEBUG_CHANNEL(bitmap); > > > -static HGDIOBJ BITMAP_SelectObject( HGDIOBJ handle, HDC hdc ); > -static INT BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID > buffer ); > -static BOOL BITMAP_DeleteObject( HGDIOBJ handle, void *obj ); > +static HGDIOBJ __cdecl BITMAP_SelectObject( HGDIOBJ handle, HDC hdc ); > +static INT __cdecl BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, > LPVOID buffer ); > +static BOOL __cdecl BITMAP_DeleteObject( HGDIOBJ handle, void *obj ); You shouldn't need to change these. -- Alexandre Julliard julli...@winehq.org
Re: Wine t-shirts?
On Wed, Dec 17, 2008 at 12:41 PM, Andrew Fenn wrote: > > Perhaps some smaller text underneath where it says wine, "The windows > translation layer" or something similar to this? Just to define what I > might be for someone who has no idea. > Probably better to use the WineHQ tag line. A normal person would think that "Windows translation layer" had something to do with internationalization. The WineHQ tag line explains it better: "Run Windows applications on Linux, BSD and Mac OS X." Remco
Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb
On Wed, 17 Dec 2008 14:13:31 +0100 Alexander Nicolaysen Sørnes wrote: > On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: > > Since the change to the new design, AppDB entries have been displaying > > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) > > in place of a variety of special characters, including anything with an > > umlaut (bug 16514). I've played around with it a bit, and the entries can > > be fixed by manually editing them, but before I undertake the task, I > > figured I'd better ask if this is something that could be fixed more easily > > (e.g., changing a setting on the server). > > Could you provide a link to a page where this problem is shown? > http://appdb.winehq.org/objectManager.php?sClass=application&iId=5651 http://appdb.winehq.org/objectManager.php?sClass=application&iId=6764 -- Rosanne DiMesio
Making the shell32/appbar tests pass on Vista
Hi Vincent,
I was trying to have the appbar tests succeed on Vista. One way I could make it
work is with the attached patch. Does this make sense? Or should we have another
possible outcome of the test? (or even a broken()?).
The change to do_events_until was only for my troubleshooting purposes. (Vista
times out without the patch).
--
Cheers,
Paul.
diff --git a/dlls/shell32/tests/appbar.c b/dlls/shell32/tests/appbar.c
index d11a999..8dff9a8 100644
--- a/dlls/shell32/tests/appbar.c
+++ b/dlls/shell32/tests/appbar.c
@@ -128,8 +128,13 @@ static void do_events_until(boolean_function test)
TranslateMessage(&msg);
DispatchMessageA(&msg);
}
-if (timedout || test())
+if (test())
break;
+else if (timedout)
+{
+trace("Timed out waiting for condition to become true\n");
+break;
+}
WaitMessage();
}
@@ -333,6 +338,8 @@ static void test_setpos(void)
windows[0].registered = FALSE;
DestroyWindow(windows[0].hwnd);
+testwindow_setpos(windows[1].hwnd);
+
do_events_until(got_expected_bottom);
ok(windows[1].allocated_rect.bottom == expected_bottom, "windows[1]'s
bottom is %i, expected %i\n", windows[1].allocated_rect.bottom,
expected_bottom);
Re: server: implement move/rename change notifications and support for multiple change notification in one reply
On Wed, Dec 17, 2008 at 1:21 AM, Henri Verbeet wrote: > The attachment is here: > http://www.winehq.org/pipermail/wine-patches/2008-December/066225.html > The archive seems to create separate mails for attached mails. D'oh! Geez, we've got to fix that... - Dan
Re: Another machine passing tests
Hi Alasdair, Alasdair Sinclair wrote: >> Would you mind sharing what hardware that's on? You're using Fedora 10, >> right? >> >> > Sure, Its a Dell XPS1530 laptop (core 2 duo T8100), 4GB Ram, GeForce > 8600M GT. > Running fedora 10 x86-64 (recently upgraded from 9) all latest patches > applied, desktop is Gnome. do you have SELinux enabled? I figure no as the default F10 SELinux "breaks" Wine. Hmm ... you might have inherited the sane boolean setting from F9 and thus aren't affected. > It's also running the proprietary Nvidia drivers packaged by rpmfusion. bye michael
Re: wined3d: Implement check for shader creation if hardware supports requested version.
2008/12/17 Paul Vriens : > So that leaves the C++ comments? > No, the code you quoted was in d3d9/tests/shader.c, so I think your comment was right, even though it's a pretty minor issue.
Re: wined3d: Implement check for shader creation if hardware supports requested version.
2008/12/17 Stefan Dösinger :
>> if ()
>> {
>> }
>> else
>> {
>> }
>>
>> block to stick with the style.
> Actually most of WineD3D's code uses the style the patch uses, but its not
> 100% consistent :-/
>
Most of the tests don't.
Re: wined3d: Implement check for shader creation if hardware supports requested version.
Henri Verbeet wrote:
> 2008/12/17 Stefan Dösinger :
>>> if ()
>>> {
>>> }
>>> else
>>> {
>>> }
>>>
>>> block to stick with the style.
>> Actually most of WineD3D's code uses the style the patch uses, but its not
>> 100% consistent :-/
>>
> Most of the tests don't.
So that leaves the C++ comments?
--
Cheers,
Paul.
RE: wined3d: Implement check for shader creation if hardware supports requested version.
> if ()
> {
> }
> else
> {
> }
>
> block to stick with the style.
Actually most of WineD3D's code uses the style the patch uses, but its not
100% consistent :-/
Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb
On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: > Since the change to the new design, AppDB entries have been displaying > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) > in place of a variety of special characters, including anything with an > umlaut (bug 16514). I've played around with it a bit, and the entries can > be fixed by manually editing them, but before I undertake the task, I > figured I'd better ask if this is something that could be fixed more easily > (e.g., changing a setting on the server). Could you provide a link to a page where this problem is shown? Alexander N. Sørnes
Re: wined3d: Reduce and improve error message spam when shader creation fails.
These should probably all be WARNs as well.
Re: wined3d: Implement check for shader creation if hardware supports requested version.
2008/12/17 Pauli Nieminen :
> +static inline BOOL is_pshader_version_supported(IWineD3DDeviceImpl
> *deviceImpl, const DWORD *byte_code)
> +{
> +struct shader_caps shader_caps;
> +const DWORD shader_version = *byte_code; /* First instruction should be
> shader version */
Please don't do that, use the reg_maps.shader_version instead.
> +ERR("First instruction in shader isn't correct shader version for pixel
> shader. (0x%x)\n", shader_version);
ERR is for internal errors, this should be a WARN. You probably don't
need to print anything at all here though, doing it from the caller
makes more sense (and you've got a message there already anyway).
> +ERR("No hardware support for pixel shader version
> (0x%x).\n",*pFunction);
Like above, this should be a WARN. That also means you can get rid of
the code to only print the message once.
Re: d3d9/tests: Add missing new lines to ok() and split long lines
Pauli Nieminen wrote:
> ---
> dlls/d3d9/tests/shader.c | 16
> 1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/dlls/d3d9/tests/shader.c b/dlls/d3d9/tests/shader.c
> index 55b414a..caae395 100644
> --- a/dlls/d3d9/tests/shader.c
> +++ b/dlls/d3d9/tests/shader.c
> @@ -85,10 +85,14 @@ static inline void
> test_create_vshader_version_check(IDirect3DDevice9 *device_pt
>
> if( version <= caps->VertexShaderVersion )
> {
> -ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x)
> creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr =
> %p", version, hret, vshader_ptr);
> +ok(hret == D3D_OK && vshader_ptr != NULL,
> +"Vertex shader (0x%x) creation failed but d3dcaps claim to
> support it. hret = 0x%x, vshader_ptr = %p\n",
> +version, hret, vshader_ptr);
> IDirect3DVertexShader9_Release(vshader_ptr);
> } else {
> -ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader
> (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x,
> vshader_ptr = %p", version, hret, vshader_ptr);
> +ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,
> +"Vertex shader (0x%x) creation succesed but d3dcaps claim not to
> support it. hret = 0x%x, vshader_ptr = %p\n",
> +version, hret, vshader_ptr);
> }
>
> }
> @@ -104,10 +108,14 @@ static inline void
> test_create_pshader_version_check(IDirect3DDevice9 *device_pt
>
> if( version <= caps->PixelShaderVersion )
> {
> -ok(hret == D3D_OK && pshader_ptr != NULL, "Pixel shader (0x%x)
> creation failed but d3dcaps claim to support it. hret = 0x%x, pshader_ptr =
> %p", version, hret, pshader_ptr);
> +ok(hret == D3D_OK && pshader_ptr != NULL,
> +"Pixel shader (0x%x) creation failed but d3dcaps claim to
> support it. hret = 0x%x, pshader_ptr = %p\n",
> +version, hret, pshader_ptr);
> IDirect3DPixelShader9_Release(pshader_ptr);
> } else {
> -ok(hret == D3DERR_INVALIDCALL && pshader_ptr == NULL,"Pixel shader
> (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x,
> pshader_ptr = %p", version, hret, pshader_ptr);
> +ok(hret == D3DERR_INVALIDCALL && pshader_ptr == NULL,
> +"Pixel shader (0x%x) creation succesed but d3dcaps claim not to
> support it. hret = 0x%x, pshader_ptr = %p\n",
> +version, hret, pshader_ptr);
> }
>
> }
Hi,
These fixes are on top of your previous patch which is not committed). If it's
a
series of patches you should mark them appropriate ([1/2] and [2/2] for
example). In this case it's probably better to incorporate this into the
previous patch and resend that one.
--
Cheers,
Paul.
Re: wined3d: Implement check for shader creation if hardware supports requested version.
Pauli Nieminen wrote:
> +
> +if( version <= caps->VertexShaderVersion )
> +{
> +ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x)
> creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr =
> %p", version, hret, vshader_ptr);
> +IDirect3DVertexShader9_Release(vshader_ptr);
> +} else {
> +ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader
> (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x,
> vshader_ptr = %p", version, hret, vshader_ptr);
> +}
Hi,
Just some style issues I've seen. You should be using a:
if ()
{
}
else
{
}
block to stick with the style.
>
> +/**
> + * checks if shader version supported that is required by new
> + * shader.
> + */
> +static inline BOOL is_pshader_version_supported(IWineD3DDeviceImpl
> *deviceImpl, const DWORD *byte_code)
> +{
> +struct shader_caps shader_caps;
> +const DWORD shader_version = *byte_code; /* First instruction should be
> shader version */
> +const WineD3D_GL_Info *gl_info = &deviceImpl->adapter->gl_info;
> +
> +deviceImpl->shader_backend->shader_get_caps(deviceImpl->devType
> ,gl_info, &shader_caps);
> +// Check which shader this is
Please use C-style comments, not C++.
> +if(shader_is_pshader_version(shader_version))
> +{
> +// Check if high enough shader version is supported
And there are a few others of those.
--
Cheers,
Paul.
Re: Wine t-shirts?
On Wed, Dec 17, 2008 at 12:14 AM, Ismael Barros² wrote: > > Well, what do you expect from a program called wine? :P > All the wine logos I know are wine-related. Maybe we can use them but > with some kind of C source code background, but even then most people > would think you are some kind of alcoholic geek. > Perhaps some smaller text underneath where it says wine, "The windows translation layer" or something similar to this? Just to define what I might be for someone who has no idea.
Re: [try2] ntoskrnl.exe: Implement Io{Allocate, Get}DriverObjectExtension.
Alexander Morozov wrote:
> Please, use this patch instead of previous "ntoskrnl.exe: Implement
> Io{Allocate,Get}DriverObjectExtension."
Shouldn't this have gone to wine-patches instead of wine-devel?
bye
michael
[try2] ntoskrnl.exe: Implement Io{Allocate, Get}DriverObjectExtension.
Please, use this patch instead of previous "ntoskrnl.exe: Implement
Io{Allocate,Get}DriverObjectExtension."
From b5441d22fe51640849436b563ca3ab6c9a80c1a5 Mon Sep 17 00:00:00 2001
From: Alexander Morozov
Date: Wed, 17 Dec 2008 12:44:46 +0300
Subject: [PATCH] ntoskrnl.exe: Implement Io{Allocate,Get}DriverObjectExtension.
---
dlls/ntoskrnl.exe/ntoskrnl.c | 53 +++--
1 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c
index a669d3b..73054e3 100644
--- a/dlls/ntoskrnl.exe/ntoskrnl.c
+++ b/dlls/ntoskrnl.exe/ntoskrnl.c
@@ -63,6 +63,16 @@ struct IrpInstance
IRP *irp;
};
+static struct list DriverObjExtensions = LIST_INIT(DriverObjExtensions);
+
+struct DriverObjExtension
+{
+struct list entry;
+void *ptr;
+DRIVER_OBJECT *driver;
+void *id_addr;
+};
+
#ifdef __i386__
#define DEFINE_FASTCALL1_ENTRYPOINT( name ) \
__ASM_GLOBAL_FUNC( name, \
@@ -267,9 +277,28 @@ NTSTATUS WINAPI IoAllocateDriverObjectExtension(
PDRIVER_OBJECT DriverObject,
ULONG
DriverObjectExtensionSize,
PVOID *DriverObjectExtension )
{
-FIXME( "%p, %p, %u, %p\n", DriverObject, ClientIdentificationAddress,
+struct DriverObjExtension *ext;
+
+TRACE( "%p, %p, %u, %p\n", DriverObject, ClientIdentificationAddress,
DriverObjectExtensionSize, DriverObjectExtension );
-return STATUS_NOT_IMPLEMENTED;
+
+*DriverObjectExtension = NULL;
+if (IoGetDriverObjectExtension( DriverObject, ClientIdentificationAddress
))
+return STATUS_OBJECT_NAME_COLLISION;
+ext = ExAllocatePool( NonPagedPool, sizeof(*ext) );
+if (ext == NULL)
+return STATUS_INSUFFICIENT_RESOURCES;
+ext->ptr = ExAllocatePool( NonPagedPool, DriverObjectExtensionSize );
+if (ext->ptr == NULL)
+{
+ExFreePool( ext );
+return STATUS_INSUFFICIENT_RESOURCES;
+}
+ext->driver = DriverObject;
+ext->id_addr = ClientIdentificationAddress;
+list_add_tail( &DriverObjExtensions, &ext->entry );
+*DriverObjectExtension = ext->ptr;
+return STATUS_SUCCESS;
}
@@ -279,7 +308,16 @@ NTSTATUS WINAPI IoAllocateDriverObjectExtension(
PDRIVER_OBJECT DriverObject,
PVOID WINAPI IoGetDriverObjectExtension( PDRIVER_OBJECT DriverObject,
PVOID ClientIdentificationAddress )
{
-FIXME( "%p, %p\n", DriverObject, ClientIdentificationAddress );
+struct DriverObjExtension *ext;
+
+TRACE( "%p, %p\n", DriverObject, ClientIdentificationAddress );
+
+LIST_FOR_EACH_ENTRY( ext, &DriverObjExtensions, struct DriverObjExtension,
entry )
+{
+if (DriverObject == ext->driver &&
+ClientIdentificationAddress == ext->id_addr)
+return ext->ptr;
+}
return NULL;
}
@@ -1138,6 +1176,7 @@ PVOID WINAPI MmGetSystemRoutineAddress(PUNICODE_STRING
SystemRoutineName)
BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved )
{
LARGE_INTEGER count;
+struct DriverObjExtension *ext, *ext2;
switch(reason)
{
@@ -1146,6 +1185,14 @@ BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason,
LPVOID reserved )
RtlAddVectoredExceptionHandler( TRUE, vectored_handler );
KeQueryTickCount( &count ); /* initialize the global KeTickCount */
break;
+case DLL_PROCESS_DETACH:
+LIST_FOR_EACH_ENTRY_SAFE( ext, ext2, &DriverObjExtensions,
+struct DriverObjExtension, entry )
+{
+list_remove( &ext->entry );
+ExFreePool( ext->ptr );
+ExFreePool( ext );
+}
}
return TRUE;
}
--
1.6.0.2.GIT
Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.
2008/12/17 Pauli Nieminen : > On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet wrote: >> If creation succeeds, you need to Release the shader again. Same goes >> for the pixel shader version of this function. > > I tried to search for example of releasing shaders from the test file but > when I couldn't find any. Should others test in that file also include > shader release? > They should, although you're right that they don't. It's not as much of an issue in these test since we don't do any fullscreen tests here, but if the device still has references to it at the end of the test it won't be released properly and won't restore the display mode.
Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.
On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet wrote:
> 2008/12/17 Pauli Nieminen :
> > +static inline void test_create_vshader_version_check(IDirect3DDevice9
> *device_ptr, const D3DCAPS9 *caps,
> > +const DWORD version, const DWORD *shader_code)
> > +{
> > +IDirect3DVertexShader9 *vshader_ptr = 0;
> > +HRESULT hret = 0;
> > +
> > +hret = IDirect3DDevice9_CreateVertexShader(device_ptr, shader_code,
> &vshader_ptr);
> > +
> > +
> > +if( version <= caps->VertexShaderVersion )
> > +{
> > +ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x)
> creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr =
> %p", version, hret, vshader_ptr);
> > +} else {
> > +ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex
> shader (0x%x) creation succesed but d3dcaps claim not to support it. hret =
> 0x%x, vshader_ptr = %p", version, hret, vshader_ptr);
> > +}
> > +
> > +}
> If creation succeeds, you need to Release the shader again. Same goes
> for the pixel shader version of this function.
>
I tried to search for example of releasing shaders from the test file but
when I couldn't find any. Should others test in that file also include
shader release?
Thanks for comments.
Re: server: implement move/rename change notifications and support for multiple change notification in one reply
2008/12/17 Dan Kegel : > On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos > wrote: >>> I don't see an attachment to >>> http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html >>> or rather, there's only a zero-length one. >> >> I just attached (In thunderbird) the file outputted by "git format-patch >> --keep-subject origin" >> Curiously the link above point to a zero length file but I received it >> correctly in my e-mail client from the mailing-list... > > That archive is a bit finicky. > I see the attachment in another archive: > http://marc.info/?l=wine-patches&m=122947592925831&w=2 > Suggestion: next time use a shorter filename, maybe that's > what screwed up the archive. > The attachment is here: http://www.winehq.org/pipermail/wine-patches/2008-December/066225.html The archive seems to create separate mails for attached mails.
Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.
2008/12/17 Pauli Nieminen :
> +static inline void test_create_vshader_version_check(IDirect3DDevice9
> *device_ptr, const D3DCAPS9 *caps,
> +const DWORD version, const DWORD *shader_code)
> +{
> +IDirect3DVertexShader9 *vshader_ptr = 0;
> +HRESULT hret = 0;
> +
> +hret = IDirect3DDevice9_CreateVertexShader(device_ptr, shader_code,
> &vshader_ptr);
> +
> +
> +if( version <= caps->VertexShaderVersion )
> +{
> +ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x)
> creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr =
> %p", version, hret, vshader_ptr);
> +} else {
> +ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader
> (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x,
> vshader_ptr = %p", version, hret, vshader_ptr);
> +}
> +
> +}
If creation succeeds, you need to Release the shader again. Same goes
for the pixel shader version of this function.
> -ok(hret == D3D_OK && shader_refcount == i && current_shader_ptr ==
> shader_ptr,
> +ok(hret == D3D_OK && shader_refcount == i && current_shader_ptr ==
> shader_ptr,
>
I don't particularly like the trailing space either, but you shouldn't
make unrelated whitespace changes in your patch.
> +static inline BOOL is_shader_version_supported(IWineD3DDeviceImpl
> *deviceImpl, const DWORD *byte_code)
> +{
> +// IWineD3DPixelShaderImpl *This = (IWineD3DPixelShaderImpl *)shader;
> + struct shader_caps shader_caps;
> + const DWORD shader_version = *byte_code; /* First instruction should
> be shader version */
> +const WineD3D_GL_Info *gl_info = &deviceImpl->adapter->gl_info;
Please don't use tabs or C++ style comments.
> /* Note that this does not count the loop register
> * as an address register. */
> @@ -216,7 +244,27 @@ HRESULT shader_get_registers_used(IWineD3DBaseShader
> *iface, struct shader_reg_m
> memset(reg_maps->bumpmat, 0, sizeof(reg_maps->bumpmat));
> memset(reg_maps->luminanceparams, 0, sizeof(reg_maps->luminanceparams));
>
> -/* get_registers_used is called on every compile on some 1.x shaders,
> which can result
> + /* If no hardware support this function should fail */
> + if
> (!is_shader_version_supported((IWineD3DDeviceImpl*)This->baseShader.device,
> pToken))
> + {
> + static BOOL warned = FALSE;
> + if (!warned)
> + {
> + warned = TRUE;
> + ERR("No hardware support for shader version.\n");
> + }
> + return WINED3DERR_INVALIDCALL;
> + }
> +
> +
> +if (!pToken)
> +{
> +WARN("Got a NULL pFunction, returning.\n");
> +This->baseShader.functionLength = 0;
> +return WINED3D_OK;
> +}
> +
> + /* get_registers_used is called on every compile on some 1.x shaders,
> which can result
>
I don't think shader_get_registers_used is the right place for this.
The version check should be in IWineD3DVertexShaderImpl_SetFunction()
and IWineD3DPixelShaderImpl_SetFunction(), after the call to
shader_get_registers_used(). Putting it there means you can use the
shader version in reg_maps.shader_version, and you can also check if
the shader is actually a vertexshader or pixelshader. Ie, passing a
pixel shader to CreateVertexShader() should most likely fail.
