Re: [PATCH] glx: Duplicate relevant fbconfigs for compositing visuals

2017-10-12 Thread Thomas Hellstrom 

Hi,

On 10/12/2017 10:32 PM, Adam Jackson wrote:

On Thu, 2017-10-12 at 15:06 +0200, Thomas Hellstrom wrote:

Ping?

If we're going to do this, and I guess we have to, I'd like to see two
changes:

1) Don't duplicate single-buffered fbconfigs


OK. I was trying to figure out what Nvidia was doing here, and they 
appear to expose

both single-buffer and sRGB 32-bit visuals.


2) Point all these fbconfigs at the same visual


The problem with doing that is that the glx visual pointed to by the 
fbconfig might have completely
different glx traits compared to the original fbconfig. I'm not sure 
whether that will cause any
problems but I guess it might be confusing. Again, looking at what 
Nvidia does, they expose a

number of 32-bit fbconfigs.

The follow-up RFC patch tries to reduce the number of identical GLX 
visuals, though.


Let me know whether you think we should go the nvidia way or try to 
expose as little as possible.


Another question that has surfaced is the criterion we use to determine 
whether a visual should be compositing or not.
In the patch I've considered 32-bit visuals as compositing. But looking 
at older dri1 client side code, it considers all

visuals with depth != DefaultDepth(dpy, screen) as compositing.

Thanks,
Thomas




- 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 1/2] os: Add epoll-like pollset implementation for AIX

2017-10-12 Thread Keith Packard 
Peter Harris  writes:

> AIX's poll only allows FD_SETSIZE entries in the fd list, which is
> insufficient for expanded MaxClients.

I can't evaluate whether these patches actually do the right thing, but
they shouldn't affect systems which don't support the necessary
functionality. I assume someone might review the Solaris patch, but is
there anyone who can review the AIX patch?

For the pair:

Acked-by: Keith Packard 

-- 
-keith


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

[PATCH xserver 2/2] os: Add epoll-like port implementation for Solaris

2017-10-12 Thread Peter Harris 
x11perf -noop with 200 xlogos connected is slightly faster with ports:

  before   after Operation
--   -   
1840.0   1920.0 (1.04)   X protocol NoOperation

Signed-off-by: Peter Harris 
---
 include/meson.build |   1 +
 os/ospoll.c | 128 +---
 2 files changed, 122 insertions(+), 7 deletions(-)

diff --git a/include/meson.build b/include/meson.build
index e0ebee258..8eec9ce36 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -126,6 +126,7 @@ conf_data.set('HAVE_MMAP', cc.has_function('mmap'))
 conf_data.set('HAVE_POLL', cc.has_function('poll'))
 conf_data.set('HAVE_POLLSET_CREATE', cc.has_function('pollset_create'))
 conf_data.set('HAVE_POSIX_FALLOCATE', cc.has_function('posix_fallocate'))
+conf_data.set('HAVE_PORT_CREATE', cc.has_function('port_create'))
 conf_data.set('HAVE_REALLOCARRAY', cc.has_function('reallocarray', 
dependencies: libbsd_dep))
 conf_data.set('HAVE_SETEUID', cc.has_function('seteuid'))
 conf_data.set('HAVE_SETITIMER', cc.has_function('setitimer'))
diff --git a/os/ospoll.c b/os/ospoll.c
index 4a59a5e6b..db9e73811 100644
--- a/os/ospoll.c
+++ b/os/ospoll.c
@@ -38,6 +38,12 @@
 #define HAVE_OSPOLL 1
 #endif
 
+#if !HAVE_OSPOLL && defined(HAVE_PORT_CREATE)
+#include 
+#define PORT1
+#define HAVE_OSPOLL 1
+#endif
+
 #if !HAVE_OSPOLL && defined(HAVE_EPOLL_CREATE1)
 #include 
 #define EPOLL   1
@@ -71,7 +77,7 @@ struct ospoll {
 
 #endif
 
-#if EPOLL
+#if EPOLL || PORT
 #include 
 
 /* epoll-based implementation */
@@ -128,7 +134,7 @@ ospoll_find(struct ospoll *ospoll, int fd)
 
 while (lo <= hi) {
 int m = (lo + hi) >> 1;
-#if EPOLL
+#if EPOLL || PORT
 int t = ospoll->fds[m]->fd;
 #endif
 #if POLL || POLLSET
@@ -145,7 +151,7 @@ ospoll_find(struct ospoll *ospoll, int fd)
 return -(lo + 1);
 }
 
-#if EPOLL
+#if EPOLL || PORT
 static void
 ospoll_clean_deleted(struct ospoll *ospoll)
 {
@@ -205,6 +211,17 @@ ospoll_create(void)
 }
 return ospoll;
 #endif
+#if PORT
+struct ospoll *ospoll = calloc(1, sizeof (struct ospoll));
+
+ospoll->epoll_fd = port_create();
+if (ospoll->epoll_fd < 0) {
+free (ospoll);
+return NULL;
+}
+xorg_list_init(>deleted);
+return ospoll;
+#endif
 #if EPOLL
 struct ospoll   *ospoll = calloc(1, sizeof (struct ospoll));
 
@@ -232,7 +249,7 @@ ospoll_destroy(struct ospoll *ospoll)
 free(ospoll);
 }
 #endif
-#if EPOLL
+#if EPOLL || PORT
 if (ospoll) {
 assert (ospoll->num == 0);
 close(ospoll->epoll_fd);
@@ -282,6 +299,41 @@ ospoll_add(struct ospoll *ospoll, int fd,
 ospoll->fds[pos].callback = callback;
 ospoll->fds[pos].data = data;
 #endif
+#if PORT
+struct ospollfd *osfd;
+
+if (pos < 0) {
+osfd = calloc(1, sizeof (struct ospollfd));
+if (!osfd)
+return FALSE;
+
+if (ospoll->num >= ospoll->size) {
+struct ospollfd **new_fds;
+int new_size = ospoll->size ? ospoll->size * 2 : MAXCLIENTS * 2;
+
+new_fds = reallocarray(ospoll->fds, new_size, sizeof 
(ospoll->fds[0]));
+if (!new_fds) {
+free (osfd);
+return FALSE;
+}
+ospoll->fds = new_fds;
+ospoll->size = new_size;
+}
+
+osfd->fd = fd;
+osfd->xevents = 0;
+
+pos = -pos - 1;
+array_insert(ospoll->fds, ospoll->num, sizeof (ospoll->fds[0]), pos);
+ospoll->fds[pos] = osfd;
+ospoll->num++;
+} else {
+osfd = ospoll->fds[pos];
+}
+osfd->data = data;
+osfd->callback = callback;
+osfd->trigger = trigger;
+#endif
 #if EPOLL
 struct ospollfd *osfd;
 
@@ -378,6 +430,16 @@ ospoll_remove(struct ospoll *ospoll, int fd)
 array_delete(ospoll->fds, ospoll->num, sizeof (ospoll->fds[0]), pos);
 ospoll->num--;
 #endif
+#if PORT
+struct ospollfd *osfd = ospoll->fds[pos];
+port_dissociate(ospoll->epoll_fd, PORT_SOURCE_FD, fd);
+
+array_delete(ospoll->fds, ospoll->num, sizeof (ospoll->fds[0]), pos);
+ospoll->num--;
+osfd->callback = NULL;
+osfd->data = NULL;
+xorg_list_add(>deleted, >deleted);
+#endif
 #if EPOLL
 struct ospollfd *osfd = ospoll->fds[pos];
 struct epoll_event ev;
@@ -400,6 +462,19 @@ ospoll_remove(struct ospoll *ospoll, int fd)
 }
 }
 
+#if PORT
+static void
+epoll_mod(struct ospoll *ospoll, struct ospollfd *osfd)
+{
+int events = 0;
+if (osfd->xevents & X_NOTIFY_READ)
+events |= EPOLLIN;
+if (osfd->xevents & X_NOTIFY_WRITE)
+events |= EPOLLOUT;
+port_associate(ospool->epoll_fd, PORT_SOURCE_FD, osfd->fd, events, osfd);
+}
+#endif
+
 #if EPOLL
 static void
 epoll_mod(struct ospoll *ospoll, struct ospollfd *osfd)
@@ -436,7 +511,7 @@ ospoll_listen(struct ospoll *ospoll, int

[PATCH xserver 1/2] os: Add epoll-like pollset implementation for AIX

2017-10-12 Thread Peter Harris 
AIX's poll only allows FD_SETSIZE entries in the fd list, which is
insufficient for expanded MaxClients.

As a bonus, x11perf -noop with ~250 xlogos connected is slightly faster
with pollset:

 before  after Operation
-      
575.0   599.0 (1.04)   X protocol NoOperation

Signed-off-by: Peter Harris 
---
 include/meson.build |   1 +
 os/ospoll.c | 146 +++-
 2 files changed, 146 insertions(+), 1 deletion(-)

diff --git a/include/meson.build b/include/meson.build
index 5d746eb70..e0ebee258 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -124,6 +124,7 @@ conf_data.set('HAVE_GETPROGNAME', 
cc.has_function('getprogname'))
 conf_data.set('HAVE_GETZONEID', cc.has_function('getzoneid'))
 conf_data.set('HAVE_MMAP', cc.has_function('mmap'))
 conf_data.set('HAVE_POLL', cc.has_function('poll'))
+conf_data.set('HAVE_POLLSET_CREATE', cc.has_function('pollset_create'))
 conf_data.set('HAVE_POSIX_FALLOCATE', cc.has_function('posix_fallocate'))
 conf_data.set('HAVE_REALLOCARRAY', cc.has_function('reallocarray', 
dependencies: libbsd_dep))
 conf_data.set('HAVE_SETEUID', cc.has_function('seteuid'))
diff --git a/os/ospoll.c b/os/ospoll.c
index ca14a0c8c..4a59a5e6b 100644
--- a/os/ospoll.c
+++ b/os/ospoll.c
@@ -32,6 +32,12 @@
 #include "ospoll.h"
 #include "list.h"
 
+#if !HAVE_OSPOLL && defined(HAVE_POLLSET_CREATE)
+#include 
+#define POLLSET 1
+#define HAVE_OSPOLL 1
+#endif
+
 #if !HAVE_OSPOLL && defined(HAVE_EPOLL_CREATE1)
 #include 
 #define EPOLL   1
@@ -44,6 +50,27 @@
 #define HAVE_OSPOLL 1
 #endif
 
+#if POLLSET
+
+// pollset-based implementation (as seen on AIX)
+struct ospollfd {
+int fd;
+int xevents;
+short   revents;
+enum ospoll_trigger trigger;
+void(*callback)(int fd, int xevents, void *data);
+void*data;
+};
+
+struct ospoll {
+pollset_t   ps;
+struct ospollfd *fds;
+int num;
+int size;
+};
+
+#endif
+
 #if EPOLL
 #include 
 
@@ -104,7 +131,7 @@ ospoll_find(struct ospoll *ospoll, int fd)
 #if EPOLL
 int t = ospoll->fds[m]->fd;
 #endif
-#if POLL
+#if POLL || POLLSET
 int t = ospoll->fds[m].fd;
 #endif
 
@@ -168,6 +195,16 @@ array_delete(void *base, size_t num, size_t size, size_t 
pos)
 struct ospoll *
 ospoll_create(void)
 {
+#if POLLSET
+struct ospoll *ospoll = calloc(1, sizeof (struct ospoll));
+
+ospoll->ps = pollset_create(-1);
+if (ospoll->ps < 0) {
+free (ospoll);
+return NULL;
+}
+return ospoll;
+#endif
 #if EPOLL
 struct ospoll   *ospoll = calloc(1, sizeof (struct ospoll));
 
@@ -187,6 +224,14 @@ ospoll_create(void)
 void
 ospoll_destroy(struct ospoll *ospoll)
 {
+#if POLLSET
+if (ospoll) {
+assert (ospoll->num == 0);
+pollset_destroy(ospoll->ps);
+free(ospoll->fds);
+free(ospoll);
+}
+#endif
 #if EPOLL
 if (ospoll) {
 assert (ospoll->num == 0);
@@ -213,6 +258,30 @@ ospoll_add(struct ospoll *ospoll, int fd,
void *data)
 {
 int pos = ospoll_find(ospoll, fd);
+#if POLLSET
+if (pos < 0) {
+if (ospoll->num == ospoll->size) {
+struct ospollfd *new_fds;
+int new_size = ospoll->size ? ospoll->size * 2 : MAXCLIENTS * 2;
+
+new_fds = reallocarray(ospoll->fds, new_size, sizeof 
(ospoll->fds[0]));
+if (!new_fds)
+return FALSE;
+ospoll->fds = new_fds;
+ospoll->size = new_size;
+}
+pos = -pos - 1;
+array_insert(ospoll->fds, ospoll->num, sizeof (ospoll->fds[0]), pos);
+ospoll->num++;
+
+ospoll->fds[pos].fd = fd;
+ospoll->fds[pos].xevents = 0;
+ospoll->fds[pos].revents = 0;
+}
+ospoll->fds[pos].trigger = trigger;
+ospoll->fds[pos].callback = callback;
+ospoll->fds[pos].data = data;
+#endif
 #if EPOLL
 struct ospollfd *osfd;
 
@@ -301,6 +370,14 @@ ospoll_remove(struct ospoll *ospoll, int fd)
 
 pos = ospoll_find(ospoll, fd);
 if (pos >= 0) {
+#if POLLSET
+struct ospollfd *osfd = >fds[pos];
+struct poll_ctl ctl = { .cmd = PS_DELETE, .fd = fd };
+pollset_ctl(ospoll->ps, , 1);
+
+array_delete(ospoll->fds, ospoll->num, sizeof (ospoll->fds[0]), pos);
+ospoll->num--;
+#endif
 #if EPOLL
 struct ospollfd *osfd = ospoll->fds[pos];
 struct epoll_event ev;
@@ -346,6 +423,19 @@ ospoll_listen(struct ospoll *ospoll, int fd, int xevents)
 int pos = ospoll_find(ospoll, fd);
 
 if (pos >= 0) {
+#if POLLSET
+struct poll_ctl ctl = { .cmd = PS_MOD, .fd = fd };
+if (xevents & X_NOTIFY_READ) {
+ctl.events |= POLLIN;
+ospoll->fds[pos].revents &= ~POLLIN;
+}
+if (xevents &

Re: [PATCH] glx: Duplicate relevant fbconfigs for compositing visuals

2017-10-12 Thread Adam Jackson 
On Thu, 2017-10-12 at 15:06 +0200, Thomas Hellstrom wrote:
> Ping?

If we're going to do this, and I guess we have to, I'd like to see two
changes:

1) Don't duplicate single-buffered fbconfigs
2) Point all these fbconfigs at the same visual

- 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] XShmGetImage: fix censoring

2017-10-12 Thread Adam Jackson 
On Wed, 2017-10-11 at 21:56 -0400, Nikolay Martynov wrote:
> Hi.
> 
> One more kind ping on this. It has been sent quite a long time ago
> without any reply. It would really appreciate if someone could let me
> know if this is a correct mailing list or not?

Thanks for your patience, this looks good. Or at least, it looks
better; the code is still kind of wrong, in that it's fetching the
image and _then_ censoring, but since the destination is shared memory
a client could potentially win the race and get some bits out that it
shouldn't. And we're doing this censorship unilaterally, which seems
like excess work if the windows clipping the one we're GetImage'ing
from belong to the same client.

Still, better than before, merged, thanks!

- 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 2/2] meson: Fix linkage of loadable modules for PE/COFF

2017-10-12 Thread Adam Jackson 
On Tue, 2017-10-10 at 14:28 +0100, Jon Turney wrote:
> For the loadable modules it makes sense to build for PE/COFF targets, link
> those loadable modules with the import library for the Xorg executable, so
> that symbols provided by the executable can be satisfied at link time (as
> required by PE/COFF).
> 
> Since this uses the syntax of using the returned build target object from an
> executable() with an implib: kwarg to link_with:, introduced in meson 0.42
> and a syntax error with older meson, also update the minimum meson version
> which we require in project() to that.

Merged, thanks.

- 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] meson: Don't forget to define DEBUG!

2017-10-12 Thread Adam Jackson 
On Wed, 2017-10-11 at 19:15 -0400, Lyude Paul wrote:
> Signed-off-by: Lyude Paul 

Nak. One, because debugoptimized appears to be the default build type,
and I'm not really convinced it makes sense to enable all the random
debugging bits in the normal case, at least not without putting in some
effort to rationalize the existing "debug" code. (grep for DebugF() and
see just how arbitrary things are.)

But also two because it breaks the build:

../hw/xfree86/fbdevhw/fbdevhw.c:123:10: error: #if with no expression
 #if DEBUG
  ^
../hw/xfree86/fbdevhw/fbdevhw.c: In function ‘fbdevHWSetMode’:
../hw/xfree86/fbdevhw/fbdevhw.c:469:10: error: #if with no expression
 #if DEBUG
  ^
../hw/xfree86/fbdevhw/fbdevhw.c:489:10: error: #if with no expression
 #if DEBUG
  ^

- 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

[ANNOUNCE] xorg-server 1.19.5

2017-10-12 Thread Adam Jackson 
One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017-
12176 through 2017-12187. C is a terrible language, please stop writing
code in it.

Adam Jackson (2):
  Revert "xf86-video-modesetting: Add ms_queue_vblank helper [v3]"
  xserver 1.19.5

Michal Srb (1):
  os: Make sure big requests have sufficient length.

Nathan Kidd (7):
  Unvalidated lengths
  xfixes: unvalidated lengths (CVE-2017-12183)
  hw/xfree86: unvalidated lengths
  Xi: integer overflow and unvalidated length in 
(S)ProcXIBarrierReleasePointer
  Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178)
  dbe: Unvalidated variable-length request in ProcDbeGetVisualInfo 
(CVE-2017-12177)
  Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176)

git tag: xorg-server-1.19.5

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2
MD5:  4ac6feeae6790436ce9de879ca9a3bf8  xorg-server-1.19.5.tar.bz2
SHA1: 307d3405f709f7e41966c850b37deefe7f83eb9b  xorg-server-1.19.5.tar.bz2
SHA256: 18fffa8eb93d06d2800d06321fc0df4d357684d8d714315a66d8dfa7df251447  
xorg-server-1.19.5.tar.bz2
SHA512: 
928dea5850b98cd815004cfa133eca23cfa9521920c934c68a92787f2cae13cca1534eee772a4fb74b8ae8cb92662b5d68b95b834c8aa8ec57cd57cb4e5dd45c
  xorg-server-1.19.5.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.gz
MD5:  97ab05c006718d6d484e4e5fe1aec534  xorg-server-1.19.5.tar.gz
SHA1: 842cc1fbc26887698a70c6ad538bb07fa94b0130  xorg-server-1.19.5.tar.gz
SHA256: 1818068b6b86387ee0e392cbe28208ff949d253a1611d17bf2908961f3669b1c  
xorg-server-1.19.5.tar.gz
SHA512: 
34f10c22bc7e003245c423288c495ef98707d7ba23ff4207d6dfde32e917fd752acc285e65da39805e74cfa275a655b1b0bf07bb5d2bc82a773854a17bc81ded
  xorg-server-1.19.5.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.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

[ANNOUNCE] xorg-server 1.19.5

2017-10-12 Thread Adam Jackson 
One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017-
12176 through 2017-12187. C is a terrible language, please stop writing
code in it.

Adam Jackson (2):
  Revert "xf86-video-modesetting: Add ms_queue_vblank helper [v3]"
  xserver 1.19.5

Michal Srb (1):
  os: Make sure big requests have sufficient length.

Nathan Kidd (7):
  Unvalidated lengths
  xfixes: unvalidated lengths (CVE-2017-12183)
  hw/xfree86: unvalidated lengths
  Xi: integer overflow and unvalidated length in 
(S)ProcXIBarrierReleasePointer
  Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178)
  dbe: Unvalidated variable-length request in ProcDbeGetVisualInfo 
(CVE-2017-12177)
  Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176)

git tag: xorg-server-1.19.5

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2
MD5:  4ac6feeae6790436ce9de879ca9a3bf8  xorg-server-1.19.5.tar.bz2
SHA1: 307d3405f709f7e41966c850b37deefe7f83eb9b  xorg-server-1.19.5.tar.bz2
SHA256: 18fffa8eb93d06d2800d06321fc0df4d357684d8d714315a66d8dfa7df251447  
xorg-server-1.19.5.tar.bz2
SHA512: 
928dea5850b98cd815004cfa133eca23cfa9521920c934c68a92787f2cae13cca1534eee772a4fb74b8ae8cb92662b5d68b95b834c8aa8ec57cd57cb4e5dd45c
  xorg-server-1.19.5.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.gz
MD5:  97ab05c006718d6d484e4e5fe1aec534  xorg-server-1.19.5.tar.gz
SHA1: 842cc1fbc26887698a70c6ad538bb07fa94b0130  xorg-server-1.19.5.tar.gz
SHA256: 1818068b6b86387ee0e392cbe28208ff949d253a1611d17bf2908961f3669b1c  
xorg-server-1.19.5.tar.gz
SHA512: 
34f10c22bc7e003245c423288c495ef98707d7ba23ff4207d6dfde32e917fd752acc285e65da39805e74cfa275a655b1b0bf07bb5d2bc82a773854a17bc81ded
  xorg-server-1.19.5.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.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.5

2017-10-12 Thread Adam Jackson 
One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017-
12176 through 2017-12187. C is a terrible language, please stop writing
code in it.

Adam Jackson (2):
  Revert "xf86-video-modesetting: Add ms_queue_vblank helper [v3]"
  xserver 1.19.5

Michal Srb (1):
  os: Make sure big requests have sufficient length.

Nathan Kidd (7):
  Unvalidated lengths
  xfixes: unvalidated lengths (CVE-2017-12183)
  hw/xfree86: unvalidated lengths
  Xi: integer overflow and unvalidated length in 
(S)ProcXIBarrierReleasePointer
  Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178)
  dbe: Unvalidated variable-length request in ProcDbeGetVisualInfo 
(CVE-2017-12177)
  Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176)

git tag: xorg-server-1.19.5

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2
MD5:  4ac6feeae6790436ce9de879ca9a3bf8  xorg-server-1.19.5.tar.bz2
SHA1: 307d3405f709f7e41966c850b37deefe7f83eb9b  xorg-server-1.19.5.tar.bz2
SHA256: 18fffa8eb93d06d2800d06321fc0df4d357684d8d714315a66d8dfa7df251447  
xorg-server-1.19.5.tar.bz2
SHA512: 
928dea5850b98cd815004cfa133eca23cfa9521920c934c68a92787f2cae13cca1534eee772a4fb74b8ae8cb92662b5d68b95b834c8aa8ec57cd57cb4e5dd45c
  xorg-server-1.19.5.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.gz
MD5:  97ab05c006718d6d484e4e5fe1aec534  xorg-server-1.19.5.tar.gz
SHA1: 842cc1fbc26887698a70c6ad538bb07fa94b0130  xorg-server-1.19.5.tar.gz
SHA256: 1818068b6b86387ee0e392cbe28208ff949d253a1611d17bf2908961f3669b1c  
xorg-server-1.19.5.tar.gz
SHA512: 
34f10c22bc7e003245c423288c495ef98707d7ba23ff4207d6dfde32e917fd752acc285e65da39805e74cfa275a655b1b0bf07bb5d2bc82a773854a17bc81ded
  xorg-server-1.19.5.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.gz.sig

- ajax

signature.asc
Description: This is a digitally signed message part
___
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] meson: Add xkb_bin_dir option

2017-10-12 Thread Adam Jackson 
On Thu, 2017-10-12 at 09:35 +0100, Daniel Stone wrote:
> Hi,
> 
> On 11 October 2017 at 23:03, Lyude Paul  wrote:
> > Now that we can actually configure all of the directories xkb uses for
> > finding things, we can (finally, but only with meson) finally make it so
> > that with the correct meson configuration the Xserver will "just work"
> > without any additional changes to the installation prefix after
> > building.
> > 
> > For the people like me who have since scripted this part out of their
> > build process and forgotten about it, building and installing the X
> > server into a non-standard prefix has always required the following (or
> > something else that makes sure that X has a valid xkbcomp configuration)
> > commands be run right after doing the installation:
> > 
> > # start in root of prefix you installed X to
> > mkdir -pv share/X11/xkb/rules
> > ln -s /usr/share/X11/xkb/rules/evdev share/X11/xkb/rules/
> > rm -f bin/xkbcomp
> > ln -s /usr/bin/xkbcomp bin/
> > 
> > The one last piece of getting rid of this post-install junk is making
> > sure that we can control the directory that X uses for finding the
> > xkbcomp binary from meson so we can point it at the system provided
> > xkbcomp (/usr/bin/xkbcomp or similar). So, this patch adds a
> > configuration option for controlling this called xkb_bin_dir.
> 
> We really should've made xkbcomp ship a pkg-config file.

Should have?

https://cgit.freedesktop.org/xorg/app/xkbcomp/tree/xkbcomp.pc.in

> Reviewed-by: Daniel Stone 

remote: I: patch #181929 updated using rev 
10cba7d54668698741510374ee63dec7a3cc3647.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   b747da5e25..10cba7d546  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] meson: Don't forget to define DEBUG!

2017-10-12 Thread Jon Turney 

On 12/10/2017 00:15, Lyude Paul wrote:

Signed-off-by: Lyude Paul 
---
  include/meson.build | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/meson.build b/include/meson.build
index 90f8de3cb..8894885c6 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -196,6 +196,9 @@ conf_data.set('XvMCExtension', build_xv)
  
  conf_data.set('HAVE_SHA1_IN_LIBNETTLE', '1') # XXX
  
+enable_debugging = (get_option('buildtype') == 'debug') or (get_option('buildtype') == 'debugoptimized')


It seems you could also write this as:

enable_debugging = get_option('buildtype').startswith('debug')


___
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] glx: Duplicate relevant fbconfigs for compositing visuals

2017-10-12 Thread Thomas Hellstrom 

Ping?

On 10/03/2017 02:19 PM, Thomas Hellstrom wrote:

Ping?

On 09/27/2017 02:28 AM, Thomas Hellstrom wrote:

Previously, before GLX_OML_swap_method was fixed, both the X server and
client ignored the swapMethod fbconfig value, which meant that, if 
the dri

driver thought it exposed more than one swapMethod, it actually just
exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method
and restricting the choice for built-in visuals to a single swap method
that meant we didn't have that many fbconfigs to choose from when 
pairing
the compositing visual with an fbconfig, resulting in the fbconfig 
paired
with the compositing visual becoming too restrictive for some 
applications,

(at least for kwin). This problem would also happen if the dri driver
only exposed a single swap method to begin with.

So, to make sure the compositing visual gets a good enough fbconfig,
duplicate fbconfigs that are suitable for compositing visuals and make
sure these duplicated fbconfigs can be used only by compositing visuals.
For duplicated fbconfigs not paired with a compositing visual, construct
new compositing visuals, making compositing clients able to choose 
visuals

/ fbconfig more adapted to their needs.

This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING"
GLX visualtype.

Fixes: 4486d199bd3b ("glx: Fix visual fbconfig matching with respect to
   swap method")
Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D102806=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=vkuCexXu1LR8eO5b1Ah8cu0J1Xw2xvDa-Id1c2l1YzM=7kcfvmjf2zGuiPPqAk7gcOQGkmnFHowOOsXyUj9Yqfs= 
Signed-off-by: Thomas Hellstrom 

Tested-By: Nick Sarnie 
---
  glx/glxdricommon.c | 45 +
  glx/glxscreens.c   | 18 --
  glx/glxscreens.h   |  4 
  3 files changed, 61 insertions(+), 6 deletions(-)

diff --git a/glx/glxdricommon.c b/glx/glxdricommon.c
index 96f28d0..1879bfc 100644
--- a/glx/glxdricommon.c
+++ b/glx/glxdricommon.c
@@ -116,13 +116,15 @@ render_type_is_pbuffer_only(unsigned renderType)
  static __GLXconfig *
  createModeFromConfig(const __DRIcoreExtension * core,
   const __DRIconfig * driConfig,
- unsigned int visualType)
+ unsigned int visualType,
+ GLboolean duplicateForComp)
  {
  __GLXDRIconfig *config;
  GLint renderType = 0;
  unsigned int attrib, value, drawableType = GLX_PBUFFER_BIT;
  int i;
  +
  config = calloc(1, sizeof *config);
    config->driConfig = driConfig;
@@ -180,6 +182,28 @@ createModeFromConfig(const __DRIcoreExtension * 
core,

  config->config.drawableType = drawableType;
  config->config.yInverted = GL_TRUE;
  +#ifdef COMPOSITE
+    /*
+ * Here we decide what fbconfigs will be duplicated for 
compositing.

+ * fgbconfigs marked with duplicatedForConf will be reserved for
+ * compositing visuals.
+ * It might look strange to do this decision this late when 
translation

+ * from a __DRIConfig is already done, but using the __DRIConfig
+ * accessor function becomes worse both with respect to code 
complexity

+ * and CPU usage.
+ */
+    if (duplicateForComp &&
+    (render_type_is_pbuffer_only(renderType) ||
+ config->config.rgbBits != 32 ||
+ config->config.visualRating != GLX_NONE ||
+ config->config.sampleBuffers != 0)) {
+    free(config);
+    return NULL;
+    }
+
+    config->config.duplicatedForComp = duplicateForComp;
+#endif
+
  return >config;
  }
  @@ -194,21 +218,34 @@ glxConvertConfigs(const __DRIcoreExtension * 
core,

  head.next = NULL;
    for (i = 0; configs[i]; i++) {
-    tail->next = createModeFromConfig(core, configs[i], 
GLX_TRUE_COLOR);
+    tail->next = createModeFromConfig(core, configs[i], 
GLX_TRUE_COLOR,

+  GL_FALSE);
  if (tail->next == NULL)
  break;
-
  tail = tail->next;
  }
    for (i = 0; configs[i]; i++) {
-    tail->next = createModeFromConfig(core, configs[i], 
GLX_DIRECT_COLOR);
+    tail->next = createModeFromConfig(core, configs[i], 
GLX_DIRECT_COLOR,

+  GL_FALSE);
  if (tail->next == NULL)
  break;
    tail = tail->next;
  }
  +#ifdef COMPOSITE
+    /* Duplicate fbconfigs for use with compositing visuals */
+    for (i = 0; configs[i]; i++) {
+    tail->next = createModeFromConfig(core, configs[i], 
GLX_TRUE_COLOR,

+  GL_TRUE);
+    if (tail->next == NULL)
+    continue;
+
+    tail = tail->next;
+    }
+#endif
+
  return head.next;
  }
  diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index f000e56..99bf6dd 100644
---

Re: [PATCH xserver] meson: Add xkb_bin_dir option

2017-10-12 Thread Daniel Stone 
Hi,

On 11 October 2017 at 23:03, Lyude Paul  wrote:
> Now that we can actually configure all of the directories xkb uses for
> finding things, we can (finally, but only with meson) finally make it so
> that with the correct meson configuration the Xserver will "just work"
> without any additional changes to the installation prefix after
> building.
>
> For the people like me who have since scripted this part out of their
> build process and forgotten about it, building and installing the X
> server into a non-standard prefix has always required the following (or
> something else that makes sure that X has a valid xkbcomp configuration)
> commands be run right after doing the installation:
>
> # start in root of prefix you installed X to
> mkdir -pv share/X11/xkb/rules
> ln -s /usr/share/X11/xkb/rules/evdev share/X11/xkb/rules/
> rm -f bin/xkbcomp
> ln -s /usr/bin/xkbcomp bin/
>
> The one last piece of getting rid of this post-install junk is making
> sure that we can control the directory that X uses for finding the
> xkbcomp binary from meson so we can point it at the system provided
> xkbcomp (/usr/bin/xkbcomp or similar). So, this patch adds a
> configuration option for controlling this called xkb_bin_dir.

We really should've made xkbcomp ship a pkg-config file.

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

Bug#878170: xserver-xorg-video-radeon: Fails to match video to vsync

2017-10-12 Thread Anton Ivanov 
It tears in full screen with and without compositing in xfce



On 11 October 2017 09:40:59 BST, "Michel Dänzer"  wrote:
>On 10/10/17 07:50 PM, Anton Ivanov wrote:
>> Package: xserver-xorg-video-radeon
>> Version: 1:7.8.0-1+b1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> Radeon (and amdgpu for that matter) in stretch no longer match frames
>> to vsync correctly. This is observable with vdpau, opengl and plain
>> xvideo. 
>> 
>> This used to work correctly in jessie so this is a recent regression.
>> 
>> This is also observable in both full screen and windowed mode. The
>> bottom ~5-10% of the picture updates on the wrong vsycn which is
>> clearly visible especially in action sequences and animation.
>> 
>> Tested with vlc, mplayer, xine and other software in a variety of
>> output modes. I think I have eliminated other possible common factors
>> leaving the video driver (and/or firmware) the most likely culprit.
>
>The only possibilities for reliably avoiding tearing in Xorg have
>always
>been:
>
>1. Using a compositing manager which uses OpenGL for rendering
>2. Running an application in fullscreen, using page flipping (i.e. the
>  application must use something like OpenGL / VDPAU / VA-API / ... for
>   rendering / presentation, but not something like XVideo or even pure
>   X11)
>3. Enabling TearFree
>
>Note that 1.+2. are not sufficient when using rotation or other
>transforms via the RandR extension.
>
>
>Does your setup fall under any of these cases? If not, you may just
>have
>gotten lucky before.
>
>
>-- 
>Earthling Michel Dänzer   |  
>http://www.amd.com
>Libre software enthusiast | Mesa and X
>developer

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati