Re: [PATCH xf86-video-dummy] Add glamor acceleration which enables native OpenGL support
On Wed, 2017-03-08 at 01:03 +, Yu, Qiang wrote: > > Now this is cool. Any chance I can get you to do the same for Xvfb? > > Thanks. I can give a try latter next month, seems glamor and egl need to > support > more depth for this. No they don't. I mean, it'd be awesome if glamor worked well at depth 16 too, but depth 24 only is entirely sufficient. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app/xkbcomp] Add xkboutputdir to xkbcomp.pc
On Tue, Mar 07, 2017 at 09:31:54PM +, Emil Velikov wrote:
> HI Adam,
>
> On 7 March 2017 at 17:42, Adam Jackson wrote:
> > The X server (and everybody else, really) wants to know where to put
> > xkbcomp's output, so xkbcomp.pc should say. This should be under
> > localstatedir, since the output is architecture-dependent (as the note
> > in xserver/xkb/README.compiled suggests).
> >
> > Signed-off-by: Adam Jackson
> > ---
> > configure.ac| 9 +
> > m4/ac_define_dir.m4 | 52
> >
> > xkbcomp.pc.in | 1 +
> > xkbpath.c | 4 +---
> > 4 files changed, 63 insertions(+), 3 deletions(-)
> > create mode 100644 m4/ac_define_dir.m4
> >
> > diff --git a/configure.ac b/configure.ac
> > index 0c8063e..3c151f3 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -26,6 +26,7 @@ AC_INIT([xkbcomp], [1.3.1],
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
> > [xkbcomp])
> > AC_CONFIG_SRCDIR([Makefile.am])
> > AC_CONFIG_HEADERS([config.h])
> > +AC_CONFIG_MACRO_DIR([m4])
> >
> > # Initialize Automake
> > AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > @@ -59,7 +60,15 @@ AC_ARG_WITH([xkb_config_root],
> > [XKBCONFIGROOT="$withval"],
> > [XKBCONFIGROOT='${datadir}/X11/xkb'])
> > AC_SUBST([XKBCONFIGROOT])
> > +AC_DEFINE_DIR(DFLT_XKB_CONFIG_ROOT, XKBCONFIGROOT, [XKB config root])
> >
> Not 100% sure but I think the current -DDFLT_XKB_CONFIG_ROOT... should
> be sufficient. Alternatively can you point out what's the current vs
> expected result ?
>
> > +AC_ARG_WITH([xkb_output_path],
> > +[AS_HELP_STRING([--with-xkb-output-path=],
> > +[Set default XKB output path (default: ${localstatedir}/xkb)])],
> > +[XKBOUTPUTPATH="$withval"],
> > +[XKBOUTPUTPATH='${localstatedir}/xkb'])
> > +AC_SUBST([XKBOUTPUTPATH])
> > +AC_DEFINE_DIR(DFLT_XKB_OUTPUT_PATH, XKBOUTPUTPATH, [XKB output path])
> >
> Slightly silly question: are these really the output path of xkbcomp ?
> Afaict the tool outputs to any user specified location.
> On my system the path /usr/share/X11/xkb is provided by
> xkeyboard-config. The latter of which providing having xkb_base
> variable in its .pc file for such purposes.
sort-of. the server defaults to ${datadir}/X11/xkb/compiled but on fedora we
use --with-xkb-output=%{_localstatedir}/lib/xkb which I guess is where ajax'
motivation comes from (and it makes more sense anyway). But for the repos to
update this reliably we need it in the pc file, etc. which is what the rest
of the patch does.
>
> > --- a/xkbcomp.pc.in
> > +++ b/xkbcomp.pc.in
> > @@ -2,6 +2,7 @@ prefix=@prefix@
> > datarootdir=@datarootdir@
> > datadir=@datadir@
> > xkbconfigdir=@XKBCONFIGROOT@
> > +xkboutputdir=@XKBOUTPUTPATH@
> >
> > Name: xkbcomp
> > Description: XKB keymap compiler
> > diff --git a/xkbpath.c b/xkbpath.c
> > index 6f18b86..3345ba9 100644
> > --- a/xkbpath.c
> > +++ b/xkbpath.c
> > @@ -33,9 +33,7 @@
> > #include
> > #include "xkbpath.h"
> >
> > -#ifndef DFLT_XKB_CONFIG_ROOT
> > -#define DFLT_XKB_CONFIG_ROOT "/usr/lib/X11/xkb"
> Regardless if the current define is sufficient, we might want to
> change this to something like below ?
>
> #ifndef DFLT_XKB_CONFIG_ROOT
> #error "DFLT_XKB_CONFIG_ROOT is not defined"
> #endif
can't we just drop it? there's no realistic path in configure that ends up
in DFLT_XKB_CONFIG_ROOT. And we should drop it from the Makefile.am as well.
Cheers,
Peter
>
> > -#endif
> > +#include "config.h"
> >
> Hmm config.h management/amongst others looks very wrong on this
> package. I'll give it some love (patches) after dinner.
>
> -Emil
> ___
> 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] Remove *Clip funcs from GCFuncs
On 08/03/17 11:37 AM, Keith Packard wrote: > Michel Dänzer writes: > >> This change will cause some drivers (at least -ati, -amdgpu and -intel) >> to fail to build; what's the plan for dealing with that? > > I'd plan on providing patches for the free software drivers that depend > on an ABI version bump in the server, then push those and finally push > the new X server bits. Seem reasonable? Yep, it does! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] Remove *Clip funcs from GCFuncs
Michel Dänzer writes: > This change will cause some drivers (at least -ati, -amdgpu and -intel) > to fail to build; what's the plan for dealing with that? I'd plan on providing patches for the free software drivers that depend on an ABI version bump in the server, then push those and finally push the new X server bits. Seem reasonable? I figured I'd wait to do those until after the server changes were at least visible, and maybe reviewed. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH xserver v2] xwayland: Monitor client states to destroy callbacks
On 07/03/17 08:08 PM, Olivier Fourdan wrote: > Client resources can survive the client itself, in which case we > may end up in our sync callback trying to access client's data after > it's been freed/reclaimed. > > Add a ClientStateCallback handler to monitor the client state changes > and clear the sync callback set up by the glamor drm code if any. > > Signed-off-by: Olivier Fourdan > --- > v2: [facepalm] forgot to use the state->callback > > hw/xwayland/xwayland-glamor.c | 52 > ++- > 1 file changed, 47 insertions(+), 5 deletions(-) > > diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c > index 65c3c00..9c4297e 100644 > --- a/hw/xwayland/xwayland-glamor.c > +++ b/hw/xwayland/xwayland-glamor.c > @@ -38,6 +38,9 @@ > #include > #include "drm-client-protocol.h" > > +static DevPrivateKeyRec xwlGlamorPrivateKeyRec; > +#define xwlGlamorPrivateKey (&xwlGlamorPrivateKeyRec) "xwlGlamorPrivateKey" seems a bit generic — this key can't be used for non-client privates at the same time, can it? > @@ -441,8 +473,7 @@ sync_callback(void *data, struct wl_callback *callback, > uint32_t serial) > dri3_send_open_reply(client, state->fd); > AttendClient(client); > } sync_callback should no longer need to check client->clientGone. > -free(state); > -wl_callback_destroy(callback); > +free_xwl_auth_state (client, state); > } Space between function name and opening parens doesn't match coding style, though there does seem to be some precedent in hw/xwayland. (There's another instance of this in the patch) Other than these, looks good to me. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] Remove *Clip funcs from GCFuncs
On 08/03/17 08:26 AM, Keith Packard wrote: > Nearly every server uses the mi versions of these; allowing them to be > replaced and wrapped is a waste of code and time. > > Xnest and Xdmx required a bit of special handling as they were using > the ChangeClip function to send the updated clip lists to the > underlying X server. Moving that code up into ChangeGC is a functional > replacement, although for Xnest, it means we're always sending > rectangles and never a bitmap. > > Signed-off-by: Keith Packard This change will cause some drivers (at least -ati, -amdgpu and -intel) to fail to build; what's the plan for dealing with that? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-dummy] Add glamor acceleration which enables native OpenGL support
> You want to AC_MSG_ERROR if the the option is set to "yes" and it's > not available. Currently one silently ignores it, which is not good. Right, so I need to make it "auto" by default? Regards, Qiang ___ 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-video-dummy] Add glamor acceleration which enables native OpenGL support
> Now this is cool. Any chance I can get you to do the same for Xvfb? Thanks. I can give a try latter next month, seems glamor and egl need to support more depth for this. Regards, Qiang ___ 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] Remove *Clip funcs from GCFuncs
Nearly every server uses the mi versions of these; allowing them to be
replaced and wrapped is a waste of code and time.
Xnest and Xdmx required a bit of special handling as they were using
the ChangeClip function to send the updated clip lists to the
underlying X server. Moving that code up into ChangeGC is a functional
replacement, although for Xnest, it means we're always sending
rectangles and never a bitmap.
Signed-off-by: Keith Packard
---
Xext/panoramiX.c | 33 +---
dix/gc.c | 52 +++--
exa/exa.c | 47 +--
fb/fbgc.c | 11 +--
glamor/glamor_core.c | 11 +--
hw/dmx/dmxgc.c | 110 --
hw/dmx/dmxgc.h | 3 -
hw/xfree86/common/xf86VGAarbiter.c | 31 +---
hw/xfree86/common/xf86VGAarbiterPriv.h | 4 -
hw/xfree86/drivers/modesetting/dri2.c | 2 +-
hw/xnest/GC.c | 138 ++---
hw/xnest/XNGC.h| 3 -
include/gc.h | 6 ++
include/gcstruct.h | 11 +--
mi/mibitblt.c | 4 +-
mi/migc.c | 40 --
mi/migc.h | 10 ---
miext/damage/damage.c | 33 +---
miext/rootless/rootlessGC.c| 38 +
present/present.c | 4 +-
render/mirect.c| 2 +-
xfixes/region.c| 3 +-
22 files changed, 143 insertions(+), 453 deletions(-)
diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c
index 209df292c..23d9103a8 100644
--- a/Xext/panoramiX.c
+++ b/Xext/panoramiX.c
@@ -130,13 +130,12 @@ static void XineramaValidateGC(GCPtr, unsigned long,
DrawablePtr);
static void XineramaChangeGC(GCPtr, unsigned long);
static void XineramaCopyGC(GCPtr, unsigned long, GCPtr);
static void XineramaDestroyGC(GCPtr);
-static void XineramaChangeClip(GCPtr, int, void *, int);
-static void XineramaDestroyClip(GCPtr);
-static void XineramaCopyClip(GCPtr, GCPtr);
static const GCFuncs XineramaGCFuncs = {
-XineramaValidateGC, XineramaChangeGC, XineramaCopyGC, XineramaDestroyGC,
-XineramaChangeClip, XineramaDestroyClip, XineramaCopyClip
+.ValidateGC = XineramaValidateGC,
+.ChangeGC = XineramaChangeGC,
+.CopyGC = XineramaCopyGC,
+.DestroyGC = XineramaDestroyGC,
};
#define Xinerama_GC_FUNC_PROLOGUE(pGC)\
@@ -293,30 +292,6 @@ XineramaCopyGC(GCPtr pGCSrc, unsigned long mask, GCPtr
pGCDst)
Xinerama_GC_FUNC_EPILOGUE(pGCDst);
}
-static void
-XineramaChangeClip(GCPtr pGC, int type, void *pvalue, int nrects)
-{
-Xinerama_GC_FUNC_PROLOGUE(pGC);
-(*pGC->funcs->ChangeClip) (pGC, type, pvalue, nrects);
-Xinerama_GC_FUNC_EPILOGUE(pGC);
-}
-
-static void
-XineramaCopyClip(GCPtr pgcDst, GCPtr pgcSrc)
-{
-Xinerama_GC_FUNC_PROLOGUE(pgcDst);
-(*pgcDst->funcs->CopyClip) (pgcDst, pgcSrc);
-Xinerama_GC_FUNC_EPILOGUE(pgcDst);
-}
-
-static void
-XineramaDestroyClip(GCPtr pGC)
-{
-Xinerama_GC_FUNC_PROLOGUE(pGC);
-(*pGC->funcs->DestroyClip) (pGC);
-Xinerama_GC_FUNC_EPILOGUE(pGC);
-}
-
int
XineramaDeleteResource(void *data, XID id)
{
diff --git a/dix/gc.c b/dix/gc.c
index cb8db8535..920620e80 100644
--- a/dix/gc.c
+++ b/dix/gc.c
@@ -340,8 +340,7 @@ ChangeGC(ClientPtr client, GC * pGC, BITS32 mask,
ChangeGCValPtr pUnion)
}
pPixmap->refcnt++;
}
-(*pGC->funcs->ChangeClip) (pGC, pPixmap ? CT_PIXMAP : CT_NONE,
- (void *) pPixmap, 0);
+ChangeClip (pGC, pPixmap ? CT_PIXMAP : CT_NONE, (void *) pPixmap,
0);
break;
case GCDashOffset:
NEXTVAL(INT16, pGC->dashOffset);
@@ -712,7 +711,7 @@ CopyGC(GC * pgcSrc, GC * pgcDst, BITS32 mask)
pgcDst->clipOrg.y = pgcSrc->clipOrg.y;
break;
case GCClipMask:
-(*pgcDst->funcs->CopyClip) (pgcDst, pgcSrc);
+CopyClip (pgcDst, pgcSrc);
break;
case GCDashOffset:
pgcDst->dashOffset = pgcSrc->dashOffset;
@@ -770,7 +769,7 @@ FreeGC(void *value, XID gid)
GCPtr pGC = (GCPtr) value;
CloseFont(pGC->font, (Font) 0);
-(*pGC->funcs->DestroyClip) (pGC);
+DestroyClip (pGC);
if (!pGC->tileIsPixel)
(*pGC->pScreen->DestroyPixmap) (pGC->tile.pixmap);
@@ -1022,13 +1021,54 @@ SetClipRects(GCPtr pGC, int xOrigin, int yOrigin, int
nrects,
if (size)
memmove((char *) prectsNew, (char *) prects, size);
-(*pGC->funcs->ChangeClip) (pGC, newct, (void *) prectsNew, nrects);
+ChangeClip (pGC, newct, (void *) prectsNew, nrects);
if (pGC->funcs->ChangeGC)
(*pGC->funcs->ChangeGC) (pGC,
GCClipXOrigin | GCClipYOrigin | GCC
Re: [PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen
Aaron Plattner writes: > For the *Clip ones, yeah definitely. Patch sent. Xnest and Xdmx took some special handling, but not much. Everything else was just deleting bits. I took the opportunity to change the GCFuncs initializers to use the field names instead of relying on struct ordering. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen
On 03/07/2017 02:44 PM, Keith Packard wrote:
> Aaron Plattner writes:
>
>> They don't do anything interesting with {Change, Copy, Destroy}Clip, though.
>
> Yeah, can we just get rid of these and replace them with calls to the mi
> versions now?
For the *Clip ones, yeah definitely.
___
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] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen
Aaron Plattner writes:
> They don't do anything interesting with {Change, Copy, Destroy}Clip, though.
Yeah, can we just get rid of these and replace them with calls to the mi
versions now?
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-dummy] Add glamor acceleration which enables native OpenGL support
On 7 March 2017 at 03:53, Qiang Yu wrote: > Enable glamor acceleration in xorg.conf by: > Section "Device" > ... > Driver "dummy" > Option "Render" "/dev/dri/renderD128" > ... > EndSection > > GPU is chosen by the Render option which specifies the render > node of the GPU DRM device. > > We could use the dumb buffer instead of gbm buffer as the > screen front buffer. But dumb buffer requires open > /dev/dri/cardx which has the limitation of only one instance > of OpenGL enabled xserver can start. > > With gbm buffer, we can use /dev/dri/renderDx which has no > limitation on the number of OpenGL enabled xserver and even > won't conflict with a "real" xserver using radeon/amdgpu DDX. > > Due to using renderDx, only DRI3 OpenGL is supported. > > DGA is disabled when glamor is enabled, we can enable it with > new gbm_bo_map/unmap API, but consider a more effiction way > is just using DRI3BufferFromPixmap for the root window pixmap. > > Signed-off-by: Qiang Yu > --- > configure.ac | 26 ++ > src/Makefile.am| 7 ++- > src/dummy.h| 9 > src/dummy_dga.c| 3 ++ > src/dummy_driver.c | 143 > - > 5 files changed, 176 insertions(+), 12 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 4eb7fae..7239b63 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -68,6 +68,32 @@ AM_CONDITIONAL([DGA], [test "x$DGA" = xyes]) > # Obtain compiler/linker options for the driver dependencies > PKG_CHECK_MODULES(XORG, [xorg-server >= 1.4.99.901] xproto fontsproto > $REQUIRED_MODULES) > > +# Check glamor support > +AC_ARG_ENABLE(glamor, > + AS_HELP_STRING([--disable-glamor], > +[Disable glamor, a new GL-based acceleration > [default=enabled]]), > + [GLAMOR="$enableval"], > + [GLAMOR=yes]) > + > +SAVE_CPPFLAGS="$CPPFLAGS" > +CPPFLAGS="$CPPFLAGS $XORG_CFLAGS" > +if test "x$GLAMOR" != "xno"; then > + AC_CHECK_HEADERS([glamor.h], , [GLAMOR=no], [#include > "xorg-server.h"]) > +fi > +CPPFLAGS="$SAVE_CPPFLAGS" > + > +if test "x$GLAMOR" != "xno"; then > + PKG_CHECK_MODULES(GBM, [gbm], , [GLAMOR=no]) > +fi > + > +AC_MSG_CHECKING([whether to include GLAMOR support]) > +AC_MSG_RESULT([$GLAMOR]) > + > +if test "x$GLAMOR" != "xno"; then > +AC_DEFINE(USE_GLAMOR, 1, [Enable glamor acceleration]) > +fi > +AM_CONDITIONAL(GLAMOR, test x$GLAMOR != xno) > + The idea is cool, but the above looks wrong/broken. You want to AC_MSG_ERROR if the the option is set to "yes" and it's not available. Currently one silently ignores it, which is not good. -Emil ___ 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/xkbcomp] Add xkboutputdir to xkbcomp.pc
HI Adam,
On 7 March 2017 at 17:42, Adam Jackson wrote:
> The X server (and everybody else, really) wants to know where to put
> xkbcomp's output, so xkbcomp.pc should say. This should be under
> localstatedir, since the output is architecture-dependent (as the note
> in xserver/xkb/README.compiled suggests).
>
> Signed-off-by: Adam Jackson
> ---
> configure.ac| 9 +
> m4/ac_define_dir.m4 | 52
> xkbcomp.pc.in | 1 +
> xkbpath.c | 4 +---
> 4 files changed, 63 insertions(+), 3 deletions(-)
> create mode 100644 m4/ac_define_dir.m4
>
> diff --git a/configure.ac b/configure.ac
> index 0c8063e..3c151f3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -26,6 +26,7 @@ AC_INIT([xkbcomp], [1.3.1],
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [xkbcomp])
> AC_CONFIG_SRCDIR([Makefile.am])
> AC_CONFIG_HEADERS([config.h])
> +AC_CONFIG_MACRO_DIR([m4])
>
> # Initialize Automake
> AM_INIT_AUTOMAKE([foreign dist-bzip2])
> @@ -59,7 +60,15 @@ AC_ARG_WITH([xkb_config_root],
> [XKBCONFIGROOT="$withval"],
> [XKBCONFIGROOT='${datadir}/X11/xkb'])
> AC_SUBST([XKBCONFIGROOT])
> +AC_DEFINE_DIR(DFLT_XKB_CONFIG_ROOT, XKBCONFIGROOT, [XKB config root])
>
Not 100% sure but I think the current -DDFLT_XKB_CONFIG_ROOT... should
be sufficient. Alternatively can you point out what's the current vs
expected result ?
> +AC_ARG_WITH([xkb_output_path],
> +[AS_HELP_STRING([--with-xkb-output-path=],
> +[Set default XKB output path (default: ${localstatedir}/xkb)])],
> +[XKBOUTPUTPATH="$withval"],
> +[XKBOUTPUTPATH='${localstatedir}/xkb'])
> +AC_SUBST([XKBOUTPUTPATH])
> +AC_DEFINE_DIR(DFLT_XKB_OUTPUT_PATH, XKBOUTPUTPATH, [XKB output path])
>
Slightly silly question: are these really the output path of xkbcomp ?
Afaict the tool outputs to any user specified location.
On my system the path /usr/share/X11/xkb is provided by
xkeyboard-config. The latter of which providing having xkb_base
variable in its .pc file for such purposes.
> --- a/xkbcomp.pc.in
> +++ b/xkbcomp.pc.in
> @@ -2,6 +2,7 @@ prefix=@prefix@
> datarootdir=@datarootdir@
> datadir=@datadir@
> xkbconfigdir=@XKBCONFIGROOT@
> +xkboutputdir=@XKBOUTPUTPATH@
>
> Name: xkbcomp
> Description: XKB keymap compiler
> diff --git a/xkbpath.c b/xkbpath.c
> index 6f18b86..3345ba9 100644
> --- a/xkbpath.c
> +++ b/xkbpath.c
> @@ -33,9 +33,7 @@
> #include
> #include "xkbpath.h"
>
> -#ifndef DFLT_XKB_CONFIG_ROOT
> -#define DFLT_XKB_CONFIG_ROOT "/usr/lib/X11/xkb"
Regardless if the current define is sufficient, we might want to
change this to something like below ?
#ifndef DFLT_XKB_CONFIG_ROOT
#error "DFLT_XKB_CONFIG_ROOT is not defined"
#endif
> -#endif
> +#include "config.h"
>
Hmm config.h management/amongst others looks very wrong on this
package. I'll give it some love (patches) after dinner.
-Emil
___
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] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen
On 03/02/2017 03:35 PM, Adam Jackson wrote:
> On Thu, 2017-03-02 at 13:20 -0800, Keith Packard wrote:
>>> Adam Jackson writes:
>>> The "call down" convention would need to know to scan ahead to find
>>> the next non-null fptr for the slot either way, but that's not really
>>> different from the current model where some slots can be null at the
>>> bottom.
>>
>> Hence my hack of filling in the pointers between the slots which are in
>> use; you just call the one below 'your' entry.
>
> That means you have to save "your" index for every slot though. Or rely
> on fptr equality I suppose, but that's not really different since you
> then have to write your own detangle code to find yourself in every
> slot. If your layer index is constant (until someone tries to wrap
> between you, which you can get notified of) then detangling yourself
> means passing your index to a common routine that nulls your column of
> the arrays for you.
>
>>> So... seems plausible. Maybe try the experiment with GCOps first before
>>> blowing up the whole Screen?
>>
>> Seems reasonable. The hard part to me seems to be coming up with a
>> complete list of 'layers', or at least complete enough for a start. I
>> don't want to have to reallocate these on the fly...
>
> I mean, I did grep for '\' for a reason. Eight is enough.
We have a few of these layers. They're mostly pretty trivial, but here
be dragons.
They don't do anything interesting with {Change, Copy, Destroy}Clip, though.
> - ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] _XDefaultError: set XlibDisplayIOError flag before calling exit
On 02/21/2017 08:16 AM, Arthur Huillet wrote: > With Jamey's review and Julien's questions answered, would someone > please push that change to libX11, unless there are objections to the > patch? > > Thank you $ git push upstream HEAD:master Counting objects: 4, done. Delta compression using up to 24 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 1.62 KiB | 0 bytes/s, done. Total 4 (delta 3), reused 0 (delta 0) remote: Updating patchwork state for https://patchwork.freedesktop.org/project/Xorg/list/ remote: I: patch #136280 updated using rev 2d20890e7ffd3ee88a9ceb25cdd2ac1fe7aaceb6. remote: I: 1 patch(es) updated to state Accepted. To git.freedesktop.org:/git/xorg/lib/libX11 42f4d7af9cf6..2d20890e7ffd HEAD -> master ___ 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] glamor: use drmGetDeviceNameFromFD2 when available
On Tue, 2017-03-07 at 11:53 +0800, Qiang Yu wrote: > This is for glamor can support fd from DRM render node > which is useful for a render only DDX. > > Signed-off-by: Qiang Yu remote: I: patch #142545 updated using rev 9232835bd16b6948442f7a4588fb9376782cb814. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver d4b7e0e..9232835 master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-dummy] Add glamor acceleration which enables native OpenGL support
On Tue, 2017-03-07 at 11:53 +0800, Qiang Yu wrote: > Enable glamor acceleration in xorg.conf by: > Section "Device" > ... > Driver "dummy" > Option "Render" "/dev/dri/renderD128" > ... > EndSection > > GPU is chosen by the Render option which specifies the render > node of the GPU DRM device. Now this is cool. Any chance I can get you to do the same for Xvfb? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v2] xwayland: clear cursor frame callback
On Tue, 2017-03-07 at 14:30 +0100, Rui Tiago Cação Matos wrote: > > On Tue, Mar 7, 2017 at 10:28 AM, Olivier Fourdan > > wrote: > > After an X cursor is unrealized, the seat's corresponding x_cursor is > > cleared, but if a frame callback was pending at the time, it will > > remain and thus prevent any further cursor update, leaving the window > > with no cursor. > > > > Make sure to destroy the frame callback, if any, when that occurs, so > > that next time a cursor needs to be set, it won't be ignored for a frame > > callback that will never be triggered. > > Reviewed-by: Rui Matos remote: I: patch #142616 updated using rev d4b7e0eaa4b2e97ce1dec653a2ae7d9621fe1431. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 64ca14b..d4b7e0e master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH app/xkbcomp] Add xkboutputdir to xkbcomp.pc
The X server (and everybody else, really) wants to know where to put
xkbcomp's output, so xkbcomp.pc should say. This should be under
localstatedir, since the output is architecture-dependent (as the note
in xserver/xkb/README.compiled suggests).
Signed-off-by: Adam Jackson
---
configure.ac| 9 +
m4/ac_define_dir.m4 | 52
xkbcomp.pc.in | 1 +
xkbpath.c | 4 +---
4 files changed, 63 insertions(+), 3 deletions(-)
create mode 100644 m4/ac_define_dir.m4
diff --git a/configure.ac b/configure.ac
index 0c8063e..3c151f3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,6 +26,7 @@ AC_INIT([xkbcomp], [1.3.1],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [xkbcomp])
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([config.h])
+AC_CONFIG_MACRO_DIR([m4])
# Initialize Automake
AM_INIT_AUTOMAKE([foreign dist-bzip2])
@@ -59,7 +60,15 @@ AC_ARG_WITH([xkb_config_root],
[XKBCONFIGROOT="$withval"],
[XKBCONFIGROOT='${datadir}/X11/xkb'])
AC_SUBST([XKBCONFIGROOT])
+AC_DEFINE_DIR(DFLT_XKB_CONFIG_ROOT, XKBCONFIGROOT, [XKB config root])
+AC_ARG_WITH([xkb_output_path],
+[AS_HELP_STRING([--with-xkb-output-path=],
+[Set default XKB output path (default: ${localstatedir}/xkb)])],
+[XKBOUTPUTPATH="$withval"],
+[XKBOUTPUTPATH='${localstatedir}/xkb'])
+AC_SUBST([XKBOUTPUTPATH])
+AC_DEFINE_DIR(DFLT_XKB_OUTPUT_PATH, XKBOUTPUTPATH, [XKB output path])
AC_CONFIG_FILES([
Makefile
diff --git a/m4/ac_define_dir.m4 b/m4/ac_define_dir.m4
new file mode 100644
index 000..3a6a359
--- /dev/null
+++ b/m4/ac_define_dir.m4
@@ -0,0 +1,52 @@
+# ===
+# http://autoconf-archive.cryp.to/ac_define_dir.html
+# ===
+#
+# SYNOPSIS
+#
+# AC_DEFINE_DIR(VARNAME, DIR [, DESCRIPTION])
+#
+# DESCRIPTION
+#
+# This macro sets VARNAME to the expansion of the DIR variable, taking
+# care of fixing up ${prefix} and such.
+#
+# VARNAME is then offered as both an output variable and a C preprocessor
+# symbol.
+#
+# Example:
+#
+# AC_DEFINE_DIR([DATADIR], [datadir], [Where data are placed to.])
+#
+# LAST MODIFICATION
+#
+# 2017-03-07 - eval ac_define_dir three times instead of two, otherwise I
+#get ${prefix}/share/X11/xkb in config.h [ajax]
+#
+# COPYLEFT
+#
+# Copyright (c) 2008 Stepan Kasal
+# Copyright (c) 2008 Andreas Schwab
+# Copyright (c) 2008 Guido U. Draheim
+# Copyright (c) 2008 Alexandre Oliva
+#
+# Copying and distribution of this file, with or without modification, are
+# permitted in any medium without royalty provided the copyright notice
+# and this notice are preserved.
+
+AC_DEFUN([AC_DEFINE_DIR], [
+ prefix_NONE=
+ exec_prefix_NONE=
+ test "x$prefix" = xNONE && prefix_NONE=yes && prefix=$ac_default_prefix
+ test "x$exec_prefix" = xNONE && exec_prefix_NONE=yes && exec_prefix=$prefix
+dnl In Autoconf 2.60, ${datadir} refers to ${datarootdir}, which in turn
+dnl refers to ${prefix}. Thus we have to use `eval' twice.
+ eval ac_define_dir="\"[$]$2\""
+ eval ac_define_dir="\"$ac_define_dir\""
+dnl Once more, but with feeling
+ eval ac_define_dir="\"$ac_define_dir\""
+ AC_SUBST($1, "$ac_define_dir")
+ AC_DEFINE_UNQUOTED($1, "$ac_define_dir", [$3])
+ test "$prefix_NONE" && prefix=NONE
+ test "$exec_prefix_NONE" && exec_prefix=NONE
+])
diff --git a/xkbcomp.pc.in b/xkbcomp.pc.in
index b8d6023..c5ccde5 100644
--- a/xkbcomp.pc.in
+++ b/xkbcomp.pc.in
@@ -2,6 +2,7 @@ prefix=@prefix@
datarootdir=@datarootdir@
datadir=@datadir@
xkbconfigdir=@XKBCONFIGROOT@
+xkboutputdir=@XKBOUTPUTPATH@
Name: xkbcomp
Description: XKB keymap compiler
diff --git a/xkbpath.c b/xkbpath.c
index 6f18b86..3345ba9 100644
--- a/xkbpath.c
+++ b/xkbpath.c
@@ -33,9 +33,7 @@
#include
#include "xkbpath.h"
-#ifndef DFLT_XKB_CONFIG_ROOT
-#define DFLT_XKB_CONFIG_ROOT "/usr/lib/X11/xkb"
-#endif
+#include "config.h"
#ifndef PATH_MAX
#definePATH_MAX 1024
--
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 v2] xwayland: clear cursor frame callback
On Tue, Mar 7, 2017 at 10:28 AM, Olivier Fourdan wrote: > After an X cursor is unrealized, the seat's corresponding x_cursor is > cleared, but if a frame callback was pending at the time, it will > remain and thus prevent any further cursor update, leaving the window > with no cursor. > > Make sure to destroy the frame callback, if any, when that occurs, so > that next time a cursor needs to be set, it won't be ignored for a frame > callback that will never be triggered. Reviewed-by: Rui Matos ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC PATCH xserver v2] xwayland: Monitor client states to destroy callbacks
Client resources can survive the client itself, in which case we
may end up in our sync callback trying to access client's data after
it's been freed/reclaimed.
Add a ClientStateCallback handler to monitor the client state changes
and clear the sync callback set up by the glamor drm code if any.
Signed-off-by: Olivier Fourdan
---
v2: [facepalm] forgot to use the state->callback
hw/xwayland/xwayland-glamor.c | 52 ++-
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 65c3c00..9c4297e 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -38,6 +38,9 @@
#include
#include "drm-client-protocol.h"
+static DevPrivateKeyRec xwlGlamorPrivateKeyRec;
+#define xwlGlamorPrivateKey (&xwlGlamorPrivateKeyRec)
+
struct xwl_pixmap {
struct wl_buffer *buffer;
struct gbm_bo *bo;
@@ -429,9 +432,38 @@ glamor_egl_dri3_fd_name_from_tex(ScreenPtr screen,
struct xwl_auth_state {
int fd;
ClientPtr client;
+struct wl_callback *callback;
};
static void
+free_xwl_auth_state(ClientPtr pClient, struct xwl_auth_state *state)
+{
+dixSetPrivate(&pClient->devPrivates, xwlGlamorPrivateKey, NULL);
+if (state) {
+wl_callback_destroy(state->callback);
+free(state);
+}
+}
+
+static void
+xwl_auth_state_client_callback(CallbackListPtr *pcbl, void *unused, void *data)
+{
+NewClientInfoRec *clientinfo = (NewClientInfoRec *) data;
+ClientPtr pClient = clientinfo->client;
+struct xwl_auth_state *state;
+
+switch (pClient->clientState) {
+case ClientStateGone:
+case ClientStateRetained:
+state = dixLookupPrivate(&pClient->devPrivates, xwlGlamorPrivateKey);
+free_xwl_auth_state (pClient, state);
+break;
+default:
+break;
+}
+}
+
+static void
sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
{
struct xwl_auth_state *state = data;
@@ -441,8 +473,7 @@ sync_callback(void *data, struct wl_callback *callback,
uint32_t serial)
dri3_send_open_reply(client, state->fd);
AttendClient(client);
}
-free(state);
-wl_callback_destroy(callback);
+free_xwl_auth_state (client, state);
}
static const struct wl_callback_listener sync_listener = {
@@ -457,7 +488,6 @@ xwl_dri3_open_client(ClientPtr client,
{
struct xwl_screen *xwl_screen = xwl_screen_get(screen);
struct xwl_auth_state *state;
-struct wl_callback *callback;
drm_magic_t magic;
int fd;
@@ -485,8 +515,9 @@ xwl_dri3_open_client(ClientPtr client,
}
wl_drm_authenticate(xwl_screen->drm, magic);
-callback = wl_display_sync(xwl_screen->display);
-wl_callback_add_listener(callback, &sync_listener, state);
+state->callback = wl_display_sync(xwl_screen->display);
+wl_callback_add_listener(state->callback, &sync_listener, state);
+dixSetPrivate(&client->devPrivates, xwlGlamorPrivateKey, state);
IgnoreClient(client);
@@ -568,6 +599,17 @@ xwl_glamor_init(struct xwl_screen *xwl_screen)
return FALSE;
}
+if (!AddCallback(&ClientStateCallback, xwl_auth_state_client_callback,
NULL)) {
+ErrorF("Failed to add client state callback\n");
+return FALSE;
+}
+
+if (!dixRegisterPrivateKey(xwlGlamorPrivateKey, PRIVATE_CLIENT, 0)) {
+ErrorF("Failed to register private key\n");
+DeleteCallback(&ClientStateCallback, xwl_auth_state_client_callback,
NULL);
+return FALSE;
+}
+
xwl_screen->CreateScreenResources = screen->CreateScreenResources;
screen->CreateScreenResources = xwl_glamor_create_screen_resources;
screen->CreatePixmap = xwl_glamor_create_pixmap;
--
2.9.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver v2] xwayland: clear cursor frame callback
After an X cursor is unrealized, the seat's corresponding x_cursor is
cleared, but if a frame callback was pending at the time, it will
remain and thus prevent any further cursor update, leaving the window
with no cursor.
Make sure to destroy the frame callback, if any, when that occurs, so
that next time a cursor needs to be set, it won't be ignored for a frame
callback that will never be triggered.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
Signed-off-by: Olivier Fourdan
Reviewed-by: Pekka Paalanen
---
v2: Rename cursor_frame_callback() to clear_cursor_frame_callback()
Add Pekka's r-b
hw/xwayland/xwayland-cursor.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
index 0c1cd34..f334f1c 100644
--- a/hw/xwayland/xwayland-cursor.c
+++ b/hw/xwayland/xwayland-cursor.c
@@ -96,14 +96,22 @@ xwl_unrealize_cursor(DeviceIntPtr device, ScreenPtr screen,
CursorPtr cursor)
}
static void
+clear_cursor_frame_callback(struct xwl_seat *xwl_seat)
+{
+ if (xwl_seat->cursor_frame_cb) {
+ wl_callback_destroy (xwl_seat->cursor_frame_cb);
+ xwl_seat->cursor_frame_cb = NULL;
+ }
+}
+
+static void
frame_callback(void *data,
struct wl_callback *callback,
uint32_t time)
{
struct xwl_seat *xwl_seat = data;
-wl_callback_destroy (xwl_seat->cursor_frame_cb);
-xwl_seat->cursor_frame_cb = NULL;
+clear_cursor_frame_callback(xwl_seat);
if (xwl_seat->cursor_needs_update) {
xwl_seat->cursor_needs_update = FALSE;
xwl_seat_set_cursor(xwl_seat);
@@ -127,6 +135,8 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
if (!xwl_seat->x_cursor) {
wl_pointer_set_cursor(xwl_seat->wl_pointer,
xwl_seat->pointer_enter_serial, NULL, 0, 0);
+clear_cursor_frame_callback(xwl_seat);
+xwl_seat->cursor_needs_update = FALSE;
return;
}
--
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
[RFC PATCH xserver] xwayland: Monitor client states to destroy callbacks
Client resources can survive the client itself, in which case we
may end up in our sync callback trying to access client's data after
it's been freed/reclaimed.
Add a ClientStateCallback handler to monitor the client state changes
and clear the sync callback set up by the glamor drm code if any.
Signed-off-by: Olivier Fourdan
---
As discussed with Michel on irc, it's possible that widnows survive the
client itself, meanign that we could still end up trying to access freed
memory in our glamor sync handler.
hw/xwayland/xwayland-glamor.c | 50 ---
1 file changed, 47 insertions(+), 3 deletions(-)
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 65c3c00..cc04a33 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -38,6 +38,9 @@
#include
#include "drm-client-protocol.h"
+static DevPrivateKeyRec xwlGlamorPrivateKeyRec;
+#define xwlGlamorPrivateKey (&xwlGlamorPrivateKeyRec)
+
struct xwl_pixmap {
struct wl_buffer *buffer;
struct gbm_bo *bo;
@@ -429,9 +432,39 @@ glamor_egl_dri3_fd_name_from_tex(ScreenPtr screen,
struct xwl_auth_state {
int fd;
ClientPtr client;
+struct wl_callback *callback;
};
static void
+free_xwl_auth_state(ClientPtr pClient, struct xwl_auth_state *state)
+{
+dixSetPrivate(&(pClient)->devPrivates, xwlGlamorPrivateKey, NULL);
+
+if (state) {
+wl_callback_destroy(state->callback);
+free(state);
+}
+}
+
+static void
+xwl_auth_state_client_callback(CallbackListPtr *pcbl, void *unused, void *data)
+{
+NewClientInfoRec *clientinfo = (NewClientInfoRec *) data;
+ClientPtr pClient = clientinfo->client;
+struct xwl_auth_state *state;
+
+switch (pClient->clientState) {
+case ClientStateGone:
+case ClientStateRetained:
+state = dixLookupPrivate(&(pClient)->devPrivates, xwlGlamorPrivateKey);
+free_xwl_auth_state (pClient, state);
+break;
+default:
+break;
+}
+}
+
+static void
sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
{
struct xwl_auth_state *state = data;
@@ -441,8 +474,7 @@ sync_callback(void *data, struct wl_callback *callback,
uint32_t serial)
dri3_send_open_reply(client, state->fd);
AttendClient(client);
}
-free(state);
-wl_callback_destroy(callback);
+free_xwl_auth_state (client, state);
}
static const struct wl_callback_listener sync_listener = {
@@ -485,8 +517,9 @@ xwl_dri3_open_client(ClientPtr client,
}
wl_drm_authenticate(xwl_screen->drm, magic);
-callback = wl_display_sync(xwl_screen->display);
+state->callback = wl_display_sync(xwl_screen->display);
wl_callback_add_listener(callback, &sync_listener, state);
+dixSetPrivate(&client->devPrivates, xwlGlamorPrivateKey, state);
IgnoreClient(client);
@@ -568,6 +601,17 @@ xwl_glamor_init(struct xwl_screen *xwl_screen)
return FALSE;
}
+if (!AddCallback(&ClientStateCallback, xwl_auth_state_client_callback,
NULL)) {
+ErrorF("Failed to add client state callback\n");
+return FALSE;
+}
+
+if (!dixRegisterPrivateKey(xwlGlamorPrivateKey, PRIVATE_CLIENT, 0)) {
+ErrorF("Failed to register private key\n");
+DeleteCallback(&ClientStateCallback, xwl_auth_state_client_callback,
NULL);
+return FALSE;
+}
+
xwl_screen->CreateScreenResources = screen->CreateScreenResources;
screen->CreateScreenResources = xwl_glamor_create_screen_resources;
screen->CreatePixmap = xwl_glamor_create_pixmap;
--
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
