date:20180209

[PATCH] Correct xorg_list_is_empty return value description

2018-02-09 Thread Roman Gilg

The helper xorg_list_is_empty returns True when the list is empty and not when
it contains one or more elements.

Signed-off-by: Roman Gilg 
---
 include/list.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/list.h b/include/list.h
index 3f0574d..f81d97f 100644
--- a/include/list.h
+++ b/include/list.h
@@ -211,7 +211,8 @@ xorg_list_del(struct xorg_list *entry)
  * Example:
  * xorg_list_is_empty(>list_of_foos);
  *
- * @return True if the list contains one or more elements or False otherwise.
+ * @return True if the list is empty or False if the list contains one or more
+ * elements.
  */
 static inline int
 xorg_list_is_empty(struct xorg_list *head)
-- 
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

[PATCH xserver] Correct xorg_list_is_empty return value description The helper xorg_list_is_empty returns True when the list is empty and not when it contains one or more elements.

2018-02-09 Thread Roman Gilg

Signed-off-by: Roman Gilg 
---
 include/list.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/list.h b/include/list.h
index 3f0574d..f81d97f 100644
--- a/include/list.h
+++ b/include/list.h
@@ -211,7 +211,8 @@ xorg_list_del(struct xorg_list *entry)
  * Example:
  * xorg_list_is_empty(>list_of_foos);
  *
- * @return True if the list contains one or more elements or False otherwise.
+ * @return True if the list is empty or False if the list contains one or more
+ * elements.
  */
 static inline int
 xorg_list_is_empty(struct xorg_list *head)
-- 
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

[RFC v3 0/3] xwayland: Add support for eglstreams

2018-02-09 Thread Lyude Paul

Some changes since the last version:
 - Get rid of some unecessary context switches
 - Remove EGLSurface from current context on deletion with
   eglMakeCurrent() since an EGLSurface can stay around after deletion
   for as long as it's current
 - Use EGL_CONTEXT_PRIORITY_LEVEL_IMG to set our rendering priority to
   high, speeds things up a tiny bit more.

Lyude Paul (3):
  xwayland: Decouple GBM from glamor
  xwayland: Add xwayland-config.h
  xwayland: Add glamor egl_backend for EGLStreams

 configure.ac|  31 ++
 hw/xwayland/Makefile.am |  26 +-
 hw/xwayland/meson.build |  18 +-
 hw/xwayland/xwayland-glamor-eglstream.c | 824 
 hw/xwayland/xwayland-glamor-gbm.c   | 628 
 hw/xwayland/xwayland-glamor.c   | 577 +-
 hw/xwayland/xwayland.c  |  57 ++-
 hw/xwayland/xwayland.h  |  95 +++-
 include/meson.build |  10 +-
 include/xwayland-config.h.in|  13 +
 include/xwayland-config.h.meson.in  |  11 +
 meson.build |  15 +
 meson_options.txt   |   2 +
 13 files changed, 1816 insertions(+), 491 deletions(-)
 create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c
 create mode 100644 hw/xwayland/xwayland-glamor-gbm.c
 create mode 100644 include/xwayland-config.h.in
 create mode 100644 include/xwayland-config.h.meson.in

-- 
2.14.3

___
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

[RFC v3 3/3] xwayland: Add glamor egl_backend for EGLStreams

2018-02-09 Thread Lyude Paul

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 has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps.  no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:

- egl_backend.allow_commits for holding off displaying any EGLStream
  backed pixmaps until the point where it's stream is completely
  initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
  surface producer before Xwayland actually damages and commits the
  wl_surface to the screen.

The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.

Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).

While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.

Signed-off-by: Lyude Paul 
---
 configure.ac|  24 +
 hw/xwayland/Makefile.am |  23 +-
 hw/xwayland/meson.build |  19 +-
 hw/xwayland/xwayland-glamor-eglstream.c | 824 
 hw/xwayland/xwayland-glamor-gbm.c   |   6 +-
 hw/xwayland/xwayland-glamor.c   | 111 -
 hw/xwayland/xwayland.c  |  34 ++
 hw/xwayland/xwayland.h  |  39 ++
 include/meson.build |   5 +-
 include/xwayland-config.h.in|   3 +
 include/xwayland-config.h.meson.in  |   3 +
 meson.build |  15 +
 meson_options.txt   |   2 +
 13 files changed, 1096 insertions(+), 12 deletions(-)
 create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c

diff --git a/configure.ac b/configure.ac
index e4c2965d6..c8d46a075 100644
--- a/configure.ac
+++ b/configure.ac
@@ -590,6 +590,7 @@ AC_ARG_ENABLE(xvfb,   
AS_HELP_STRING([--enable-xvfb], [Build Xvfb server
 AC_ARG_ENABLE(xnest, AS_HELP_STRING([--enable-xnest], [Build 
Xnest

[RFC v3 1/3] xwayland: Decouple GBM from glamor

2018-02-09 Thread Lyude Paul

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.

Signed-off-by: Lyude Paul 
---
 hw/xwayland/Makefile.am   |   3 +-
 hw/xwayland/meson.build   |   1 +
 hw/xwayland/xwayland-glamor-gbm.c | 632 ++
 hw/xwayland/xwayland-glamor.c | 500 +-
 hw/xwayland/xwayland.c|  13 +-
 hw/xwayland/xwayland.h|  54 +++-
 6 files changed, 705 insertions(+), 498 deletions(-)
 create mode 100644 hw/xwayland/xwayland-glamor-gbm.c

diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 7204591e3..d9e9fe8b6 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -33,7 +33,8 @@ Xwayland_built_sources =
 
 if GLAMOR_EGL
 Xwayland_SOURCES +=\
-   xwayland-glamor.c
+   xwayland-glamor.c   \
+   xwayland-glamor-gbm.c
 if XV
 Xwayland_SOURCES +=\
xwayland-glamor-xv.c
diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
index 24203c63e..d219e2f44 100644
--- a/hw/xwayland/meson.build
+++ b/hw/xwayland/meson.build
@@ -43,6 +43,7 @@ srcs += code.process(xdg_output_xml)
 xwayland_glamor = []
 if gbm_dep.found()
 srcs += 'xwayland-glamor.c'
+srcs += 'xwayland-glamor-gbm.c'
 if build_xv
 srcs += 'xwayland-glamor-xv.c'
 endif
diff --git a/hw/xwayland/xwayland-glamor-gbm.c 
b/hw/xwayland/xwayland-glamor-gbm.c
new file mode 100644
index 0..4b973019f
--- /dev/null
+++ b/hw/xwayland/xwayland-glamor-gbm.c
@@ -0,0 +1,632 @@
+/*
+ * Copyright © 2011-2014 Intel Corporation
+ * Copyright © 2017 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including
+ * the next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Lyude Paul 
+ *
+ */
+
+#include "xwayland.h"
+
+#include 
+#include 
+#include 
+
+#define MESA_EGL_NO_X11_HEADERS
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include "drm-client-protocol.h"
+
+struct xwl_gbm_private {
+struct gbm_device *gbm;
+struct wl_drm *drm;
+char *device_name;
+int drm_fd;
+int fd_render_node;
+Bool drm_authenticated;
+uint32_t capabilities;
+};
+
+struct xwl_pixmap {
+struct wl_buffer *buffer;
+EGLImage image;
+unsigned int texture;
+struct gbm_bo *bo;
+};
+
+static DevPrivateKeyRec xwl_gbm_private_key;
+static DevPrivateKeyRec xwl_auth_state_private_key;
+
+static inline struct xwl_gbm_private *
+xwl_gbm_get(struct xwl_screen *xwl_screen)
+{
+return dixLookupPrivate(_screen->screen->devPrivates,
+_gbm_private_key);
+}
+
+static uint32_t
+gbm_format_for_depth(int depth)
+{
+switch (depth) {
+case 16:
+return GBM_FORMAT_RGB565;
+case 24:
+return GBM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return GBM_FORMAT_ARGB;
+}
+}
+
+static uint32_t
+drm_format_for_depth(int depth)
+{
+switch (depth) {
+case 15:
+return WL_DRM_FORMAT_XRGB1555;
+case 16:
+return WL_DRM_FORMAT_RGB565;
+case 24:
+return WL_DRM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return WL_DRM_FORMAT_ARGB;
+}
+}
+
+static char
+is_fd_render_node(int fd)
+{
+struct stat render;
+
+if (fstat(fd, ))
+return 0;
+if (!S_ISCHR(render.st_mode))
+return 0;
+if (render.st_rdev & 0x80)
+return 1;
+
+return 0;
+}
+
+static PixmapPtr
+xwl_glamor_gbm_create_pixmap_for_bo(ScreenPtr screen, struct gbm_bo *bo,
+int depth)
+{
+PixmapPtr

[RFC v3 2/3] xwayland: Add xwayland-config.h

2018-02-09 Thread Lyude Paul

Just a small autogenerated header that will soon contain more then just
one macro.

Signed-off-by: Lyude Paul 
---
 configure.ac   |  7 +++
 hw/xwayland/xwayland.c | 10 ++
 hw/xwayland/xwayland.h |  2 +-
 include/meson.build|  7 +++
 include/xwayland-config.h.in   | 10 ++
 include/xwayland-config.h.meson.in |  8 
 6 files changed, 39 insertions(+), 5 deletions(-)
 create mode 100644 include/xwayland-config.h.in
 create mode 100644 include/xwayland-config.h.meson.in

diff --git a/configure.ac b/configure.ac
index 98b8ea2ed..e4c2965d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,8 @@ dnl xkb-config.h covers XKB for the Xorg and Xnest DDXs.
 AC_CONFIG_HEADERS(include/xkb-config.h)
 dnl xwin-config.h covers the XWin DDX.
 AC_CONFIG_HEADERS(include/xwin-config.h)
+dnl xwayland-config.h covers Xwayland.
+AC_CONFIG_HEADERS(include/xwayland-config.h)
 dnl version-config.h covers the version numbers so they can be bumped without
 dnl forcing an entire recompile.x
 AC_CONFIG_HEADERS(include/version-config.h)
@@ -2373,6 +2375,11 @@ if test "x$XWAYLAND" = xyes; then
AC_MSG_ERROR([Xwayland build explicitly requested, but required 
modules not found.])
fi
 
+   if test "x$GLAMOR" = xyes && test "x$GBM" = xyes; then
+   AC_DEFINE(XWL_HAS_GLAMOR, 1,
+ [Build xwayland with glamor support])
+   fi
+
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"
AC_SUBST([XWAYLAND_LIBS])
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 979b72918..f4a9a0615 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -647,7 +647,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
 region = DamageRegion(xwl_window->damage);
 pixmap = (*xwl_screen->screen->GetWindowPixmap) (xwl_window->window);
 
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
 if (xwl_screen->glamor)
 buffer = xwl_glamor_pixmap_get_wl_buffer(pixmap);
 else
@@ -725,7 +725,7 @@ registry_global(void *data, struct wl_registry *registry, 
uint32_t id,
 wl_registry_bind(registry, id, _output_manager_v1_interface, 
1);
 xwl_screen_init_xdg_output(xwl_screen);
 }
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
 else if (xwl_screen->glamor) {
 xwl_glamor_init_wl_registry(xwl_screen, registry, id, interface,
 version);
@@ -909,7 +909,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 dixSetPrivate(>devPrivates, _screen_private_key, xwl_screen);
 xwl_screen->screen = pScreen;
 
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
 xwl_screen->glamor = 1;
 #endif
 
@@ -937,12 +937,14 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 }
 }
 
+#ifdef XWL_HAS_GLAMOR
 if (xwl_screen->glamor) {
 if (!xwl_glamor_init_gbm(xwl_screen)) {
 ErrorF("xwayland glamor: failed to setup GBM backend, falling back 
to sw accel\n");
 xwl_screen->glamor = 0;
 }
 }
+#endif
 
 /* In rootless mode, we don't have any screen storage, and the only
  * rendering should be to redirected mode. */
@@ -1026,7 +1028,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 if (!xwl_screen_init_cursor(xwl_screen))
 return FALSE;
 
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
 if (xwl_screen->glamor && !xwl_glamor_init(xwl_screen)) {
 ErrorF("Failed to initialize glamor, falling back to sw\n");
 xwl_screen->glamor = 0;
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 88e9ec832..7961cc6f1 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -26,7 +26,7 @@
 #ifndef XWAYLAND_H
 #define XWAYLAND_H
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/include/meson.build b/include/meson.build
index 00ec0573d..a5701fc53 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -293,6 +293,13 @@ configure_file(output : 'xwin-config.h',
input : 'xwin-config.h.meson.in',
configuration : xwin_data)
 
+xwayland_data = configuration_data()
+xwayland_data.set('XWL_HAS_GLAMOR', build_glamor and gbm_dep.found())
+
+configure_file(output : 'xwayland-config.h',
+   input : 'xwayland-config.h.meson.in',
+   configuration : xwayland_data)
+
 if build_xorg
 install_data(
 [
diff --git a/include/xwayland-config.h.in b/include/xwayland-config.h.in
new file mode 100644
index 0..333b53f23
--- /dev/null
+++ b/include/xwayland-config.h.in
@@ -0,0 +1,10 @@
+/* xwayland-config.h.in: not

Re: [PATCH xserver 5/5] glamor: Enable composite acceleration for rgb10 formats.

2018-02-09 Thread Eric Anholt

Mario Kleiner  writes:

> argb2101010 and xrgb2101010. Seems to work fine,
> but not sure if because of dumb luck or because
> it is meant to be. (Re)viewer discretion advised!
>
> Tested on KDE Plasma-5 with XRender based composite
> acceleration backend. Much smoother and faster.
>
> Signed-off-by: Mario Kleiner 
> ---
>  glamor/glamor_render.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index 7a96c82..659537f 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -773,6 +773,8 @@ static Bool
>  glamor_render_format_is_supported(PictFormatShort format)
>  {
>  switch (format) {
> +case PICT_a2r10g10b10:
> +case PICT_x2r10g10b10:

I don't think you can include a2r10g10b10 here.  A pixmap that you've
attached that pictformat to must be depth 32, which will have been
created as an  GL texture.  Doing composite on that when asked for
2101010 formatwill end up referencing the wrong bits in the color
channels.  I think if you ran rendercheck, it would throw errors about
this.

Other than that, patch 2-5 get my reviewed-by, except that we should
stack the glamor fixes before enabling the feature in the modesetting
driver.

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

Re: [PATCH xserver] glx: Only assign 8 bpc fbconfigs for composite visuals.

2018-02-09 Thread Thomas Hellstrom


On 02/07/2018 03:18 PM, Mario Kleiner wrote:

On 02/06/2018 08:04 PM, Adam Jackson wrote:

On Mon, 2018-02-05 at 11:25 +0100, Thomas Hellstrom wrote:

On 02/05/2018 11:20 AM, Mario Kleiner wrote:

Commit 91c42093b248 ("glx: Duplicate relevant fbconfigs for
compositing visuals") adds many new depth 32 fbconfigs as
composite visuals. On a X-Screen running at depth 24, this
also adds bgra 10-10-10-2 fbconigs, as they also have
config.rgbBits == 32, but these are not displayable on a
depth 24 screen, leading to visually corrupted desktops
under some compositors, e.g., fdo bug 104597 "Compton
weird colors" when running compton with
"compton --backend glx".

Be more conservative for now and only select fbconfigs with
8 bpc red, green, blue components for composite visuals.

Fixes: 91c42093b248 ("glx: Duplicate relevant fbconfigs for
    compositing visuals")
Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D104597=DwIBAg=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=IbtkCrmjzJVhB0PdaE0y9A3Zqx2CEYhUPvtI6PeGSEo=6MOlztrQC3tRtcJvqesPVJ1ri_ILRWLMh-iZbrs7NJ0=

Signed-off-by: Mario Kleiner 
Cc: Thomas Hellstrom 
Cc: Adam Jackson 


Reviewed-by: Thomas Hellstrom 


remote: I: patch #202588 updated using rev 
bebcc8477c8070ade9dd4be7299c718baeab3d7a.

remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
    98edb9a35e..bebcc8477c  master -> master

- ajax



Thanks for the review and merge. This also needs to get picked into 
the server 1.19 branch. Are there plans to tag a new 1.19.7 release 
soon? I'm worried that if spring distro updates like Ubuntu 18.04 LTS 
would ship with Mesa 18.0 + server 1.19.6, instead of a 1.19.7 with 
these fixes, the 10 bpc related issues and the new sRGB Intel DRI 
stuff could cause quite a bit of pain for distro users without the 
fixes in the 1.19 branch, e.g., disappering menus in firefox and 
GNU/Octave under desktop composition, depending on the ddx in use and 
the phase of the moon.


thanks,
-mario


Hi,

I'm not sure the duplicating 91c420 commit actually got backported to 
1.19? If not, that commit needs backporting as well as its fixes.


/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

2018 X.Org Board of Directors Elections Nomination period is NOW

2018-02-09 Thread Rob Clark

We are seeking nominations for candidates for election to the X.Org
Foundation Board of Directors. All X.Org Foundation members are
eligible for election to the board.

Nominations for the 2018 election are now open and will remain open
until 23:59 UTC on 23 Feb 2018.

The Board consists of directors elected from the membership. Each
year, an election is held to bring the total number of directors to
eight. The four members receiving the highest vote totals will serve
as directors for two year terms.

The directors who received two year terms starting in 2017 were Rob
Clark, Martin Peres, Taylor Campbell and Daniel Vetter. They will
continue to serve until their term ends in 2019. Current directors
whose term expires in 2018 are Alex Deucher, Egbert Eich, Keith
Packard and Bryce Harrington.

A director is expected to participate in the fortnightly IRC meeting
to discuss current business and to attend the annual meeting of the
X.Org Foundation, which will be held at a location determined in
advance by the Board of Directors.

A member may nominate themselves or any other member they feel is
qualified. Nominations should be sent to the Election Committee at
elections at x.org.

Nominees shall be required to be current members of the X.Org
Foundation, and submit a personal statement of up to 200 words that
will be provided to prospective voters. The collected statements,
along with the statement of contribution to the X.Org Foundation in
the members account page on http://members.x.org, will be made
available to all voters to help them make their voting decisions.

Nominations, membership applications or renewals and completed
personal statements must be received no later than 23:59 UTC on 23 Feb
2018.

The slate of candidates will be published 1 Mar 2018 and candidate Q
will begin then. The deadline for Xorg membership applications and
renewals is 1 Mar 2018.

Cheers, Rob Clark, on behalf of the X.Org BoD
https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
___
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/5] modesetting: Don't call xf86HandleColorMaps() at screen depth 30.

2018-02-09 Thread Mario Kleiner


On 02/09/2018 10:45 AM, Michel Dänzer wrote:

On 2018-02-09 07:24 AM, Mario Kleiner wrote:

On 02/08/2018 03:55 PM, Michel Dänzer wrote:

On 2018-02-08 12:14 PM, Mario Kleiner wrote:

As it turns out, doing so will make any gamma table updates
silently fail, because xf86HandleColorMaps() hooks the
.LoadPalette function to xf86RandR12LoadPalette() if the
.gamma_set function is supported by the ddx, as is in our
case.

Once xf86RandR12LoadPalette() has been called during server
startup, all palette and/or gamma table updates go through
xf86RandR12CrtcComputeGamma() to combine color palette
updates with gamma table updates into a proper hardware lut
for upload into the hw via the .gamma_set function/ioctl,
passing in a palette with palette_red/green/blue_size == the
size given by the visuals red/green/blueMask, which will
be == 1024 for a depth 30 screen.

That in turn is a problem, because the size of the hw lut
crtc->gamma_size is fixed to 256 slots on all kms-drivers
when using the legacy gamma_set ioctl, but
xf86RandR12CrtcComputeGamma() can only handle palettes of a
size <= the hw lut size. As the palette size of 1024 is greater
than the hw lut size of 256, the code silently fails
(gamma_slots == 0 in xf86RandR12CrtcComputeGamma()).

Skipping xf86HandleColormaps() on a depth > 24 screen disables
color palette handling, but keeps at least gamma table updates
via xf86vidmode extension and RandR working.


Sort of... It means xf86VidMode and RandR call directly into the driver
to set their LUTs, with no coordination between them, so whichever calls
into the driver last wins and clobbers the HW LUT.


Wouldn't that be desirable behavior in this case, assuming the client
that calls last is the one that wants something more specific?


If it was that simple... :)

Imagine you use something like Night Light / redshift which uses
xf86VidMode, and some kind of per-monitor gamma calibration tool which
uses RandR. Surely you want to see the combination of the two
transformations, not only one or the other, depending on which one has
ended up calling into the driver last (which could result in
flip-flopping between the two transformations, depending on how often
each tool (re-)sets its LUT).



Ok, thanks for the example. That makes sense. And creates new potential 
horror-scenario for me, given that my scientific users need very well 
defined gamma calibrations in many situations. Never thought about 
redshift or such messing with gamma behind the back of my RandR based 
code by having combined gamma lut's. The pitfalls never end...





It would be better to fix xf86RandR12CrtcComputeGamma instead.


But how? The current code can upsample an input palette < hw lut by
replicating input values onto multiple hw slots, which makes perfect
sense. But downsampling a bigger input palette, e.g., by just picking
every n'th slot, seems problematic to me. You lose information from the
palette in a way that might not be at all what the application wanted if
it went to the trouble of creating a custom palette, assuming any apps
would do anything meaningful with palettes on a depth 30 screen in the
first place.


You're right that the downsampling could theoretically be a problem. But
in practice, the LUTs should usually correspond to some kind of more or
less smooth curve, and I'm told display hardware tends to interpolate
between the LUT entries.



Depending on hw lut mode.




Unless the application just used the default palette or a
truecolor visual, like probably most do nowadays, which i assume would
be an identity mapping, so it doesn't matter if a palette is applied at
all?


No colormaps means e.g. the gamma sliders in some games don't work.




Ok. I'll try if i can come up with some "take every n'th slot" 
subsampling in xf86RandR12CrtcComputeGamma, and some switching in 
modesetting ddx inside xf86HandleColormaps a la


xf86HandleColormaps(pScreen, 1 << sigRgbBits, 10, ...)

to switch maxColors between 256 and 1024 for depth 24 vs. 30.

That creates a bit of a problem for intel-ddx and nouveau-ddx though, as 
they need the same treatment, but need to work on both older servers and 
an upcoming v1.20. Or special case handling depending on server version.


-mario
___
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] glx: Only assign 8 bpc fbconfigs for composite visuals.

2018-02-09 Thread Timo Aaltonen

On 07.02.2018 16:18, Mario Kleiner wrote:
> On 02/06/2018 08:04 PM, Adam Jackson wrote:
>> On Mon, 2018-02-05 at 11:25 +0100, Thomas Hellstrom wrote:
>>> On 02/05/2018 11:20 AM, Mario Kleiner wrote:
 Commit 91c42093b248 ("glx: Duplicate relevant fbconfigs for
 compositing visuals") adds many new depth 32 fbconfigs as
 composite visuals. On a X-Screen running at depth 24, this
 also adds bgra 10-10-10-2 fbconigs, as they also have
 config.rgbBits == 32, but these are not displayable on a
 depth 24 screen, leading to visually corrupted desktops
 under some compositors, e.g., fdo bug 104597 "Compton
 weird colors" when running compton with
 "compton --backend glx".

 Be more conservative for now and only select fbconfigs with
 8 bpc red, green, blue components for composite visuals.

 Fixes: 91c42093b248 ("glx: Duplicate relevant fbconfigs for
     compositing visuals")
 Bugzilla:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D104597=DwIBAg=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=IbtkCrmjzJVhB0PdaE0y9A3Zqx2CEYhUPvtI6PeGSEo=6MOlztrQC3tRtcJvqesPVJ1ri_ILRWLMh-iZbrs7NJ0=

 Signed-off-by: Mario Kleiner 
 Cc: Thomas Hellstrom 
 Cc: Adam Jackson 
>>>
>>> Reviewed-by: Thomas Hellstrom 
>>
>> remote: I: patch #202588 updated using rev
>> bebcc8477c8070ade9dd4be7299c718baeab3d7a.
>> remote: I: 1 patch(es) updated to state Accepted.
>> To ssh://git.freedesktop.org/git/xorg/xserver
>>     98edb9a35e..bebcc8477c  master -> master
>>
>> - ajax
>>
> 
> Thanks for the review and merge. This also needs to get picked into the
> server 1.19 branch. Are there plans to tag a new 1.19.7 release soon?
> I'm worried that if spring distro updates like Ubuntu 18.04 LTS would
> ship with Mesa 18.0 + server 1.19.6, instead of a 1.19.7 with these
> fixes, the 10 bpc related issues and the new sRGB Intel DRI stuff could
> cause quite a bit of pain for distro users without the fixes in the 1.19
> branch, e.g., disappering menus in firefox and GNU/Octave under desktop
> composition, depending on the ddx in use and the phase of the moon.

1.19.7 would be nice, my wishlist would also include the OutputClass
commits from last year, but that might be pushing too far..



-- 
t
___
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/5] modesetting: Don't call xf86HandleColorMaps() at screen depth 30.

2018-02-09 Thread Michel Dänzer

On 2018-02-09 07:24 AM, Mario Kleiner wrote:
> On 02/08/2018 03:55 PM, Michel Dänzer wrote:
>> On 2018-02-08 12:14 PM, Mario Kleiner wrote:
>>> As it turns out, doing so will make any gamma table updates
>>> silently fail, because xf86HandleColorMaps() hooks the
>>> .LoadPalette function to xf86RandR12LoadPalette() if the
>>> .gamma_set function is supported by the ddx, as is in our
>>> case.
>>>
>>> Once xf86RandR12LoadPalette() has been called during server
>>> startup, all palette and/or gamma table updates go through
>>> xf86RandR12CrtcComputeGamma() to combine color palette
>>> updates with gamma table updates into a proper hardware lut
>>> for upload into the hw via the .gamma_set function/ioctl,
>>> passing in a palette with palette_red/green/blue_size == the
>>> size given by the visuals red/green/blueMask, which will
>>> be == 1024 for a depth 30 screen.
>>>
>>> That in turn is a problem, because the size of the hw lut
>>> crtc->gamma_size is fixed to 256 slots on all kms-drivers
>>> when using the legacy gamma_set ioctl, but
>>> xf86RandR12CrtcComputeGamma() can only handle palettes of a
>>> size <= the hw lut size. As the palette size of 1024 is greater
>>> than the hw lut size of 256, the code silently fails
>>> (gamma_slots == 0 in xf86RandR12CrtcComputeGamma()).
>>>
>>> Skipping xf86HandleColormaps() on a depth > 24 screen disables
>>> color palette handling, but keeps at least gamma table updates
>>> via xf86vidmode extension and RandR working.
>>
>> Sort of... It means xf86VidMode and RandR call directly into the driver
>> to set their LUTs, with no coordination between them, so whichever calls
>> into the driver last wins and clobbers the HW LUT.
> 
> Wouldn't that be desirable behavior in this case, assuming the client
> that calls last is the one that wants something more specific?

If it was that simple... :)

Imagine you use something like Night Light / redshift which uses
xf86VidMode, and some kind of per-monitor gamma calibration tool which
uses RandR. Surely you want to see the combination of the two
transformations, not only one or the other, depending on which one has
ended up calling into the driver last (which could result in
flip-flopping between the two transformations, depending on how often
each tool (re-)sets its LUT).


>> It would be better to fix xf86RandR12CrtcComputeGamma instead.
> 
> But how? The current code can upsample an input palette < hw lut by
> replicating input values onto multiple hw slots, which makes perfect
> sense. But downsampling a bigger input palette, e.g., by just picking
> every n'th slot, seems problematic to me. You lose information from the
> palette in a way that might not be at all what the application wanted if
> it went to the trouble of creating a custom palette, assuming any apps
> would do anything meaningful with palettes on a depth 30 screen in the
> first place.

You're right that the downsampling could theoretically be a problem. But
in practice, the LUTs should usually correspond to some kind of more or
less smooth curve, and I'm told display hardware tends to interpolate
between the LUT entries.


> Unless the application just used the default palette or a
> truecolor visual, like probably most do nowadays, which i assume would
> be an identity mapping, so it doesn't matter if a palette is applied at
> all?

No colormaps means e.g. the gamma sliders in some games don't work.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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] Fix null-pointer exception in open_restricted()

2018-02-09 Thread Peter Hutterer

On Fri, Feb 09, 2018 at 01:28:39AM -0600, Jeff Smith wrote:
> If the path passed to open_restricted() is null, it results in a
> segfault when passing it to strneq.

weird, but imo this really needs to (also?) be fixed in libinput, calling
open for a NULL path indicates a libinput bug. We should never call
open_restricted for something that's NULL, it stops us from having decent
error messages.

Cheers,
   Peter

> 
> Return an error code from open_restricted() when path is null.  This
> leaves it up to the calling function to provide an error message.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1536633
> https://bugzilla.redhat.com/show_bug.cgi?id=1539046
> https://bugzilla.redhat.com/show_bug.cgi?id=1539783
> https://bugzilla.redhat.com/show_bug.cgi?id=1540662
> https://bugs.freedesktop.org/show_bug.cgi?id=104278
> 
> Signed-off-by: Jeff Smith 
> ---
>  src/xf86libinput.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/xf86libinput.c b/src/xf86libinput.c
> index 5727040..67577f4 100644
> --- a/src/xf86libinput.c
> +++ b/src/xf86libinput.c
> @@ -2208,6 +2208,9 @@ open_restricted(const char *path, int flags, void *data)
>   InputInfoPtr pInfo;
>   int fd = -1;
>  
> + if (path == NULL)
> + return -EFAULT;
> +
>   /* Special handling for sysfs files (used for pad LEDs) */
>   if (strneq(path, "/sys/", 5)) {
>   fd = open(path, flags);
> -- 
> 2.14.3
 
___
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] Correct xorg_list_is_empty return value description

[PATCH xserver] Correct xorg_list_is_empty return value description The helper xorg_list_is_empty returns True when the list is empty and not when it contains one or more elements.

[RFC v3 0/3] xwayland: Add support for eglstreams

[RFC v3 3/3] xwayland: Add glamor egl_backend for EGLStreams

[RFC v3 1/3] xwayland: Decouple GBM from glamor

[RFC v3 2/3] xwayland: Add xwayland-config.h

Re: [PATCH xserver 5/5] glamor: Enable composite acceleration for rgb10 formats.

Re: [PATCH xserver] glx: Only assign 8 bpc fbconfigs for composite visuals.

2018 X.Org Board of Directors Elections Nomination period is NOW

Re: [PATCH xserver 1/5] modesetting: Don't call xf86HandleColorMaps() at screen depth 30.

Re: [PATCH xserver] glx: Only assign 8 bpc fbconfigs for composite visuals.

Re: [PATCH xserver 1/5] modesetting: Don't call xf86HandleColorMaps() at screen depth 30.

Re: [PATCH] Fix null-pointer exception in open_restricted()

13 matches

Site Navigation

Mail list logo

Footer information