Re: [ANNOUNCE] xorg-server 1.19.99.904

[Adam Jackson]

On Sat, 2018-04-21 at 11:42 +0200, Thomas Klausner wrote:

> Thanks!
> 
> We already had a patch for such a problem with pid_t in pkgsrc, and
> I've extended it to uint32_t, which fixes the problem for me.
> 
> It's attached.
> 
> Let me know if it can go in like this or what else we can do to fix
> this.

Merged this, thanks:

remote: E: failed to find patch for rev 
8275903956d7876519fa55fb805669dc301bf243.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   e29d78327..827590395  master -> master

- ajax
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

On Fri, Apr 20, 2018 at 11:07:04AM -0400, Adam Jackson wrote:
> On Fri, 2018-04-20 at 08:18 +0200, Thomas Klausner wrote:
> 
> > extern __attribute__((visibility("default")))
> > # 112 "../../dri3/dri3.h" 3 4
> > __uint32_t
> > 
> > # 113 "../../dri3/dri3.h"
> > drm_format_for_depth(
> > 
> > 
> >
> > I don't see the problem, do you?
> 
> We're not expecting another #line expansion there.

Thanks!

We already had a patch for such a problem with pid_t in pkgsrc, and
I've extended it to uint32_t, which fixes the problem for me.

It's attached.

Let me know if it can go in like this or what else we can do to fix
this.

Thanks,
 Thomas


patch-hw_xfree86_sdksyms.sh
Description: Bourne shell script
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Adam Jackson]

On Fri, 2018-04-20 at 08:18 +0200, Thomas Klausner wrote:

> extern __attribute__((visibility("default")))
> # 112 "../../dri3/dri3.h" 3 4
> __uint32_t
> 
> # 113 "../../dri3/dri3.h"
> drm_format_for_depth(
> 
> 
>
> I don't see the problem, do you?

We're not expecting another #line expansion there.

- ajax
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

On Wed, Apr 18, 2018 at 10:13:36AM -0500, Jeff Smith wrote:
> Here is something that may help in tracking down the cause of the
> disappearing symbol.
> 1: apply the following changes to sdksyms.sh
> 2: re-run the build
>   (this will output what is being fed into awk from the pre-processor
> into sdksyms.i)
> 3: search for  drm_format_for_depth  in sdksyms.i
>   (if not found, search for dri3_send_open_reply instead)
> 4: post the relevant section of sdksyms.i
> 
> -${CPP:-cpp} "$@" sdksyms.c | ${AWK:-awk} -v topdir=$topdir '
> +${CPP:-cpp} "$@" sdksyms.c | tee sdksyms.i | ${AWK:-awk} -v topdir=$topdir '

Here's the requested data:

typedef struct dri3_screen_info {

# 88 "../../dri3/dri3.h" 3 4
   __uint32_t 
# 88 "../../dri3/dri3.h"
   version;

dri3_open_proc open;
dri3_pixmap_from_fd_proc pixmap_from_fd;
dri3_fd_from_pixmap_proc fd_from_pixmap;


dri3_open_client_proc open_client;


dri3_pixmap_from_fds_proc pixmap_from_fds;
dri3_fds_from_pixmap_proc fds_from_pixmap;
dri3_get_formats_proc get_formats;
dri3_get_modifiers_proc get_modifiers;
dri3_get_drawable_modifiers_proc get_drawable_modifiers;

} dri3_screen_info_rec, *dri3_screen_info_ptr;

extern __attribute__((visibility("default"))) Bool
dri3_screen_init(ScreenPtr screen, const dri3_screen_info_rec *info);

extern __attribute__((visibility("default"))) int
dri3_send_open_reply(ClientPtr client, int fd);

extern __attribute__((visibility("default")))
# 112 "../../dri3/dri3.h" 3 4
__uint32_t

# 113 "../../dri3/dri3.h"
drm_format_for_depth(
# 113 "../../dri3/dri3.h" 3 4
__uint32_t
# 113 "../../dri3/dri3.h"
 depth,
# 113 "../../dri3/dri3.h" 3 4
__uint32_t
# 113 "../../dri3/dri3.h"
 bpp);
# 106 "sdksyms.c" 2
# 120 "sdksyms.c"


I don't see the problem, do you?

The whole .i file is available at

http://danbala.tuwien.ac.at/~wiz/tmp/xdksyms.output.gz

 Thomas
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Jeff Smith]

On Thu, Apr 12, 2018 at 1:18 AM, Thomas Klausner  wrote:
> On Wed, Apr 11, 2018 at 04:24:02PM -0500, Jeff Smith wrote:
>> On Wed, Apr 11, 2018 at 2:44 AM, Thomas Klausner  wrote:
>> > I still see this build failure on NetBSD:
>> >
>> > sdksyms.c:1773:15: error: expected expression before ',' token
>> >  (void *) &,  /* 
>> > ../../dri3/dri3.h:110 */
>> >^
>> >
>> >  Thomas
>> >
>>
>> BTW, because of a line-numbering bug in sdksyms.sh, it is misreporting
>> the relevant header line as dri3.h:110,
>> when it should have reported dri3.h:113 (the line declaring
>> drm_format_for_depth).  I'm limited in what I can
>> test at the moment, and haven't been able to reproduce or see a reason
>> why that line would be a problem.
>
> True, there seems to be a line numbering bug:
>
> (void *) _screen_init,  /* 
> ../../dri3/dri3.h:106 */
> (void *) _send_open_reply,  /* 
> ../../dri3/dri3.h:108 */
> (void *) &,  /* 
> ../../dri3/dri3.h:110 */
>
> and in dri3/dri3.h:
>
>106  extern _X_EXPORT Bool
>107  dri3_screen_init(ScreenPtr screen, const dri3_screen_info_rec *info);
>108
>109  extern _X_EXPORT int
>110  dri3_send_open_reply(ClientPtr client, int fd);
>111
>112  extern _X_EXPORT uint32_t
>113  drm_format_for_depth(uint32_t depth, uint32_t bpp);
>
>> I wonder, is that the only line in sdksyms.c that came out like that,
>> or just the first?
>
> It's the only one.
>  Thomas

Here is something that may help in tracking down the cause of the
disappearing symbol.
1: apply the following changes to sdksyms.sh
2: re-run the build
  (this will output what is being fed into awk from the pre-processor
into sdksyms.i)
3: search for  drm_format_for_depth  in sdksyms.i
  (if not found, search for dri3_send_open_reply instead)
4: post the relevant section of sdksyms.i

-${CPP:-cpp} "$@" sdksyms.c | ${AWK:-awk} -v topdir=$topdir '
+${CPP:-cpp} "$@" sdksyms.c | tee sdksyms.i | ${AWK:-awk} -v topdir=$topdir '

 - Jeff
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

On Wed, Apr 11, 2018 at 04:24:02PM -0500, Jeff Smith wrote:
> On Wed, Apr 11, 2018 at 2:44 AM, Thomas Klausner  wrote:
> > I still see this build failure on NetBSD:
> >
> > sdksyms.c:1773:15: error: expected expression before ',' token
> >  (void *) &,  /* 
> > ../../dri3/dri3.h:110 */
> >^
> >
> >  Thomas
> >
> 
> BTW, because of a line-numbering bug in sdksyms.sh, it is misreporting
> the relevant header line as dri3.h:110,
> when it should have reported dri3.h:113 (the line declaring
> drm_format_for_depth).  I'm limited in what I can
> test at the moment, and haven't been able to reproduce or see a reason
> why that line would be a problem.

True, there seems to be a line numbering bug:

(void *) _screen_init,  /* 
../../dri3/dri3.h:106 */
(void *) _send_open_reply,  /* 
../../dri3/dri3.h:108 */
(void *) &,  /* 
../../dri3/dri3.h:110 */

and in dri3/dri3.h:

   106  extern _X_EXPORT Bool
   107  dri3_screen_init(ScreenPtr screen, const dri3_screen_info_rec *info);
   108  
   109  extern _X_EXPORT int
   110  dri3_send_open_reply(ClientPtr client, int fd);
   111  
   112  extern _X_EXPORT uint32_t
   113  drm_format_for_depth(uint32_t depth, uint32_t bpp);

> I wonder, is that the only line in sdksyms.c that came out like that,
> or just the first?

It's the only one.
 Thomas
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Jeff Smith]

On Wed, Apr 11, 2018 at 2:44 AM, Thomas Klausner  wrote:
> I still see this build failure on NetBSD:
>
> sdksyms.c:1773:15: error: expected expression before ',' token
>  (void *) &,  /* 
> ../../dri3/dri3.h:110 */
>^
>
>  Thomas
>

BTW, because of a line-numbering bug in sdksyms.sh, it is misreporting
the relevant header line as dri3.h:110,
when it should have reported dri3.h:113 (the line declaring
drm_format_for_depth).  I'm limited in what I can
test at the moment, and haven't been able to reproduce or see a reason
why that line would be a problem.

I wonder, is that the only line in sdksyms.c that came out like that,
or just the first?

 - Jeff
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Adam Jackson]

On Wed, 2018-04-11 at 09:44 +0200, Thomas Klausner wrote:
> I still see this build failure on NetBSD:
> 
> sdksyms.c:1773:15: error: expected expression before ',' token
>  (void *) &,  /* 
> ../../dri3/dri3.h:110 */
>^

I'm setting up a netbsd vm to look into this; debugging awk over email
sounded unpleasant.

- ajax
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Olivier Fourdan]

Hey Adam,

On Wed, Apr 11, 2018 at 4:40 PM, Adam Jackson  wrote:

> On Wed, 2018-04-11 at 09:49 +0200, Olivier Fourdan wrote:
>
> > What are the risks of landing it? It would break for hardware/driver
> > which are not supported yet anyway?
>
> The code it adds basically only runs on NVIDIA's drivers, since nobody
> else supports EGL_KHR_streams (as far as I'm aware, at least). Mesa
> doesn't seem to have any interest in adding it, and even if they did
> we'd probably prefer to keep using gbm there as the streams approach is
> intrinsically one more blit, at least as written.
>
> So the risks are low. The benefit is Xwayland could use glamor instead
> of fb. Which you'd think would be a win, as I'm told NVIDIA's GL is
> pretty good. In practice it's kind of a wash at the moment. It's
> possible that's because glamor is doing something naive in its renderer
> or its streams usage, or due to a bug in NVIDIA's driver.
>

Right, and in the worse case (i.e. a bug with EGLstream crashes glamor),
users can set XWAYLAND_NO_GLAMOR to disable glamor support.

So the risks are even lower...

Cheers,
Olivier
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Adam Jackson]

On Wed, 2018-04-11 at 09:49 +0200, Olivier Fourdan wrote:

> What are the risks of landing it? It would break for hardware/driver
> which are not supported yet anyway?

The code it adds basically only runs on NVIDIA's drivers, since nobody
else supports EGL_KHR_streams (as far as I'm aware, at least). Mesa
doesn't seem to have any interest in adding it, and even if they did
we'd probably prefer to keep using gbm there as the streams approach is
intrinsically one more blit, at least as written.

So the risks are low. The benefit is Xwayland could use glamor instead
of fb. Which you'd think would be a win, as I'm told NVIDIA's GL is
pretty good. In practice it's kind of a wash at the moment. It's
possible that's because glamor is doing something naive in its renderer
or its streams usage, or due to a bug in NVIDIA's driver.

- ajax
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Olivier Fourdan]

Hi Adam,

[Re-sending to xorg-devel where this was intended, sorry!]

On 10 April 2018 at 21:57, Adam Jackson  wrote:

> Another batch of cleanups and fixes, mostly in glamor and DRI3.
>
> At this point the only outstanding major feature for 1.20 that hasn't
> landed yet is EGLStreams support for Xwayland. The patches require some
> minor rebasing to account for per-window flips in Present, I'll post
> that momentarily I suppose. I'm honestly of two minds about merging it,
> the deafening silence of review feedback has not been encouraging.
>

FWIW, I actually looked at the patches and did not spot anything wrong at
the time, but I don't have any hardware/driver to actually try it, so I
cannot tell whether or not those are correct, so I did not reply...

What are the risks of landing it? It would break for hardware/driver which
are not supported yet anyway?

Cheers,
Olivier
___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

I still see this build failure on NetBSD:

sdksyms.c:1773:15: error: expected expression before ',' token
 (void *) &,  /* 
../../dri3/dri3.h:110 */
   ^

 Thomas

On Tue, Apr 10, 2018 at 03:57:25PM -0400, Adam Jackson wrote:
> Another batch of cleanups and fixes, mostly in glamor and DRI3.
> 
> At this point the only outstanding major feature for 1.20 that hasn't
> landed yet is EGLStreams support for Xwayland. The patches require some
> minor rebasing to account for per-window flips in Present, I'll post
> that momentarily I suppose. I'm honestly of two minds about merging it,
> the deafening silence of review feedback has not been encouraging.
> 
> Aaron Plattner (1):
>   xfree86: Restore newline before "X Protocol Version" string
> 
> Adam Jackson (10):
>   gtf: Warning fix
>   dmx: Fix some snprintf warnings.
>   dmx: Fix a read-from-uninitialized warning
>   dmx: Clean up some argument parsing code
>   dmx: Silence a string truncation warning.
>   xkb: Silence some compiler warnings
>   mi: Hush an almost certainly bogus warning
>   dix: Hush an almost certainly bogus warning
>   xwayland: Silence a build warning if we can
>   xserver 1.20 RC4
> 
> Daniel Stone (10):
>   dri3: Use single-FD screen call for single-FD request
>   drmmode: Track if BO allocation used modifiers
>   glamor: Track if BO allocation used modifiers
>   glamor: Push make_exportable into callers
>   glamor: Reallocate pixmap storage without modifiers if necessary
>   glamor: Fall back to non-modifier allocations
>   glamor: Add fd_from_pixmap hook
>   modesetting: Don't reuse iterator in nested loop
>   dri3: Set stride and size for old clients
>   modesetting: Actually get framebuffer ID
> 
> Emil Velikov (10):
>   dri3: annotate the dri3_screen_info data as const
>   xwayland: don't close() fds we don't own
>   dri3: annotate fds/strides/offsets arrays as const
>   dri3: simplify dri3_open() implementation
>   xwayland: zero num_modifiers from the start
>   glamor: zero num_modifiers from the start
>   dri3: check for ::get_drawable_modifiers failure
>   xwayland: zero num_formats from the start
>   glamor: zero num_formats from the start
>   dri3: rework format/modifier caching
> 
> Jon Turney (1):
>   hw/xwin/glx: Allocate fbconfigs correctly
> 
> Kyle Brenneman (1):
>   GLX: Fix a use after free error with the GLVND vendor handle.
> 
> Louis-Francis Ratté-Boulianne (2):
>   modesetting: Use atomic modesetting to set DPMS mode
>   modesetting: Have consistent state when using atomic modesetting
> 
> Mario Kleiner (1):
>   modesetting: Fix page flipping harder under DRI 3.2.
> 
> Michal Srb (2):
>   glx: Do not call into Composite if it is disabled.
>   Xext: Fix memory leaks in hashtable.
> 
> Peter Hutterer (1):
>   xfree86: drop KDSKBMUTE handling
> 
> Samuel Thibault (1):
>   dix: always send focus event on grab change
> 
> git tag: xorg-server-1.19.99.904
> 
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.bz2
> MD5:  b7623726287e405ed03b9e27f0811f87  xorg-server-1.19.99.904.tar.bz2
> SHA1: 5bfe19ab814ab8b973c0c4b53547de4e951d3679  
> xorg-server-1.19.99.904.tar.bz2
> SHA256: 0ec3bb260c3798964d413db4238485fca5cab774a9d279c04e5272202f8e58b8  
> xorg-server-1.19.99.904.tar.bz2
> SHA512: 
> b9dccc777d0a30c6b40bddffe1f359dde4103539c6598f04bf8cf5f59e6770229221a199c1866b4eba0cf8d2d87fe878985bbd2e3c6ec5b65e3f16195ea8d57e
>   xorg-server-1.19.99.904.tar.bz2
> PGP:  
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.bz2.sig
> 
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.gz
> MD5:  f5082147af9822ade469f808c420a121  xorg-server-1.19.99.904.tar.gz
> SHA1: c481217424beb1e0f0d38d98dfc4c194a1631354  xorg-server-1.19.99.904.tar.gz
> SHA256: f1fe5e27d0eab494a4eea11a075f8f6d3989c3683c22e0bdf5c060e57d351c0f  
> xorg-server-1.19.99.904.tar.gz
> SHA512: 
> dad39ecc6f8a99a74191d542709d03a14415f1065f8f2c8c68ad87d3fb7c3392eaf3ff97d90827f53d2c16e0e5acbaaa0f3bf580f60615c3f35b40965f23
>   xorg-server-1.19.99.904.tar.gz
> PGP:  
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.gz.sig
> 
> - ajax
> ___
> xorg-announce mailing list
> xorg-annou...@lists.x.org
> https://lists.x.org/mailman/listinfo/xorg-announce
___
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