Re: [PATCH v2 xserver 4/7] configure.ac: factor out xquartz bundle destdir
On Tue, Apr 04, 2017 at 05:07:25PM -0700, Jeremy Huddleston Sequoia wrote:
> I'm not familiar with the problem. Is this the canonical way to actually do
> this? It seems a bit odd, but it looks fine to me if just a bit quirky:
>
v1 did it in the makefile, and is indeed probably preferrable, at least
because configure does not currently contain any DESTDIR occurences.
> Reviewed-by: Jeremy Sequoia
>
> > On Apr 4, 2017, at 4:49 PM, Mihail Konev wrote:
> >
> > Fixes DESTDIR not being included in x11appdir, allowing to run distcheck
> > as non-root.
> >
> > Signed-off-by: Mihail Konev
> > ---
> > v2: Move DESTDIR to configure. Add missing Cc.
> >
> > configure.ac | 4 ++--
> > hw/xquartz/bundle/Makefile.am | 8
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 3196e42df16a..7e44f2c3166c 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -566,8 +566,8 @@ AC_ARG_WITH(serverconfig-path,
> > AS_HELP_STRING([--with-serverconfig-path=PATH],
> > [ SERVERCONFIG="$withval" ],
> > [ SERVERCONFIG="${libdir}/xorg" ])
> > AC_ARG_WITH(apple-applications-dir,AS_HELP_STRING([--with-apple-applications-dir=PATH],
> > [Path to the Applications directory (default: /Applications/Utilities)]),
> > - [ APPLE_APPLICATIONS_DIR="${withval}" ],
> > - [
> > APPLE_APPLICATIONS_DIR="/Applications/Utilities" ])
> > + [
> > APPLE_APPLICATIONS_DIR='$(DESTDIR)'"${withval}" ],
> > + [
> > APPLE_APPLICATIONS_DIR='$(DESTDIR)'"/Applications/Utilities" ])
> > AC_SUBST([APPLE_APPLICATIONS_DIR])
> > AC_ARG_WITH(apple-application-name,AS_HELP_STRING([--with-apple-application-name=NAME],
> > [Name for the .app (default: X11)]),
> > [ APPLE_APPLICATION_NAME="${withval}" ],
> > diff --git a/hw/xquartz/bundle/Makefile.am b/hw/xquartz/bundle/Makefile.am
> > index 424a7475f063..c8d29e6718c0 100644
> > --- a/hw/xquartz/bundle/Makefile.am
> > +++ b/hw/xquartz/bundle/Makefile.am
> > @@ -11,12 +11,12 @@ CPP_FILES_FLAGS += -DXQUARTZ_SPARKLE
> > -DXQUARTZ_SPARKLE_FEED_URL="$(XQUARTZ_SPARK
> > endif
> >
> > install-data-hook:
> > - $(srcdir)/mk_bundke.sh $(srcdir) $(builddir)
> > $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app install
> > + $(srcdir)/mk_bundke.sh $(srcdir) $(builddir)
> > $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app install
> >
> > uninstall-hook:
> > - $(RM) -rf
> > $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Resources
> > - $(RM) -rf
> > $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Info.plist
> > - $(RM) -rf
> > $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/PkgInfo
> > + $(RM) -rf
> > $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Resources
> > + $(RM) -rf
> > $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Info.plist
> > + $(RM) -rf
> > $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/PkgInfo
> >
> > noinst_PRE = Info.plist.cpp
> > noinst_DATA = $(noinst_PRE:plist.cpp=plist)
> > --
> > 2.9.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
Re: [PATCH xrandr] Adding a "--filter" flag
ping :)
Thanks,
Pablo
On Thu, 23 Mar 2017, Pablo De La Garza wrote:
> From: pdelagarza
>
> Flag can be set to "nearest" or "bilinear"
>
> Signed-off-by: Pablo De La Garza
> ---
> xrandr.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/xrandr.c b/xrandr.c
> index dcfdde0..c2cc82e 100644
> --- a/xrandr.c
> +++ b/xrandr.c
> @@ -54,6 +54,12 @@ static Boolautomatic = False;
> static Bool properties = False;
> static Bool grab_server = True;
> static Bool no_primary = False;
> +static int filterType = -1;
> +
> +static const char *filterTypeList[2] = {
> +"bilinear",
> +"nearest"};
> +
>
> static const char *direction[5] = {
> "normal",
> @@ -118,6 +124,7 @@ usage(void)
> " --fb x\n"
> " --fbmm x\n"
> " --dpi /\n"
> + " --filter ,filterType: nearest, bilinear\n"
> " --output \n"
> " --auto\n"
> " --mode \n"
> @@ -285,6 +292,7 @@ typedef enum _changes {
> changes_panning = (1 << 10),
> changes_gamma = (1 << 11),
> changes_primary = (1 << 12),
> +changes_filter = (1 << 13),
> } changes_t;
>
> typedef enum _name_kind {
> @@ -1311,6 +1319,11 @@ set_output_info (output_t *output, RROutput xid,
> XRROutputInfo *output_info)
> output->transform.params = NULL;
> }
> }
> +if (output->changes & changes_filter)
> +{
> +output->transform.filter = filterTypeList[filterType];
> +}
> +
>
> /* set primary */
> if (!(output->changes & changes_primary))
> @@ -2808,6 +2821,28 @@ main (int argc, char **argv)
> action_requested = True;
> continue;
> }
> +
> +if (!strcmp("--filter", argv[i]))
> +{
> +if (!config_output) argerr ("%s must be used after --output\n",
> argv[i]);
> +if (++i >= argc) argerr("%s requires an argument\n", argv[i-1]);
> +
> +for (int t=0;t <
> sizeof(filterTypeList)/sizeof(filterTypeList[0]);t++)
> +{
> +if (!strcmp(filterTypeList[t],argv[i]))
> +{
> +filterType = t;
> +break;
> +}
> +}
> +
> +if (filterType==-1) argerr("Bad argument: %s, for a filter\n",
> argv[i]);
> +
> +config_output->changes |= changes_filter;
> +action_requested = True;
> +continue;
> +}
> +
> if (!strcmp ("--crtc", argv[i])) {
> if (!config_output) argerr ("%s must be used after --output\n",
> argv[i]);
> if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
> --
> 2.7.4
>
>
___
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 v2 xserver 4/7] configure.ac: factor out xquartz bundle destdir
I'm not familiar with the problem. Is this the canonical way to actually do
this? It seems a bit odd, but it looks fine to me if just a bit quirky:
Reviewed-by: Jeremy Sequoia
> On Apr 4, 2017, at 4:49 PM, Mihail Konev wrote:
>
> Fixes DESTDIR not being included in x11appdir, allowing to run distcheck
> as non-root.
>
> Signed-off-by: Mihail Konev
> ---
> v2: Move DESTDIR to configure. Add missing Cc.
>
> configure.ac | 4 ++--
> hw/xquartz/bundle/Makefile.am | 8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 3196e42df16a..7e44f2c3166c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -566,8 +566,8 @@ AC_ARG_WITH(serverconfig-path,
> AS_HELP_STRING([--with-serverconfig-path=PATH],
> [ SERVERCONFIG="$withval" ],
> [ SERVERCONFIG="${libdir}/xorg" ])
> AC_ARG_WITH(apple-applications-dir,AS_HELP_STRING([--with-apple-applications-dir=PATH],
> [Path to the Applications directory (default: /Applications/Utilities)]),
> - [ APPLE_APPLICATIONS_DIR="${withval}" ],
> - [
> APPLE_APPLICATIONS_DIR="/Applications/Utilities" ])
> + [
> APPLE_APPLICATIONS_DIR='$(DESTDIR)'"${withval}" ],
> + [
> APPLE_APPLICATIONS_DIR='$(DESTDIR)'"/Applications/Utilities" ])
> AC_SUBST([APPLE_APPLICATIONS_DIR])
> AC_ARG_WITH(apple-application-name,AS_HELP_STRING([--with-apple-application-name=NAME],
> [Name for the .app (default: X11)]),
> [ APPLE_APPLICATION_NAME="${withval}" ],
> diff --git a/hw/xquartz/bundle/Makefile.am b/hw/xquartz/bundle/Makefile.am
> index 424a7475f063..c8d29e6718c0 100644
> --- a/hw/xquartz/bundle/Makefile.am
> +++ b/hw/xquartz/bundle/Makefile.am
> @@ -11,12 +11,12 @@ CPP_FILES_FLAGS += -DXQUARTZ_SPARKLE
> -DXQUARTZ_SPARKLE_FEED_URL="$(XQUARTZ_SPARK
> endif
>
> install-data-hook:
> - $(srcdir)/mk_bundke.sh $(srcdir) $(builddir)
> $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app install
> + $(srcdir)/mk_bundke.sh $(srcdir) $(builddir)
> $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app install
>
> uninstall-hook:
> - $(RM) -rf
> $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Resources
> - $(RM) -rf
> $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Info.plist
> - $(RM) -rf
> $(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/PkgInfo
> + $(RM) -rf
> $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Resources
> + $(RM) -rf
> $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Info.plist
> + $(RM) -rf
> $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/PkgInfo
>
> noinst_PRE = Info.plist.cpp
> noinst_DATA = $(noinst_PRE:plist.cpp=plist)
> --
> 2.9.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
Re: [PATCH v2 xserver 5/7] hw/xquartz: fix path to pseudoramiX headers
Thanks.
Reviewed-by: Jeremy Sequoia
> On Apr 4, 2017, at 4:49 PM, Mihail Konev wrote:
>
> Fixes out-of-source XQuartz build.
>
> Fixes: 39c548da ("XQuartz: Fix build with moved pseudoramiX")
> Signed-off-by: Mihail Konev
> ---
> v2: Reword. Add missing Cc.
>
> hw/xquartz/Makefile.am | 2 +-
> hw/xquartz/xpr/Makefile.am | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xquartz/Makefile.am b/hw/xquartz/Makefile.am
> index 4da896d76173..5ccbe48917bc 100644
> --- a/hw/xquartz/Makefile.am
> +++ b/hw/xquartz/Makefile.am
> @@ -8,7 +8,7 @@ AM_CPPFLAGS = \
> -DUSE_NEW_CLUT \
> -DXFree86Server \
> -I$(top_srcdir)/miext/rootless \
> - -I$(top_builddir)/pseudoramiX \
> + -I$(top_srcdir)/pseudoramiX \
> -DX11LIBDIR=\"$(libdir)\"
>
> if GLX
> diff --git a/hw/xquartz/xpr/Makefile.am b/hw/xquartz/xpr/Makefile.am
> index c654ee595cb9..e4b138617805 100644
> --- a/hw/xquartz/xpr/Makefile.am
> +++ b/hw/xquartz/xpr/Makefile.am
> @@ -3,7 +3,7 @@ noinst_LTLIBRARIES = libXquartzXpr.la
> AM_CFLAGS = $(DIX_CFLAGS)
> AM_CPPFLAGS = \
> -I$(srcdir) -I$(srcdir)/.. \
> - -I$(top_builddir)/pseudoramiX \
> + -I$(top_srcdir)/pseudoramiX \
> -I$(top_srcdir)/miext \
> -I$(top_srcdir)/miext/rootless
>
> --
> 2.9.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
[PATCH v2 xserver 1/7] configure.ac: only stub sdksyms.dep as needed
Fixes the file not being cleaned with --disable-xorg, for such a distcheck not to fail. Signed-off-by: Mihail Konev --- v2: Reword. configure.ac | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index ac11e65728e8..3196e42df16a 100644 --- a/configure.ac +++ b/configure.ac @@ -2488,7 +2488,9 @@ AC_SUBST([libdir]) AC_SUBST([exec_prefix]) AC_SUBST([prefix]) -AC_CONFIG_COMMANDS([sdksyms], [touch hw/xfree86/sdksyms.dep]) +if test "x$XORG" = xyes; then + AC_CONFIG_COMMANDS([sdksyms], [touch hw/xfree86/sdksyms.dep]) +fi if test "x$CONFIG_HAL" = xno && test "x$CONFIG_UDEV" = xno; then AC_MSG_WARN([ -- 2.9.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
[PATCH v2 xserver 4/7] configure.ac: factor out xquartz bundle destdir
Fixes DESTDIR not being included in x11appdir, allowing to run distcheck
as non-root.
Signed-off-by: Mihail Konev
---
v2: Move DESTDIR to configure. Add missing Cc.
configure.ac | 4 ++--
hw/xquartz/bundle/Makefile.am | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3196e42df16a..7e44f2c3166c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -566,8 +566,8 @@ AC_ARG_WITH(serverconfig-path,
AS_HELP_STRING([--with-serverconfig-path=PATH],
[ SERVERCONFIG="$withval" ],
[ SERVERCONFIG="${libdir}/xorg" ])
AC_ARG_WITH(apple-applications-dir,AS_HELP_STRING([--with-apple-applications-dir=PATH],
[Path to the Applications directory (default: /Applications/Utilities)]),
- [ APPLE_APPLICATIONS_DIR="${withval}" ],
- [
APPLE_APPLICATIONS_DIR="/Applications/Utilities" ])
+ [
APPLE_APPLICATIONS_DIR='$(DESTDIR)'"${withval}" ],
+ [
APPLE_APPLICATIONS_DIR='$(DESTDIR)'"/Applications/Utilities" ])
AC_SUBST([APPLE_APPLICATIONS_DIR])
AC_ARG_WITH(apple-application-name,AS_HELP_STRING([--with-apple-application-name=NAME],
[Name for the .app (default: X11)]),
[ APPLE_APPLICATION_NAME="${withval}" ],
diff --git a/hw/xquartz/bundle/Makefile.am b/hw/xquartz/bundle/Makefile.am
index 424a7475f063..c8d29e6718c0 100644
--- a/hw/xquartz/bundle/Makefile.am
+++ b/hw/xquartz/bundle/Makefile.am
@@ -11,12 +11,12 @@ CPP_FILES_FLAGS += -DXQUARTZ_SPARKLE
-DXQUARTZ_SPARKLE_FEED_URL="$(XQUARTZ_SPARK
endif
install-data-hook:
- $(srcdir)/mk_bundke.sh $(srcdir) $(builddir)
$(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app install
+ $(srcdir)/mk_bundke.sh $(srcdir) $(builddir)
$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app install
uninstall-hook:
- $(RM) -rf
$(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Resources
- $(RM) -rf
$(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Info.plist
- $(RM) -rf
$(DESTDIR)$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/PkgInfo
+ $(RM) -rf
$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Resources
+ $(RM) -rf
$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/Info.plist
+ $(RM) -rf
$(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/PkgInfo
noinst_PRE = Info.plist.cpp
noinst_DATA = $(noinst_PRE:plist.cpp=plist)
--
2.9.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
[PATCH v2 xserver 7/7] configure.ac: use automake option subdir-objects
Both fixes "source file is in a subdirectory" autoreconf warnings and ensures automake 2.0 (future) compatibility. Dummy source files that only #include the real one are so that every dir has its own source, and, therefore, does not reuse compilation results of another (objects are now put where the source is, not the makefile), thus retaining the CFLAGS and other settings as before. Explicitly distribute hw/xfree86/os-support/shared/, as other dirs now wouldn't do that implicitly by referencing source files from it. Signed-off-by: Mihail Konev --- v2: fix empty line in hw/kdrive/src/minintext.include.c .gitignore| 1 + configure.ac | 2 +- hw/dmx/Makefile.am| 4 ++-- hw/dmx/config/Makefile.am | 4 ++-- hw/dmx/config/dmxlog.include.c| 1 + hw/dmx/config/strlcpy.include.c | 1 + hw/dmx/miinitext.include.c| 1 + hw/dmx/panoramiX.include.c| 1 + hw/kdrive/src/Makefile.am | 2 +- hw/kdrive/src/miinitext.include.c | 1 + hw/vfb/Makefile.am| 2 +- hw/vfb/miinitext.include.c| 1 + hw/xfree86/dixmods/Makefile.am| 2 +- hw/xfree86/dixmods/miinitext.include.c| 1 + hw/xfree86/glamor_egl/Makefile.am | 4 ++-- hw/xfree86/glamor_egl/glamor_egl.include.c| 1 + hw/xfree86/glamor_egl/glamor_eglmodule.include.c | 1 + hw/xfree86/int10/Makefile.am | 4 ++-- hw/xfree86/int10/linux.include.c | 1 + hw/xfree86/int10/linux_vm86.include.c | 1 + hw/xfree86/os-support/Makefile.am | 14 +- hw/xfree86/os-support/bsd/Makefile.am | 20 ++-- hw/xfree86/os-support/bsd/agp_noop.include.c | 1 + hw/xfree86/os-support/bsd/ioperm_noop.include.c | 1 + hw/xfree86/os-support/bsd/kmod_noop.include.c | 1 + hw/xfree86/os-support/bsd/lnx_agp.include.c | 1 + hw/xfree86/os-support/bsd/pm_noop.include.c | 1 + hw/xfree86/os-support/bsd/posix_tty.include.c | 1 + hw/xfree86/os-support/bsd/sigio.include.c | 1 + hw/xfree86/os-support/bsd/vidmem.include.c| 1 + hw/xfree86/os-support/hurd/Makefile.am| 14 +++--- hw/xfree86/os-support/hurd/VTsw_noop.include.c| 1 + hw/xfree86/os-support/hurd/agp_noop.include.c | 1 + hw/xfree86/os-support/hurd/kmod_noop.include.c| 1 + hw/xfree86/os-support/hurd/pm_noop.include.c | 1 + hw/xfree86/os-support/hurd/posix_tty.include.c| 1 + hw/xfree86/os-support/hurd/sigiostubs.include.c | 1 + hw/xfree86/os-support/hurd/vidmem.include.c | 1 + hw/xfree86/os-support/linux/Makefile.am | 8 hw/xfree86/os-support/linux/VTsw_usl.include.c| 1 + hw/xfree86/os-support/linux/posix_tty.include.c | 1 + hw/xfree86/os-support/linux/sigio.include.c | 1 + hw/xfree86/os-support/linux/vidmem.include.c | 1 + hw/xfree86/os-support/solaris/Makefile.am | 12 ++-- hw/xfree86/os-support/solaris/VTsw_noop.include.c | 1 + hw/xfree86/os-support/solaris/agp_noop.include.c | 1 + hw/xfree86/os-support/solaris/kmod_noop.include.c | 1 + hw/xfree86/os-support/solaris/posix_tty.include.c | 1 + hw/xfree86/os-support/solaris/sigio.include.c | 1 + hw/xfree86/os-support/solaris/vidmem.include.c| 1 + hw/xfree86/os-support/stub/Makefile.am| 16 hw/xfree86/os-support/stub/VTsw_noop.include.c| 1 + hw/xfree86/os-support/stub/agp_noop.include.c | 1 + hw/xfree86/os-support/stub/ioperm_noop.include.c | 1 + hw/xfree86/os-support/stub/kmod_noop.include.c| 1 + hw/xfree86/os-support/stub/pm_noop.include.c | 1 + hw/xfree86/os-support/stub/posix_tty.include.c| 1 + hw/xfree86/os-support/stub/sigio.include.c| 1 + hw/xfree86/os-support/stub/vidmem.include.c | 1 + hw/xfree86/utils/cvt/Makefile.am | 4 ++-- hw/xfree86/utils/cvt/xf86cvt.include.c| 1 + hw/xfree86/utils/cvt/xprintf.include.c| 1 + hw/xnest/Makefile.am | 2 +- hw/xnest/miinitext.include.c | 1 + hw/xquartz/Makefile.am| 2 +- hw/xquartz/mach-startup/Makefile.am | 2 +- hw/xquartz/mach-startup/strndup.include.c | 1 + hw/xquartz/miinitext.include.c| 1 + hw/xwayland/Makefile.am | 6 +++--- hw/xwayland/dpmsstubs.include.c | 1 + hw/xwayland/miinitext.include.c | 1 + hw/xwayland/stubs.include.c | 1 + hw/xwin/Makefile.am | 2 +- hw/xwin/miinitext.include.c
[PATCH v2 xserver 0/7] Minor build system corrections
v2 (Emil Velikov): 2/7: Figure out what exactly happens. 3/7: Add missing ifdef. 5/7: Move DESTDIR to configure. Add missing Cc. 1-5/7: Reword. The 7/7 has also been suggested to use "ln -s". Kept unchanged since: - It is simpler than https://lists.x.org/archives/xorg-devel/2017-February/052761.html No need to SUFFIXES, CLEANFILES, or -include in every makefile. - Compiler errors are acceptable: CC posix_tty.include.lo In file included from posix_tty.include.c:1:0: ../shared/posix_tty.c: In function `GetBaud': ../shared/posix_tty.c:110:9: error: `rturn' undeclared (first use in this function) rturn B460800; ^ ../shared/posix_tty.c:110:9: note: each undeclared identifier is reported only once for each function it appears in In file included from /usr/include/termios.h:39:0, from ../../../../hw/xfree86/os-support/xf86_OSlib.h:186, from ../shared/posix_tty.c:63, from posix_tty.include.c:1: ../shared/posix_tty.c:110:15: error: expected `;' before numeric constant rturn B460800; ^ Makefile:670: recipe for target 'posix_tty.include.lo' failed make: *** [posix_tty.include.lo] Error 1 Mihail Konev (7): configure.ac: only stub sdksyms.dep as needed sdksyms: fix typo in export keyword index hw/xfree86: add suid wrapper to uninstall target configure.ac: add missing xquartz destdir hw/xquartz: fix path to pseudoramiX headers os-support/solaris: add asm to gitignore configure.ac: use automake option subdir-objects .gitignore| 1 + configure.ac | 10 ++ hw/dmx/Makefile.am| 4 ++-- hw/dmx/config/Makefile.am | 4 ++-- hw/dmx/config/dmxlog.include.c| 1 + hw/dmx/config/strlcpy.include.c | 1 + hw/dmx/miinitext.include.c| 1 + hw/dmx/panoramiX.include.c| 1 + hw/kdrive/src/Makefile.am | 2 +- hw/kdrive/src/miinitext.include.c | 1 + hw/vfb/Makefile.am| 2 +- hw/vfb/miinitext.include.c| 1 + hw/xfree86/Makefile.am| 3 +++ hw/xfree86/dixmods/Makefile.am| 2 +- hw/xfree86/dixmods/miinitext.include.c| 1 + hw/xfree86/glamor_egl/Makefile.am | 4 ++-- hw/xfree86/glamor_egl/glamor_egl.include.c| 1 + hw/xfree86/glamor_egl/glamor_eglmodule.include.c | 1 + hw/xfree86/int10/Makefile.am | 4 ++-- hw/xfree86/int10/linux.include.c | 1 + hw/xfree86/int10/linux_vm86.include.c | 1 + hw/xfree86/os-support/Makefile.am | 14 +- hw/xfree86/os-support/bsd/Makefile.am | 20 ++-- hw/xfree86/os-support/bsd/agp_noop.include.c | 1 + hw/xfree86/os-support/bsd/ioperm_noop.include.c | 1 + hw/xfree86/os-support/bsd/kmod_noop.include.c | 1 + hw/xfree86/os-support/bsd/lnx_agp.include.c | 1 + hw/xfree86/os-support/bsd/pm_noop.include.c | 1 + hw/xfree86/os-support/bsd/posix_tty.include.c | 1 + hw/xfree86/os-support/bsd/sigio.include.c | 1 + hw/xfree86/os-support/bsd/vidmem.include.c| 1 + hw/xfree86/os-support/hurd/Makefile.am| 14 +++--- hw/xfree86/os-support/hurd/VTsw_noop.include.c| 1 + hw/xfree86/os-support/hurd/agp_noop.include.c | 1 + hw/xfree86/os-support/hurd/kmod_noop.include.c| 1 + hw/xfree86/os-support/hurd/pm_noop.include.c | 1 + hw/xfree86/os-support/hurd/posix_tty.include.c| 1 + hw/xfree86/os-support/hurd/sigiostubs.include.c | 1 + hw/xfree86/os-support/hurd/vidmem.include.c | 1 + hw/xfree86/os-support/linux/Makefile.am | 8 hw/xfree86/os-support/linux/VTsw_usl.include.c| 1 + hw/xfree86/os-support/linux/posix_tty.include.c | 1 + hw/xfree86/os-support/linux/sigio.include.c | 1 + hw/xfree86/os-support/linux/vidmem.include.c | 1 + hw/xfree86/os-support/solaris/.gitignore | 1 + hw/xfree86/os-support/solaris/Makefile.am | 12 ++-- hw/xfree86/os-support/solaris/VTsw_noop.include.c | 1 + hw/xfree86/os-support/solaris/agp_noop.include.c | 1 + hw/xfree86/os-support/solaris/kmod_noop.include.c | 1 + hw/xfree86/os-support/solaris/posix_tty.include.c | 1 + hw/xfree86/os-support/solaris/sigio.include.c | 1 + hw/xfree86/os-support/solaris/vidmem.include.c| 1 + hw/xfree86/os-support/stub/Makefile.am| 16 hw/xfree86/os-support/stub/VTsw_noop.include.c| 1 + hw/xfree86/os-support/stub/agp_noop.include.c | 1 + hw/xfree86/os-support/stub/ioperm_noop.include.c | 1 + hw/xfree86/os-support/stub/kmod_noop.include.c
[PATCH v2 xserver 2/7] sdksyms: fix typo in export keyword index
In headers, the symbols exported from Xorg are declared as
"extern _X_EXPORT type name [...]".
In 3dad57b1 ("sdksyms: Tighten up the symbols we add to the magic table"),
a check has been inserted that ensures the word at the index matches the
_X_EXPORT expansion.
With GCC 5, the "skip line numbers" loop will reassign the index, and
the check works as intended.
With GCC 4 and below, for declarations having the type on the same line
as "extern" (most of them), the initial index is off by one, the check
will look at the type instead, never pass, and the build breaks.
Fixes: b1dac41f ('Use libtool convenience libraries and better "symbol" table')
Signed-off-by: Mihail Konev
---
v2: Figure out what exactly happens. Reword.
hw/xfree86/sdksyms.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index 767ce2181d5f..0139a5077516 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -348,7 +348,7 @@ BEGIN {
/^extern[ ]/ {
if (sdk) {
- n = 3;
+ n = 2;
# skip line numbers GCC 5 adds before __attribute__
while ($n == "" || $0 ~ /^# [0-9]+ "/) {
--
2.9.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
[PATCH v2 xserver 6/7] os-support/solaris: add asm to gitignore
Signed-off-by: Mihail Konev --- hw/xfree86/os-support/solaris/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 hw/xfree86/os-support/solaris/.gitignore diff --git a/hw/xfree86/os-support/solaris/.gitignore b/hw/xfree86/os-support/solaris/.gitignore new file mode 100644 index ..00a2f5d91aeb --- /dev/null +++ b/hw/xfree86/os-support/solaris/.gitignore @@ -0,0 +1 @@ +solaris-*.il -- 2.9.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
[PATCH v2 xserver 3/7] hw/xfree86: add suid wrapper to uninstall target
Fixes --enable-suid-wrapper distcheck. Signed-off-by: Mihail Konev --- v2: Add missing ifdef. Reword. hw/xfree86/Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am index 85bd0bed0e58..9e1b58485764 100644 --- a/hw/xfree86/Makefile.am +++ b/hw/xfree86/Makefile.am @@ -120,6 +120,9 @@ endif uninstall-hook: $(AM_V_at)rm -f $(DESTDIR)$(bindir)/X +if SUID_WRAPPER + $(AM_V_at)rm -f $(DESTDIR)$(SUID_WRAPPER_DIR)/Xorg +endif # Use variables from XORG_MANPAGE_SECTIONS and X Server configuration # Do not include manpages.am as values are not appropriate for rc files -- 2.9.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
[PATCH v2 xserver 5/7] hw/xquartz: fix path to pseudoramiX headers
Fixes out-of-source XQuartz build.
Fixes: 39c548da ("XQuartz: Fix build with moved pseudoramiX")
Signed-off-by: Mihail Konev
---
v2: Reword. Add missing Cc.
hw/xquartz/Makefile.am | 2 +-
hw/xquartz/xpr/Makefile.am | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xquartz/Makefile.am b/hw/xquartz/Makefile.am
index 4da896d76173..5ccbe48917bc 100644
--- a/hw/xquartz/Makefile.am
+++ b/hw/xquartz/Makefile.am
@@ -8,7 +8,7 @@ AM_CPPFLAGS = \
-DUSE_NEW_CLUT \
-DXFree86Server \
-I$(top_srcdir)/miext/rootless \
- -I$(top_builddir)/pseudoramiX \
+ -I$(top_srcdir)/pseudoramiX \
-DX11LIBDIR=\"$(libdir)\"
if GLX
diff --git a/hw/xquartz/xpr/Makefile.am b/hw/xquartz/xpr/Makefile.am
index c654ee595cb9..e4b138617805 100644
--- a/hw/xquartz/xpr/Makefile.am
+++ b/hw/xquartz/xpr/Makefile.am
@@ -3,7 +3,7 @@ noinst_LTLIBRARIES = libXquartzXpr.la
AM_CFLAGS = $(DIX_CFLAGS)
AM_CPPFLAGS = \
-I$(srcdir) -I$(srcdir)/.. \
- -I$(top_builddir)/pseudoramiX \
+ -I$(top_srcdir)/pseudoramiX \
-I$(top_srcdir)/miext \
-I$(top_srcdir)/miext/rootless
--
2.9.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
[PATCH libXdmcp v2] Use getentropy() if arc4random_buf() is not available
This allows to fix CVE-2017-2625 on Linux platforms without pulling in
libbsd.
The libc getentropy() is available since glibc 2.25 but also on OpenBSD.
For Linux, we need at least a v3.17 kernel. If the recommended
arc4random_buf() function is not available, emulate it by first trying
to use getentropy() on a supported glibc and kernel. If the call fails,
fall back to the current (vulnerable) code.
Signed-off-by: Benjamin Tissoires
---
changes in v2:
- use the getentropy() from glibc, not the plain syscall
- make it clear that arc4random_buf() should be preferred and that we
are only adding band-aids on top of the missing function
---
Key.c| 31 ++-
configure.ac | 2 +-
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/Key.c b/Key.c
index a09b316..70607d0 100644
--- a/Key.c
+++ b/Key.c
@@ -62,10 +62,11 @@ getbits (long data, unsigned char *dst)
#define getpid(x) _getpid(x)
#endif
-void
-XdmcpGenerateKey (XdmAuthKeyPtr key)
-{
#ifndef HAVE_ARC4RANDOM_BUF
+
+static void
+emulate_getrandom_buf (char *auth, int len)
+{
longlowbits, highbits;
srandom ((int)getpid() ^ time((Time_t *)0));
@@ -73,9 +74,29 @@ XdmcpGenerateKey (XdmAuthKeyPtr key)
highbits = random ();
getbits (lowbits, key->data);
getbits (highbits, key->data + 4);
-#else
+}
+
+static void
+arc4random_buf (void *auth, int len)
+{
+intret;
+
+#if HAVE_GETENTROPY
+/* weak emulation of arc4random through the getentropy libc call */
+ret = getentropy (auth, len);
+if (ret == 0)
+ return;
+#endif /* HAVE_GETENTROPY */
+
+emulate_getrandom_buf (auth, len);
+}
+
+#endif /* !defined(HAVE_ARC4RANDOM_BUF) */
+
+void
+XdmcpGenerateKey (XdmAuthKeyPtr key)
+{
arc4random_buf(key->data, 8);
-#endif
}
int
diff --git a/configure.ac b/configure.ac
index 2288502..d2b045d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -65,7 +65,7 @@ esac
# Checks for library functions.
AC_CHECK_LIB([bsd], [arc4random_buf])
-AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf])
+AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf getentropy])
# Obtain compiler/linker options for depedencies
PKG_CHECK_MODULES(XDMCP, xproto)
--
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 libICE v2] Use getentropy() if arc4random_buf() is not available
This allows to fix CVE-2017-2626 on Linux platforms without pulling in
libbsd.
The libc getentropy() is available since glibc 2.25 but also on OpenBSD.
For Linux, we need at least a v3.17 kernel. If the recommended
arc4random_buf() function is not available, emulate it by first trying
to use getentropy() on a supported glibc and kernel. If the call fails,
fall back to the current (partly vulnerable) code.
Signed-off-by: Benjamin Tissoires
---
changes in v2:
- use the getentropy() from glibc, not the plain syscall
- make it clear that arc4random_buf() should be preferred and that we
are only adding band-aids on top of the missing function
---
configure.ac | 2 +-
src/iceauth.c | 65 ++-
2 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/configure.ac b/configure.ac
index 458882a..c971ab6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,7 +38,7 @@ AC_DEFINE(ICE_t, 1, [Xtrans transport type])
# Checks for library functions.
AC_CHECK_LIB([bsd], [arc4random_buf])
-AC_CHECK_FUNCS([asprintf arc4random_buf])
+AC_CHECK_FUNCS([asprintf arc4random_buf getentropy])
# Allow checking code with lint, sparse, etc.
XORG_WITH_LINT
diff --git a/src/iceauth.c b/src/iceauth.c
index ed31683..de4785b 100644
--- a/src/iceauth.c
+++ b/src/iceauth.c
@@ -44,31 +44,19 @@ Author: Ralph Mor, X Consortium
static int was_called_state;
-/*
- * MIT-MAGIC-COOKIE-1 is a sample authentication method implemented by
- * the SI. It is not part of standard ICElib.
- */
+#ifndef HAVE_ARC4RANDOM_BUF
-
-char *
-IceGenerateMagicCookie (
+static void
+emulate_getrandom_buf (
+ char *auth,
int len
)
{
-char*auth;
-#ifndef HAVE_ARC4RANDOM_BUF
longldata[2];
intseed;
intvalue;
inti;
-#endif
-if ((auth = malloc (len + 1)) == NULL)
- return (NULL);
-
-#ifdef HAVE_ARC4RANDOM_BUF
-arc4random_buf(auth, len);
-#else
#ifdef ITIMER_REAL
{
struct timeval now;
@@ -76,13 +64,13 @@ IceGenerateMagicCookie (
ldata[0] = now.tv_sec;
ldata[1] = now.tv_usec;
}
-#else
+#else /* ITIMER_REAL */
{
longtime ();
ldata[0] = time ((long *) 0);
ldata[1] = getpid ();
}
-#endif
+#endif /* ITIMER_REAL */
seed = (ldata[0]) + (ldata[1] << 16);
srand (seed);
for (i = 0; i < len; i++)
@@ -90,7 +78,46 @@ IceGenerateMagicCookie (
value = rand ();
auth[i] = value & 0xff;
}
-#endif
+}
+
+static void
+arc4random_buf (
+ char *auth,
+ int len
+)
+{
+intret;
+
+#if HAVE_GETENTROPY
+/* weak emulation of arc4random through the entropy libc */
+ret = getentropy (auth, len);
+if (ret == 0)
+ return;
+#endif /* HAVE_GETENTROPY */
+
+emulate_getrandom_buf (auth, len);
+}
+
+#endif /* !defined(HAVE_ARC4RANDOM_BUF) */
+
+/*
+ * MIT-MAGIC-COOKIE-1 is a sample authentication method implemented by
+ * the SI. It is not part of standard ICElib.
+ */
+
+
+char *
+IceGenerateMagicCookie (
+ int len
+)
+{
+char*auth;
+
+if ((auth = malloc (len + 1)) == NULL)
+ return (NULL);
+
+arc4random_buf (auth, len);
+
auth[len] = '\0';
return (auth);
}
--
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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Daniel Vetter writes: > Yeah I think that's a pretty neat idea to reduce the lease complexity even > more. If the VR compositor is unhappy and wants a different mode, it can > simply nuke the lease and as for a new one. Forgot to say that :-) Not sure it changes the lease complexity, but it reduces the potential interference with the X server after the lease is created. Hrm. Thinking about the impact on X a bit more, this seems hard - you can't just display the root window in the HMD, so you need a frame buffer to use. The VR compositor can construct this knowing the planned X mode, but, we then have to wire it through the whole X mode set infrastructure, which is not exactly set up to do that. I'll go look at the code in more detail, but I suspect the easiest plan will be to have the VR compositor set its own mode. That may fail if X is consuming too many display resources, but that doesn't seem significantly different from having the lease fail. This doesn't change the kernel API at all, so we can figure out the X bits separately from the kernel bits. -- -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 libXdmcp] Use getrandom() syscall if available
> From: Benjamin Tissoires
> Date: Tue, 4 Apr 2017 11:05:47 +0200
>
> On Mon, Apr 3, 2017 at 9:17 PM, Mark Kettenis wrote:
> > OpenBSD does not have a getrandom(3) function in libc. The OpenBSD
> > postion is that the arc4random(3) family of functions is always the
> > preferred way to get proper random numbers as all the other interfaces
> > have nasty corner cases that people shouldn't have to deal with. In
> > your case for example, getrandom(2) may block and therefore could
> > return EINTR, a case which your patch doesn't handle.
>
> I see. So if arc4random_buf(3) is available, it should always be
> preferred. When it is not available, I guess I should go for
> getrandom/getentropy and probably don't care about the syscall at all.
Right. You probably shouldn't bother with getentropy() though, unless
you build a complete proper PRNG on top of it.
> > So I'd argue that from a Linux distro point of view, making sure that
> > a proper arc4random_buf(3) implementation is available would be the
> > best way to fix this vulnerability. Either by improving the version
> > provided in libbsd (feel free to take the code from libressl) or by
> > lobbying for its inclusion in glibc.
>
> TBH, the issue with the libbsd implementation is that it's not shipped
> with RHEL (where I try to provide a fix). For various reasons we do
> not ship libbsd and adding it there only for one PRNG is something
> that will be costly in term of maintenance.
More costly than pushing/maintaining patches for several other
projects?
> I don't think we ship libressl either, but the problem is not that
> much with RHEL (we can ship custom fixes if required), but more the
> fact that there is no true fix besides "use libbsd".
>
> Which is why I wanted to provide an alternative for Linux that we can
> point customers at.
>
> Regarding adding arc4random_buf(3) in glibc, I am not sure I
> personally want to go this path. It took a little bit more than 2
> years to have getrandom() in glibc, when it was pushed by far more
> knowledgeable people than me :(
I sympathize.
> > Adding more #ifdef spaghetti
> > everywhere isn't going to help.
>
> True. But the current situation where the code might be vulnerable or
> not is not a good situation either. Having a CVE out there without a
> fix is not good. Users will want it to be fixed and we can't guarantee
> that the code they are running is safe. I am not pointing fingers at
> anybody (I was not in the security discussion), I am just trying to
> justify the fact that we still need a patch that we can point people
> at.
The CVE is a bit of a joke though. The original commit to use
arc4random_buf() in libICE was made in 2013, exactly to avoid the use
of poor quality random numbers in a security-sensitive bit of code
that the CVE is about. A bit sad to see that four years there still
isn't a one-stop solution for this on Linux
> How about (in pseudo-c):
>
> ---
> #ifndef HAVE_ARC4RANDOM_BUF
> void arc4random_buf(char *auth, int len)
> {
> #if HAVE_GET_ENTROPY
> getentropy(auth, len);
> if (failed)
> #endif
> {
> /* use the older, unsafe code */
> }
> }
> #endif
>
> void
> XdmcpGenerateKey (XdmAuthKeyPtr key)
> {
> arc4random_buf(key->data, 8)
> }
>
> ---
>
> This should make the code cleaner, remove a little bit of spaghetti,
> and will allow for future libc to implement arc4random_buf in the
> missing architectures.
Agreed. That would be the best way to move forward.
___
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: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Daniel Vetter writes: > The multi-seat thing sounds like vapourware, I think we should care about > the vr use-case for now, and only that one. Ok, I can live with that, even if I like the idea of a slightly more general solution. > For VR itself I'd go as far as saying that probably our "create lease" > ioctl should have only the semantics we need to pass one crtc+primary > plane for pageflipping in a VR compositor, expressed in a flag. Yeah, we can't express planes through X anyways. I'll leave the kernel API with multiple planes as that's actually simpler than having it validate that only a single plane is in the lease. > All the details about additional corner cases are just so unclear to > me (and there's not even a clear use case that will materialize) that > I don't think having the uapi is worth it. Too close to the "I'll > regret this immediately" bucket :-) Removing the 'ChangeLease' ioctl eliminates a bunch of complexity in the code, and means I don't even have to think about sending events. I'll also go ahead and remove the ability to hide resources from the lessor. Thanks, as always, for your thoughtful review. ps -- Any thoughts on whether the X request should include the mode to use? Doing that would let us restrict the lessee from setting modes, and avoid potential resource issues with the window system. However, it would also require providing a scanout buffer in the request. -- -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 libpciaccess 1/2]: probe should not hold pci nexus drivers open
On 04/ 4/17 07:05 AM, Emil Velikov wrote: Thanks for the patches Henry. They are part of libpciaccess 0.13.5. For future patches please check with the wiki page [1] Namely: do send patches inline, to make reviewing easier. Thanks - unfortunately those patches were in the review queue so long that Henry no longer works here. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libpciaccess 1/2]: probe should not hold pci nexus drivers open
Thanks for the patches Henry. They are part of libpciaccess 0.13.5. For future patches please check with the wiki page [1] Namely: do send patches inline, to make reviewing easier. -Emil [1] https://www.x.org/wiki/Development/Documentation/SubmittingPatches/ ___ 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/2] Introduce keyboard grabbing protocol for Xwayland
On 4 April 2017 at 13:25, Olivier Fourdan wrote: > Hey Emil, > >> On 22 March 2017 at 10:33, Olivier Fourdan wrote: >> > [...] >> > Makefile.am| 2 + >> > configure.ac | 2 +- >> > unstable/xwayland-keyboard-grab/README | 4 + >> Humble question: >> Seems like close to none of the READMEs are bundled in the tarball. Is >> that intentional ? > > Aren't they? I tried a "make dist" and the README files are all included: > > $ find . -name README | wc -l > 16 > > $ make dist > $ tar tf wayland-protocols-1.?.tar.xz | grep README | wc -l > 16 > Silly me did not notice the constructs in dist_noinst_DATA Thank you for the correction. -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 1/2] Introduce keyboard grabbing protocol for Xwayland
Hey Emil, > On 22 March 2017 at 10:33, Olivier Fourdan wrote: > > [...] > > Makefile.am| 2 + > > configure.ac | 2 +- > > unstable/xwayland-keyboard-grab/README | 4 + > Humble question: > Seems like close to none of the READMEs are bundled in the tarball. Is > that intentional ? Aren't they? I tried a "make dist" and the README files are all included: $ find . -name README | wc -l 16 $ make dist $ tar tf wayland-protocols-1.?.tar.xz | grep README | wc -l 16 > > .../xwayland-keyboard-grab-unstable-v1.xml | 101 > > + > > 4 files changed, 108 insertions(+), 1 deletion(-) > > create mode 100644 unstable/xwayland-keyboard-grab/README > > create mode 100644 > > unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index e693afa..d100c13 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > [...] > > + > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > > This line should be part of the patch that introduces the file - 2/2. Oh definitely! Thanks! Olivier ___ 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/2] Introduce keyboard grabbing protocol for Xwayland
Hi Olivier On 22 March 2017 at 10:33, Olivier Fourdan wrote: > This patch introduces a new protocol for grabbing the keyboard from > Xwayland. > > This is needed for X11 applications that map an override redirect window > (ths not focused by the window manager) and issue an active grab on the > keyboard to capture all keyboard events. > > Signed-off-by: Olivier Fourdan > --- > Makefile.am| 2 + > configure.ac | 2 +- > unstable/xwayland-keyboard-grab/README | 4 + Humble question: Seems like close to none of the READMEs are bundled in the tarball. Is that intentional ? > .../xwayland-keyboard-grab-unstable-v1.xml | 101 > + > 4 files changed, 108 insertions(+), 1 deletion(-) > create mode 100644 unstable/xwayland-keyboard-grab/README > create mode 100644 > unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index e693afa..d100c13 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -12,6 +12,8 @@ unstable_protocols = > \ > unstable/tablet/tablet-unstable-v2.xml > \ > unstable/xdg-foreign/xdg-foreign-unstable-v1.xml > \ > unstable/idle-inhibit/idle-inhibit-unstable-v1.xml > \ > + > unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml \ > + > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ This line should be part of the patch that introduces the file - 2/2. Regards, 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 1/2] Introduce keyboard grabbing protocol for Xwayland
Hi
> I cannot see why this api cannot be correctly emulated using some
> wayland api that normal wayland clients can also use. Allowing X
> clients to have more rights and abilities than Wayland clients seems
> horrendously wrong.
>
> The X emulation does not have to do 1:1 translation of X11 calls into
> Wayland requests.
>
> In this case I would think an attempt to grab the keyboard would
> instead send an "activate" or "raise" or "needs attention" (that seems
> to be a popular name) request. The X client would then get keystrokes
> (possibly after some more user interaction such as clicking or of
> de-iconizing the client). Because the X11 app may not expect to lose
> the focus until the grab is lost, the X emulator would also re-request
> the focus if it is lost at any time it could, such as on mouse clicks
> or mouse enter events.
>
> I suppose the plan is that this does not actually do something that
> Wayland clients can't do, but in that case you are just moving "how to
> replicate what X does" from the X emulator into the compositor. That
> still seems wrong, since compositors may differ, making it impossible
> for the client to be rewritten to not use the X emulator but still
> have the same behavior. I would much rather see this done by the X
> emulator.
Again, even though the protocol does not specifically target override-redirect
windows, those are the main problem here, sensible X11 window managers do not
"manage" those, so setting EWMH properties such as "activate" or "demand
attention" will be ignored by most X11 window managers on O-R windows.
I have attached a simple code sample to demonstrate this - And this is not an
hypothetical issue, this is https://bugs.freedesktop.org/show_bug.cgi?id=96547
- This works fine on X11 thanks to the Xserver issuing the requested grab, it
cannot work on Xwayland because Wayland has no similar mechanism.
But if you can solve this issue reliably for all X11 window managers/Wayland
compositors in Xwayland alone without the help of any additional protocol, best
would be to send your patches for Xwayland to xorg-devel.
Cheers,
Olivier/*
* Copyright (C) 2017 Red Hat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*
* Written by:
* Olivier Fourdan
*
* Compile with :
*
* for gtk2:
* gcc -Wall -g grab.c -o grab `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0`
*
* for gtk3:
* gcc -Wall -g grab.c -o grab `pkg-config --cflags gtk+-3.0` `pkg-config --libs gtk+-3.0`
*
* To exercise Xwayland grabs, make sure to either build with gtk2 (which doesn't have a
* Wayland backend) or force the X11 backend if built with gtk3 (GDK_BACKEND=x11 ...)
*/
#include
static gboolean
on_map_event_cb (GtkWidget *widget,
GdkEvent *event,
gpointer user_data)
{
GdkWindow *gdk_window = gtk_widget_get_window (widget);
gdk_keyboard_grab (gdk_window, TRUE, GDK_CURRENT_TIME);
g_message ("Widget %p is mapped!", widget);
return FALSE;
}
static void
destroy (GtkWidget *widget, gpointer data)
{
gtk_main_quit ();
}
static gboolean
on_key_press_event (GtkWidget *widget, GdkEventKey *event, gpointer data)
{
g_message ("Key 0x%x pressed, widget %p", event->keyval, widget);
return FALSE;
}
static gboolean
on_key_release_event (GtkWidget *widget, GdkEventKey *event, gpointer data)
{
g_message ("Key 0x%x released, widget %p", event->keyval, widget);
return FALSE;
}
int
main (int argc, char *argv[])
{
GtkWidget *window1;
GtkWidget *button;
GtkWidget *vbox;
GtkWidget *label;
GtkWidget *entry;
gchar* str;
gtk_init (&argc, &argv);
/* Popup window (override redirect on X11) */
window1 = gtk_window_new (GTK_WINDOW_POPUP);
gtk_window_set_keep_above (GTK_WINDOW (window1), TRUE);
gtk_window_set_position (GTK_WINDOW (window1), GTK_WIN_POS_CENTER_ALWAYS);
gtk_container_set_border_width (GTK_CONTAINER (window1), 25);
g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (destroy), NULL);
g_signal_connect (G_OBJECT (window1), "map-event", G_CALLBACK (on_map_event_cb), NULL);
vbox = gtk_vbox_new (FALSE, 10);
gtk_container_add (GTK_CONTAINER (window1), vbox);
label = gtk_label_new (NULL);
gtk_label_set_use_markup (GTK_LABEL (label), TRUE);
str =
[PATCH] fb: Remove screen extents check, fix GetImage/GetSpans on Xwayland.
Screenshotting is currently broken when using Xwayland’s non-GLAMOR
code path headless, due to the screen extents being unknown and thus
initialised to zero.
This patch doesn’t seem to introduce any regression on GetImage when
using e.g. the modesetting DDX and switching away to another VT,
contrary to what the comment was saying, but I would welcome a more
experienced pair of eyes for that.
---
fb/fb.h | 12
fb/fbgetsp.c | 7 ---
fb/fbimage.c | 7 ---
3 files changed, 26 deletions(-)
diff --git a/fb/fb.h b/fb/fb.h
index 7d1e443dd..194c5efed 100644
--- a/fb/fb.h
+++ b/fb/fb.h
@@ -488,18 +488,6 @@ typedef struct {
fbGetPixmapStipData(_pPix, pointer, stride, bpp);
\
}
-/*
- * XFree86 empties the root BorderClip when the VT is inactive,
- * here's a macro which uses that to disable GetImage and GetSpans
- */
-
-#define fbWindowEnabled(pWin) \
-RegionNotEmpty(&(pWin)->drawable.pScreen->root->borderClip)
-
-#define fbDrawableEnabled(pDrawable) \
-((pDrawable)->type == DRAWABLE_PIXMAP ? \
- TRUE : fbWindowEnabled((WindowPtr) pDrawable))
-
#define FbPowerOfTwo(w)(((w) & ((w) - 1)) == 0)
/*
* Accelerated tiles are power of 2 width <= FB_UNIT
diff --git a/fb/fbgetsp.c b/fb/fbgetsp.c
index 445a4e385..149b82ab0 100644
--- a/fb/fbgetsp.c
+++ b/fb/fbgetsp.c
@@ -37,13 +37,6 @@ fbGetSpans(DrawablePtr pDrawable,
int srcXoff, srcYoff;
int xoff;
-/*
- * XFree86 DDX empties the root borderClip when the VT is
- * switched away; this checks for that case
- */
-if (!fbDrawableEnabled(pDrawable))
-return;
-
fbGetDrawable(pDrawable, src, srcStride, srcBpp, srcXoff, srcYoff);
while (nspans--) {
diff --git a/fb/fbimage.c b/fb/fbimage.c
index bd24728fd..d49d6dc44 100644
--- a/fb/fbimage.c
+++ b/fb/fbimage.c
@@ -215,13 +215,6 @@ fbGetImage(DrawablePtr pDrawable,
FbStip *dst;
FbStride dstStride;
-/*
- * XFree86 DDX empties the root borderClip when the VT is
- * switched away; this checks for that case
- */
-if (!fbDrawableEnabled(pDrawable))
-return;
-
fbGetDrawable(pDrawable, src, srcStride, srcBpp, srcXoff, srcYoff);
x += pDrawable->x;
--
2.12.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
Re: [PATCH libXdmcp] Use getrandom() syscall if available
On Mon, Apr 3, 2017 at 9:17 PM, Mark Kettenis wrote:
> OpenBSD does not have a getrandom(3) function in libc. The OpenBSD
> postion is that the arc4random(3) family of functions is always the
> preferred way to get proper random numbers as all the other interfaces
> have nasty corner cases that people shouldn't have to deal with. In
> your case for example, getrandom(2) may block and therefore could
> return EINTR, a case which your patch doesn't handle.
I see. So if arc4random_buf(3) is available, it should always be
preferred. When it is not available, I guess I should go for
getrandom/getentropy and probably don't care about the syscall at all.
>
> So I'd argue that from a Linux distro point of view, making sure that
> a proper arc4random_buf(3) implementation is available would be the
> best way to fix this vulnerability. Either by improving the version
> provided in libbsd (feel free to take the code from libressl) or by
> lobbying for its inclusion in glibc.
TBH, the issue with the libbsd implementation is that it's not shipped
with RHEL (where I try to provide a fix). For various reasons we do
not ship libbsd and adding it there only for one PRNG is something
that will be costly in term of maintenance.
I don't think we ship libressl either, but the problem is not that
much with RHEL (we can ship custom fixes if required), but more the
fact that there is no true fix besides "use libbsd".
Which is why I wanted to provide an alternative for Linux that we can
point customers at.
Regarding adding arc4random_buf(3) in glibc, I am not sure I
personally want to go this path. It took a little bit more than 2
years to have getrandom() in glibc, when it was pushed by far more
knowledgeable people than me :(
> Adding more #ifdef spaghetti
> everywhere isn't going to help.
True. But the current situation where the code might be vulnerable or
not is not a good situation either. Having a CVE out there without a
fix is not good. Users will want it to be fixed and we can't guarantee
that the code they are running is safe. I am not pointing fingers at
anybody (I was not in the security discussion), I am just trying to
justify the fact that we still need a patch that we can point people
at.
How about (in pseudo-c):
---
#ifndef HAVE_ARC4RANDOM_BUF
void arc4random_buf(char *auth, int len)
{
#if HAVE_GET_ENTROPY
getentropy(auth, len);
if (failed)
#endif
{
/* use the older, unsafe code */
}
}
#endif
void
XdmcpGenerateKey (XdmAuthKeyPtr key)
{
arc4random_buf(key->data, 8)
}
---
This should make the code cleaner, remove a little bit of spaghetti,
and will allow for future libc to implement arc4random_buf in the
missing architectures.
Cheers,
Benjamin
>
> Cheers,
>
> Mark
>
>> >> diff --git a/configure.ac b/configure.ac
>> >> index 2288502..d0d4d05 100644
>> >> --- a/configure.ac
>> >> +++ b/configure.ac
>> >> @@ -63,6 +63,9 @@ case $host_os in
>> >> ;;
>> >> esac
>> >>
>> >> +# Checks for syscalls
>> >> +AC_CHECK_DECLS([SYS_getrandom], [], [], [[#include ]])
>> >> +
>> >> # Checks for library functions.
>> >> AC_CHECK_LIB([bsd], [arc4random_buf])
>> >> AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf])
>> >>
>> >
>> > Could you move that check up into the case $host_os section above it
>> > under a new case for *linux* perhaps?
>>
>> Sure.
>>
>> Cheers,
>> Benjamin
>> ___
>> 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 libXdmcp] Use getrandom() syscall if available
On Mon, Apr 3, 2017 at 9:27 PM, Alan Coopersmith wrote: > On 04/ 3/17 12:17 PM, Mark Kettenis wrote: >>> >>> From: Benjamin Tissoires >>> Date: Mon, 3 Apr 2017 17:52:32 +0200 >>> >>> On Mon, Apr 3, 2017 at 4:02 PM, Alan Coopersmith >>> wrote: On 04/ 3/17 05:52 AM, Benjamin Tissoires wrote: > > > This allows to fix CVE-2017-2625 on Linux platforms without pulling in > libbsd. > The syscall getrandom is available since kernel v3.17. The code first > tries to use the syscall on a supported kernel. If the syscall fails, > it falls back to the current (vulnerable) code. > We do not implement the glibc getrandom() call given that it's only > available in glibc 2.25, and the #if dance is already messy here. > > Signed-off-by: Benjamin Tissoires This is dangerous - Solaris defines SYS_getrandom, but I don't know if our syscall arguments/semantics are the same, and we only support applications calling the libc getrandom() function, not the raw syscall. >> >> >> Doesn't Solaris have a proper arc4random_buf(3) in libc now though? > > > Yes - and if that was preferred over the raw syscall it would help, > but this patch looked like it always went to the syscall first, then > fell back to arc4random_buf. (The similar patch for libICE appears > to be the other way around, which is better, only making the syscall > if HAVE_ARC4RANDOM_BUF isn't defined.) > > Or did I misread it? > Well, I guess the current #ifdef/#ifndef doesn't help, but if Solaris has arc4random_buf(3), it should only be used with this patch as well. I can also extract the same helpers than the libICE patch to clarify the situation, but the idea was indeed to first rely on arc4random_buf(3) if available. If it is not available at compile time, we would use the syscall and then fallback on the unsafe PRNG. I'll come up with a better patch. Cheers, Benjamin ___ 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
