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

Re: [PATCH 3/3] windowscodecs: Use source palette if it wasn't specified earlier for PNG frame
by Dmitry Timoshkov 27 Jan '17

27 Jan '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -1765,6 +1765,18 @@ static HRESULT WINAPI PngFrameEncode_WriteSource(IWICBitmapFrameEncode *iface, > > if (SUCCEEDED(hr)) > { > + if (This->colors == 0) > + { > + IWICPalette *palette; > + > + if (SUCCEEDED(PaletteImpl_Create(&palette))) > + { > + if (SUCCEEDED(IWICBitmapSource_CopyPalette(pIBitmapSource, palette))) > + IWICBitmapFrameEncode_SetPalette(iface, palette); > + IWICPalette_Release(palette); > + } > + } > + > hr = write_source(iface, pIBitmapSource, prc, > This->format->guid, This->format->bpp, This->width, This->height); > } What is this for? It looks like a workaround for a WIC converter bug. I'd like to see a test case for this behaviour. -- Dmitry.

1 0

Re: [PATCH 1/3] windowscodecs: Implement IWICBitmapFrameEncode::SetPalette in PNG encoder.
by Dmitry Timoshkov 27 Jan '17

27 Jan '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > From: Dmitry Timoshkov <dmitry(a)baikal.ru> ... > diff --git a/dlls/windowscodecs/tests/converter.c b/dlls/windowscodecs/tests/converter.c > index 2af985785c..9da82f1665 100644 > --- a/dlls/windowscodecs/tests/converter.c > +++ b/dlls/windowscodecs/tests/converter.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "objbase.h" > #include "wincodec.h" > +#include "wincodecsdk.h" > #include "wine/test.h" > > typedef struct bitmap_data { > @@ -577,6 +578,50 @@ struct setting { > void *value; > }; > > +#define EXPECT_REF(obj,ref) _expect_ref((IUnknown*)obj, ref, __LINE__) > +static void _expect_ref(IUnknown* obj, ULONG ref, int line) I'd prefer to avoid getting a credit for the code I never had written. -- Dmitry.

1 0

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings (fwd)
by Julia Lawall 27 Jan '17

27 Jan '17

Check the type of seg on line 267. julia ---------- Forwarded message ---------- Date: Thu, 26 Jan 2017 05:24:40 +0800 From: kbuild test robot <fengguang.wu(a)intel.com> To: kbuild(a)01.org Cc: Julia Lawall <julia.lawall(a)lip6.fr> Subject: Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings In-Reply-To: <20170125202353.101059-6-ricardo.neri-calderon(a)linux.intel.com> Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.10-rc5 next-20170125] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/x86-Enable-User-Mode-… :::::: branch date: 51 minutes ago :::::: commit date: 51 minutes ago >> arch/x86/lib/insn-kernel.c:267:6-9: WARNING: Unsigned expression compared with zero: seg < 0 git remote add linux-review https://github.com/0day-ci/linux git remote update linux-review git checkout 574de0de238ef30c816985006f02f7a1dbba92aa vim +267 arch/x86/lib/insn-kernel.c 574de0de Ricardo Neri 2017-01-25 251 addr = (seg << 4) + regs_get_register(regs, addr_offset1); 574de0de Ricardo Neri 2017-01-25 252 } else { 574de0de Ricardo Neri 2017-01-25 253 ret = get_reg_offset_16(insn, regs, &addr_offset1, 574de0de Ricardo Neri 2017-01-25 254 &addr_offset2); 574de0de Ricardo Neri 2017-01-25 255 if (ret < 0) 574de0de Ricardo Neri 2017-01-25 256 goto out_err; 574de0de Ricardo Neri 2017-01-25 257 /* 574de0de Ricardo Neri 2017-01-25 258 * Don't fail on invalid offset values. They might be invalid 574de0de Ricardo Neri 2017-01-25 259 * because they are not supported. Instead, use them in the 574de0de Ricardo Neri 2017-01-25 260 * calculation only if they contain a valid value. 574de0de Ricardo Neri 2017-01-25 261 */ 574de0de Ricardo Neri 2017-01-25 262 if (addr_offset1 >= 0) 574de0de Ricardo Neri 2017-01-25 263 addr1 = regs_get_register(regs, addr_offset1); 574de0de Ricardo Neri 2017-01-25 264 if (addr_offset2 >= 0) 574de0de Ricardo Neri 2017-01-25 265 addr2 = regs_get_register(regs, addr_offset2); 574de0de Ricardo Neri 2017-01-25 266 seg = __get_segment_selector_16(regs, insn, addr_offset1); 574de0de Ricardo Neri 2017-01-25 @267 if (seg < 0) 574de0de Ricardo Neri 2017-01-25 268 goto out_err; 574de0de Ricardo Neri 2017-01-25 269 addr = (seg << 4) + addr1 + addr2; 574de0de Ricardo Neri 2017-01-25 270 } 574de0de Ricardo Neri 2017-01-25 271 addr += insn->displacement.value; 574de0de Ricardo Neri 2017-01-25 272 574de0de Ricardo Neri 2017-01-25 273 return (void __user *)addr; 574de0de Ricardo Neri 2017-01-25 274 out_err: 574de0de Ricardo Neri 2017-01-25 275 return (void __user *)-1; --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 1

Re: comctl32: Move prototype to header
by Sebastian Lackner 26 Jan '17

26 Jan '17

On 27.01.2017 00:26, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/comctl32/comctl32.h | 1 + > dlls/comctl32/syslink.c | 2 -- > 2 files changed, 1 insertion(+), 2 deletions(-) > Any specific reason that you don't use include/shlwapi.h ?

2 1

Re: msvideo.dll16: Implement DrawDibProfileDisplay
by Alexandre Julliard 26 Jan '17

26 Jan '17

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -35,7 +35,7 @@ > 111 stub DRAWDIBCHANGEPALETTE > 112 pascal -ret16 DrawDibRealize(word word word) DrawDibRealize16 > 113 stub DRAWDIBTIME > -114 stub DRAWDIBPROFILEDISPLAY > +114 pascal -ret16 DrawDibProfileDisplay(segptr) DrawDibProfileDisplay16 segptr is not correct if you pass the pointer to 32-bit code. -- Alexandre Julliard julliard(a)winehq.org

3 3

Performance Testing Wine-1.2-rc4 vs Wine-1.8
by Stefan Dösinger 26 Jan '17

26 Jan '17

Hi, After more than a year of break I ran my Wine benchmarking scripts again on one of my two test machines: The iMac5.1 box with a Radeon X1600 GPU. You can see the results and the comparison to the last regular run here: http://openbenchmarking.org/result/1701170-RI-UPDATETES12,1512236-GA-WINE18… The one game that jumps out is Trackmania Nations. It apparently regressed from approx. 32 fps to 24. I will run a bisect in the next days to pinpoint the patch that caused this. The game itself wasn't updated. Other than TMNations there is nothing too surprising. 3DMark2000 and 2001 are slightly slower, Half Life 2 (which surprisingly didn't seem to be changed by Valve since December 2015) is slightly faster. Unigine Heaven, UT2004 and World in Conflict are unchanged. As you can see in the results I updated the kernel, Mesa and Wine separately to see where changes come from (stable interfaces ftw!). The oldkernel_oldmesa_oldwine result differs from the 2015 one in the general update of the system (KDE Desktop, X server, DDX driver, etc). Unfortunately this old machine is the less interesting one of my two test boxes. I still don't have a monitor for my Radeon HD 5700 Desktop. I ordered one a while ago and it should arrive soon. If I have time I'll try to run the tests next week. Cheers, Stefan

2 4

Re: [PATCH] hidclass.sys: When processing reads fill all the buffers
by Sebastian Lackner 26 Jan '17

26 Jan '17

On 26.01.2017 13:57, Aric Stewart wrote: > This is a follow-up fix for continuing work on bug 42225 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hidclass.sys/buffer.c | 34 +++++++++++++++++++++++++++++++++- > dlls/hidclass.sys/device.c | 2 +- > dlls/hidclass.sys/hid.h | 3 ++- > 3 files changed, 36 insertions(+), 3 deletions(-) > > > > 0001-hidclass.sys-When-processing-reads-fill-all-the-buffer.txt > > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 0b29f97b69..41bbb8e241 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -127,7 +127,7 @@ NTSTATUS RingBuffer_SetSize(struct ReportRingBuffer *ring, UINT size) > return STATUS_SUCCESS; > } > > -void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +void RingBuffer_ReadNew(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > { > void *ret = NULL; > > @@ -155,6 +155,38 @@ void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UI > } > } > > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +{ > + int pointer = ring->pointers[index]; > + void *ret = NULL; > + > + EnterCriticalSection(&ring->lock); > + if (index >= ring->pointer_alloc || ring->pointers[index] == POINTER_UNUSED > + || ring->end == ring->start) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + return; > + } > + > + if (pointer == ring->end) > + pointer--; > + > + if (pointer < 0) > + pointer = ring->size - 1; > + > + ret = &ring->buffer[pointer * ring->buffer_size]; > + memcpy(output, ret, ring->buffer_size); > + if (pointer == ring->pointers[index]) > + { > + ring->pointers[index]++; > + if (ring->pointers[index] == ring->size) > + ring->pointers[index] = 0; > + } > + LeaveCriticalSection(&ring->lock); > + *size = ring->buffer_size; Have you been able to reproduce a similar behavior on Windows? The new code looks very suspicious and I'm not sure if this is the right approach to fix it. Also please note that this will effectively disable any asynchronous Read requests - HID_Device_read() will always use the first code path when there is at least one package in the ring buffer and never return STATUS_PENDING. > +} > + > UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > { > UINT idx; > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index b241016e72..d6a0a358e3 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -662,7 +662,7 @@ NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > ptr = PtrToUlong( irp->Tail.Overlay.OriginalFileObject->FsContext ); > > irp->IoStatus.Information = 0; > - RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + RingBuffer_ReadNew(ext->ring_buffer, ptr, packet, &buffer_size); > > if (buffer_size) > { > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index adc547cc43..1829319ccf 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -62,7 +62,8 @@ typedef struct _BASE_DEVICE_EXTENSION { > void RingBuffer_Write(struct ReportRingBuffer *buffer, void *data) DECLSPEC_HIDDEN; > UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; > -void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +void RingBuffer_ReadNew(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > UINT RingBuffer_GetSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > > >

2 1

DirectX 12 in Wine
by Gabríel Arthúr Pétursson 25 Jan '17

25 Jan '17

Hi, I am interested on working on getting DirectX 12 support into Wine. Is there anyone currently working towards that goal that I can get in contact with? With that said, what would an appropriate implementation in Wine look like? DirectX 12 on top of Vulkan seems like an obvious choice. The two APIs are very similar, whereas the DirectX 12 programming model deviates significantly from both OpenGL and DirectX 11. Another approach is to leverage wined3d (i.e. OpenGL + extensions). I don't know to what extent wined3d can be used or needs to be changed in order to support DirectX 12, or if it'd be useful at all. Can anyone shed some light on whether this would be a feasible approach? Thanks.

3 3

A couple unrelated issues
by Rafał Mużyło 25 Jan '17

25 Jan '17

Just as the title says, I've got a couple problems/questions that don't have much in common except for "happening in wine". 1. regedit and long REG_BINARY values: the edit control should either be made resizable or scrollable, cause long values just don't fit in the box; as a temporary solution, I've made a hackish patch, that changes the font the control uses (not sure if that's necesarry, but it's just feels more natural to use monospaced font here), makes sure all glyphs get the same space and once the value wraps, if it's a non-integer divide, the last line is correctly placed; 2. alsa/pulseaudio and stream recovery: as in the past, it's hard to tell if it's wine or the underlaying stuff that fails; the problem I'm hearing is that apps sometimes without any apparent reason (as CPU usage isn't all that different than the average) go into '(snd_pcm_recover) underrun occurred' mode and start playing the sounds on much higher rate and then just as randomly (as it's again seemingly not related to CPU usage) recover; it's the randomness that bothers me: both going into the state *and* not recovering for several minutes; would it be possible, if not outright fix that, then for example add a helper app, that the user could manually trigger to force recovery ? 3. err:ntdll:RtlpWaitForCriticalSection wait timed out in thread <nr>, blocked by <nr>, retrying (60 sec): this is an annoyance, sometimes a major one; namely, it happens that I terminate an app by pressing ^C; usually, that works just fine, but every now and then app goes into that unterminatable state and not for those 60 sec (which is horribly long anyway), but pretty much indefinitelly; it really shouldn't do that; this requires a taskmgr or wineboot intervention to close it 4. (somewhat related to the previous) taskmgr could use a little enhancement: when running several apps with the same executable name, it's very hard to tell (impossible ?) how a line from process tab relates to application tab; usually it's not much of a problem, but if point 3 strikes, there's no more entry in the app tab, but the process is still there and you need to guess, which will often be wrong; perhaps the entries in the process tab should print the app name or have an option in the context menu to retrieve it ?

4 6

Re: [PATCH 3/7] d3d11/tests: Add test for interleaved Draw() and Dispatch() calls.
by Henri Verbeet 25 Jan '17

25 Jan '17

On 25 January 2017 at 11:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d11/tests/d3d11.c | 186 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 186 insertions(+) > This fails here: d3d11.c:1310: Feature level 0xb000. d3d11.c:6487: Tests skipped: Some AMD drivers have a bug affecting the test. d3d11.c:10104: Compute shader support via SM4 0x1. d3d11.c:11197: Optional format 0x59 - display supported, feature level 0xa100. d3d11.c:11197: Optional format 0x59 - display supported, feature level 0xa000. d3d11.c:12628: Test failed: Got 0x00000000, expected 0xffffffff at (0, 0), sub-resource 0. d3d11: 7402 tests executed (0 marked as todo, 1 failure), 1 skipped. It also takes a long time to run; it might be hanging the GPU.

2 1