Re: tarball types (was: [ANNOUNCE] xf86-input-libinput 1.2.1)

[Julien Cristau]

On Mon, Jan 24, 2022 at 03:53:23PM -0800, Alan Coopersmith wrote:
> On 1/23/22 21:18, Peter Hutterer wrote:
> > xf86-input-libinput 1.2.1 is now available. Primarily a few typos and misc
> > minor fixes, the most visible change to distributions is that we now ship an
> > xz tarball instead of bz2. Due to a global shortage of flying cars, you will
> > have to accept that as your "welcome to the future" present. If you don't 
> > like
> > the future (and who can blame you!), we still have gz tarballs, simply
> > because I didn't realize we still generated those until I typed out this
> > email.
> 
> While I've been applying this change across the Xorg modules, I've followed
> the lead of those who came before me, and just replaced "dist-bz2" with
> "dist-xz".  To get rid of the gzip files we'd also have to add "no-dist-gzip"
> to our AM_INIT_AUTOMAKE() options.
> 
> Since it's been a decade since GNOME switched to exclusively releasing xz
> tarballs [1], I would expect there being no major headaches to us doing the
> same now, we just hadn't thought much about it. Is this something we want to
> do?  Does anyone have a reason we shouldn't stop making .gz files?
> (It looks like xwayland is already doing xz-only releases now.)
> 
I'm still using the gz tarballs for the Debian source packages and would
like to keep doing that, if possible.

Cheers,
Julien

Re: Maintainer / Owner privileges at xf86-video-vmware

[Julien Cristau]

On Fri, Feb 22, 2019 at 13:28:34 +, Daniel Stone wrote:

> Hi Thomas,
> 
> On Fri, 22 Feb 2019 at 13:18, Thomas Hellstrom  wrote:
> > I was trying to add Deepak Rawat as a member on the xf86-video-vmware
> > project on fdo gitlab. Turns out I have only developer privileges
> > there. Could someone please raise that to maintainer or owner?
> 
> Bouncing this over to xorg-devel; since moving to GitLab, the admins
> are no longer involved in permission changes, but each project can do
> that themselves.
> 
I've now set Thomas as maintainer for xf86-video-vmware.

Cheers,
Julien
___
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 xorgproto] Add DPMSInfoNotify event

[Julien Cristau]

On 10/02/2018 03:10 PM, Alexander Volkov wrote:
> From: Alexander Volkov 
> 
> This allows applications to respond to changes of power level
> of a monitor, e.g. an application may stop rendering and related
> calculations when the monitor is off.
> 
> Bump DPMS version to 1.2.
> 
> Signed-off-by: Alexander Volkov 
> ---
>  include/X11/extensions/dpmsconst.h |  5 -
>  include/X11/extensions/dpmsproto.h | 27 ++-
>  2 files changed, 30 insertions(+), 2 deletions(-)
> 
We shouldn't be adding new extension events that don't come through the
Generic Event Extension, as the extension event space is basically full,
IIRC (see
https://lists.x.org/pipermail/xorg-devel/2010-March/006716.html).  This
also seems like it might belong in RANDR rather than DPMS, as DPMS
doesn't actually tie things to a monitor?

Cheers,
Julien
___
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 xcb] don't flag extra reply in xcb_take_socket

[Julien Cristau]

+xcb@

On 08/09/2018 12:20 AM, Erik Kurzinger wrote:
> If any flags are specified in a call to xcb_take_socket,
> they should only be applied to replies for requests sent
> after that function returns (and until the socket is
> re-acquired by XCB).
> 
> Previously, they would also be incorrectly applied to the
> reply for the last request sent before the socket was taken.
> For instance, in this example program the reply for the
> GetInputFocus request gets discarded, even though it was
> sent before the socket was taken. This results in the
> call to retrieve the reply hanging indefinitely.
> 
> static void return_socket(void *closure) {}
> 
> int main(void)
> {
> Display *dpy = XOpenDisplay(NULL);
> xcb_connection_t *c = XGetXCBConnection(dpy);
> 
> xcb_get_input_focus_cookie_t cookie = xcb_get_input_focus_unchecked(c);
> xcb_flush(c);
> 
> uint64_t seq;
> xcb_take_socket(c, return_socket, dpy, XCB_REQUEST_DISCARD_REPLY, );
> 
> xcb_generic_error_t *err;
> xcb_get_input_focus_reply(c, cookie, );
> }
> 
> In practice, this has been causing intermittent KWin crashes when
> used in combination with the proprietary NVIDIA driver such as
> https://bugs.kde.org/show_bug.cgi?id=386370 since when Xlib fails to
> retrieve one of these incorrectly discarded replies it triggers
> an IO error.
> 
> Signed-off-by: Erik Kurzinger 
> ---
>  src/xcb_in.c  | 21 +++--
>  src/xcb_out.c | 10 --
>  2 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/src/xcb_in.c b/src/xcb_in.c
> index 73209e0..4333ad3 100644
> --- a/src/xcb_in.c
> +++ b/src/xcb_in.c
> @@ -958,8 +958,25 @@ void _xcb_in_replies_done(xcb_connection_t *c)
>  pend = container_of(c->in.pending_replies_tail, struct 
> pending_reply, next);
>  if(pend->workaround == WORKAROUND_EXTERNAL_SOCKET_OWNER)
>  {
> -pend->last_request = c->out.request;
> -pend->workaround = WORKAROUND_NONE;
> +if (XCB_SEQUENCE_COMPARE(pend->first_request, <=, 
> c->out.request)) {
> +pend->last_request = c->out.request;
> +pend->workaround = WORKAROUND_NONE;
> +} else {
> +/* The socket was taken, but no requests were actually sent
> + * so just discard the pending_reply that was created.
> + */
> +struct pending_reply *prev_pend = c->in.pending_replies;
> +if (prev_pend == pend) {
> +c->in.pending_replies = NULL;
> +c->in.pending_replies_tail = >in.pending_replies;
> +} else {
> +while (prev_pend->next != pend)
> +prev_pend = prev_pend->next;
> +prev_pend->next = NULL;
> +c->in.pending_replies_tail = _pend->next;
> +}
> +free(pend);
> +}
>  }
>  }
>  }
> diff --git a/src/xcb_out.c b/src/xcb_out.c
> index 3601a5f..c9593e5 100644
> --- a/src/xcb_out.c
> +++ b/src/xcb_out.c
> @@ -387,8 +387,14 @@ int xcb_take_socket(xcb_connection_t *c, void 
> (*return_socket)(void *closure), v
>  {
>  c->out.return_socket = return_socket;
>  c->out.socket_closure = closure;
> -if(flags)
> -_xcb_in_expect_reply(c, c->out.request, 
> WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
> +if(flags) {
> +/* c->out.request + 1 will be the first request sent by the 
> external
> + * socket owner. If the socket is returned before this request 
> is sent
> + * it will be detected in _xcb_in_replies_done and this 
> pending_reply
> + * will be discarded.
> + */
> +_xcb_in_expect_reply(c, c->out.request + 1, 
> WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
> +}
>  assert(c->out.request == c->out.request_written);
>  *sent = c->out.request;
>  }
> 

___
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 app/xdm] Add missing brackets to multi-statement if in SaveServerAuthorizations

[Julien Cristau]

On Sat, May  5, 2018 at 12:33:12 -0700, Alan Coopersmith wrote:

> Introduced by commit 5222d28e8d8e5b4cc
> 
> Reported by gcc 7.3:
> 
> auth.c: In function ‘SaveServerAuthorizations’:
> auth.c:447:6: warning: this ‘if’ clause does not guard... 
> [-Wmisleading-indentation]
>   if (auths[i]->data_length > 0)
>   ^~
> auth.c:452:3: note: ...this statement, but the latter is misleadingly 
> indented as if it were guarded by the ‘if’
>(void) fflush (auth_file);
>^
> 
> Signed-off-by: Alan Coopersmith 
> ---
>  xdm/auth.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
Woops, sorry about that.  Thanks for the fix.

Cheers,
Julien
___
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 xorgproto] Fix MAN_SUBSTS libdir replacement

[Julien Cristau]

__libdir__ doesn't seem to actually be used anywhere in the man page,
but...

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 8c1faf8..a58faca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -209,7 +209,7 @@ MAN_SUBSTS = \
 -e 's|__vendorversion__|"$(XORGRELSTRING)" "$(XORGMANNAME)"|' \
 -e 's|__xorgversion__|"$(XORGRELSTRING)" "$(XORGMANNAME)"|' \
 -e 's|__datadir__|$(datadir)|g' \
--e 's|__datadir__|$(libdir)|g' \
+-e 's|__libdir__|$(libdir)|g' \
 -e 's|__sysconfdir__|$(sysconfdir)|g' \
 -e 's|__appmansuffix__|$(APP_MAN_SUFFIX)|g' \
 -e 's|__libmansuffix__|$(LIB_MAN_SUFFIX)|g' \
-- 
2.11.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] present: cap the version returned to the client

[Julien Cristau]

On Mon, Mar 19, 2018 at 16:04:43 +, Emil Velikov wrote:

> From: Emil Velikov 
> 
> As per the protocol, the server should not return version greater than
> the one supported by the client.
> 
> Add a spec quote and tweak the numbers accordingly.
> 
> Fixes: 5c5c1b77982 ("present: Add Present extension")
> Cc: Thierry Reding 
> Cc: Daniel Stone 
> Cc: Keith Packard 
> Signed-off-by: Emil Velikov 
> ---
> Analogous to the DRI3 patch here
> https://patchwork.freedesktop.org/patch/210343/
> ---
>  present/present_request.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/present/present_request.c b/present/present_request.c
> index c6afe5fa7..f52efa52b 100644
> --- a/present/present_request.c
> +++ b/present/present_request.c
> @@ -41,7 +41,19 @@ proc_present_query_version(ClientPtr client)
>  };
>  
>  REQUEST_SIZE_MATCH(xPresentQueryVersionReq);
> -(void) stuff;
> +/* From presentproto:
> + *
> + * The client sends the highest supported version to the server
> + * and the server sends the highest version it supports, but no
> + * higher than the requested version.
> + */
> +
> +if (rep.majorVersion > stuff->majorVersion ||
> +rep.minorVersion > stuff->minorVersion) {
> +rep.majorVersion = stuff->majorVersion;
> +rep.minorVersion = stuff->minorVersion;
> +}

Doesn't this break when e.g. client supports 2.2 and server supports
1.4, where we'll return 2.2 instead of 1.4?  i.e. it seems to me this
should be

if (rep.majorVersion > stuff->majorVersion ||
(rep.majorVersion == stuff->majorVersion &&
 rep.minorVersion > stuff->minorVersion)) {
 ...
}

Cheers,
Julien

> +
>  if (client->swapped) {
>  swaps();
>  swapl();
> -- 
> 2.16.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
___
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 xcb/proto] screensaver: Use CARD32 encoding for ScreenSaverSuspend 'suspend'

[Julien Cristau]

I think this belongs on xcb@.

Cheers,
Julien

On Mon, Mar 12, 2018 at 12:03:19 -0700, Keith Packard wrote:

> This was set to BOOL, but the protocol headers used Bool, presumably a
> 32-bit type. We're switching everything to CARD32 as the best option
> for compatibility.
> 
> Signed-off-by: Keith Packard 
> ---
>  src/screensaver.xml | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/screensaver.xml b/src/screensaver.xml
> index 8d5abb4..c546f94 100644
> --- a/src/screensaver.xml
> +++ b/src/screensaver.xml
> @@ -168,8 +168,7 @@ Draft Standard Version 1.1
>
>
>
> -
> -
> +
>
>  
>
> -- 
> 2.16.2
> 
> ___
> 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
___
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] dix: Don't vary the ClientRec ABI at build time

[Julien Cristau]

On Tue, Oct 24, 2017 at 14:38:12 -0400, Adam Jackson wrote:

> Just no.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  include/dixstruct.h | 2 --
>  1 file changed, 2 deletions(-)
> 
for the series:
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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 app/bdftopcf] Import libXfont's BDF-to-PCF code

[Julien Cristau]

On Tue, Oct 24, 2017 at 13:54:47 -0400, Adam Jackson wrote:

> bdftopcf is the only consumer of libXfont 1.x's read/write support, and
> we'd like 1.x to go away entirely. Copy in the BDF read and PCF write
> support so there's one fewer consumer of 1.x.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>

Yes please.

Acked-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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 libXrender 1/2] Avoid OOB write in XRenderQueryFilters

[Julien Cristau]

Anyone?  This still looks wrong to me.

Cheers,
Julien

On Sat, Jan  7, 2017 at 18:46:57 +0100, Julien Cristau wrote:

> On Sun, Sep 25, 2016 at 22:50:45 +0200, Matthieu Herrb wrote:
> 
> > From: Tobias Stoeckmann <tob...@stoeckmann.org>
> > 
> > The memory for filter names is reserved right after receiving the reply.
> > After that, filters are iterated and each individual filter name is
> > stored in that reserved memory.
> > 
> > The individual name lengths are not checked for validity, which means
> > that a malicious server can reserve less memory than it will write to
> > during each iteration.
> > 
> > v2: consume remaining bytes in reply buffer on error.
> > 
> > Signed-off-by: Tobias Stoeckmann <tob...@stoeckmann.org>
> > Reviewed-by: Matthieu Herrb <matth...@herrb.eu>
> > ---
> >  src/Filter.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/Filter.c b/src/Filter.c
> > index edfa572..8d701eb 100644
> > --- a/src/Filter.c
> > +++ b/src/Filter.c
> > @@ -38,7 +38,7 @@ XRenderQueryFilters (Display *dpy, Drawable drawable)
> >  char   *name;
> >  char   len;
> >  inti;
> > -unsigned long  nbytes, nbytesAlias, nbytesName;
> > +unsigned long  nbytes, nbytesAlias, nbytesName, reply_left;
> >  
> >  if (!RenderHasExtension (info))
> > return NULL;
> > @@ -114,6 +114,7 @@ XRenderQueryFilters (Display *dpy, Drawable drawable)
> >   * Read the filter aliases
> >   */
> >  _XRead16Pad (dpy, filters->alias, 2 * rep.numAliases);
> > +reply_left = 8 + rep.length - 2 * rep.numAliases;;
> >  
> reply_left looks like a byte count, in which case shouldn't rep.length
> be multiplied by 4?  I don't get where that 8 comes from, either, any
> chance you could explain?  In fact I wonder if this couldn't use
> nbytesName instead?
> 
> Cheers,
> Julien
> ___
> 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
___
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] shm, xwayland: prefer atomic close-on-exec without O_TMPFILE

[Julien Cristau]

On Fri, Jul  7, 2017 at 22:41:06 +0200, Jan Beich wrote:

> Julien Cristau <jcris...@debian.org> writes:
> 
> > On Fri, Jul  7, 2017 at 16:31:48 +0200, Jan Beich wrote:
> >> -  flags = fcntl(fd, F_GETFD);
> >> +#ifndef HAVE_MKOSTEMP
> >> +  int flags = fcntl(fd, F_GETFD);
> >
> > Do we allow mixed declarations and code nowadays?
> 
> xserver has quite a few of those already, even in Xext/shm.c e.g.,
> 
Those examples are all at the beginning of a block, so they don't count
:)

Anyway, I think
https://cgit.freedesktop.org/xorg/xserver/tree/doc/c-extensions#n35
answers my question, so it's fine.

Cheers,
Julien
___
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] shm, xwayland: prefer atomic close-on-exec without O_TMPFILE

[Julien Cristau]

On Fri, Jul  7, 2017 at 16:31:48 +0200, Jan Beich wrote:

> 
> Signed-off-by: Jan Beich 
> ---
>  Xext/shm.c  | 9 +++--
>  configure.ac| 2 +-
>  include/dix-config.h.in | 3 +++
>  3 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Xext/shm.c b/Xext/shm.c
> index 91ea90b14..6edeba6fb 100644
> --- a/Xext/shm.c
> +++ b/Xext/shm.c
> @@ -1199,7 +1199,6 @@ shm_tmpfile(void)
>  {
>  #ifdef SHMDIR
>   int fd;
> - int flags;
>   chartemplate[] = SHMDIR "/shmfd-XX";
>  #ifdef O_TMPFILE
>   fd = open(SHMDIR, O_TMPFILE|O_RDWR|O_CLOEXEC|O_EXCL, 0666);
> @@ -1209,15 +1208,21 @@ shm_tmpfile(void)
>   }
>   ErrorF ("Not using O_TMPFILE\n");
>  #endif
> +#ifdef HAVE_MKOSTEMP
> + fd = mkostemp(template, O_CLOEXEC);
> +#else
>   fd = mkstemp(template);
> +#endif
>   if (fd < 0)
>   return -1;
>   unlink(template);
> - flags = fcntl(fd, F_GETFD);
> +#ifndef HAVE_MKOSTEMP
> + int flags = fcntl(fd, F_GETFD);

Do we allow mixed declarations and code nowadays?

Cheers,
Julien
___
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 libxshmfence] futex: unbreak build on FreeBSD 11.0+

[Julien Cristau]

On Fri, Jul  7, 2017 at 16:31:07 +0200, Jan Beich wrote:

> From: Jung-uk Kim 
> Date: Tue, 15 Apr 2014 17:08:46 +
> 
> In file included from src/xshmfence_alloc.c:27:
> In file included from src/xshmfenceint.h:32:
> src/xshmfence_futex.h:40:39: error: use of undeclared identifier 'INT_MAX'
> return sys_futex(addr, UMTX_OP_WAKE, INT_MAX);
>  ^
> 1 error generated.
> 
> Signed-off-by: Jan Beich 
> ---
>  src/xshmfence_futex.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/xshmfence_futex.h b/src/xshmfence_futex.h
> index ea96cf4..c1b743d 100644
> --- a/src/xshmfence_futex.h
> +++ b/src/xshmfence_futex.h
> @@ -29,6 +29,7 @@
>  #ifdef HAVE_UMTX
>  
>  #include 
> +#include 
>  #include 
>  
>  static inline int sys_futex(void *addr, int op, int32_t val)

Can we make that ?

Cheers,
Julien
___
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 CLOCK_MONOTONIC test

[Julien Cristau]

On Thu, May 11, 2017 at 17:21:04 -0400, Adam Jackson wrote:

> On Thu, 2017-05-11 at 17:17 -0400, Adam Jackson wrote:
> 
> > @@ -4,7 +4,10 @@ dri_dep = dependency('dri', required: build_dri2 or
> > build_dri3)
> >  conf_data = configuration_data()
> >  conf_data.set('_DIX_CONFIG_H_', '1')
> >  
> > +
> > +
> >  conf_data.set('MONOTONIC_CLOCK', cc.compiles('''
> > +#define _POSIX_C_SOURCE 200112L
> >  #include 
> >  #include 
> >  #ifndef CLOCK_MONOTONIC
> 
> Forgive the excess spaces.
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>
for the series.

Cheers,
Julien
___
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] Replace all checks for 'linux' macro with '__linux__'

[Julien Cristau]

gcc -std=c99 does not define the former, and it's a horrible namespace
confusion anyway.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 hw/xfree86/common/compiler.h   | 14 +++---
 hw/xfree86/common/xf86Config.c |  2 +-
 hw/xfree86/common/xf86Configure.c  |  2 +-
 hw/xfree86/common/xf86Init.c   |  2 +-
 hw/xfree86/common/xf86str.h|  2 +-
 hw/xfree86/os-support/bus/Pci.h|  4 ++--
 hw/xfree86/os-support/bus/Sbus.c   |  2 +-
 hw/xfree86/os-support/bus/xf86Sbus.h   |  2 +-
 hw/xfree86/os-support/linux/lnx_agp.c  |  6 +++---
 hw/xfree86/os-support/misc/SlowBcopy.c |  2 +-
 10 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
index 5a1fdac96f..eea29dfb52 100644
--- a/hw/xfree86/common/compiler.h
+++ b/hw/xfree86/common/compiler.h
@@ -98,9 +98,9 @@
 #if defined(DO_PROTOTYPES)
 #if !defined(__arm__)
 #if !defined(__sparc__) && !defined(__arm32__) && !defined(__nds32__) \
-  && !(defined(__alpha__) && defined(linux)) \
-  && !(defined(__ia64__) && defined(linux)) \
-  && !(defined(__mips64) && defined(linux)) \
+  && !(defined(__alpha__) && defined(__linux__)) \
+  && !(defined(__ia64__) && defined(__linux__)) \
+  && !(defined(__mips64) && defined(__linux__)) \
 
 extern _X_EXPORT void outb(unsigned short, unsigned char);
 extern _X_EXPORT void outw(unsigned short, unsigned short);
@@ -215,7 +215,7 @@ extern _X_EXPORT void xf86WriteMmio32Le (void *, unsigned 
long, unsigned int);
 #ifdef __GNUC__
 #if defined(__alpha__)
 
-#ifdef linux
+#ifdef __linux__
 /* for Linux on Alpha, we use the LIBC _inx/_outx routines */
 /* note that the appropriate setup via "ioperm" needs to be done */
 /*  *before* any inx/outx is done. */
@@ -263,7 +263,7 @@ inl(unsigned long port)
 return _inl(port);
 }
 
-#endif  /* linux */
+#endif  /* __linux__ */
 
 #if (defined(__FreeBSD__) || defined(__OpenBSD__)) \
   && !defined(DO_PROTOTYPES)
@@ -570,7 +570,7 @@ inl(unsigned PORT_SIZE port)
 }
 
 #if defined(__mips__)
-#ifdef linux/* don't mess with other OSs */
+#ifdef __linux__/* don't mess with other OSs */
 #if X_BYTE_ORDER == X_BIG_ENDIAN
 static __inline__ unsigned int
 xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
@@ -594,7 +594,7 @@ xf86WriteMmio32Be(__volatile__ void *base, const unsigned 
long offset,
  :"r"(val), "r"(addr));
 }
 #endif
-#endif  /* !linux */
+#endif  /* !__linux__ */
 #endif  /* __mips__ */
 
 #elif defined(__powerpc__)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index c2b522a184..fa04a3f119 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -868,7 +868,7 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, XF86OptionPtr 
layoutopts)
 
 /* when forcing input devices, we use kbd. otherwise evdev, so use the
  * evdev rules set. */
-#if defined(linux)
+#if defined(__linux__)
 if (!xf86Info.forceInputDevices)
 rules = "evdev";
 else
diff --git a/hw/xfree86/common/xf86Configure.c 
b/hw/xfree86/common/xf86Configure.c
index 668a55151a..5f9643a52d 100644
--- a/hw/xfree86/common/xf86Configure.c
+++ b/hw/xfree86/common/xf86Configure.c
@@ -61,7 +61,7 @@ static Bool foundMouse = FALSE;
 #if   defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || 
defined(__DragonFly__)
 static const char *DFLT_MOUSE_DEV = "/dev/sysmouse";
 static const char *DFLT_MOUSE_PROTO = "auto";
-#elif defined(linux)
+#elif defined(__linux__)
 static const char *DFLT_MOUSE_DEV = "/dev/input/mice";
 static const char *DFLT_MOUSE_PROTO = "auto";
 #elif defined(WSCONS_SUPPORT)
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index d0bd6e95bb..994b63b430 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -183,7 +183,7 @@ xf86PrintBanner(void)
 xf86ErrorFVerb(0, "Current Operating System: %s %s %s %s %s\n",
name.sysname, name.nodename, name.release,
name.version, name.machine);
-#ifdef linux
+#ifdef __linux__
 do {
 char buf[80];
 int fd = open("/proc/cmdline", O_RDONLY);
diff --git a/hw/xfree86/common/xf86str.h b/hw/xfree86/common/xf86str.h
index 1da66e2dd0..edd91c745a 100644
--- a/hw/xfree86/common/xf86str.h
+++ b/hw/xfree86/common/xf86str.h
@@ -249,7 +249,7 @@ typedef struct _DriverRec {
  */
 
 /* Tolerate prior #include  */
-#if defined(linux)
+#if defined(__linux__)
 #undef BUS_NONE
 #undef BUS_PC

[PATCH xserver 1/2] Drop workaround for pre-glibc linux

[Julien Cristau]

It seems unlikely anyone still needs to build against libc4/libc5.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 Xext/xf86bigfont.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/Xext/xf86bigfont.c b/Xext/xf86bigfont.c
index 72bb774011..529595bb75 100644
--- a/Xext/xf86bigfont.c
+++ b/Xext/xf86bigfont.c
@@ -40,13 +40,6 @@
 
 #include 
 #ifdef HAS_SHM
-#if defined(linux) && (!defined(__GNU_LIBRARY__) || __GNU_LIBRARY__ < 2)
-/* libc4 does not define __GNU_LIBRARY__, libc5 defines __GNU_LIBRARY__ as 1 */
-/* Linux libc4 and libc5 only (because glibc doesn't include kernel headers):
-   Linux 2.0.x and 2.2.x define SHMLBA as PAGE_SIZE, but forget to define
-   PAGE_SIZE. It is defined in . */
-#include 
-#endif
 #ifdef SVR4
 #include 
 #endif
-- 
2.11.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 5/7] meson: Make XV optional

[Julien Cristau]

On Mon, May  8, 2017 at 10:13:52 -0700, Eric Anholt wrote:

> Optional XV seems a bit silly to me.  Could we just do something
> like:
> 
> build_xv = build_xorg || build_dmx || build_ephyr?

FWIW the Xorg build we're shipping in debian installer images (which run
a single specific gtk2 client) have xv disabled.  I could be convinced
not to care, though; no idea what the size difference is, or if this
still matters 7 years later.

Cheers,
Julien
___
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 app/xdpyinfo] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

[Julien Cristau]

On Fri, May  5, 2017 at 10:08:14 +0200, Pali Rohár wrote:

> PING.
> 
> I would like to know if there is some problem with this and something
> needs to be reworked or if it can be accepted.
> 
> Currently xdpyinfo report bogus dimensions and resolution values and lot
> of people complain about this problem. It should be fixed.
> 
Yes, there's a problem with this.  xrandr is the tool to get monitor
dimensions, xdpyinfo serves a different purpose.  You could add support
for xdpyinfo -ext RANDR, but changing the default output is a bad idea
IMO.

Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] vfb: Bump default depth to 24

[Julien Cristau]

On Mon, Feb 20, 2017 at 10:24:14 -0500, Adam Jackson wrote:

> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  hw/vfb/InitOutput.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Acked-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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: Xorg 1.19.1 SIGPIPE on application close

[Julien Cristau]

On 02/06/2017 03:32 PM, Antoine Martin wrote:
> Hi,
> 
> I can reproduce this Xorg server crash fairly reliably using xpra and
> glxspheres simply by closing the application window:
> 
> Thread 1 "Xorg" received signal SIGPIPE, Broken pipe.
> 0x757ca83d in writev () at ../sysdeps/unix/syscall-template.S:84
> 84T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)

That's not a crash.  SIGPIPE on client disconnect is expected, and is
not fatal.

Cheers,
Julien

___
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 libX11] _XDefaultError: set XlibDisplayIOError flag before calling exit

[Julien Cristau]

On Wed, Feb  1, 2017 at 15:02:41 +0100, arthur.huil...@free.fr wrote:

> It is legal for an application to make Xlib calls during _fini, and that is 
> useful for an OpenGL driver to avoid resource leaks on the X server side, for 
> example in the dlopen/dlclose case. However, the driver can not readily tell 
> whether its _fini is being called because Xlib called exit, or for another 
> reason (dlclose), so it is hard to cleanly work around this issue in the 
> driver.
> 
I don't get the resource leaks justification.  Can't the X server clean
up when the client goes away?

Cheers,
Julien
___
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 libXrandr] Avoid out of boundary accesses on illegal responses

[Julien Cristau]

On Sat, Jan  7, 2017 at 19:15:42 +0100, Tobias Stoeckmann wrote:

> Hi Julien,
> 
> On Sat, Jan 07, 2017 at 07:03:17PM +0100, Julien Cristau wrote:
> > It looks like we're leaking 'attr' on these error paths?
> 
> confirmed. That is what I get for copying the error handling of the
> attr == NULL case...
> 
Pushed as
https://cgit.freedesktop.org/xorg/lib/libXrandr/commit/?id=87227e5fc79750d3eccc3c3482a3c5b3f2af2e90

I kind of wonder if those error paths shouldn't just IOError, if we're
talking to a broken and/or malicious X server what's the point trying to
recover...

Cheers,
Julien
___
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] presentproto 1.1

[Julien Cristau]

This release fixes a bug causing libXpresent to have a wrong idea of the
present wire protocol structures.  Plus a number of documentation
improvements.

Aaron Plattner (1):
  Copy the standard .gitignore from other proto packages

Adam Jackson (2):
  Add COPYING
  Force Window and Pixmap to be CARD32 on the wire

Alan Coopersmith (1):
  configure: Drop AM_MAINTAINER_MODE

Emil Velikov (1):
  autogen.sh: use quoted string variables

Gaetan Nadon (2):
  Add the required README file.
  config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES

Julien Cristau (2):
  Fix wrong reference to DRI3 in the protocol spec
  Bump version to 1.1

Keith Packard (4):
  Fix spelling of James Jones' email address
  Move Redirect stuff to 'later version' sections
  Don't define 'redirect' stuff in header files
  autogen.sh: Implement GNOME Build API

Kenneth Graunke (1):
  Fix typo (modifiy -> modify)

Mihail Konev (1):
  autogen: add default patch prefix

Peter Hutterer (1):
  autogen.sh: use exec instead of waiting for configure to finish

git tag: presentproto-1.1

https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.bz2
MD5:  92f9dda9c870d78a1d93f366bcb0e6cd  presentproto-1.1.tar.bz2
SHA1: b1294dbb3a8337f79252142b45aa123ee1aa7602  presentproto-1.1.tar.bz2
SHA256: f69b23a8869f78a5898aaf53938b829c8165e597cda34f06024d43ee1e6d26b9  
presentproto-1.1.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.gz
MD5:  dc689e8569eda66b8c404e355f575119  presentproto-1.1.tar.gz
SHA1: 9b3e57202e666f584923ae2b54361a1c902d2ed3  presentproto-1.1.tar.gz
SHA256: 114252e97afb4dfae8b31e6b0d5e24e4babda26b364e2be57abc2f3c30248b87  
presentproto-1.1.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.gz.sig



signature.asc
Description: 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

[ANNOUNCE] presentproto 1.1

[Julien Cristau]

This release fixes a bug causing libXpresent to have a wrong idea of the
present wire protocol structures.  Plus a number of documentation
improvements.

Aaron Plattner (1):
  Copy the standard .gitignore from other proto packages

Adam Jackson (2):
  Add COPYING
  Force Window and Pixmap to be CARD32 on the wire

Alan Coopersmith (1):
  configure: Drop AM_MAINTAINER_MODE

Emil Velikov (1):
  autogen.sh: use quoted string variables

Gaetan Nadon (2):
  Add the required README file.
  config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES

Julien Cristau (2):
  Fix wrong reference to DRI3 in the protocol spec
  Bump version to 1.1

Keith Packard (4):
  Fix spelling of James Jones' email address
  Move Redirect stuff to 'later version' sections
  Don't define 'redirect' stuff in header files
  autogen.sh: Implement GNOME Build API

Kenneth Graunke (1):
  Fix typo (modifiy -> modify)

Mihail Konev (1):
  autogen: add default patch prefix

Peter Hutterer (1):
  autogen.sh: use exec instead of waiting for configure to finish

git tag: presentproto-1.1

https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.bz2
MD5:  92f9dda9c870d78a1d93f366bcb0e6cd  presentproto-1.1.tar.bz2
SHA1: b1294dbb3a8337f79252142b45aa123ee1aa7602  presentproto-1.1.tar.bz2
SHA256: f69b23a8869f78a5898aaf53938b829c8165e597cda34f06024d43ee1e6d26b9  
presentproto-1.1.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.gz
MD5:  dc689e8569eda66b8c404e355f575119  presentproto-1.1.tar.gz
SHA1: 9b3e57202e666f584923ae2b54361a1c902d2ed3  presentproto-1.1.tar.gz
SHA256: 114252e97afb4dfae8b31e6b0d5e24e4babda26b364e2be57abc2f3c30248b87  
presentproto-1.1.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/proto/presentproto-1.1.tar.gz.sig



signature.asc
Description: PGP signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: libx11: Issues with Data32/_XData32

[Julien Cristau]

On Tue, Jan 24, 2017 at 01:12:23 +, James Clarke wrote:

> Hi,
> I've been debugging an issue in gtk2-perl causing it to SIGBUS on
> sparc64, and traced it back to what seems to be dodgy code inside
> libx11. One of the tests calls gdk_window_set_opacity, which calls
> XChangeProperty with a pointer to a guint32, cast to char*, with the
> length set to 32 bits as expected. However, this data pointer then gets
> cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed,
> the definition of Data32 specifies that data is a (long *) on sparc64,
> since LONG64 is defined. This feels very wrong, but in and of itself is
> not too bad (I believe it violates strict aliasing).
> 
As discussed on irc this sounds like a gtk bug, fixed by
https://git.gnome.org/browse/gtk+/commit/?id=0e1a424829937abc27780da97a8bf60e81233d6c
for gtk 3.

Cheers,
Julien
___
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 00/19] Module loader cleanup

[Julien Cristau]

On Mon, Jan 23, 2017 at 14:32:14 -0500, Adam Jackson wrote:

> I'd like to move the module loader up to dix. In preparation for that, here's
> a bunch of cleanup patches. The first three aren't mine, I just think they're
> neat.
> 
A few nits in separate mails, but for the series:
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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 19/19] loader: Fix an obviously backwards comparison

[Julien Cristau]

On Mon, Jan 23, 2017 at 14:32:33 -0500, Adam Jackson wrote:

> Hmm, this code looks wrong to me. I know! Instead of fix it, I'll put a
> comment here that nobody will look at for decades on end.
> 
> Yaaay xfree86.
> 
> Signed-off-by: Adam Jackson 
> ---
>  hw/xfree86/loader/loadmod.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
> index ca77c7a..55bec14 100644
> --- a/hw/xfree86/loader/loadmod.c
> +++ b/hw/xfree86/loader/loadmod.c
> @@ -545,8 +545,7 @@ CheckVersion(const char *module, XF86ModuleVersionInfo * 
> data,
> "(%d)\n", module, maj, reqmaj);
>  return FALSE;
>  }
> -/* XXX Maybe this should be the other way around? */
> -if (min > reqmin) {
> +if (min < reqmin) {
>  LogMessageVerb(X_WARNING, 2, "%s: module ABI minor version "
> "(%d) is newer than that available (%d)\n",
> module, min, reqmin);

I guess the message should be fixed too?

Cheers,
Julien
___
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 06/19] loader: Remove *GetOS

[Julien Cristau]

On Mon, Jan 23, 2017 at 14:32:20 -0500, Adam Jackson wrote:

> This API is dumb.  uname(3) exists, feel free to use it, but ideally
> write to the interface not to the OS.  There are a couple of drivers
> using this API, they could all reasonably just not.
> 
It's uname(2) AFAICT :)

Cheers,
Julien
___
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 04/19] xfree86: flatten pathlist management in the loader

[Julien Cristau]

On Mon, Jan 23, 2017 at 14:32:18 -0500, Adam Jackson wrote:

> From: Emil Velikov 
> 
> Now that used can set the path only via LoaderSetPath(), we can simplify
> things.
> 
used -> users, maybe?

Cheers,
Julien
___
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 01/19] xfree86: remove references from LoadSubModule's path from the doc

[Julien Cristau]

On Mon, Jan 23, 2017 at 14:32:15 -0500, Adam Jackson wrote:

> From: Emil Velikov 
> 
> Afaics the argument hasn't been part of the API since the documentation
> has been converted to xml with commit fc6ebe1e1d3 "Convert LinuxDoc
> documents to DocBook/XML"
> 
The commit message seems confused.  AFAICT the text says "LoadSubModule
is like LoadModule except it doesn't take a 'path' parameter", which
until patch 2 seems to be correct?

Cheers,
Julien

> Signed-off-by: Emil Velikov 
> ---
>  hw/xfree86/doc/ddxDesign.xml | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
> index f7d6628..b62272d 100644
> --- a/hw/xfree86/doc/ddxDesign.xml
> +++ b/hw/xfree86/doc/ddxDesign.xml
> @@ -5695,11 +5695,7 @@ the server, and may also be used from within modules.
>  described above, except that the module loaded is registered as a
>  child of the calling module.  The parent parameter
>  is the calling module's handle.  Modules loaded with this function
> -are automatically unloaded when the parent module is unloaded.  The
> -other difference is that the path parameter may not be specified.
> -The module search path used for modules loaded with this function
> -is the default search path as initialised with
> -LoaderSetPath().
> +are automatically unloaded when the parent module is unloaded.
>   
>  
> 
> -- 
> 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
___
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:xdm] Install xdm man pages under admin section (8), not user programs (1)

[Julien Cristau]

On Mon, Jan 16, 2017 at 16:26:08 -0800, Alan Coopersmith wrote:

> As best I can tell, it was historically under section 1 mainly because
> the old X Consortium Imake configs only supporting installing program
> man pages there, and didn't have an option for using other sections.
> 
> Signed-off-by: Alan Coopersmith 
> ---
> 
> I'm sending this out not just for review that I made the right changes,
> but to see if there's general agreement this change is right.  It was
> pointed out by one of our users who thought it odd that gdm's man page
> is in section 8, but xdm's is in section 1.
> 
That seems right to me.

Cheers,
Julien
___
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 libXrandr] Avoid out of boundary accesses on illegal responses

[Julien Cristau]

[resending with xorg-devel cc added which I forgot the first time around]

On Sun, Sep 25, 2016 at 22:50:44 +0200, Matthieu Herrb wrote:

> diff --git a/src/XrrCrtc.c b/src/XrrCrtc.c
> index 5ae35c5..6665092 100644
> --- a/src/XrrCrtc.c
> +++ b/src/XrrCrtc.c
[...]
> @@ -357,7 +378,7 @@ XRRGetCrtcTransform (Display  *dpy,
>  xRRGetCrtcTransformReq   *req;
>  int  major_version, minor_version;
>  XRRCrtcTransformAttributes   *attr;
> -char *extra = NULL, *e;
> +char *extra = NULL, *end = NULL, *e;
>  int  p;
>  
>  *attributes = NULL;
> @@ -395,9 +416,17 @@ XRRGetCrtcTransform (Display *dpy,
>   else
>   {
>   int extraBytes = rep.length * 4 - CrtcTransformExtra;
> - extra = Xmalloc (extraBytes);
> + if (rep.length < INT_MAX / 4 &&
> + rep.length * 4 >= CrtcTransformExtra) {
> + extra = Xmalloc (extraBytes);
> + end = extra + extraBytes;
> + } else
> + extra = NULL;
>   if (!extra) {
> - _XEatDataWords (dpy, rep.length - (CrtcTransformExtra >> 2));
> + if (rep.length > (CrtcTransformExtra >> 2))
> + _XEatDataWords (dpy, rep.length - (CrtcTransformExtra >> 
> 2));
> + else
> + _XEatDataWords (dpy, rep.length);
>   UnlockDisplay (dpy);
>   SyncHandle ();
>   return False;
> @@ -429,22 +458,38 @@ XRRGetCrtcTransform (Display*dpy,
>  
>  e = extra;
>  
> +if (e + rep.pendingNbytesFilter > end) {
> + XFree (extra);
> + return False;
> +}
>  memcpy (attr->pendingFilter, e, rep.pendingNbytesFilter);
>  attr->pendingFilter[rep.pendingNbytesFilter] = '\0';
>  e += (rep.pendingNbytesFilter + 3) & ~3;
>  for (p = 0; p < rep.pendingNparamsFilter; p++) {
>   INT32   f;
> + if (e + 4 > end) {
> + XFree (extra);
> + return False;
> + }
>   memcpy (, e, 4);
>   e += 4;
>   attr->pendingParams[p] = (XFixed) f;
>  }
>  attr->pendingNparams = rep.pendingNparamsFilter;
>  
> +if (e + rep.currentNbytesFilter > end) {
> + XFree (extra);
> + return False;
> +}
>  memcpy (attr->currentFilter, e, rep.currentNbytesFilter);
>  attr->currentFilter[rep.currentNbytesFilter] = '\0';
>  e += (rep.currentNbytesFilter + 3) & ~3;
>  for (p = 0; p < rep.currentNparamsFilter; p++) {
>   INT32   f;
> + if (e + 4 > end) {
> + XFree (extra);
> + return False;
> + }
>   memcpy (, e, 4);
>   e += 4;
>   attr->currentParams[p] = (XFixed) f;

It looks like we're leaking 'attr' on these error paths?

Cheers,
Julien
___
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 libXrender 1/2] Avoid OOB write in XRenderQueryFilters

[Julien Cristau]

On Sun, Sep 25, 2016 at 22:50:45 +0200, Matthieu Herrb wrote:

> From: Tobias Stoeckmann 
> 
> The memory for filter names is reserved right after receiving the reply.
> After that, filters are iterated and each individual filter name is
> stored in that reserved memory.
> 
> The individual name lengths are not checked for validity, which means
> that a malicious server can reserve less memory than it will write to
> during each iteration.
> 
> v2: consume remaining bytes in reply buffer on error.
> 
> Signed-off-by: Tobias Stoeckmann 
> Reviewed-by: Matthieu Herrb 
> ---
>  src/Filter.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/src/Filter.c b/src/Filter.c
> index edfa572..8d701eb 100644
> --- a/src/Filter.c
> +++ b/src/Filter.c
> @@ -38,7 +38,7 @@ XRenderQueryFilters (Display *dpy, Drawable drawable)
>  char *name;
>  char len;
>  int  i;
> -unsigned longnbytes, nbytesAlias, nbytesName;
> +unsigned longnbytes, nbytesAlias, nbytesName, reply_left;
>  
>  if (!RenderHasExtension (info))
>   return NULL;
> @@ -114,6 +114,7 @@ XRenderQueryFilters (Display *dpy, Drawable drawable)
>   * Read the filter aliases
>   */
>  _XRead16Pad (dpy, filters->alias, 2 * rep.numAliases);
> +reply_left = 8 + rep.length - 2 * rep.numAliases;;
>  
reply_left looks like a byte count, in which case shouldn't rep.length
be multiplied by 4?  I don't get where that 8 comes from, either, any
chance you could explain?  In fact I wonder if this couldn't use
nbytesName instead?

Cheers,
Julien
___
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 libX11] Fix wrong Xfree in XListFonts failure path

[Julien Cristau]

'ch' gets moved inside the allocated buffer as we're looping through
fonts, so keep a reference to the start of the buffer so we can pass
that to Xfree in the failure case.

Fixes: commit 20a3f99eba5001925b8b313da3accb7900eb1927 "Plug a memory leak"

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 src/FontNames.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/FontNames.c b/src/FontNames.c
index 3e23b5f4..9ffdfd29 100644
--- a/src/FontNames.c
+++ b/src/FontNames.c
@@ -43,6 +43,7 @@ int *actualCount) /* RETURN */
 register int length;
 char **flist = NULL;
 char *ch = NULL;
+char *chstart;
 char *chend;
 int count = 0;
 xListFontsReply rep;
@@ -86,6 +87,7 @@ int *actualCount) /* RETURN */
/*
 * unpack into null terminated strings.
 */
+   chstart = ch;
chend = ch + (rlen + 1);
length = *(unsigned char *)ch;
*ch = 1; /* make sure it is non-zero for XFreeFontNames */
@@ -98,14 +100,14 @@ int *actualCount)  /* RETURN */
*ch = '\0';  /* and replace with null-termination */
count++;
} else {
-Xfree(ch);
+Xfree(chstart);
 Xfree(flist);
 flist = NULL;
 count = 0;
 break;
}
} else {
-Xfree(ch);
+Xfree(chstart);
 Xfree(flist);
 flist = NULL;
 count = 0;
-- 
2.11.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 libxi] Fix possible free of uninitialized pointer

[Julien Cristau]

On Tue, Dec 27, 2016 at 17:24:10 +0100, Emilio Pozuelo Monfort wrote:

> If the _XReply() call fails, we'll try to free an uninitialized
> pointer.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849026
> 
> Reported-by: Thomas Walker <thwalk...@gmail.com>
> Signed-off-by: Emilio Pozuelo Monfort <po...@debian.org>
> Reviewed-by: Julien Cristau <jcris...@debian.org>
> Tested-by: Thomas Walker <thwalk...@gmail.com>
> ---
>  src/XIQueryDevice.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
remote: Updating patchwork state for
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #129240 updated using rev
557b60798a9da49386f1034b133838332735de22.
remote: I: 1 patch(es) updated to state Accepted.
To git.freedesktop.org:/git/xorg/lib/libXi
   4c5c8d6..557b607  master -> master

Cheers,
Julien
___
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] xf86-video-dummy 0.3.8

[Julien Cristau]

This new release of the dummy Xorg video driver adds a few cleanups and
compatibility with xorg-server 1.19.

Aaron Plattner (1):
  Remove pointless empty functions

Alan Coopersmith (2):
  configure: Drop AM_MAINTAINER_MODE
  autogen.sh: Honor NOCONFIGURE=1

Antoine Martin (2):
  Honor DacSpeed setting in xorg.conf
  remove dead code in dummy driver

Julien Cristau (2):
  configure: require xorg-server 1.4.99.901
  xf86-video-dummy 0.3.8

Peter Hutterer (1):
  Switch to using dixChangeWindowProperty

git tag: xf86-video-dummy-0.3.8

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.bz2
MD5:  dfd8b9d02a5f12decd474b4c52775977  xf86-video-dummy-0.3.8.tar.bz2
SHA1: 6d24be1c693214935b298bf6f9457ee464d5c4fd  xf86-video-dummy-0.3.8.tar.bz2
SHA256: 3712bb869307233491e4c570732d6073c0dc3d99adfdb9977396a3fdf84e95b9  
xf86-video-dummy-0.3.8.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.gz
MD5:  6f784c63f617b566289e6e9755c592da  xf86-video-dummy-0.3.8.tar.gz
SHA1: 0fe3a6af409372f2eacf72e021b227983db9ea91  xf86-video-dummy-0.3.8.tar.gz
SHA256: ee5ad51e80c8cc90d4c76ac3dec2269a3c769f4232ed418b29d60d618074631b  
xf86-video-dummy-0.3.8.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.gz.sig



signature.asc
Description: 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

[ANNOUNCE] xf86-video-dummy 0.3.8

[Julien Cristau]

This new release of the dummy Xorg video driver adds a few cleanups and
compatibility with xorg-server 1.19.

Aaron Plattner (1):
  Remove pointless empty functions

Alan Coopersmith (2):
  configure: Drop AM_MAINTAINER_MODE
  autogen.sh: Honor NOCONFIGURE=1

Antoine Martin (2):
  Honor DacSpeed setting in xorg.conf
  remove dead code in dummy driver

Julien Cristau (2):
  configure: require xorg-server 1.4.99.901
  xf86-video-dummy 0.3.8

Peter Hutterer (1):
  Switch to using dixChangeWindowProperty

git tag: xf86-video-dummy-0.3.8

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.bz2
MD5:  dfd8b9d02a5f12decd474b4c52775977  xf86-video-dummy-0.3.8.tar.bz2
SHA1: 6d24be1c693214935b298bf6f9457ee464d5c4fd  xf86-video-dummy-0.3.8.tar.bz2
SHA256: 3712bb869307233491e4c570732d6073c0dc3d99adfdb9977396a3fdf84e95b9  
xf86-video-dummy-0.3.8.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.gz
MD5:  6f784c63f617b566289e6e9755c592da  xf86-video-dummy-0.3.8.tar.gz
SHA1: 0fe3a6af409372f2eacf72e021b227983db9ea91  xf86-video-dummy-0.3.8.tar.gz
SHA256: ee5ad51e80c8cc90d4c76ac3dec2269a3c769f4232ed418b29d60d618074631b  
xf86-video-dummy-0.3.8.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-dummy-0.3.8.tar.gz.sig



signature.asc
Description: PGP signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present

[Julien Cristau]

On Wed, Oct  5, 2016 at 09:42:19 -0700, Keith Packard wrote:

> If we're never painting anything in the window, we probably don't need
> to map it.
> 
> Signed-off-by: Keith Packard 
> ---
>  hw/kdrive/ephyr/hostx.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
> index 887f654..f49ed02 100644
> --- a/hw/kdrive/ephyr/hostx.c
> +++ b/hw/kdrive/ephyr/hostx.c
> @@ -95,6 +95,7 @@ char *ephyrResName = NULL;
>  int ephyrResNameFromCmd = 0;
>  char *ephyrTitle = NULL;
>  Bool ephyr_glamor = FALSE;
> +extern Bool ephyr_glamor_gles2, ephyr_glamor_skip_present;
>  
>  Bool
>  hostx_has_extension(xcb_extension_t *extension)

The extern ephyr_glamor_skip_present declaration should probably live in
ephyr_glamor_glx.h so mismatches between it and ephyr_glamor_glx.c are
caught.

Cheers,
Julien
___
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 libXi] Properly validate server responses.

[Julien Cristau]

On Sun, Sep 25, 2016 at 22:50:43 +0200, Matthieu Herrb wrote:

> From: Tobias Stoeckmann 
> 
> By validating length fields from server responses, out of boundary
> accesses and endless loops can be mitigated.
> 
> Signed-off-by: Tobias Stoeckmann 
> Reviewed-by: Matthieu Herrb 
> ---
>  src/XGMotion.c  |  3 ++-
>  src/XGetBMap.c  |  3 ++-
>  src/XGetDCtl.c  |  6 --
>  src/XGetFCtl.c  |  7 ++-
>  src/XGetKMap.c  | 14 +++---
>  src/XGetMMap.c  | 11 +--
>  src/XIQueryDevice.c | 36 ++--
>  src/XListDev.c  | 21 +++--
>  src/XOpenDev.c  | 13 ++---
>  src/XQueryDv.c  |  8 ++--
>  10 files changed, 99 insertions(+), 23 deletions(-)
> 
[...]
> diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c
> index fb8504f..a457cd6 100644
> --- a/src/XIQueryDevice.c
> +++ b/src/XIQueryDevice.c
> @@ -26,6 +26,7 @@
>  #include 
>  #endif
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -43,6 +44,7 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  xXIQueryDeviceReq   *req;
>  xXIQueryDeviceReply reply;
>  char*ptr;
> +char*end;
>  int i;
>  char*buf;
>  
> @@ -60,14 +62,24 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  if (!_XReply(dpy, (xReply*) , 0, xFalse))
>  goto error;
>  
> -*ndevices_return = reply.num_devices;
> -info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo));
> +if (reply.length < INT_MAX / 4)
> +{
> + *ndevices_return = reply.num_devices;
> + info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo));
> +}
> +else
> +{
> + *ndevices_return = 0;
> + info = NULL;
> +}
> +
>  if (!info)
>  goto error;
>  
>  buf = Xmalloc(reply.length * 4);

Should we check for allocation failure here?

>  _XRead(dpy, buf, reply.length * 4);
>  ptr = buf;
> +end = buf + reply.length * 4;
>  
>  /* info is a null-terminated array */
>  info[reply.num_devices].name = NULL;
> @@ -79,6 +91,9 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  XIDeviceInfo*lib = [i];
>  xXIDeviceInfo   *wire = (xXIDeviceInfo*)ptr;
>  
> +if (ptr + sizeof(xXIDeviceInfo) > end)
> +goto error_loop;
> +
>  lib->deviceid= wire->deviceid;
>  lib->use = wire->use;
>  lib->attachment  = wire->attachment;
> @@ -87,12 +102,23 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  
>  ptr += sizeof(xXIDeviceInfo);
>  
> +if (ptr + wire->name_len > end)
> +goto error_loop;
> +
>  lib->name = Xcalloc(wire->name_len + 1, 1);
> +if (lib->name == NULL)
> +goto error_loop;
>  strncpy(lib->name, ptr, wire->name_len);
> +lib->name[wire->name_len] = '\0';
>  ptr += ((wire->name_len + 3)/4) * 4;
>  
>  sz = size_classes((xXIAnyInfo*)ptr, nclasses);
>  lib->classes = Xmalloc(sz);
> +if (lib->classes == NULL)
> +{
> +Xfree(lib->name);
> +goto error_loop;
> +}
>  ptr += copy_classes(lib, (xXIAnyInfo*)ptr, );
>  /* We skip over unused classes */
>  lib->num_classes = nclasses;
> @@ -103,6 +129,12 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  SyncHandle();
>  return info;
>  
> +error_loop:
> +while (--i >= 0)
> +{
> +Xfree(info[i].name);
> +Xfree(info[i].classes);
> +}
>  error:
>  UnlockDisplay(dpy);
>  error_unlocked:

AFAICT this is missing
Xfree(info);
Xfree(buf);

Cheers,
Julien
___
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 libX11 1/2] The validation of server responses avoids out of boundary accesses.

[Julien Cristau]

Hi all,

Sorry I didn't get a chance to look at these before they went public...

On Sun, Sep 25, 2016 at 22:50:40 +0200, Matthieu Herrb wrote:

> From: Tobias Stoeckmann 
> 
> v2: FontNames.c  return a NULL list whenever a single
> length field from the server is incohent.
> 
> Signed-off-by: Tobias Stoeckmann 
> Reviewed-by: Matthieu Herrb 
> ---
>  src/FontNames.c | 23 +--
>  src/ListExt.c   | 12 
>  src/ModMap.c|  3 ++-
>  3 files changed, 27 insertions(+), 11 deletions(-)
> 
> diff --git a/src/FontNames.c b/src/FontNames.c
> index 21dcafe..e55f338 100644
> --- a/src/FontNames.c
> +++ b/src/FontNames.c
> @@ -66,7 +66,7 @@ int *actualCount)   /* RETURN */
>  
>  if (rep.nFonts) {
>   flist = Xmalloc (rep.nFonts * sizeof(char *));
> - if (rep.length < (INT_MAX >> 2)) {
> + if (rep.length > 0 && rep.length < (INT_MAX >> 2)) {
>   rlen = rep.length << 2;
>   ch = Xmalloc(rlen + 1);
>   /* +1 to leave room for last null-terminator */
> @@ -93,11 +93,22 @@ int *actualCount) /* RETURN */
>   if (ch + length < chend) {
>   flist[i] = ch + 1;  /* skip over length */
>   ch += length + 1;  /* find next length ... */
> - length = *(unsigned char *)ch;
> - *ch = '\0';  /* and replace with null-termination */
> - count++;
> - } else
> - flist[i] = NULL;
> + if (ch <= chend) {
> + length = *(unsigned char *)ch;
> + *ch = '\0';  /* and replace with null-termination */
> + count++;
> + } else {
> +Xfree(flist);
> +flist = NULL;
> +count = 0;
> +break;
> + }
> + } else {
> +Xfree(flist);
> +flist = NULL;
> +count = 0;
> +break;
> +}
>   }
>  }
>  *actualCount = count;

I believe these new error paths are missing Xfree(ch).

> diff --git a/src/ListExt.c b/src/ListExt.c
> index be6b989..0516e45 100644
> --- a/src/ListExt.c
> +++ b/src/ListExt.c
> @@ -55,7 +55,7 @@ char **XListExtensions(
>  
>   if (rep.nExtensions) {
>   list = Xmalloc (rep.nExtensions * sizeof (char *));
> - if (rep.length < (INT_MAX >> 2)) {
> + if (rep.length > 0 && rep.length < (INT_MAX >> 2)) {
>   rlen = rep.length << 2;
>   ch = Xmalloc (rlen + 1);
>  /* +1 to leave room for last null-terminator */
> @@ -80,9 +80,13 @@ char **XListExtensions(
>   if (ch + length < chend) {
>   list[i] = ch+1;  /* skip over length */
>   ch += length + 1; /* find next length ... */
> - length = *ch;
> - *ch = '\0'; /* and replace with null-termination */
> - count++;
> + if (ch <= chend) {
> + length = *ch;
> + *ch = '\0'; /* and replace with null-termination */
> + count++;
> + } else {
> + list[i] = NULL;
> + }
>   } else
>   list[i] = NULL;
>   }

This might have been more readable by just replacing the previous
if (ch + length < chend)
with
if (ch + length + 1 < chend)
?

Cheers,
Julien
___
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 05/10 v2] test: Add a little xinit-like program for starting servers for testing.

[Julien Cristau]

On Fri, Sep 23, 2016 at 10:58:54 +0300, Eric Anholt wrote:

> The normal xinit is racy because it doesn't use -displayfd.  This
> implements the bare minimum for testing purposes, using -displayfd to
> sequence starting the client, and avoids adding yet another dependency
> to the server.
> 
> v2: Fix asprintf error checks.
> 
> Signed-off-by: Eric Anholt 
> ---
>  test/.gitignore |   1 +
>  test/Makefile.am|  13 ++-
>  test/simple-xinit.c | 223 
> 
>  3 files changed, 233 insertions(+), 4 deletions(-)
>  create mode 100644 test/simple-xinit.c
> 
Two other things I noticed:
- lack of error checking for fork()
- this allocation:
> +char **args_storage = calloc(argc + 2, sizeof(char **));
  should be calloc(argc + 2, sizeof(char *))
  (no actual difference, though, so meh)

Other than that the series looks good to me.

Cheers,
Julien
___
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 xbitmaps] Install pkgconfig file into arch-dependent location

[Julien Cristau]

On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:

> Signed-off-by: Heiko Becker 
> ---
>  Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 060112d..9a89bbe 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -1,4 +1,4 @@
> -pkgconfigdir = $(datadir)/pkgconfig
> +pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = xbitmaps.pc
>  
>  MAINTAINERCLEANFILES = ChangeLog INSTALL

That seems like it's going backwards, and your commit message doesn't
explain why.

Cheers,
Julien
___
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 06/10] test: Make the piglit-running script callable with an arbitrary server.

[Julien Cristau]

On Thu, Sep 22, 2016 at 11:45:07 +0300, Eric Anholt wrote:

> diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/run-piglit.sh
> similarity index 90%
> copy from test/scripts/xvfb-piglit.sh
> copy to test/scripts/run-piglit.sh
> index b775239e34f5..ab37ee3b92ad 100755
> --- a/test/scripts/xvfb-piglit.sh
> +++ b/test/scripts/run-piglit.sh
> @@ -14,6 +14,12 @@ if test "x$PIGLIT_DIR" = "x"; then
>  exit 77
>  fi
>  
> +if test "x$PIGLIT_RESULTS_DIR" = "x"; then
> +echo "PIGLIT_RESULTS_DIR must be set to where to output piglit results."
> +# Exit as a real failure because it should always be set.
> +exit 1
> +fi
> +
>  if test "x$XSERVER_DIR" = "x"; then
>  echo "XSERVER_DIR must be set to the directory of the xserver 
> repository."
>  # Exit as a real failure because it should always be set.
> @@ -26,14 +32,10 @@ if test "x$XSERVER_BUILDDIR" = "x"; then
>  exit 1
>  fi
>  
> -export PIGLIT_RESULTS_DIR=$PIGLIT_DIR/results/xvfb
> -
>  startx \
>  $XSERVER_DIR/test/scripts/xinit-piglit-session.sh \
>  -- \
> -$XSERVER_BUILDDIR/hw/vfb/Xvfb \
> --noreset \
> --screen scrn 1280x1024x24
> +$SERVER_COMMAND
>  
>  # Write out piglit-summaries.
>  SHORT_SUMMARY=$PIGLIT_RESULTS_DIR/summary

Should this check up-front that SERVER_COMMAND is set, like the other
variables?

Cheers,
Julien
___
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 05/10] test: Add a little xinit-like program for starting servers for testing.

[Julien Cristau]

On Thu, Sep 22, 2016 at 11:45:06 +0300, Eric Anholt wrote:

> +asprintf(_string, "%d", displayfd);
> +if (!displayfd_string)
> +exit(1);

I think you need to check the return value from asprintf, not
displayfd_string:

   When  successful,  these  functions return the number of bytes printed,
   just like sprintf(3).  If memory allocation wasn't  possible,  or  some
   other error occurs, these functions will return -1, and the contents of
   strp are undefined.

Cheers,
Julien
___
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 00/10] release.sh cleanups, mesa support and more

[Julien Cristau]

On Tue, Sep 20, 2016 at 01:03:33 +0100, Emil Velikov wrote:

> On 15 September 2016 at 15:12, Julien Cristau <jcris...@debian.org> wrote:
[...]
> > For 1, 3, 4, 5, 7 (assuming 10 goes in in some way):
> > Reviewed-by: Julien Cristau <jcris...@debian.org>
> >
> Thanks, can you push 1, 3, 4, 5 (and 7 ?). I'm short on commit access.
> 
Pushed 1, 3, 4, 5, 6.  Skipped 7 because it sounds like mesa can be
downloaded over https as well.

[...]
> >  9 seems to add a new requirement that I'm not sure is ok.
> On the contrary it should remove/simplify things.
> 
> But as the commit mentions, if people prefer I can rework to have an
> option in a --dist vs --distcheck line manner. Keeping it "off" by
> default, with the long term goal to make it "on" by default.
> 
I don't think adding an option is a good idea, but I also don't know
what problem this is trying to fix...

Cheers,
Julien
___
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 00/10] release.sh cleanups, mesa support and more

[Julien Cristau]

On Fri, Jul  1, 2016 at 15:44:41 +0100, Emil Velikov wrote:

> Hi all,
> 
> A series that I've had around for long time. It covers three main topics.
>  - misc cleanups and small reformatting in prep. for mesa support
>  - mesa support (10/10)
>  - give us control to autoreconf, configure and build_dir (09/10).
> 
> The last option might be a bit controversial, yet it effectively allows 
> us to remove the "user must run autoreconf/configure" requirement 
> from every single package. If configure is OK, `make distcheck' should 
> produce consistent result, and the tarball contents should not vary.
> 
> It also minimises the chances of stale (generated) files being used as 
> we suggest git clean -fXd/fxd, and we use fresh, unique build_dir. IMHO 
> it also makes things more reproducible, yet again... I'm too flesh on 
> the topic to be an expert.
> 
> As always, any and all comments, suggestions are appreciated.
> 
For 1, 3, 4, 5, 7 (assuming 10 goes in in some way):
Reviewed-by: Julien Cristau <jcris...@debian.org>

Not a fan of 2 and 6.  I don't have enough context to understand what 8
changes.  9 seems to add a new requirement that I'm not sure is ok.  And
I wish mesa stopped using a separate directory per release :)

Cheers,
Julien
___
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 2/2] release.sh: use https for URLs in announcement

[Julien Cristau]

{xorg,dri,wayland,www}.freedesktop.org are all https now.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 release.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/release.sh b/release.sh
index bb3f17a..6d5ac80 100755
--- a/release.sh
+++ b/release.sh
@@ -103,11 +103,11 @@ RELEASE
 
 for tarball in $tarbz2 $targz $tarxz; do
cat <http://$host_current/$section_path/$tarball
+https://$host_current/$section_path/$tarball
 MD5:  `$MD5SUM $tarball`
 SHA1: `$SHA1SUM $tarball`
 SHA256: `$SHA256SUM $tarball`
-PGP:  http://${host_current}/${section_path}/${tarball}.sig
+PGP:  https://${host_current}/${section_path}/${tarball}.sig
 
 RELEASE
 done
-- 
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 util/modular 1/2] release.sh: use canonical address for xorg mailing lists

[Julien Cristau]

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 release.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/release.sh b/release.sh
index ef384de..bb3f17a 100755
--- a/release.sh
+++ b/release.sh
@@ -504,10 +504,10 @@ process_module() {
 host_wayland="wayland.freedesktop.org"
 
 # Mailing lists where to post the all [Announce] e-mails
-list_to="xorg-annou...@lists.freedesktop.org"
+list_to="xorg-annou...@lists.x.org"
 
 # Mailing lists to be CC according to the project (xorg|dri|xkb)
-list_xorg_user="x...@lists.freedesktop.org"
+list_xorg_user="x...@lists.x.org"
 list_dri_devel="dri-de...@lists.freedesktop.org"
 list_xkb="x...@listserv.bat.ru"
 list_xcb="x...@lists.freedesktop.org"
-- 
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] config/dbus: Initialize dbus fd to -1 so teardown doesn't use fd 0

[Julien Cristau]

On Wed, Sep 14, 2016 at 22:44:15 -0700, Keith Packard wrote:

> The dbus teardown code is called when the server fatal errors even if
> that is before dbus has ever been initialized.  By statically
> initializing the value of bus_info.fd, we avoid calling RemoveNotifyFd
> on stdin.
> 
> Signed-off-by: Keith Packard <kei...@keithp.com>
> ---
>  config/dbus-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien

> diff --git a/config/dbus-core.c b/config/dbus-core.c
> index 3c85ad7..6d9a3f9 100644
> --- a/config/dbus-core.c
> +++ b/config/dbus-core.c
> @@ -43,7 +43,7 @@ struct dbus_core_info {
>  OsTimerPtr timer;
>  struct dbus_core_hook *hooks;
>  };
> -static struct dbus_core_info bus_info;
> +static struct dbus_core_info bus_info = { .fd = -1 };
>  
>  static CARD32 reconnect_timer(OsTimerPtr timer, CARD32 time, void *arg);
>  
> -- 
> 2.8.1
> 
> ___
> 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
___
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 2/3] Xext/shm: Better support cases where O_CLOEXEC is not defined

[Julien Cristau]

On Mon, Sep 12, 2016 at 10:53:39 -0700, Jeremy Huddleston Sequoia wrote:

> 
> > On Sep 12, 2016, at 04:33, Julien Cristau <jcris...@debian.org> wrote:
> > 
> > On Sun, Sep 11, 2016 at 20:01:50 -0700, Jeremy Huddleston Sequoia wrote:
> > 
> >> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
> >> ---
> >> Xext/shm.c | 6 +-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >> 
> > Does anything have O_TMPFILE but not O_CLOEXEC?
> 
> Not sure, but I figured it'd be good to be on the safe side.  Snow Leopard 
> (OS X 10.6) doesn't have either.  I saw this when making the change to check 
> for O_CLOEXEC in os/inputthread and thought I'd bring it up for consideration.
> 
> If you don't think that O_TMPFILE && !O_CLOEXEC is something we'll see in the 
> wild, I'm happy to just leave it as is.
> 
As far as I know O_TMPFILE is a Linux-ism, so my vote would be for
leaving this as-is until it becomes a problem, if ever.

Cheers,
Julien
___
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 3/3] os/inputthread: Fix setting of cloexec on file descriptors

[Julien Cristau]

On Sun, Sep 11, 2016 at 20:01:51 -0700, Jeremy Huddleston Sequoia wrote:

> O_CLOEXEC is not a file bit.  It is not setable with F_SETFL.  One must use it
> when calling open(2).  To set it cloexec on an existing fd, F_SETFD and
> FD_CLOEXEC must be used.
> 
> This also fixes a build failure regression on configurations that don't have
> O_CLOEXEC defined.
> 
> cf: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
> Regressed-in: 30ac7567980a1eb79d084a63e0e74e1d9a3af673
> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
> ---
>  os/inputthread.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
A possible further improvement would be to use pipe2(2) where available
to set O_CLOEXEC immediately, rather than as a separate step.

Anyway, this gets my
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien

> diff --git a/os/inputthread.c b/os/inputthread.c
> index 2ea39e7..6aa0a9c 100644
> --- a/os/inputthread.c
> +++ b/os/inputthread.c
> @@ -385,6 +385,7 @@ void
>  InputThreadPreInit(void)
>  {
>  int fds[2], hotplugPipe[2];
> +int flags;
>  
>  if (!InputThreadEnable)
>  return;
> @@ -408,13 +409,23 @@ InputThreadPreInit(void)
>   * in parallel.
>   */
>  inputThreadInfo->readPipe = fds[0];
> -fcntl(inputThreadInfo->readPipe, F_SETFL, O_NONBLOCK | O_CLOEXEC);
> +fcntl(inputThreadInfo->readPipe, F_SETFL, O_NONBLOCK);
> +flags = fcntl(inputThreadInfo->readPipe, F_GETFD);
> +if (flags != -1) {
> +flags |= FD_CLOEXEC;
> +(void)fcntl(inputThreadInfo->readPipe, F_SETFD, );
> +}
>  SetNotifyFd(inputThreadInfo->readPipe, InputThreadNotifyPipe, 
> X_NOTIFY_READ, NULL);
>  
>  inputThreadInfo->writePipe = fds[1];
>  
>  hotplugPipeRead = hotplugPipe[0];
> -fcntl(hotplugPipeRead, F_SETFL, O_NONBLOCK | O_CLOEXEC);
> +fcntl(hotplugPipeRead, F_SETFL, O_NONBLOCK);
> +flags = fcntl(hotplugPipeRead, F_GETFD);
> +if (flags != -1) {
> +flags |= FD_CLOEXEC;
> +(void)fcntl(hotplugPipeRead, F_SETFD, );
> +}
>  hotplugPipeWrite = hotplugPipe[1];
>  
>  #if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID)
> -- 
> 2.10.0 (Apple Git-99)
> 
> ___
> 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
___
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 2/3] Xext/shm: Better support cases where O_CLOEXEC is not defined

[Julien Cristau]

On Sun, Sep 11, 2016 at 20:01:50 -0700, Jeremy Huddleston Sequoia wrote:

> Signed-off-by: Jeremy Huddleston Sequoia 
> ---
>  Xext/shm.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
Does anything have O_TMPFILE but not O_CLOEXEC?

Cheers,
Julien

> diff --git a/Xext/shm.c b/Xext/shm.c
> index 125000f..7a45dbd 100644
> --- a/Xext/shm.c
> +++ b/Xext/shm.c
> @@ -1202,7 +1202,11 @@ shm_tmpfile(void)
>   int flags;
>   chartemplate[] = SHMDIR "/shmfd-XX";
>  #ifdef O_TMPFILE
> - fd = open(SHMDIR, O_TMPFILE|O_RDWR|O_CLOEXEC|O_EXCL, 0666);
> + flags = O_TMPFILE|O_RDWR|O_EXCL;
> +#ifdef O_CLOEXEC
> + flags |= O_CLOEXEC;
> +#endif
> + fd = open(SHMDIR, flags, 0666);
>   if (fd >= 0) {
>   ErrorF ("Using O_TMPFILE\n");
>   return fd;
> -- 
> 2.10.0 (Apple Git-99)
> 
> ___
> 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
___
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 1/3] Xext/shm: Fix usage of F_GETFD to match standard

[Julien Cristau]

On Sun, Sep 11, 2016 at 20:01:49 -0700, Jeremy Huddleston Sequoia wrote:

> flags = fcntl(fd, F_GETFD) is compliant.
> 
> fcntl(fd, F_GETFD, ) is non-compliant (Linux extension?)
> 
> cf: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
> ---
>  Xext/shm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien

> diff --git a/Xext/shm.c b/Xext/shm.c
> index 0557538..125000f 100644
> --- a/Xext/shm.c
> +++ b/Xext/shm.c
> @@ -1213,7 +1213,8 @@ shm_tmpfile(void)
>   if (fd < 0)
>   return -1;
>   unlink(template);
> - if (fcntl(fd, F_GETFD, ) >= 0) {
> + flags = fcntl(fd, F_GETFD);
> + if (flags != -1) {
>   flags |= FD_CLOEXEC;
>   (void) fcntl(fd, F_SETFD, );
>   }
> -- 
> 2.10.0 (Apple Git-99)
> 
> ___
> 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
___
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] test: Remember to swap the window argument to XIQueryPointer

[Julien Cristau]

On Wed, Aug 17, 2016 at 10:43:27 -0400, Adam Jackson wrote:

> Before 5c69cb60 this wouldn't matter, because ProcXIQueryPointer
> manually emitted its own error before (bogusly) returning Success to the
> main loop. Since these tests only look at the return value of the
> dispatch function we'd think things succeeded even when we'd generated
> an error.
> 
> With that fixed, the test code's failure to swap the window id would
> make dixLookupWindow (rightly) throw BadWindow.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  test/xi2/protocol-xiquerypointer.c | 1 +
>  1 file changed, 1 insertion(+)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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 --gpgkey option

[Julien Cristau]

On Tue, Jul 19, 2016 at 15:27:02 +0100, Emil Velikov wrote:

> From: Emil Velikov 
> 
> To allow users with multiple keys to select the appropriate one.
> 
> Signed-off-by: Emil Velikov 
> ---
> All the "if x$GPGKEY = x" checking looks iffy so any suggestions how to
> minimise/remove it are greatly appreciated.

Set GPGKEY to "-u $1" instead of just $1, and pass that to gpg / git tag
unconditionally?

Cheers,
Julien
___
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] linux: Do not try to open /dev/vc/0, fix error msg when /dev/tty0 open fails

[Julien Cristau]

On Thu, Jul  7, 2016 at 10:55:04 +0200, Hans de Goede wrote:

> /dev/vc/0 is a devfs thing which is long dead, so stop trying to open
> /dev/vc/0, besides being a (small) code cleanup this will also fix the
> "parse_vt_settings: Cannot open /dev/tty0 (%s)\n" error message to
> display the actual error, rather then the -ENOENT from also trying
> /dev/vc/0.
> 
> BugLink: https://patchwork.freedesktop.org/patch/8768/
> Reported-by: Chad Versace <chad.vers...@linux.intel.com>
> Suggested-by: Julien Cristau <jcris...@debian.org>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> ---
>  hw/xfree86/os-support/linux/lnx_init.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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] xkb: add a cause to the xkb indicator update after a keymap change

[Julien Cristau]

On Tue, Jun 28, 2016 at 11:48:58 +1000, Peter Hutterer wrote:

> Regression introduce by ac164e58870d which calls
> XkbUpdateAllDeviceIndicators() with two NULL arguments. A few layers down into
> the stack and we triggered a NULL-pointer dereference. In theory a NULL cause
> is acceptable since we don't actually change modifier state here. Instead of
> updating all places to check for NULL just set the cause to the client
> request and go to the pub.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=96384
> 
> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> ---
>  xkb/xkb.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
Going to the pub seems like a great plan.

Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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 xf86-input-libinput] Switch to xf86AddEnabledDevice if we have the input thread

[Julien Cristau]

On Mon, May 30, 2016 at 18:12:36 +1000, Peter Hutterer wrote:

> Pre input-thread xf86AddEnabledDevice was hooked up to the signal handler.
> libinput never was capable of running inside a signal handler, so we had to
> use AddEnabledDevice() instead which merely hooks to the server's select loop.
> 
> Now with the input thread we can use xf86AddEnabledDevice and let the server
> decide what is best from there.
> 
> Signed-off-by: Peter Hutterer 
> ---
> Effectively the same but the meat around it is different. More expressive
> with HAVE_INPUT_THEAD and the ABI check instead of AC_CHECK_DECL.
> 
HAVE_INPUT_THREAD with an extra R?

Cheers,
Julien
___
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 17/23] os: Add ospoll interface

[Julien Cristau]

On Sun, May 29, 2016 at 11:35:16 -0700, Keith Packard wrote:

> Emil Velikov  writes:
> 
> > There's two things which I should have mentioned:
> >  - How does one have poll.h when poll() is missing - Cygwin may have
> > the header, although I'm not sure about other Windows based
> > implementations (the mingw and msvc ones).
> 
> I'd expect whatever changes were needed to support those operating
> systems to come from people using them. In particular, Windows has
> winsock2.h, which may provide the necessary values, but as I'm not doing
> that port, I can't really say what changes should be provided. I'd love
> to get feedback from people who can provide it.
> 
> >  - Considering that we have our own header with wrapper functions and
> > an opaque struct, it would make sense to have X server specific
> > macros. Even (ideally) if they are ABI compatible with the POSIX ones.
> 
> Yeah, maybe just using X_NOTIFY_READ, X_NOTIFY_WRITE instead of
> POLLIN/POLLOUT:
> 
> How about:
> 
> #define X_NOTIFY_READ   POLLIN
> #define X_NOTIFY_WRITE  POLLOUT
> #define X_NOTIFY_OTHER  (!(POLLIN|POLLOUT))
> 
I guess you mean ~(POLLIN|POLLOUT).

Cheers,
Julien
___
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] xproto 7.0.29

[Julien Cristau]

Alan Coopersmith (1):
  Incorrect guard block in HPkeysym.h

James Clarke (1):
  Don't let XFD_SETSIZE exceed FD_SETSIZE

Julien Cristau (1):
  xproto 7.0.29

Olivier Fourdan (1):
  Raise the number of FD on WIN32 as well

git tag: xproto-7.0.29

http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.bz2
MD5:  eeeae1f47d43a33ef0d5c56727410326  xproto-7.0.29.tar.bz2
SHA1: e2ea1d12235bfcd83dbc815fb69524ef0be5c1fb  xproto-7.0.29.tar.bz2
SHA256: 6c1a477092ca73233902b8d5f33012635c4b0208f17e7833cc7efe5c93ba9f8a  
xproto-7.0.29.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.gz
MD5:  16a78dd2c5ad73011105c96235f6a0af  xproto-7.0.29.tar.gz
SHA1: 4e222a8f616a521a40fc254357da326e5eef1634  xproto-7.0.29.tar.gz
SHA256: 628243b3a0fa9b65eda804810ab7238cb88af92fe89efdbc858f25ee5e93a324  
xproto-7.0.29.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.gz.sig



signature.asc
Description: 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

[ANNOUNCE] xproto 7.0.29

[Julien Cristau]

Alan Coopersmith (1):
  Incorrect guard block in HPkeysym.h

James Clarke (1):
  Don't let XFD_SETSIZE exceed FD_SETSIZE

Julien Cristau (1):
  xproto 7.0.29

Olivier Fourdan (1):
  Raise the number of FD on WIN32 as well

git tag: xproto-7.0.29

http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.bz2
MD5:  eeeae1f47d43a33ef0d5c56727410326  xproto-7.0.29.tar.bz2
SHA1: e2ea1d12235bfcd83dbc815fb69524ef0be5c1fb  xproto-7.0.29.tar.bz2
SHA256: 6c1a477092ca73233902b8d5f33012635c4b0208f17e7833cc7efe5c93ba9f8a  
xproto-7.0.29.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.gz
MD5:  16a78dd2c5ad73011105c96235f6a0af  xproto-7.0.29.tar.gz
SHA1: 4e222a8f616a521a40fc254357da326e5eef1634  xproto-7.0.29.tar.gz
SHA256: 628243b3a0fa9b65eda804810ab7238cb88af92fe89efdbc858f25ee5e93a324  
xproto-7.0.29.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.29.tar.gz.sig



signature.asc
Description: PGP signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: [PATCH libICE] Bump the major version

[Julien Cristau]

On Thu, May 12, 2016 at 14:27:48 +0100, Emil Velikov wrote:

> With previous commits we've hidden a selection of internal symbols from
> the DSO. Neither of them has been part of the API, although let's do the
> sane thing and bump the major, as we might have changed things in a
> backward incompatible way. I.e. we might have unintentionally broken
> some applications.
> 
> Signed-off-by: Emil Velikov 
> ---
> Funny story... seems that the SONAME still uses the non-modular X
> version (and it hasn't been bumped since the split) while configure uses
> fresher numbers.
> 
> Leaning that we should bump at least the SONAME one, although I've did
> both just in case ;-)

Very much against bumping SONAME.  If you think that's needed as a
result of these patches, then please rethink whether these patches are a
good idea.

Cheers,
Julien
___
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] Xmir DDX

[Julien Cristau]

On Fri, Apr 29, 2016 at 15:25:40 +, Robert Ancell wrote:

> On Fri, Apr 29, 2016 at 4:47 PM Adam Jackson  wrote:
> 
> > On Fri, 2016-04-29 at 11:11 +0200, Robert Ancell wrote:
> > > This is currently used in Ubuntu to allow X applications and sessions to
> > run in
> > > newer versions of Unity 8. For example, this allows applications like
> > GIMP to
> > > run on mobile devices like the Bq Aquaris M10 [2] (currently shipping).
> > >
> > > The proposed patch allows software based rendering only. The XMir used
> > in Ubuntu
> > > contains more changes (developed on Launchpad [3]) that are unlikely to
> > be of
> > > sufficient quality for proposal upstream. We will propose those changes
> > when
> > > they are ready.
> >
> > Your footnotes seem to have gone missing.
> >
> 
> Not sure what you mean by footnotes?
> 
The [2] and [3] dangling references above.

Cheers,
Julien
___
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] kdrive: Nuke a bunch of dead code

[Julien Cristau]

On Fri, Apr 29, 2016 at 11:16:08 -0400, Adam Jackson wrote:

> On Fri, 2016-04-29 at 17:01 +0200, Julien Cristau wrote:
> > On Fri, Apr 29, 2016 at 10:53:22 -0400, Adam Jackson wrote:
> > 
> > > gcc6 says:
> > > 
> > > keyboard.c:46:21: warning: ‘linux_to_x’ defined but not used
> > > 
> > > Only referenced by a bunch of long if-0'd code, so chuck it all out.
> > > 
> > > Signed-off-by: Adam Jackson <a...@redhat.com>
> > > ---
> > >  hw/kdrive/linux/keyboard.c | 441 
> > > -----
> > >  1 file changed, 441 deletions(-)
> > > 
> > Reviewed-by: Julien Cristau <jcris...@debian.org>
> 
> Any chance that can apply to 1/2 as well?
> 
Yes.  Yes you can.

Cheers,
Julien
___
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] kdrive: Nuke a bunch of dead code

[Julien Cristau]

On Fri, Apr 29, 2016 at 10:53:22 -0400, Adam Jackson wrote:

> gcc6 says:
> 
> keyboard.c:46:21: warning: ‘linux_to_x’ defined but not used
> 
> Only referenced by a bunch of long if-0'd code, so chuck it all out.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  hw/kdrive/linux/keyboard.c | 441 
> -
>  1 file changed, 441 deletions(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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] prime: clean up slave bo properly. (v2)

[Julien Cristau]

On Fri, Apr 29, 2016 at 15:54:28 +1000, Dave Airlie wrote:

> This is an ABI break, in that we now pass NULL to a function
> that hasn't accepted it before.
> 
> Alex Goins had a different patch for this but it wasn't symmetrical,
> it freed something in a very different place than it allocated it,
> this attempts to retain symmetry in the releasing of the backing bo.
> 
> v2: use a new toplevel API, though it still passes NULL to something
> that wasn't expecting it.
> 
> Signed-off-by: Dave Airlie 

AIUI you're assuming the handle will never be 0, even though that's a
valid fd.  Are we somehow sure that'll never happen?

Cheers,
Julien
___
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] XDMCP: For IPv6 add IPv6 link local addresses to the end of the list

[Julien Cristau]

On Thu, Apr 28, 2016 at 15:21:15 +0200, Stefan Dirsch wrote:

> From: Reinhard Max 
> 
> For IPv6 add a link local addresses to the end of the list passed to
> the XDMCP servers.
> Reason: for link local addresses the XDMCP server would need to either
> know the interface thru a scope identifier or try all available interfaces.
> If they don't this address will fail in which case the XDMCP server
> could still try the other addresses passed - however some only try
> the first address and then give up.
> Even if this seems to be the wrong place to fix this it seems to be
> easier than fixing all display servers.

Commit message says "add to the end of the list", code says "ignore",
which is it?

Cheers,
Julien

> ---
>  os/access.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/os/access.c b/os/access.c
> index 58f95a9..f44d93e 100644
> --- a/os/access.c
> +++ b/os/access.c
> @@ -827,7 +827,9 @@ DefineSelf(int fd)
>  
>  /*
>   * ignore 'localhost' entries as they're not useful
> - * on the other end of the wire
> + * on the other end of the wire and because on hosts
> + * with shared home dirs they'll result in conflicting
> + * entries in ~/.Xauthority
>   */
>  if (ifr->ifa_flags & IFF_LOOPBACK)
>  continue;
> @@ -848,6 +850,14 @@ DefineSelf(int fd)
>  else if (family == FamilyInternet6 &&
>   IN6_IS_ADDR_LOOPBACK((struct in6_addr *) addr))
>  continue;
> +
> +  /* Ignore IPv6 link local addresses (fe80::/10), because
> +   * they need a scope identifier, which we have no way
> +   * of telling to the other end.
> +   */
> +  if (family == FamilyInternet6 &&
> + IN6_IS_ADDR_LINKLOCAL((struct in6_addr *)addr))
> + continue;
>  #endif
>  XdmcpRegisterConnection(family, (char *) addr, len);
>  #if defined(IPv6) && defined(AF_INET6)
> -- 
> 2.6.2
> 
> ___
> 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
___
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] ad hoc fix for mmap's truncated offset parameter on 32bit

[Julien Cristau]

On Thu, Apr 28, 2016 at 16:10:01 +0200, Mark Kettenis wrote:

> > From: Stefan Dirsch 
> > Date: Thu, 28 Apr 2016 14:35:00 +0200
> > 
> > Builtin modesetting driver didn't work on 32bit on cirrus KMS. See
> > https://bugzilla.suse.com/show_bug.cgi?id=917385 for more details.
> 
> I think selectively compiling with -D_FILE_OFFSET_BITS=64 is a
> seriously bad idea.  Either evrything should be compiled with that
> switch, or nothing.  And adding a #define like that after including
> some other header files is even worse.
> 
I think the right fix for the referenced bug was
https://cgit.freedesktop.org/xorg/xserver/commit/?id=4962c8c08842d9d3ca66d254b1ce4cacc4fb3756
so this patch should not be necessary anyway.

Cheers,
Julien

> > Signed-off-by: Stefan Dirsch 
> > ---
> >  hw/xfree86/drivers/modesetting/dumb_bo.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/hw/xfree86/drivers/modesetting/dumb_bo.c 
> > b/hw/xfree86/drivers/modesetting/dumb_bo.c
> > index cf13f0a..42abe8b 100644
> > --- a/hw/xfree86/drivers/modesetting/dumb_bo.c
> > +++ b/hw/xfree86/drivers/modesetting/dumb_bo.c
> > @@ -29,6 +29,12 @@
> >  #include "dix-config.h"
> >  #endif
> >  
> > +/*
> > + * ad hoc fix for mmap's truncated offset parameter on 32bit
> > + * see also https://bugzilla.suse.com/show_bug.cgi?id=917385
> > + */
> > +#define _FILE_OFFSET_BITS 64
> > +
> >  #include "dumb_bo.h"
> >  
> >  #include 
> > -- 
> > 2.6.2
> > 
> > ___
> > 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
> > 
> > 
> ___
> 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
___
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#822868: System with AMD A6-7400K Radeon R5 with display errors (Pepper Flash, VLC Video)

[Julien Cristau]

On Thu, Apr 28, 2016 at 16:56:07 +0200, Patrick Frank wrote:

> Package: xserver-xorg-video-radeon
> Version: 1:7.5.0-1
> Severity: normal
> 
You're not actually using that driver...

> DRM Information from dmesg:
> ---
> [0.00] AGP: No AGP bridge found
> [0.00] AGP: Checking aperture...
> [0.00] AGP: No AGP bridge found
> [0.00] AGP: Node 0: aperture [bus addr 0x-0x01ff] (32MB)
> [0.00] AGP: Your BIOS doesn't leave a aperture memory hole
> [0.00] AGP: Please enable the IOMMU option in the BIOS setup
> [0.00] AGP: This costs you 64MB of RAM
> [0.00] AGP: Mapping aperture over RAM [mem 0x9400-0x97ff]
> (65536KB)
> [0.928652] Linux agpgart interface v0.103
> [1.521077] ata1.00: supports DRM functions and may not be fully
> accessible
> [1.521895] ata1.00: supports DRM functions and may not be fully
> accessible
> [1.894511] [drm] Initialized drm 1.1.0 20060810
> [1.923576] [drm] radeon kernel modesetting enabled.
> [1.931630] [drm:radeon_pci_probe] *ERROR* radeon kernel modesetting for
> R600 or later requires firmware-linux-nonfree.
> 
... because it requires the firmware-linux-nonfree package for your
hardware.

Cheers,
Julien

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

Re: [PATCH] uxa: fix missing includes for fstat

[Julien Cristau]

On Thu, Apr 28, 2016 at 11:06:38 +0200, Stefan Dirsch wrote:

> On Wed, Apr 27, 2016 at 11:23:10PM +0100, Emil Velikov wrote:
> > P.S. For xorg-devel patches please set the correct prefix $ git config
> > --local format.subjectPrefix "PATCH foo". With foo being the
> > respective project.
> 
> Ok. Will do that. Is there a an official policy available for submitting
> patches to xorg-devel like it exists for Mesa
> (http://mesa3d.org/devinfo.html#submitting)?
> 
http://www.x.org/wiki/Development/Documentation/SubmittingPatches/

Cheers,
Julien
___
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#822225: xserver-xorg-video-radeon: White glow and flicker on edges of LVDS display on boot

[Julien Cristau]

Control: reassign -1 src:linux 4.4.6-1~bpo8+1

On Thu, Apr 28, 2016 at 12:26:04 +0900, Michel Dänzer wrote:

> On 22.04.2016 17:17, thomas wrote:
> > Package: xserver-xorg-video-radeon
> > Version: 1:7.7.0-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> >I installed the open radeon driver package instead of the closed one
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >Boot the system
> > 
> >* What was the outcome of this action?
> >Increasing white glow on the edges of the built in display, a freeze,
> >some flicker and finally the normal boot process continues
> > 
> >* What outcome did you expect instead?
> >A normal boot process without the glitches
> > 
> > I am not sure if this is the fault of the display driver,
> 
> Agreed, however...
> 
> > but since it looks like a display (or maybe backlight?) glitch, I
> > though it was best to report this under the video driver package.
> 
> ... the display driver is actually the kernel driver with KMS, so this
> report should be reassigned to the kernel package.
> 
Reassigning.

Cheers,
Julien

> 
> > I am worried that it might damage something hardware related, because
> > it really doesn't look healthy to me.
> 
> FWIW, IME it's quite unlikely that this kind of issue could result in
> hardware damage.
> 
> 
> -- 
> 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: [PATCH cirrus 1/2] Remove (almost) no-op setup functions

[Julien Cristau]

On Wed, Apr 27, 2016 at 12:25:31 -0400, Adam Jackson wrote:

> These became practical no-ops when I removed reference to the loader
> symbol lists. gcc will still emit code (and bss) for them though. No
> functional change, just doing it to prove that nothing special happens
> at submodule load.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  src/alp_driver.c | 14 +-
>  src/lg_driver.c  | 15 +--
>  2 files changed, 2 insertions(+), 27 deletions(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>
for the series.

Cheers,
Julien
___
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] Avoid 10x7 heuristic, handled by server

[Julien Cristau]

On Tue, Apr 26, 2016 at 14:09:24 +0200, Stefan Dirsch wrote:

> On Tue, Apr 26, 2016 at 12:58:55PM +0200, Julien Cristau wrote:
> > On Tue, Apr 26, 2016 at 11:45:15 +0200, Stefan Dirsch wrote:
> > 
> > > From: Frederic Crozat <fcro...@suse.com>
> > > 
> > > Remove the 10x7 heuristic, since the server has equivalent code now.
> > > Instead, disable "acceleration" under qemu, since taking the hypercall
> > > trap is really quite expensive and you're better off doing noaccel.
> > > (Fedora)
> > > ---
> > >  src/alp_driver.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > What does "the 10x7 heuristic" refer to?  Maybe
> > http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-cirrus.git/tree/cirrus-1.2.0-qemu.patch?id=b726ffdd66d6aaf49c64f999eb2c004e1d5041fb
> > which is an earlier version of this patch?
> 
> Wow! Thanks for the pointer. Honestly I never understood the comment, since
> today I've seen the original patch the first time. ;-) LOL!
> 
> > (Also, authorship seems wrong, if you took this patch from Fedora, it
> > should be attributed to ajax afaict:
> > http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-cirrus.git/log/cirrus-1.2.0-qemu.patch
> 
> Ok. Since the patch we're using is obviously no longer related to Ajax'
> original one I keep it attributed to Frederic. Unless he or you're vetoing. I
> could add "very loosely based on Ajax' patch" though.
> 
The patch you're using today seems to be pretty much the same as
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-cirrus.git/tree/cirrus-1.2.0-qemu.patch?id=daccd1c8174623500eddfa297d8ea76a86d3c5d9

Cheers,
Julien
___
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] Avoid 10x7 heuristic, handled by server

[Julien Cristau]

On Tue, Apr 26, 2016 at 11:45:15 +0200, Stefan Dirsch wrote:

> From: Frederic Crozat 
> 
> Remove the 10x7 heuristic, since the server has equivalent code now.
> Instead, disable "acceleration" under qemu, since taking the hypercall
> trap is really quite expensive and you're better off doing noaccel.
> (Fedora)
> ---
>  src/alp_driver.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
What does "the 10x7 heuristic" refer to?  Maybe
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-cirrus.git/tree/cirrus-1.2.0-qemu.patch?id=b726ffdd66d6aaf49c64f999eb2c004e1d5041fb
which is an earlier version of this patch?

(Also, authorship seems wrong, if you took this patch from Fedora, it
should be attributed to ajax afaict:
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-cirrus.git/log/cirrus-1.2.0-qemu.patch
)

Cheers,
Julien

> diff --git a/src/alp_driver.c b/src/alp_driver.c
> index bd5e52f..da31321 100644
> --- a/src/alp_driver.c
> +++ b/src/alp_driver.c
> @@ -774,6 +774,13 @@ AlpPreInit(ScrnInfoPtr pScrn, int flags)
>   else
>   xf86SetDDCproperties(pScrn,xf86PrintEDID(
>xf86DoEDID_DDC2(XF86_SCRN_ARG(pScrn),pCir->I2CPtr1)));
> +
> +#ifdef XSERVER_LIBPCIACCESS
> + if (!pScrn->monitor->DDC &&
> + ((pCir->PciInfo->subvendor_id & 0x) == 0x1af4)) {
> + pCir->NoAccel = TRUE;
> + }
> +#endif
>   
>   /* Probe the possible LCD display */
>   AlpProbeLCD(pScrn);
> -- 
> 2.6.2
> 
> ___
> 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
___
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 xproto v2] Don't let XFD_SETSIZE exceed FD_SETSIZE

[Julien Cristau]

On Mon, Apr 25, 2016 at 17:12:08 +0100, James Clarke wrote:

> This fixes 2c94cdb453bc641246cc8b9a876da9799bee1ce7 on the Hurd, as FD_SETSIZE
> is only 256, and so anyone using XFD_SETSIZE to iterate over the contents of
> an fd_set will overrun the array.
> 
> Signed-off-by: James Clarke <jrt...@jrtc27.com>
> ---
> Changes since v1:
>   * Added Signed-off-by
>   * Added xproto component to subject prefix
> 
>  Xpoll.h.in | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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] libpciaccess/vgaarb: add function to get default vga device and it's decodes.

[Julien Cristau]

On Thu, Apr 21, 2016 at 15:22:36 +0200, Stefan Dirsch wrote:

> From: Egbert Eich 
> 
> Reenable default device when shutting down VGA arbitration.
> https://bugzilla.opensuse.org/show_bug.cgi?id=714677
> ---
>  src/common_vgaarb.c | 9 +
>  1 file changed, 9 insertions(+)
> 
I don't understand how the patch description relates to the patch.  This
doesn't seem to add a function...

Cheers,
Julien

> diff --git a/src/common_vgaarb.c b/src/common_vgaarb.c
> index 7a7d204..2c0686e 100644
> --- a/src/common_vgaarb.c
> +++ b/src/common_vgaarb.c
> @@ -156,6 +156,11 @@ pci_device_vgaarb_fini(void)
>  {
>  if (!pci_sys)
>  return;
> +if (pci_device_vgaarb_set_target(NULL) < 0 ||
> + pci_device_vgaarb_lock() < 0 ||
> + pci_device_vgaarb_unlock() < 0) {
> + fprintf(stderr, "VGA Arbitration: Cannot restore default device.\n");
> +}
>  
>  close(pci_sys->vgaarb_fd);
>  }
> @@ -334,6 +339,10 @@ pci_device_vgaarb_unlock(void)
>  int pci_device_vgaarb_get_info(struct pci_device *dev, int *vga_count, int 
> *rsrc_decodes)
>  {
>  *vga_count = pci_sys->vga_count;
> +if (!rsrc_decodes)
> +return 0;
> +if (!dev)
> +dev = pci_sys->vga_default_dev;
>  if (!dev)
>  return 0;
>  
> -- 
> 2.6.2
> 
> ___
> 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
___
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] Search for DRI drivers at LIBGL_DRIVERS_PATH environment variable.

[Julien Cristau]

On Tue, Apr 12, 2016 at 19:59:14 +0200, Carlos Alberto Lopez Perez wrote:

>   * The Mesa driver uses this environment variable to override the
> default compiled search path for DRI drivers.
> 
>   * This is useful for testing purposes when the user needs to
> override the system default one at runtime.
> 
> Signed-off-by: Carlos Alberto Lopez Perez 
> ---
>  glx/glxdricommon.c | 40 ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
> 
NAK.  The server doesn't trust the environment today, and there are
still cases where we are setuid, so I don't think we should go down this
road.  Or if we do, at least make it if (geteuid() != 0).

Not to mention repurposing somebody else's env var feels wrong...

Cheers,
Julien
___
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/4] glx: Macroize building the attribute list in DoGetDrawableAttributes

[Julien Cristau]

On Thu, Mar 10, 2016 at 13:25:03 -0500, Adam Jackson wrote:

> No functional change, just a little easier to read and harder to get
> wrong.
> 
> Signed-off-by: Adam Jackson 
> ---
>  glx/glxcmds.c | 38 +++---
>  1 file changed, 15 insertions(+), 23 deletions(-)
> 
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index 6eb3541..65d0739 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -1945,31 +1945,23 @@ DoGetDrawableAttributes(__GLXclientState * cl, XID 
> drawId)
>  if (pGlxDraw)
>  pDraw = pGlxDraw->pDraw;
>  
> -attributes[2*num] = GLX_Y_INVERTED_EXT;
> -attributes[2*num+1] = GL_FALSE;
> -num++;
> -attributes[2*num] = GLX_WIDTH;
> -attributes[2*num+1] = pDraw->width;
> -num++;
> -attributes[2*num] = GLX_HEIGHT;
> -attributes[2*num+1] = pDraw->height;
> -num++;
> +#define ATTRIB(a, v) { \
> +attributes[2*num] = (a); \
> +attributes[2*num+1] = (v); \
> +num++; \
> +}
> +
> +ATTRIB(GLX_Y_INVERTED_EXT, GL_FALSE);
> +ATTRIB(GLX_WIDTH, pDraw->width);
> +ATTRIB(GLX_HEIGHT, pDraw->height);
>  if (pGlxDraw) {
> -attributes[2*num] = GLX_TEXTURE_TARGET_EXT;
> -attributes[2*num+1] = pGlxDraw->target == GL_TEXTURE_2D ?
> -GLX_TEXTURE_2D_EXT :
> -GLX_TEXTURE_RECTANGLE_EXT;
> -num++;
> -attributes[2*num] = GLX_EVENT_MASK;
> -attributes[2*num+1] = pGlxDraw->eventMask;
> -num++;
> -attributes[2*num] = GLX_FBCONFIG_ID;
> -attributes[2*num+1] = pGlxDraw->config->fbconfigID;
> -num++;
> +ATTRIB(GLX_TEXTURE_TARGET_EXT,
> +   pGlxDraw->target == GL_TEXTURE_2D ?
> +GLX_TEXTURE_2D_EXT : GLX_TEXTURE_RECTANGLE_EXT);
> +ATTRIB(GLX_EVENT_MASK, pGlxDraw->eventMask);
> +ATTRIB(GLX_FBCONFIG_ID, pGlxDraw->config->fbconfigID);
>  if (pGlxDraw->type == GLX_DRAWABLE_PBUFFER) {
> -attributes[2*num] = GLX_PRESERVED_CONTENTS;
> -attributes[2*num+1] = GL_TRUE;
> -num++;
> +ATTRIB(GLX_PRESERVED_CONTENTS, GL_TRUE);
>  }
>  }
>  
maybe #undef ATTRIB when you're done?

Cheers,
Julien
___
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] xwayland: Correctly detect whether posix_fallocate exists

[Julien Cristau]

On Tue, Mar  8, 2016 at 20:05:33 +0800, Jonas Ådahl wrote:

> We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever
> defined anywhere. This commit makes it so that this macro is defined if
> the posix_fallocate is detected during configure.
> 
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  configure.ac   | 3 ++-
>  hw/xwayland/xwayland-shm.c | 4 
>  include/dix-config.h.in| 3 +++
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien
___
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] xwayland: Correctly detect whether posix_fallocate exists

[Julien Cristau]

On Tue, Mar  8, 2016 at 18:32:27 +0800, Jonas Ådahl wrote:

> On Tue, Feb 23, 2016 at 08:54:47AM +0800, Jonas Ådahl wrote:
> > On Fri, Feb 19, 2016 at 11:53:46AM +0100, Julien Cristau wrote:
> > > On Fri, Feb 19, 2016 at 15:08:13 +0800, Jonas Ådahl wrote:
> > > 
> > > > We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever
> > > > defined anywhere. This commit makes it so that this macro is defined if
> > > > the posix_fallocate is detected during configure.
> > > > 
> > > > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > > 
> > > Hi,
> > > 
> > > any reason not to do the check unconditionally and put the define in
> > > dix-config.h?
> > 
> > The only reason is that the function checked is only used by the
> > xwayland ddx. It could just as well be added to dix-config.h if that is
> > preferred.
> 
> So any opinions regarding this? Should the macro be moved ddx/ or not?
> 
I still think putting it in dix-config is simpler and I can't think of
any downsides.

Cheers,
Julien
___
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/9] xvmc: Fix unchecked AddResource

[Julien Cristau]

On Tue, Mar  8, 2016 at 09:12:34 +0100, walter harms wrote:

> 
> 
> Am 07.03.2016 23:20, schrieb Julien Cristau:
> > Signed-off-by: Julien Cristau <jcris...@debian.org>
> > ---
> >  Xext/xvmc.c | 17 ++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Xext/xvmc.c b/Xext/xvmc.c
> > index 64eda92..7565c17 100644
> > --- a/Xext/xvmc.c
> > +++ b/Xext/xvmc.c
> > @@ -253,6 +253,10 @@ ProcXvMCCreateContext(ClientPtr client)
> >  free(pContext);
> >  return result;
> >  }
> > +if (!AddResource(pContext->context_id, XvMCRTContext, pContext)) {
> > +free(data);
> > +return BadAlloc;
> > +}
> >  
> >  rep = (xvmcCreateContextReply) {
> >  .type = X_Reply,
> > @@ -266,7 +270,6 @@ ProcXvMCCreateContext(ClientPtr client)
> >  WriteToClient(client, sizeof(xvmcCreateContextReply), );
> >  if (dwords)
> >  WriteToClient(client, dwords << 2, data);
> > -AddResource(pContext->context_id, XvMCRTContext, pContext);
> >  
> >  free(data);
> >  
> > @@ -329,6 +332,11 @@ ProcXvMCCreateSurface(ClientPtr client)
> >  free(pSurface);
> >  return result;
> >  }
> > +if (!AddResource(pSurface->surface_id, XvMCRTSurface, pSurface)) {
> > +free(data);
> > +return BadAlloc;
> > +}
> > +
> 
> 
> I do not see the whole picture but the free a few lines before indicate that
> the error path may need to free other previously allocated resources.
> 
If AddResource fails it'll have freed pSurface already.

Cheers,
Julien
___
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 3/9] glx: don't call pGlxDraw->destroy() if AddResource fails

[Julien Cristau]

AddResource will have called DrawableGone, which takes care of the
destruction.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 glx/glxcmds.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 0416dac..6eb3541 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -544,7 +544,6 @@ __glXGetDrawable(__GLXcontext * glxc, GLXDrawable drawId, 
ClientPtr client,
 
 /* since we are creating the drawablePrivate, drawId should be new */
 if (!AddResource(drawId, __glXDrawableRes, pGlxDraw)) {
-pGlxDraw->destroy(pGlxDraw);
 *error = BadAlloc;
 return NULL;
 }
@@ -1239,20 +1238,16 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen * 
pGlxScreen,
 if (pGlxDraw == NULL)
 return BadAlloc;
 
-if (!AddResource(glxDrawableId, __glXDrawableRes, pGlxDraw)) {
-pGlxDraw->destroy(pGlxDraw);
+if (!AddResource(glxDrawableId, __glXDrawableRes, pGlxDraw))
 return BadAlloc;
-}
 
 /*
  * Windows aren't refcounted, so track both the X and the GLX window
  * so we get called regardless of destruction order.
  */
 if (drawableId != glxDrawableId && type == GLX_DRAWABLE_WINDOW &&
-!AddResource(pDraw->id, __glXDrawableRes, pGlxDraw)) {
-pGlxDraw->destroy(pGlxDraw);
+!AddResource(pDraw->id, __glXDrawableRes, pGlxDraw))
 return BadAlloc;
-}
 
 return Success;
 }
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 0/9] double frees in AddResource failure paths

[Julien Cristau]

Hi,

prompted by Adam's recent fixes for unchecked AddResource, I've been
looking at the failure paths, and found a number of places where it
looks like we're freeing things twice (once as part of AddResource
itself calling the destroy function for the resource, and once in the
caller).  Plus more unchecked AddResource calls in xvmc and dri3.

Cheers,
Julien

Julien Cristau (9):
  xvmc: Fix unchecked AddResource
  dri3: return an error if AddResource fails
  glx: don't call pGlxDraw->destroy() if AddResource fails
  dmx/glxProxy: don't free the glx pixmap twice if AddResource fails
  modesetting: avoid double free if AddResource fails
  xwin: no need to free auth data if AddResource fails
  record: don't call RecordDeleteContext when AddResource fails
  render: free already allocated formats in PictureInit failure case
  xfixes: avoid double free if AddResource fails

 Xext/xvmc.c   | 17 ++---
 dri3/dri3_request.c   |  4 ++--
 glx/glxcmds.c |  9 ++---
 hw/dmx/glxProxy/glxcmds.c |  5 +
 hw/xfree86/drivers/modesetting/dri2.c |  4 +---
 hw/xwin/winauth.c | 17 +++--
 record/record.c   |  1 -
 render/picture.c  |  3 +++
 xfixes/cursor.c   |  4 +---
 9 files changed, 27 insertions(+), 37 deletions(-)

-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 6/9] xwin: no need to free auth data if AddResource fails

[Julien Cristau]

This is taken care of by SecurityDeleteAuthorization

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 hw/xwin/winauth.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/hw/xwin/winauth.c b/hw/xwin/winauth.c
index 7efa1c0..7be7dca 100644
--- a/hw/xwin/winauth.c
+++ b/hw/xwin/winauth.c
@@ -114,7 +114,6 @@ GenerateAuthorization(unsigned name_length,
 Bool
 winGenerateAuthorization(void)
 {
-Bool fFreeAuth = FALSE;
 SecurityAuthorizationPtr pAuth = NULL;
 
 /* Call OS layer to generate authorization key */
@@ -123,7 +122,7 @@ winGenerateAuthorization(void)
  0, NULL, _uiAuthDataLen, _pAuthData);
 if ((XID) ~0L == g_authId) {
 ErrorF("winGenerateAuthorization - GenerateAuthorization failed\n");
-goto auth_bailout;
+return FALSE;
 }
 
 else {
@@ -139,7 +138,7 @@ winGenerateAuthorization(void)
 if (!(pAuth)) {
 ErrorF("winGenerateAuthorization - Failed allocating "
"SecurityAuthorizationPtr.\n");
-goto auth_bailout;
+return FALSE;
 }
 
 /* Fill in the auth fields */
@@ -155,21 +154,11 @@ winGenerateAuthorization(void)
 /* Add the authorization to the server's auth list */
 if (!AddResource(g_authId, SecurityAuthorizationResType, pAuth)) {
 ErrorF("winGenerateAuthorization - AddResource failed for auth.\n");
-fFreeAuth = TRUE;
-goto auth_bailout;
+return FALSE;
 }
-
-/* Don't free the auth data, since it is still used internally */
-pAuth = NULL;
 #endif
 
 return TRUE;
-
- auth_bailout:
-if (fFreeAuth)
-free(pAuth);
-
-return FALSE;
 }
 
 /* Use our generated cookie for authentication */
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 4/9] dmx/glxProxy: don't free the glx pixmap twice if AddResource fails

[Julien Cristau]

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 hw/dmx/glxProxy/glxcmds.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glxProxy/glxcmds.c
index ddcb981..a77d556 100644
--- a/hw/dmx/glxProxy/glxcmds.c
+++ b/hw/dmx/glxProxy/glxcmds.c
@@ -2010,11 +2010,8 @@ CreateGLXPixmap(__GLXclientState * cl,
 XFlush(dpy);
 }
 
-if (!(AddResource(glxpixmapId, __glXPixmapRes, pGlxPixmap))) {
-free(pGlxPixmap->be_xids);
-free(pGlxPixmap);
+if (!(AddResource(glxpixmapId, __glXPixmapRes, pGlxPixmap)))
 return BadAlloc;
-}
 
 return Success;
 }
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 2/9] dri3: return an error if AddResource fails

[Julien Cristau]

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 dri3/dri3_request.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index 2b36221..35548b6 100644
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -178,8 +178,8 @@ proc_dri3_pixmap_from_buffer(ClientPtr client)
 (*drawable->pScreen->DestroyPixmap) (pixmap);
 return rc;
 }
-if (AddResource(stuff->pixmap, RT_PIXMAP, (void *) pixmap))
-return Success;
+if (!AddResource(stuff->pixmap, RT_PIXMAP, (void *) pixmap))
+return BadAlloc;
 
 return Success;
 }
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 7/9] record: don't call RecordDeleteContext when AddResource fails

[Julien Cristau]

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 record/record.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/record/record.c b/record/record.c
index 1caf3f1..82bb060 100644
--- a/record/record.c
+++ b/record/record.c
@@ -1878,7 +1878,6 @@ ProcRecordCreateContext(ClientPtr client)
 return Success;
 }
 else {
-RecordDeleteContext((void *) pContext, pContext->id);
 return BadAlloc;
 }
  bailout:
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 8/9] render: free already allocated formats in PictureInit failure case

[Julien Cristau]

Probably pointless, if this fails you're not likely to get far...

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 render/picture.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/render/picture.c b/render/picture.c
index 6d9c9df..9e4036e 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -665,6 +665,9 @@ PictureInit(ScreenPtr pScreen, PictFormatPtr formats, int 
nformats)
 for (n = 0; n < nformats; n++) {
 if (!AddResource
 (formats[n].id, PictFormatType, (void *) (formats + n))) {
+int i;
+for (i = 0; i < n; i++)
+FreeResource(formats[i].id, RT_NONE);
 free(formats);
 return FALSE;
 }
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 9/9] xfixes: avoid double free if AddResource fails

[Julien Cristau]

pChc is already freed through CursorFreeHideCount →
deleteCursorHideCount.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 xfixes/cursor.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 5619aad..10f9b23 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -774,10 +774,8 @@ createCursorHideCount(ClientPtr pClient, ScreenPtr pScreen)
  * Create a resource for this element so it can be deleted
  * when the client goes away.
  */
-if (!AddResource(pChc->resource, CursorHideCountType, (void *) pChc)) {
-free(pChc);
+if (!AddResource(pChc->resource, CursorHideCountType, (void *) pChc))
 return BadAlloc;
-}
 
 return Success;
 }
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 1/9] xvmc: Fix unchecked AddResource

[Julien Cristau]

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 Xext/xvmc.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/Xext/xvmc.c b/Xext/xvmc.c
index 64eda92..7565c17 100644
--- a/Xext/xvmc.c
+++ b/Xext/xvmc.c
@@ -253,6 +253,10 @@ ProcXvMCCreateContext(ClientPtr client)
 free(pContext);
 return result;
 }
+if (!AddResource(pContext->context_id, XvMCRTContext, pContext)) {
+free(data);
+return BadAlloc;
+}
 
 rep = (xvmcCreateContextReply) {
 .type = X_Reply,
@@ -266,7 +270,6 @@ ProcXvMCCreateContext(ClientPtr client)
 WriteToClient(client, sizeof(xvmcCreateContextReply), );
 if (dwords)
 WriteToClient(client, dwords << 2, data);
-AddResource(pContext->context_id, XvMCRTContext, pContext);
 
 free(data);
 
@@ -329,6 +332,11 @@ ProcXvMCCreateSurface(ClientPtr client)
 free(pSurface);
 return result;
 }
+if (!AddResource(pSurface->surface_id, XvMCRTSurface, pSurface)) {
+free(data);
+return BadAlloc;
+}
+
 rep = (xvmcCreateSurfaceReply) {
 .type = X_Reply,
 .sequenceNumber = client->sequence,
@@ -338,7 +346,6 @@ ProcXvMCCreateSurface(ClientPtr client)
 WriteToClient(client, sizeof(xvmcCreateSurfaceReply), );
 if (dwords)
 WriteToClient(client, dwords << 2, data);
-AddResource(pSurface->surface_id, XvMCRTSurface, pSurface);
 
 free(data);
 
@@ -445,6 +452,11 @@ ProcXvMCCreateSubpicture(ClientPtr client)
 free(pSubpicture);
 return result;
 }
+if (!AddResource(pSubpicture->subpicture_id, XvMCRTSubpicture, 
pSubpicture)) {
+free(data);
+return BadAlloc;
+}
+
 rep = (xvmcCreateSubpictureReply) {
 .type = X_Reply,
 .sequenceNumber = client->sequence,
@@ -462,7 +474,6 @@ ProcXvMCCreateSubpicture(ClientPtr client)
 WriteToClient(client, sizeof(xvmcCreateSubpictureReply), );
 if (dwords)
 WriteToClient(client, dwords << 2, data);
-AddResource(pSubpicture->subpicture_id, XvMCRTSubpicture, pSubpicture);
 
 free(data);
 
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 5/9] modesetting: avoid double free if AddResource fails

[Julien Cristau]

ms_dri2_frame_event_client_gone or ms_dri2_frame_event_drawable_gone
already free the resource.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 hw/xfree86/drivers/modesetting/dri2.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/dri2.c 
b/hw/xfree86/drivers/modesetting/dri2.c
index 0fe420c..83cb3e0 100644
--- a/hw/xfree86/drivers/modesetting/dri2.c
+++ b/hw/xfree86/drivers/modesetting/dri2.c
@@ -97,10 +97,8 @@ ms_get_resource(XID id, RESTYPE type)
 if (resource == NULL)
 return NULL;
 
-if (!AddResource(id, type, resource)) {
-free(resource);
+if (!AddResource(id, type, resource))
 return NULL;
-}
 
 resource->id = id;
 resource->type = type;
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] xv: fix double free in AddResource failure case

[Julien Cristau]

XvdiDestroyVideoNotifyList already frees the list if AddResource fails,
so don't do it twice.  And set tpn->client to NULL explicitly to avoid
confusing uninitialized memory with a valid value.

Signed-off-by: Julien Cristau <jcris...@debian.org>
---
 Xext/xvmain.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Xext/xvmain.c b/Xext/xvmain.c
index 0c6f25b..de6cc7a 100644
--- a/Xext/xvmain.c
+++ b/Xext/xvmain.c
@@ -800,10 +800,9 @@ XvdiSelectVideoNotify(ClientPtr client, DrawablePtr pDraw, 
BOOL onoff)
 if (!(tpn = malloc(sizeof(XvVideoNotifyRec
 return BadAlloc;
 tpn->next = NULL;
-if (!AddResource(pDraw->id, XvRTVideoNotifyList, tpn)) {
-free(tpn);
+tpn->client = NULL;
+if (!AddResource(pDraw->id, XvRTVideoNotifyList, tpn))
 return BadAlloc;
-}
 }
 else {
 /* LOOK TO SEE IF ENTRY ALREADY EXISTS */
-- 
2.7.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/5] dri1: Fix unchecked AddResource

[Julien Cristau]

On Tue, Mar  1, 2016 at 14:09:30 -0500, Adam Jackson wrote:

> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  hw/xfree86/dri/dri.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
Kind of silly that those result in BadValue instead of BadAlloc, but
meh, dri1.

for the series (1/5 and 2/5):
Reviewed-by: Julien Cristau <jcris...@debian.org>

Cheers,
Julien

> diff --git a/hw/xfree86/dri/dri.c b/hw/xfree86/dri/dri.c
> index 875c9cc..0046e52 100644
> --- a/hw/xfree86/dri/dri.c
> +++ b/hw/xfree86/dri/dri.c
> @@ -1032,7 +1032,8 @@ DRICreateContext(ScreenPtr pScreen, VisualPtr visual,
>  }
>  
>  /* track this in case the client dies before cleanup */
> -AddResource(context, DRIContextPrivResType, (void *) pDRIContextPriv);
> +if (!AddResource(context, DRIContextPrivResType, (void *) 
> pDRIContextPriv))
> +return FALSE;
>  
>  return TRUE;
>  }
> @@ -1263,8 +1264,9 @@ DRICreateDrawable(ScreenPtr pScreen, ClientPtr client, 
> DrawablePtr pDrawable,
>  }
>  
>  /* track this in case the client dies */
> -AddResource(FakeClientID(client->index), DRIDrawablePrivResType,
> -(void *) (intptr_t) pDrawable->id);
> +if (!AddResource(FakeClientID(client->index), DRIDrawablePrivResType,
> + (void *) (intptr_t) pDrawable->id))
> +return FALSE;
>  
>  if (pDRIDrawablePriv->hwDrawable) {
>  drmUpdateDrawableInfo(pDRIPriv->drmFD,
> -- 
> 2.5.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
___
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] xwayland: Correctly detect whether posix_fallocate exists

[Julien Cristau]

On Fri, Feb 19, 2016 at 15:08:13 +0800, Jonas Ådahl wrote:

> We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever
> defined anywhere. This commit makes it so that this macro is defined if
> the posix_fallocate is detected during configure.
> 
> Signed-off-by: Jonas Ådahl 

Hi,

any reason not to do the check unconditionally and put the define in
dix-config.h?

Cheers,
Julien
___
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 kdrive/ephyr v7 5/9] kdrive: add options to set default XKB properties

[Julien Cristau]

On Tue, Feb  9, 2016 at 14:23:59 +1000, Peter Hutterer wrote:

> On Mon, Feb 08, 2016 at 10:00:21PM -0200, Laércio de Sousa wrote:
> > Em 8 de fev de 2016 17:54, "Adam Jackson"  escreveu:
> > > How are you in a scenario where you can pass these values to Xephyr on
> > > the command line, but can't modify the udev properties?
> > Well... What I really mean is a scenario where neither the Linux distro,
> > nor the keyboard vendor, nor the sysadmin him(her)self provides any udev
> > rules to set XKB properties.
> > 
> > For example, I know there are some distros that ship a set of default udev
> > rules to set XKB properties, but not all of them do it (at least the one I
> > used when I wrote this patch didn't).
> 
> when we introduced the udev config backend we mostly agreed that we weren't
> going to use udev as a config storage (which is how InputClass was
> conceived). Debian ships them because there was some release timing conflict
> where the udev patches where ready but the InputClass bits weren't but aside
> from Debian I don't expect any distro to set the xkb config via udev.
> 
At this point it's not so much a timing conflict as the fact that we use
/etc/default/keyboard to configure the layout for console and X, and
getting information from there into the udev db seems easier/saner than
generating an xorg.conf snippet in /run whenever the actual config
source changes (or whenever X starts, or on boot, or...).  Unless I'm
missing some other way to get that info in the right place?

Cheers,
Julien
___
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 macros v2] Fix XORG_WITH_XMLTO to work with xmlto >= 0.0.27

[Julien Cristau]

On Wed, Jan 13, 2016 at 19:51:55 -0500, Gaetan Nadon wrote:

> On 16-01-12 07:59 AM, Andreas Boll wrote:
> > Starting with xmlto version 0.0.27 the return code of
> >   xmlto --skip-validation txt conftest.xml
> > is non-zero if conftest.xml is an empty file.
> >
[...]
> >
> >  xorg-macros.m4.in | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> 
> Reviewed-by: Gaetan Nadon 
> 
remote: Updating patchwork state for 
http://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #70283 updated using rev 
d7acec2d3a3abe79814ceb72e2c0d4d95ed31d37.
remote: I: 1 patch(es) updated to state Accepted.
To git.freedesktop.org:/git/xorg/util/macros
   8b92f46..d7acec2  master -> master

Thanks for the patch and review.

Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11-xcb] add XCBGetXDisplay

[Julien Cristau]

On Fri, Jan  1, 2016 at 11:39:32 -0800, Alan Coopersmith wrote:

> Did we ever reach a conclusion on this patch?  I was thinking of doing a
> libX11 release sometime early this year, and if this is ready to include,
> would pull it in.
> 
> (Is http://patchwork.freedesktop.org/patch/50613/ the latest version or is
>  there a newer one?  I've lost track in my mail folders.)
> 
FWIW I would agree with Uli that having a new copy of hundreds of lines
from XOpenDisplay instead of sharing common code seems like a bad
idea...

Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

[Julien Cristau]

On Thu, Dec 10, 2015 at 11:42:36 -0800, Keith Packard wrote:

> Mark Kettenis  writes:
> 
> > Ugh.  Exporting global variables as part of the ABI is generally not
> > such a good idea.  Perhaps it is better to use functions to acquire
> > and release the input mutex instead?
> 
> Yeah, the mutex isn't exactly performance critical.
> 
> > Also, using TLS (i.e. __thread variables) isn't portable.  That
> > mechanism certainly isn't supported by all platforms supported by
> > Xorg.
> 
> Ok, I've added support for pthread_setspecific/pthread_getspecific and
> made sure that works; I cannot test the autoconf bits (other than
> verifying that if I misspell '__thread' as '__tread' it fails as
> expected).
> 
You could maybe use
http://www.gnu.org/software/autoconf-archive/ax_tls.html for the
autoconf bits?

Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2] xwayland: Do set root clip with rootless

[Julien Cristau]

On Sat, Nov 21, 2015 at 14:43:47 +0100, Olivier Fourdan wrote:

> diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
> index ebaf05a..16d1ab9 100644
> --- a/hw/xwayland/xwayland-glamor.c
> +++ b/hw/xwayland/xwayland-glamor.c
> @@ -233,9 +233,11 @@ xwl_glamor_create_screen_resources(ScreenPtr screen)
>  if (!ret)
>  return ret;
>  
> -if (xwl_screen->rootless)
> +if (xwl_screen->rootless) {
>  screen->devPrivate =
>  fbCreatePixmap(screen, 0, 0, screen->rootDepth, 0);
> +SetRootClip(screen, FALSE);

indentation looks wrong here here...

> +}
>  else {
>  screen->devPrivate =
>  xwl_glamor_create_pixmap(screen, screen->width, screen->height,
[...]
> diff --git a/hw/xwayland/xwayland-shm.c b/hw/xwayland/xwayland-shm.c
> index 1022c0d..3c42456 100644
> --- a/hw/xwayland/xwayland-shm.c
> +++ b/hw/xwayland/xwayland-shm.c
> @@ -279,9 +279,11 @@ xwl_shm_create_screen_resources(ScreenPtr screen)
>  if (!ret)
>  return ret;
>  
> -if (xwl_screen->rootless)
> +if (xwl_screen->rootless) {
>  screen->devPrivate =
>  fbCreatePixmap(screen, 0, 0, screen->rootDepth, 0);
> +SetRootClip(screen, FALSE);

and here.

Cheers,
Julien

> +}
>  else
>  screen->devPrivate =
>  xwl_shm_create_pixmap(screen, screen->width, screen->height,
> -- 
> 2.5.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel