March 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 1/4] xmllite/writer: Handle initial and ready states in the rest of tested Write* methods
by Dmitry Timoshkov March 24, 2016

March 24, 2016

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + switch (This->state) > + { > + case XmlWriterState_Initial: > + return E_UNEXPECTED; > + case XmlWriterState_DocClosed: > + return WR_E_INVALIDACTION; > + default: > + ; > + } What's wrong with explicit 'break;' instead of weird ';'? -- Dmitry.

1 0

Re: oleaut32: add OleLoadPictureFile stub (try 2)
by Dmitry Timoshkov March 24, 2016

March 24, 2016

Austin English <austinenglish(a)gmail.com> wrote: > -422 stub OleLoadPictureFile > +422 stdcall OleLoadPictureFile(long ptr) ... > +HRESULT WINAPI OleLoadPictureFile(VARIANT file, LPDISPATCH *picture) > +{ > + FIXME("(%p),stub!\n", picture); > + return E_NOTIMPL; > +} Is passing VARIANT by value supposed to be represented like this in a .spec file? -- Dmitry.

2 1

Re: oleaut32: add OleLoadPictureFile stub
by Andrew Eikum March 24, 2016

March 24, 2016

> + * OleLoadPictureFile (OLEAUT32.422) > + */ > +HRESULT WINAPI OleLoadPictureFile(VARIANT file, LPDISPATCH *picture) > +{ > + FIXME("(%p),stub!\n", picture); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +/*********************************************************************** This should return an HRESULT, right? Probably E_NOTIMPL. Andrew

2 1

Re: [v2] d3d9: Add test for D3DFMT_L8 format as render target.
by Henri Verbeet March 23, 2016

March 23, 2016

On 23 March 2016 at 17:17, Paul Gofman <gofmanp(a)gmail.com> wrote: > @@ -11295,10 +11296,10 @@ static void pixelshader_blending_test(void) > /* Quad with R=0x10, G=0x20 */ > quad1[] = > { > - {{-1.0f, -1.0f, 0.1f}, 0x80102000}, > - {{-1.0f, 1.0f, 0.1f}, 0x80102000}, > - {{ 1.0f, -1.0f, 0.1f}, 0x80102000}, > - {{ 1.0f, 1.0f, 0.1f}, 0x80102000}, > + {{-1.0f, -1.0f, 0.1f}, 0x80103000}, > + {{-1.0f, 1.0f, 0.1f}, 0x80103000}, > + {{ 1.0f, -1.0f, 0.1f}, 0x80103000}, > + {{ 1.0f, 1.0f, 0.1f}, 0x80103000}, > }, The patch looks fine at first sight, but you should probably either update the comment or just remove it.

1 0

XInput and HID - architecture
by Juan Jose Gonzalez March 23, 2016

March 23, 2016

Hi, I got a bit stuck and would like to hear your opinion on the XInput HID backend, specifically on the mappings, i.e. the code that "accepts" a certain device based on its properties and then maps its buttons and axes to XInput buttons and axes. As long as the mappings are fixed, i.e. are not supposed to be extended or edited by the user, everything can be compiled into xinput1_3.dll. However, I would like to provide a "xinput.cpl" control panel node for xinput similar to "joy.cpl", where the user can not only test the XInput gamepads, but also manage the XInput-HID backend mappings. The first part can be accomplished by using xinput1_3.dll. However, in order to load and persist different mappings, the second part requires access to the functions that serialize and deserialize the mappings. It also needs some way of getting raw capabilities and changes in HID devices in order to be able to create new mappings. Here are some possible ways of solving it: * Extend xinput1_3.dll with the required management functions and add a "wine/xinput_hid_mgmt.h" or similar header that declares those methods. xinput.cpl could then simply use xinput1_3.dll to perform all management functions. I'm not sure if this would break anything due to the additional exports in the dll. * Extract the mapping load and store logic into a separate "xinputhid.dll" or similar. I this case both xinput1_3.dll and xinput.cpl would access this library to load and store mappings. * Move the xinput core and backends into a driver and let xinput1_3.dll access it via IOCTLs. I believe this is the way it works on windows, although there doesn't seem to be any freely available documentation regarding the internal architecture. The XInput-HID backend could then create its own kernel object as a management interface, which could be accessed by xinput.cpl. This would have the added effect of having a single instance managing the xinput devices if several programs are running at the same time, which mimics the behavior of windows. What do you think would be the best option? Is there another way I haven't mentioned? - Juan

6 24

Re: [PATCH 2/5] d3d11/tests: Add test for ClearRenderTargetView().
by Marvin March 23, 2016

March 23, 2016

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=21619 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/5] d3d10core/tests: Add test for ClearRenderTargetView().
by Marvin March 23, 2016

March 23, 2016

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=21618 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/4] xmllite/writer: Fix WriteEndElement()/WriteFullEndElement() on ready state
by Marvin March 23, 2016

March 23, 2016

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=21608 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] xmllite/writer: Properly fail on initial state in WriteEndElement()
by Marvin March 23, 2016

March 23, 2016

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=21607 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] xmllite/writer: Fix initial state handling in WriteEndDocument()
by Marvin March 23, 2016

March 23, 2016

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=21606 Your paranoid android. === build (build) === Patch failed to apply

1 0