[PATCH] arch: Fix image and bitmap byte order for ppc64le
From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h index 11f6c10..360b701 100644 --- a/include/servermd.h +++ b/include/servermd.h @@ -114,8 +114,13 @@ SOFTWARE. #if defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) -#define IMAGE_BYTE_ORDERMSBFirst -#define BITMAP_BIT_ORDERMSBFirst +# if defined(__BIG_ENDIAN__) +# define IMAGE_BYTE_ORDER MSBFirst +# define BITMAP_BIT_ORDER MSBFirst +# else +# define IMAGE_BYTE_ORDER LSBFirst +# define BITMAP_BIT_ORDER LSBFirst +# endif #define GLYPHPADBYTES 4 #endif /* PowerPC */ -- 1.8.4.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] arch: Fix image and bitmap byte order for ppc64le
X-Original-To: xorg-devel@lists.x.org From: Egbert Eich e...@freedesktop.org Date: Mon, 24 Feb 2014 10:57:23 +0100 From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Isn't it safer to revert the logic? I'm not sure all compilers/platforms define __BIG_ENDIAN__ when appropriate, and in that case existing working PowerPC platforms will get the wrong byte orders. So something like: #if defined(__LITTLE_ENDIAN__) #define IMAGE_BYTE_ORDER LSBFirst #define BITMAP_BIT_ORDER LSBFirst #else #define IMAGE_BYTE_ORDER MSBFirst #define BITMAP_BIT_ORDER MSBFirst #endif Also, the way you changed the indentation makes it inconsistent with what's already in the file. Cheers, Mark Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h index 11f6c10..360b701 100644 --- a/include/servermd.h +++ b/include/servermd.h @@ -114,8 +114,13 @@ SOFTWARE. #if defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) -#define IMAGE_BYTE_ORDERMSBFirst -#define BITMAP_BIT_ORDERMSBFirst +# if defined(__BIG_ENDIAN__) +# define IMAGE_BYTE_ORDER MSBFirst +# define BITMAP_BIT_ORDER MSBFirst +# else +# define IMAGE_BYTE_ORDER LSBFirst +# define BITMAP_BIT_ORDER LSBFirst +# endif #define GLYPHPADBYTES 4 #endif /* PowerPC */ -- 1.8.4.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2] arch: Fix image and bitmap byte order for ppc64le
From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h index 11f6c10..256d84b 100644 --- a/include/servermd.h +++ b/include/servermd.h @@ -114,8 +114,13 @@ SOFTWARE. #if defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) -#define IMAGE_BYTE_ORDERMSBFirst -#define BITMAP_BIT_ORDERMSBFirst +#if defined(__LITTLE_ENDIAN__) +#define IMAGE_BYTE_ORDER LSBFirst +#define BITMAP_BIT_ORDER LSBFirst +#else +#define IMAGE_BYTE_ORDER MSBFirst +#define BITMAP_BIT_ORDER MSBFirst +#endif #define GLYPHPADBYTES 4 #endif /* PowerPC */ -- 1.8.4.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 0/2] Build Xi and DPMS stubs as convenience libraries
On 03/11/2011 14:27, Jon TURNEY wrote: Build Xi and DPMS stubs as convenience libraries, rather than once for each DDX which wants to use them. The tangled history of fbcmap_mi.c is a little hard to unweave, but I suspect that can be put back into libfb. Unfortunately, miinitext.c is a much harder nut to crack. Update for master. Since commit 84e8de1271bb11b5b4b9747ae4647f47333a8ab7 fbcmap.c doesn't exist anymore and fbcmap_mi.c is used everywhere [1], so presumably that could be put back into libfb/libwfb now? [1] https://bugs.freedesktop.org/show_bug.cgi?id=5436 Jon TURNEY (2): Build dpmsstubs.c once as a convenience library, rather than once for each DDX which wants to use it Build Xi/stubs.c once as a convenience library, rather than once for each DDX which wants to use it Xext/Makefile.am | 4 +++- Xi/Makefile.am | 5 +++-- hw/vfb/Makefile.am | 6 +++--- hw/xnest/Makefile.am | 6 +++--- hw/xwin/Makefile.am | 8 test/Makefile.am | 6 +++--- 6 files changed, 19 insertions(+), 16 deletions(-) -- 1.8.3.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] Build Xi/stubs.c once as a convenience library, rather than once for each DDX which wants to use it
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- Xi/Makefile.am | 5 +++-- hw/vfb/Makefile.am | 4 ++-- hw/xnest/Makefile.am | 4 ++-- hw/xwin/Makefile.am | 4 ++-- test/Makefile.am | 4 ++-- 5 files changed, 11 insertions(+), 10 deletions(-) diff --git a/Xi/Makefile.am b/Xi/Makefile.am index af85bd0..6c456c4 100644 --- a/Xi/Makefile.am +++ b/Xi/Makefile.am @@ -1,4 +1,4 @@ -noinst_LTLIBRARIES = libXi.la +noinst_LTLIBRARIES = libXi.la libXistubs.la AM_CFLAGS = $(DIX_CFLAGS) @@ -107,4 +107,5 @@ libXi_la_SOURCES = \ xiwarppointer.c \ xiwarppointer.h -EXTRA_DIST = stubs.c +libXistubs_la_SOURCES =\ + stubs.c diff --git a/hw/vfb/Makefile.am b/hw/vfb/Makefile.am index c9f6957..a02a438 100644 --- a/hw/vfb/Makefile.am +++ b/hw/vfb/Makefile.am @@ -9,7 +9,6 @@ AM_CFLAGS = -DHAVE_DIX_CONFIG_H \ SRCS = InitInput.c \ InitOutput.c \ - $(top_srcdir)/Xi/stubs.c \ $(top_srcdir)/mi/miinitext.c libfbcmap_a_CFLAGS = $(AM_CFLAGS) @@ -22,7 +21,8 @@ XVFB_LIBS = \ libfbcmap.a \ $(MAIN_LIB) \ $(XSERVER_LIBS) \ - $(top_builddir)/Xext/libXextdpmsstubs.la + $(top_builddir)/Xext/libXextdpmsstubs.la \ + $(top_builddir)/Xi/libXistubs.la Xvfb_LDADD = $(XVFB_LIBS) $(XVFB_SYS_LIBS) $(XSERVER_SYS_LIBS) Xvfb_DEPENDENCIES = $(XVFB_LIBS) diff --git a/hw/xnest/Makefile.am b/hw/xnest/Makefile.am index c5560fd..bb8d3d8 100644 --- a/hw/xnest/Makefile.am +++ b/hw/xnest/Makefile.am @@ -42,7 +42,6 @@ SRCS =Args.c \ XNPixmap.h \ XNWindow.h \ xnest-config.h \ - $(top_srcdir)/Xi/stubs.c \ $(top_srcdir)/mi/miinitext.c libfbcmap_a_SOURCES = $(top_srcdir)/fb/fbcmap_mi.c @@ -51,7 +50,8 @@ libfbcmap_a_CFLAGS = $(AM_CFLAGS) XNEST_LIBS = \ @XNEST_LIBS@ \ libfbcmap.a \ - $(top_builddir)/Xext/libXextdpmsstubs.la + $(top_builddir)/Xext/libXextdpmsstubs.la \ + $(top_builddir)/Xi/libXistubs.la Xnest_SOURCES = $(SRCS) diff --git a/hw/xwin/Makefile.am b/hw/xwin/Makefile.am index 6668045..b0da704 100644 --- a/hw/xwin/Makefile.am +++ b/hw/xwin/Makefile.am @@ -127,7 +127,6 @@ SRCS = InitInput.c \ winresource.h \ winwindow.h \ XWin.rc \ - $(top_srcdir)/Xi/stubs.c \ $(top_srcdir)/mi/miinitext.c \ $(top_srcdir)/fb/fbcmap_mi.c \ $(SRCS_CLIPBOARD) \ @@ -153,7 +152,8 @@ AM_CPPFLAGS = -I$(top_srcdir)/miext/rootless XWIN_SYS_LIBS += -ldxguid XWIN_LIBS += $(top_builddir)/pseudoramiX/libPseudoramiX.la \ -$(top_builddir)/Xext/libXextdpmsstubs.la +$(top_builddir)/Xext/libXextdpmsstubs.la \ +$(top_builddir)/Xi/libXistubs.la XWin_DEPENDENCIES = $(MULTIWINDOWEXTWM_LIBS) $(XWIN_GLX_LIBS) $(XWIN_LIBS) $(XSERVER_LIBS) XWin_LDADD = $(MULTIWINDOW_LIBS) $(MULTIWINDOWEXTWM_LIBS) $(XWIN_GLX_LIBS) $(XWIN_GLX_LINK_FLAGS) $(XWIN_LIBS) $(MAIN_LIB) $(XSERVER_LIBS) $(XSERVER_SYS_LIBS) $(XWIN_SYS_LIBS) XWin_LDFLAGS = -mwindows -static -Wl,--disable-stdcall-fixup diff --git a/test/Makefile.am b/test/Makefile.am index 6264b48..2feff43 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -71,8 +71,7 @@ endif else nodist_libxservertest_la_SOURCES = \ ddxstubs.c \ -$(top_srcdir)/mi/miinitext.c \ -$(top_srcdir)/Xi/stubs.c +$(top_srcdir)/mi/miinitext.c libxservertest_la_LIBADD += \ $(top_builddir)/damageext/libdamageext.la \ @@ -85,6 +84,7 @@ libxservertest_la_LIBADD += \ $(top_builddir)/Xext/libXext.la \ $(top_builddir)/Xext/libXextdpmsstubs.la \ $(top_builddir)/Xi/libXi.la \ +$(top_builddir)/Xi/libXistubs.la \ $(top_builddir)/xfixes/libxfixes.la \ $(top_builddir)/xkb/libxkb.la \ $(top_builddir)/xkb/libxkbstubs.la -- 1.8.3.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] Build dpmsstubs.c once as a convenience library, rather than once for each DDX which wants to use it
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- Xext/Makefile.am | 4 +++- hw/vfb/Makefile.am | 4 ++-- hw/xnest/Makefile.am | 4 ++-- hw/xwin/Makefile.am | 6 +++--- test/Makefile.am | 2 +- 5 files changed, 11 insertions(+), 9 deletions(-) diff --git a/Xext/Makefile.am b/Xext/Makefile.am index 8e31f13..a9a4468 100644 --- a/Xext/Makefile.am +++ b/Xext/Makefile.am @@ -1,4 +1,4 @@ -noinst_LTLIBRARIES = libXext.la +noinst_LTLIBRARIES = libXext.la libXextdpmsstubs.la AM_CFLAGS = $(DIX_CFLAGS) @@ -96,6 +96,8 @@ endif libXext_la_SOURCES = $(BUILTIN_SRCS) libXext_la_LIBADD =$(BUILTIN_LIBS) +libXextdpmsstubs_la_SOURCES = dpmsstubs.c + EXTRA_DIST = \ $(MITSHM_SRCS) \ $(XV_SRCS) \ diff --git a/hw/vfb/Makefile.am b/hw/vfb/Makefile.am index 9f4992c..c9f6957 100644 --- a/hw/vfb/Makefile.am +++ b/hw/vfb/Makefile.am @@ -9,7 +9,6 @@ AM_CFLAGS = -DHAVE_DIX_CONFIG_H \ SRCS = InitInput.c \ InitOutput.c \ - $(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c \ $(top_srcdir)/mi/miinitext.c @@ -22,7 +21,8 @@ XVFB_LIBS = \ @XVFB_LIBS@ \ libfbcmap.a \ $(MAIN_LIB) \ - $(XSERVER_LIBS) + $(XSERVER_LIBS) \ + $(top_builddir)/Xext/libXextdpmsstubs.la Xvfb_LDADD = $(XVFB_LIBS) $(XVFB_SYS_LIBS) $(XSERVER_SYS_LIBS) Xvfb_DEPENDENCIES = $(XVFB_LIBS) diff --git a/hw/xnest/Makefile.am b/hw/xnest/Makefile.am index 3c099cd..c5560fd 100644 --- a/hw/xnest/Makefile.am +++ b/hw/xnest/Makefile.am @@ -42,7 +42,6 @@ SRCS =Args.c \ XNPixmap.h \ XNWindow.h \ xnest-config.h \ - $(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c \ $(top_srcdir)/mi/miinitext.c @@ -51,7 +50,8 @@ libfbcmap_a_CFLAGS = $(AM_CFLAGS) XNEST_LIBS = \ @XNEST_LIBS@ \ - libfbcmap.a + libfbcmap.a \ + $(top_builddir)/Xext/libXextdpmsstubs.la Xnest_SOURCES = $(SRCS) diff --git a/hw/xwin/Makefile.am b/hw/xwin/Makefile.am index 7f0eaf0..6668045 100644 --- a/hw/xwin/Makefile.am +++ b/hw/xwin/Makefile.am @@ -127,7 +127,6 @@ SRCS = InitInput.c \ winresource.h \ winwindow.h \ XWin.rc \ - $(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c \ $(top_srcdir)/mi/miinitext.c \ $(top_srcdir)/fb/fbcmap_mi.c \ @@ -153,12 +152,13 @@ XWin_SOURCES = $(SRCS) AM_CPPFLAGS = -I$(top_srcdir)/miext/rootless XWIN_SYS_LIBS += -ldxguid -XWIN_LIBS += $(top_builddir)/pseudoramiX/libPseudoramiX.la - +XWIN_LIBS += $(top_builddir)/pseudoramiX/libPseudoramiX.la \ +$(top_builddir)/Xext/libXextdpmsstubs.la XWin_DEPENDENCIES = $(MULTIWINDOWEXTWM_LIBS) $(XWIN_GLX_LIBS) $(XWIN_LIBS) $(XSERVER_LIBS) XWin_LDADD = $(MULTIWINDOW_LIBS) $(MULTIWINDOWEXTWM_LIBS) $(XWIN_GLX_LIBS) $(XWIN_GLX_LINK_FLAGS) $(XWIN_LIBS) $(MAIN_LIB) $(XSERVER_LIBS) $(XSERVER_SYS_LIBS) $(XWIN_SYS_LIBS) XWin_LDFLAGS = -mwindows -static -Wl,--disable-stdcall-fixup + .rc.o: $(AM_V_GEN)$(WINDRES) --use-temp-file -i $ --input-format=rc -o $@ -O coff -I $(top_builddir)/include diff --git a/test/Makefile.am b/test/Makefile.am index f8aa659..6264b48 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -72,7 +72,6 @@ else nodist_libxservertest_la_SOURCES = \ ddxstubs.c \ $(top_srcdir)/mi/miinitext.c \ -$(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c libxservertest_la_LIBADD += \ @@ -84,6 +83,7 @@ libxservertest_la_LIBADD += \ $(top_builddir)/randr/librandr.la \ $(top_builddir)/render/librender.la \ $(top_builddir)/Xext/libXext.la \ +$(top_builddir)/Xext/libXextdpmsstubs.la \ $(top_builddir)/Xi/libXi.la \ $(top_builddir)/xfixes/libxfixes.la \ $(top_builddir)/xkb/libxkb.la \ -- 1.8.3.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
Am 24.02.2014 11:36, schrieb Egbert Eich: From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h index 11f6c10..256d84b 100644 --- a/include/servermd.h +++ b/include/servermd.h @@ -114,8 +114,13 @@ SOFTWARE. #if defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) -#define IMAGE_BYTE_ORDERMSBFirst -#define BITMAP_BIT_ORDERMSBFirst +#if defined(__LITTLE_ENDIAN__) +#define IMAGE_BYTE_ORDER LSBFirst +#define BITMAP_BIT_ORDER LSBFirst +#else +#define IMAGE_BYTE_ORDER MSBFirst +#define BITMAP_BIT_ORDER MSBFirst +#endif #define GLYPHPADBYTES 4 #endif /* PowerPC */ Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. re, wh ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
On 14-02-23 11:46 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. Can we turn on the subdir-objects feature after this patch then? Not yet. And it would be only for this Makefile.am, not for the whole server code. There are those three other cases to handle: nodist_libxservertest_la_SOURCES = \ ddxstubs.c \ $(top_srcdir)/mi/miinitext.c \ $(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c Jon Turney just posted a patches Build Xi and DPMS stubs as convenience libraries which takes care of two out of the three cases (If I understand correctly, just done a quick read). That would leave miinitext.c to handle. Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0 gets pervasive. This is the complete list of Makefile.am affected by this issue. Xi/Makefile.am fb/Makefile.am hw/dmx/Makefile.am hw/dmx/config/Makefile.am hw/kdrive/src/Makefile.am hw/vfb/Makefile.am hw/xfree86/dixmods/Makefile.am hw/xfree86/int10/Makefile.am hw/xfree86/os-support/bsd/Makefile.am hw/xfree86/os-support/hurd/Makefile.am hw/xfree86/os-support/linux/Makefile.am hw/xfree86/os-support/solaris/Makefile.am hw/xfree86/os-support/stub/Makefile.am hw/xfree86/parser/Makefile.am hw/xfree86/utils/cvt/Makefile.am hw/xnest/Makefile.am hw/xquartz/Makefile.am hw/xquartz/mach-startup/Makefile.am hw/xwin/Makefile.am test/Makefile.am The other area that has not been tackled yet is in the os-support and the shared directory: Mark Kettenis has commented: Note that not all warnings are actually problems. For example the directories under hw/xfree86/os-support are largely subdir-objects safe. Probably enough to make sure hw/xfree86/os-support/shared gets created in the build directory before entering the OS-specific directory. The same is probably true for os/strlcpy.c and os/strlcat.c. Although those files are defenitely candidates for a libtool convenience library. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
walter harms wha...@bfs.de writes: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. That would risk breaking little endian platforms that failed to define this. Safest to limit the scope of the change the PPC platforms, where __LITTLE_ENDIAN__ is a new option, and hence likely to be set correctly. I would sure like to be able to detect the difference between 'this option is set to false' and 'this option isn't defined'; is there something that PPC defines in both cases, and sets to TRUE in one case and FALSE in the other? -- keith.pack...@intel.com pgpPRLjAElXa5.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/2] Build Xi and DPMS stubs as convenience libraries
On 14-02-24 07:07 AM, Jon TURNEY wrote: Jon TURNEY (2): Build dpmsstubs.c once as a convenience library, rather than once for each DDX which wants to use it Build Xi/stubs.c once as a convenience library, rather than once for each DDX which wants to use it Xext/Makefile.am | 4 +++- Xi/Makefile.am | 5 +++-- hw/vfb/Makefile.am | 6 +++--- hw/xnest/Makefile.am | 6 +++--- hw/xwin/Makefile.am | 8 test/Makefile.am | 6 +++--- 6 files changed, 19 insertions(+), 16 deletions(-) Reviewed-by: Gaetan Nadon mems...@videotron.ca And passes distcheck. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
From: Egbert Eich e...@freedesktop.org Date: Mon, 24 Feb 2014 11:36:54 +0100 From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org Reviewed-by: Mark Kettenis kette...@openbsd.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h index 11f6c10..256d84b 100644 --- a/include/servermd.h +++ b/include/servermd.h @@ -114,8 +114,13 @@ SOFTWARE. #if defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) -#define IMAGE_BYTE_ORDERMSBFirst -#define BITMAP_BIT_ORDERMSBFirst +#if defined(__LITTLE_ENDIAN__) +#define IMAGE_BYTE_ORDER LSBFirst +#define BITMAP_BIT_ORDER LSBFirst +#else +#define IMAGE_BYTE_ORDER MSBFirst +#define BITMAP_BIT_ORDER MSBFirst +#endif #define GLYPHPADBYTES 4 #endif /* PowerPC */ -- 1.8.4.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
On Mon, 2014-02-24 at 08:09:33 -0800, Keith Packard wrote: walter harms wha...@bfs.de writes: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. That would risk breaking little endian platforms that failed to define this. Safest to limit the scope of the change the PPC platforms, where __LITTLE_ENDIAN__ is a new option, and hence likely to be set correctly. I would sure like to be able to detect the difference between 'this option is set to false' and 'this option isn't defined'; is there something that PPC defines in both cases, and sets to TRUE in one case and FALSE in the other? I'm probably missing something (maybe this header cannot include a dix-config.h or equivalent), but why not use AC_C_BIGENDIAN? Thanks, Guillem ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] reviewed glamor changes
Eric Anholt e...@anholt.net writes: Eric Anholt (17): glamor: Convert to using libepoxy. glamor: Rename glamor_get/put_dispatch to glamor_get/put_context. glamor: Put in a pluggable context switcher for GLX versus EGL. glamor: Drop useless glEnable/glDisable(GL_TEXTURE_2D) calls. glamor: Drop fixed function transformation matrix setup. glamor: yInverted is a boolean value, so use the Bool type. glamor: Drop a bunch of GLES2 ifdefs. glamor: Add a screen argument to drop an ifdef from glamor_set_alu(). glamor: Pass pixmaps around to unifdef glamor_iformat_for_depth(). glamor: Unifdef the cache format indices. glamor: Move glamor_get_tex_format_type_from_pictformat to a .c file. glamor: Unifdef the picture-format-to-format-and-type functions. glamor: Move shader precision stuff from build time to shader compile time. glamor: Fix typo in setting v_position's attrib location. glamor: Don't bother keeping references to shader stages for gradients. glamor: Fix linking of the gradient shaders on GLES2. glamor: Move the EGL DRI3 code to GLAMOR_HAS_GBM. Merged. 0f10cfd..0840a30 master - master -- keith.pack...@intel.com pgpockstrN9Kp.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Hi, On 24 February 2014 15:28, Gaetan Nadon mems...@videotron.ca wrote: There are those three other cases to handle: nodist_libxservertest_la_SOURCES = \ ddxstubs.c \ $(top_srcdir)/mi/miinitext.c \ $(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c Jon Turney just posted a patches Build Xi and DPMS stubs as convenience libraries which takes care of two out of the three cases (If I understand correctly, just done a quick read). That would leave miinitext.c to handle. miinitext.c was originally built separately from everything else because it was a nest of per-server #ifdefs. I unified that back in July 2012, so now the only thing standing in the way of linking it into libmi should just be resolving link order issues. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Hi, Overall, I think it's close to the best we can make of a bad situation (in hindsight, I think we both would've done things differently ...), but Keith's pretty on the money: On 24 February 2014 06:57, Keith Packard kei...@keithp.com wrote: Peter Hutterer peter.hutte...@who-t.net writes: yeah, it does seem like the most sensible behaviour but right now the keyboards are completely independent and the event routing is based on that. so if you hit ctrl on one keyboard, alt on the other, the master will have ctrl+alt down, while each keyboard only has either modifier set. somewhat similar to the button state. There is an obvious difference between locking and non-locking modifiers. One can imagine wanting to update only the locking modifier state and associated indicators and leaving the state of the non-locking modifiers alone, so that hitting Shift on one keyboard would not be visible if monitoring another slave keyboard device, but that NumLock *would* be mirrored across slaves connected to the same master. On second thought, that's a crazy plan. I'd say the correct semantic is for the slave device to report the same modifier state through either the slave or master device, and so the only sensible plan is to mirror the modifier state across all slave keyboards. Otherwise, why would you have tied the two slaves to the same master? It is a crazy plan indeed - and not just because one of the stated usecases was for footpedal modifiers to take effect on a keyboard for accessibility reasons. But I think the locking thing is actually pretty close to the money: what if, when pushing state back down to slave devices, we only push the lock state, rather than latched/active? I think that solves the immediate problem (synchronising LEDs and permanent state) whilst not doing anything surprising like having a base modifier down which was never pressed on that device. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Daniel Stone dan...@fooishbar.org writes: whilst not doing anything surprising like having a base modifier down which was never pressed on that device. Are you saying that we should only mirror the locking modifier state From master to slaves? That seems plausible, but seems more complicated and not all that useful to me, as now the slave will report some, but not all, of the master modifier state. -- keith.pack...@intel.com pgpT37QADL5JG.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Hi, On 24 February 2014 21:28, Keith Packard kei...@keithp.com wrote: Daniel Stone dan...@fooishbar.org writes: whilst not doing anything surprising like having a base modifier down which was never pressed on that device. Are you saying that we should only mirror the locking modifier state From master to slaves? That seems plausible, but seems more complicated and not all that useful to me, as now the slave will report some, but not all, of the master modifier state. I'm suggesting the minimal change possible to solve the stated problem (which is essentially that new slaves don't inherit the LED - i.e. lock - state of their masters). I'm pretty wary of the full push to always push master state down to slaves, especially given the fact that slaves may have wholly disjoint keymaps to their masters. The latter was an incredibly dumb idea in hindsight and can almost never produce meaningful results in practice, but hey, what can you do. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Daniel Stone dan...@fooishbar.org writes: I'm suggesting the minimal change possible to solve the stated problem (which is essentially that new slaves don't inherit the LED - i.e. lock - state of their masters). Ok, that seems like a fine plan to me I'm pretty wary of the full push to always push master state down to slaves, especially given the fact that slaves may have wholly disjoint keymaps to their masters. So, the trick is to identify which modifiers are locking. CapsLock/ShiftLock is easy as it uses a fixed modifier bit, but NumLock can move around. -- keith.pack...@intel.com pgpCu2Du1GxX7.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
On Mon, Feb 24, 2014 at 09:32:57PM +, Daniel Stone wrote: Hi, On 24 February 2014 21:28, Keith Packard kei...@keithp.com wrote: Daniel Stone dan...@fooishbar.org writes: whilst not doing anything surprising like having a base modifier down which was never pressed on that device. Are you saying that we should only mirror the locking modifier state From master to slaves? That seems plausible, but seems more complicated and not all that useful to me, as now the slave will report some, but not all, of the master modifier state. I'm suggesting the minimal change possible to solve the stated problem (which is essentially that new slaves don't inherit the LED - i.e. lock - state of their masters). I'm pretty wary of the full push to always push master state down to slaves, especially given the fact that slaves may have wholly disjoint keymaps to their masters. The latter was an incredibly dumb idea in hindsight and can almost never produce meaningful results in practice, but hey, what can you do. yeah, I agree, I'm a bit wary of pushing down the state too, it was the simplest approach though. but I'm sure 2 years down the track we'll hear from someone whose workflow relied on the current behaviour... the less-intrusive alternative would be to force only the indicator state down to the slaves. won't change keyboard behaviour as seen by the client and still has the effect that most people expect from their keyboards. comments? Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Peter Hutterer peter.hutte...@who-t.net writes: the less-intrusive alternative would be to force only the indicator state down to the slaves. won't change keyboard behaviour as seen by the client and still has the effect that most people expect from their keyboards. comments? That seems even weirder to me -- you've got a NumLock light on, and yet your keyboard doesn't have NumLock pressed when seen as a slave? -- keith.pack...@intel.com pgpjPsK_fu0Ev.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Gaetan Nadon mems...@videotron.ca writes: Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0 gets pervasive. Sure would be nice if automake 2.0 had a compatibility mode that would let us continue with our current scheme. Has anyone looked at the 2.0 code to see if there's a way we can avoid changing how we build things just to make autofu happy? -- keith.pack...@intel.com pgpl4FUfkitFG.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add devd config backend for FreeBSD (and GNU/kFreeBSD)
On 22/02/2014 16:12, Guillem Jover wrote:
Hi,
Just a quick review skimming over. The C code has a mix of indentation
by tab and spaces, not just 4 spaces, no cudled braces, etc. I've
ignored other style issues too.
I just went through the style rules in http://www.x.org/wiki/CodingStyle/
and applied them to devd.c. Hopefully all style issues are solved now.
+++ b/config/devd.c
@@ -0,0 +1,365 @@
+/*
+ * Copyright ?? 2012 Baptiste Daroussin
Encoding issue? Should be ©, I guess.
It's © in the actual file - just checked.
+if (sysctlbyname(name, NULL, len, NULL, 0) == 0) {
+dest = malloc(len + 1);
malloc() return value unchecked.
Fixed, thanks.
+walk = strchr(line, ' ');
+if (walk != NULL)
+walk[0] = '\0';
You could do this (and the one from device_remove()) in the single
caller where it seems to matter, that is wakeup_handler(), and pass
a devicename (or similar) as argument instead of the generic line.
Done.
+if (asprintf(path, /dev/%s, line) == -1)
+return;
+
+options = input_option_new(NULL, _source, server/devd);
+if (!options)
+return;
Leaks path.
Fixed, thanks.
+vendor = sysctl_get_str(dev.%s.%s.%%desc, hw_types[i].driver, line +
strlen(hw_types[i].driver));
+if (vendor == NULL) {
+attrs.vendor = strdup((unnamed));
+} else {
+if ((product = strchr(vendor, ' ')) != NULL) {
+product[0] = '\0';
+product++;
+}
+attrs.vendor = strdup(vendor);
+if (product != NULL (walk = strchr(product, ',')) != NULL)
+walk[0] = '\0';
+attrs.product = strdup(product != NULL ? product : (unnamed));
+options = input_option_new(options, name, product != NULL ?
product : (unnamed));
You could compute the product once before the conditional (as it's
used later on too),
Done.
+if (rc != Success)
+goto unwind;
A bit useless, although future-proof.
I suppose that's what Baptiste had in mind. The compiler clears this out anyway.
+return;
Useless return.
Removed.
+static void
+device_removed(char *line)
+{
+char *walk;
+char *value;
+
+walk = strchr(line, ' ');
+if (walk != NULL)
+walk[0] = '\0';
Same comment here as in device_added.
Fixed likewise.
+static ssize_t
+socket_getline(int fd, char **out)
+{
+char *buf;
+ssize_t ret, cap, sz = 0;
+char c;
+
+cap = 1024;
+buf = malloc(cap * sizeof(char));
Useless sizeof(),
Useless to the compiler, like many other things, but not necessarily useless to
the reader.
As far as I can see this is an established practice in xserver codebase. Some
cases go as
far as specifying signedness:
config/hal.c:ret = calloc(sizeof(char), len + i);/* i - 1 commas, 1
NULL */
dix/gc.c:dash = malloc(2 * sizeof(unsigned char));
dix/gc.c:dash = malloc(pgcSrc-numInDashList * sizeof(unsigned
char));
dix/gc.c:p = malloc(2 * ndash * sizeof(unsigned char));
dix/gc.c:p = malloc(ndash * sizeof(unsigned char));
.
.
etc
realloc() can do the initial alloc if buf is NULL.
What would be the point in that? This change pessimizes on the common case by
adding
two extra in-loop branches, without actually saving any cost since the
allocation needs
to happen anyway.
+for (;;) {
+ret = read(sock_devd, c, 1);
+if (ret 1) {
+free(buf);
+return -1;
+}
You might want to check for EINTR here.
Fixed, thanks.
+if (c == '\n')
+break;
+
+if (sz + 1 = cap) {
+cap *= 2;
+buf = realloc(buf, cap *sizeof(char));
Leaks on failure,
Fixed, thanks.
+int
+config_devd_init(void)
+{
+struct sockaddr_un devd;
+char devicename[1024];
+int i, j;
+
+/* first scan the sysctl to determine the hardware if needed */
+
+for (i = 0; hw_types[i].driver != NULL; i++) {
+for (j = 0; sysctl_exists(dev.%s.%i.%%desc, hw_types[i].driver,
j); j++) {
+snprintf(devicename, 1024, %s%i, hw_types[i].driver, j);
sizeof(devicename) instead of hard-coding 1024, which can easily get
out of sync.
Fixed, thanks.
+if (connect(sock_devd, (struct sockaddr *) devd, sizeof(struct
sockaddr_un)) 0) {
Better sizeof(devd), it will always match the variable type,
and it's shorter so the line fits in 80 chars.
Fixed, thanks.
-#if defined(CONFIG_HAL) || defined(CONFIG_UDEV) || defined(CONFIG_WSCONS)
+#if defined(CONFIG_HAL) || defined(CONFIG_UDEV) || defined(CONFIG_WSCONS)
|| defined(CONFIG_DEVD)
.forceInputDevices = FALSE,
.autoAddDevices = TRUE,
.autoEnableDevices = TRUE,
You might want to wrap these long lines to 80 chars.
Done.
On 22/02/2014 17:15, Guillem Jover wrote:
+static void
+device_added(char *line)
Re: [RFC] Automatic modifier update of slave devices
On Mon, Feb 24, 2014 at 02:28:55PM -0800, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: the less-intrusive alternative would be to force only the indicator state down to the slaves. won't change keyboard behaviour as seen by the client and still has the effect that most people expect from their keyboards. comments? That seems even weirder to me -- you've got a NumLock light on, and yet your keyboard doesn't have NumLock pressed when seen as a slave? the recommendation for XI2 was always to not handle slaves separately when they're attached to a master device, because any event will feed into the master. it's a fine line between doing what the user expects and not breaking what we did for the last couple of years. there is no good solution here, it's just a question which foot we prefer shooting at. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Hi,
On 24 February 2014 22:28, Keith Packard kei...@keithp.com wrote:
Peter Hutterer peter.hutte...@who-t.net writes:
the less-intrusive alternative would be to force only the indicator state
down to the slaves. won't change keyboard behaviour as seen by the client
and still has the effect that most people expect from their keyboards.
comments?
That seems even weirder to me -- you've got a NumLock light on, and yet
your keyboard doesn't have NumLock pressed when seen as a slave?
Yeah, this is exactly my problem: the disjoint state. Although it
would do the right thing as a master ...
I think we should just synchronise locking state always. XKB makes
this easy (for once!) and you don't have to guess: every keyboard has
separate state for base (physically pressed down, e.g. Shift), latched
(next press carries and resets state, e.g. phone keyboard Shift), and
locked (e.g. Caps Lock). These all get combined into the effective
state, from which the core state is derived.
So all you have to do is copy
device-key-xkbInfo-state.locked_{mods,group} from master to slave,
and then call XkbUpdateDerivedState() on each device.
I think the only real long-term solution is to bite the bullet and
ensure master and slaves always have the same keymap (i.e. changing
the keymap on any, changes all in the group), and then synchronise the
state between them all on every keypress. Slaves joining would then
inherit the master's keymap. The only real problem with this is how
this would work with xorg.conf, where people might be setting
XkbOptions that would take effect on the slave: when you start the
server, you want these options to take effect and change the whole
group. But when you have a desktop environment which has changed the
keymap, you don't want a hotplugged keyboard to reset from your DE's
chosen keymap, to the one you put in xorg.conf.
Ultimately this would make things a lot more simple and eliminate a
whole class of problems, but I fear that it's a lot more effort than
anyone would be willing to put into XKB these days ...
Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
PH == Peter Hutterer peter.hutte...@who-t.net writes: PH the less-intrusive alternative would be to force only the indicator state PH down to the slaves. won't change keyboard behaviour as seen by the client PH and still has the effect that most people expect from their keyboards. PH comments? So hitting compose on one keyboard would light the compose led on all associated keyboards but only intitiate a compose sequence on the one? Or caps-lock? Or level shifts? Or group toggles? If I read that right, that seems even worse. I'd want indicator state on a phisical kbd always to match what that kbd will do. I'm not certain about the other two options, though. Given that I use a keyboard which shows up as two usb endpoints, and each endpoint is a separate slave kbd to the shared master, I'd prefer that shift, et alia states for one slave apply to all. But that may not be right for everyone's setup. Perhaps xinput(1) should be able to configure whether given slaves share such state with their brethren? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXau] Constify XauGetBestAuthByAddr type_names argument
The type names are merely accessed, not changed. So make it const to
avoid warnings in other projects (like libxcb) which pass in a static
table of string literals.
Signed-off-by: Ran Benita ran...@gmail.com
---
AuGetBest.c | 2 +-
include/X11/Xauth.h | 2 +-
man/Xau.man | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/AuGetBest.c b/AuGetBest.c
index 5556559..0d59f85 100644
--- a/AuGetBest.c
+++ b/AuGetBest.c
@@ -57,7 +57,7 @@ XauGetBestAuthByAddr (
#endif
_Xconst char* number,
inttypes_length,
-char** types,
+_Xconst char** types,
_Xconst int* type_lengths)
{
FILE*auth_file;
diff --git a/include/X11/Xauth.h b/include/X11/Xauth.h
index a707bed..e0c4f28 100644
--- a/include/X11/Xauth.h
+++ b/include/X11/Xauth.h
@@ -128,7 +128,7 @@ unsigned short /* number_length */,
#endif
_Xconst char* /* number */,
int/* types_length */,
-char** /* type_names */,
+_Xconst char** /* type_names */,
_Xconst int* /* type_lengths */
);
diff --git a/man/Xau.man b/man/Xau.man
index d1b6603..aa69b0d 100644
--- a/man/Xau.man
+++ b/man/Xau.man
@@ -59,7 +59,7 @@ Xauth *XauGetAuthByAddr (unsigned short \fIfamily\fP\^,
unsigned short
Xauth *XauGetBestAuthByAddr (unsigned short \fIfamily\fP\^, unsigned short
\fIaddress_length\fP\^, const char *\fIaddress\fP\^, unsigned short
\fInumber_length\fP\^, const char *\fInumber\fP\^, int \fItypes_length\fP\^,
-char **\fItypes\fR\^, const int *\fItype_lengths\fR\^);
+const char **\fItypes\fR\^, const int *\fItype_lengths\fR\^);
.HP
int XauLockAuth (const char *\fIfile_name\fP\^, int \fIretries\fP\^, int
\fItimeout\fP\^, long \fIdead\fP\^);
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Hi, On 24 February 2014 22:56, James Cloos cl...@jhcloos.com wrote: So hitting compose on one keyboard would light the compose led on all associated keyboards but only intitiate a compose sequence on the one? Or caps-lock? Or level shifts? Or group toggles? If I read that right, that seems even worse. Depends. Every key press generates two events - one for the slave and another for the master, and both are processed totally differently. So if you had Num Lock being set in this manner (actually locked on the master, but only updating the LED for the slave), then pressing 4 would result in a KP_4 keypress on the master, and a KP_Left press on the slave. Still not present, but as Peter says, don't listen to slaves which are attached to masters and expect sensible results ... I'd want indicator state on a phisical kbd always to match what that kbd will do. I'm not certain about the other two options, though. Given that I use a keyboard which shows up as two usb endpoints, and each endpoint is a separate slave kbd to the shared master, I'd prefer that shift, et alia states for one slave apply to all. But that may not be right for everyone's setup. Perhaps xinput(1) should be able to configure whether given slaves share such state with their brethren? Ugh, that sounds like the worst of all possible worlds, if I'm honest: this is one place we really, really, don't need more complexity and unexpected behaviour. I'd prefer us to just make a decision one way or another - go all-out and forcibly harmonise keymaps, or one of the compromises along the way - and stick with that to the bitter end. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Peter Hutterer peter.hutte...@who-t.net writes: there is no good solution here, it's just a question which foot we prefer shooting at. Yeah, that part seems clear enough at least. So, it seems like we have a list of options: 1) Mirror nothing. Indicators and modifiers for each slave are independent. Events seen through the slave device will not have modifier bits set. Event seen through the master device will have the union of all slave device modifiers. Problems: Users may be confused by the mis-match between indicator state and locking modifier state for master devices. Benefits: Slave devices will operate independently and will not report mysterious modifier bits. 2) Mirror indicators. Indicators for slave devices are driven by the master; all slave device indicators match the master state. Problems: Users may be confused by the mis-match between indicator state and associated locking modifier state on slave devices. Question: Will the locking keys operate oddly on the other slave devices? If the state of the local locking key is not reflected by the local indicator, what happens when you press the local locking modifier which is logically 'up' while the matching indicator says 'down'? Benefit: Users will see correct indicators for locking modifiers for events sent through the master device. 3) Mirror locking modifiers and indicators. Locking modifiers and their associated indicators are driven by the master. All slave indicators and locking modifiers are sent to the master and then distributed to all other slaves. Problems: Slave devices will end up sending locking modifier state from other associated slave devices, but not other modifier state. Benefit: Slave locking modifiers should act consistently with the associated indicators (see question for 2 above). 4) Mirror all modifiers All modifiers for all slave devices are mirrored through the master so that all slaves exactly track all modifiers. Problem: Slave devices will see shift/ctrl/alt modifiers from other slaves, as well as seeing locking modifiers from other slaves. Benefit: All modifiers will the same as seen through both the slave and master devices, and all indicators will match everywhere. 1) is what we do today, and the lack of indicator tracking sucks for users. 2) and 3) differ only slightly, and the question I have for 2) is whether the locking keys will act 'funny'. If so, then 3) is clearly a better plan. I do lean to 3) at this point, just because that way the indicators correctly reflect events sent to both slave and master devices, which at least seems a bit more consistent. -- keith.pack...@intel.com pgpGppIUwW3lU.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] sync: Avoid ridiculously long timeouts
Matthieu Herrb matthieu.he...@laas.fr writes: Mark Kettenis (1): sync: Avoid ridiculously long timeouts Rescued from obscurity and merged. c85ea92..1940508 master - master -- keith.pack...@intel.com pgpCiIOT72Hl3.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] gcc 4.2.1 doesn't support #pragma GCC diagnostic ignored
Matthieu Herrb matthieu.he...@laas.fr writes: Signed-off-by: Matthieu Herrb matth...@herrb.eu Merged. 1940508..e67f2d7 master - master -- keith.pack...@intel.com pgpfEWxr4gw3j.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/2] Fix test/signal-logging to work on Solaris
Peter Hutterer peter.hutte...@who-t.net writes: On Sun, Feb 09, 2014 at 11:13:50PM -0800, Alan Coopersmith wrote: For some reason, Solaris libc sprintf() doesn't add 0x to the %p output as glibc does, causing the test to fail for not matching the exact output. Since the 0x is desirable, we add it ourselves to the test string. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Reviewed-by: Peter Hutterer peter.hutte...@who-t.net for both Merged. e67f2d7..249565a master - master -- keith.pack...@intel.com pgpXcRrvCduBm.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] V2: Add check for link from output to crtc before optimizing out a CrtcSet call
David Sodman dsod...@chromium.org writes: Signed-off-by: David Sodman dsod...@chromium.org Reviewed-by: Stéphane Marchesin marc...@chromium.org Merged. 249565a..caf1dec master - master -- keith.pack...@intel.com pgpjwzlPMEQlT.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/6] xephyr: Pass incoming XCB events to the Xlib event filter.
This is the same thing that Qt ended up doing to get DRI2's event
mangling to happen despite using an XCB event loop.
Signed-off-by: Eric Anholt e...@anholt.net
Reviewed-by: Keith Packard kei...@keithp.com
---
hw/kdrive/ephyr/ephyr.c| 3 +++
hw/kdrive/ephyr/ephyr_glamor_glx.c | 39 ++
hw/kdrive/ephyr/ephyr_glamor_glx.h | 15 +--
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index 75a6fcb..def50d8 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -1223,6 +1223,9 @@ ephyrPoll(void)
break;
}
+if (ephyr_glamor)
+ephyr_glamor_process_event(xev);
+
free(xev);
}
}
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c
b/hw/kdrive/ephyr/ephyr_glamor_glx.c
index a937c1a..d56907f 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
@@ -29,12 +29,17 @@
#include stdlib.h
#include X11/Xlib.h
+#include X11/Xlibint.h
+#undef Xcalloc
+#undef Xrealloc
+#undef Xfree
#include X11/Xlib-xcb.h
#include xcb/xcb_aux.h
#include pixman.h
#include epoxy/glx.h
#include ephyr_glamor_glx.h
#include os.h
+#include X11/Xproto.h
/** @{
*
@@ -218,6 +223,40 @@ ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
glXSwapBuffers(dpy, glamor-glx_win);
}
+/**
+ * Xlib-based handling of xcb events for glamor.
+ *
+ * We need to let the Xlib event filtering run on the event so that
+ * Mesa's dri2_glx.c userspace event mangling gets run, and we
+ * correctly get our invalidate events propagated into the driver.
+ */
+void
+ephyr_glamor_process_event(xcb_generic_event_t *xev)
+{
+
+uint32_t response_type = xev-response_type 0x7f;
+/* Note the types on wire_to_event: there's an Xlib XEvent (with
+ * the broken types) that it returns, and a protocol xEvent that
+ * it inspects.
+ */
+Bool (*wire_to_event)(Display *dpy, XEvent *ret, xEvent *event);
+
+XLockDisplay(dpy);
+/* Set the event handler to NULL to get access to the current one. */
+wire_to_event = XESetWireToEvent(dpy, response_type, NULL);
+if (wire_to_event) {
+XEvent processed_event;
+
+/* OK they had an event handler. Plug it back in, and call
+ * through to it.
+ */
+XESetWireToEvent(dpy, response_type, wire_to_event);
+xev-sequence = LastKnownRequestProcessed(dpy);
+wire_to_event(dpy, processed_event, (xEvent *)xev);
+}
+XUnlockDisplay(dpy);
+}
+
struct ephyr_glamor *
ephyr_glamor_glx_screen_init(xcb_window_t win)
{
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.h
b/hw/kdrive/ephyr/ephyr_glamor_glx.h
index 950beff..8995e1e 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.h
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.h
@@ -53,10 +53,21 @@ ephyr_glamor_glx_screen_fini(struct ephyr_glamor *glamor);
void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage);
-#else
+
+void
+ephyr_glamor_process_event(xcb_generic_event_t *xev);
+
+#else /* !GLAMOR */
+
static inline void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage)
{
}
-#endif
+
+static inline void
+ephyr_glamor_process_event(xcb_generic_event_t *xev)
+{
+}
+
+#endif /* !GLAMOR */
--
1.9.rc1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
glamor: Enabling xephyr and Xorg.
Here's a short series to make the server glamor stuff actually testable. I'm now running glamor for my normal desktop, and the xephyr bits work too. I pulled out changes that would have required more from the intel 2d driver: now it's just a matter of not linking to the external module's libglamor.so, and not trying to do its own DRI3 support. I also pulled out the swap events code: While my timing tracecs on swap events are looking reasonable, there's really weird stuff going on with x11perf performance both before and after that change, and I'm holding off until I can understand it. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/6] xorg: Build a glamor_egl module.
This is not exposing the API we want long term, but it should get
existing DDX drivers up and running while we massage the API into
shape.
v2: Use LIBADD instead of LDFLAGS to fix deps on libglamor.la, and use
version 0.5.1 (the point it was forked from the external repo).
Signed-off-by: Eric Anholt e...@anholt.net
---
configure.ac | 11 +++
glamor/glamor_eglmodule.c | 3 ++-
hw/xfree86/Makefile.am| 7 ++-
hw/xfree86/glamor_egl/Makefile.am | 39 +++
include/dix-config.h.in | 3 +++
5 files changed, 61 insertions(+), 2 deletions(-)
create mode 100644 hw/xfree86/glamor_egl/Makefile.am
diff --git a/configure.ac b/configure.ac
index 5934950..74819bf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -806,6 +806,8 @@ LIBAPPLEWM=applewm = 1.4
LIBDMX=dmx = 1.0.99.1
LIBDRI=dri = 7.8.0
LIBDRM=libdrm = 2.3.0
+LIBEGL=egl
+LIBGBM=gbm = 9
LIBGL=gl = 7.1.0
LIBXEXT=xext = 1.0.99.4
LIBXFONT=xfont = 1.4.2
@@ -2070,7 +2072,15 @@ AM_CONDITIONAL([GLAMOR], [test x$GLAMOR = xyes])
if test x$GLAMOR = xyes; then
AC_DEFINE(GLAMOR, 1, [Build glamor])
PKG_CHECK_MODULES([GLAMOR], [epoxy])
+
+ PKG_CHECK_MODULES(GBM, $LIBGBM, [GBM=yes], [GBM=no])
+ if test x$GBM = xyes; then
+ AC_DEFINE(GLAMOR_HAS_GBM, 1,
+ [Build glamor with GBM-based EGL support])
+ fi
+
fi
+AM_CONDITIONAL([GLAMOR_EGL], [test x$GBM = xyes])
dnl XWin DDX
@@ -2479,6 +2489,7 @@ hw/xfree86/exa/Makefile
hw/xfree86/exa/man/Makefile
hw/xfree86/fbdevhw/Makefile
hw/xfree86/fbdevhw/man/Makefile
+hw/xfree86/glamor_egl/Makefile
hw/xfree86/i2c/Makefile
hw/xfree86/int10/Makefile
hw/xfree86/loader/Makefile
diff --git a/glamor/glamor_eglmodule.c b/glamor/glamor_eglmodule.c
index 5ddd602..fb5b855 100644
--- a/glamor/glamor_eglmodule.c
+++ b/glamor/glamor_eglmodule.c
@@ -30,6 +30,7 @@
#include dix-config.h
#include xorg-server.h
+#include xf86.h
#define GLAMOR_FOR_XORG
#include xf86Module.h
#include glamor.h
@@ -40,7 +41,7 @@ static XF86ModuleVersionInfo VersRec = {
MODINFOSTRING1,
MODINFOSTRING2,
XORG_VERSION_CURRENT,
-PACKAGE_VERSION_MAJOR, PACKAGE_VERSION_MINOR, PACKAGE_VERSION_PATCHLEVEL,
+0, 5, 1, /* version */
ABI_CLASS_ANSIC,/* Only need the ansic layer */
ABI_ANSIC_VERSION,
MOD_CLASS_NONE,
diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
index 9672904..73e1b4c 100644
--- a/hw/xfree86/Makefile.am
+++ b/hw/xfree86/Makefile.am
@@ -14,6 +14,10 @@ DRI3_BUILDDIR = $(top_builddir)/dri3
DRI3_LIB = $(DRI3_BUILDDIR)/libdri3.la
endif
+if GLAMOR_EGL
+GLAMOR_EGL_SUBDIR = glamor_egl
+endif
+
if XF86UTILS
XF86UTILS_SUBDIR = utils
endif
@@ -33,7 +37,8 @@ endif
SUBDIRS = common ddc x86emu $(INT10_SUBDIR) os-support parser \
ramdac $(VGAHW_SUBDIR) loader modes $(DRI_SUBDIR) \
$(DRI2_SUBDIR) . $(VBE_SUBDIR) i2c dixmods \
- fbdevhw shadowfb exa $(XF86UTILS_SUBDIR) doc man
+ fbdevhw shadowfb exa $(XF86UTILS_SUBDIR) doc man \
+ $(GLAMOR_EGL_SUBDIR)
DIST_SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support \
parser ramdac shadowfb vbe vgahw \
diff --git a/hw/xfree86/glamor_egl/Makefile.am
b/hw/xfree86/glamor_egl/Makefile.am
new file mode 100644
index 000..827e033
--- /dev/null
+++ b/hw/xfree86/glamor_egl/Makefile.am
@@ -0,0 +1,39 @@
+# Copyright © 2013 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+
+module_LTLIBRARIES = libglamoregl.la
+
+libglamoregl_la_SOURCES = \
+ $(top_srcdir)/glamor/glamor_egl.c \
+ $(top_srcdir)/glamor/glamor_eglmodule.c \
+ $()
+
+libglamoregl_la_LDFLAGS = \
+ -avoid-version \
+ $(GBM_LIBS) \
+ $()
+
+libglamoregl_la_LIBADD = \
+ $(top_builddir)/glamor/libglamor.la \
+ $()
+
+AM_CPPFLAGS = $(XORG_INCS)
+AM_CFLAGS =
[PATCH 1/6] xephyr: Build support for rendering with glamor using a -glamor option.
v2: Avoid making the Ximage for the screen that we'll never use, and
drive the screen pixmap creation for glamor ourselves.
Signed-off-by: Eric Anholt e...@anholt.net
Reviewed-by: Keith Packard kei...@keithp.com (v1)
---
configure.ac | 3 +
glamor/glamor.c| 11 ++
glamor/glamor.h| 2 +
hw/kdrive/ephyr/Makefile.am| 20 ++-
hw/kdrive/ephyr/ephyr.c| 42 --
hw/kdrive/ephyr/ephyr.h| 14 ++
hw/kdrive/ephyr/ephyr_glamor_glx.c | 292 +
hw/kdrive/ephyr/ephyr_glamor_glx.h | 62
hw/kdrive/ephyr/ephyrinit.c| 14 ++
hw/kdrive/ephyr/hostx.c| 126 +++-
10 files changed, 570 insertions(+), 16 deletions(-)
create mode 100644 hw/kdrive/ephyr/ephyr_glamor_glx.c
create mode 100644 hw/kdrive/ephyr/ephyr_glamor_glx.h
diff --git a/configure.ac b/configure.ac
index 0fb2fc3..5934950 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2319,6 +2319,9 @@ if test $KDRIVE = yes; then
if test x$DRI = xyes test x$GLX = xyes; then
XEPHYR_REQUIRED_LIBS=$XEPHYR_REQUIRED_LIBS libdrm xcb-glx xcb-xf86dri
1.6
fi
+if test x$GLAMOR = xyes; then
+XEPHYR_REQUIRED_LIBS=$XEPHYR_REQUIRED_LIBS x11-xcb
+fi
if test x$XEPHYR = xauto; then
PKG_CHECK_MODULES(XEPHYR, $XEPHYR_REQUIRED_LIBS, [XEPHYR=yes],
[XEPHYR=no])
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 7d8228c..85fd560 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -123,6 +123,17 @@ glamor_set_screen_pixmap(PixmapPtr screen_pixmap,
PixmapPtr *back_pixmap)
glamor_priv-back_pixmap = back_pixmap;
}
+uint32_t
+glamor_get_pixmap_texture(PixmapPtr pixmap)
+{
+glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
+
+if (pixmap_priv-type != GLAMOR_TEXTURE_ONLY)
+return 0;
+
+return pixmap_priv-base.fbo-tex;
+}
+
PixmapPtr
glamor_create_pixmap(ScreenPtr screen, int w, int h, int depth,
unsigned int usage)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index eec6872..08ffd26 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -124,6 +124,8 @@ extern _X_EXPORT Bool glamor_close_screen(ScreenPtr screen);
extern _X_EXPORT void glamor_set_screen_pixmap(PixmapPtr screen_pixmap,
PixmapPtr *back_pixmap);
+extern _X_EXPORT uint32_t glamor_get_pixmap_texture(PixmapPtr pixmap);
+
/* @glamor_glyphs_init: Initialize glyphs internal data structures.
*
* @pScreen: Current screen pointer.
diff --git a/hw/kdrive/ephyr/Makefile.am b/hw/kdrive/ephyr/Makefile.am
index 6b790fd..040993c 100644
--- a/hw/kdrive/ephyr/Makefile.am
+++ b/hw/kdrive/ephyr/Makefile.am
@@ -27,12 +27,20 @@ AM_CPPFLAGS = \
@XEPHYR_INCS@ \
@XEPHYR_CFLAGS@ \
-I$(top_srcdir) \
+ -I$(top_srcdir)/glamor \
-I$(top_srcdir)/exa
if XV
XV_SRCS = ephyrvideo.c
endif
+if GLAMOR
+GLAMOR_SRCS = \
+ ephyr_glamor_glx.c \
+ ephyr_glamor_glx.h \
+ ()
+endif
+
if DRI
DRI_SRCS = \
ephyrdriext.c \
@@ -59,14 +67,24 @@ Xephyr_SOURCES = \
hostx.h \
$(XV_SRCS) \
$(DRI_SRCS) \
+ $(GLAMOR_SRCS) \
$()
+if GLAMOR
+AM_CPPFLAGS += $(XLIB_CFLAGS)
+XEPHYR_GLAMOR_LIB = \
+ $(top_builddir)/glamor/libglamor.la \
+ $(top_builddir)/glamor/libglamor_egl_stubs.la \
+ $()
+endif
+
Xephyr_LDADD = \
$(top_builddir)/exa/libexa.la \
+ $(XEPHYR_GLAMOR_LIB)\
@KDRIVE_LIBS@ \
@XEPHYR_LIBS@
-Xephyr_DEPENDENCIES = @KDRIVE_LOCAL_LIBS@
+Xephyr_DEPENDENCIES = @KDRIVE_LOCAL_LIBS@ $(XEPHYR_GLAMOR_LIB)
Xephyr_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index 9681273..75a6fcb 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -43,9 +43,15 @@
#include ephyrglxext.h
#endif /* XF86DRI */
+#ifdef GLAMOR
+#include glamor.h
+#endif
+#include ephyr_glamor_glx.h
+
#include xkbsrv.h
extern int KdTsPhyScreen;
+extern Bool ephyr_glamor;
KdKeyboardInfo *ephyrKbd;
KdPointerInfo *ephyrMouse;
@@ -326,15 +332,19 @@ ephyrInternalDamageRedisplay(ScreenPtr pScreen)
int nbox;
BoxPtr pbox;
-nbox = RegionNumRects(pRegion);
-pbox = RegionRects(pRegion);
-
-while (nbox--) {
-hostx_paint_rect(screen,
- pbox-x1, pbox-y1,
- pbox-x1, pbox-y1,
- pbox-x2 - pbox-x1, pbox-y2 - pbox-y1);
-pbox++;
+if (ephyr_glamor) {
+ephyr_glamor_damage_redisplay(scrpriv-glamor, pRegion);
+} else {
+nbox =
[PATCH 6/6] glamor: Add support for DRI3.
The render-nodes case is untested.
v2: Add a flag for wayland to suppress the native DRI3 support.
Wayland isn't running as a master itself, so it can't do the auth
on its own and has to ask the compositor to do it for us. Dropped
XXX about randr provider -- the conclusion from discussion with
keithp was that if the driver's dri3_open for a provider on a
different screen, that's a core dri3 bug.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.h | 4 +-
glamor/glamor_egl.c | 78 +++
hw/xfree86/glamor_egl/Makefile.am | 5 ++-
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 20988f4..d3520ab 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -67,10 +67,12 @@ typedef enum glamor_pixmap_type {
#define GLAMOR_USE_SCREEN (1 1)
#define GLAMOR_USE_PICTURE_SCREEN (1 2)
#define GLAMOR_USE_EGL_SCREEN (1 3)
+#define GLAMOR_NO_DRI3 (1 4)
#define GLAMOR_VALID_FLAGS (GLAMOR_INVERTED_Y_AXIS\
| GLAMOR_USE_SCREEN\
| GLAMOR_USE_PICTURE_SCREEN \
-| GLAMOR_USE_EGL_SCREEN)
+| GLAMOR_USE_EGL_SCREEN\
+ | GLAMOR_NO_DRI3)
/* @glamor_init: Initialize glamor internal data structure.
*
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 56d8913..c883777 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -50,6 +50,7 @@
#include glamor.h
#include glamor_priv.h
+#include dri3.h
static const char glamor_name[] = glamor;
@@ -68,6 +69,7 @@ struct glamor_egl_screen_private {
EGLDisplay display;
EGLContext context;
EGLint major, minor;
+char *device_path;
CreateScreenResourcesProcPtr CreateScreenResources;
CloseScreenProcPtr CloseScreen;
@@ -627,10 +629,67 @@ glamor_egl_has_extension(struct glamor_egl_screen_private
*glamor_egl,
return FALSE;
}
+static int
+glamor_dri3_open(ScreenPtr screen,
+ RRProviderPtr provider,
+ int *fdp)
+{
+ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+struct glamor_egl_screen_private *glamor_egl =
+glamor_egl_get_screen_private(scrn);
+int fd;
+drm_magic_t magic;
+
+fd = open(glamor_egl-device_path, O_RDWR|O_CLOEXEC);
+if (fd 0)
+return BadAlloc;
+
+/* Before FD passing in the X protocol with DRI3 (and increased
+ * security of rendering with per-process address spaces on the
+ * GPU), the kernel had to come up with a way to have the server
+ * decide which clients got to access the GPU, which was done by
+ * each client getting a unique (magic) number from the kernel,
+ * passing it to the server, and the server then telling the
+ * kernel which clients were authenticated for using the device.
+ *
+ * Now that we have FD passing, the server can just set up the
+ * authentication on its own and hand the prepared FD off to the
+ * client.
+ */
+if (drmGetMagic(fd, magic) 0) {
+if (errno == EACCES) {
+/* Assume that we're on a render node, and the fd is
+ * already as authenticated as it should be.
+ */
+*fdp = fd;
+return Success;
+} else {
+close(fd);
+return BadMatch;
+}
+}
+
+if (drmAuthMagic(glamor_egl-fd, magic) 0) {
+close(fd);
+return BadMatch;
+}
+
+*fdp = fd;
+return Success;
+}
+
+static dri3_screen_info_rec glamor_dri3_info = {
+.version = 0,
+.open = glamor_dri3_open,
+.pixmap_from_fd = glamor_pixmap_from_fd,
+.fd_from_pixmap = glamor_fd_from_pixmap,
+};
+
void
glamor_egl_screen_init(ScreenPtr screen, struct glamor_context *glamor_ctx)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
struct glamor_egl_screen_private *glamor_egl =
glamor_egl_get_screen_private(scrn);
@@ -642,6 +701,23 @@ glamor_egl_screen_init(ScreenPtr screen, struct
glamor_context *glamor_ctx)
glamor_ctx-get_context = glamor_egl_get_context;
glamor_ctx-put_context = glamor_egl_put_context;
+
+if (glamor_egl-dri3_capable !(glamor_priv-flags GLAMOR_NO_DRI3)) {
+/* Tell the core that we have the interfaces for import/export
+ * of pixmaps.
+ */
+glamor_enable_dri3(screen);
+
+/* To do DRI3 device FD generation, we need to open a new fd
+ * to the same device we were handed in originally.
+ */
+glamor_egl-device_path = drmGetDeviceNameFromFd(glamor_egl-fd);
+
+if (!dri3_screen_init(screen, glamor_dri3_info)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+
[PATCH 5/6] glamor: Rename the DRI-related pixmap functions.
There was confusion over whether they should have egl in the name, and
they had DRI3 in the name even though they're useful to have without
DRI3.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 10 +-
glamor/glamor.h | 54 +
glamor/glamor_egl.c | 12 ++--
3 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 85fd560..0516716 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -567,16 +567,16 @@ glamor_enable_dri3(ScreenPtr screen)
}
Bool
-glamor_is_dri3_support_enabled(ScreenPtr screen)
+glamor_supports_pixmap_import_export(ScreenPtr screen)
{
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
return glamor_priv-dri3_enabled;
}
-int
-glamor_dri3_fd_from_pixmap(ScreenPtr screen,
- PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
+_X_EXPORT int
+glamor_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
@@ -600,7 +600,7 @@ glamor_dri3_fd_from_pixmap(ScreenPtr screen,
}
int
-glamor_dri3_name_from_pixmap(PixmapPtr pixmap)
+glamor_name_from_pixmap(PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 89e7d80..20988f4 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -173,21 +173,23 @@ extern _X_EXPORT int
glamor_egl_dri3_fd_name_from_tex(ScreenPtr, PixmapPtr,
unsigned int, Bool,
CARD16 *, CARD32 *);
-/* @glamor_is_dri3_support_enabled: Returns if DRI3 support is enabled.
+/* @glamor_supports_pixmap_import_export: Returns whether
+ * glamor_fd_from_pixmap(), glamor_name_from_pixmap(), and
+ * glamor_pixmap_from_fd() are supported.
*
* @screen: Current screen pointer.
*
- * To have DRI3 support enabled, glamor and glamor_egl need to be initialized,
- * and glamor_egl_init_textured_pixmap need to be called. glamor also
- * has to be compiled with gbm support.
- * The EGL layer need to have the following extensions working:
+ * To have DRI3 support enabled, glamor and glamor_egl need to be
+ * initialized. glamor also has to be compiled with gbm support.
+ *
+ * The EGL layer needs to have the following extensions working:
+ *
* .EGL_KHR_gl_texture_2D_image
* .EGL_EXT_image_dma_buf_import
- * If DRI3 support is not enabled, the following helpers will return an error.
* */
-extern _X_EXPORT Bool glamor_is_dri3_support_enabled(ScreenPtr screen);
+extern _X_EXPORT Bool glamor_supports_pixmap_import_export(ScreenPtr screen);
-/* @glamor_dri3_fd_from_pixmap: DRI3 helper to get a dma-buf fd from a pixmap.
+/* @glamor_fd_from_pixmap: Get a dma-buf fd from a pixmap.
*
* @screen: Current screen pointer.
* @pixmap: The pixmap from which we want the fd.
@@ -198,22 +200,26 @@ extern _X_EXPORT Bool
glamor_is_dri3_support_enabled(ScreenPtr screen);
* content.
* Returns the fd on success, -1 on error.
* */
-extern _X_EXPORT int glamor_dri3_fd_from_pixmap(ScreenPtr screen,
-PixmapPtr pixmap,
-CARD16 *stride, CARD32 *size);
+extern _X_EXPORT int glamor_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap,
+ CARD16 *stride, CARD32 *size);
-/* @glamor_dri3_name_from_pixmap: helper to get an gem name from a pixmap.
+/**
+ * @glamor_name_from_pixmap: Gets a gem name from a pixmap.
*
* @pixmap: The pixmap from which we want the gem name.
*
- * the pixmap and the buffer associated by the gem name will share the same
- * content. This function can be used by the DDX to support DRI2, but needs
- * glamor DRI3 support to be activated.
+ * the pixmap and the buffer associated by the gem name will share the
+ * same content. This function can be used by the DDX to support DRI2,
+ * and needs the same set of buffer export GL extensions as DRI3
+ * support.
+ *
* Returns the name on success, -1 on error.
* */
-extern _X_EXPORT int glamor_dri3_name_from_pixmap(PixmapPtr pixmap);
+extern _X_EXPORT int glamor_name_from_pixmap(PixmapPtr pixmap,
+ CARD16 *stride, CARD32 *size);
-/* @glamor_egl_dri3_pixmap_from_fd: DRI3 helper to get a pixmap from a dma-buf
fd.
+/* @glamor_pixmap_from_fd: Creates a pixmap to wrap a dma-buf fd.
*
* @screen: Current screen pointer.
* @fd: The dma-buf fd to import.
@@ -225,13 +231,13 @@ extern _X_EXPORT int
glamor_dri3_name_from_pixmap(PixmapPtr pixmap);
*
* Returns a valid pixmap if the import succeeded, else NULL.
* */
-extern _X_EXPORT PixmapPtr
[PATCH 4/6] xorg: Connect up the glamor XV code, xorg DDX-only for now.
Porting this code to be non-xorg-dependent is going to take
significant hacking, so just dump it in the glamoregl module for the
moment, so I can hack on it while regression testing.
v2: Fix compiler warnings by adding #include dix-config.h at the top,
don't try to auto-init (I'll try to fix the xv ABI later).
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/Makefile.am| 1 -
glamor/glamor.h | 5 -
glamor/glamor_eglmodule.c | 2 +-
glamor/glamor_xv.c| 17 ++---
hw/xfree86/glamor_egl/Makefile.am | 1 +
5 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/glamor/Makefile.am b/glamor/Makefile.am
index 12a57c4..77492bc 100644
--- a/glamor/Makefile.am
+++ b/glamor/Makefile.am
@@ -37,7 +37,6 @@ libglamor_la_SOURCES = \
glamor_window.c\
glamor_fbo.c\
glamor_compositerects.c\
- glamor_xv.c\
glamor_utils.h\
glamor.h
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 08ffd26..89e7d80 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -35,6 +35,9 @@
#include picturestr.h
#include fb.h
#include fbpict.h
+#ifdef GLAMOR_FOR_XORG
+#include xf86xv.h
+#endif
struct glamor_context;
@@ -434,7 +437,7 @@ extern _X_EXPORT Bool glamor_poly_line_nf(DrawablePtr
pDrawable, GCPtr pGC,
extern _X_EXPORT Bool glamor_poly_lines_nf(DrawablePtr drawable, GCPtr gc,
int mode, int n, DDXPointPtr
points);
-#if 0
+#ifdef GLAMOR_FOR_XORG
extern _X_EXPORT XF86VideoAdaptorPtr glamor_xv_init(ScreenPtr pScreen,
int num_texture_ports);
#endif
diff --git a/glamor/glamor_eglmodule.c b/glamor/glamor_eglmodule.c
index fb5b855..d7e1836 100644
--- a/glamor/glamor_eglmodule.c
+++ b/glamor/glamor_eglmodule.c
@@ -41,7 +41,7 @@ static XF86ModuleVersionInfo VersRec = {
MODINFOSTRING1,
MODINFOSTRING2,
XORG_VERSION_CURRENT,
-0, 5, 1, /* version */
+1, 0, 0, /* version */
ABI_CLASS_ANSIC,/* Only need the ansic layer */
ABI_ANSIC_VERSION,
MOD_CLASS_NONE,
diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index dc39476..a4ad031 100644
--- a/glamor/glamor_xv.c
+++ b/glamor/glamor_xv.c
@@ -32,10 +32,14 @@
* Xv acceleration implementation
*/
-#include glamor_priv.h
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
-#ifdef GLAMOR_XV
#include xf86xv.h
+#define GLAMOR_FOR_XORG
+#include glamor_priv.h
+
#include X11/extensions/Xv.h
#include fourcc.h
/* Reference color space transform data */
@@ -614,12 +618,3 @@ glamor_xv_init(ScreenPtr screen, int num_texture_ports)
}
return adapt;
}
-#else
-#if 0
-XF86VideoAdaptorPtr
-glamor_xv_init(ScreenPtr screen, int num_texture_ports)
-{
-return NULL;
-}
-#endif
-#endif
diff --git a/hw/xfree86/glamor_egl/Makefile.am
b/hw/xfree86/glamor_egl/Makefile.am
index 827e033..bb1b511 100644
--- a/hw/xfree86/glamor_egl/Makefile.am
+++ b/hw/xfree86/glamor_egl/Makefile.am
@@ -24,6 +24,7 @@ module_LTLIBRARIES = libglamoregl.la
libglamoregl_la_SOURCES = \
$(top_srcdir)/glamor/glamor_egl.c \
$(top_srcdir)/glamor/glamor_eglmodule.c \
+ $(top_srcdir)/glamor/glamor_xv.c \
$()
libglamoregl_la_LDFLAGS = \
--
1.9.rc1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
On Mon, Feb 24, 2014 at 05:56:41PM -0500, James Cloos wrote: PH == Peter Hutterer peter.hutte...@who-t.net writes: PH the less-intrusive alternative would be to force only the indicator state PH down to the slaves. won't change keyboard behaviour as seen by the client PH and still has the effect that most people expect from their keyboards. PH comments? So hitting compose on one keyboard would light the compose led on all associated keyboards but only intitiate a compose sequence on the one? Or caps-lock? Or level shifts? Or group toggles? If I read that right, that seems even worse. I'd want indicator state on a phisical kbd always to match what that kbd will do. I'm not certain about the other two options, though. Given that I use a keyboard which shows up as two usb endpoints, and each endpoint is a separate slave kbd to the shared master, I'd prefer that shift, et alia states for one slave apply to all. But that may not be right for everyone's setup. Perhaps xinput(1) should be able to configure whether given slaves share such state with their brethren? the event processing in the server treats slave and master device separately, even when attached. So if you hit capslock on your physical keyboard, you'll toggle the lock on that slave device. The same event is then processed throught he master device, where it will also toggle the lock. The physical keyboard will have the LED on, the virtual-only master keyboard too but you obviously can't see that. Now, when you press caps on your second keyboard, you'll enable it on that keyboard, the event passes through the master and caps lock will be disabled on the master, despite being enabled on both slave devices, and both LEDs being on. The master copies the keyboard, so you can have two physical keyboards with two different layouts. So in the case where you have compose:caps on one keyboard, if you it caps first, then compose on the other keyboard, you'll get an uppercase compose sequence on the master, regardless which keyboard you now type on. This is the current state. It's not ideal... I'd want indicator state on a phisical kbd always to match what that kbd will do. that's the problem here, it's really hard to tell in some circumstances, but one thing is sure: we're not doing that at the moment. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
Guillem Jover guil...@hadrons.org writes: I'm probably missing something (maybe this header cannot include a dix-config.h or equivalent), but why not use AC_C_BIGENDIAN? Yeah, this would be nicer -- AC_C_BIGENDIAN should be more reliable than any presumption about compiler defined symbols. -- keith.pack...@intel.com pgp9kEjIKPdt5.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
On Mon, Feb 24, 2014 at 04:00:28PM -0800, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: there is no good solution here, it's just a question which foot we prefer shooting at. Yeah, that part seems clear enough at least. So, it seems like we have a list of options: 1) Mirror nothing. Indicators and modifiers for each slave are independent. Events seen through the slave device will not have modifier bits set. Event seen through the master device will have the union of all slave device modifiers. Problems: Users may be confused by the mis-match between indicator state and locking modifier state for master devices. Benefits: Slave devices will operate independently and will not report mysterious modifier bits. again, I need to point out here that slaves operate independently, but this is not what the user would see. XI2 applications (should) care about master devices and floating slaves, if an application cares about attached slaves that should only be for very device-specific handling. gnome-settings-daemon currently does this for wacom pad buttons, but this is not for your average client, and _certainly_ not for core clients which see the merged master device state. (see also my reply to JimC here) 2) Mirror indicators. Indicators for slave devices are driven by the master; all slave device indicators match the master state. Problems: Users may be confused by the mis-match between indicator state and associated locking modifier state on slave devices. Question: Will the locking keys operate oddly on the other slave devices? If the state of the local locking key is not reflected by the local indicator, what happens when you press the local locking modifier which is logically 'up' while the matching indicator says 'down'? Benefit: Users will see correct indicators for locking modifiers for events sent through the master device. see my comment on 1, the only time this would be noticed is in XI2 applications that handle attached slave devices. 3) Mirror locking modifiers and indicators. Locking modifiers and their associated indicators are driven by the master. All slave indicators and locking modifiers are sent to the master and then distributed to all other slaves. Problems: Slave devices will end up sending locking modifier state from other associated slave devices, but not other modifier state. Benefit: Slave locking modifiers should act consistently with the associated indicators (see question for 2 above). 4) Mirror all modifiers All modifiers for all slave devices are mirrored through the master so that all slaves exactly track all modifiers. Problem: Slave devices will see shift/ctrl/alt modifiers from other slaves, as well as seeing locking modifiers from other slaves. Benefit: All modifiers will the same as seen through both the slave and master devices, and all indicators will match everywhere. 1) is what we do today, and the lack of indicator tracking sucks for users. 2) and 3) differ only slightly, and the question I have for 2) is whether the locking keys will act 'funny'. If so, then 3) is clearly a better plan. yes, they will act funny as in the indicator still doesn't reflect the slave device's state. so you still get situations where master has caps lock on, slave 1 has caps lock on, but slave 2 has the LED on but caps off. you'd then get two different xkb syms from master and slave (XI2 only, core won't see it, XI1 won't ever see the master device). I do lean to 3) at this point, just because that way the indicators correctly reflect events sent to both slave and master devices, which at least seems a bit more consistent. I'm fine with either 3 or 4 tbh, though note that from the user's POV we already do 4. open xterm, hit ctrl one one keyboard and C on the other and you'll get a ctrl+c through the core protocol and from the XI2 master. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Automatic modifier update of slave devices
Peter Hutterer peter.hutte...@who-t.net writes: I'm fine with either 3 or 4 tbh, though note that from the user's POV we already do 4. open xterm, hit ctrl one one keyboard and C on the other and you'll get a ctrl+c through the core protocol and from the XI2 master. Right, I wanted to enumerate all of the choices and differences between them, even though I think we all agree that differences visible through slave devices are largely irrelevant. In any case, I think the only concern here is that the state of the master lock indicators get reflected to all slave devices, and whether you do that by mirroring the indicators, lock modifiers or all of the modifiers is largely irrelevant. I think Daniel's concern was that by trying to reflect all of the modifiers, even those which may mis-match between different slaves, you may accidentally cause further damage. Would it be difficult to map the non-standard modifier bits by keysym and try to reflect those accurately? -- keith.pack...@intel.com pgptUKUcd5fGY.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
On 02/24/14 04:52 AM, walter harms wrote: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. You're 25 years too late to stop that - we already define it for every architecture and always have, because there's enough differences in what they #define for their platform: http://cgit.freedesktop.org/xorg/xserver/tree/include/servermd.h -- -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: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le
On 02/24/14 08:19 AM, Guillem Jover wrote: On Mon, 2014-02-24 at 08:09:33 -0800, Keith Packard wrote: walter harms wha...@bfs.de writes: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. That would risk breaking little endian platforms that failed to define this. Safest to limit the scope of the change the PPC platforms, where __LITTLE_ENDIAN__ is a new option, and hence likely to be set correctly. I would sure like to be able to detect the difference between 'this option is set to false' and 'this option isn't defined'; is there something that PPC defines in both cases, and sets to TRUE in one case and FALSE in the other? I'm probably missing something (maybe this header cannot include a dix-config.h or equivalent), but why not use AC_C_BIGENDIAN? Because tradition! And because Imake didn't work that way! But mostly because no one has had the patience to change it since, and to make a servermd.h.in that configure can generate servermd.h from to install for use by driver builds that may not have the exact same macros set by AC_C_BIGENDIAN in their builds. -- -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: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
On 14-02-24 05:27 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0 gets pervasive. Sure would be nice if automake 2.0 had a compatibility mode that would let us continue with our current scheme. Has anyone looked at the 2.0 code to see if there's a way we can avoid changing how we build things just to make autofu happy? Does not look like there is any new code in git. http://git.savannah.gnu.org/cgit/automake.git Being a 2.0 version, some changes will not be backwards compatible. According to their PLANS, the way it works now is a historical accident and they are determined to correcting it. From the PLANS/subdir-objs.txt file from Automake 1.14 package: The fact that Automake-generated Makefiles place compiled object files in the current directory by default, also when the corresponding source file is in a subdirectory, is basically an historical accident, due to the fact that the 'subdir-objects' option had only been introduced in April 1999, starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never made the default (likely to avoid backwards-compatibility issues). Since I believe the behaviour enabled by the 'subdir-objects' is the most useful one, and in fact the *only* natural one, I'd like to make it the only one available, simplifying the Automake implementation and APIs a little in the process. I originally submitted a patch series which fixes all of the makefiles using git links. It's not the best solution, but it shows it is a reasonable endeavour. Reviewers asked for a better solution which I couldn't provide alone. Jon Turney responded with patches (already reviewed) which fixes most of the DDX code reuse case. That leaves miinitext for which Daniel Stone provided a hint. This is the hardest one. Mark Kettenis suggested how os-support source can be organized and looks fairly simple. I provided a couple patches to fix the test makefile and one of them has already landed in master. In my opinion, this is energy well spent. Time is on our side (rarely happens) as the issue has been detected early thanks to warnings in 1.14. The reusable source code will be better organized, which is not a negligible benefit. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-input-synaptics 6/8] Ignore motion the first X ms after a clickpad click
On Fri, Feb 21, 2014 at 10:31:42AM +0100, Hans de Goede wrote:
This fixes my #1 anoyance with clickpads, where 2 out of 3 clicks turn into
a click + drag unless I hold my finger really really still.
do we really need a property and an option for this? I'm tempted to try for
a hardcoded value here and skip the configurable option until we either find
a value that works well enough for everyone [1] or really have to expose yet
another option.
Cheers,
Peter
[1] lol
Signed-off-by: Hans de Goede hdego...@redhat.com
---
include/synaptics-properties.h | 2 ++
man/synaptics.man | 10 ++
src/properties.c | 10 ++
src/synaptics.c| 12
src/synapticsstr.h | 2 ++
tools/synclient.c | 1 +
6 files changed, 37 insertions(+)
diff --git a/include/synaptics-properties.h b/include/synaptics-properties.h
index 19bd2b2..20026fc 100644
--- a/include/synaptics-properties.h
+++ b/include/synaptics-properties.h
@@ -51,6 +51,8 @@
/* 8 bit (BOOL) */
#define SYNAPTICS_PROP_CLICKPAD Synaptics ClickPad
+#define SYNAPTICS_PROP_CLICKPAD_IGNORE_MOTION_TIME Synaptics ClickPad
Ignore Motion Time
+
/* 8 bit (BOOL) */
#define SYNAPTICS_PROP_TAP_FAST Synaptics Tap FastTap
diff --git a/man/synaptics.man b/man/synaptics.man
index f2d178f..04d1ca0 100644
--- a/man/synaptics.man
+++ b/man/synaptics.man
@@ -133,6 +133,11 @@ Whether the device is a click pad. See
.B ClickPad support
for more details. Property: Synaptics ClickPad
.TP 7
+.BI Option \*qClickPadIgnoreMotionTime\*q \*q integer \*q
+Time (in milliseconds) to ignore motion after a clickpad click. See
+.B ClickPad support
+for more details. Property: Synaptics ClickPad Ignore Motion Time
+.TP 7
.BI Option \*qVertEdgeScroll\*q \*q boolean \*q
Enable vertical scrolling when dragging along the right edge. Property:
Synaptics Edge Scrolling
@@ -717,6 +722,11 @@ ClickPads provide software emulated buttons through
These buttons enable areas on the touchpad to perform as right or middle
mouse button. When the user performs a click within a defined soft button
area, a right or middle click is performed.
+.LP
+Since pressing the pad to click often generates unwanted motion events,
+motion is ignored for
+.B Option ClickPadIgnoreMotionTime
+milliseconds after a click.
.SH DEVICE PROPERTIES
Synaptics 1.0 and higher support input device properties if the driver is
diff --git a/src/properties.c b/src/properties.c
index d4fd3cb..b7bee89 100644
--- a/src/properties.c
+++ b/src/properties.c
@@ -58,6 +58,7 @@ Atom prop_tap_time = 0;
Atom prop_tap_move = 0;
Atom prop_tap_durations = 0;
Atom prop_clickpad = 0;
+Atom prop_clickpad_ignore_motion_time = 0;
Atom prop_middle_timeout = 0;
Atom prop_twofinger_pressure = 0;
Atom prop_twofinger_width = 0;
@@ -219,6 +220,9 @@ InitDeviceProperties(InputInfoPtr pInfo)
InitAtom(pInfo-dev, SYNAPTICS_PROP_TAP_DURATIONS, 32, 3, values);
prop_clickpad =
InitAtom(pInfo-dev, SYNAPTICS_PROP_CLICKPAD, 8, 1, para-clickpad);
+prop_clickpad_ignore_motion_time =
+InitAtom(pInfo-dev, SYNAPTICS_PROP_CLICKPAD_IGNORE_MOTION_TIME, 32,
1,
+ para-clickpad_ignore_motion_time);
prop_middle_timeout =
InitAtom(pInfo-dev, SYNAPTICS_PROP_MIDDLE_TIMEOUT, 32, 1,
para-emulate_mid_button_time);
@@ -468,6 +472,12 @@ SetProperty(DeviceIntPtr dev, Atom property,
XIPropertyValuePtr prop,
para-clickpad = *(BOOL *) prop-data;
}
+else if (property == prop_clickpad_ignore_motion_time) {
+if (prop-size != 1 || prop-format != 32 || prop-type !=
XA_INTEGER)
+return BadMatch;
+
+para-clickpad_ignore_motion_time = *(INT32 *) prop-data;
+}
else if (property == prop_middle_timeout) {
if (prop-size != 1 || prop-format != 32 || prop-type !=
XA_INTEGER)
return BadMatch;
diff --git a/src/synaptics.c b/src/synaptics.c
index 84e704b..bd14100 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -683,6 +683,7 @@ set_default_parameters(InputInfoPtr pInfo)
pars-tap_time_2 = xf86SetIntOption(opts, MaxDoubleTapTime, 180);
pars-click_time = xf86SetIntOption(opts, ClickTime, 100);
pars-clickpad = xf86SetBoolOption(opts, ClickPad, pars-clickpad);
/* Probed */
+pars-clickpad_ignore_motion_time = xf86SetIntOption(opts,
ClickPadIgnoreMotionTime, 100);
/* middle mouse button emulation on a clickpad? nah, you're joking */
middle_button_timeout = pars-clickpad ? 0 : 75;
pars-emulate_mid_button_time =
@@ -1043,6 +1044,7 @@ SynapticsReset(SynapticsPrivate * priv)
priv-count_packet_finger = 0;
priv-finger_state = FS_UNTOUCHED;
priv-last_motion_millis = 0;
+priv-clickpad_click_millis = 0;
priv-inside_button_area = FALSE;
priv-tap_state = TS_START;
Re: [PATCH xf86-input-synaptics 8/8] Wait for *new* coordinates on a clickpad click before reporting the click
On Fri, Feb 21, 2014 at 10:31:44AM +0100, Hans de Goede wrote:
It is possible for a click to get reported before any related touch events
get reported, here is the relevant part of an evemu-record session on a T440s:
E: 3.985585 # SYN_REPORT (0) --
E: 3.997419 0003 0039 -001# EV_ABS / ABS_MT_TRACKING_ID -1
E: 3.997419 0001 014a # EV_KEY / BTN_TOUCH0
E: 3.997419 0003 0018 # EV_ABS / ABS_PRESSURE 0
E: 3.997419 0001 0145 # EV_KEY / BTN_TOOL_FINGER 0
E: 3.997419 # SYN_REPORT (0) --
E: 5.117881 0001 0110 0001# EV_KEY / BTN_LEFT 1
E: 5.117881 # SYN_REPORT (0) --
E: 5.133422 0003 0039 0187# EV_ABS / ABS_MT_TRACKING_ID 187
E: 5.133422 0003 0035 3098# EV_ABS / ABS_MT_POSITION_X3098
E: 5.133422 0003 0036 3282# EV_ABS / ABS_MT_POSITION_Y3282
E: 5.133422 0003 003a 0046# EV_ABS / ABS_MT_PRESSURE 46
E: 5.133422 0001 014a 0001# EV_KEY / BTN_TOUCH1
E: 5.133422 0003 3102# EV_ABS / ABS_X3102
E: 5.133422 0003 0001 3282# EV_ABS / ABS_Y3282
E: 5.133422 0003 0018 0046# EV_ABS / ABS_PRESSURE 46
E: 5.133422 0001 0145 0001# EV_KEY / BTN_TOOL_FINGER 1
E: 5.133422 # SYN_REPORT (0) --
Notice the BTN_LEFT event all by itself!
If this happens, it may lead to the following problem scenario:
-touch the touchpad in its right click area
-let go of the touchpad
-rapidly click in the middle area, so that BTN_LEFT gets reported before the
new coordinates (such as seen in the trace above, this may require some
practicing with evemu-record to reproduce)
-the driver registers the click as a right click because it uses the
old coordinates from the cumulative coordinates to determine the
click location
This commit fixes this by:
1) Resetting the cumulative coordinates not only when no button is pressed,
but also when there is no finger touching the touchpad, so that when
we do get a touch the cumulative coordinates start at the right place
2) Delaying processing the BTN_LEFT down transition if there is no finger
touching the touchpad
This approach has one downside, if we wrongly identify a touchpad as
a clickpad, then the left button won't work unless the user touches the
touchpad while clicking the left button.
If we want we can fix this by doing something like this:
1) Making update_hw_button_state return a delay; and
2) Tracking that we've delayed BTN_LEFT down transition processing; and
3) When we've delayed BTN_LEFT down transition return a small delay value; and
4) If when we're called again we still don't have a finger down, just
treat the click as a BTN_LEFT
But this is not worth the trouble IMHO, the proper thing to do in this
scenario is to fix the mis-identification of the touchpad as a clickpad.
indeed, this is not something we need to hack around.
this series is Reviewed-by: Peter Hutterer peter.hutte...@who-t.net except
for the property patch, I'll do some more testing with my clickpad over the
week though.
Cheers,
Peter
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/eventcomm.c | 5 +++--
src/synaptics.c | 7 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/eventcomm.c b/src/eventcomm.c
index fe57aa8..231afbc 100644
--- a/src/eventcomm.c
+++ b/src/eventcomm.c
@@ -675,8 +675,9 @@ EventReadHwState(InputInfoPtr pInfo,
SynapticsResetTouchHwState(hw, FALSE);
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
+/* Reset cumulative values if buttons were not previously pressed,
+ * or no finger was previously present. */
+if ((!hw-left !hw-right !hw-middle) || hw-z
para-finger_low) {
hw-cumulative_dx = hw-x;
hw-cumulative_dy = hw-y;
sync_cumulative = TRUE;
diff --git a/src/synaptics.c b/src/synaptics.c
index bd14100..59fcf48 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2810,6 +2810,12 @@ update_hw_button_state(const InputInfoPtr pInfo,
struct SynapticsHwState *hw,
if (para-clickpad) {
/* hw-left is down, but no other buttons were already down */
if (!(priv-lastButtons 7) hw-left !hw-right
!hw-middle) {
+/* If the finger down event is delayed, the x and y
+ * coordinates are stale so we delay processing the click */
+if (hw-z para-finger_low) {
+hw-left = 0;
+goto out;
+}
if (is_inside_rightbutton_area(para, hw-x, hw-y)) {
hw-left = 0;
hw-right = 1;
@@ -2841,6 +2847,7 @@ update_hw_button_state(const InputInfoPtr pInfo, struct
SynapticsHwState *hw,
if
Re: [PATCH 6/6] glamor: Add support for DRI3.
Hi,
While for XWayland we want to provide our own dri3_open, we still want to have
glamor
enabling the dri3 support
That is rather a GLAMOR_NO_DRI3_SETUP flag
and
+if (glamor_egl-dri3_capable !(glamor_priv-flags GLAMOR_NO_DRI3)) {
+/* Tell the core that we have the interfaces for import/export
+ * of pixmaps.
+ */
+glamor_enable_dri3(screen);
+
+/* To do DRI3 device FD generation, we need to open a new fd
+ * to the same device we were handed in originally.
+ */
+glamor_egl-device_path = drmGetDeviceNameFromFd(glamor_egl-fd);
+
+if (!dri3_screen_init(screen, glamor_dri3_info)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ Failed to initialize DRI3.\n);
+}
+}
would be like that:
+if (glamor_egl-dri3_capable) {
+/* Tell the core that we have the interfaces for import/export
+ * of pixmaps.
+ */
+glamor_enable_dri3(screen);
+
+if (!(glamor_priv-flags GLAMOR_NO_DRI3_SETUP)) {
+/* To do DRI3 device FD generation, we need to open a new fd
+ * to the same device we were handed in originally.
+ */
+glamor_egl-device_path = drmGetDeviceNameFromFd(glamor_egl-fd);
+
+if (!dri3_screen_init(screen, glamor_dri3_info)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ Failed to initialize DRI3.\n);
+}
+}
+}
Otherwise, it looks fine.
Perhaps it would be better to detect if the device is a render-node or not,
and if it is a render-node, then prevent doing an IOCTL call for nothing.
Thanks,
Axel Davy
On 25/02/2014, Eric Anholt wrote :
The render-nodes case is untested.
v2: Add a flag for wayland to suppress the native DRI3 support.
Wayland isn't running as a master itself, so it can't do the auth
on its own and has to ask the compositor to do it for us. Dropped
XXX about randr provider -- the conclusion from discussion with
keithp was that if the driver's dri3_open for a provider on a
different screen, that's a core dri3 bug.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.h | 4 +-
glamor/glamor_egl.c | 78
+++
hw/xfree86/glamor_egl/Makefile.am | 5 ++-
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 20988f4..d3520ab 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -67,10 +67,12 @@ typedef enum glamor_pixmap_type {
#define GLAMOR_USE_SCREEN(1 1)
#define GLAMOR_USE_PICTURE_SCREEN(1 2)
#define GLAMOR_USE_EGL_SCREEN(1 3)
+#define GLAMOR_NO_DRI3 (1 4)
#define GLAMOR_VALID_FLAGS (GLAMOR_INVERTED_Y_AXIS \
| GLAMOR_USE_SCREEN\
| GLAMOR_USE_PICTURE_SCREEN \
- | GLAMOR_USE_EGL_SCREEN)
+ | GLAMOR_USE_EGL_SCREEN\
+ | GLAMOR_NO_DRI3)
/* @glamor_init: Initialize glamor internal data structure.
*
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 56d8913..c883777 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -50,6 +50,7 @@
#include glamor.h
#include glamor_priv.h
+#include dri3.h
static const char glamor_name[] = glamor;
@@ -68,6 +69,7 @@ struct glamor_egl_screen_private {
EGLDisplay display;
EGLContext context;
EGLint major, minor;
+char *device_path;
CreateScreenResourcesProcPtr CreateScreenResources;
CloseScreenProcPtr CloseScreen;
@@ -627,10 +629,67 @@ glamor_egl_has_extension(struct
glamor_egl_screen_private *glamor_egl,
return FALSE;
}
+static int
+glamor_dri3_open(ScreenPtr screen,
+ RRProviderPtr provider,
+ int *fdp)
+{
+ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+struct glamor_egl_screen_private *glamor_egl =
+glamor_egl_get_screen_private(scrn);
+int fd;
+drm_magic_t magic;
+
+fd = open(glamor_egl-device_path, O_RDWR|O_CLOEXEC);
+if (fd 0)
+return BadAlloc;
+
+/* Before FD passing in the X protocol with DRI3 (and increased
+ * security of rendering with per-process address spaces on the
+ * GPU), the kernel had to come up with a way to have the server
+ * decide which clients got to access the GPU, which was done by
+ * each client getting a unique (magic) number from the kernel,
+ * passing it to the server, and the server then telling the
+ * kernel which clients were authenticated for using the device.
+ *
+ * Now that we have FD passing, the server can just set up the
+ * authentication on its own and hand the prepared FD
