Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Mike Lothian 
On Tue, 24 Apr 2018 at 09:17 Mario Kleiner 
wrote:

> Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>
> Reason is that the servers DRI3 version is now unconditionally
> reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> do not support the needed hooks like info->pixmap_from_fds or
> info->get_formats, info->get_modifiers. Unfortunately we can't
> simply report the servers DRI3 version as 1.0 in this case, as
> the reported version can not be specific to a X-Screen, and
> different screens may have drivers with different capabilities.
>
> Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap,
> and simply reporting an empty set of supported modifiers for the
> DRI3GetSupportedModifiers request if the ddx doesn't support
> DRI 3.2.
>
> Clients like Mesa 18.1's dri3 loader respond to the empty set
> of reported modifiers by falling back to a dri driver selected
> buffer format (image->createImageWithModifiers responds to a
> NULL modifier_list by acting like ->createImage()). This works,
> but Mesa 18.1 will still try to use the DRI3PixmapFromBuffers
> request to create the corresponding pixmap, just passing in
> a modifier that corresponds to whatever tiling the dri driver
> selected by default. To prevent this request - and thereby
> the client - from failing with a BadImplementation error,
> remove the check for modifier == DRM_MOD_FORMAT_INVALID in
> the pixmap_from_fd fallback path of dri3_pixmap_from_fds()
> and trust that if we hit the fallback path then the client
> will have passed a buffer with some driver specific default
> tiling that can be handled by pixmap_from_fd.
>
> Another approach would be for Mesa's dri3 loader to keep
> track how a buffer was created (with explicit modifiers or
> not), and then call DRI3PixmapFromBuffers or DRI3PixmapFromBuffer,
> but then any future DRI3 client implementation would need to be
> fixed, so the server side is probably the better place for this.
>
> Tested on Intel Ivybridge and NVidia Pascal.
>
> Fixes: 6e7c40f62db6 ("dri3: Add multi-planar/modifier buffer requests")
> Signed-off-by: Mario Kleiner 
> Cc: Daniel Stone 
> Cc: Louis-Francis Ratté-Boulianne 
> ---
>  dri3/dri3_screen.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
> index 23e33f4..243dab7 100644
> --- a/dri3/dri3_screen.c
> +++ b/dri3/dri3_screen.c
> @@ -66,8 +66,7 @@ dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr
> screen,
>  if (info->version >= 2 && info->pixmap_from_fds != NULL) {
>  pixmap = (*info->pixmap_from_fds) (screen, num_fds, fds, width,
> height,
> strides, offsets, depth, bpp,
> modifier);
> -} else if (info->pixmap_from_fd != NULL && num_fds == 1 &&
> -   modifier == DRM_FORMAT_MOD_INVALID) {
> +} else if (info->pixmap_from_fd != NULL && num_fds == 1) {
>  pixmap = (*info->pixmap_from_fd) (screen, fds[0], width, height,
>strides[0], depth, bpp);
>  } else {
> --
> 2.7.4
>
> ___
> 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


Hi Mario

Thanks for fixing this, that's xserver 1.20 working with the Intel and
AMDGPU DDXs on my laptop with Kwin

The plasmashell & steam freezes aren't present with the Intel or AMDGPU
DDXs, only modesetting

I'm quite happy to mark https://bugs.freedesktop.org/show_bug.cgi?id=105851 as
resolved and look into the modesetting freezes seperately

Feel free to add my:

Tested-by: Mike Lothian 

Cheers again

Mike
___
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

[ANNOUNCE] xorg-server 1.19.99.905

2018-04-24 Thread Adam Jackson 
More bugfixes, and streams support for Xwayland. This will almost
certainly be the last RC.

Adam Jackson (10):
  sdksyms: Skip empty symbols
  xwayland: Don't crash on WarpPointer(dest_w = None)
  modesetting: Fix inverted check in dri2 WaitMSC
  animcur: Fix crash when removing a master device
  dix: Factor out extension availability check
  dix: Allow an extension to disable itself
  vnd: Disable GLX if no vendors successfully initialized
  glx: Require depth > 12 for GLX visuals
  vfb: Fix man page in re depth
  xserver 1.20 RC5

Chris Wilson (1):
  os/WaitFor: Check timers on every iteration

Daniel Stone (1):
  dri3: Don't call vfuncs on old DRI3 screens

David Woodhouse (1):
  glamor: fix glamor_xv_query_image_attributes() for odd-width images

Emil Velikov (1):
  configure.ac: make use of wayland-scanner.pc

Lyude Paul (5):
  meson: Ensure we always build Xext/hashtable.c for glx
  meson: Fix indenting in glx/meson.build
  xwayland: Decouple GBM from glamor
  xwayland: Add xwayland-config.h
  xwayland: Add glamor egl_backend for EGLStreams

Mario Kleiner (2):
  dri3: Fix dri3_buffers_from_pixmap request.
  modesetting: Only use modifiers on kms drivers which do support them.

Matt Turner (1):
  modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM

Olivier Fourdan (3):
  xwayland: Fix build without glamor
  xwayland: avoid using freed xwl_window on unrealize
  xwayland: Clean up all frame callbacks

Thomas Klausner (1):
  sdksyms: Cope with __pid_t and __uint32_t

git tag: xorg-server-1.19.99.905

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.bz2
MD5:  9be2bf4bc611789b61fa1073810f1030  xorg-server-1.19.99.905.tar.bz2
SHA1: 03db7ca162a907debb8230e207a02274a711c17e  xorg-server-1.19.99.905.tar.bz2
SHA256: f73c33d70d8b52db142e0d796be98953308f68fb7625084ae15a2d46b5cc628e  
xorg-server-1.19.99.905.tar.bz2
SHA512: 
9a6f173835989f7562debfbadae0077d75e35bfad5be1f78931fe46ac43df20591162950b27e2c813fd857114f98247be28d357566e45e5d3ac6b60873d94466
  xorg-server-1.19.99.905.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.gz
MD5:  bc4df37dc28e97865a7328c8cebf1b56  xorg-server-1.19.99.905.tar.gz
SHA1: 067fccc3687711a9b46a45e2c97bbf41e0b242d5  xorg-server-1.19.99.905.tar.gz
SHA256: 0df18d38805a8e1735480cbe6479193dbb221e66b5f766461fca160ebaf18ac9  
xorg-server-1.19.99.905.tar.gz
SHA512: 
a570df74e75ad259bef7a72620cd33dbd58d145d843adc74c699ca32b0d352d2d4d29003882f28a7ecf75a890abe2d5423cda5c2d8f22cf61804d53d7b172156
  xorg-server-1.19.99.905.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.gz.sig

- ajax

signature.asc
Description: This is a digitally signed message part
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[ANNOUNCE] xorg-server 1.19.99.905

2018-04-24 Thread Adam Jackson 
More bugfixes, and streams support for Xwayland. This will almost
certainly be the last RC.

Adam Jackson (10):
  sdksyms: Skip empty symbols
  xwayland: Don't crash on WarpPointer(dest_w = None)
  modesetting: Fix inverted check in dri2 WaitMSC
  animcur: Fix crash when removing a master device
  dix: Factor out extension availability check
  dix: Allow an extension to disable itself
  vnd: Disable GLX if no vendors successfully initialized
  glx: Require depth > 12 for GLX visuals
  vfb: Fix man page in re depth
  xserver 1.20 RC5

Chris Wilson (1):
  os/WaitFor: Check timers on every iteration

Daniel Stone (1):
  dri3: Don't call vfuncs on old DRI3 screens

David Woodhouse (1):
  glamor: fix glamor_xv_query_image_attributes() for odd-width images

Emil Velikov (1):
  configure.ac: make use of wayland-scanner.pc

Lyude Paul (5):
  meson: Ensure we always build Xext/hashtable.c for glx
  meson: Fix indenting in glx/meson.build
  xwayland: Decouple GBM from glamor
  xwayland: Add xwayland-config.h
  xwayland: Add glamor egl_backend for EGLStreams

Mario Kleiner (2):
  dri3: Fix dri3_buffers_from_pixmap request.
  modesetting: Only use modifiers on kms drivers which do support them.

Matt Turner (1):
  modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM

Olivier Fourdan (3):
  xwayland: Fix build without glamor
  xwayland: avoid using freed xwl_window on unrealize
  xwayland: Clean up all frame callbacks

Thomas Klausner (1):
  sdksyms: Cope with __pid_t and __uint32_t

git tag: xorg-server-1.19.99.905

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.bz2
MD5:  9be2bf4bc611789b61fa1073810f1030  xorg-server-1.19.99.905.tar.bz2
SHA1: 03db7ca162a907debb8230e207a02274a711c17e  xorg-server-1.19.99.905.tar.bz2
SHA256: f73c33d70d8b52db142e0d796be98953308f68fb7625084ae15a2d46b5cc628e  
xorg-server-1.19.99.905.tar.bz2
SHA512: 
9a6f173835989f7562debfbadae0077d75e35bfad5be1f78931fe46ac43df20591162950b27e2c813fd857114f98247be28d357566e45e5d3ac6b60873d94466
  xorg-server-1.19.99.905.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.gz
MD5:  bc4df37dc28e97865a7328c8cebf1b56  xorg-server-1.19.99.905.tar.gz
SHA1: 067fccc3687711a9b46a45e2c97bbf41e0b242d5  xorg-server-1.19.99.905.tar.gz
SHA256: 0df18d38805a8e1735480cbe6479193dbb221e66b5f766461fca160ebaf18ac9  
xorg-server-1.19.99.905.tar.gz
SHA512: 
a570df74e75ad259bef7a72620cd33dbd58d145d843adc74c699ca32b0d352d2d4d29003882f28a7ecf75a890abe2d5423cda5c2d8f22cf61804d53d7b172156
  xorg-server-1.19.99.905.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.gz.sig

- ajax

signature.asc
Description: This is a digitally signed message part
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: [PATCH xserver] dri3: Clamp to 1.0 if not all screens support 1.2

2018-04-24 Thread Adam Jackson 
On Tue, 2018-04-24 at 21:24 +0100, Daniel Stone wrote:
> Hi Adam,
> 
> On 24 April 2018 at 21:08, Adam Jackson  wrote:
> > +for (int i = 0; i < screenInfo.numScreens; i++) {
> > +if (!dri3_screen_can_one_point_two(screenInfo.screens[i])) {
> > +rep.minorVersion = 0;
> > +break;
> > +}
> > +}
> > +
> > +for (int i = 0; i < screenInfo.numGPUScreens; i++) {
> > +if (!dri3_screen_can_one_point_two(screenInfo.gpuscreens[i])) {
> > +rep.minorVersion = 0;
> > +break;
> > +}
> > +}
> 
> Makes sense, but would this disable v1.2 for, e.g., UDL?

It would not, assuming the X driver ends up being modesetting, because
ms only has the one dri3 info struct.

- 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: [PATCH xserver] dri3: Don't call vfuncs on old DRI3 screens

2018-04-24 Thread Adam Jackson 
On Tue, 2018-04-24 at 21:27 +0100, Daniel Stone wrote:
> Only call the get_supported_modifiers vfunc if the DRI3 screen struct is
> sufficiently new.
> 
> Signed-off-by: Daniel Stone 

Merged, thanks:

remote: I: patch #218627 updated using rev 
c593d843f6305dd8bc5fa7762273d319a223abc4.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   54ac09717c..c593d843f6  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: [PATCH xserver 4/3] fixup! xwayland streams buglets

2018-04-24 Thread Adam Jackson 
On Tue, 2018-04-24 at 15:22 -0400, Adam Jackson wrote:
> - Properly disable glamor if streams setup fails
> - Disable window-mode present if streams is in use
> 
> Signed-off-by: Adam Jackson 

Fixed up the bits Daniel pointed out in 1/3, squashed this and 5/3 into
3/3, and merged:

remote: E: failed to find patch for rev 
1545e2dbadcb147d7d52b546d053149de866a031.
remote: I: patch #218123 updated using rev 
994f781007079176e0247ee64af5696d34debcde.
remote: E: failed to find patch for rev 
54ac09717cd8c49259f53a4a227d903ebe8e0a32.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   d2d664df97..54ac09717c  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

[PATCH xserver] dri3: Don't call vfuncs on old DRI3 screens

2018-04-24 Thread Daniel Stone 
Only call the get_supported_modifiers vfunc if the DRI3 screen struct is
sufficiently new.

Signed-off-by: Daniel Stone 
---
 dri3/dri3_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 23e33f401..a1d6f47dd 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -171,7 +171,7 @@ cache_formats_and_modifiers(ScreenPtr screen)
 if (!info)
 return BadImplementation;
 
-if (!info->get_formats || !info->get_modifiers) {
+if (info->version < 2 || !info->get_formats || !info->get_modifiers) {
 ds->formats = NULL;
 ds->num_formats = 0;
 ds->formats_cached = TRUE;
-- 
2.17.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

Re: [PATCH xserver] dri3: Clamp to 1.0 if not all screens support 1.2

2018-04-24 Thread Daniel Stone 
Hi Adam,

On 24 April 2018 at 21:08, Adam Jackson  wrote:
> +for (int i = 0; i < screenInfo.numScreens; i++) {
> +if (!dri3_screen_can_one_point_two(screenInfo.screens[i])) {
> +rep.minorVersion = 0;
> +break;
> +}
> +}
> +
> +for (int i = 0; i < screenInfo.numGPUScreens; i++) {
> +if (!dri3_screen_can_one_point_two(screenInfo.gpuscreens[i])) {
> +rep.minorVersion = 0;
> +break;
> +}
> +}

Makes sense, but would this disable v1.2 for, e.g., UDL?

I've sent another one I just spotted by inspection, but this is:
Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
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] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Daniel Stone 
Hi Adam,

On 24 April 2018 at 20:52, Adam Jackson  wrote:
> On Tue, 2018-04-24 at 11:42 +0100, Daniel Stone wrote:
>> On 24 April 2018 at 09:17, Mario Kleiner  wrote:
>> > Both xf86-video-intel and xf86-video-nouveau cause OpenGL
>> > clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>> >
>> > Reason is that the servers DRI3 version is now unconditionally
>> > reported as DRI3 1.2 to 1.2 capable clients. This causes clients
>> > using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
>> > DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
>> > do not support the needed hooks like info->pixmap_from_fds or
>> > info->get_formats, info->get_modifiers. Unfortunately we can't
>> > simply report the servers DRI3 version as 1.0 in this case, as
>> > the reported version can not be specific to a X-Screen, and
>> > different screens may have drivers with different capabilities.
>
> I think this implies we should not advertise 1.2 if any screen lacks
> the 1.2 hooks.

To be honest, I'd be fine with that too.

>> Thanks a lot for hunting this down! This fix does still make me
>> uncomfortable though. I think a better fix would be, on the Mesa side,
>> to never call any 1.2 codepaths for the server if we get no
>> formats/modifiers back from the GetSupported calls, and to never call
>> any 1.2 codepaths for the drawable if DRIImage's
>> createImageWithModifiers does not exist or if it fails and we fall
>> back to regular createImage. That way we make sure that both sides
>> exercise the same behaviour: either both with explicit modifiers, or
>> neither.
>
> The problem with that strategy is it means 1.20 would be compatible
> with zero already-released versions of Mesa.

True, though it is only 18.1.0rc1 broken now, and we've plenty of time
before rc2.

Cheers,
Daniel
___
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

[PATCH xserver] dri3: Clamp to 1.0 if not all screens support 1.2

2018-04-24 Thread Adam Jackson 
Signed-off-by: Adam Jackson 
---
 dri3/dri3_request.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index 452b08a876..8b35036110 100644
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -32,6 +32,17 @@
 #include 
 #include 
 
+static Bool
+dri3_screen_can_one_point_two(ScreenPtr screen)
+{
+dri3_screen_priv_ptr dri3 = dri3_screen_priv(screen);
+
+if (dri3 && dri3->info && dri3->info->version >= 2)
+return TRUE;
+
+return FALSE;
+}
+
 static int
 proc_dri3_query_version(ClientPtr client)
 {
@@ -45,6 +56,21 @@ proc_dri3_query_version(ClientPtr client)
 };
 
 REQUEST_SIZE_MATCH(xDRI3QueryVersionReq);
+
+for (int i = 0; i < screenInfo.numScreens; i++) {
+if (!dri3_screen_can_one_point_two(screenInfo.screens[i])) {
+rep.minorVersion = 0;
+break;
+}
+}
+
+for (int i = 0; i < screenInfo.numGPUScreens; i++) {
+if (!dri3_screen_can_one_point_two(screenInfo.gpuscreens[i])) {
+rep.minorVersion = 0;
+break;
+}
+}
+
 /* From DRI3 proto:
  *
  * The client sends the highest supported version to the server
-- 
2.17.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

[PATCH xserver 5/3] fixup! build fix for autotools

2018-04-24 Thread Adam Jackson 
Have to do AM_CONDITIONAL at global scope because autoconf is stupid and
terrible.
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index a18170b2fc..3f9752572e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2407,7 +2407,6 @@ if test "x$XWAYLAND" = xyes; then
AC_DEFINE(XWL_HAS_EGLSTREAM, 1,
  [Build xwayland with eglstream support])
fi
-   AM_CONDITIONAL(XWAYLAND_EGLSTREAM, [test "x$XWAYLAND_EGLSTREAM" = 
"xyes"])
 
XWAYLAND_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB 
$RECORD_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_LIB 
$MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB 
$XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB"
XWAYLAND_SYS_LIBS="$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS"
@@ -2430,6 +2429,7 @@ if test "x$XWAYLAND" = xyes; then
 
AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`)
 fi
+AM_CONDITIONAL(XWAYLAND_EGLSTREAM, [test "x$XWAYLAND_EGLSTREAM" = "xyes"])
 
 
 dnl and the rest of these are generic, so they're in config.h
-- 
2.17.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

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Adam Jackson 
On Tue, 2018-04-24 at 11:42 +0100, Daniel Stone wrote:
> Hi Mario,
> 
> On 24 April 2018 at 09:17, Mario Kleiner  wrote:
> > Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> > clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
> > 
> > Reason is that the servers DRI3 version is now unconditionally
> > reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> > using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> > DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> > do not support the needed hooks like info->pixmap_from_fds or
> > info->get_formats, info->get_modifiers. Unfortunately we can't
> > simply report the servers DRI3 version as 1.0 in this case, as
> > the reported version can not be specific to a X-Screen, and
> > different screens may have drivers with different capabilities.

I think this implies we should not advertise 1.2 if any screen lacks
the 1.2 hooks.

> Thanks a lot for hunting this down! This fix does still make me
> uncomfortable though. I think a better fix would be, on the Mesa side,
> to never call any 1.2 codepaths for the server if we get no
> formats/modifiers back from the GetSupported calls, and to never call
> any 1.2 codepaths for the drawable if DRIImage's
> createImageWithModifiers does not exist or if it fails and we fall
> back to regular createImage. That way we make sure that both sides
> exercise the same behaviour: either both with explicit modifiers, or
> neither.

The problem with that strategy is it means 1.20 would be compatible
with zero already-released versions of Mesa.

- 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

[PATCH xserver 4/3] fixup! xwayland streams buglets

2018-04-24 Thread Adam Jackson 
- Properly disable glamor if streams setup fails
- Disable window-mode present if streams is in use

Signed-off-by: Adam Jackson 
---
 hw/xwayland/xwayland-present.c | 9 +
 hw/xwayland/xwayland.c | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-present.c b/hw/xwayland/xwayland-present.c
index c41a8a2d12..07fdc7c184 100644
--- a/hw/xwayland/xwayland-present.c
+++ b/hw/xwayland/xwayland-present.c
@@ -509,5 +509,14 @@ static present_wnmd_info_rec xwl_present_info = {
 Bool
 xwl_present_init(ScreenPtr screen)
 {
+struct xwl_screen *xwl_screen = xwl_screen_get(screen);
+
+/*
+ * doesn't work with the streams backend. we don't have an explicit
+ * boolean for that, but we do know gbm doesn't fill in this hook...
+ */
+if (xwl_screen->egl_backend.post_damage != NULL)
+return FALSE;
+
 return present_wnmd_screen_init(screen, _present_info);
 }
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 4c0c2d3270..f7e2ce9312 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -998,7 +998,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 if (use_eglstreams) {
 if (!xwl_glamor_init_eglstream(xwl_screen)) {
 ErrorF("xwayland glamor: failed to setup eglstream backend, 
falling back to swaccel\n");
-xwl_screen->glamor = 1;
+xwl_screen->glamor = 0;
 }
 } else
 #endif
-- 
2.17.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

Re: [PATCH xserver] vfb: Fix man page in re depth

2018-04-24 Thread Adam Jackson 
On Mon, 2018-04-23 at 15:08 -0700, Alan Coopersmith wrote:

> >  .TP 8
> >  Xvfb :1 -screen 1 1600x1200x16
> >  The server will listen for connections as server number 1, will have the
> 
> Should that say "screen 0 will have..."

Yes it should. Fixed and merged, thanks:

remote: E: failed to find patch for rev 
d2d664df974ac5a55d5819f0379fcdac05d22fa3.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   79a7137557..d2d664df97  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

[Bug 96396] Segfault in Xorg after RADEON(0): Failed to make 28944x66x32bpp GBM bo

2018-04-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96396

--- Comment #12 from Theo  ---
I get the same kind of error on a current openSUSE Tumbleweed:

(EE) RADEON(0): Failed to make 9893x308x32bpp GBM bo

with backtrace messages about libglamoregl.so as in OP's X.Org log. It happens
quite often, but I'm not sure which application causes the error.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver 1/3] xwayland: Decouple GBM from glamor

2018-04-24 Thread Lyude Paul 
On Tue, 2018-04-24 at 10:35 +0100, Daniel Stone wrote:
> Hi,
> 
> On 20 April 2018 at 19:38, Adam Jackson  wrote:
> > This takes all of the gbm related code in wayland-glamor.c and moves it
> > into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
> > Additionally, we add the egl_backend struct into xwl_screen in order to
> > provide hooks for alternative EGL backends such as nvidia's EGLStreams.
> 
> I do think the end result of this commit is better; there are a lot of
> good cleanups in here. It would be much easier to review next time
> though, if this was broken into a few separate commits. There is mass
> code motion, resequencing of functions, reordering of struct members,
> minor changes of struct declarations (e.g. void * -> EGLImage in
> xwl_pixmap), a lot of formatting changes, and other cleanups like
> moving variable declarations into child blocks. It's taken until now
> to review it because I've got four panes open with new and old code
> side by side, with quite a lot of back and forth.
> 
> > +_X_EXPORT Bool
> > +glamor_get_formats(ScreenPtr screen,
> > +   CARD32 *num_formats, CARD32 **formats)
> > +{
> > +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> > +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> > +int i;
> > +
> > +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> > +return FALSE;
> > +
> > +if (xwl_screen->num_formats == 0) {
> > +   *num_formats = 0;
> > +   return TRUE;
> > +}
> 
> Changes from ac48724639e0a6a9e421b3b4e545d8506fd6bf5dost in rebase.
> 
> > +_X_EXPORT Bool
> > +glamor_get_modifiers(ScreenPtr screen, CARD32 format,
> > + CARD32 *num_modifiers, uint64_t **modifiers)
> > +{
> > +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> > +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> > +struct xwl_format *xwl_format = NULL;
> > +int i;
> > +
> > +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> > +return FALSE;
> > +
> > +/* Explicitly zero the count as the caller may ignore the return
> > value */
> > +*num_modifiers = 0;
> 
> Changes from b36a14c0b0e7e38406622eb5ff0666a8b8bc50f4 misplaced in rebase.
> 
> > +static void
> > +xwl_drm_handle_device(void *data, struct wl_drm *drm, const char *device)
> > +{
> > +   struct xwl_screen *xwl_screen = data;
> > +   struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> > +   drm_magic_t magic;
> > +
> > +   xwl_gbm->device_name = strdup(device);
> > +   if (!xwl_gbm->device_name) {
> > +   xwl_glamor_gbm_cleanup(xwl_screen);
> > +   return;
> > +   }
> > +
> > +   xwl_gbm->drm_fd = open(xwl_gbm->device_name, O_RDWR | O_CLOEXEC);
> > +   if (xwl_gbm->drm_fd == -1) {
> > +   ErrorF("wayland-egl: could not open %s (%s)\n",
> > +  xwl_gbm->device_name, strerror(errno));
> > +   xwl_glamor_gbm_cleanup(xwl_screen);
> > +   return;
> > +   }
> > +
> > +   if (is_fd_render_node(xwl_gbm->drm_fd)) {
> > +   xwl_gbm->fd_render_node = 1;
> > +   xwl_screen->expecting_event--;
> > +   } else {
> > +   drmGetMagic(xwl_gbm->drm_fd, );
> > +   wl_drm_authenticate(xwl_gbm->drm, magic);
> > +   }
> > +}
> 
> e.g. here, the change to expecting_event is unnecessary; the previous
> code explicitly decremented and re-incremented to make it clear which
> event was which, and the change meant I had to double back and read
> through the whole init flow again. The current code is still correct,
> and I don't care enough to ask for it to be made back the way it was,
> but in future please try to keep these kinds of subtle changes
> separate from mass code motion.

Will keep that in mind for the future, thanks!
> 
> The rest is:
> Reviewed-by: Daniel Stone 
> 
> Cheers,
> Daniel
-- 
Cheers,
Lyude Paul
___
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] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Daniel Stone 
Hi Mario,

On 24 April 2018 at 09:17, Mario Kleiner  wrote:
> Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>
> Reason is that the servers DRI3 version is now unconditionally
> reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> do not support the needed hooks like info->pixmap_from_fds or
> info->get_formats, info->get_modifiers. Unfortunately we can't
> simply report the servers DRI3 version as 1.0 in this case, as
> the reported version can not be specific to a X-Screen, and
> different screens may have drivers with different capabilities.

Thanks a lot for hunting this down! This fix does still make me
uncomfortable though. I think a better fix would be, on the Mesa side,
to never call any 1.2 codepaths for the server if we get no
formats/modifiers back from the GetSupported calls, and to never call
any 1.2 codepaths for the drawable if DRIImage's
createImageWithModifiers does not exist or if it fails and we fall
back to regular createImage. That way we make sure that both sides
exercise the same behaviour: either both with explicit modifiers, or
neither.

Cheers,
Daniel
___
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 3/3] xwayland: Add glamor egl_backend for EGLStreams

2018-04-24 Thread Daniel Stone 
Hi,

On 20 April 2018 at 19:38, Adam Jackson  wrote:
> This adds initial support for displaying Xwayland applications through
> the use of EGLStreams and nvidia's custom wayland protocol by adding
> another egl_backend driver. This also adds some additional egl_backend
> hooks that are required to make things work properly.
>
> EGLStreams work a lot differently then the traditional way of handling
> buffers with wayland. Unfortunately, there are also a LOT of various
> pitfalls baked into it's design that need to be explained.

This is every bit as unpleasant as the commit message details, but I'm
not sure how you'd do it better, and it is at least minimally
intrusive to the rest.

Acked-by: Daniel Stone 

Cheers,
Daniel
___
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 2/3] xwayland: Add xwayland-config.h

2018-04-24 Thread Daniel Stone 
On 20 April 2018 at 19:38, Adam Jackson  wrote:
> Just a small autogenerated header that will soon contain more then just
> one macro.
>
> Signed-off-by: Lyude Paul 

Reviewed-by: Daniel Stone 
___
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 1/3] xwayland: Decouple GBM from glamor

2018-04-24 Thread Daniel Stone 
Hi,

On 20 April 2018 at 19:38, Adam Jackson  wrote:
> This takes all of the gbm related code in wayland-glamor.c and moves it
> into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
> Additionally, we add the egl_backend struct into xwl_screen in order to
> provide hooks for alternative EGL backends such as nvidia's EGLStreams.

I do think the end result of this commit is better; there are a lot of
good cleanups in here. It would be much easier to review next time
though, if this was broken into a few separate commits. There is mass
code motion, resequencing of functions, reordering of struct members,
minor changes of struct declarations (e.g. void * -> EGLImage in
xwl_pixmap), a lot of formatting changes, and other cleanups like
moving variable declarations into child blocks. It's taken until now
to review it because I've got four panes open with new and old code
side by side, with quite a lot of back and forth.

> +_X_EXPORT Bool
> +glamor_get_formats(ScreenPtr screen,
> +   CARD32 *num_formats, CARD32 **formats)
> +{
> +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +int i;
> +
> +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> +return FALSE;
> +
> +if (xwl_screen->num_formats == 0) {
> +   *num_formats = 0;
> +   return TRUE;
> +}

Changes from ac48724639e0a6a9e421b3b4e545d8506fd6bf5dost in rebase.

> +_X_EXPORT Bool
> +glamor_get_modifiers(ScreenPtr screen, CARD32 format,
> + CARD32 *num_modifiers, uint64_t **modifiers)
> +{
> +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +struct xwl_format *xwl_format = NULL;
> +int i;
> +
> +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> +return FALSE;
> +
> +/* Explicitly zero the count as the caller may ignore the return value */
> +*num_modifiers = 0;

Changes from b36a14c0b0e7e38406622eb5ff0666a8b8bc50f4 misplaced in rebase.

> +static void
> +xwl_drm_handle_device(void *data, struct wl_drm *drm, const char *device)
> +{
> +   struct xwl_screen *xwl_screen = data;
> +   struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +   drm_magic_t magic;
> +
> +   xwl_gbm->device_name = strdup(device);
> +   if (!xwl_gbm->device_name) {
> +   xwl_glamor_gbm_cleanup(xwl_screen);
> +   return;
> +   }
> +
> +   xwl_gbm->drm_fd = open(xwl_gbm->device_name, O_RDWR | O_CLOEXEC);
> +   if (xwl_gbm->drm_fd == -1) {
> +   ErrorF("wayland-egl: could not open %s (%s)\n",
> +  xwl_gbm->device_name, strerror(errno));
> +   xwl_glamor_gbm_cleanup(xwl_screen);
> +   return;
> +   }
> +
> +   if (is_fd_render_node(xwl_gbm->drm_fd)) {
> +   xwl_gbm->fd_render_node = 1;
> +   xwl_screen->expecting_event--;
> +   } else {
> +   drmGetMagic(xwl_gbm->drm_fd, );
> +   wl_drm_authenticate(xwl_gbm->drm, magic);
> +   }
> +}

e.g. here, the change to expecting_event is unnecessary; the previous
code explicitly decremented and re-incremented to make it clear which
event was which, and the change meant I had to double back and read
through the whole init flow again. The current code is still correct,
and I don't care enough to ask for it to be made back the way it was,
but in future please try to keep these kinds of subtle changes
separate from mass code motion.

The rest is:
Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
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

[PATCH xrandr] xrandr: Consider transform when placing monitors relatively to each other.

2018-04-24 Thread Michal Srb 
For example: xrandr --output HDMI-1 --scale 0.5 --left-of HDMI-2
Will no create any gap between HDMI-1 and HDMI-2.
---
 xrandr.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/xrandr.c b/xrandr.c
index 7f1e867..21e121a 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -2015,6 +2015,7 @@ set_positions (void)
 Bool   keep_going;
 Bool   any_set;
 intmin_x, min_y;
+box_t  bounds;
 
 for (;;)
 {
@@ -2054,20 +2055,24 @@ set_positions (void)

switch (output->relation) {
case relation_left_of:
+   mode_geometry(output->mode_info, output->rotation, 
>transform.transform, );
output->y = relation->y;
-   output->x = relation->x - mode_width (output->mode_info, 
output->rotation);
+   output->x = relation->x - bounds.x2;
break;
case relation_right_of:
+   mode_geometry(relation->mode_info, relation->rotation, 
>transform.transform, );
output->y = relation->y;
-   output->x = relation->x + mode_width (relation->mode_info, 
relation->rotation);
+   output->x = relation->x + bounds.x2;
break;
case relation_above:
+   mode_geometry(output->mode_info, output->rotation, 
>transform.transform, );
output->x = relation->x;
-   output->y = relation->y - mode_height (output->mode_info, 
output->rotation);
+   output->y = relation->y - bounds.y2;
break;
case relation_below:
+   mode_geometry(relation->mode_info, relation->rotation, 
>transform.transform, );
output->x = relation->x;
-   output->y = relation->y + mode_height (relation->mode_info, 
relation->rotation);
+   output->y = relation->y + bounds.y2;
break;
case relation_same_as:
output->x = relation->x;
-- 
2.13.6

___
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

[PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Mario Kleiner 
Both xf86-video-intel and xf86-video-nouveau cause OpenGL
clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.

Reason is that the servers DRI3 version is now unconditionally
reported as DRI3 1.2 to 1.2 capable clients. This causes clients
using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
do not support the needed hooks like info->pixmap_from_fds or
info->get_formats, info->get_modifiers. Unfortunately we can't
simply report the servers DRI3 version as 1.0 in this case, as
the reported version can not be specific to a X-Screen, and
different screens may have drivers with different capabilities.

Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap,
and simply reporting an empty set of supported modifiers for the
DRI3GetSupportedModifiers request if the ddx doesn't support
DRI 3.2.

Clients like Mesa 18.1's dri3 loader respond to the empty set
of reported modifiers by falling back to a dri driver selected
buffer format (image->createImageWithModifiers responds to a
NULL modifier_list by acting like ->createImage()). This works,
but Mesa 18.1 will still try to use the DRI3PixmapFromBuffers
request to create the corresponding pixmap, just passing in
a modifier that corresponds to whatever tiling the dri driver
selected by default. To prevent this request - and thereby
the client - from failing with a BadImplementation error,
remove the check for modifier == DRM_MOD_FORMAT_INVALID in
the pixmap_from_fd fallback path of dri3_pixmap_from_fds()
and trust that if we hit the fallback path then the client
will have passed a buffer with some driver specific default
tiling that can be handled by pixmap_from_fd.

Another approach would be for Mesa's dri3 loader to keep
track how a buffer was created (with explicit modifiers or
not), and then call DRI3PixmapFromBuffers or DRI3PixmapFromBuffer,
but then any future DRI3 client implementation would need to be
fixed, so the server side is probably the better place for this.

Tested on Intel Ivybridge and NVidia Pascal.

Fixes: 6e7c40f62db6 ("dri3: Add multi-planar/modifier buffer requests")
Signed-off-by: Mario Kleiner 
Cc: Daniel Stone 
Cc: Louis-Francis Ratté-Boulianne 
---
 dri3/dri3_screen.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 23e33f4..243dab7 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -66,8 +66,7 @@ dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr screen,
 if (info->version >= 2 && info->pixmap_from_fds != NULL) {
 pixmap = (*info->pixmap_from_fds) (screen, num_fds, fds, width, height,
strides, offsets, depth, bpp, 
modifier);
-} else if (info->pixmap_from_fd != NULL && num_fds == 1 &&
-   modifier == DRM_FORMAT_MOD_INVALID) {
+} else if (info->pixmap_from_fd != NULL && num_fds == 1) {
 pixmap = (*info->pixmap_from_fd) (screen, fds[0], width, height,
   strides[0], depth, bpp);
 } else {
-- 
2.7.4

___
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] Xwayland: Don't notify RR of an unchanged size

2018-04-24 Thread Preston Carpenter 
On Sun, Apr 22, 2018 at 2:18 PM, Matt Turner  wrote:
>
>
> Do you mind using your real name?


Sure, here is the patch again with my real name.

From: Preston Carpenter 

On Wayland compositors such as Sway and Way Cooler Xwayland windows will
be scaled twice if a TTY change occurs. This is due to sending the
output mode information twice, causing it to be applied twice to RandR.

This patch does not notify RandR if the size did not change, covering
the case where a TTY was suspended and then later resumed.

Signed-off-by: Preston Carpenter 
---
 hw/xwayland/xwayland-output.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 48faeb142..dc988ed2f 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -194,7 +194,7 @@ update_screen_size(struct xwl_output *xwl_output, int
width, int height)

 SetRootClip(xwl_screen->screen, xwl_screen->root_clip_mode);

-if (xwl_screen->screen->root) {
+if (xwl_screen->screen->root && xwl_output->width != width &&
xwl_output->height != height) {
 BoxRec box = { 0, 0, width, height };

 xwl_screen->screen->root->drawable.width = width;
--
2.17.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