[PATCH libXt] Use automake silent rules for BUILT_SOURCES generation
From: Yaakov Selkowitz yselkow...@users.sourceforge.net Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- src/Makefile.am | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index a43fb22..2b39ec5 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -97,9 +97,9 @@ all-local: $(BUILT_FILES) $(BUILT_HEADER): $(BUILT_SOURCE) $(BUILT_SOURCE): - $(top_builddir)/util/makestrs -i $(top_srcdir) $(STRINGSABIOPTIONS) $(STRING_LIST) StringDefs.c - mkdir -p $(top_builddir)/src - mkdir -p $(top_builddir)/include/X11 - cp StringDefs.h $(top_builddir)/include/X11 - cp Shell.h $(top_builddir)/include/X11 - rm StringDefs.h Shell.h + $(AM_V_GEN)$(top_builddir)/util/makestrs -i $(top_srcdir) $(STRINGSABIOPTIONS) $(STRING_LIST) StringDefs.c + $(AM_V_at)mkdir -p $(top_builddir)/src + $(AM_V_at)mkdir -p $(top_builddir)/include/X11 + $(AM_V_at)cp StringDefs.h $(top_builddir)/include/X11 + $(AM_V_at)cp Shell.h $(top_builddir)/include/X11 + $(AM_V_at)rm StringDefs.h Shell.h -- 1.6.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
Re: Multitouch followup: gesture recognition?
Just specifying what gestures a specific window would be interested in
wouldn't usually be live, would it? That's something defined at
creation time and maybe changed occasionally over the lifetime, but not
constantly.
Which is why a declarative approach is OK for that. It's the dynamics
that make it harder. More specificially, the dynamic part of your
formalism likely needs tailored requests.
The reason for this being that the special client won't be notified of
property changes on other client windows, correct?
Not quite, the sgc could probably register for prop changes. By
'dynamics' I was referring to cancelling a gesture or other gesture
state feedback a client may want to send. Props aren't good for that,
but requests are.
In requests, you're free to define semantics, whereas props are limited
and quite racy.
OK, I see. I'll probably stay with properties for the first attempt (the
protocol used in my userspace lib doesn't require any such realtime callbacks
right now). I'll probably blatantly ignore _any_ performance-related
issues in the prototype, just to get a general feel for the problem.
If you want to try a special client, it's therefore sensible to divide
your requests and events into route-through (client - special gesture
client or sgc - client) and server-processed (server-sgc or sgc-
server), if possible.
As far as I understand the architecture, everything except the plain
input events would be just routed through the server between the two
clients. In fact, I guess that after defining some custom events in
Yes, part of the idea is that the server provides only the
infrastructure. Routing, simple state tracking, somesuch.
Good - seems I've finally understood that part :-)
inputproto, it should be possible to send them through
XSend{Extension}Event?
At first glance it looks suitable, but I'm not convinced it is
appropriate. You'll want the server to select which clients get events,
as is done with Xi event masks. This way, the gesture client doesn't
need to know about all the windows out there.
Also, I recall Xi2 and Xi1 (XSendExtensionEvent) shouldn't be mixed.
I've had a brief look at the code in libXi, and AFAICT there's nothing
to prevent this from working with any custom event, as long as
_XiEventToWire is adapted, too. Peter, maybe you could comment on this?
// select motion events for entire screen
XIEventMask mask;
mask.deviceid = XIAllDevices;
mask.mask_len = XIMaskLen( XI_LASTEVENT );
mask.mask = (unsigned char*)calloc( mask.mask_len, sizeof(char) );
XISetMask( mask.mask, XI_Motion );
XISetMask( mask.mask, XI_ButtonPress );
XISetMask( mask.mask, XI_ButtonRelease );
XISelectEvents( display, DefaultRootWindow(display), mask, 1 );
free( mask.mask );
to capture all XInput events, however, I believe that's also quite
flawed. What other options exist?
To me it seems sane.
This replication of all input is one of the reasons for the 'special' in
'special gesture client'. Whatever it shall be it should probably be a
part of Xi2. What leads you to think the above is flawed ?
The main reason why this code isn't yet sufficient IMHO is that I
haven't yet found out how to get some additional data from the received
events, particularly
a) which client window the event is actually targeted at and
b) what the position in window-relative coordinates is.
These are probably related, can you give me a hint how to retrieve this
information?
Florian
--
0666 - Filemode of the Beast
___
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 xinput 1/2] man: Use AC_PROG_SED to find sed
On Thu, Apr 1, 2010 at 10:30 PM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: From: Yaakov Selkowitz yselkow...@users.sourceforge.net Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ 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: Multitouch followup: gesture recognition?
Am 02.04.2010 10:52, schrieb Florian Echtler: Just specifying what gestures a specific window would be interested in wouldn't usually be live, would it? That's something defined at creation time and maybe changed occasionally over the lifetime, but not constantly. Which is why a declarative approach is OK for that. It's the dynamics that make it harder. More specificially, the dynamic part of your formalism likely needs tailored requests. The reason for this being that the special client won't be notified of property changes on other client windows, correct? Not quite, the sgc could probably register for prop changes. By 'dynamics' I was referring to cancelling a gesture or other gesture state feedback a client may want to send. Props aren't good for that, but requests are. In requests, you're free to define semantics, whereas props are limited and quite racy. OK, I see. I'll probably stay with properties for the first attempt (the protocol used in my userspace lib doesn't require any such realtime callbacks right now). I'll probably blatantly ignore _any_ performance-related issues in the prototype, just to get a general feel for the problem. Not needing callbacks even in-process (where they're cheap) sounds like an excellent precondition for such an implementation. Though I'd guess it won't stay like that forever. To me it seems sane. This replication of all input is one of the reasons for the 'special' in 'special gesture client'. Whatever it shall be it should probably be a part of Xi2. What leads you to think the above is flawed ? The main reason why this code isn't yet sufficient IMHO is that I haven't yet found out how to get some additional data from the received events, particularly a) which client window the event is actually targeted at and b) what the position in window-relative coordinates is. I think this is intentional. You only get 'your events'. It's possible you need to explicitly knock up a sort-of input cc mechanism to divert the flow as appropriate. In that case, I guess the solution would need to be minimally intrusive to be acceptable. CC'ing input may have security implications as well. But as always, Peter may know something better ;) Cheers, Simon ___ 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 xinput 1/2] man: Use AC_PROG_SED to find sed
On Fri, 2010-04-02 at 00:30 -0500, Yaakov (Cygwin/X) wrote: From: Yaakov Selkowitz yselkow...@users.sourceforge.net Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- configure.ac|1 + man/Makefile.am |4 +--- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 32facc7..c50b7b2 100644 --- a/configure.ac +++ b/configure.ac @@ -16,6 +16,7 @@ AM_CONFIG_HEADER(config.h) AC_PROG_CC AC_PROG_INSTALL +AC_PROG_SED # Checks for pkg-config packages diff --git a/man/Makefile.am b/man/Makefile.am index db77de2..7902ff7 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -27,8 +27,6 @@ appman_DATA = $(appman_PRE:m...@app_man_suffix@) EXTRA_DIST = $(appman_PRE) CLEANFILES = $(appman_DATA) -SED = sed - # Strings to replace in man pages XORGRELSTRING = @PACKAGE_STRING@ XORGMANNAME = X Version 11 @@ -49,5 +47,5 @@ MAN_SUBSTS = \ SUFFIXES = .$(APP_MAN_SUFFIX) .man .man.$(APP_MAN_SUFFIX): - sed $(MAN_SUBSTS) $ $@ + $(SED) $(MAN_SUBSTS) $ $@ Acked-by: Gaetan Nadon mems...@videotron.ca 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 libXt] Use automake silent rules for BUILT_SOURCES generation
On Fri, 2010-04-02 at 01:44 -0500, Yaakov (Cygwin/X) wrote: From: Yaakov Selkowitz yselkow...@users.sourceforge.net Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- src/Makefile.am | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index a43fb22..2b39ec5 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -97,9 +97,9 @@ all-local: $(BUILT_FILES) $(BUILT_HEADER): $(BUILT_SOURCE) $(BUILT_SOURCE): - $(top_builddir)/util/makestrs -i $(top_srcdir) $(STRINGSABIOPTIONS) $(STRING_LIST) StringDefs.c - mkdir -p $(top_builddir)/src - mkdir -p $(top_builddir)/include/X11 - cp StringDefs.h $(top_builddir)/include/X11 - cp Shell.h $(top_builddir)/include/X11 - rm StringDefs.h Shell.h + $(AM_V_GEN)$(top_builddir)/util/makestrs -i $(top_srcdir) $(STRINGSABIOPTIONS) $(STRING_LIST) StringDefs.c + $(AM_V_at)mkdir -p $(top_builddir)/src + $(AM_V_at)mkdir -p $(top_builddir)/include/X11 + $(AM_V_at)cp StringDefs.h $(top_builddir)/include/X11 + $(AM_V_at)cp Shell.h $(top_builddir)/include/X11 + $(AM_V_at)rm StringDefs.h Shell.h Acked-by: Gaetan Nadon mems...@videotron.ca 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:macros] doc: add XORG_CHECK_SGML_DOCTOOLS to detect xorg-sgml-doctools
On 2010-03-25 20:00, Gaetan Nadon wrote: All set to go. Thanks. I modified slightly the doctools patch per the recent thread, as the .pc.in need not be in EXTRA_DIST because it will be disted automatically since it is used by AC_OUTPUT. To implement this we need to: 1) Push these commits to doctools and macros. 2) Version bump and release doctools-1.4. 3) Version bump and release macros-1.7.0. Who shall do this, and when? Yaakov Cygwin/X ___ 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 4/4] xfree86: Fix reference to SGML entities
On 2010-03-25 03:46, Yaakov (Cygwin/X) wrote: From: Yaakov Selkowitzyselkowitz-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org XORG_CHECK_LINUXDOC sets the SGML search path to the parent of X11/defs.ent. Signed-off-by: Yaakov Selkowitzyselkowitz-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org --- hw/xfree86/doc/sgml/DESIGN.sgml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/doc/sgml/DESIGN.sgml b/hw/xfree86/doc/sgml/DESIGN.sgml index 5beff65..e95df79 100644 --- a/hw/xfree86/doc/sgml/DESIGN.sgml +++ b/hw/xfree86/doc/sgml/DESIGN.sgml @@ -1,5 +1,5 @@ !DOCTYPE linuxdoc PUBLIC -//Xorg//DTD linuxdoc//EN [ -!ENTITY % defs SYSTEM defs.ent %defs; +!ENTITY % defs SYSTEM X11/defs.ent %defs; !-- config file keyword markup -- !ENTITY s.key STARTTAG bf !ENTITY e.key ENDTAG bf Ping? Yaakov Cygwin/X ___ 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
[PULL] Cygwin configure fixes
These patches for configure are all Cygwin-specific, and are necessary for the xserver build to succeed when configure is run without arguments. They were posted to the list 10 days ago but received no reviews. The following changes since commit 495cec794dad95ed0c79048f3c410ad23e7d5ea4: Keith Packard (1): xserver 1.8.0 are available in the git repository at: git://anongit.freedesktop.org/~yselkowitz/xserver.git master Jon TURNEY (1): Don't enable ROOTLESS_WORKAROUND, it breaks composite Yaakov Selkowitz (3): Disable setuid configure test on Cygwin Cygwin/X: Disable unsupported extensions in configure Cygwin/X: Add configure option for WindowsWM configure.ac | 37 +++-- 1 files changed, 23 insertions(+), 14 deletions(-) ___ 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 xfree86] Don't keep a pointer to a possibly freed cursor when changing screens, preventing a crash in xf86CursorEnableDisableFBAccess() trying to restore it.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com --- hw/xfree86/ramdac/xf86Cursor.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c index 7f23d9e..f5f0873 100644 --- a/hw/xfree86/ramdac/xf86Cursor.c +++ b/hw/xfree86/ramdac/xf86Cursor.c @@ -312,6 +312,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCurs, xf86SetCursor(pScreen, NullCursor, x, y); ScreenPriv-isUp = FALSE; } +ScreenPriv-CurrentCursor = NullCursor; return; } -- 1.7.0 --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ 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: introduce --{enable, disable}-syscall-clock
On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson a...@redhat.com wrote: On Mon, 2010-03-29 at 11:02 -0700, Alan Coopersmith wrote: Tiago Vignatti wrote: Some systems might not want to link against rt and pthread libraries simply to implement monotonic clock, inside GetTimeInMillis(). For those, use a direct syscall instead. This patch keeps the new syscall version disabled by default - therefore not changing the original behaviour of the xserver build. The main concern was regarding some eventual performance degradation when not going through optimized code in C library, or because syscall is varargs based. That's actually my secondary concern - my primary concern is that on most non-Linux systems, the system libraries are the public, stable, supported, documented interface, and syscall() is a private implementation detail to those, which applications are strongly discouraged from calling directly. Yeah, it's not really something I want Linux to default to using either. I mean, we're going to want input threads, so slicing off librt just because it pulls in libpthread is a bit temporary. And Mesa's GLX support pulls in pthreads already, so the class of device where this applies is pretty thin. At the moment, clock_gettime() is the only reason I can't get Mesa off of libpthread. Before a bunch of ugly hacking in libdrm, the overhead From pthreads presence was around 10% CPU time on CPU-bound apps on i965. These days it's down to a few percent. It seems to me like the real problem is that clock_gettime() isn't in glibc without the pthreads cost. Perhaps someone could look into that instead of hacking around it in its consumers? pgpUT4KDV0U0S.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] vfb: add a name to the pointer and keyboard
Fixes a crash in XIQueryDevice which calls strlen on a NULL pointer. #0 strlen () at ../sysdeps/x86_64/strlen.S:31 #1 0x004c16ed in SizeDeviceInfo (dev=0x969bd0) at ../../Xi/xiquerydevice.c:204 #2 0x004c1a01 in ProcXIQueryDevice (client=0xa57510) at ../../Xi/xiquerydevice.c:98 Debian bug#575905 http://bugs.debian.org/575905 Reported-by: Bernhard R. Link brl...@debian.org Signed-off-by: Julien Cristau jcris...@debian.org --- Resending with fixed commit message, git had eaten the lines starting with #. hw/vfb/InitInput.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/vfb/InitInput.c b/hw/vfb/InitInput.c index 35d1dc4..3136e93 100644 --- a/hw/vfb/InitInput.c +++ b/hw/vfb/InitInput.c @@ -139,7 +139,9 @@ InitInput(int argc, char *argv[]) p = AddInputDevice(serverClient, vfbMouseProc, TRUE); k = AddInputDevice(serverClient, vfbKeybdProc, TRUE); RegisterPointerDevice(p); +p-name = strdup(mouse); RegisterKeyboardDevice(k); +k-name = strdup(keyboard); (void)mieqInit(); } -- 1.7.0.3 ___ 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
