[ANNOUNCE] xorg-server 1.19.6

2017-12-20 Thread Adam Jackson 
Yet another collection of fixes from master. There will likely be at
least one more 1.19.x release in 2018 as there are still a number of
unreviewed patches pending. Until then, happy new year.

Adam Jackson (10):
  xfixes: Remove the CursorCurrent array
  glx: Fix typos that break GLX_ARB_context_flush_control
  glx: Only flush indirect contexts in MakeCurrent (v2)
  glx: Fix glXQueryContext for GLX_FBCONFIG_ID and GLX_RENDER_TYPE (v2)
  composite: Remove a misleading comment
  composite: Export compIsAlternateVisual
  composite: Make compIsAlternateVisual safe even if Composite is off
  glx: Send GLX_VISUAL_SELECT_GROUP_SGIX attribute for visuals
  glx: Move Composite's synthetic visuals to a different select group
  xserver 1.19.6

Alex Goins (1):
  ramdac: Check ScreenPriv != NULL in xf86ScreenSetCursor()

Daniel Martin (4):
  modesetting: Fix potential buffer overflow
  test: input: Fix used uninitialized warning in dix_event_to_core
  test: signal-logging: Fix looping signed number tests
  os/xdmcp: Honour -once when session is dead

Eric Anholt (1):
  xkb: Print the xkbcomp path being executed when we fail to compile.

Giuseppe Bilotta (3):
  xkb: initialize tsyms
  randr: ProcRRGetOutputInfo: initialize memory
  randr: rrGetScreenResources: initialize memory

Hector Martin (1):
  edid: fix off-by-one error in CEA mode numbering

Michel Dänzer (1):
  present: Only send PresentCompleteNotify events to the presenting client

Nikolay Martynov (1):
  XShmGetImage: fix censoring

Olivier Fourdan (2):
  xwayland: Fix non-argb cursor conversion
  dix: avoid deferencing NULL PtrCtrl

Peter Hutterer (1):
  config/udev: consider ID_INPUT_FOO=0 as 'unset'

Thomas Hellstrom (3):
  glx: Work around a GLX_OML swap method in older dri drivers
  glx: Fix visual fbconfig matching with respect to swap method
  glx: Duplicate relevant fbconfigs for compositing visuals

Tomasz Śniatowski (1):
  os: Fix strtok/free crash in ComputeLocalClient

git tag: xorg-server-1.19.6

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.bz2
MD5:  3e4ff034a331aed2322b078694a8  xorg-server-1.19.6.tar.bz2
SHA1: 2dd560ac49bdbda7f67166546af43541fabf517f  xorg-server-1.19.6.tar.bz2
SHA256: a732502f1db000cf36a376cd0c010ffdbf32ecdd7f1fa08ba7f5bdf9601cc197  
xorg-server-1.19.6.tar.bz2
SHA512: 
38519a8d0af9dd034045fc346959496dd718fa59b6188307974797a1cd9c349deb54987f6232ea8396baf810dcc710c0ff191f76ed2186cae4d44921b3680412
  xorg-server-1.19.6.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.gz
MD5:  ada013becbe850b92e2a8433dfb2cfe6  xorg-server-1.19.6.tar.gz
SHA1: f58b318bd17fe3af41ebf32d5a22da5dc667009e  xorg-server-1.19.6.tar.gz
SHA256: 3c0e4a354a6b1d5d357b121357946ee8ffdb2f52158b2e63e105be9cef013168  
xorg-server-1.19.6.tar.gz
SHA512: 
0ee9e7a20bac7b3a9a7730fc453a8b1f146e36f774721c7f69f723976c5cb456b18ce27bba71605995a8fc087518e462f06deb52f5145b87f28397f8e2cc1210
  xorg-server-1.19.6.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.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.6

2017-12-20 Thread Adam Jackson 
Yet another collection of fixes from master. There will likely be at
least one more 1.19.x release in 2018 as there are still a number of
unreviewed patches pending. Until then, happy new year.

Adam Jackson (10):
  xfixes: Remove the CursorCurrent array
  glx: Fix typos that break GLX_ARB_context_flush_control
  glx: Only flush indirect contexts in MakeCurrent (v2)
  glx: Fix glXQueryContext for GLX_FBCONFIG_ID and GLX_RENDER_TYPE (v2)
  composite: Remove a misleading comment
  composite: Export compIsAlternateVisual
  composite: Make compIsAlternateVisual safe even if Composite is off
  glx: Send GLX_VISUAL_SELECT_GROUP_SGIX attribute for visuals
  glx: Move Composite's synthetic visuals to a different select group
  xserver 1.19.6

Alex Goins (1):
  ramdac: Check ScreenPriv != NULL in xf86ScreenSetCursor()

Daniel Martin (4):
  modesetting: Fix potential buffer overflow
  test: input: Fix used uninitialized warning in dix_event_to_core
  test: signal-logging: Fix looping signed number tests
  os/xdmcp: Honour -once when session is dead

Eric Anholt (1):
  xkb: Print the xkbcomp path being executed when we fail to compile.

Giuseppe Bilotta (3):
  xkb: initialize tsyms
  randr: ProcRRGetOutputInfo: initialize memory
  randr: rrGetScreenResources: initialize memory

Hector Martin (1):
  edid: fix off-by-one error in CEA mode numbering

Michel Dänzer (1):
  present: Only send PresentCompleteNotify events to the presenting client

Nikolay Martynov (1):
  XShmGetImage: fix censoring

Olivier Fourdan (2):
  xwayland: Fix non-argb cursor conversion
  dix: avoid deferencing NULL PtrCtrl

Peter Hutterer (1):
  config/udev: consider ID_INPUT_FOO=0 as 'unset'

Thomas Hellstrom (3):
  glx: Work around a GLX_OML swap method in older dri drivers
  glx: Fix visual fbconfig matching with respect to swap method
  glx: Duplicate relevant fbconfigs for compositing visuals

Tomasz Śniatowski (1):
  os: Fix strtok/free crash in ComputeLocalClient

git tag: xorg-server-1.19.6

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.bz2
MD5:  3e4ff034a331aed2322b078694a8  xorg-server-1.19.6.tar.bz2
SHA1: 2dd560ac49bdbda7f67166546af43541fabf517f  xorg-server-1.19.6.tar.bz2
SHA256: a732502f1db000cf36a376cd0c010ffdbf32ecdd7f1fa08ba7f5bdf9601cc197  
xorg-server-1.19.6.tar.bz2
SHA512: 
38519a8d0af9dd034045fc346959496dd718fa59b6188307974797a1cd9c349deb54987f6232ea8396baf810dcc710c0ff191f76ed2186cae4d44921b3680412
  xorg-server-1.19.6.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.gz
MD5:  ada013becbe850b92e2a8433dfb2cfe6  xorg-server-1.19.6.tar.gz
SHA1: f58b318bd17fe3af41ebf32d5a22da5dc667009e  xorg-server-1.19.6.tar.gz
SHA256: 3c0e4a354a6b1d5d357b121357946ee8ffdb2f52158b2e63e105be9cef013168  
xorg-server-1.19.6.tar.gz
SHA512: 
0ee9e7a20bac7b3a9a7730fc453a8b1f146e36f774721c7f69f723976c5cb456b18ce27bba71605995a8fc087518e462f06deb52f5145b87f28397f8e2cc1210
  xorg-server-1.19.6.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.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

Re: [PATCH] glx: do not pick sRGB config for 32-bit RGBA visual

2017-12-20 Thread Adam Jackson 
On Mon, 2017-12-11 at 07:53 +0200, Tapani Pälli wrote:
> Hi;
> 
> Any comments? Without this change there will be issues with certain 
> Linux desktops when distributions start to use Mesa 17.4.

I've merged Thomas' GLX visual setup changes to the 1.19 branch since
at least fdobz#102086 has a positive confirmation of the fix and I'm
already late in delivering 1.19.6. This change could still be correct
but I didn't have much success in reproducing the issue to begin with;
maybe I just don't know what I'm looking for.

- 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#884846: xserver-xorg-video-radeon: xrandr hang on resolution setup after xorg has been started

2017-12-20 Thread Michel Dänzer 
On 2017-12-20 12:17 PM, Angelo Dureghello wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:7.8.0-1+b1
> Severity: grave
> Justification: renders package unusable

"renders the package unusable" in this context means the package cannot
be used for its intended purpose at all by anyone, which isn't the case.


> Dear Maintainer,
> 
> In xserver-xorg-video-radeon v.1.7.10.0-1 i am observing the following issue:
> 
> after xorg has been started, and openbox-session is called, xrandr seems to
> hang leaving interface with mouse pointer only, but not usable.
> 
> The line causing the issue is :
> (sleep 1s && xrandr --output VGA-0 --off --output DVI-0 --primary --mode
> 2560x1440 --output HDMI-0 --mode 1920x1080 --right-of DVI-0) &

When it hangs, can you attach gdb to the Xorg process and get a
backtrace? See
https://www.x.org/wiki/Development/Documentation/ServerDebugging/ for
detailed information about how this can be done. Make sure the
xserver-xorg-core-dbgsym and xserver-xorg-video-radeon-dbg packages are
installed.


> If i roll back to v.1.7.8.0.1+b1 version all works fine as usual and expected.

Can you use git bisect to determine which change introduced the problem?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [RFC xserver 0/1] Xwayland to send more accurate damage

2017-12-20 Thread Michel Dänzer 
On 2017-12-20 12:18 PM, Pekka Paalanen wrote:
> 
> - What X11 applications would be good to analyze for the drawing (damage) they
>   produce?

Some xscreensaver hacks can cause lots of tiny damage rectangles, e.g.
interaggregate or cloudlife.


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

[RFC xserver 0/1] Xwayland to send more accurate damage

2017-12-20 Thread Pekka Paalanen 
From: Pekka Paalanen 

Hi,

currently Xwayland collapses all wl_surface damage into a single bounding
rectangle. If the actual damage area is just a fraction of the sent damage
area, this will cause massive extra work in the Wayland compositor. The effect
is most notable in software rendered Wayland compositors. However, I would not
be surprised if there were measurable benefits for GPU accelerated Wayland
compositors, particularly if Xwayland was still software rendered but also with
GLAMOR, on low-end systems and large screens.

The motivation for this RFC is a real world use case with Weston/pixman as the
compositor and a proprietary X11 application in fullscreen. An equivalent patch
was measured to reduce Weston's CPU usage down to one third or one quarter
compared to without the patch. In steady state animation that was roughly from
0.3-0.4 CPUs down to 0.1 CPUs consumed by Weston which was a quite significant
portion of the total CPU power available.

The case was originally discussed on June 28, 2017, on #xorg-devel, but I
couldn't work much on it then.

The patch here is crude: send up to 500 rectangles of accurate damage but if
more, fall back to sending the bounding box. The reason to limit the number of
rectangles is that if the Wayland connection overflows, it will abort Xwayland.

Sending (more) accurate damage increases the risk of Xwayland aborting, so
limiting the number of rectangles is not just a performance question. However,
solving the overflow problem is not the goal here - I just try to mitigate the
risk.

The approach in the patch is problematic, because it uses a single hard-coded
threshold without much justification: the threshold was found by experimenting
with a proprietary application, and if I recall right, 300 was a sufficient
limit while 150 was not, so it was not a case of just a few rectangles in the
damage region.

An idea by ajax was to compute the ratio of accurate damage area vs. the
boundingbox area and use that percentage as a fixed threshold. The idea is nice
and simple, but I think it also needs a limit on the number of rectangles to
reduce the overflow risk.

I have been thinking about an optimization based approach, where one would
essentially assign relative costs to each pixel of extra damage added and each
rectangle sent and attempt to minimize the total cost by merging rectangles
into bigger rectangles before sending.

The questions:

- Which of the three approaches or something else would be sufficient for
  upstream?

- What testing should I perform since sending significantly more Wayland
  requests is risky?

- What X11 applications would be good to analyze for the drawing (damage) they
  produce?

If we need anything more complicated than what is in this patch, then I would
probably like to record the damage regions from various apps to gather a data
set to develop on. Unless you think it's not necessary?


Thanks,
pq

ps. I'll be on holidays until Jan 11, so might not reply until then.

Pekka Paalanen (1):
  xwayland: reduce over-damage

 hw/xwayland/xwayland.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

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

[RFC xserver 1/1] xwayland: reduce over-damage

2017-12-20 Thread Pekka Paalanen 
From: Pekka Paalanen 

If an X11 app draws a little here, some there, and a tiny bit in the
opposite corner, using RegionExtents for the damage to be sent to the
Wayland compositor will cause massive over-damaging.

However, we cannot blindly send an arbitrary number of damage
rectangles, because there is a risk of overflowing the Wayland
connection. If that happens, it triggers an abort in libwayland-client.

Try to be more accurate with the damage by sending up to 500 rectangles
per window, and fall back to extents otherwise. The number is completely
arbitrary.

Signed-off-by: Pekka Paalanen 
---
 hw/xwayland/xwayland.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index c5a3ae7ae..383680d7a 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -629,6 +629,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
 BoxPtr box;
 struct wl_buffer *buffer;
 PixmapPtr pixmap;
+int i;
 
 assert(!xwl_window->frame_callback);
 
@@ -644,9 +645,20 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
 
 wl_surface_attach(xwl_window->surface, buffer, 0, 0);
 
-box = RegionExtents(region);
-wl_surface_damage(xwl_window->surface, box->x1, box->y1,
-box->x2 - box->x1, box->y2 - box->y1);
+/* Arbitrary limit to try to avoid flooding the Wayland
+ * connection. If we flood it too much anyway, this could
+ * abort in libwayland-client.
+ */
+if (RegionNumRects(region) > 500) {
+box = RegionExtents(region);
+wl_surface_damage(xwl_window->surface, box->x1, box->y1,
+  box->x2 - box->x1, box->y2 - box->y1);
+} else {
+box = RegionRects(region);
+for (i = 0; i < RegionNumRects(region); i++, box++)
+wl_surface_damage(xwl_window->surface, box->x1, box->y1,
+  box->x2 - box->x1, box->y2 - box->y1);
+}
 
 xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
 wl_callback_add_listener(xwl_window->frame_callback, _listener, 
xwl_window);
-- 
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