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

Re: [09/23] wined3d: Fix mapping of SV_VertexID to gl_VertexID.
by Henri Verbeet Nov. 14, 2016

Nov. 14, 2016

On 13 November 2016 at 19:35, Andrew Wesie <awesie(a)gmail.com> wrote: > @@ -481,7 +481,7 @@ void wined3d_cs_emit_draw(struct wined3d_cs *cs, int base_vertex_idx, unsigned i > > op = cs->ops->require_space(cs, sizeof(*op)); > op->opcode = WINED3D_CS_OP_DRAW; > - op->base_vertex_idx = base_vertex_idx; > + op->base_vertex_idx = indexed ? base_vertex_idx : 0; This change seems questionable. Why is it needed? > @@ -1988,7 +1988,11 @@ void CDECL wined3d_device_set_base_vertex_index(struct wined3d_device *device, I > { > TRACE("device %p, base_index %d.\n", device, base_index); > > - device->update_state->base_vertex_index = base_index; > + if (device->update_state->base_vertex_index != base_index) > + { > + device->update_state->base_vertex_index = base_index; > + device_invalidate_state(device, STATE_BASEVERTEXINDEX); > + } > } This should happen in wined3d_cs_exec_draw(). (The background is that we're working on executing that on a different thread, and state invalidation should generally happen in that same thread.) > @@ -1424,6 +1425,12 @@ static void shader_glsl_load_constants(void *shader_priv, struct wined3d_context > checkGLcall("glUniform4fv"); > } > > + if (update_mask & WINED3D_SHADER_CONST_BASE_VERTEX) > + { > + GL_EXTCALL(glUniform1i(prog->vs.base_vertex_location, state->base_vertex_index)); > + checkGLcall("glUniform1i"); > + } > @@ -1793,7 +1800,8 @@ static void shader_glsl_declare_generic_vertex_attribute(struct wined3d_string_b > > if (e->sysval_semantic == WINED3D_SV_VERTEX_ID) > { > - shader_addline(buffer, "vec4 vs_in%u = vec4(intBitsToFloat(gl_VertexID), 0.0, 0.0, 0.0);\n", > + shader_addline(buffer, "uniform int base_vertex;\n"); > + shader_addline(buffer, "vec4 vs_in%u = vec4(intBitsToFloat(gl_VertexID - base_vertex), 0.0, 0.0, 0.0);\n", > index); > return; > } Does this do the right thing when ARB_draw_elements_base_vertex is not supported?

1 0

Re: [00/23] Fixes to support Overwatch
by Matteo Bruni Nov. 14, 2016

Nov. 14, 2016

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > This is the first set of patches to support running Overwatch under WINE. > There are additional patches necessary but I am still preparing those for > release. Wow, that's very cool! Thank you for your work! You can expect your patches to be reviewed over the next few days and get either sign-offs or comments about things to improve. Going forward, in general I suggest you to limit your patch series to 5 patches or so (depending on how it makes the most sense), it makes it easier to the reviewers. I'm going to reply to a few patches in your series with the things I noticed at a quick look...

2 1

Re: [PATCH] wined3d: Add Polaris GPUs and their driver.
by Henri Verbeet Nov. 14, 2016

Nov. 14, 2016

On 13 November 2016 at 23:10, Grazvydas Ignotas <notasas(a)gmail.com> wrote: > - {HW_VENDOR_AMD, CARD_AMD_RADEON_R9, "AMD Radeon R9 290", DRIVER_AMD_R600, 4096}, > + {HW_VENDOR_AMD, CARD_AMD_RADEON_R9, "AMD Radeon R9 290", DRIVER_AMD_RX, 4096}, Is that change intentional?

2 4

Re: [PATCH v2] hidclass.sys: Handle POP and PUSH in device descriptors
by Sebastian Lackner Nov. 14, 2016

Nov. 14, 2016

On 14.11.2016 15:08, Aric Stewart wrote: > + if (!list_empty(&caps_stack)) > + { > + struct caps_stack *entry, *cursor; > + ERR("%i unpopped device caps on the stack\n", list_count(&caps_stack)); > + LIST_FOR_EACH_ENTRY_SAFE(entry, cursor, &caps_stack, struct caps_stack, entry) > + list_remove(&entry->entry); I assume you also wanted to deallocate the remaining blocks? > + }

2 1

Status of HID in Wine
by Aric Stewart Nov. 14, 2016

Nov. 14, 2016

Hello everyone, So with this the last few commits I can officially say that WINE now has a fully functioning HID stack for Linux hidraw devices. Thanks to Sebastian Lackner and Alexandre for all the help, reviews and attention paid. It is working and in the state it is now because of their assistance. This means that applications that use hid.dll or direct device access to HID devices will start seeing and being able to interact with devices. This is very exciting but is just the very first step. Of course any application trying to do HID directly would be a wonderful test case, I am sure there are many many things that will need to be refined and added before a real application starts being happy. I do have a very rough, quick, poorly coded test case for HID controllers available to the curious. https://www.codeweavers.com/xfer/aric/HID/hid.exe There are still manual steps required before things will start working. 1) By default no hidraw devices on Linux are given any access to users. So you will need to had rw permission to the /dev/hidraw<X> device that you want to have accessible in Wine. Or if you want to be wild and crazy you can add a new udev rule to add permission to all the devices as they are added. 2) The winebus service is not started by default yet. so you will need to start winebus. (wine net start winebus) This makes things a little complicated. I would recommend testing with a process like this: wine cmd net start winebus <test application> Or you an change the service start for winebus in the registry [System\\CurrentControlSet\\Services\\WineBus] "Start"=dword:00000002 I would love comment, reports, anything as people test various devices and programs. As for more platforms, patches for OS/X have just been submitted so that IOHID devices will work on Mac. Then I have a set of patches adding linux event devices as well. Looking forward, the hope is that then we will be able to build RawInput support on top of HID, and also dinput and xinput support as well. As a fun challenge I have been working to get native dinput from DirectX 9 to work on Wine on top of HID and it is moving forward much better than I expect, with a lot of hacks at present. (native Dinput sees the gamepads and even start trying to read them, but current is not getting reports properly) So tell me how things work! thanks, -aric

2 2

Re: uiautomationcore: add stub dll, with UiaClientsAreListening
by Sebastian Lackner Nov. 14, 2016

Nov. 14, 2016

On 10.11.2016 08:39, Austin English wrote: > +@ stub UiaClientsAreListening You forgot to add the function to the spec file. Regards, Sebastian

1 0

Re: [PATCH] hidclass.sys: Handle POP and PUSH in device descriptors
by Nikolay Sivov Nov. 14, 2016

Nov. 14, 2016

> + if (list_count(&caps_stack)) > + { > + struct caps_stack *entry, *cursor; > + ERR("%i unpopped device caps on the stack\n", list_count(&caps_stack)); > + LIST_FOR_EACH_ENTRY_SAFE(entry, cursor, &caps_stack, struct caps_stack, entry) > + list_remove(&entry->entry); > + } > + If you only want to check if there's any elements left, it's faster to do list_empty().

1 0

Re: [PATCH 2/4] include: Add d3d11 error codes.
by Henri Verbeet Nov. 14, 2016

Nov. 14, 2016

On 14 November 2016 at 00:26, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +cpp_quote("#define _FACD3D11 (0x87c)") Does that really need a cpp_quote()?

1 0

Re: [PATCH 1/4] ddraw: Use wined3d_device_process_vertices for execute buffers (v2).
by Henri Verbeet Nov. 14, 2016

Nov. 14, 2016

On 13 November 2016 at 22:12, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -627,29 +544,58 @@ static HRESULT WINAPI d3d_execute_buffer_Unlock(IDirect3DExecuteBuffer *iface) > static HRESULT WINAPI d3d_execute_buffer_SetExecuteData(IDirect3DExecuteBuffer *iface, D3DEXECUTEDATA *data) ... > + memcpy(&buffer->data, data, data->dwSize); It's not a new issue, but should be blindly accept "dwSize" here?

1 0

Re: [v2] cmd: Command chain fixes
by Hugh McMaster Nov. 14, 2016

Nov. 14, 2016

On Monday, 14 November 2016 6:42 AM, Flávio J. Saraiva wrote: > I'd like to cancel/recall this patch, which is a partial fix. > > I have detected many issues that can't be properly fixed until the > parsing stage is redone, such as this one, so it's better to only > tackle them after redoing the parsing stage. > > I wanted to keep the tests, but didn't understand how to properly add > them as TODOs. (if it's even possible) Tests in cmd.exe can be marked as todo_wine by using the syntax @todo_wine@ at the start of the relevant line. The wiki page on cmd conformance tests has more information. [1] Thanks for working on this area. Hugh [1] https://wiki.winehq.org/Cmd_Conformance_Tests

1 0