[RFC] Use ICU in wine ?
On Mon Oct 10 12:48:27 CDT 2011, André Hentschel wrote a few things: Well, in the bug you've mentioned (#5163) there was a link to that file in mono, but while it seems nice, just looking at mono code makes my eyes bleed and the perspective of rewriting it in perl would fill me with terror. There's also the question of how close did mono get to Windows in this case. Still, that would at most fixed the default table, the tailoring needs to be implemented anyway.
Re: 79869: [2/4] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 4)
Still fails tests here. Sorry if I wasn't clear before. The wine tests are supposed to pass after *every* patch in your series. That means you have to merge patches 2 and 3 together, I think. On Wed, Oct 12, 2011 at 9:27 PM, wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while > building Wine. > Full details are available at: > http://buildbot.kegel.com/builders/runtests-default/builds/297 (though maybe > not for long, as I'm still reinstalling the buildbot periodically while > experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > make: *** [pen.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >
Re: ntdll: Define PATH_MAX when needed
André Hentschel wrote: > Am 12.10.2011 23:53, schrieb Dan Kegel: > > When is PATH_MAX not defined? > > > > It's part of posix (see > > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html > > ) > > > > Are you trying to build on Gnu Hurd? > > Yes that's for Hurd. Austin already pointed out dynamic allocation might be a > better solution, so... Notice that PATH_MAX and MAX_PATH are completely different things going from different sources which can't be replaced by each other. -- Dmitry.
Re: [4/3] gdi32/tests: update test for PS_USERSTYLE
Yeah, I'll recombine them in a bit, but I didn't really remove the test,
per-se, I removed the if/else that performs the test with todo_wine when
the style is PS_USERSTYLE (see the line below, that, of course, is
improperly indented -- why I don't allow single statements in if, else,
while, etc. without a {} block in my own projects).
Daniel
On 10/12/2011 07:12 PM, Austin English wrote:
> On Wed, Oct 12, 2011 at 19:06, Daniel wrote:
>> OK, I hope [4/3] is acceptable. These are the test updates I forgot
>> (removes a todo_wine).
> Two problems:
> A) It needs to be combined with the original patch, so that it passes make
> test.
> B) Why remove the test? Just remove 'todo_wine' itself, since the test
> now passes on wine..
>
re: [4/3] gdi32/tests: update test for PS_USERSTYLE
> OK, I hope [4/3] is acceptable. It's fine for humans, but for buildbot, you really need to send the whole patch series again, with the test fixes right in the same patch as the code that fixes them (so that the wine tree passes all tests after each patch in the series). Otherwise your code will not be tested.
Re: [4/3] gdi32/tests: update test for PS_USERSTYLE
On Wed, Oct 12, 2011 at 19:06, Daniel wrote: > OK, I hope [4/3] is acceptable. These are the test updates I forgot > (removes a todo_wine). Two problems: A) It needs to be combined with the original patch, so that it passes make test. B) Why remove the test? Just remove 'todo_wine' itself, since the test now passes on wine.. -- -Austin
Re: 79857: [2/3] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 3)
> Fails the gdi32/pen.ok test here, with error > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > > Looks like you need to update a test. whoops, I forgot about my tests. Will do.
Re: 79857: [2/3] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 3)
Fails the gdi32/pen.ok test here, with error pen.c:317: Test succeeded inside todo block: expected 7, got 7 Looks like you need to update a test. On Wed, Oct 12, 2011 at 4:00 PM, wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while > building Wine. > Full details are available at: > http://buildbot.kegel.com/builders/runtests-default/builds/280 (though maybe > not for long, as I'm still reinstalling the buildbot periodically while > experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > make: *** [pen.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >
Re: ntdll: Define PATH_MAX when needed
Am 12.10.2011 23:53, schrieb Dan Kegel: > When is PATH_MAX not defined? > > It's part of posix (see > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html > ) > > Are you trying to build on Gnu Hurd? Yes that's for Hurd. Austin already pointed out dynamic allocation might be a better solution, so... -- Best Regards, André Hentschel
Re: wined3d: Report every texture format as filterable and blendable.
2011/10/12 Dan Kegel : > Fails d3d9's visual tests here. > > os: Linux 3.0.0-12-generic, Ubuntu 11.10 > gpu: GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13 > > On Wed, Oct 12, 2011 at 2:52 PM, wrote: >> This is an experimental automated build and test service. >> Please feel free to ignore this email while we work the kinks out. >> >> For more info about this message, see http://wiki.winehq.org/BuildBot >> >> The Buildbot has detected a failed build on builder runtests-default while >> building Wine. >> Full details are available at: >> http://buildbot.kegel.com/builders/runtests-default/builds/273 (though maybe >> not for long, as I'm still reinstalling the buildbot periodically while >> experimenting) >> BUILD FAILED: failed shell_3 >> >> Errors: >> alarum: failed command was ../../../wine d3d9_test.exe.so visual.c >> fixme:win:EnumDisplayDevicesW ((null),0,0x33f0cc,0x), stub! >> fixme:d3d_draw:drawPrimitive Using software emulation because manual fog >> coordinates are provided >> fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported >> fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported >> visual.c:9147: Tests skipped: D3DFMT_G16R16 textures not supported as render >> targets. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_R16F: Got color >> 0x20, expected 0x18. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_G16R16F: Got color >> 0x2010ff, expected 0x1818ff. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_R32F: Got color >> 0x20, expected 0x18. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_G32R32F: Got color >> 0x2010ff, expected 0x1818ff. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_A32B32G32R32F: Got >> color 0x201000, expected 0x181800. >> visual.c:7741: Tests skipped: Card has unconditional pow2 support, skipping >> conditional NP2 tests >> make: *** [visual.ok] Error 5 >> * Call to xpconnect wrapped JSObject produced this error: * >> * Call to xpconnect wrapped JSObject produced this error: * >> GnuTLS error: GnuTLS internal error. >> >> > Interesting. I didn't test on your kind of GPUs but I understood that it should support the feature I'm enabling. I'm not sure right now if it really doesn't support it or it is a driver bug of some kind. Thank you for catching it, if you have Windows installed on that machine I'll probably ask you to run a small testcase soon...
Re: wined3d: Report every texture format as filterable and blendable.
Fails d3d9's visual tests here. os: Linux 3.0.0-12-generic, Ubuntu 11.10 gpu:GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13 On Wed, Oct 12, 2011 at 2:52 PM, wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while > building Wine. > Full details are available at: > http://buildbot.kegel.com/builders/runtests-default/builds/273 (though maybe > not for long, as I'm still reinstalling the buildbot periodically while > experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine d3d9_test.exe.so visual.c > fixme:win:EnumDisplayDevicesW ((null),0,0x33f0cc,0x), stub! > fixme:d3d_draw:drawPrimitive Using software emulation because manual fog > coordinates are provided > fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported > fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported > visual.c:9147: Tests skipped: D3DFMT_G16R16 textures not supported as render > targets. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_R16F: Got color > 0x20, expected 0x18. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_G16R16F: Got color > 0x2010ff, expected 0x1818ff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_R32F: Got color > 0x20, expected 0x18. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_G32R32F: Got color > 0x2010ff, expected 0x1818ff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_A32B32G32R32F: Got > color 0x201000, expected 0x181800. > visual.c:7741: Tests skipped: Card has unconditional pow2 support, skipping > conditional NP2 tests > make: *** [visual.ok] Error 5 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >
re: ntdll: Define PATH_MAX when needed
When is PATH_MAX not defined? It's part of posix (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html ) Are you trying to build on Gnu Hurd?
Please Test again, user32: use uniscribe in the single line edit control
Apologies I sent this to the wrong list just now.
Ok, Thanks to Dan I have found and corrected the issues that this
created with the tests. I believe all the tests should continue to pass
with this version of the patch.
Has anyone tried it live in any applications?
-aric
---
dlls/user32/edit.c | 252
+---
1 files changed, 142 insertions(+), 110 deletions(-)
diff --git a/dlls/user32/edit.c b/dlls/user32/edit.c
index e02a268..78c89fe 100644
--- a/dlls/user32/edit.c
+++ b/dlls/user32/edit.c
@@ -158,6 +158,7 @@ typedef struct
* Uniscribe Data
*/
SCRIPT_LOGATTR *logAttr;
+ SCRIPT_STRING_ANALYSIS ssa; /* Uniscribe Data for single line controls */
} EDITSTATE;
@@ -365,6 +366,48 @@ static INT EDIT_CallWordBreakProc(EDITSTATE *es, INT start, INT index, INT count
return ret;
}
+static inline void EDIT_InvalidateUniscribeData(EDITSTATE *es)
+{
+ if (es->ssa)
+ {
+ ScriptStringFree(&es->ssa);
+ es->ssa = NULL;
+ }
+}
+
+static SCRIPT_STRING_ANALYSIS EDIT_UpdateUniscribeData(EDITSTATE *es, HDC dc, INT line)
+{
+ if (!(es->style & ES_MULTILINE))
+ {
+ if (!es->ssa)
+ {
+ INT length = get_text_length(es);
+ HFONT old_font = NULL;
+ HDC udc = dc;
+
+ if (!udc)
+udc = GetDC(es->hwndSelf);
+ if (es->font)
+old_font = SelectObject(udc, es->font);
+
+ if (es->style & ES_PASSWORD)
+ScriptStringAnalyse(udc, &es->password_char, length, (1.5*length+16), -1, SSA_LINK|SSA_FALLBACK|SSA_GLYPHS|SSA_PASSWORD, -1, NULL, NULL, NULL, NULL, NULL, &es->ssa);
+ else
+ScriptStringAnalyse(udc, es->text, length, (1.5*length+16), -1, SSA_LINK|SSA_FALLBACK|SSA_GLYPHS, -1, NULL, NULL, NULL, NULL, NULL, &es->ssa);
+
+ if (es->font)
+SelectObject(udc, old_font);
+ if (udc != dc)
+ReleaseDC(es->hwndSelf, udc);
+ }
+ return es->ssa;
+ }
+ else
+ {
+ return NULL;
+ }
+}
+
/*
*
* EDIT_BuildLineDefs_ML
@@ -647,52 +690,19 @@ static void EDIT_BuildLineDefs_ML(EDITSTATE *es, INT istart, INT iend, INT delta
/*
*
- * EDIT_GetPasswordPointer_SL
- *
- * note: caller should free the (optionally) allocated buffer
- *
- */
-static LPWSTR EDIT_GetPasswordPointer_SL(EDITSTATE *es)
-{
- if (es->style & ES_PASSWORD) {
- INT len = get_text_length(es);
- LPWSTR text = HeapAlloc(GetProcessHeap(), 0, (len + 1) * sizeof(WCHAR));
- text[len] = '\0';
- while(len) text[--len] = es->password_char;
- return text;
- } else
- return es->text;
-}
-
-
-/*
- *
* EDIT_CalcLineWidth_SL
*
*/
static void EDIT_CalcLineWidth_SL(EDITSTATE *es)
{
- SIZE size;
- LPWSTR text;
- HDC dc;
- HFONT old_font = 0;
-
- text = EDIT_GetPasswordPointer_SL(es);
+ const SIZE *size;
- dc = GetDC(es->hwndSelf);
- if (es->font)
- old_font = SelectObject(dc, es->font);
-
- GetTextExtentPoint32W(dc, text, strlenW(text), &size);
-
- if (es->font)
- SelectObject(dc, old_font);
- ReleaseDC(es->hwndSelf, dc);
-
- if (es->style & ES_PASSWORD)
- HeapFree(GetProcessHeap(), 0, text);
-
- es->text_width = size.cx;
+ EDIT_UpdateUniscribeData(es, NULL, 0);
+ size = ScriptString_pSize(es->ssa);
+ if (size)
+ es->text_width = size->cx;
+ else
+ es->text_width = 0;
}
/*
@@ -708,11 +718,11 @@ static void EDIT_CalcLineWidth_SL(EDITSTATE *es)
static INT EDIT_CharFromPos(EDITSTATE *es, INT x, INT y, LPBOOL after_wrap)
{
INT index;
- HDC dc;
- HFONT old_font = 0;
INT x_high = 0, x_low = 0;
if (es->style & ES_MULTILINE) {
+ HDC dc;
+ HFONT old_font = 0;
INT line = (y - es->format_rect.top) / es->line_height + es->y_offset;
INT line_index = 0;
LINEDEF *line_def = es->first_line_def;
@@ -762,9 +772,12 @@ static INT EDIT_CharFromPos(EDITSTATE *es, INT x, INT y, LPBOOL after_wrap)
if (after_wrap)
*after_wrap = ((index == line_index + line_def->net_length) &&
(line_def->ending == END_WRAP));
+ if (es->font)
+ SelectObject(dc, old_font);
+ ReleaseDC(es->hwndSelf, dc);
} else {
- LPWSTR text;
- SIZE size;
+ INT xoff = 0;
+ INT trailing;
if (after_wrap)
*after_wrap = FALSE;
x -= es->format_rect.left;
@@ -780,60 +793,47 @@ static INT EDIT_CharFromPos(EDITSTATE *es, INT x, INT y, LPBOOL after_wrap)
x -= indent / 2;
}
- text = EDIT_GetPasswordPointer_SL(es);
- dc = GetDC(es->hwndSelf);
- if (es->font)
- old_font = SelectObject(dc, es->font);
+ EDIT_UpdateUniscribeData(es, NULL, 0);
+ if (es->x_offset)
+ {
+ if (es->x_offset>= get_text_length(es))
+ {
+const SIZE *size;
+size = ScriptString_pSize(es->ssa);
+xoff = size->cx;
+ }
+ ScriptStringCPtoX(es->ssa, es->x_offset, FALSE, &xoff);
+ }
if (x < 0)
-{
-INT low = 0;
-INT high = es->x_offset;
-
Re: shell32/tests: Better check the result of SHGetDesktopFolder
2011/10/12 André Hentschel :
> Might fix the crash in some NT4 systems
> ---
> dlls/shell32/tests/brsfolder.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/shell32/tests/brsfolder.c b/dlls/shell32/tests/brsfolder.c
> index 7b87967..6e5e73b 100644
> --- a/dlls/shell32/tests/brsfolder.c
> +++ b/dlls/shell32/tests/brsfolder.c
> @@ -331,7 +331,8 @@ static void test_selection(void)
>
> hr = SHGetDesktopFolder(&desktop_object);
> ok (SUCCEEDED(hr), "SHGetDesktopFolder failed with hr 0x%08x\n", hr);
> - if (FAILED(hr)) {
> + ok (desktop_object, "Expected desktop_object to be a valid interface\n");
> + if (FAILED(hr) || !desktop_object) {
> skip("SHGetDesktopFolder failed - skipping\n");
> return;
> }
> --
>
> Best Regards, André Hentschel
Causes a compiler warning on Buildbot:
Errors:
brsfolder.c: In function 'test_selection':
brsfolder.c:334:5: error: passing argument 1 of 'winetest_ok' makes
integer from pointer without a cast [-Werror]
make[1]: *** [brsfolder.o] Error 1
--
-Austin
Re: Warning report for wine-1.3.30-55-g583e887
On Oct 12, 2011, at 1:31 PM, Octavian Voicu wrote: > On Wed, Oct 12, 2011 at 11:22 PM, Josh Juran wrote: >> My understanding is that accessing element n or greater in an array[n] >> is undefined behavior, but declaring a huge array and allocating only >> part of it is valid. > > It's a commonly used pattern in C. Agreed. > You declare a size-one array at the > end of a structure, then you allocate enough memory to hold the > structure plus (n-1) extra elements of the array. In wine size is > usually calculated with the macro FIELD_OFFSET(struct, member[size]). I understand. I'm just passing on what I read on another mailing list, which is that the construction is non-portable (even if it happens to work everywhere), and that might be the justification for the warning. A purist approach would call for avoiding this idiom, but pragmatically, disabling the warning is sufficient. Josh
Re: Warning report for wine-1.3.30-55-g583e887
On Wed, Oct 12, 2011 at 11:22 PM, Josh Juran wrote: > My understanding is that accessing element n or greater in an array[n] > is undefined behavior, but declaring a huge array and allocating only > part of it is valid. It's a commonly used pattern in C. You declare a size-one array at the end of a structure, then you allocate enough memory to hold the structure plus (n-1) extra elements of the array. In wine size is usually calculated with the macro FIELD_OFFSET(struct, member[size]). Octavian
Re: Warning report for wine-1.3.30-55-g583e887
On Oct 12, 2011, at 10:11 AM, Dmitry Timoshkov wrote: > Jerome Leclanche wrote: > >> It would be nice to fix the "array subscript is above array bounds" >> warning spam for 1.4.0. They make up 90% of the warnings. > > The compiler is misguided, you can safely ignore those warnings. My understanding is that accessing element n or greater in an array[n] is undefined behavior, but declaring a huge array and allocating only part of it is valid. Josh
Re: Warning report for wine-1.3.30-55-g583e887
On 10/12/2011 02:29 PM, Jerome Leclanche wrote:
> It would be nice to fix the "array subscript is above array bounds"
> warning spam for 1.4.0. They make up 90% of the warnings.
The fix would be to add a configure check for that bogus warning on
access to the array[n]; n > 1
struct _tag {
...
array[1];
}
and to add -Wno-array-bounds in that case.
bye
michael
Re: [Corrected^2] dlls/ntdll/serial.c: Generate a single EV_TXEMPTY when the\ TX buffer turns empty
Uwe Bonnes writes:
> @@ -807,8 +808,22 @@ typedef struct async_commio
> static NTSTATUS get_irq_info(int fd, serial_irq_info *irq_info)
> {
> NTSTATUS status = STATUS_NOT_IMPLEMENTED;
> -#ifdef TIOCGICOUNT
> struct serial_icounter_struct einfo;
You can't move this out of the #idef.
--
Alexandre Julliard
julli...@winehq.org
Re: WineHQ database compromise
On 10/11/2011 09:13 PM, Jeremy White wrote: I am sad to say that there was a compromise of the WineHQ database system. "Nothing Is Invulnerable" So, now or later, your system will be compromised. The only thing you have to do is to be prepared to face an incident and of course secure your systems to slow the attacker(s) down. The bugzilla case does not really worry me because it's only bugs. But as CEO, you have to protect your company and your customers. I'm of course a simple "user" of wine and I have absolutely not the right to tell you what to do. But something was open, broken or whatever .. and now you have to spend time and energy to try to repair the breach. Just don't let it happen again. There are lots of methods to analyse risk. Depending on what level of security you want, it will cost more or less. Just think about it. Anyway, thanks for the quick reply, communication is really important in this situation.
Re: Warning report for wine-1.3.30-55-g583e887
Jerome Leclanche wrote: > It would be nice to fix the "array subscript is above array bounds" > warning spam for 1.4.0. They make up 90% of the warnings. The compiler is misguided, you can safely ignore those warnings. -- Dmitry.
Re: d3d8/tests: skip the visual test if d3d cannot be initialized
On Wed, Oct 12, 2011 at 04:39, Henri Verbeet wrote: > On 12 October 2011 01:51, Austin English wrote: >> Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies >> the behavior to match the d3d9 behavior. >> > I seem to recall this being intentional, so that you get a failure if > your setup has e.g. no OpenGL. If the goal is to ensure some test fails with that setup, opengl32/tests/opengl.c already ensures that: ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c && touch opengl.ok err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems opengl.c:1295: Test failed: Unable to find pixel format. *** Error code 1 I was looking to make d3d8/d3d9 consistent. Instead we could make d3d9 fail if OpenGL isn't available, as d3d8 does now. -- -Austin
Re: [4/4] wined3d: Don't allow fbo blits to frontbuffers that need fixups.
On Wednesday 12 October 2011 11:35:48 Henri Verbeet wrote: > On 11 October 2011 22:31, Stefan Dösinger wrote: > > static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, > > enum wined3d_blit_op blit_op, > > > > const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool, > > const struct wined3d_format *src_format, > > > > -const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, > > const struct wined3d_format *dst_format) +const RECT *dst_rect, > > DWORD dst_usage, WINED3DPOOL dst_pool, const struct wined3d_format > > *dst_format, +const struct wined3d_surface *dst_surface) > > I don't think we want this. Does this actually ever happen? I had to double-check this. It used to be a problem before you introduced the shadow ddraw frontbuffer. Now it works by luck because the shadow frontbuffer has a palette set and is converted on upload time, so it is a RGB surface that doesn't need read-time conversion. There are two things that make the fbo blit work correctly although it should be broken: *) The offscreen P8 surfaces should be converted with the destination's palette. The palette happens to be the same for the shadow frontbuffer, but for no other surface. *) The shadow frontbuffer has SFLAG_CONVERTED set. Thus blits to it happen in software, otherwise we'd write P8 data to it that had no palette when it was converted to RGB(the ERR in d3dfmt_p8_init_palette). So in the end we never happen to have a P8 surface that only has GL_ALPHA8 data right now. No surface uses COMPLEX_FIXUP_P8 right now. It will be a problem again once we load offscreen surfaces(render target or just offscreenplain) with GL_ALPHA8 textures that require COMPLEX_FIXUP_P8. I'll send the patch again with the patchset that re-enables shader P8 conversion. And yeah, we don't actually want to pass the destination surface to fbo_blit_supported. It can go away again once we have the shadow frontbuffers in wined3d instead of ddraw. The ARB and FFP blitter have a similar problem when blitting to onscreen P8 surfaces, but unlike the FBO blitter they can do the palette lookup. They can accept the blit no matter what the destination is, but they have to make sure to select the right color fixup and palette. signature.asc Description: This is a digitally signed message part.
Re: 79794: Help Test Please: use uniscribe in the single line edit control
Thank Dan, I had not gotten to a full test run. I will look into those. -aric On 10/11/11 8:01 PM, Dan Kegel wrote: Hi Aric, failed again on second run, http://buildbot.kegel.com:8010/builders/runtests-default/builds/209 Failing tests are comctl32_test.exe.so listview.c comctl32_test.exe.so updown.c user32_test.exe.so edit.c On Tue, Oct 11, 2011 at 1:26 PM, Dan Kegel wrote: Hey Aric, don't know if I trust the bot at the moment, but it says the tests failed here... I'll rerun them to see if the failure is repeatable. -- Forwarded message -- From: Date: Tue, Oct 11, 2011 at 1:21 PM Subject: Re: 79794: Help Test Please: use uniscribe in the single line edit control To: d...@kegel.com, wine-tests-resu...@winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/186 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_3 Errors: alarum: Timeout! Killing child ../../../wine. alarum: failed command was ../../../wine comctl32_test.exe.so listview.c alarum: ../../../wine terminated abnormally make: *** [listview.ok] Error 99 alarum: Timeout! Killing child ../../../wine. alarum: failed command was ../../../wine comctl32_test.exe.so updown.c alarum: ../../../wine terminated abnormally make: *** [updown.ok] Error 99 * Call to xpconnect wrapped JSObject produced this error: * * Call to xpconnect wrapped JSObject produced this error: * alarum: failed command was ../../../wine user32_test.exe.so edit.c edit.c:1138: Test failed: expected 1 got 0 edit.c:1156: Test failed: expected 1 got 0 edit.c:1174: Test failed: expected 1 got 0 make: *** [edit.ok] Error 3 GnuTLS error: GnuTLS internal error.
Re: [PATCH 5/5] server/named_pipe.c: remove the ps_disconnected_server state, if DisconnectNamedPipe is called, the server i
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14844 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1603: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1603: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997
Re: [PATCH 4/5] kernel32, ntdll: implement most of GetNamedPipeHandleState (try 2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14843 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997
Re: [2/4] wined3d: reject ARB shader blits if the destination is not fbo attachable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.10.2011 um 11:26 schrieb Henri Verbeet:
> On 11 October 2011 22:30, Stefan Dösinger wrote:
>> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
>> +{
>> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
>> (dst_usage & WINED3DUSAGE_RENDERTARGET)))
>> +return FALSE;
>> +}
>> +else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET))
>> +{
>> +return FALSE;
>> +}
> Formats are never FBO-attachable if we don't have
> FBOs. It's not clear this is what you want either way though. This
> pretty much looks like a copy/paste from fbo_blit_supported(), and the
> WINED3DUSAGE_RENDERTARGET check there is to allow formats that don't
> have a FBO-attachable internal format, but were created with the
> rtInternal format (which should always be attachable). There's really
> no equivalent check for backbuffer ORM, it just renders something and
> hopes we can read it back.
I'm not sure I see what you mean. What I want is to make sure the blitter
doesn't draw to a surface that GL can't draw to. In the FBO ORM case the
fbo_attachable || rendertarget case seems just right, for the reasons you
mention.
With backbuffer ORM we don't really know where we can draw(e.g. stuff like
surface size vs framebuffer size comes into play), but I think RENDERTARGET
usage is a decent heuristic since we'll probably have to be able to draw to it
anyways, or things fails.
I could add some surface_is_drawable() function or equivalent surface flag.
That might be a good idea on its own, but I don't see a better way to define if
a surface can be rendered to than the above statement.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iQIcBAEBAgAGBQJOlYhaAAoJEN0/YqbEcdMwpxgQAJTF3i75QLb+gosDaGkFODbk
nhNUt/PHRw7k8yTVFBHp5aBWNCROdcr9yFANMj4AD74ii1HGNj9jzGISyfogvfqv
RNHHHvwdff7b8Ev8MtKBEY3w9fTPvl7w0FzdzoSTFBF2SxkeEMc6QnecaHIfcepr
SCf69/FFeVkPniOiVa3RCbLXyvrWG6ifMpJpXV8DFw23NTqb/JGyQIjodW2hc+Qy
Gpgz4hwBw/jywOeFPCyOXtpR0bTBdD03mix3XWeYYaZg1Ukm+jyARQOvBSFU0dgB
xhEcVTR0aNGA5WAgpKxUT1f3jRQc9f36U7HS5jTZemFR71wAXFPO0pMm7RNNrMXQ
imhzE9+56OS7o96Vk4Rz8UdFYDBgDvTjO8nlp9j5aDOi8ylsX9TstDdRi2kh3ILI
Satb83g0brU6JZaDqsLd5xZI8ZTPL55MniKRGvXJ1EEepViC0isgvMmrM1b/I2Wo
N0FSoLkukXAfJHcal9YD6nAQeoI1HbM9HNNmAMPMCtDb9Y8Q0VSSWoeh71iP8cGF
DziZZ3uSnX90kDrt7q6maXDFSWUS8YKZz2lviRxupb2LzwaSMAP2Aw1XEQz/YImH
HxZkPuY4kZdQNShcYOyv9ZqNKUBrD5geFhmErYqxSL+Ede1nM7Lcp52NhbVRnTLI
9ksujocgWYGZYbzbhwym
=04xu
-END PGP SIGNATURE-
Re: [1/4] wined3d: Use an rbtree for the blit programs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.10.2011 um 11:57 schrieb Henri Verbeet: > You already have the P8 shader. My bad. What will actually be added is the NONE conversion with color keying. But adding a color keying flag is what makes the current approach unsustainable because it's orthogonal to the other properties. > In the case of color keying it should > probably at least be in the same series as the code that uses it, I can resend the patch later, but IMO getting rid of the current spaghetti shader selection code makes sense on its own. > but > I'm not sure an rbtree would really have a lot of advantages over a > simple array there. I chose the rbtree for consistency with the ffp and pshader/vshader selection, but an array is probably more efficient because I don't expect to have more than 4 different blit shaders at a time. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOlXiYAAoJEN0/YqbEcdMwXLMP/0OUs1gZK6lJDmTOo7/HJRqt xh0+4pTZqWfQsPOePPJ9Erz5wtPSToKayShimwpbdvsmfdUgsGuWGqR22MipgADJ Q7t8muOEe8K9tFb5QgLwNhK39VQMASh+WohuUNFazMmBXbRIETT2UaGkh/VipihK gkI/7JnA8ju/Y41golqiEdnYShnmSTcnTXgaQp4NZDYZDgkT9IFHOmdd+uE4NvE2 ngYciZywyA8Rt37On4DjEMw9Jv32NKpnfoocXx7sPWFFpcqeDejCqIj32yVbWZBo Wj8gi4IbfAE+xdMWFBS2PIlCR1rbv6wwfaC9jB9rAYVpKin4hvk7DDPr4fqCTJ5q eTi5w1ehoH4MOeH8YPnu9BtxrKkrUwXYGKsivKB2jDBTzjm0G+IiZxKT00rvBrmL WpId1Y3Zau7TkTKeoy/W6LThjZzLeyw48Mmf5XTUabp8U/TBIwbPHzn5bHuYZJle AFt/74iWwbIfMVgeRGgSbXXCk56aV1+ykK9HT7DrH4Ne/74tZjZM4+kf54s/H9T+ hjj9lmR3mdm6wCnJqPdX+9+DyiYLSCgkdVa3Cd9TDaElsoMaggJIraxU8PFidU7c 3tzyg5AE+7QjqjKgv1ZZQhyYUWK85Z29iij5BWpzlqvaqfsKQD0fC6inaRhbkLG6 t5j6zcErEey2yeNttNas =3kLs -END PGP SIGNATURE-
Re: [1/4] wined3d: Use an rbtree for the blit programs
On 12 October 2011 11:47, Stefan Dösinger wrote: > Because when we add more conversions(P8) and settings(color keying) the > current approach will result ugly unmaintainable if blocks. > You already have the P8 shader. In the case of color keying it should probably at least be in the same series as the code that uses it, but I'm not sure an rbtree would really have a lot of advantages over a simple array there.
Re: [1/4] wined3d: Use an rbtree for the blit programs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.10.2011 um 11:26 schrieb Henri Verbeet: > Why do you need this? Because when we add more conversions(P8) and settings(color keying) the current approach will result ugly unmaintainable if blocks. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOlWIoAAoJEN0/YqbEcdMwdsoP/1FWotm97eiLNanErb/fXL6C t9dlTzVVXbcUboFSw9uBhSY+GQNj+sjZ3sQ5wLJSsQbsypW4MMOYjoBIUD4n+N91 6QY2xK5Bys7DnE7l8T9k3jCss5Fi93TpOkrQjDi0I7C0OreL7/yueM3NJQwn4PiS PJE9C5upvARhPII158NqYtVrd5TmImpLes6yshI9k4gQc4XfDZt9n0x0ERWmL8ag zS8nVR2Zaa3HaRuk/BMnf5X8FWiImwT/JapK9AyroWV4Lcg4MlKaOLGl43KaRTjQ 8IbMDPxFdWOFyU4yOfu8MEwLPDj1g7wG/CxCDNrKXMgRxgTmam9mtogM+e/dGWFX H8x+Td7h56syIU9l7g+L/4ODVugIKBxBlDdeJVUYbjOOpxuaUjsiQXG5aUcfYLf2 +1hVoKXuk7XfobCF3XKRW0hQIZGW9iJ2NAfLQ6OWK/tCZIsQ+GQafjJRPSAMgC7E y/WQ6YuuTA9eGo9si8wiuzJ5xCJoqjG7Y4oB7aih/l0DjG8MwKwWuxk85kcMg6xF 9Hnkz7738HyXhb6Y2cyUtPVsJTao5DZkBFXKs+SiCQhOnLFKPrXyIB8Zk2R4uLl3 9v+OU9khdzjTvu+f8uRw+V3HW4X+inDdS2UueGNlRHh/rYFMHX8GIYKeVK+8PS/C 1ZEjQ+1hE7S664QuNv3g =Ptfk -END PGP SIGNATURE-
Re: d3d8/tests: skip the visual test if d3d cannot be initialized
On 12 October 2011 01:51, Austin English wrote: > Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies > the behavior to match the d3d9 behavior. > I seem to recall this being intentional, so that you get a failure if your setup has e.g. no OpenGL.
Re: [4/4] wined3d: Don't allow fbo blits to frontbuffers that need fixups.
On 11 October 2011 22:31, Stefan Dösinger wrote: > static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum > wined3d_blit_op blit_op, > const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool, const > struct wined3d_format *src_format, > -const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, const > struct wined3d_format *dst_format) > +const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, const > struct wined3d_format *dst_format, > +const struct wined3d_surface *dst_surface) I don't think we want this. Does this actually ever happen?
Re: [1/4] wined3d: Use an rbtree for the blit programs
Why do you need this?
Re: [3/4] wined3d: reject ffp blits if the destination is not fbo attachable
On 11 October 2011 22:30, Stefan Dösinger wrote:
> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
> +{
> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
> (dst_usage & WINED3DUSAGE_RENDERTARGET)))
> +return FALSE;
> +}
> +else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET))
> +{
> +return FALSE;
> +}
Same consideration as for 2/4. Guess I should have caught this when
bccfd7cc introduced it.
Re: [2/4] wined3d: reject ARB shader blits if the destination is not fbo attachable
On 11 October 2011 22:30, Stefan Dösinger wrote:
> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
> +{
> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
> (dst_usage & WINED3DUSAGE_RENDERTARGET)))
> +return FALSE;
> +}
> +else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET))
> +{
> +return FALSE;
> +}
This is redundant. Formats are never FBO-attachable if we don't have
FBOs. It's not clear this is what you want either way though. This
pretty much looks like a copy/paste from fbo_blit_supported(), and the
WINED3DUSAGE_RENDERTARGET check there is to allow formats that don't
have a FBO-attachable internal format, but were created with the
rtInternal format (which should always be attachable). There's really
no equivalent check for backbuffer ORM, it just renders something and
hopes we can read it back.
