February 2017 - Wine-devel - list.winehq.org

Re: [PATCH 2/6] wined3d: Fix swizzle for ld_raw instruction.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 13:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -5063,9 +5071,9 @@ static void shader_glsl_ld_raw(const struct wined3d_shader_instruction *ins) > &dst, dst.reg.data_type))) > continue; > > - shader_glsl_swizzle_to_str(src->swizzle, FALSE, write_mask, dst_swizzle); > - shader_addline(buffer, "%s(%s_%s%u, %s / 4)%s);\n", > - function, prefix, resource, src->reg.idx[0].offset, offset.param_str, dst_swizzle); > + swizzle = shader_glsl_swizzle_get_component(src->swizzle, write_mask); That doesn't look right, should that use "i" instead of "write_mask"?

1 0

Re: Reproducible builds
by wylda＠volny.cz 20 Feb '17

20 Feb '17

> Od: Marcus Meissner <marcus(a)jet.franken.de> > > CC: <stefandoesinger(a)gmail.com, wine-devel(a)winehq.org> >On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda(a)volny.cz wrote: >> > Od: Stefan Dösinger <stefandoesinger(a)gmail.com> >> > >> >Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> >> value and use that consistently. Why are these libraries built >> >> inconsitently? Is that intentional? An example is attached. >> > >> >Have you looked at the .o files of those libraries? Finding the .c file >> >that introduces the difference might give some hints to pin down the >> >problem. >> > >> >> Thanks. These "random" value come from: >> >> * olepro_t.res >> * std_ole_v2_t.res >> * wuapi_tlb_t.res >> >> Anyway, all the other folders also have *.res files. Can these 3 be "fixed" >> so that they behave like the rest of dll-folders? Or can i pass some kind >> of parameter or switch? > >std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds >when I set WIDL_TIME_OVERRIDE="0". > >Same for olepro_t.res > >(current git state) When i do: export WIDL_TIME_OVERRIDE="0" rm dlls/olepro32/olepro_t.res make -k dlls/olepro32 md5sum -b dlls/olepro32/olepro_t.res then i always get different MD5 checksum. Marcus, could you send me your dlls/olepro32/Makefile please? What is your distro?

4 3

winetricks alldlls=builtin update based on wine-2.2
by wylda＠volny.cz 20 Feb '17

20 Feb '17

Hi, in case you find it useful... W.

2 1

Re: [PATCH] winemp3.acm: Fixes compilation for older mpg123 library versions
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 19.02.2017 19:54, Bruno Jesus wrote: > From: Bruno Jesus <00cpxxx(a)gmail.com> > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=42483 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winemp3.acm/mpegl3.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/winemp3.acm/mpegl3.c b/dlls/winemp3.acm/mpegl3.c > index 28a1998..100aa49 100644 > --- a/dlls/winemp3.acm/mpegl3.c > +++ b/dlls/winemp3.acm/mpegl3.c > @@ -249,12 +249,14 @@ static LRESULT MPEG3_StreamOpen(PACMDRVSTREAMINSTANCE adsi) > aad->mh = mpg123_new(NULL,&err); > mpg123_open_feed(aad->mh); > > +#ifdef MPG123_IGNORE_INFOFRAME Are you sure this works? On my system it is an enum, not a define. > /* mpg123 may find a XING header in the mp3 and use that information > * to ask for seeks in order to read specific frames in the file. > * We cannot allow that since the caller application is feeding us. > * This fixes problems for mp3 files encoded with LAME (bug 42361) > */ > mpg123_param(aad->mh, MPG123_ADD_FLAGS, MPG123_IGNORE_INFOFRAME, 0); > +#endif > } > /* no encoding yet > else if (adsi->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM && >

2 5

Re: [v2 PATCH 2/2] comctl32/tests: Some tests for property page initialization
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 19.02.2017 19:24, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > Resending, it depends on header change in 1/2. > > dlls/comctl32/tests/propsheet.c | 142 ++++++++++++++++++++++++++++++++++++++++ > include/prsht.h | 1 + > 2 files changed, 143 insertions(+) > > diff --git a/dlls/comctl32/tests/propsheet.c b/dlls/comctl32/tests/propsheet.c > index 7547e793e8..d11fac4bb0 100644 > --- a/dlls/comctl32/tests/propsheet.c > +++ b/dlls/comctl32/tests/propsheet.c > @@ -987,6 +987,147 @@ if (0) > DestroyWindow(hdlg); > } > > +struct custom_proppage > +{ > + union > + { > + PROPSHEETPAGEA pageA; > + PROPSHEETPAGEW pageW; > + } u; > + unsigned int addref_called; > + unsigned int release_called; > +}; > + > +static UINT CALLBACK proppage_callback_a(HWND hwnd, UINT msg, PROPSHEETPAGEA *psp) > +{ > + struct custom_proppage *cpage = (struct custom_proppage *)psp->lParam; > + PROPSHEETPAGEA *psp_orig = &cpage->u.pageA; > + > + ok(hwnd == NULL, "Expected NULL hwnd, got %p\n", hwnd); > + > + ok(psp->lParam && psp->lParam != (LPARAM)psp, "Expected newly allocated page description, got %lx, %p\n", > + psp->lParam, psp); > + ok(psp_orig->pszTitle == psp->pszTitle, "Expected same page title pointer\n"); > + ok(!lstrcmpA(psp_orig->pszTitle, psp->pszTitle), "Expected same page title string\n"); > + > + switch (msg) > + { > + case PSPCB_ADDREF: > + ok(psp->dwSize > PROPSHEETPAGEA_V1_SIZE, "Expected ADDREF for V2+ only, got size %u\n", psp->dwSize); > + cpage->addref_called++; > + break; > + case PSPCB_RELEASE: > + ok(psp->dwSize >= PROPSHEETPAGEA_V1_SIZE, "Unexpected RELEASE, got size %u\n", psp->dwSize); > + cpage->release_called++; > + break; > + default: > + ok(0, "Unexpected message %u\n", msg); > + } > + > + return 1; > +} > + > +static UINT CALLBACK proppage_callback_w(HWND hwnd, UINT msg, PROPSHEETPAGEW *psp) > +{ > + struct custom_proppage *cpage = (struct custom_proppage *)psp->lParam; > + PROPSHEETPAGEW *psp_orig = &cpage->u.pageW; > + > + ok(hwnd == NULL, "Expected NULL hwnd, got %p\n", hwnd); > + ok(psp->lParam && psp->lParam != (LPARAM)psp, "Expected newly allocated page description, got %lx, %p\n", > + psp->lParam, psp); > + ok(psp_orig->pszTitle == psp->pszTitle, "Expected same page title pointer\n"); > + ok(!lstrcmpW(psp_orig->pszTitle, psp->pszTitle), "Expected same page title string\n"); > + > + switch (msg) > + { > + case PSPCB_ADDREF: > + ok(psp->dwSize > PROPSHEETPAGEW_V1_SIZE, "Expected ADDREF for V2+ only, got size %u\n", psp->dwSize); > + cpage->addref_called++; > + break; > + case PSPCB_RELEASE: > + ok(psp->dwSize >= PROPSHEETPAGEW_V1_SIZE, "Unexpected RELEASE, got size %u\n", psp->dwSize); > + cpage->release_called++; > + break; > + default: > + ok(0, "Unexpected message %u\n", msg); > + } > + > + return 1; > +} > + > +static void test_CreatePropertySheetPage(void) > +{ > + static const WCHAR titleW[] = {'T','i','t','l','e',0}; > + struct custom_proppage page; > + HPROPSHEETPAGE hpsp; > + BOOL ret; > + > + memset(&page.u.pageA, 0, sizeof(page.u.pageA)); > + page.u.pageA.dwFlags = PSP_USECALLBACK; > + page.u.pageA.pfnDlgProc = page_dlg_proc_messages; > + page.u.pageA.pfnCallback = proppage_callback_a; > + page.u.pageA.lParam = (LPARAM)&page; > + page.u.pageA.pszTitle = "Title"; > + > + /* Only minimal size validation is performed */ > + for (page.u.pageA.dwSize = PROPSHEETPAGEA_V1_SIZE - 1; page.u.pageA.dwSize <= PROPSHEETPAGEA_V4_SIZE + 1; page.u.pageA.dwSize++) > + { > + page.addref_called = 0; > + hpsp = CreatePropertySheetPageA(&page.u.pageA); > + > + if (page.u.pageA.dwSize < PROPSHEETPAGEA_V1_SIZE) > + todo_wine > + ok(hpsp == NULL, "Expected failure, size %u\n", page.u.pageA.dwSize); > + else > + { > + ok(hpsp != NULL, "Failed to create a page, size %u\n", page.u.pageA.dwSize); > + todo_wine_if(page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) > + ok(page.addref_called == (page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) ? 1 : 0, "Expected ADDREF callback message\n"); > + } > + > + if (hpsp) > + { > + page.release_called = FALSE; It would be better to use 0 when its a counter. > + ret = DestroyPropertySheetPage(hpsp); > + ok(ret, "Failed to destroy a page\n"); > + todo_wine > + ok(page.release_called == 1, "Expected RELEASE callback message\n"); > + } > + } > + > + memset(&page.u.pageW, 0, sizeof(page.u.pageW)); > + page.u.pageW.dwFlags = PSP_USECALLBACK; > + page.u.pageW.pfnDlgProc = page_dlg_proc_messages; > + page.u.pageW.pfnCallback = proppage_callback_w; > + page.u.pageW.lParam = (LPARAM)&page; > + page.u.pageW.pszTitle = titleW; > + > + for (page.u.pageW.dwSize = PROPSHEETPAGEW_V1_SIZE - 1; page.u.pageW.dwSize <= PROPSHEETPAGEW_V4_SIZE + 1; page.u.pageW.dwSize++) > + { > + page.addref_called = 0; > + hpsp = CreatePropertySheetPageW(&page.u.pageW); > + > + if (page.u.pageW.dwSize < PROPSHEETPAGEW_V1_SIZE) > + todo_wine > + ok(hpsp == NULL, "Expected failure, size %u\n", page.u.pageW.dwSize); > + else > + { > + ok(hpsp != NULL, "Failed to create a page, size %u\n", page.u.pageW.dwSize); > + todo_wine_if(page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) Shouldn't it be pageW here? > + ok(page.addref_called == (page.u.pageW.dwSize > PROPSHEETPAGEW_V1_SIZE) ? 1 : 0, "Expected ADDREF callback message\n"); > + } > + > + if (hpsp) > + { > + page.release_called = 0; > + ret = DestroyPropertySheetPage(hpsp); > + ok(ret, "Failed to destroy a page\n"); > + todo_wine > + ok(page.release_called == 1, "Expected RELEASE callback message\n"); > + } > + } > +} > + > START_TEST(propsheet) > { > test_title(); > @@ -998,4 +1139,5 @@ START_TEST(propsheet) > test_messages(); > test_PSM_ADDPAGE(); > test_PSM_INSERTPAGE(); > + test_CreatePropertySheetPage(); > } > diff --git a/include/prsht.h b/include/prsht.h > index f12f402afc..2b2a3e18f3 100644 > --- a/include/prsht.h > +++ b/include/prsht.h > @@ -293,6 +293,7 @@ DECL_PRSHT_TYPE_AW(LPCPROPSHEETPAGE, LATEST) > #define PSP_USEFUSIONCONTEXT 0x00004000 > #define PSP_COMMANDLINKS 0x00040000 > > +#define PSPCB_ADDREF 0 > #define PSPCB_RELEASE 1 > #define PSPCB_CREATE 2 > > -- 2.11.0 >

2 2

Re: Reproducible builds
by wylda＠volny.cz 19 Feb '17

19 Feb '17

> Od: Stefan Dösinger <stefandoesinger(a)gmail.com> > >Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> value and use that consistently. Why are these libraries built >> inconsitently? Is that intentional? An example is attached. > >Have you looked at the .o files of those libraries? Finding the .c file >that introduces the difference might give some hints to pin down the >problem. > Thanks. These "random" value come from: * olepro_t.res * std_ole_v2_t.res * wuapi_tlb_t.res Anyway, all the other folders also have *.res files. Can these 3 be "fixed" so that they behave like the rest of dll-folders? Or can i pass some kind of parameter or switch? Thank you! W.

2 1

Re: [PATCH 4/5] usp10: Iterate in visual order in GPOS_apply_feature().
by Henri Verbeet 19 Feb '17

19 Feb '17

On 19 February 2017 at 18:16, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > In particular, cursive attachment application depends on previous visual order > glyph offsets. Affects e.g. wordpad with Nastaliq fonts. > Actually, ignore this one for the moment, it depends on a few other patches.

1 0

Reproducible builds
by wylda＠volny.cz 19 Feb '17

19 Feb '17

Hi, i wanted to make a reproducible wine builds, so that striped files produce exactly same checksum. To achieve that, I run make that with: export WIDL_TIME_OVERRIDE="0" Anyway, there are 7 files out of 2750 which _always_ pickup some random value and use that consistently. Why are these libraries built inconsitently? Is that intentional? An example is attached. Thanks for hint. W.

2 1

Re: [PATCH 5/5] d3d9/tests: Allow a higher slop for test_updatetexture.
by Marvin 19 Feb '17

19 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28758 Your paranoid android. === w8 (32 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test. === w1064 (32 bit visual) === visual.c:7941: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.
by Marvin 19 Feb '17

19 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28756 Your paranoid android. === w1064 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0