[PATCH xserver 1/3] docbook.am: global maintenance update - entities, images and olinking
Adding support in libX11 for html chunking caused a reorg of docbook.am as well as the xorg-sgml-doctools masterdb for olinking. The parameter img.src.path is added for pdf images. A searchpath to the root builddir is added for local entities, if present. This feature was initiated by xserver module and made available to all. The docbook.am makefile hides all the details and is identical for all 22 modules having DocBook documentation. It is included by a thin Makefile.am which requires no docbook knowledge. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- docbook.am | 116 1 files changed, 62 insertions(+), 54 deletions(-) diff --git a/docbook.am b/docbook.am index eb3bf0c..9377f5b 100644 --- a/docbook.am +++ b/docbook.am @@ -21,76 +21,84 @@ shelf_DATA = dist_shelf_DATA = $(docbook) $(chapters) if HAVE_XMLTO -# -# Generate DocBook/XML output formats with or without stylesheets -# - -# Stylesheets are available if the package xorg-sgml-doctools is installed if HAVE_STYLESHEETS -# The location where all cross reference databases are installed -sgmldbsdir = $(XORG_SGML_PATH)/X11/dbs -masterdb = $(sgmldbsdir)/masterdb$(suffix $@).xml -XMLTO_FLAGS = \ - --searchpath $(XORG_SGML_PATH)/X11\ - --searchpath $(abs_top_builddir) \ - --stringparam target.database.document=$(masterdb) \ - --stringparam current.docid=$(:.xml=)\ - --stringparam collect.xref.targets=no - -XMLTO_XHTML_FLAGS = \ - -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl \ - --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css - -XMLTO_FO_FLAGS = \ - -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl -endif HAVE_STYLESHEETS +XMLTO_SEARCHPATH_FLAGS = \ + --searchpath $(XORG_SGML_PATH)/X11\ + --searchpath $(abs_top_builddir) +XMLTO_HTML_OLINK_FLAGS = \ + --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \ + --stringparam current.docid=$(:.xml=) +XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl +XMLTO_HTML_CSS_STYLESHEET_FLAGS = --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css +XMLTO_HTML_FLAGS = \ + $(XMLTO_SEARCHPATH_FLAGS) \ + $(XMLTO_HTML_STYLESHEET_FLAGS) \ + $(XMLTO_HTML_CSS_STYLESHEET_FLAGS) \ + $(XMLTO_HTML_OLINK_FLAGS) shelf_DATA += $(docbook:.xml=.html) -%.html: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) xhtml-nochunks $ - -if HAVE_FOP -shelf_DATA += $(docbook:.xml=.pdf) $(docbook:.xml=.ps) -%.pdf: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop pdf $ -%.ps: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop ps $ -endif HAVE_FOP +%.html: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $ if HAVE_XMLTO_TEXT + shelf_DATA += $(docbook:.xml=.txt) %.txt: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) txt $ + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $ endif HAVE_XMLTO_TEXT -# -# Generate documents cross-reference target databases -# +if HAVE_FOP +XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/ +XMLTO_PDF_OLINK_FLAGS = \ + --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \ + --stringparam current.docid=$(:.xml=) +XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl + +XMLTO_FO_FLAGS = \ + $(XMLTO_SEARCHPATH_FLAGS) \ + $(XMLTO_FO_STYLESHEET_FLAGS)\ + $(XMLTO_FO_IMAGEPATH_FLAGS) \ + $(XMLTO_PDF_OLINK_FLAGS) + +shelf_DATA += $(docbook:.xml=.pdf) +%.pdf: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $ -# This is only possible if the xorg-sgml-doctools package is installed -if HAVE_STYLESHEETS -if HAVE_XSLTPROC +shelf_DATA += $(docbook:.xml=.ps) +%.ps: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $ +endif HAVE_FOP -# DocBook/XML generated document cross-reference database -shelf_DATA += $(docbook:.xml=.html.db) $(docbook:.xml=.fo.db) +# Generate documents cross-reference target databases +if HAVE_XSLTPROC -# Generate DocBook/XML document cross-reference database -# Flags for the XSL Transformation processor generating xref target databases -XSLTPROC_FLAGS = \ +XSLT_SEARCHPATH_FLAGS =\ --path $(XORG_SGML_PATH)/X11 \ - --path $(abs_top_builddir)\ - --stringparam targets.filename $@ \ -
[PATCH xserver 2/3] docbook.am: embed css styles inside the HTML HEAD element
Rather than referring to the external xorg.css stylesheet, embed the content of the file in the html output produced. This is accomplished by using version 1.10 of xorg-xhtml.xsl. This makes the whole html docs tree much more relocatable. In addition, it eliminates xorg.css as a runtime file which makes xorg-sgml-doctools a build time only package. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- docbook.am |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/docbook.am b/docbook.am index 9377f5b..bba4d54 100644 --- a/docbook.am +++ b/docbook.am @@ -30,11 +30,9 @@ XMLTO_HTML_OLINK_FLAGS = \ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \ --stringparam current.docid=$(:.xml=) XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl -XMLTO_HTML_CSS_STYLESHEET_FLAGS = --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css XMLTO_HTML_FLAGS = \ $(XMLTO_SEARCHPATH_FLAGS) \ $(XMLTO_HTML_STYLESHEET_FLAGS) \ - $(XMLTO_HTML_CSS_STYLESHEET_FLAGS) \ $(XMLTO_HTML_OLINK_FLAGS) shelf_DATA += $(docbook:.xml=.html) -- 1.7.4.1 ___ 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 xserver 3/3] devbook.am: maintenance update from docbook.am
The developer docs are generated from a subset of docbook.am which is sometimes updated. The one difference for xserver is the embedded css style in the HEAD element. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- devbook.am | 45 +++-- 1 files changed, 19 insertions(+), 26 deletions(-) diff --git a/devbook.am b/devbook.am index 4e23bb7..400b2ca 100644 --- a/devbook.am +++ b/devbook.am @@ -20,43 +20,36 @@ noinst_DATA = # DocBook/XML file with chapters, appendix and images it includes dist_noinst_DATA = $(docbook) $(chapters) -# -# Generate DocBook/XML output formats with or without stylesheets -# - -# Stylesheets are available if the package xorg-sgml-doctools is installed if HAVE_STYLESHEETS -# The location where all cross reference databases are installed -XMLTO_FLAGS = \ - --searchpath $(XORG_SGML_PATH)/X11\ +XMLTO_HTML_FLAGS = \ + --searchpath $(XORG_SGML_PATH)/X11\ --searchpath $(abs_top_builddir) \ - --stringparam current.docid=$(:.xml=) - -XMLTO_XHTML_FLAGS = \ - -m $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl \ - --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css - -XMLTO_FO_FLAGS = \ - -m $(STYLESHEET_SRCDIR)/xorg-fo.xsl -endif HAVE_STYLESHEETS + -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl noinst_DATA += $(docbook:.xml=.html) %.html: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) xhtml-nochunks $ + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $ + +if HAVE_XMLTO_TEXT +noinst_DATA += $(docbook:.xml=.txt) +%.txt: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $ +endif HAVE_XMLTO_TEXT if HAVE_FOP +XMLTO_FO_FLAGS = \ + --searchpath $(XORG_SGML_PATH)/X11\ + --searchpath $(abs_top_builddir) \ + --stringparam img.src.path=$(abs_builddir)/ \ + -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl + noinst_DATA += $(docbook:.xml=.pdf) $(docbook:.xml=.ps) %.pdf: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop pdf $ + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $ %.ps: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop ps $ + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $ endif HAVE_FOP - -if HAVE_XMLTO_TEXT -noinst_DATA += $(docbook:.xml=.txt) -%.txt: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) txt $ -endif HAVE_XMLTO_TEXT +endif HAVE_STYLESHEETS CLEANFILES = $(noinst_DATA) -- 1.7.4.1 ___ 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] int10: Delete unused _PC variant methods.
I retract this patch. I didn't see this section of
hw/xfree86/int10/Makefile.am:
if I386_VIDEO
I386_VIDEO_CFLAGS = -D_PC
endif
configure.ac is setting I386_VIDEO on i*86 and x86_64/amd64.
Jamey
On Tue, Sep 13, 2011 at 05:36:48PM -0500, Jamey Sharp wrote:
I can't find any evidence that _PC has ever been defined.
Patch created by fixing the documentation that referenced _PC, and
running:
for f in `git grep -Fwl _PC -- '*.[ch]'`; do
unifdef -U_PC -B $f | sponge $f;
done
Signed-off-by: Jamey Sharp ja...@minilop.net
Cc: Tomas Carnecky t...@dbservice.com
---
Tomas, you're the last person who touched anything _PC-related, and it
looks like you were building with _PC defined, so perhaps you could
comment on where this symbol comes from?
hw/xfree86/int10/INT10.HOWTO |6 +--
hw/xfree86/int10/generic.c| 85
-
hw/xfree86/int10/helper_exec.c| 64 --
hw/xfree86/int10/helper_mem.c |2 -
hw/xfree86/int10/xf86int10.c |6 --
hw/xfree86/int10/xf86int10.h |3 -
hw/xfree86/os-support/linux/int10/linux.c |9 ---
7 files changed, 1 insertions(+), 174 deletions(-)
diff --git a/hw/xfree86/int10/INT10.HOWTO b/hw/xfree86/int10/INT10.HOWTO
index e2154c1..7f734fc 100644
--- a/hw/xfree86/int10/INT10.HOWTO
+++ b/hw/xfree86/int10/INT10.HOWTO
@@ -121,10 +121,6 @@ IPC to map the appropriate real mode memory image to
address 0 in
virtual address space just prior to execution may be found in
xfree86/os-support/linux/int10/linux.c.
-On non-PC like platforms emulation of certain PC features such as
-initialization of BIOS int vectors, sys_BIOS constants or PCI config
-method 1 can be turned on by defining _PC.
-
I. Setup Code
-
@@ -316,7 +312,7 @@ is provided. The use should be self explanatory.
Register and memory access functions are provided in helper_mem.c.
The PIO register access functions can trap access to PCI config space
-access register (config method 1) if _PC is not defined.
+access register (config method 1).
A header file 'defines.h' is required to define OS/emulator specific
ways to access memory and xf86 CPU registers: Defines need to be
diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index fe8bb69..77eb917 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -55,10 +55,6 @@ int10MemRec genericMem = {
static void MapVRam(xf86Int10InfoPtr pInt);
static void UnmapVRam(xf86Int10InfoPtr pInt);
-#ifdef _PC
-#define GET_HIGH_BASE(x) (((V_BIOS + (x) + getpagesize() - 1)/getpagesize())
\
- * getpagesize())
-#endif
static void *sysMem = NULL;
@@ -75,7 +71,6 @@ static void *sysMem = NULL;
* etc.). How do we know that \c pci_device_read_rom will return the
* legacy VGA BIOS image?
*/
-#ifndef _PC
static int
read_legacy_video_BIOS(struct pci_device *dev, unsigned char *Buf)
{
@@ -115,7 +110,6 @@ read_legacy_video_BIOS(struct pci_device *dev, unsigned
char *Buf)
return Len;
}
-#endif /* _PC */
xf86Int10InfoPtr
@@ -161,76 +155,6 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
* registers into this range.
*/
MapVRam(pInt);
-#ifdef _PC
-if (!sysMem)
- sysMem = xf86MapVidMem(screen, VIDMEM_MMIO, V_BIOS,
-BIOS_SIZE + SYS_BIOS - V_BIOS);
-INTPriv(pInt)-sysMem = sysMem;
-
-if (xf86ReadBIOS(0, 0, base, LOW_PAGE_SIZE) 0) {
- xf86DrvMsg(screen, X_ERROR, Cannot read int vect\n);
- goto error1;
-}
-
-/*
- * Retrieve everything between V_BIOS and SYS_BIOS as some system BIOSes
- * have executable code there. Note that xf86ReadBIOS() can only read in
- * 64kB at a time.
- */
-memset((char *)base + V_BIOS, 0, SYS_BIOS - V_BIOS);
-#if 0
-for (cs = V_BIOS; cs SYS_BIOS; cs += V_BIOS_SIZE)
- if (xf86ReadBIOS(cs, 0, (unsigned char *)base + cs, V_BIOS_SIZE)
- V_BIOS_SIZE)
- xf86DrvMsg(screen, X_WARNING,
-Unable to retrieve all of segment 0x%06X.\n, cs);
-#endif
-INTPriv(pInt)-highMemory = V_BIOS;
-
-if (xf86IsEntityPrimary(entityIndex) !(initPrimary(options))) {
- if (!xf86int10GetBiosSegment(pInt, (unsigned char *)sysMem - V_BIOS))
- goto error1;
-
- set_return_trap(pInt);
-
- pInt-Flags = Flags (SET_BIOS_SCRATCH | RESTORE_BIOS_SCRATCH);
- if (! (pInt-Flags SET_BIOS_SCRATCH))
- pInt-Flags = ~RESTORE_BIOS_SCRATCH;
- xf86Int10SaveRestoreBIOSVars(pInt, TRUE);
-
-} else {
- const BusType location_type = xf86int10GetBiosLocationType(pInt);
- int bios_location = V_BIOS;
-
-reset_int_vect(pInt);
- set_return_trap(pInt);
-
- switch (location_type) {
[PATCH] configure.ac: Remove unreachable check for VM86 headers.
configure --with-int10=yes is not a valid configuration, and the check for sys/vm86.h and sys/io.h is not used. Delete it. Signed-off-by: Jamey Sharp ja...@minilop.net --- configure.ac|4 include/dix-config.h.in |6 -- 2 files changed, 0 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index 93cd6a9..06cf9bf 100644 --- a/configure.ac +++ b/configure.ac @@ -702,10 +702,6 @@ AM_CONDITIONAL(SECURE_RPC, [test x$SECURE_RPC = xyes]) AM_CONDITIONAL(INT10_VM86, [test x$INT10 = xvm86]) AM_CONDITIONAL(INT10_X86EMU, [test x$INT10 = xx86emu]) AM_CONDITIONAL(INT10_STUB, [test x$INT10 = xstub]) -if test x$INT10 = xyes; then - dnl VM86 headers - AC_CHECK_HEADERS([sys/vm86.h sys/io.h]) -fi dnl Handle installing libxf86config AM_CONDITIONAL(INSTALL_LIBXF86CONFIG, [test x$INSTALL_LIBXF86CONFIG = xyes]) diff --git a/include/dix-config.h.in b/include/dix-config.h.in index 4710ef8..5facb11 100644 --- a/include/dix-config.h.in +++ b/include/dix-config.h.in @@ -209,9 +209,6 @@ */ #undef HAVE_SYS_DIR_H -/* Define to 1 if you have the sys/io.h header file. */ -#undef HAVE_SYS_IO_H - /* Define to 1 if you have the sys/ndir.h header file, and it defines `DIR'. */ #undef HAVE_SYS_NDIR_H @@ -225,9 +222,6 @@ /* Define to 1 if you have the sys/utsname.h header file. */ #undef HAVE_SYS_UTSNAME_H -/* Define to 1 if you have the sys/vm86.h header file. */ -#undef HAVE_SYS_VM86_H - /* Define to 1 if you have the tslib.h header file. */ #undef HAVE_TSLIB_H -- 1.7.5.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] Extend XIAllowEvents for handling touch grab processing
This removes the XIAllowTouchEvents request, which was the only new
request added for multitouch.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
XI2.h |6 +--
XI2proto.h | 20 ++--
specs/XI2proto.txt | 87 +++
3 files changed, 38 insertions(+), 75 deletions(-)
diff --git a/XI2.h b/XI2.h
index 2e19e03..2514d55 100644
--- a/XI2.h
+++ b/XI2.h
@@ -108,10 +108,8 @@
#define XIAsyncPairedDevice 3
#define XIAsyncPair 4
#define XISyncPair 5
-
-/* XIAllowTouchEvents bitmask event-modes */
-#define XITouchAccept (1 0)
-#define XITouchReject (1 1)
+#define XIAcceptTouch 6
+#define XIRejectTouch 7
/* DeviceChangedEvent change reasons */
#define XISlaveSwitch 1
diff --git a/XI2proto.h b/XI2proto.h
index 8117767..3315f1e 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -92,10 +92,9 @@
#define X_XIDeleteProperty 58
#define X_XIGetProperty 59
#define X_XIGetSelectedEvents 60
-#define X_XIAllowTouchEvents61
/** Number of XI requests */
-#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1)
+#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
/** Number of XI2 events */
#define XI2EVENTS (XI_LASTEVENT + 1)
@@ -648,8 +647,9 @@ typedef struct {
uint16_tdeviceid;
uint8_t mode;
uint8_t pad;
+uint32_ttouch_id; /** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 12
+#define sz_xXIAllowEventsReq 16 /** Was 12 before XI 2.2 */
/**
@@ -799,20 +799,6 @@ typedef struct {
} xXIGetPropertyReply;
#define sz_xXIGetPropertyReply 32
-/**
- * Accept or reject a grabbed touch sequence.
- */
-typedef struct {
-uint8_t reqType;
-uint8_t ReqType;/** Always ::X_XIAllowTouchEvents */
-uint16_tlength; /** Length in 4 byte units */
-uint32_ttouchid;
-uint16_tdeviceid;
-uint8_t mode; /** bitmask */
-uint8_t pad;
-} xXIAllowTouchEventsReq;
-#define sz_xXIAllowTouchEventsReq 12
-
/*
*
*
* EVENTS
*
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3eea2f5..9bd586a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -360,9 +360,8 @@ Ownership of touch sequences
Once a grabbing client becomes the owner of a touch, it must either “accept” or
-reject the touch sequence using the
-XIAllowTouchEvents request. If a touch sequence is
-rejected, a TouchEnd event is sent to the rejecting client, and it will not
+reject the touch sequence using the XIAllowEvents request. If a touch
sequence
+is rejected, a TouchEnd event is sent to the rejecting client, and it will not
receive any more events for this touch. The server then looks to the next
window in the stack for another passive grab, and attempts to pass ownership
on to the next candidate for a passive grab (i.e. the next window towards
@@ -1371,11 +1370,16 @@ active device grab becomes not viewable.
time:TIMESTAMP or CurrentTime
event_mode: { AsyncDevice, SyncDevice,
AsyncPairedDevice, SyncPairedDevice,
- ReplayDevice, AsyncPair, SyncPair }
+ ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
+ RejectTouch* }
+touch_id*: CARD32
└───
+* since XI 2.2
+
The XIAllowEvents request releases some queued events if the client
-has caused a device to freeze.
+has caused a device to freeze. It also is used to handle touch grab and
+ownership processing.
deviceid
The device to grab.
@@ -1383,12 +1387,19 @@ has caused a device to freeze.
A valid server time or CurrentTime.
event_mode
Specifies whether a device is to be thawed and events are to be
-replayed.
+replayed, or how to handle a grabbed touch sequence.
+touch_id
+The ID of the touch sequence to accept or reject. The value is
undefined
+for event modes other than AcceptTouch and RejectTouch.
The request has no effect if the specified time is earlier than the
last-grab time of the most recent active grab for the client, or if the
specified time is later than the current X server time.
+When event-mode is AcceptTouch or RejectTouch, a BadValue error occurs if the
+touch ID is invalid.
Re: [PATCH] configure.ac: Remove unreachable check for VM86 headers.
On 09/14/11 10:07 AM, Jamey Sharp wrote: configure --with-int10=yes is not a valid configuration, and the check for sys/vm86.h and sys/io.h is not used. Delete it. AM_CONDITIONAL(INT10_VM86, [test x$INT10 = xvm86]) AM_CONDITIONAL(INT10_X86EMU, [test x$INT10 = xx86emu]) AM_CONDITIONAL(INT10_STUB, [test x$INT10 = xstub]) -if test x$INT10 = xyes; then - dnl VM86 headers - AC_CHECK_HEADERS([sys/vm86.h sys/io.h]) -fi Should that be checking for x$INT10 = xvm86 since it's checking for the vm86 headers? Perhaps AC_ERRORing if vm86 is requested and they're not found? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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] configure.ac: Remove unreachable check for VM86 headers.
On Wed, Sep 14, 2011 at 10:39:53AM -0500, Alan Coopersmith wrote: On 09/14/11 10:07 AM, Jamey Sharp wrote: configure --with-int10=yes is not a valid configuration, and the check for sys/vm86.h and sys/io.h is not used. Delete it. AM_CONDITIONAL(INT10_VM86, [test x$INT10 = xvm86]) AM_CONDITIONAL(INT10_X86EMU, [test x$INT10 = xx86emu]) AM_CONDITIONAL(INT10_STUB, [test x$INT10 = xstub]) -if test x$INT10 = xyes; then -dnl VM86 headers -AC_CHECK_HEADERS([sys/vm86.h sys/io.h]) -fi Should that be checking for x$INT10 = xvm86 since it's checking for the vm86 headers? Perhaps AC_ERRORing if vm86 is requested and they're not found? Oddly, nothing in-tree #includes sys/vm86.h, not even the INT10_VM86 implementation. So no, I think this block should just die. Some things do #include sys/io.h, but they aren't related to int10 and didn't use HAVE_SYS_IO_H. Jamey signature.asc Description: Digital 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] Extend XIAllowEvents for handling touch grab processing
On Wed, Sep 14, 2011 at 10:22:35AM -0500, Chase Douglas wrote:
This removes the XIAllowTouchEvents request, which was the only new
request added for multitouch.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
XI2.h |6 +--
XI2proto.h | 20 ++--
specs/XI2proto.txt | 87 +++
3 files changed, 38 insertions(+), 75 deletions(-)
diff --git a/XI2.h b/XI2.h
index 2e19e03..2514d55 100644
--- a/XI2.h
+++ b/XI2.h
@@ -108,10 +108,8 @@
#define XIAsyncPairedDevice 3
#define XIAsyncPair 4
#define XISyncPair 5
-
-/* XIAllowTouchEvents bitmask event-modes */
-#define XITouchAccept (1 0)
-#define XITouchReject (1 1)
+#define XIAcceptTouch 6
+#define XIRejectTouch 7
/* DeviceChangedEvent change reasons */
#define XISlaveSwitch 1
diff --git a/XI2proto.h b/XI2proto.h
index 8117767..3315f1e 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -92,10 +92,9 @@
#define X_XIDeleteProperty 58
#define X_XIGetProperty 59
#define X_XIGetSelectedEvents 60
-#define X_XIAllowTouchEvents61
/** Number of XI requests */
-#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1)
+#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
/** Number of XI2 events */
#define XI2EVENTS (XI_LASTEVENT + 1)
@@ -648,8 +647,9 @@ typedef struct {
uint16_tdeviceid;
uint8_t mode;
uint8_t pad;
+uint32_ttouch_id; /** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 12
+#define sz_xXIAllowEventsReq 16 /** Was 12 before XI 2.2
*/
/**
@@ -799,20 +799,6 @@ typedef struct {
} xXIGetPropertyReply;
#define sz_xXIGetPropertyReply 32
-/**
- * Accept or reject a grabbed touch sequence.
- */
-typedef struct {
-uint8_t reqType;
-uint8_t ReqType;/** Always ::X_XIAllowTouchEvents */
-uint16_tlength; /** Length in 4 byte units */
-uint32_ttouchid;
-uint16_tdeviceid;
-uint8_t mode; /** bitmask */
-uint8_t pad;
-} xXIAllowTouchEventsReq;
-#define sz_xXIAllowTouchEventsReq 12
-
/*
*
*
* EVENTS
*
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3eea2f5..9bd586a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -360,9 +360,8 @@ Ownership of touch sequences
Once a grabbing client becomes the owner of a touch, it must either “accept”
or
-reject the touch sequence using the
-XIAllowTouchEvents request. If a touch sequence is
-rejected, a TouchEnd event is sent to the rejecting client, and it will not
+reject the touch sequence using the XIAllowEvents request. If a touch
sequence
+is rejected, a TouchEnd event is sent to the rejecting client, and it will
not
receive any more events for this touch. The server then looks to the next
window in the stack for another passive grab, and attempts to pass ownership
on to the next candidate for a passive grab (i.e. the next window towards
@@ -1371,11 +1370,16 @@ active device grab becomes not viewable.
time:TIMESTAMP or CurrentTime
event_mode: { AsyncDevice, SyncDevice,
AsyncPairedDevice, SyncPairedDevice,
- ReplayDevice, AsyncPair, SyncPair }
+ ReplayDevice, AsyncPair, SyncPair,
AcceptTouch*,
+ RejectTouch* }
+touch_id*: CARD32
└───
+* since XI 2.2
+
The XIAllowEvents request releases some queued events if the client
-has caused a device to freeze.
+has caused a device to freeze. It also is used to handle touch grab and
+ownership processing.
deviceid
The device to grab.
@@ -1383,12 +1387,19 @@ has caused a device to freeze.
A valid server time or CurrentTime.
event_mode
Specifies whether a device is to be thawed and events are to be
-replayed.
+replayed, or how to handle a grabbed touch sequence.
+touch_id
+The ID of the touch sequence to accept or reject. The value is
undefined
+for event modes other than AcceptTouch and RejectTouch.
The request has no effect if the specified time
Re: [PATCH 2/2] Allow grabbing clients to accept or reject touches any time
On Wed, Sep 14, 2011 at 10:22:36AM -0500, Chase Douglas wrote:
This is potentially both a performance and client complexity
improvement.
this needs more description, especially for the archives (we just talked
about this here at the XDC), please add that to the commit message.
and one more thing: if a client can reject a sequence at any time it may be
that the sequence already disappeared by the time the reject is processed.
(this shouldn't happen unless the client buffers the request but thats been
known to happen).
should we allow clients to reject any touch (even invalid ones) without
returning a BadValue?
Cheers,
Peter
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
XI2proto.h |3 ++-
specs/XI2proto.txt | 26 +-
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 3315f1e..9e2c63c 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -648,8 +648,9 @@ typedef struct {
uint8_t mode;
uint8_t pad;
uint32_ttouch_id; /** Since XI 2.2 */
+Window grab_window;/** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 16 /** Was 12 before XI 2.2
*/
+#define sz_xXIAllowEventsReq 20 /** Was 12 before XI 2.2
*/
/**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9bd586a..63e8bb3 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1373,6 +1373,7 @@ active device grab becomes not viewable.
ReplayDevice, AsyncPair, SyncPair,
AcceptTouch*,
RejectTouch* }
touch_id*: CARD32
+grab_window*:Window
└───
* since XI 2.2
@@ -1391,14 +1392,18 @@ ownership processing.
touch_id
The ID of the touch sequence to accept or reject. The value is
undefined
for event modes other than AcceptTouch and RejectTouch.
+grab_window
+The window on which to accept or reject a touch sequence grab. The
value
+is undefined for event modes other than AcceptTouch and RejectTouch.
-The request has no effect if the specified time is earlier than the
-last-grab time of the most recent active grab for the client, or if the
-specified time is later than the current X server time.
+For event modes other than AcceptTouch and RejectTouch, the request has no
+effect if the specified time is earlier than the last-grab time of the most
+recent active grab for the client, or if the specified time is later than the
+current X server time.
When event-mode is AcceptTouch or RejectTouch, a BadValue error occurs if the
touch ID is invalid. A BadAccess error occurs if this client is not the
current
-owner of the specified touch ID.
+or potential owner of the specified touch ID.
The following describes the processing that occurs depending on what constant
you pass to the event-mode argument:
@@ -1470,13 +1475,16 @@ you pass to the event-mode argument:
paired master device frozen by the client.
AsyncPair has no effect if deviceid specifies a slave device.
AcceptTouch
-The client is deemed to have taken control of the touch sequence.
-TouchEnd events will be sent to all other clients listening to the
touch
-sequence, and they will no longer receive any TouchUpdate events.
+The client is deemed to have taken control of the touch sequence
once it
+owns the sequence. TouchEnd events will be sent to all clients
listening
+to the touch sequence that have either grabbed the touch sequence on
a
+child window of the grab_window or have received events for the touch
+sequence through event selection. These clients will no longer
receive
+any TouchUpdate events.
RejectTouch
The client is no longer interested in the touch sequence, and will
-receive a TouchEnd event. Ownership will be passed on to the next
-listener.
+receive a TouchEnd event. If the client is the current owner of the
+sequence, ownership will be passed on to the next listener.
[[requests-passivegrabdevice]]
┌───
--
1.7.4.1
___
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 PATCH 0/9] Bus layer cleanups
I'm interested in this patch series since I'm working to get Xorg building on
darwin and need to get the IOADDRESS type of shared code. This is a pre-req
for Tiago's --enable-pciaccess changes which I've rebased on recent master.
This series still applies except for the following:
[PATCH 5/9] vgahw: Port to pciaccess IO space routines
[PATCH 6/9] pci: Port xf86MapLegacyIO to pciaccess
[PATCH 7/9] linux: Use pci_device_get_parent_bridge instead of open-coding it
Adam, would you mind rebasing these and sending them out again for review? For
now I'm just going to work with Tiago's version which just does
s/IOADDRESS/unsigned long/
--Jeremy
On Sep 21, 2010, at 6:28 PM, Adam Jackson wrote:
This attempts to tackle Tiago's (justified) hatred for the IOADDRESS type
in a slightly more elegant way. We move more of the VGA hacks to vgahw,
port it and int10 over to pciaccess' legacy I/O API, and then clean up
some of the remaining detritus.
THIS IS AN ABI BREAK. Like, a pretty massive one. Please do not pull
this yet. I'm mostly looking for r-b's here that the strategy looks
sane. The driver work needs to land before this lands, and it's pretty
trivial, but I don't want to bother unless this is actually going to
merge.
Once (if) this lands, the only remaining direct usage of {in,out}[bwl]
in xserver will be xf86SlowBcopy (jokes). This also makes it plausible
to convert the rest of the drivers to the pciaccess API, which then
means we can drop roughly 137% of the content of compiler.h.
---
The following changes since commit c768cdda92696b636c10bb2df64167d5274b4b99:
Merge remote branch 'jamey/reviewed' (2010-09-13 16:48:33 -0700)
are available in the git repository at:
ssh://people.freedesktop.org/~ajax/xserver.git ioaddress
Adam Jackson (9):
xfree86: Move xf86GetClocks to vgahw
int10: Port to pciaccess' legacy IO API
vgahw: Move IO domain setup to IO dispatch vector setup
vgahw: Don't default to standard (port space) access routines
vgahw: Port to pciaccess IO space routines
pci: Port xf86MapLegacyIO to pciaccess
linux: Use pci_device_get_parent_bridge instead of open-coding it
bus: remove some dead struct fields
linux: Remove pre-2.6 PCI interface support
hw/xfree86/common/xf86.h |6 -
hw/xfree86/common/xf86Bus.c |1 -
hw/xfree86/common/xf86Bus.h |1 -
hw/xfree86/common/xf86Helper.c| 90 ---
hw/xfree86/common/xf86pciBus.c| 17 ++-
hw/xfree86/common/xf86str.h |1 -
hw/xfree86/int10/generic.c|5 +-
hw/xfree86/int10/helper_exec.c| 36 +++---
hw/xfree86/int10/xf86int10.c | 61 +-
hw/xfree86/int10/xf86int10.h |2 +-
hw/xfree86/os-support/bus/Pci.c |2 +-
hw/xfree86/os-support/bus/Pci.h | 16 +--
hw/xfree86/os-support/bus/bsd_pci.c |9 +--
hw/xfree86/os-support/bus/linuxPci.c | 200 +
hw/xfree86/os-support/bus/xf86Pci.h |4 +-
hw/xfree86/os-support/shared/vidmem.c |6 -
hw/xfree86/vgahw/vgaHW.c | 178 ++---
hw/xfree86/vgahw/vgaHW.h | 24 ++--
18 files changed, 221 insertions(+), 438 deletions(-)
---
- ajax
___
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 lib/libxtrans] Removing SUN specific code,let solaris create .X11-pipe with sticky bit on
In solaris, /tmp/.X11-unix/ is already created with privilege
drwxrwxrwt(01777), there is no reason to restrict /tmp/.X11-pipe with
drwxrwxr-x (0775). So I have removed unwanted sun specific code.
Alan told me, named pipe support was added around Solaris 2.6 when that was a
much better performing transport than Unix sockets on the Solaris kernels of
the time. By Solaris 10, Unix sockets had been reimplemented in the kernel to
be faster, so they became the default again. In Solaris 11, we don't even have
named pipe support in the libxcb library that implements X client connection
code now, so the named pipes would only be accessed by code with a different
libX11 or a statically linked libX11 from Solaris 2.6-9
Signed-off-by: Arvind Umraoarvind.um...@oracle.com
---
Xtranslcl.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/Xtranslcl.c b/Xtranslcl.c
index ca04e7f..239d8d2 100644
--- a/Xtranslcl.c
+++ b/Xtranslcl.c
@@ -742,15 +742,11 @@ TRANS(NAMEDOpenPipe)(const char *server_path)
struct statsbuf;
intmode;
-#if defined(sun) defined(X11_t)
-mode = 0775; /* Solaris requires uid or gid 0 to create X11 pipes */
-#else
#ifdef HAS_STICKY_DIR_BIT
mode = 01777;
#else
mode = 0777;
#endif
-#endif
if (trans_mkdir(X_STREAMS_DIR, mode) == -1) {
PRMSG (1, NAMEDOpenPipe: mkdir(%s) failed, errno = %d\n,
X_STREAMS_DIR, errno, 0);
--
1.7.6
___
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 2/2] Allow grabbing clients to accept or reject touches any time
On 09/14/2011 11:59 AM, Peter Hutterer wrote: On Wed, Sep 14, 2011 at 10:22:36AM -0500, Chase Douglas wrote: This is potentially both a performance and client complexity improvement. this needs more description, especially for the archives (we just talked about this here at the XDC), please add that to the commit message. and one more thing: if a client can reject a sequence at any time it may be that the sequence already disappeared by the time the reject is processed. (this shouldn't happen unless the client buffers the request but thats been known to happen). should we allow clients to reject any touch (even invalid ones) without returning a BadValue? Hmmm... The same could happen with accept too: * Client A owns touch * Client B has a touch grab and is listening too 1. Client A accepts touch 2. TouchEnd sent to client B 3. Client B accepts touch (which means, I accept iff I become the owner) 4. TouchEnd reaches client B 5. Client B gets an error from the touch acceptance because at the time the server got the accept request, the touch has already ended for client B We probably need to think a bit more about this... -- Chase ___ 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 xorg-docs] Solaris: set X11 release information
Signed-off-by: Gaetan Nadon mems...@videotron.ca --- general/platforms/Solaris.xml |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/general/platforms/Solaris.xml b/general/platforms/Solaris.xml index 0a60a34..3890c7f 100644 --- a/general/platforms/Solaris.xml +++ b/general/platforms/Solaris.xml @@ -13,6 +13,7 @@ titleX Window System support for trademarkSolaris/trademark amp; trademarkOpenSolaris/trademark from X.Org /title + releaseinfoX Version 11, Release fullrelvers;/releaseinfo authorgroup author firstnameDavid/firstnamesurnameHolland/surname -- 1.7.4.1 ___ 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] int10: Remove the vm86 and stub backends
From: Adam Jackson a...@redhat.com vm86 has been defaulted off since 1.6, and is still a terrible idea to actually use. Time to say goodbye. The stub backend is only ever built by default on freebsd/ppc, and can't be doing any good there. The right fix is --disable-int10 if you want to not ship int10 support. Signed-off-by: Adam Jackson a...@redhat.com Reviewed-by: Jamey Sharp ja...@minilop.net --- I'd like to resurrect this patch that ajax proposed a year ago. The thread where it was last discussed is here: http://lists.x.org/archives/xorg-devel/2010-July/011163.html This patch is, as far as I can tell, a correct and complete implementation of removing vm86 and stub. The controversy last time was only over this is the right thing to do. My impression is that everyone agrees that vm86 *should* die, but some commenters were concerned that x86emu didn't support some particularly terrible BIOSes that happened to work on vm86. I'm not convinced that's a sufficient argument for rejecting the patch. The default has been x86emu on everything but Linux/x86-32 since 2005, and x86emu everywhere since 2008. If anybody still cares, please fix up x86emu. configure.ac | 11 - hw/xfree86/int10/Makefile.am | 17 - hw/xfree86/int10/stub.c| 69 --- hw/xfree86/os-support/int10Defines.h | 52 +-- hw/xfree86/os-support/linux/int10/linux.c | 544 .../os-support/linux/int10/vm86/linux_vm86.c | 300 --- hw/xfree86/x86emu/Makefile.am |2 - 7 files changed, 1 insertions(+), 994 deletions(-) delete mode 100644 hw/xfree86/int10/stub.c delete mode 100644 hw/xfree86/os-support/linux/int10/linux.c delete mode 100644 hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c diff --git a/configure.ac b/configure.ac index 06cf9bf..9687f04 100644 --- a/configure.ac +++ b/configure.ac @@ -323,7 +323,6 @@ dnl --- dnl Bus options and CPU capabilities. Replaces logic in dnl hw/xfree86/os-support/bus/Makefile.am, among others. dnl --- -DEFAULT_INT10=x86emu dnl Override defaults as needed for specific platforms: @@ -354,9 +353,6 @@ case $host_cpu in ;; powerpc*) PPC_VIDEO=yes - case $host_os in - *freebsd*) DEFAULT_INT10=stub ;; - esac ;; sparc*) SPARC64_VIDEO=yes @@ -464,9 +460,6 @@ AC_ARG_ENABLE(debug, AS_HELP_STRING([--enable-debug], AC_ARG_ENABLE(use-sigio-by-default, AS_HELP_STRING([--enable-use-sigio-by-default] [Enable SIGIO input handlers by default (default: $USE_SIGIO_BY_DEFAULT)]), [USE_SIGIO_BY_DEFAULT=$enableval], []) -AC_ARG_WITH(int10, AS_HELP_STRING([--with-int10=BACKEND], [int10 backend: vm86, x86emu or stub]), - [INT10=$withval], - [INT10=$DEFAULT_INT10]) AC_ARG_WITH(vendor-name, AS_HELP_STRING([--with-vendor-name=VENDOR], [Vendor string reported by the server]), [ VENDOR_NAME=$withval ], []) @@ -699,10 +692,6 @@ XTRANS_CONNECTION_FLAGS XTRANS_SECURE_RPC_FLAGS AM_CONDITIONAL(SECURE_RPC, [test x$SECURE_RPC = xyes]) -AM_CONDITIONAL(INT10_VM86, [test x$INT10 = xvm86]) -AM_CONDITIONAL(INT10_X86EMU, [test x$INT10 = xx86emu]) -AM_CONDITIONAL(INT10_STUB, [test x$INT10 = xstub]) - dnl Handle installing libxf86config AM_CONDITIONAL(INSTALL_LIBXF86CONFIG, [test x$INSTALL_LIBXF86CONFIG = xyes]) diff --git a/hw/xfree86/int10/Makefile.am b/hw/xfree86/int10/Makefile.am index f5ece69..79eb25a 100644 --- a/hw/xfree86/int10/Makefile.am +++ b/hw/xfree86/int10/Makefile.am @@ -17,16 +17,6 @@ if I386_VIDEO I386_VIDEO_CFLAGS = -D_PC endif -if INT10_VM86 -AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(DIX_CFLAGS) $(XORG_CFLAGS) $(EXTRA_CFLAGS) -INCLUDES = $(XORG_INCS) -libint10_la_SOURCES = \ - $(COMMON_SOURCES) \ - $(srcdir)/../os-support/linux/int10/vm86/linux_vm86.c \ - $(srcdir)/../os-support/linux/int10/linux.c -endif - -if INT10_X86EMU AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_X86EMU -DNO_SYS_HEADERS \ $(XORG_CFLAGS) $(EXTRA_CFLAGS) $(DIX_CFLAGS) INCLUDES = $(XORG_INCS) -I$(srcdir)/../x86emu @@ -35,12 +25,5 @@ libint10_la_SOURCES = \ xf86x86emu.c \ generic.c \ x86emu.c -endif - -if INT10_STUB -AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(DIX_CFLAGS) $(XORG_CFLAGS) $(EXTRA_CFLAGS) -INCLUDES = $(XORG_INCS) -libint10_la_SOURCES = stub.c xf86int10module.c -endif EXTRA_DIST = xf86x86emu.h INT10.HOWTO diff --git a/hw/xfree86/int10/stub.c b/hw/xfree86/int10/stub.c deleted file mode 100644 index 58b6578..000 --- a/hw/xfree86/int10/stub.c +++ /dev/null @@ -1,69 +0,0 @@ -/* - *
[PATCH] int10: Delete #if 0'd implementation that's older than our git history.
Throughout the xserver git history, the generic portion of the int10
module has always used other methods for reading the video BIOS. For
some time now it's been purely libpciaccess based. This commented-out
use of xf86ReadBIOS is entirely superfluous.
Signed-off-by: Jamey Sharp ja...@minilop.net
---
hw/xfree86/int10/generic.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index fe8bb69..9940854 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -128,10 +128,6 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
int screen;
legacyVGARec vga;
-#if 0
-CARD32 cs;
-#endif
-
screen = (xf86FindScreenForEntity(entityIndex))-scrnIndex;
options = xf86HandleInt10Options(xf86Screens[screen],entityIndex);
@@ -174,17 +170,9 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
/*
* Retrieve everything between V_BIOS and SYS_BIOS as some system BIOSes
- * have executable code there. Note that xf86ReadBIOS() can only read in
- * 64kB at a time.
+ * have executable code there.
*/
memset((char *)base + V_BIOS, 0, SYS_BIOS - V_BIOS);
-#if 0
-for (cs = V_BIOS; cs SYS_BIOS; cs += V_BIOS_SIZE)
- if (xf86ReadBIOS(cs, 0, (unsigned char *)base + cs, V_BIOS_SIZE)
- V_BIOS_SIZE)
- xf86DrvMsg(screen, X_WARNING,
- Unable to retrieve all of segment 0x%06X.\n, cs);
-#endif
INTPriv(pInt)-highMemory = V_BIOS;
if (xf86IsEntityPrimary(entityIndex) !(initPrimary(options))) {
--
1.7.5.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] int10: Remove the vm86 and stub backends
On Wed, Sep 14, 2011 at 12:25:20 -0500, Jamey Sharp wrote: From: Adam Jackson a...@redhat.com vm86 has been defaulted off since 1.6, and is still a terrible idea to actually use. Time to say goodbye. The stub backend is only ever built by default on freebsd/ppc, and can't be doing any good there. The right fix is --disable-int10 if you want to not ship int10 support. Signed-off-by: Adam Jackson a...@redhat.com Reviewed-by: Jamey Sharp ja...@minilop.net Acked-by: Julien Cristau jcris...@debian.org Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] Allow grabbing clients to accept or reject touches any time
On Wed, Sep 14, 2011 at 12:09:02PM -0500, Chase Douglas wrote: On 09/14/2011 11:59 AM, Peter Hutterer wrote: On Wed, Sep 14, 2011 at 10:22:36AM -0500, Chase Douglas wrote: This is potentially both a performance and client complexity improvement. this needs more description, especially for the archives (we just talked about this here at the XDC), please add that to the commit message. and one more thing: if a client can reject a sequence at any time it may be that the sequence already disappeared by the time the reject is processed. (this shouldn't happen unless the client buffers the request but thats been known to happen). should we allow clients to reject any touch (even invalid ones) without returning a BadValue? Hmmm... The same could happen with accept too: * Client A owns touch * Client B has a touch grab and is listening too 1. Client A accepts touch 2. TouchEnd sent to client B 3. Client B accepts touch (which means, I accept iff I become the owner) 4. TouchEnd reaches client B 5. Client B gets an error from the touch acceptance because at the time the server got the accept request, the touch has already ended for client B We probably need to think a bit more about this... accept is a different case where the client should handle errors appropriately. reject is more fire-and-forget. same with Ungrab, iirc it always succeeds even if you don't actually have the grab. 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 2/2] Allow grabbing clients to accept or reject touches any time
On 09/14/2011 02:04 PM, Peter Hutterer wrote: On Wed, Sep 14, 2011 at 12:09:02PM -0500, Chase Douglas wrote: On 09/14/2011 11:59 AM, Peter Hutterer wrote: On Wed, Sep 14, 2011 at 10:22:36AM -0500, Chase Douglas wrote: This is potentially both a performance and client complexity improvement. this needs more description, especially for the archives (we just talked about this here at the XDC), please add that to the commit message. and one more thing: if a client can reject a sequence at any time it may be that the sequence already disappeared by the time the reject is processed. (this shouldn't happen unless the client buffers the request but thats been known to happen). should we allow clients to reject any touch (even invalid ones) without returning a BadValue? Hmmm... The same could happen with accept too: * Client A owns touch * Client B has a touch grab and is listening too 1. Client A accepts touch 2. TouchEnd sent to client B 3. Client B accepts touch (which means, I accept iff I become the owner) 4. TouchEnd reaches client B 5. Client B gets an error from the touch acceptance because at the time the server got the accept request, the touch has already ended for client B We probably need to think a bit more about this... accept is a different case where the client should handle errors appropriately. reject is more fire-and-forget. same with Ungrab, iirc it always succeeds even if you don't actually have the grab. This makes sense to me after further thought. I agree we should not emit an error on reject if the touch id is invalid, as you suggest. I'll send a v2 with this change and a more verbose commit message. -- Chase ___ 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] int10: Remove the vm86 and stub backends
On Wed, Sep 14, 2011 at 12:25:20PM -0500, Jamey Sharp wrote: From: Adam Jackson a...@redhat.com vm86 has been defaulted off since 1.6, and is still a terrible idea to actually use. Time to say goodbye. Not a good idea. I've reenabled it in our enterprise product lately. Reason: I've run into issues with SMIs that were triggered by outb()s to specific registers. These SMIs returned their return state in CPU registers whose values were checked later on in the code. The emulator doesn't track the state of CPU register itself thus will not catch any such results. The stub backend is only ever built by default on freebsd/ppc, and can't be doing any good there. The right fix is --disable-int10 if you want to not ship int10 support. This was used to handle the request for loading the int10 module and provide targets for the function calls in drivers. If it can be ensured that drivers won't load this module and call its function this can probably be deleted. Cheers, Egbert. ___ 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 inputproto multitouch v2] Allow grabbing clients to accept or reject touches any time
This is potentially both a performance and client complexity
improvement. An example is a gesture recognizer using touch grabs on
each window with a subscription. If events on a child window is known
to not match any subscription on the child window, then the client
should be able to reject the touch grab even if the parent window hasn't
accepted any of the touches, perhaps because the parent window
gesture hasn't timed out or crossed other thresholds yet.
As an inverse example, the events may match a child window subscription
before the root window has rejected ownership. The child window should
be able to accept the touch proactively. This allows for further clients
to receive a TouchEnd event earlier, and means the client may be able to
reduce state being tracked. If this were not allowed, the client would
need to wait until it received ownership before accepting the sequence.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
XI2proto.h |3 ++-
specs/XI2proto.txt | 28 ++--
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 3315f1e..9e2c63c 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -648,8 +648,9 @@ typedef struct {
uint8_t mode;
uint8_t pad;
uint32_ttouch_id; /** Since XI 2.2 */
+Window grab_window;/** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 16 /** Was 12 before XI 2.2 */
+#define sz_xXIAllowEventsReq 20 /** Was 12 before XI 2.2 */
/**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9bd586a..dfc80cc 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1373,6 +1373,7 @@ active device grab becomes not viewable.
ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
RejectTouch* }
touch_id*: CARD32
+grab_window*:Window
└───
* since XI 2.2
@@ -1391,13 +1392,17 @@ ownership processing.
touch_id
The ID of the touch sequence to accept or reject. The value is
undefined
for event modes other than AcceptTouch and RejectTouch.
+grab_window
+The window on which to accept or reject a touch sequence grab. The
value
+is undefined for event modes other than AcceptTouch and RejectTouch.
-The request has no effect if the specified time is earlier than the
-last-grab time of the most recent active grab for the client, or if the
-specified time is later than the current X server time.
+For event modes other than AcceptTouch and RejectTouch, the request has no
+effect if the specified time is earlier than the last-grab time of the most
+recent active grab for the client, or if the specified time is later than the
+current X server time.
-When event-mode is AcceptTouch or RejectTouch, a BadValue error occurs if the
-touch ID is invalid. A BadAccess error occurs if this client is not the current
+When event-mode is AcceptTouch, a BadValue error occurs if the touch ID is
+invalid. A BadAccess error occurs if this client is not the current or
potential
owner of the specified touch ID.
The following describes the processing that occurs depending on what constant
@@ -1470,13 +1475,16 @@ you pass to the event-mode argument:
paired master device frozen by the client.
AsyncPair has no effect if deviceid specifies a slave device.
AcceptTouch
-The client is deemed to have taken control of the touch sequence.
-TouchEnd events will be sent to all other clients listening to the
touch
-sequence, and they will no longer receive any TouchUpdate events.
+The client is deemed to have taken control of the touch sequence once
it
+owns the sequence. TouchEnd events will be sent to all clients
listening
+to the touch sequence that have either grabbed the touch sequence on a
+child window of the grab_window or have received events for the touch
+sequence through event selection. These clients will no longer receive
+any TouchUpdate events.
RejectTouch
The client is no longer interested in the touch sequence, and will
-receive a TouchEnd event. Ownership will be passed on to the next
-listener.
+receive a TouchEnd event. If the client is the current owner of the
+sequence, ownership will be passed on to the next listener.
[[requests-passivegrabdevice]]
┌───
--
1.7.4.1
___
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 inputproto multitouch v2] Allow grabbing clients to accept or reject touches any time
On Wed, Sep 14, 2011 at 02:43:17PM -0500, Chase Douglas wrote:
This is potentially both a performance and client complexity
improvement. An example is a gesture recognizer using touch grabs on
each window with a subscription. If events on a child window is known
s/is/are/
to not match any subscription on the child window, then the client
should be able to reject the touch grab even if the parent window hasn't
accepted any of the touches, perhaps because the parent window
gesture hasn't timed out or crossed other thresholds yet.
As an inverse example, the events may match a child window subscription
before the root window has rejected ownership. The child window should
be able to accept the touch proactively. This allows for further clients
to receive a TouchEnd event earlier, and means the client may be able to
reduce state being tracked. If this were not allowed, the client would
need to wait until it received ownership before accepting the sequence.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
I think this may require some rewording of the other sections to emphasise
this more. We can do that at a later review of the whole document.
---
XI2proto.h |3 ++-
specs/XI2proto.txt | 28 ++--
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 3315f1e..9e2c63c 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -648,8 +648,9 @@ typedef struct {
uint8_t mode;
uint8_t pad;
uint32_ttouch_id; /** Since XI 2.2 */
+Window grab_window;/** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 16 /** Was 12 before XI 2.2
*/
+#define sz_xXIAllowEventsReq 20 /** Was 12 before XI 2.2
*/
/**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9bd586a..dfc80cc 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1373,6 +1373,7 @@ active device grab becomes not viewable.
ReplayDevice, AsyncPair, SyncPair,
AcceptTouch*,
RejectTouch* }
touch_id*: CARD32
+grab_window*:Window
└───
* since XI 2.2
@@ -1391,13 +1392,17 @@ ownership processing.
touch_id
The ID of the touch sequence to accept or reject. The value is
undefined
for event modes other than AcceptTouch and RejectTouch.
+grab_window
+The window on which to accept or reject a touch sequence grab. The
value
+is undefined for event modes other than AcceptTouch and RejectTouch.
-The request has no effect if the specified time is earlier than the
-last-grab time of the most recent active grab for the client, or if the
-specified time is later than the current X server time.
+For event modes other than AcceptTouch and RejectTouch, the request has no
+effect if the specified time is earlier than the last-grab time of the most
+recent active grab for the client, or if the specified time is later than the
+current X server time.
why do we need to change this? could we not keep this around (or otherwise
force clients to use CurrentTime for passive touch grabs).
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net otherwise though.
Cheers,
Peter
-When event-mode is AcceptTouch or RejectTouch, a BadValue error occurs if the
-touch ID is invalid. A BadAccess error occurs if this client is not the
current
+When event-mode is AcceptTouch, a BadValue error occurs if the touch ID is
+invalid. A BadAccess error occurs if this client is not the current or
potential
owner of the specified touch ID.
The following describes the processing that occurs depending on what constant
@@ -1470,13 +1475,16 @@ you pass to the event-mode argument:
paired master device frozen by the client.
AsyncPair has no effect if deviceid specifies a slave device.
AcceptTouch
-The client is deemed to have taken control of the touch sequence.
-TouchEnd events will be sent to all other clients listening to the
touch
-sequence, and they will no longer receive any TouchUpdate events.
+The client is deemed to have taken control of the touch sequence
once it
+owns the sequence. TouchEnd events will be sent to all clients
listening
+to the touch sequence that have either grabbed the touch sequence on
a
+child window of the grab_window or have received events for the touch
+sequence through event selection. These clients will no longer
receive
+any TouchUpdate events.
RejectTouch
The client is no longer interested in the touch sequence, and will
-receive a TouchEnd event. Ownership will be passed on to the next
-listener.
+receive a TouchEnd event. If the client is the current owner of the
+
Re: [PATCH inputproto multitouch v2] Allow grabbing clients to accept or reject touches any time
On 09/14/2011 02:57 PM, Peter Hutterer wrote:
On Wed, Sep 14, 2011 at 02:43:17PM -0500, Chase Douglas wrote:
This is potentially both a performance and client complexity
improvement. An example is a gesture recognizer using touch grabs on
each window with a subscription. If events on a child window is known
s/is/are/
to not match any subscription on the child window, then the client
should be able to reject the touch grab even if the parent window hasn't
accepted any of the touches, perhaps because the parent window
gesture hasn't timed out or crossed other thresholds yet.
As an inverse example, the events may match a child window subscription
before the root window has rejected ownership. The child window should
be able to accept the touch proactively. This allows for further clients
to receive a TouchEnd event earlier, and means the client may be able to
reduce state being tracked. If this were not allowed, the client would
need to wait until it received ownership before accepting the sequence.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
I think this may require some rewording of the other sections to emphasise
this more. We can do that at a later review of the whole document.
---
XI2proto.h |3 ++-
specs/XI2proto.txt | 28 ++--
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 3315f1e..9e2c63c 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -648,8 +648,9 @@ typedef struct {
uint8_t mode;
uint8_t pad;
uint32_ttouch_id; /** Since XI 2.2 */
+Window grab_window;/** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 16 /** Was 12 before XI 2.2
*/
+#define sz_xXIAllowEventsReq 20 /** Was 12 before XI 2.2
*/
/**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9bd586a..dfc80cc 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1373,6 +1373,7 @@ active device grab becomes not viewable.
ReplayDevice, AsyncPair, SyncPair,
AcceptTouch*,
RejectTouch* }
touch_id*: CARD32
+grab_window*:Window
└───
* since XI 2.2
@@ -1391,13 +1392,17 @@ ownership processing.
touch_id
The ID of the touch sequence to accept or reject. The value is
undefined
for event modes other than AcceptTouch and RejectTouch.
+grab_window
+The window on which to accept or reject a touch sequence grab. The
value
+is undefined for event modes other than AcceptTouch and RejectTouch.
-The request has no effect if the specified time is earlier than the
-last-grab time of the most recent active grab for the client, or if the
-specified time is later than the current X server time.
+For event modes other than AcceptTouch and RejectTouch, the request has no
+effect if the specified time is earlier than the last-grab time of the most
+recent active grab for the client, or if the specified time is later than
the
+current X server time.
why do we need to change this? could we not keep this around (or otherwise
force clients to use CurrentTime for passive touch grabs).
The time check is used for pointer or key passive grabbing. For example:
1. Button press causes passive grab
2. Button press releases grab
3. Button press causes passive grab
4. Client receives passive grab events from the press in step 1
5. Client makes XIAllowEvents request
The time helps determine which grab the XIAllowEvents is supposed to
affect. Or something like that anyways.
With touches, each new touch has a new ID, so the touch_id and window
fields effectively take care of all ambiguities.
Here at XDC, Peter suggested to just require clients to use CurrenTime
instead of leaving it undefined for touch modes. I'll fix that up and
push it.
-- Chase
___
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 xorg-docs] Solaris: set X11 release information
On 09/14/11 12:24 PM, Gaetan Nadon wrote: Signed-off-by: Gaetan Nadonmems...@videotron.ca --- general/platforms/Solaris.xml |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/general/platforms/Solaris.xml b/general/platforms/Solaris.xml index 0a60a34..3890c7f 100644 --- a/general/platforms/Solaris.xml +++ b/general/platforms/Solaris.xml @@ -13,6 +13,7 @@ titleX Window System support fortrademarkSolaris/trademark amp; trademarkOpenSolaris/trademark from X.Org /title +releaseinfoX Version 11, Releasefullrelvers;/releaseinfo authorgroup author firstnameDavid/firstnamesurnameHolland/surname For both this [PATCH xorg-docs] Solaris: shorten the title a bit: Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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] int10: Remove the vm86 and stub backends
On Wed, 2011-09-14 at 19:28 +, Egbert Eich wrote: On Wed, Sep 14, 2011 at 12:25:20PM -0500, Jamey Sharp wrote: From: Adam Jackson a...@redhat.com vm86 has been defaulted off since 1.6, and is still a terrible idea to actually use. Time to say goodbye. Not a good idea. I've reenabled it in our enterprise product lately. Reason: I've run into issues with SMIs that were triggered by outb()s to specific registers. These SMIs returned their return state in CPU registers whose values were checked later on in the code. The emulator doesn't track the state of CPU register itself thus will not catch any such results. Seems like the better solution is to emulate the state machines of those ports. We do a half-baked job of this already for some ports. Actually, the better better solution is not int10. In general I consider vm86 to be completely unsupportable. Mapping anything at the 0 page means kernel bugs aren't segfaults, which is the kind of security bug that's been actively exploited in the wild. Pretending to care about bugs like the one you describe implies that the affected machine can only work with vesa on i386 and not amd64, and that's not the kind of gotcha I want to enable. int10 services is a losing battle though. Some vendors ship BIOSes that actively flaunt their own documentation about what instructions are legal in vm86 mode (HI INTEL HOW ARE YOU [1]), newer versions of Windows skip it entirely which means it's going to be increasingly unreliable, you might not have int10 at all in EFI, you can't get to unreal mode from vm86 even though some BIOSes expect it... the list goes on. None of this is news though. I've already argued for why vm86 is garbage, and why x86emu is the only thing that can be made to work safely and reliably. If other people want more pain in their lives, that's a thing they can do, people make bad choices all the time and I can't care about every damn thing. [1] - http://lists.fedoraproject.org/pipermail/test/2011-September/102549.html - ajax signature.asc Description: This is a digitally signed message part ___ 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] Fix handling of SendEvent requests which set the SendEvent bit before sending the event down the wire
Excellent, thanks Sam.
Reviewed-by: Jamey Sharp ja...@minilop.net
Peter says he'll route this through his tree, so I'll leave it to him.
Jamey
On Wed, Sep 14, 2011 at 10:00:45AM +0800, Sam Spilsbury wrote:
From cf2cd8c03551c42d73a21ac5077904c8ec8ee4bd Mon Sep 17 00:00:00 2001
From: Sam Spilsbury sam.spilsb...@canonical.com
Date: Wed, 14 Sep 2011 09:58:34 +0800
Subject: [PATCH] Remove the SendEvent bit (0x80) before doing range checks on
event type.
Some extension libraries may set this bit before converting the event to
wire protocol and as such range checking the event will cause an invalid
BadValue error to result. As the documentation suggests the the bit
should be forced on, remove it before doing range checks and continue
to force it on in the server.
---
dix/events.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 8a4c6b9..9e58edb 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -5224,6 +5224,8 @@ CloseDownEvents(void)
InputEventList = NULL;
}
+#define SEND_EVENT_BIT 0x80
+
/**
* Server-side protocol handling for SendEvent request.
*
@@ -5241,6 +5243,16 @@ ProcSendEvent(ClientPtr client)
REQUEST_SIZE_MATCH(xSendEventReq);
+/* libXext and other extension libraries may set the bit indicating
+ * that this event came from a SendEvent request so remove it
+ * since otherwise the event type may fail the range checks
+ * and cause an invalid BadValue error to be returned.
+ *
+ * This is safe to do since we later add the SendEvent bit (0x80)
+ * back in once we send the event to the client */
+
+stuff-event.u.u.type = ~(SEND_EVENT_BIT);
+
/* The client's event type must be a core event type or one defined by an
extension. */
@@ -5298,7 +5310,7 @@ ProcSendEvent(ClientPtr client)
client-errorValue = stuff-propagate;
return BadValue;
}
-stuff-event.u.u.type |= 0x80;
+stuff-event.u.u.type |= SEND_EVENT_BIT;
if (stuff-propagate)
{
for (;pWin; pWin = pWin-parent)
--
1.7.5.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
signature.asc
Description: Digital 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] fb: Rename wfbTriangles and wfbTrapezoids
These symbols were not renamed when they were added to libfb: # nm -D libwfb.so | grep ' fb' 00028d00 T fbTrapezoids 00028d60 T fbTriangles This causes corruption and/or crashes on wfb-ful drivers like nvidia: Program received signal SIGABRT, Aborted. 0x7fd67f3a0405 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x7fd67f3a0405 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7fd67f3a3680 in *__GI_abort () at abort.c:92 #2 0x7fd67f3995b1 in *__GI___assert_fail (assertion=0x7fd679ecb804 key-initialized, file=optimized out, line=116, function=0x7fd679ecbbc0 dixGetPrivateAddr) at assert.c:81 #3 0x7fd679ec55b6 in ?? () from /usr/lib/xorg/modules/libfb.so #4 0x7fd679eca9ef in ?? () from /usr/lib/xorg/modules/libfb.so #5 0x7fd679ecae20 in fbTriangles () from /usr/lib/xorg/modules/libfb.so #6 0x7fd67a58fc55 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so #7 0x004f38d1 in ?? () #8 0x00437ae9 in ?? () #9 0x00426eaa in ?? () #10 0x7fd67f38cead in __libc_start_main (main=optimized out, argc=optimized out, ubp_av=optimized out, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fff99860d78) at libc-start.c:228 #11 0x0042719d in _start () Signed-off-by: Aaron Plattner aplatt...@nvidia.com --- fb/wfbrename.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fb/wfbrename.h b/fb/wfbrename.h index e855edd..8b896eb 100644 --- a/fb/wfbrename.h +++ b/fb/wfbrename.h @@ -160,6 +160,8 @@ #define fbStippleTable wfbStippleTable #define fbTile wfbTile #define fbTransparentSpan wfbTransparentSpan +#define fbTrapezoids wfbTrapezoids +#define fbTriangles wfbTriangles #define fbUninstallColormap wfbUninstallColormap #define fbUnmapWindow wfbUnmapWindow #define fbUnrealizeFont wfbUnrealizeFont -- 1.7.4.1 ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
Every module building against xorg-server does not *Require* pixman nor
libpciaccess. If such modules need pixman or pciaccess, they should be
depending on them directly rather than inheriting a dependency from
xorg-server.
This also moves pixman-1 to Requires.private, so CPPFLAGS is set right to
to satisfy include dependencies but avoid linking needlessly.
Signed-off-by: Jeremy Huddleston jerem...@apple.com
---
configure.ac | 11 ++-
xorg-server.pc.in |1 -
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 415ead8..a97da47 100644
--- a/configure.ac
+++ b/configure.ac
@@ -785,11 +785,6 @@ VIDMODEPROTO=xf86vidmodeproto = 2.2.99.1
WINDOWSWMPROTO=windowswmproto
APPLEWMPROTO=applewmproto = 1.4
-dnl Core modules for most extensions, et al.
-SDK_REQUIRED_MODULES=[xproto = 7.0.22] [randrproto = 1.2.99.3] [renderproto
= 0.11] [xextproto = 7.1.99] [inputproto = 1.9.99.902] [kbproto = 1.0.3]
fontsproto
-# Make SDK_REQUIRED_MODULES available for inclusion in xorg-server.pc
-AC_SUBST(SDK_REQUIRED_MODULES)
-
dnl List of libraries that require a specific version
LIBAPPLEWM=applewm = 1.4
LIBDMX=dmx = 1.0.99.1
@@ -811,6 +806,11 @@ dnl specific modules against it
PKG_CHECK_MODULES(PIXMAN, $LIBPIXMAN)
REQUIRED_LIBS=$REQUIRED_LIBS $LIBPIXMAN $LIBXFONT xau
+dnl Core modules for most extensions, et al.
+SDK_REQUIRED_MODULES=[xproto = 7.0.22] [randrproto = 1.2.99.3] [renderproto
= 0.11] [xextproto = 7.1.99] [inputproto = 1.9.99.902] [kbproto = 1.0.3]
fontsproto $LIBPIXMAN
+# Make SDK_REQUIRED_MODULES available for inclusion in xorg-server.pc
+AC_SUBST(SDK_REQUIRED_MODULES)
+
REQUIRED_MODULES=[fixesproto = 5.0] [damageproto = 1.1] [xcmiscproto =
1.2.0] [xtrans = 1.2.2] [bigreqsproto = 1.1.0] $SDK_REQUIRED_MODULES
if test x$CONFIG_UDEV = xyes
@@ -1561,6 +1561,7 @@ if test x$XORG = xyes; then
if test x$PCI = xyes; then
PKG_CHECK_MODULES([PCIACCESS], $LIBPCIACCESS)
+ SDK_REQUIRED_MODULES=$SDK_REQUIRED_MODULES $LIBPCIACCESS
XORG_SYS_LIBS=$XORG_SYS_LIBS $PCIACCESS_LIBS $GLX_SYS_LIBS
XORG_CFLAGS=$XORG_CFLAGS $PCIACCESS_CFLAGS
diff --git a/xorg-server.pc.in b/xorg-server.pc.in
index fb238b5..a98eca8 100644
--- a/xorg-server.pc.in
+++ b/xorg-server.pc.in
@@ -15,7 +15,6 @@ abi_extension=@abi_extension@
Name: xorg-server
Description: Modular X.Org X Server
Version: @PACKAGE_VERSION@
-Requires: pixman-1 pciaccess
Requires.private: @SDK_REQUIRED_MODULES@
Cflags: -I${sdkdir} @symbol_visibility@
Libs: -L${libdir}
--
1.7.6.1
___
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/3] xfree86: fbdevhw: Remove unused include of pciaccess.h
Signed-off-by: Jeremy Huddleston jerem...@apple.com --- hw/xfree86/fbdevhw/fbdevhw.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/fbdevhw/fbdevhw.h b/hw/xfree86/fbdevhw/fbdevhw.h index bc46b9c..34870c2 100644 --- a/hw/xfree86/fbdevhw/fbdevhw.h +++ b/hw/xfree86/fbdevhw/fbdevhw.h @@ -5,8 +5,6 @@ #include xf86str.h #include colormapst.h -#include pciaccess.h - #define FBDEVHW_PACKED_PIXELS 0 /* Packed Pixels*/ #define FBDEVHW_PLANES 1 /* Non interleaved planes */ #define FBDEVHW_INTERLEAVED_PLANES 2 /* Interleaved planes */ -- 1.7.6.1 ___ 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/3] xfree86: Link modules with -module
This makes a difference on darwin (and apparently nowhere else) Signed-off-by: Jeremy Huddleston jerem...@apple.com --- hw/xfree86/dixmods/Makefile.am| 12 ++-- hw/xfree86/dixmods/extmod/Makefile.am |2 +- hw/xfree86/exa/Makefile.am|2 +- hw/xfree86/fbdevhw/Makefile.am|2 +- hw/xfree86/ramdac/Makefile.am |1 + hw/xfree86/shadowfb/Makefile.am |2 +- hw/xfree86/vbe/Makefile.am|2 +- hw/xfree86/xaa/Makefile.am|2 +- 8 files changed, 13 insertions(+), 12 deletions(-) diff --git a/hw/xfree86/dixmods/Makefile.am b/hw/xfree86/dixmods/Makefile.am index 1a162ab..b6eb54f 100644 --- a/hw/xfree86/dixmods/Makefile.am +++ b/hw/xfree86/dixmods/Makefile.am @@ -30,21 +30,21 @@ INCLUDES = @XORG_INCS@ \ -I$(top_srcdir)/miext/shadow \ -I$(top_srcdir)/glx -libdbe_la_LDFLAGS = -avoid-version +libdbe_la_LDFLAGS = -module -avoid-version libdbe_la_LIBADD = $(top_builddir)/dbe/libdbe.la libdbe_la_SOURCES = dbemodule.c -libfb_la_LDFLAGS = -avoid-version +libfb_la_LDFLAGS = -module -avoid-version libfb_la_LIBADD = $(top_builddir)/fb/libfb.la libfb_la_SOURCES = $(top_builddir)/fb/fbcmap_mi.c fbmodule.c libfb_la_CFLAGS = $(AM_CFLAGS) -libwfb_la_LDFLAGS = -avoid-version +libwfb_la_LDFLAGS = -module -avoid-version libwfb_la_LIBADD = $(top_builddir)/fb/libwfb.la libwfb_la_SOURCES = $(top_builddir)/fb/fbcmap_mi.c fbmodule.c libwfb_la_CFLAGS = $(AM_CFLAGS) -DFB_ACCESS_WRAPPER -libglx_la_LDFLAGS = -avoid-version +libglx_la_LDFLAGS = -module -avoid-version if AIGLX_DRI_LOADER GLXDRI_LIBRARY = $(top_builddir)/glx/libglxdri.la endif @@ -53,11 +53,11 @@ libglx_la_LIBADD = \ $(GLXDRI_LIBRARY) libglx_la_SOURCES = glxmodule.c -librecord_la_LDFLAGS = -avoid-version +librecord_la_LDFLAGS = -module -avoid-version librecord_la_LIBADD = $(top_builddir)/record/librecord.la librecord_la_SOURCES = recordmod.c -libshadow_la_LDFLAGS = -avoid-version +libshadow_la_LDFLAGS = -module -avoid-version libshadow_la_LIBADD = $(top_builddir)/miext/shadow/libshadow.la libshadow_la_SOURCES = shmodule.c diff --git a/hw/xfree86/dixmods/extmod/Makefile.am b/hw/xfree86/dixmods/extmod/Makefile.am index cce19f7..87c28a4 100644 --- a/hw/xfree86/dixmods/extmod/Makefile.am +++ b/hw/xfree86/dixmods/extmod/Makefile.am @@ -21,7 +21,7 @@ INCLUDES = @XORG_INCS@ \ -I$(top_srcdir)/hw/xfree86/loader \ -I$(top_srcdir)/miext/shadow -libextmod_la_LDFLAGS = -avoid-version +libextmod_la_LDFLAGS = -module -avoid-version libextmod_la_SOURCES = modinit.c \ modinit.h \ $(DGA_SRCS) \ diff --git a/hw/xfree86/exa/Makefile.am b/hw/xfree86/exa/Makefile.am index 39f7a90..3ced531 100644 --- a/hw/xfree86/exa/Makefile.am +++ b/hw/xfree86/exa/Makefile.am @@ -2,7 +2,7 @@ SUBDIRS = man module_LTLIBRARIES = libexa.la -libexa_la_LDFLAGS = -avoid-version +libexa_la_LDFLAGS = -module -avoid-version INCLUDES = \ $(XORG_INCS) \ diff --git a/hw/xfree86/fbdevhw/Makefile.am b/hw/xfree86/fbdevhw/Makefile.am index 2a03890..4472acd 100644 --- a/hw/xfree86/fbdevhw/Makefile.am +++ b/hw/xfree86/fbdevhw/Makefile.am @@ -2,7 +2,7 @@ SUBDIRS = man module_LTLIBRARIES = libfbdevhw.la -libfbdevhw_la_LDFLAGS = -avoid-version +libfbdevhw_la_LDFLAGS = -module -avoid-version if FBDEVHW libfbdevhw_la_SOURCES = fbdevhw.c diff --git a/hw/xfree86/ramdac/Makefile.am b/hw/xfree86/ramdac/Makefile.am index 3c37805..d29ded5 100644 --- a/hw/xfree86/ramdac/Makefile.am +++ b/hw/xfree86/ramdac/Makefile.am @@ -1,5 +1,6 @@ noinst_LTLIBRARIES = libramdac.la +libramdac_la_LDFLAGS = -module -avoid-version libramdac_la_SOURCES = xf86RamDac.c xf86RamDacCmap.c \ xf86Cursor.c xf86HWCurs.c IBM.c BT.c TI.c \ xf86BitOrder.c diff --git a/hw/xfree86/shadowfb/Makefile.am b/hw/xfree86/shadowfb/Makefile.am index 02d2dd4..39c6610 100644 --- a/hw/xfree86/shadowfb/Makefile.am +++ b/hw/xfree86/shadowfb/Makefile.am @@ -1,5 +1,5 @@ module_LTLIBRARIES = libshadowfb.la -libshadowfb_la_LDFLAGS = -avoid-version +libshadowfb_la_LDFLAGS = -module -avoid-version libshadowfb_la_SOURCES = sfbmodule.c shadow.c sdk_HEADERS = shadowfb.h diff --git a/hw/xfree86/vbe/Makefile.am b/hw/xfree86/vbe/Makefile.am index 85c6fd8..4b794e6 100644 --- a/hw/xfree86/vbe/Makefile.am +++ b/hw/xfree86/vbe/Makefile.am @@ -1,5 +1,5 @@ module_LTLIBRARIES = libvbe.la -libvbe_la_LDFLAGS = -avoid-version +libvbe_la_LDFLAGS = -module -avoid-version libvbe_la_SOURCES = vbe.c vbeModes.c vbe_module.c sdk_HEADERS = vbe.h vbeModes.h diff --git a/hw/xfree86/xaa/Makefile.am b/hw/xfree86/xaa/Makefile.am index 5bfb4e9..7ebe0b9 100644 --- a/hw/xfree86/xaa/Makefile.am +++ b/hw/xfree86/xaa/Makefile.am @@ -8,7 +8,7 @@ MSB_FIXED = mf-xaaBitmap.c mf-xaaStipple.c mf-xaaTEGlyph.c MSB_3_FIXED = mf3-xaaBitmap.c mf3-xaaStipple.c POLYSEG = s-xaaLine.c s-xaaDashLine.c -libxaa_la_LDFLAGS =
[PATCH inputproto multitouch] Create separate structure for XI 2.2 XIAllowEvents request
The GetReq Xlib macro uses string contatenation of request names to
assign structures and get the appropriate size block from the Xlib
buffer. This means we can't use GetReq with a different struct name than
the original XI 2.0 name.
The only sane way around this seems to be to create a separate struct to
hold the new members of the extended request. Then, GetReqExtra can be
used to get a request set up correctly with extra room on the end for
the extended parameters.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
XI2proto.h | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 2460cf5..37304b9 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -647,10 +647,19 @@ typedef struct {
uint16_tdeviceid;
uint8_t mode;
uint8_t pad;
-uint32_ttouch_id; /** Since XI 2.2 */
-Window grab_window;/** Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 20 /** Was 12 before XI 2.2 */
+#define sz_xXIAllowEventsReq 12
+
+
+/**
+ * Allow or replay events on the specified grabbed device (XI 2.2 and on).
+ */
+typedef struct {
+xXIAllowEventsReq req_2_0;
+uint32_ttouch_id;
+Window grab_window;
+} xXIAllowEventsReq_2_2;
+#define sz_xXIAllowEvents_2_2Req 20
/**
--
1.7.4.1
___
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 libXi multitouch 1/4] Bump to 1.5.99 for XI 2.2 (multitouch) support
Signed-off-by: Chase Douglas chase.doug...@canonical.com --- configure.ac |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 02cf034..96d2a35 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ # Initialize Autoconf AC_PREREQ([2.60]) -AC_INIT([libXi], [1.4.99], +AC_INIT([libXi], [1.5.99], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXi]) AC_CONFIG_SRCDIR([Makefile.am]) AC_CONFIG_HEADERS([src/config.h]) @@ -28,7 +28,7 @@ XORG_WITH_ASCIIDOC(8.4.5) XORG_CHECK_MALLOC_ZERO # Obtain compiler/linker options for depedencies -PKG_CHECK_MODULES(XI, [xproto = 7.0.13] [x11 = 1.2.99.1] [xextproto = 7.0.3] [xext = 1.0.99.1] [inputproto = 1.9.99.902]) +PKG_CHECK_MODULES(XI, [xproto = 7.0.13] [x11 = 1.2.99.1] [xextproto = 7.0.3] [xext = 1.0.99.1] [inputproto = 2.1.99.1]) # Check for xmlto and asciidoc for man page conversion # (only needed by people building tarballs) -- 1.7.4.1 ___ 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 libXi multitouch 2/4] Make users aware of the unstable nature of this development branch
The library will fail to configure unless the --enable-unstable-library flag is used. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- configure.ac |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 96d2a35..6c2f731 100644 --- a/configure.ac +++ b/configure.ac @@ -30,6 +30,15 @@ XORG_CHECK_MALLOC_ZERO # Obtain compiler/linker options for depedencies PKG_CHECK_MODULES(XI, [xproto = 7.0.13] [x11 = 1.2.99.1] [xextproto = 7.0.3] [xext = 1.0.99.1] [inputproto = 2.1.99.1]) +# Make sure the user knows what they are doing! +AC_ARG_ENABLE(unstable-library, + AS_HELP_STRING([--enable-unstable-library], + [Enables compilation of yet-to-be-finalised library (default: disabled)]), + [UNSTABLE_LIB=$enableval], [UNSTABLE_LIB=no]) +if ! test x$UNSTABLE_LIB = xyes; then +AC_MSG_ERROR([This branch contains elements which have not yet been finalised. When this branch is updated, you will probably need to recompile both the any clients using the library, and may experience crashes or undefined behaviour if you do not.]) +fi + # Check for xmlto and asciidoc for man page conversion # (only needed by people building tarballs) if test $have_xmlto = yes test $have_asciidoc = yes; then -- 1.7.4.1 ___ 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 libXi multitouch 3/4] Define macros for unstable protocol development
Signed-off-by: Chase Douglas chase.doug...@canonical.com --- configure.ac |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 6c2f731..f3d6d8e 100644 --- a/configure.ac +++ b/configure.ac @@ -39,6 +39,9 @@ if ! test x$UNSTABLE_LIB = xyes; then AC_MSG_ERROR([This branch contains elements which have not yet been finalised. When this branch is updated, you will probably need to recompile both the any clients using the library, and may experience crashes or undefined behaviour if you do not.]) fi +# Define macros for compiling with unstable protocols +AC_SUBST(CFLAGS, -DXINPUT2_1_USE_UNSTABLE_PROTOCOL -DXINPUT2_2_USE_UNSTABLE_PROTOCOL) + # Check for xmlto and asciidoc for man page conversion # (only needed by people building tarballs) if test $have_xmlto = yes test $have_asciidoc = yes; then -- 1.7.4.1 ___ 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 libXi multitouch 4/4] Implement support for XI 2.2
XI 2.1 has not been implemented yet, so this code defines version info
for it too. These will be dropped when XI 2.1 support is merged.
The code is based on what we have in the prototype libXi in Ubuntu. The
main differences are:
* No touch valuator classes
* No TouchUpdateUnownedEvents
* Addition of raw touch events
* Touch grab and ungrab is handled in existing passive grab functions
* XIAllowTouchEvents has been added as an extension of XIAllowEvents
* XIAllowEvents has been extended when XI 2.2 is supported
The last item causes a bit of an issue. The XIAllowEvents handling in
released X.org servers check that the size of the request is exactly the
size published in XI 2.0. Since we are extending the request, we must
get the right request size from the Xlib buffer depending on what
version of XI the server supports.
None of this code has been tested because we don't have a server to test
it with yet.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
include/X11/extensions/XInput2.h | 33 ++
src/XExtInt.c| 88 +-
src/XIAllowEvents.c | 51 +-
src/XIint.h |2 +
4 files changed, 172 insertions(+), 2 deletions(-)
diff --git a/include/X11/extensions/XInput2.h b/include/X11/extensions/XInput2.h
index 3fcf083..93b980d 100644
--- a/include/X11/extensions/XInput2.h
+++ b/include/X11/extensions/XInput2.h
@@ -135,6 +135,14 @@ typedef struct
typedef struct
{
+int type;
+int sourceid;
+int mode;
+int num_touches;
+} XITouchClassInfo;
+
+typedef struct
+{
int deviceid;
char*name;
int use;
@@ -292,6 +300,23 @@ typedef struct {
int what;
} XIPropertyEvent;
+typedef struct {
+int type; /* GenericEvent */
+unsigned long serial; /* # of last request processed by server */
+Bool send_event; /* true if this came from a SendEvent request
*/
+Display *display; /* Display the event was read from */
+int extension;/* XI extension offset */
+int evtype;
+Time time;
+int deviceid;
+int sourceid;
+unsigned int touchid;
+Windowroot;
+Windowevent;
+Windowchild;
+int flags;
+} XITouchOwnershipEvent;
+
_XFUNCPROTOBEGIN
extern Bool XIQueryPointer(
@@ -415,6 +440,14 @@ extern Status XIAllowEvents(
Timetime
);
+extern Status XIAllowTouchEvents(
+Display*display,
+int deviceid,
+unsigned inttouch_id,
+Window grab_window,
+int event_mode
+);
+
extern int XIGrabButton(
Display*display,
int deviceid,
diff --git a/src/XExtInt.c b/src/XExtInt.c
index 86a780e..598f302 100644
--- a/src/XExtInt.c
+++ b/src/XExtInt.c
@@ -146,6 +146,9 @@ static int
wireToEnterLeave(xXIEnterEvent *in, XGenericEventCookie *cookie);
static int
wireToPropertyEvent(xXIPropertyEvent *in, XGenericEventCookie *cookie);
+static int
+wireToTouchOwnershipEvent(xXITouchOwnershipEvent *in,
+ XGenericEventCookie *cookie);
static /* const */ XEvent emptyevent;
@@ -270,7 +273,9 @@ static XExtensionVersion versions[] = { {XI_Absent, 0, 0},
XI_Add_DevicePresenceNotify_Minor},
{XI_Present, XI_Add_DeviceProperties_Major,
XI_Add_DeviceProperties_Minor},
-{XI_Present, 2, 0}
+{XI_Present, 2, 0},
+{XI_Present, 2, 1},
+{XI_Present, 2, 2}
};
/***
@@ -923,6 +928,9 @@ XInputWireToCookie(
case XI_ButtonRelease:
case XI_KeyPress:
case XI_KeyRelease:
+case XI_TouchBegin:
+case XI_TouchUpdate:
+case XI_TouchEnd:
*cookie = *(XGenericEventCookie*)save;
if (!wireToDeviceEvent((xXIDeviceEvent*)event, cookie))
{
@@ -949,12 +957,25 @@ XInputWireToCookie(
break;
}
return ENQUEUE_EVENT;
+case XI_TouchOwnership:
+*cookie = *(XGenericEventCookie*)save;
+if (!wireToTouchOwnershipEvent((xXITouchOwnershipEvent*)event,
+ cookie))
+{
+printf(XInputWireToCookie: CONVERSION FAILURE! evtype=%d\n,
+ge-evtype);
+break;
+}
+return ENQUEUE_EVENT;
case XI_RawKeyPress:
case XI_RawKeyRelease:
case XI_RawButtonPress:
case XI_RawButtonRelease:
case XI_RawMotion:
+case XI_RawTouchBegin:
+case XI_RawTouchUpdate:
+case XI_RawTouchEnd:
*cookie = *(XGenericEventCookie*)save;
if
