Re: [PATCH xserver 1/2] xwayland: use the lowercase xnf.*alloc API

2017-09-05 Thread Peter Hutterer 
On Mon, Sep 04, 2017 at 03:47:18PM +0100, Emil Velikov wrote:
> Hi Olivier,
> 
> On 30 May 2016 at 08:50, Olivier Fourdan  wrote:
> > Hi Emil,
> >
> > On 29 May 2016 at 12:16, Emil Velikov  wrote:
> >> Can anyone ack/nack this and patch 2/2 ?
> >
> > While at it, could you please also add the XNFreallocarray() I added in the 
> > meantime in xwayland-glamor-xv.c to your patch for xwayland?
> >
> I believe the patch addresses the exact case you've mentioned - for
> reference [1]. That or I've completely failed at git grep :-\
> 
> > Meanwhile for 1/2 and 2/2 in https://patchwork.freedesktop.org/series/5835/
> >
> > Reviewed-by: Olivier Fourdan 
> >
> Thank you. Can anyone push this patch?

done

remote: I: 2 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/xserver
   cdd0352ba..ea82ececb  master -> master

Cheers,
   Peter

> 
> -Emil
> 
> [1] https://patchwork.freedesktop.org/patch/81538/
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC v2 00/10] DRI3 v1.1: modifiers and multi-plane

2017-09-05 Thread Jason Ekstrand 
On Tue, Sep 5, 2017 at 1:01 PM, Jason Ekstrand  wrote:

> I'm pulling down your series and trying to test it all out today.  FYI,
> you have to pass --disable-xwayland or it won't build.
>

I've gotten everything built but it's not working.  It crashes immediately
with the following backtrace:

[   986.456] (EE) Backtrace:
[   986.456] (EE) 0: /home/jason/.local/xorg-ccs/bin/X (OsSigHandler+0x29)
[0x471c79]
[   986.457] (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50)
[0x7f6bf37ba30f]
[   986.457] (EE) 2: /lib64/libc.so.6 (gsignal+0xcb) [0x7f6bf340d66b]
[   986.457] (EE) 3: /lib64/libc.so.6 (abort+0x1b0) [0x7f6bf340f470]
[   986.458] (EE) 4: /lib64/libc.so.6 (__libc_message+0x2f1)
[0x7f6bf34538b1]
[   986.458] (EE) 5: /lib64/libc.so.6 (_int_free+0x3e9) [0x7f6bf345e759]
[   986.458] (EE) 6: /lib64/libc.so.6 (cfree+0x16e) [0x7f6bf34640be]
[   986.459] (EE) 7: /home/jason/.local/xorg-ccs/lib/libdrm.so.2
(drmModeAtomicCommit+0x22c) [
0x7f6bf47c867c]
[   986.459] (EE) 8:
/home/jason/.local/xorg-ccs/lib/xorg/modules/drivers/modesetting_drv.so
(drmmode_crtc_set_fb+0x4e2) [0x7f6beebb9442]
[   986.459] (EE) 9:
/home/jason/.local/xorg-ccs/lib/xorg/modules/drivers/modesetting_drv.so
(drmmode_set_mode_major+0x231) [0x7f6beebba081]
[   986.459] (EE) 10:
/home/jason/.local/xorg-ccs/lib/xorg/modules/drivers/modesetting_drv.so
(drmmode_set_desired_modes+0x137) [0x7f6beebbb417]
[   986.459] (EE) 11: /home/jason/.local/xorg-ccs/bin/X (BlockHandler+0xb1)
[0x440251]
[   986.459] (EE) 12: /home/jason/.local/xorg-ccs/bin/X
(WaitForSomething+0xcd) [0x475f6d]
[   986.459] (EE) 13: /home/jason/.local/xorg-ccs/bin/X (Dispatch+0xb3)
[0x43b733]
[   986.459] (EE) 14: /home/jason/.local/xorg-ccs/bin/X (dix_main+0x378)
[0x43f8b8]
[   986.460] (EE) 15: /lib64/libc.so.6 (__libc_start_main+0xea)
[0x7f6bf33f74da]
[   986.460] (EE) 16: /home/jason/.local/xorg-ccs/bin/X (_start+0x2a)
[0x42a5ba]


> On Tue, Aug 29, 2017 at 9:45 PM, Louis-Francis Ratté-Boulianne <
> l...@collabora.com> wrote:
>
>> Hi,
>>
>> This is the RFC v2 for DRI3 v1.1 (minus the DMA fence part of it). For
>> context, please see:
>>
>> https://lists.x.org/archives/xorg-devel/2017-June/053854.html
>>
>> The main changes apart from bug fixes and cleanup are:
>>
>>  - DRI3 advertised version is not bumped in this serie. It will wait
>>for all the functions to be implemented (i.e. DMA fences).
>>
>>  - Don't use a new DRM format type but just old dumb depth/bpp when
>>creating a pixmap and requesting supported modifiers. That also means
>>that DRI3 GetSupportedFormats is no longer needed.
>>
>>  - Use GBM instead of relying on EGL extension to create multi-planes
>>pixmaps.
>>
>> The Git repositories containing all of these changes and related ones are
>> (branch: rfc/2017-08/dri3-v1.1)
>>
>> git://git.collabora.com/git/user/lfrb/dri3proto
>> git://git.collabora.com/git/user/lfrb/xcb-proto
>> git://git.collabora.com/git/user/lfrb/mesa
>> git://git.collabora.com/git/user/lfrb/xserver
>>
>> I will appreciate any comment to make it better!
>>
>> Thanks,
>> Louis-Francis
>>
>> --
>> 2.13.0
>>
>> ___
>> xorg-devel@lists.x.org: X.Org development
>> Archives: http://lists.x.org/archives/xorg-devel
>> Info: https://lists.x.org/mailman/listinfo/xorg-devel
>
>
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC v2 00/10] DRI3 v1.1: modifiers and multi-plane

2017-09-05 Thread Jason Ekstrand 
I'm pulling down your series and trying to test it all out today.  FYI, you
have to pass --disable-xwayland or it won't build.

On Tue, Aug 29, 2017 at 9:45 PM, Louis-Francis Ratté-Boulianne <
l...@collabora.com> wrote:

> Hi,
>
> This is the RFC v2 for DRI3 v1.1 (minus the DMA fence part of it). For
> context, please see:
>
> https://lists.x.org/archives/xorg-devel/2017-June/053854.html
>
> The main changes apart from bug fixes and cleanup are:
>
>  - DRI3 advertised version is not bumped in this serie. It will wait
>for all the functions to be implemented (i.e. DMA fences).
>
>  - Don't use a new DRM format type but just old dumb depth/bpp when
>creating a pixmap and requesting supported modifiers. That also means
>that DRI3 GetSupportedFormats is no longer needed.
>
>  - Use GBM instead of relying on EGL extension to create multi-planes
>pixmaps.
>
> The Git repositories containing all of these changes and related ones are
> (branch: rfc/2017-08/dri3-v1.1)
>
> git://git.collabora.com/git/user/lfrb/dri3proto
> git://git.collabora.com/git/user/lfrb/xcb-proto
> git://git.collabora.com/git/user/lfrb/mesa
> git://git.collabora.com/git/user/lfrb/xserver
>
> I will appreciate any comment to make it better!
>
> Thanks,
> Louis-Francis
>
> --
> 2.13.0
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] squash! sync: Convert from "CARD64" to int64_t. (v2)

2017-09-05 Thread Eric Anholt 
Pekka Paalanen  writes:

> [ Unknown signature status ]
> On Fri,  1 Sep 2017 11:55:15 -0700
> Eric Anholt  wrote:
>
>> ---
>> 
>> Pekka - that link didn't help, because we still need a correct
>> "result" value.  I don't believe that the compiler could break uint ->
>> int conversions with the high bit, but here's the patch I think we
>> would need for that.  I still think v1 is the better version.
>
> Hi,
>
> sorry, but I'm confused. What is the correct "result" value in case of
> an overflow?

The 2s complement addition/subtraction result.

>>  include/misc.h | 21 +++--
>>  1 file changed, 15 insertions(+), 6 deletions(-)
>> 
>> diff --git a/include/misc.h b/include/misc.h
>> index 0feeaebc7c1a..fc1a55dac343 100644
>> --- a/include/misc.h
>> +++ b/include/misc.h
>> @@ -327,13 +327,21 @@ bswap_32(uint32_t x)
>>  static inline Bool
>>  checked_int64_add(int64_t *out, int64_t a, int64_t b)
>>  {
>> -int64_t result = a + b;
>> +/* Note that overflow behavior with signed ints in C is undefined,
>> + * and the compiler might optimize our check away if we do so.  In
>> + * the discussion about it, people raised the concern that even
>> + * casting from uint to int would be undefined, so we stick with
>> + * all of our math in uint and memcpy the result, out of extreme
>> + * paranoia.
>> + */
>> +uint64_t result = (uint64_t)a + (uint64_t)b;
>>  /* signed addition overflows if operands have the same sign, and
>>   * the sign of the result doesn't match the sign of the inputs.
>>   */
>> -Bool overflow = (a < 0) == (b < 0) && (a < 0) != (result < 0);
>> +Bool result_negative = (result & (1ull << 63)) != 0;
>> +Bool overflow = (a < 0) == (b < 0) && (a < 0) != result_negative;
>>  
>> -*out = result;
>> +memcpy(out, , sizeof(result));
>
> You might hate the memcpy() and so do I, but better ideas seem scarce.
>
> One might be a union { int64_t; uint64_t; } for the "casting".
>
> Another would be to write the code any way you please, but add a test
> that ensures the possibly-not-guaranteed behaviour you rely on is
> actually there and correct.
>
> This is more of a learning experience for me as well, than already
> knowing what's a good way.

I already wrote the unit test, it's in patch 5 that we're replying to.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel