[ANNOUNCE] pthread-stubs 0.4

[Uli Schlachter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

pthread-stubs 0.4 is now available. This new release stops providing
stubs, but instead expects libc to do so. On platforms where this is
not the case, "-pthread" is injected via our pkg-config file instead.
This was done to make loading libpthread (indirectly) via dlopen()
work correctly in the presence of pthread-stubs.

Download:
  https://xcb.freedesktop.org/dist/libpthread-stubs-0.4.tar.bz2
  https://xcb.freedesktop.org/dist/libpthread-stubs-0.4.tar.gz

md5sum:
  48c1544854a94db0e51499cc3afd797f  libpthread-stubs-0.4.tar.bz2
  7d2734e604a3e2f6f665c420b835ab62  libpthread-stubs-0.4.tar.gz

sha1sum:
  c42503a2ae0067b2238b2f3fefc86656baa4dd8e  libpthread-stubs-0.4.tar.bz2
  4d5e2636a13d6cb0ae0d92ef9d0232a43fb47ff0  libpthread-stubs-0.4.tar.gz

sha256sum:
  libpthread-stubs-0.4.tar.bz2
  e4d05911a3165d3b18321cc067fdd2f023f06436e391c6a28dff618a78d2e733

  50d5686b79019ccea08bcbd7b02fe5a40634abcfd4146b6e75c6420cc170e9d9
  libpthread-stubs-0.4.tar.gz

Enjoy!
Uli
- -- 
Sent from my Game Boy.
-BEGIN PGP SIGNATURE-

iQFDBAEBCAAtFiEEK7MviP89HnbmgjA/IuQo68uPywYFAljIL1QPHHBzeWNob25A
em5jLmluAAoJECLkKOvLj8sGM5wH/ArVJMvJrh2DQemUsDihJFkZJnQhuUafKFUK
k3n4i0oYNtWWXrUGGlf74iCZh6Ng/9JDlcFlKLW5utHmnp1A9mWJs9yKiHOheTaE
Lun+mRqDiJzzTGInYDdOlgT4fSLCMdyKhaDO6HuBaccAMT8+stboSZIDKuXRowik
xFwuJ4Lokq8T5haJiydpog6pYPYeENrUswS19wEqQ3hgRhAjPVOsa+YyhrrPNu/D
EFudRbn48CfzxpDW/LU6fgwwD/vU7X56RMbMND8RFNWsDg7UOejCJI+kMd0CcDOM
aC0SwrS4X9X0//zEkoPSRCN835SJeoPHXSZQIDlQRKcjVDLgS5E=
=osiD
-END PGP SIGNATURE-
___
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: Video tearing with modesetting driver and Intel Sandybridge graphics

[Michel Dänzer]

On 14/03/17 07:52 PM, Tino Mettler wrote:
> Hi,
> 
> I get tearing video with the modesetting driver on a Debian Sid
> installation.

Which desktop environment are you using?


> It happens at least in VLC and Firefox in Gnome3 using HDMI output of
> the Sandybridge graphics.

In Firefox, you probably need to force hardware compositing by setting
layers.acceleration.force-enabled=true in about:config . Check what
about:support says for *_COMPOSITING.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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

`pkg-config --static --libs x11` unusable for static linking?

[xorg]

Hello list,

I'm trying to support clean-ish static linking of a small autotools and
libx11-using monitoring program via:

PKG_CONFIG="pkg-config --static" LDFLAGS="-static" ./configure

But linking fails on libdl and libpthread symbols:

$ gcc  -g -O2  -static -o vwm vwm-clickety.o vwm-composite.o vwm-context.o 
vwm-desktop.o vwm-key.o vwm-launch.o vwm-logo.o vwm-overlays.o vwm-screen.o 
vwm-vwm.o vwm-window.o vwm-xevent.o vwm-xserver.o vwm-xwindow.o -lXinerama 
-lXrandr -lXext -lXcomposite -lXdamage -lXfixes -lXrender -lX11 -lpthread -lxcb 
-lXau -lXdmcp  libvmon/libvmon.a 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(xim_trans.o):
 In function `_XimXTransSocketINETConnect':
(.text+0xe32): warning: Using 'getaddrinfo' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o):
 In function `open_library':
(.text+0x32): undefined reference to `dlopen'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o):
 In function `fetch_symbol':
(.text+0x61): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o):
 In function `fetch_symbol':
(.text+0x85): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `xcb_disconnect.part.0':
(.text+0x27): undefined reference to `pthread_mutex_destroy'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `xcb_connect_to_fd':
(.text+0x140): undefined reference to `pthread_mutex_init'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `xcb_connect_to_fd':
(.text+0x262): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `xcb_connect_to_fd':
(.text+0x27d): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `_xcb_conn_wait':
(.text+0x472): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `_xcb_conn_wait':
(.text+0x4ba): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `_xcb_conn_wait':
(.text+0x691): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
 In function `_xcb_conn_wait':
(.text+0x6e5): undefined reference to `pthread_cond_wait'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `get_socket_back':
(.text+0x41): undefined reference to `pthread_cond_wait'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `get_socket_back':
(.text+0x66): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `get_socket_back':
(.text+0x7b): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `get_socket_back':
(.text+0x8d): undefined reference to `pthread_cond_broadcast'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `xcb_prefetch_maximum_request_length.part.0':
(.text+0xd4): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `xcb_get_maximum_request_length':
(.text+0x191): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `xcb_get_maximum_request_length':
(.text+0x1a2): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `_xcb_out_init':
(.text+0x276): undefined reference to `pthread_mutex_init'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `_xcb_out_destroy':
(.text+0x295): undefined reference to `pthread_cond_destroy'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `_xcb_out_send':
(.text+0x315): undefined reference to `pthread_cond_broadcast'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `xcb_writev':
(.text+0x35c): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `xcb_writev':
(.text+0x37b): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
 In function `xcb_send_request':
(.text+0x647): undefined 

Re: [PATCH xserver 0/2] Check initial screen resources creations in Xephyr

[Michel Dänzer]

On 14/03/17 11:22 PM, Olivier Fourdan wrote:
> On startup, Xephyr does not check for the successful creation of its
> screen pixmap, and would crash if it fails.
> 
> The following patches aim at exiting cleanly instead of segfaulting
> if the screen pixmap creation fails, with glamor.
> 
> This was reported in downstream bug https://bugzilla.redhat.com/1431633
> 
> Cheers,
> Olivier
> 
> Olivier Fourdan (2):
>   glamor: Check for NULL pixmap in glamor_get_pixmap_texture()
>   Xephyr: Check screen resources creation success

Both patches are

Reviewed-by: Michel Dänzer 


-- 
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: RandR 1.5 "Monitors" and splitting a single physical display

[Jack Coulter]

Hi Nathan,

> I ran into issues trying to do setup multiple Monitors for an Output,
> and sent a mail to the list in September 2016; Aaron Plattner from
> NVIDIA responded, noting about the "ConnectionNumber" property from
> the xrandr --prop command.  The Intel hardware I'm using (Intel
> Skylake; Iris Pro Graphics P580 [8086:193d] (rev 09).
>
> The thread can be viewed here:
>
> https://lists.x.org/archives/xorg/2016-September/058245.html 
Thanks for the information, although after a brief read through the
linked thread, I'm not certain of the relevance of "ConnectorNumber" to
what we're trying to do.

> Jack, let me know if you figure this out, please and thank you! 
After some further reading of the RandR 1.5 spec, I noticed this tidbit
under RRSetMonitor:
> For each output in 'info.outputs, each one is removed from all
> pre-existing Monitors. If removing the output causes the list of
> outputs for that Monitor to become empty, then that Monitor will be
> deleted as if RRDeleteMonitor were called.
From reading this it seems that it is not possible to have multiple
monitor objects sharing the same output, making our use-case impossible
(outside of hacks such as fakexinerama).

To the wider list, I have to ask: Is this behaviour something that could
be amended in a future version of the specification? There are perfectly
valid use cases for multiple monitors on a single output (such as the
one detailed at the start of this thread).


Kind regards,
Jack



signature.asc
Description: OpenPGP digital signature
___
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 libXaw] NULL pointer dereference in XawAsciiSinkInitialize

[Peter Hutterer]

On Mon, Mar 13, 2017 at 08:01:27PM +0100, Tobias Stoeckmann wrote:
> The function XawAsciiSinkInitialize is prone to a NULL pointer
> dereference if no font is available.
> 
> Even though a specific check for a NULL font exists, it is called
> after GetGC(), which in turn would trigger the NPE in such a case.
> 
> Spotted by calling xmessage on a system with an incomplete x font setup:
> 
> $ xmessage -b text
> Warning: Unable to load any usable ISO8859 font
> Segmentation fault
> $ _
> 
> Signed-off-by: Tobias Stoeckmann 

thanks!

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #143812 updated using rev 
ba7321b6a52726cdb9964b82c5111518dc1f437d.
remote: I: 1 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/lib/libXaw
   a77be15..ba7321b  master -> master

Cheers,
   Peter
> ---
>  src/AsciiSink.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/AsciiSink.c b/src/AsciiSink.c
> index d776895..1cccb1c 100644
> --- a/src/AsciiSink.c
> +++ b/src/AsciiSink.c
> @@ -1704,10 +1704,10 @@ XawAsciiSinkInitialize(Widget request, Widget cnew,
>  {
>  AsciiSinkObject sink = (AsciiSinkObject)cnew;
>  
> -GetGC(sink);
> -
>  if (!sink->ascii_sink.font) XtError("Aborting: no font found\n");
>  
> +GetGC(sink);
> +
>  sink->ascii_sink.cursor_position = 0;
>  sink->ascii_sink.laststate = XawisOff;
>  sink->ascii_sink.cursor_x = sink->ascii_sink.cursor_y = 0;
> -- 
> 2.12.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 util-modular] release.sh: add sha512sum

[Peter Hutterer]

On Tue, Mar 14, 2017 at 01:22:16PM -0700, Alan Coopersmith wrote:
> On 03/14/17 01:13 PM, Peter Hutterer wrote:
> > Fedora is using that now and manually running md5sum instead of just peeking
> > at the announce email is boring.
> 
> Did you mean manually running sha512sum in that comment?

well, I did it the other way round, i.e. grab the tarball, run md5/sha*sum
on it, then compare with the announce email. but you're right, it's
confusing this way, i'll just shorten it to "Fedora is using that now".

> 
> >  MD5:  `$MD5SUM $tarball`
> >  SHA1: `$SHA1SUM $tarball`
> >  SHA256: `$SHA256SUM $tarball`
> > +SHA512: `$SHA512SUM $tarball`
> >  PGP:  https://${host_current}/${section_path}/${tarball}.sig
> 
> Instead of just increasing the list, is it time to pop md5sum off the
> top?  Does anyone still rely on md5?

RHEL does for example, but it doesn't have the churn to justify keeping it
in the release announce.

Cheers,
   Peter
___
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: Video tearing with modesetting driver and Intel Sandybridge graphics

[Tino Mettler]

Hi,

it looks like my dualhead setup is causing problems. The LCD is
reported to use 59.88 Hz in xrandr. The projector is reported to use 60
Hz. Disabling one of the outputs makes the tearing go away.

I can set the projector to use 59.94 Hz (NTSC), but this doesn't solve
the tearing issue. The LCD can't change the display rate.

Is there a way to get tearing free video with the modesetting driver in
such a setup, or am I forced to use the (somewhat deprecated) Intel
driver?

Regards,
Tino

___
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 util-modular] release.sh: add sha512sum

[Alan Coopersmith]

On 03/14/17 01:13 PM, Peter Hutterer wrote:

Fedora is using that now and manually running md5sum instead of just peeking
at the announce email is boring.


Did you mean manually running sha512sum in that comment?


 MD5:  `$MD5SUM $tarball`
 SHA1: `$SHA1SUM $tarball`
 SHA256: `$SHA256SUM $tarball`
+SHA512: `$SHA512SUM $tarball`
 PGP:  https://${host_current}/${section_path}/${tarball}.sig


Instead of just increasing the list, is it time to pop md5sum off the
top?  Does anyone still rely on md5?

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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 util-modular] release.sh: add sha512sum

[Peter Hutterer]

Fedora is using that now and manually running md5sum instead of just peeking
at the announce email is boring.

Signed-off-by: Peter Hutterer 
---
 release.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/release.sh b/release.sh
index cb56f58..f976f94 100755
--- a/release.sh
+++ b/release.sh
@@ -130,6 +130,7 @@ https://$host_current/$section_path/$tarball
 MD5:  `$MD5SUM $tarball`
 SHA1: `$SHA1SUM $tarball`
 SHA256: `$SHA256SUM $tarball`
+SHA512: `$SHA512SUM $tarball`
 PGP:  https://${host_current}/${section_path}/${tarball}.sig
 
 RELEASE
@@ -698,6 +699,7 @@ process_module() {
 MD5SUM=`which md5sum || which gmd5sum`
 SHA1SUM=`which sha1sum || which gsha1sum`
 SHA256SUM=`which sha256sum || which gsha256sum`
+SHA512SUM=`which sha512sum || which gsha512sum`
 
 # - Generate the announce e-mail --
 # Failing to generate the announce is not considered a fatal error
-- 
2.9.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

Re: [PATCH xserver] Workaround a sdksyms problem with gcc5 on Cygwin

[Adam Jackson]

On Mon, 2017-03-06 at 17:44 +, Jon Turney wrote:
> The linemarkers in the preprocessor output from gcc5 on Cygwin have
> canonicalized paths to included files (e.g. xserver/build/../include/misc.h
> is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
> which causes the transformation performed by -fcanonical-system-headers to
> be applied to all include pathnames)
> 
> These canonicalized paths won't match $topdir, so sdksyms doesn't look at
> the contents of those headers for sdk exported symbols.
> 
> Workaround this by canonicalizing all the paths we consider, using readlink.
> 
> v2:
> Keep a cache of readlink results so it isn't quite so dreadfully slow.

remote: I: patch #142416 updated using rev 
bca221609004aecbcc8928382ad29ce319d2eb6f.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   ac15d4c..bca2216  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 1/2] glamor: Check for NULL pixmap in glamor_get_pixmap_texture()

[Olivier Fourdan]

glamor_create_pixmap() would return a NullPixmap if the given size is
larger than the maximum size of a pixmap.

But glamor_get_pixmap_texture() won't check if the given pixmap is
non-null, leading to a segfault if glamor_create_pixmap() failed.

This can be reproduced by passing Xephyr a very large screen width,
e.g.:

 $ Xephyr -glamor -screen 32768x1024 :10

 (EE)
 (EE) Backtrace:
 (EE) 0: Xephyr (OsSigHandler+0x29)
 (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
 (EE) 2: Xephyr (glamor_get_pixmap_texture+0x30)
 (EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6)
 (EE) 4: Xephyr (ephyrCreateResources+0x98)
 (EE) 5: Xephyr (dix_main+0x275)
 (EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1)
 (EE) 7: Xephyr (_start+0x2a)
 (EE) 8: ? (?+0x2a) [0x2a]
 (EE)
 (EE) Segmentation fault at address 0x0
 (EE)
 Fatal server error:
 (EE) Caught signal 11 (Segmentation fault). Server aborting
 (EE)
 Aborted (core dumped)

Bugzilla: https://bugzilla.redhat.com/1431633
Signed-off-by: Olivier Fourdan 
---
 glamor/glamor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/glamor/glamor.c b/glamor/glamor.c
index c54cf3b..2467443 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -133,6 +133,9 @@ glamor_get_pixmap_texture(PixmapPtr pixmap)
 {
 glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
 
+if (!pixmap_priv)
+return 0;
+
 if (pixmap_priv->type != GLAMOR_TEXTURE_ONLY)
 return 0;
 
-- 
2.9.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 xserver 2/2] Xephyr: Check screen resources creation success

[Olivier Fourdan]

If the screen pixmap or the corresponding texture creation with glamor
fails, exit cleanly with an error message instead of segfaulting.

Fixes: https://bugzilla.redhat.com/1431633
Signed-off-by: Olivier Fourdan 
---
 hw/kdrive/ephyr/ephyr.c | 6 --
 hw/kdrive/ephyr/hostx.c | 5 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index 4eec72a..ef5350e 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -725,8 +725,10 @@ ephyrCreateResources(ScreenPtr pScreen)
ephyrShadowUpdate, ephyrWindowLinear);
 else {
 #ifdef GLAMOR
-if (ephyr_glamor)
-ephyr_glamor_create_screen_resources(pScreen);
+if (ephyr_glamor) {
+if (!ephyr_glamor_create_screen_resources(pScreen))
+return FALSE;
+}
 #endif
 return ephyrSetInternalDamage(pScreen);
 }
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index fe69f84..a9ea372 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
@@ -1559,6 +1559,8 @@ ephyr_glamor_create_screen_resources(ScreenPtr pScreen)
   pScreen->height,
   pScreen->rootDepth,
   GLAMOR_CREATE_NO_LARGE);
+if (!screen_pixmap)
+return FALSE;
 
 pScreen->SetScreenPixmap(screen_pixmap);
 if (pScreen->root && pScreen->SetWindowPixmap)
@@ -1566,6 +1568,9 @@ ephyr_glamor_create_screen_resources(ScreenPtr pScreen)
 
 /* Tell the GLX code what to GL texture to read from. */
 tex = glamor_get_pixmap_texture(screen_pixmap);
+if (!tex)
+return FALSE;
+
 ephyr_glamor_set_texture(scrpriv->glamor, tex);
 
 return TRUE;
-- 
2.9.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 xserver 0/2] Check initial screen resources creations in Xephyr

[Olivier Fourdan]

On startup, Xephyr does not check for the successful creation of its
screen pixmap, and would crash if it fails.

The following patches aim at exiting cleanly instead of segfaulting
if the screen pixmap creation fails, with glamor.

This was reported in downstream bug https://bugzilla.redhat.com/1431633

Cheers,
Olivier

Olivier Fourdan (2):
  glamor: Check for NULL pixmap in glamor_get_pixmap_texture()
  Xephyr: Check screen resources creation success

 glamor/glamor.c | 3 +++
 hw/kdrive/ephyr/ephyr.c | 6 --
 hw/kdrive/ephyr/hostx.c | 5 +
 3 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.9.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 xserver 2/2 v2] glamor: Check glamor_set_destination_drawable() return value

[Olivier Fourdan]

Check the value returned by glamor_set_destination_drawable() and use
the fallback code path where possible.

Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan 
---
 v2: Remove leftover from previous WIP in glamor_poly_fill_rect_gl()...
 Sorry!

 glamor/glamor_copy.c | 17 ++---
 glamor/glamor_glyphblt.c | 26 --
 glamor/glamor_lines.c| 13 -
 glamor/glamor_points.c   | 14 --
 glamor/glamor_rects.c| 13 -
 glamor/glamor_segs.c | 14 --
 glamor/glamor_spans.c| 13 -
 7 files changed, 66 insertions(+), 44 deletions(-)

diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c
index 3ca56fb..ff8f44e 100644
--- a/glamor/glamor_copy.c
+++ b/glamor/glamor_copy.c
@@ -344,6 +344,7 @@ glamor_copy_fbo_fbo_draw(DrawablePtr src,
 glamor_program *prog;
 const glamor_facet *copy_facet;
 int n;
+Bool ret = FALSE;
 
 glamor_make_current(glamor_priv);
 
@@ -410,9 +411,10 @@ glamor_copy_fbo_fbo_draw(DrawablePtr src,
 goto bail_ctx;
 
 glamor_pixmap_loop(dst_priv, dst_box_index) {
-glamor_set_destination_drawable(dst, dst_box_index, FALSE, FALSE,
-prog->matrix_uniform,
-_off_x, _off_y);
+if (!glamor_set_destination_drawable(dst, dst_box_index, FALSE, 
FALSE,
+ prog->matrix_uniform,
+ _off_x, _off_y))
+goto bail_ctx;
 
 glScissor(dst_off_x - args.dx,
   dst_off_y - args.dy,
@@ -422,13 +424,14 @@ glamor_copy_fbo_fbo_draw(DrawablePtr src,
 glamor_glDrawArrays_GL_QUADS(glamor_priv, nbox);
 }
 }
-glDisable(GL_SCISSOR_TEST);
-glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
 
-return TRUE;
+ret = TRUE;
 
 bail_ctx:
-return FALSE;
+glDisable(GL_SCISSOR_TEST);
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+return ret;
 }
 
 /**
diff --git a/glamor/glamor_glyphblt.c b/glamor/glamor_glyphblt.c
index b21aa06..78315ea 100644
--- a/glamor/glamor_glyphblt.c
+++ b/glamor/glamor_glyphblt.c
@@ -49,6 +49,7 @@ glamor_poly_glyph_blt_gl(DrawablePtr drawable, GCPtr gc,
 glamor_program *prog;
 RegionPtr clip = gc->pCompositeClip;
 int box_index;
+Bool ret = FALSE;
 
 pixmap_priv = glamor_get_pixmap_private(pixmap);
 if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
@@ -75,8 +76,9 @@ glamor_poly_glyph_blt_gl(DrawablePtr drawable, GCPtr gc,
 int off_x, off_y;
 char *vbo_offset;
 
-glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
-prog->matrix_uniform, _x, _y);
+if (!glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
+  prog->matrix_uniform, _x, 
_y))
+goto bail;
 
 max_points = 500;
 num_points = 0;
@@ -138,11 +140,12 @@ glamor_poly_glyph_blt_gl(DrawablePtr drawable, GCPtr gc,
 }
 }
 
-glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+ret = TRUE;
 
-return TRUE;
 bail:
-return FALSE;
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+return ret;
 }
 
 void
@@ -174,6 +177,7 @@ glamor_push_pixels_gl(GCPtr gc, PixmapPtr bitmap,
 int num_points;
 INT16 *points = NULL;
 char *vbo_offset;
+Bool ret = FALSE;
 
 if (w * h > MAXINT / (2 * sizeof(float)))
 goto bail;
@@ -221,17 +225,19 @@ glamor_push_pixels_gl(GCPtr gc, PixmapPtr bitmap,
 glamor_put_vbo_space(screen);
 
 glamor_pixmap_loop(pixmap_priv, box_index) {
-glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
-prog->matrix_uniform, NULL, NULL);
+if (!glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
+ prog->matrix_uniform, NULL, NULL))
+goto bail;
 
 glDrawArrays(GL_POINTS, 0, num_points);
 }
 
-glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
-return TRUE;
+ret = TRUE;
 
 bail:
-return FALSE;
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+return ret;
 }
 
 void
diff --git a/glamor/glamor_lines.c b/glamor/glamor_lines.c
index a2c9b1f..5d95333 100644
--- a/glamor/glamor_lines.c
+++ b/glamor/glamor_lines.c
@@ -46,6 +46,7 @@ glamor_poly_lines_solid_gl(DrawablePtr drawable, GCPtr gc,
 char *vbo_offset;
 int box_index;
 int add_last;
+Bool ret = FALSE;
 
 pixmap_priv = glamor_get_pixmap_private(pixmap);
 if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
@@ -103,8 +104,9 @@ glamor_poly_lines_solid_gl(DrawablePtr drawable, GCPtr gc,
 int nbox = RegionNumRects(gc->pCompositeClip);
 BoxPtr box = RegionRects(gc->pCompositeClip);
 
- 

[PATCH xserver 1/2] glamor: glamor_set_destination_drawable() can fail

[Olivier Fourdan]

The fbo_array of a given glamor pixmap can be NULL in some cases, as
glamor_create_fbo_array() can fail to allocate the FBO array.

If this is the case, glamor_pixmap_fbo_at() will return NULL even though
the box index is valid, and glamor_set_destination_drawable() simply
assumes glamor_pixmap_fbo_at() will return an FBO prior to pass the
value to glamor_set_destination_pixmap_fbo(), which will segfault.

We need a way for glamor_set_destination_drawable() to fail safely and
let the caller know about the failure.

Add a boolean return value to glamor_set_destination_drawable() for that
purpose.

Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan 
---
 glamor/glamor_transform.c | 11 +--
 glamor/glamor_transform.h |  2 +-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/glamor/glamor_transform.c b/glamor/glamor_transform.c
index eff500c..2d5a634 100644
--- a/glamor/glamor_transform.c
+++ b/glamor/glamor_transform.c
@@ -33,7 +33,7 @@
  * clipping computations can be adjusted as appropriate
  */
 
-void
+Bool
 glamor_set_destination_drawable(DrawablePtr drawable,
 int box_index,
 Booldo_drawable_translate,
@@ -53,6 +53,11 @@ glamor_set_destination_drawable(DrawablePtr drawable,
 float scale_x = 2.0f / (float) w;
 float scale_y = 2.0f / (float) h;
 float center_adjust = 0.0f;
+glamor_pixmap_fbo *pixmap_fbo;
+
+pixmap_fbo = glamor_pixmap_fbo_at(pixmap_priv, box_index);
+if (!pixmap_fbo)
+return FALSE;
 
 glamor_get_drawable_deltas(drawable, pixmap, _x, _y);
 
@@ -94,8 +99,10 @@ glamor_set_destination_drawable(DrawablePtr drawable,
 scale_x, (off_x + center_adjust) * scale_x - 1.0f,
 scale_y, (off_y + center_adjust) * scale_y - 1.0f);
 
-glamor_set_destination_pixmap_fbo(glamor_priv, 
glamor_pixmap_fbo_at(pixmap_priv, box_index),
+glamor_set_destination_pixmap_fbo(glamor_priv, pixmap_fbo,
   0, 0, w, h);
+
+return TRUE;
 }
 
 /*
diff --git a/glamor/glamor_transform.h b/glamor/glamor_transform.h
index 70d2c16..28855e3 100644
--- a/glamor/glamor_transform.h
+++ b/glamor/glamor_transform.h
@@ -23,7 +23,7 @@
 #ifndef _GLAMOR_TRANSFORM_H_
 #define _GLAMOR_TRANSFORM_H_
 
-void
+Bool
 glamor_set_destination_drawable(DrawablePtr drawable,
 int box_index,
 Booldo_drawable_translate,
-- 
2.9.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 RFC xserver 0/2] glamor pixmap FBO array can be NULL

[Olivier Fourdan]

Hi,

Downstream bugzilla https://bugzilla.redhat.com/1417575 relates to a 
crash in glamor:

https://bugzilla.redhat.com/attachment.cgi?id=1245820

While this is clearly a client bug, I reckon the Xserver should not
crash.

It appears that glamor_create_fbo_array() can fail to allocate the FBO
array, but then we always assume that the FBO returned by further calls
to glamor_pixmap_fbo_at() is not NULL.

To avoid the issue, check for the value returned by glamor_pixmap_fbo_at()
and return early without crashing when NULL, and change the API of
glamor_set_destination_drawable() to return a boolean, that will be FALSE
if the FBO is NULL so that we can check for the that calue and use a
fallback code path when this occurs.

There are some cases where we don't have a fallback code path, in which
case we'll avoid the crash in glamor_set_destination_drawable() but won't
render properly, but this is a rare occurence and not rendering properly
is still better than crashing the X server and the user losing his/her
entire session...

Note, I tried but failed to come up with a simple reproducer client for
this bug, thus the RFC status of the following patches...

Cheers,
Olivier

Olivier Fourdan (2):
  glamor: glamor_set_destination_drawable() can fail
  glamor: Check glamor_set_destination_drawable() return value

 glamor/glamor_copy.c  | 17 ++---
 glamor/glamor_glyphblt.c  | 26 --
 glamor/glamor_lines.c | 13 -
 glamor/glamor_points.c| 14 --
 glamor/glamor_rects.c | 16 +++-
 glamor/glamor_segs.c  | 14 --
 glamor/glamor_spans.c | 13 -
 glamor/glamor_transform.c | 11 +--
 glamor/glamor_transform.h |  2 +-
 9 files changed, 79 insertions(+), 47 deletions(-)

-- 
2.9.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 xserver 2/2] glamor: Check glamor_set_destination_drawable() return value

[Olivier Fourdan]

Check the value returned by glamor_set_destination_drawable() and use
the fallback code path where possible.

Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan 
---
 glamor/glamor_copy.c | 17 ++---
 glamor/glamor_glyphblt.c | 26 --
 glamor/glamor_lines.c| 13 -
 glamor/glamor_points.c   | 14 --
 glamor/glamor_rects.c| 16 +++-
 glamor/glamor_segs.c | 14 --
 glamor/glamor_spans.c| 13 -
 7 files changed, 69 insertions(+), 44 deletions(-)

diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c
index 3ca56fb..ff8f44e 100644
--- a/glamor/glamor_copy.c
+++ b/glamor/glamor_copy.c
@@ -344,6 +344,7 @@ glamor_copy_fbo_fbo_draw(DrawablePtr src,
 glamor_program *prog;
 const glamor_facet *copy_facet;
 int n;
+Bool ret = FALSE;
 
 glamor_make_current(glamor_priv);
 
@@ -410,9 +411,10 @@ glamor_copy_fbo_fbo_draw(DrawablePtr src,
 goto bail_ctx;
 
 glamor_pixmap_loop(dst_priv, dst_box_index) {
-glamor_set_destination_drawable(dst, dst_box_index, FALSE, FALSE,
-prog->matrix_uniform,
-_off_x, _off_y);
+if (!glamor_set_destination_drawable(dst, dst_box_index, FALSE, 
FALSE,
+ prog->matrix_uniform,
+ _off_x, _off_y))
+goto bail_ctx;
 
 glScissor(dst_off_x - args.dx,
   dst_off_y - args.dy,
@@ -422,13 +424,14 @@ glamor_copy_fbo_fbo_draw(DrawablePtr src,
 glamor_glDrawArrays_GL_QUADS(glamor_priv, nbox);
 }
 }
-glDisable(GL_SCISSOR_TEST);
-glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
 
-return TRUE;
+ret = TRUE;
 
 bail_ctx:
-return FALSE;
+glDisable(GL_SCISSOR_TEST);
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+return ret;
 }
 
 /**
diff --git a/glamor/glamor_glyphblt.c b/glamor/glamor_glyphblt.c
index b21aa06..78315ea 100644
--- a/glamor/glamor_glyphblt.c
+++ b/glamor/glamor_glyphblt.c
@@ -49,6 +49,7 @@ glamor_poly_glyph_blt_gl(DrawablePtr drawable, GCPtr gc,
 glamor_program *prog;
 RegionPtr clip = gc->pCompositeClip;
 int box_index;
+Bool ret = FALSE;
 
 pixmap_priv = glamor_get_pixmap_private(pixmap);
 if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
@@ -75,8 +76,9 @@ glamor_poly_glyph_blt_gl(DrawablePtr drawable, GCPtr gc,
 int off_x, off_y;
 char *vbo_offset;
 
-glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
-prog->matrix_uniform, _x, _y);
+if (!glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
+  prog->matrix_uniform, _x, 
_y))
+goto bail;
 
 max_points = 500;
 num_points = 0;
@@ -138,11 +140,12 @@ glamor_poly_glyph_blt_gl(DrawablePtr drawable, GCPtr gc,
 }
 }
 
-glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+ret = TRUE;
 
-return TRUE;
 bail:
-return FALSE;
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+return ret;
 }
 
 void
@@ -174,6 +177,7 @@ glamor_push_pixels_gl(GCPtr gc, PixmapPtr bitmap,
 int num_points;
 INT16 *points = NULL;
 char *vbo_offset;
+Bool ret = FALSE;
 
 if (w * h > MAXINT / (2 * sizeof(float)))
 goto bail;
@@ -221,17 +225,19 @@ glamor_push_pixels_gl(GCPtr gc, PixmapPtr bitmap,
 glamor_put_vbo_space(screen);
 
 glamor_pixmap_loop(pixmap_priv, box_index) {
-glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
-prog->matrix_uniform, NULL, NULL);
+if (!glamor_set_destination_drawable(drawable, box_index, FALSE, TRUE,
+ prog->matrix_uniform, NULL, NULL))
+goto bail;
 
 glDrawArrays(GL_POINTS, 0, num_points);
 }
 
-glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
-return TRUE;
+ret = TRUE;
 
 bail:
-return FALSE;
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+return ret;
 }
 
 void
diff --git a/glamor/glamor_lines.c b/glamor/glamor_lines.c
index a2c9b1f..5d95333 100644
--- a/glamor/glamor_lines.c
+++ b/glamor/glamor_lines.c
@@ -46,6 +46,7 @@ glamor_poly_lines_solid_gl(DrawablePtr drawable, GCPtr gc,
 char *vbo_offset;
 int box_index;
 int add_last;
+Bool ret = FALSE;
 
 pixmap_priv = glamor_get_pixmap_private(pixmap);
 if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
@@ -103,8 +104,9 @@ glamor_poly_lines_solid_gl(DrawablePtr drawable, GCPtr gc,
 int nbox = RegionNumRects(gc->pCompositeClip);
 BoxPtr box = RegionRects(gc->pCompositeClip);
 
-glamor_set_destination_drawable(drawable, box_index, TRUE, TRUE,
- 

Video tearing with modesetting driver and Intel Sandybridge graphics

[Tino Mettler]

Hi,

I get tearing video with the modesetting driver on a Debian Sid
installation.  It happens at least in VLC and Firefox in Gnome3 using
HDMI output of the Sandybridge graphics.

I does not happen when using the Intel DDX driver with the TearFree
option enabled.

According to several sources in the internet, modesetting together with
DRI3 should solve the tearing issue. However, this doesn't seem to be
the case for me.

Can you please give some hints and/or instructions how I can solve or
at least debug this issue, e.g. how to create useful diagnostic output
or test alternative software in case both Firefox and VLC do things
wrong.

I use a video projector connected to the HDMI output and video tearing
in this setup ist very disturbing.

Regards,
Tino
___
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: xorg-server-1.18.x and xorg-server-1.19.x: xf86Config.c / auto_gpu_device=1 failed to configure my Radeon 280X (commit: 69e4b8e602ecc7b69c75988a447ec5b509b22402)

[wallak]

I tried the option "AutoAddGPU" without success. Something has to be fixed 
somewhere; But I'm not sure of the expected software behavior.

Wallak.


- Mail original -
De: "Michel Dänzer" 
À: wal...@free.fr
Cc: xorg-devel@lists.x.org
Envoyé: Mardi 14 Mars 2017 03:14:14
Objet: Re: xorg-server-1.18.x and xorg-server-1.19.x: xf86Config.c / 
auto_gpu_device=1 failed to configure my Radeon 280X (commit: 
69e4b8e602ecc7b69c75988a447ec5b509b22402)

On 13/03/17 09:48 PM, wal...@free.fr wrote:
> Here is below the test Xorg configuration (tst.conf). I just checked
> that removing sections related to other devices, and using only the
> sections related to the target device as a simple 'skeleton' fixes
> the issue too. But this last method is not what we want (I hope so).

Is there any particular issue with that? (Don't expect me to look
through that configuration in detail :) If so, does adding

Option  "AutoAddGPU""off"

to Section "ServerFlags" help?


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

[Bug 99769] RADEON(0): flip queue failed in radeon_scanout_flip: Cannot allocate memory

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99769

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130209|0   |1
is obsolete||

--- Comment #9 from Michel Dänzer  ---
Created attachment 130210
  --> https://bugs.freedesktop.org/attachment.cgi?id=130210=edit
If a TearFree flip fails, fall back to non-TearFree operation

The previous patch had leftover debugging code to induce this failure, please
test this patch instead.

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