May 2017 - Wine-Devel - list.winehq.org

Re: [5/8] d3d10core/tests: Add R9G9B9E5_SHAREDEXP to test_texture.

by Józef Kucia

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > + static const DWORD r9g9b9e5_colors[16] = { Please try to put opening brackets on a new line (applies also to the d3d11 version).

May 25, 2017

Re: [PATCH 1/5] d3dx9/tests: Use ARRAY_SIZE in test_D3DXSHEvalDirectionalLight().

by Matteo Bruni

2017-05-23 11:04 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > @@ -2908,7 +2908,7 @@ static void test_D3DXSHEvalDirectionalLight(void) > green_out = test[l].green_in; > blue_out = test[l].blue_in; > > - for (j = 0; j < 49; j++) > + for (j = 0; j < ARRAY_SIZE(red_out); ++j) red_out here is defined as a pointer, not an array.

May 24, 2017

Re: [v5 PATCH 1/3] wined3d: Send texture updates through the command stream.

by Stefan Dösinger

Am 2017-05-24 um 15:49 schrieb Masanori Kakura: > + for (j = 0; j < layer_count; ++j) > + { > + wined3d_cs_emit_blt_sub_resource(cs, > + &dst_texture->resource, j * dst_level_count + i, &box, > + &src_texture->resource, j * src_level_count + i + src_skip_levels, &box, > + 0, NULL, WINED3D_TEXF_POINT); > + } I don't like emitting new operations in the CS handler instead of doing the actual operation. Maybe this can be avoided with some refactoring of wined3d_cs_exec_blt_sub_resource?

May 24, 2017

Re: [v5 PATCH 3/3] wined3d: Update only dirty regions in wined3d_cs_exec_update_texture().

by Marvin

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=31147 Your paranoid android. === w1064 (32 bit visual) === visual.c:8016: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

May 24, 2017

Re: [PATCH v7 04/26] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b

by Borislav Petkov

On Fri, May 05, 2017 at 11:17:02AM -0700, Ricardo Neri wrote: > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software > Developer's Manual volume 2A states that when ModRM.mod !=11b and > ModRM.rm = 100b indexed register-indirect addressing is used. In other > words, a SIB byte follows the ModRM byte. In the specific case of > SIB.index = 100b, the scale*index portion of the computation of the > effective address is null. To signal callers of this particular situation, > get_reg_offset() can return -EDOM (-EINVAL continues to indicate that an > error when decoding the SIB byte). > > An example of this situation can be the following instruction: > > 8b 4c 23 80 mov -0x80(%rbx,%riz,1),%rcx > ModRM: 0x4c [mod:1b][reg:1b][rm:100b] > SIB: 0x23 [scale:0b][index:100b][base:11b] > Displacement: 0x80 (1-byte, as per ModRM.mod = 1b) > > The %riz 'register' indicates a null index. > > In long mode, a REX prefix may be used. When a REX prefix is present, > REX.X adds a fourth bit to the register selection of SIB.index. This gives > the ability to refer to all the 16 general purpose registers. When REX.X is > 1b and SIB.index is 100b, the index is indicated in %r12. In our example, > this would look like: > > 42 8b 4c 23 80 mov -0x80(%rbx,%r12,1),%rcx > REX: 0x42 [W:0b][R:0b][X:1b][B:0b] > ModRM: 0x4c [mod:1b][reg:1b][rm:100b] > SIB: 0x23 [scale:0b][.X: 1b, index:100b][.B:0b, base:11b] > Displacement: 0x80 (1-byte, as per ModRM.mod = 1b) > > Cc: Borislav Petkov <bp(a)suse.de> > Cc: Andy Lutomirski <luto(a)kernel.org> > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > Cc: Colin Ian King <colin.king(a)canonical.com> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Nathan Howard <liverlint(a)gmail.com> > Cc: Adan Hawthorn <adanhawthorn(a)gmail.com> > Cc: Joe Perches <joe(a)perches.com> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > Cc: x86(a)kernel.org > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > --- > arch/x86/mm/mpx.c | 20 ++++++++++++++++++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c > index ebdead8..7397b81 100644 > --- a/arch/x86/mm/mpx.c > +++ b/arch/x86/mm/mpx.c > @@ -110,6 +110,14 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > regno = X86_SIB_INDEX(insn->sib.value); > if (X86_REX_X(insn->rex_prefix.value)) > regno += 8; <--- newline. > + /* > + * If ModRM.mod !=3 and SIB.index (regno=4) the scale*index > + * portion of the address computation is null. This is > + * true only if REX.X is 0. In such a case, the SIB index > + * is used in the address computation. > + */ > + if (X86_MODRM_MOD(insn->modrm.value) != 3 && regno == 4) > + return -EDOM; > break; > > case REG_TYPE_BASE: > @@ -159,11 +167,19 @@ static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs) > goto out_err; > > indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX); > - if (indx_offset < 0) <--- newline. > + /* > + * A negative offset generally means a error, except an > + * -EDOM, which means that the contents of the register > + * should not be used as index. > + */ > + if (indx_offset == -EDOM) > + indx = 0; > + else if (indx_offset < 0) > goto out_err; > + else > + indx = regs_get_register(regs, indx_offset); > > base = regs_get_register(regs, base_offset); > - indx = regs_get_register(regs, indx_offset); > eff_addr = base + indx * (1 << X86_SIB_SCALE(sib)); > } else { > addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM); > -- > 2.9.3 > -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

May 24, 2017

Re: [PATCH] iphlpapi: Implement if_nametoindex.

by Stefan Dösinger

> Am 24.05.2017 um 14:26 schrieb Hans Leidekker <hans(a)codeweavers.com>: > > Why not call ConvertInterfaceNameToLuidA and then ConvertInterfaceLuidToIndex? Hmm, I think I see what you mean now. WGC passes a string like "{00000001-0000-0000-0000-000000000000}“ to if_nametoindex, which I suspect is not what the POSIX function with the same name expects. I think this warrants some tests.

May 24, 2017

Re: [PATCH] iphlpapi: Implement if_nametoindex.

by Bruno Jesus

On Wed, May 24, 2017 at 9:43 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> On Wed, May 24, 2017 at 9:17 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >>> I’m not sure what you mean by "ASCII version“. getInterfaceIndexByName also >>> accepts a const char * rather than a WCHAR *. >> >> I meant a "char* version of GetAdapterIndex", which receives a WCHAR*. > > Calling GetAdapterIndex seems kinda wasteful as well, we’d have to convert to WCHAR, then GetAdapterIndex converts back to char and calls getInterfaceIndexByName, which calls if_nametoindex, which is where we started. No, that was not what I meant. I just said that if_nametoindex is char*, while GetAdapterIndex is a WCHAR*, I didn't say you have to use GetAdapterIndex.

May 24, 2017

Re: [PATCH] iphlpapi: Implement if_nametoindex.

by Bruno Jesus

On Wed, May 24, 2017 at 9:35 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >> Am 24.05.2017 um 14:26 schrieb Hans Leidekker <hans(a)codeweavers.com>: >> >> Why not call ConvertInterfaceNameToLuidA and then ConvertInterfaceLuidToIndex? > Maybe I am missing something, but this looks like an even more elaborate way to implement a function that has a 1:1 match in the native library. ConvertInterfaceNameToLuidA calls getInterfaceIndexByName to do its work. > > Unless I am missing something and we’re doing an elaborate interface number reordering that I can’t find in the code… I believe iphlpapi is split in different source files to try separating the OS (ifenum.c/ifstats.c) code to the unix->windows conversion code (iphlpapi_main.c). That was the idea to reuse the other function from ifenum, if that is not what the file division was meant to mean then your patch is certainly fine ;-)

May 24, 2017

Re: [PATCH] iphlpapi: Implement if_nametoindex.

by Stefan Dösinger

> Am 24.05.2017 um 14:36 schrieb Bruno Jesus <00cpxxx(a)gmail.com>: > > On Wed, May 24, 2017 at 9:17 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> I’m not sure what you mean by "ASCII version“. getInterfaceIndexByName also >> accepts a const char * rather than a WCHAR *. > > I meant a "char* version of GetAdapterIndex", which receives a WCHAR*. Calling GetAdapterIndex seems kinda wasteful as well, we’d have to convert to WCHAR, then GetAdapterIndex converts back to char and calls getInterfaceIndexByName, which calls if_nametoindex, which is where we started.

May 24, 2017

Re: [PATCH 2/2] winex11.drv: Implement clipboard changes tracking using xfixes extension

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > On 05/24/17 14:15, Alexandre Julliard wrote: >> Piotr Caban <piotr(a)codeweavers.com> writes: >> >>> @@ -499,6 +499,7 @@ extern Atom systray_atom DECLSPEC_HIDDEN; >>> typedef BOOL (*x11drv_event_handler)( HWND hwnd, XEvent *event ); >>> extern void X11DRV_register_event_handler( int type, >>> x11drv_event_handler handler, const char *name ) DECLSPEC_HIDDEN; >>> +extern void X11DRV_register_XFixesSelectionNotify( int type ) DECLSPEC_HIDDEN; >> >> Is there a reason you can't use X11DRV_register_event_handler? >> > I didn't find any guarantee that returned event type will be small > enough to fit into the handlers table. In my testing > event_base returned by XFixesQueryExtension was equal to 83. It will fit, 128 is an X protocol limit. -- Alexandre Julliard julliard(a)winehq.org

May 24, 2017