Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Thu, May 03, 2012 at 12:40:58PM +1000, Christopher James Halse Rogers wrote:
> On Thu, 2012-05-03 at 11:05 +1000, Peter Hutterer wrote:
> > On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers
> > wrote:
> > > ---
> > >
> > > I've got a corresponding xserver patch, but it needs updating for the
> > > Great Reindent of '12. Might as well get support for the protocol
> > > additions
> > > before fixing it up.
> > >
> > > A slightly different variant of this (it's gone through a number of
> > > iterations
> > > in conjunction with the Unity team) is used by the Unity shell as
> > > infrastructure
> > > for the one-launcher-per-display support, so there's evidence that it's a
> > > usable
> > > protocol.
> >
> > looks good, a few minor clarifications are needed below. The main change I'd
> > like to see is a change to use generic events instead of a standard event..
>
> I'll finish reading up on how to make that happen, then :)
>
> >
> > we've hit the maximum event number in the past, adding another non-generic
> > event can cause us to stretch over the limit.
> > http://lists.x.org/archives/xorg-devel/2010-March/006716.html
> >
> > > configure.ac |2 +-
> > > fixesproto.txt | 94
> > >
> > > xfixesproto.h | 59 +++
> > > xfixeswire.h | 23 +++--
> > > 4 files changed, 173 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/configure.ac b/configure.ac
> > > index f85b802..07dd29a 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -22,7 +22,7 @@ dnl
> > > dnl Process this file with autoconf to create configure.
> > >
> > > AC_PREREQ([2.60])
> > > -AC_INIT([FixesProto], [5.0],
> > > +AC_INIT([FixesProto], [6.0],
> > > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > > AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > > AM_MAINTAINER_MODE
> > > diff --git a/fixesproto.txt b/fixesproto.txt
> > > index 5903ac9..6f8c705 100644
> > > --- a/fixesproto.txt
> > > +++ b/fixesproto.txt
> > > @@ -650,6 +650,100 @@ DestroyPointerBarrier
> > >
> > > Errors: Barrier
> > >
> > > +* XFIXES VERSION 6 OR BETTER ***
> > > +
> > > +13. Pointer Barriers Expansion
> > > +
> > > +This update extends pointer barriers to optionally allow the pointer
> > > through
> > > +when a threshold is reached. This can be useful for desktop
> > > environments that
> > > +wish to use a large region of the screen, such as an entire edge, to
> > > provide a
> > > +casual target while allowing determined movement to pass through.
> > > +
> > > +13.1 Types
> > > +
> > > + BarrierEvent: {Hit, ThresholdExceeded}
> > > + BarrierEventID: CARD32
> > > +
> > > +13.2 Events
> > > +
> > > +BarrierNotify
> > > +
> > > + subtype:BarrierEvent
> > > + window: WINDOW
> > > + event-id: BarrierEventID
> > > + barrier:BARRIER
> > > + velocity: CARD32
> > > + x, y: INT16
> > > + raw-displacement: FP1616
> > > + delta-t:INT16
> > > + deviceid: INT16
> > > +
> > > +13.3 Requests
> > > +
> > > +SelectBarrierInput
> > > +
> > > + window: WINDOW
> > > + event-mask: SETofBarrierEvent
> > > +
> > > +
> > > + This request directs barrier events to the named window. Subtype
> > > + indicates the trigger of the event, which is Hit when the barrier has
> > > + prevented pointer movement and ThresholdExceeded when the barrier has
> > > + been hit but has not prevented pointer movement due to the threshold
> > > + being exceeded.
> > > +
> > > + Barrier is the barrier on which the event was triggered. (x,y) contain
> > > + the coordinates of the pointer after restriction by any applicable
> > > + barriers, and velocity is the unrestricted instantaneous velocity
> > > + of the pointer, perpendicular to the barrier.
> >
> > how is velocity defined?
> > (edit: found it below, this should be either in some common section or
> > everywhere. You could just define a VELOCITY type and explain it there)
>
> That makes sense, I'll do so.
>
> >
> > > +
> > > + deviceid is the identifier of the device which caused the barrier
> > > + event, raw-displacement and delta-t are the raw valuator (purpendicular
> >
> > I'm not sure what you raw-displacement here is, can you clarify?
> >
>
> Raw-displacement is exactly the value you'd get if you were subscribed
> to XI 2 raw events and selected the valuator perpendicular to the
> barrier.
>
> It (and delta-t) are here so that a client can get a pre-acceleration
> idea of the velocity and user behaviour if the client desires. This is
> useful for clients to determine when they want to release the barrier.
Two questions:
Is this really enough then?
Re: [PULL 1.12] input fixes for 1.12
Thanks. ed33772..22a1953 server-1.12-branch -> server-1.12-branch On May 2, 2012, at 18:36, Peter Hutterer wrote: > Particularly the timer fix and #47281 are important, both can send the > server into an infinite loop. > > The following changes since commit ed33772a0d3ace5844e157ae78885ded000819ea: > > xfree86: workaround crash on close (2012-04-26 21:07:09 -0700) > > are available in the git repository at: > > git://people.freedesktop.org/~whot/xserver server-1.12-branch > > for you to fetch changes up to 90299556db24543bb7365e8c2897deca3aa219e7: > > dix: when disabling a device, release all buttons and keys (2012-05-03 > 11:24:44 +1000) > > > Chase Douglas (1): > TouchListenerAcceptReject: Warn and return early on bad listener index > > Peter Hutterer (3): > os: make timers signal-safe > dix: don't emulate scroll events for non-existing axes (#47281) > dix: when disabling a device, release all buttons and keys > > dix/devices.c |2 ++ > dix/getevents.c |3 +++ > dix/touch.c |5 + > os/WaitFor.c| 18 -- > 4 files changed, 26 insertions(+), 2 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
Re: [PULL] XIQueryPointer fixes
On Thu, 3 May 2012 11:21:32 +1000, Peter Hutterer wrote: > Chase Douglas (2): > Report logical button state in ProcXIQueryPointer > Report touch emulated buttons in XIQueryPointer for XI 2.1 and earlier 1908272..9704136 master -> master -- keith.pack...@intel.com pgpZfzsIIaRFu.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/4] os/log: refactor logging
On Wed, Apr 18, 2012 at 05:51:53PM +0800, Daniel Kurtz wrote:
> It is not safe to ever use an arbitrary (possibly user supplied) string as
> part of the format for a *sprintf() call.
>
> For example:
> 1. Name a Bluetooth keyboard "%n%n%n%n%n%n%n%n"
> 2. Pair it with a computer running X and try to use it
> 3. X is not happy when trying to do the following in xf86-input-evdev:
> xf86IDrvMsg(pInfo, X_CONFIG, "Device: \"%s\"\n", device);
> because LogVHdrMessageVerb() has put the %n from the device name
> into a format string.
>
> Instead, build up a log message in place by appending successive formatted
> strings by sncprintf'ing to the end of the previous.
>
> Signed-off-by: Daniel Kurtz
verified and all 4 merged, thanks. took me a while to find the actual issue
because I was looking in the wrong place. for the archives: The culprit here
was not the user-supplied format string but rather xf86IDrvMsg using the
device's name, assembling a format string in the form of
: : message
i.e.
"evdev: %n%n%n%n: Device \"%s\"\n"
and using that as format string to LogVWrite.
Cheers,
Peter
> ---
> os/log.c | 97 +
> 1 files changed, 46 insertions(+), 51 deletions(-)
>
> diff --git a/os/log.c b/os/log.c
> index 36378e4..2c13c1a 100644
> --- a/os/log.c
> +++ b/os/log.c
> @@ -268,36 +268,19 @@ LogSetParameter(LogParameter param, int value)
> }
>
> /* This function does the actual log message writes. */
> -
> -void
> -LogVWrite(int verb, const char *f, va_list args)
> +static void
> +LogSWrite(int verb, const char *buf, size_t len, Bool end_line)
> {
> -static char tmpBuffer[1024];
> -int len = 0;
> static Bool newline = TRUE;
>
> -if (verb > logFileVerbosity && verb > logVerbosity)
> -return;
> -
> -/*
> - * Since a va_list can only be processed once, write the string to a
> - * buffer, and then write the buffer out to the appropriate output
> - * stream(s).
> - */
> -if (verb < 0 || logFileVerbosity >= verb || logVerbosity >= verb) {
> -len = Xvscnprintf(tmpBuffer, sizeof(tmpBuffer), f, args);
> -/* If message is truncated, terminate with '\n' */
> -if (sizeof(tmpBuffer) - len == 1)
> -tmpBuffer[len - 1] = '\n';
> -}
> -if ((verb < 0 || logVerbosity >= verb) && len > 0)
> -fwrite(tmpBuffer, len, 1, stderr);
> -if ((verb < 0 || logFileVerbosity >= verb) && len > 0) {
> +if (verb < 0 || logVerbosity >= verb)
> +fwrite(buf, len, 1, stderr);
> +if (verb < 0 || logFileVerbosity >= verb) {
> if (logFile) {
> if (newline)
> fprintf(logFile, "[%10.3f] ", GetTimeInMillis() / 1000.0);
> -newline = (tmpBuffer[len - 1] == '\n');
> -fwrite(tmpBuffer, len, 1, logFile);
> +newline = end_line;
> +fwrite(buf, len, 1, logFile);
> if (logFlush) {
> fflush(logFile);
> #ifndef WIN32
> @@ -315,13 +298,19 @@ LogVWrite(int verb, const char *f, va_list args)
> FatalError("realloc() failed while saving log
> messages\n");
> }
> bufferUnused -= len;
> -memcpy(saveBuffer + bufferPos, tmpBuffer, len);
> +memcpy(saveBuffer + bufferPos, buf, len);
> bufferPos += len;
> }
> }
> }
>
> void
> +LogVWrite(int verb, const char *f, va_list args)
> +{
> +return LogVMessageVerb(X_NONE, verb, f, args);
> +}
> +
> +void
> LogWrite(int verb, const char *f, ...)
> {
> va_list args;
> @@ -376,22 +365,28 @@ void
> LogVMessageVerb(MessageType type, int verb, const char *format, va_list args)
> {
> const char *type_str;
> -char tmpFormat[1024];
> -const char *new_format;
> +char buf[1024];
> +const size_t size = sizeof(buf);
> +Bool newline;
> +size_t len = 0;
>
> type_str = LogMessageTypeVerbString(type, verb);
> if (!type_str)
> return;
>
> -/* if type_str is not "", prepend it and ' ', to format */
> -if (type_str[0] == '\0')
> -new_format = format;
> -else {
> -new_format = tmpFormat;
> -snprintf(tmpFormat, sizeof(tmpFormat), "%s %s", type_str, format);
> -}
> +/* if type_str is not "", prepend it and ' ', to message */
> +if (type_str[0] != '\0')
> +len += Xscnprintf(&buf[len], size - len, "%s ", type_str);
> +
> +if (size - len > 1)
> +len += Xvscnprintf(&buf[len], size - len, format, args);
> +
> +/* Force '\n' at end of truncated line */
> +if (size - len == 1)
> +buf[len - 1] = '\n';
>
> -LogVWrite(verb, new_format, args);
> +newline = (buf[len - 1] == '\n');
> +LogSWrite(verb, buf, len, newline);
> }
>
> /* Log message with verbosity level specified. */
> @@ -421,31 +416,31 @@ LogVHdrMessageVerb(MessageType type, int verb, const
> char *msg_format,
>
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Thu, 2012-05-03 at 11:12 +1000, Peter Hutterer wrote:
> On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers
> wrote:
> > ---
> >
> > I've got a corresponding xserver patch, but it needs updating for the
> > Great Reindent of '12. Might as well get support for the protocol
> > additions
> > before fixing it up.
> >
> > A slightly different variant of this (it's gone through a number of
> > iterations
> > in conjunction with the Unity team) is used by the Unity shell as
> > infrastructure
> > for the one-launcher-per-display support, so there's evidence that it's a
> > usable
> > protocol.
> >
> > configure.ac |2 +-
> > fixesproto.txt | 94
> >
> > xfixesproto.h | 59 +++
> > xfixeswire.h | 23 +++--
> > 4 files changed, 173 insertions(+), 5 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index f85b802..07dd29a 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -22,7 +22,7 @@ dnl
> > dnl Process this file with autoconf to create configure.
> >
> > AC_PREREQ([2.60])
> > -AC_INIT([FixesProto], [5.0],
> > +AC_INIT([FixesProto], [6.0],
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > AM_MAINTAINER_MODE
> > diff --git a/fixesproto.txt b/fixesproto.txt
> > index 5903ac9..6f8c705 100644
> > --- a/fixesproto.txt
> > +++ b/fixesproto.txt
> > @@ -650,6 +650,100 @@ DestroyPointerBarrier
> >
> > Errors: Barrier
> >
> > +* XFIXES VERSION 6 OR BETTER ***
> > +
> > +13. Pointer Barriers Expansion
> > +
> > +This update extends pointer barriers to optionally allow the pointer
> > through
> > +when a threshold is reached. This can be useful for desktop environments
> > that
> > +wish to use a large region of the screen, such as an entire edge, to
> > provide a
> > +casual target while allowing determined movement to pass through.
> > +
> > +13.1 Types
> > +
> > + BarrierEvent: {Hit, ThresholdExceeded}
> > + BarrierEventID: CARD32
> > +
> > +13.2 Events
> > +
> > +BarrierNotify
> > +
> > + subtype:BarrierEvent
> > + window: WINDOW
> > + event-id: BarrierEventID
> > + barrier:BARRIER
> > + velocity: CARD32
> > + x, y: INT16
> > + raw-displacement: FP1616
> > + delta-t:INT16
> > + deviceid: INT16
> > +
> > +13.3 Requests
> > +
> > +SelectBarrierInput
> > +
> > + window: WINDOW
> > + event-mask: SETofBarrierEvent
> > +
> > +
> > + This request directs barrier events to the named window. Subtype
> > + indicates the trigger of the event, which is Hit when the barrier has
> > + prevented pointer movement and ThresholdExceeded when the barrier has
> > + been hit but has not prevented pointer movement due to the threshold
> > + being exceeded.
> > +
> > + Barrier is the barrier on which the event was triggered. (x,y) contain
> > + the coordinates of the pointer after restriction by any applicable
> > + barriers, and velocity is the unrestricted instantaneous velocity
> > + of the pointer, perpendicular to the barrier.
> > +
> > + deviceid is the identifier of the device which caused the barrier
> > + event, raw-displacement and delta-t are the raw valuator (purpendicular
> > + to the barrier) and time-since-last-input-event for deviceid
> > + respectively.
> > +
> > + event-id is an identifier for this barrier event. A barrier event
> > + begins when the pointer is first restricted by the barrier, and ends
> > + with the first mouse event that is not restricted by the barrier.
> > +
> > + In the case of multiple overlapping barriers an event is sent for each.
>
> are events triggered on barriers without velocity?
Yes. I could make this more obvious by explicitly stating that barriers
without velocity will never send ThresholdExceeded.
>
> > +
> > +CreatePointerBarrierVelocity
> > +
> > + barrier:BARRIER
> > + drawable: DRAWABLE
> > + x1, y2, x2, y2: INT16
> > + directions: CARD32
> > + velocity: CARD32
> > + devices:LISTofDEVICEID
> > +
> > + Creates a pointer barrier along the line specified by the given
> > + coordinates on the screen associated with the given drawable. This
> > + has identical semantics to CreatePointerBarrier, except that the
> > + barrier created will not block the pointer if the threshold
> > + velocity is exceeded. The velocity is measured in px/sec perpendicular
> > + to the barrier.
> > +
> > + Once the pointe
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Thu, 2012-05-03 at 11:05 +1000, Peter Hutterer wrote:
> On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers
> wrote:
> > ---
> >
> > I've got a corresponding xserver patch, but it needs updating for the
> > Great Reindent of '12. Might as well get support for the protocol
> > additions
> > before fixing it up.
> >
> > A slightly different variant of this (it's gone through a number of
> > iterations
> > in conjunction with the Unity team) is used by the Unity shell as
> > infrastructure
> > for the one-launcher-per-display support, so there's evidence that it's a
> > usable
> > protocol.
>
> looks good, a few minor clarifications are needed below. The main change I'd
> like to see is a change to use generic events instead of a standard event.
I'll finish reading up on how to make that happen, then :)
>
> we've hit the maximum event number in the past, adding another non-generic
> event can cause us to stretch over the limit.
> http://lists.x.org/archives/xorg-devel/2010-March/006716.html
>
> > configure.ac |2 +-
> > fixesproto.txt | 94
> >
> > xfixesproto.h | 59 +++
> > xfixeswire.h | 23 +++--
> > 4 files changed, 173 insertions(+), 5 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index f85b802..07dd29a 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -22,7 +22,7 @@ dnl
> > dnl Process this file with autoconf to create configure.
> >
> > AC_PREREQ([2.60])
> > -AC_INIT([FixesProto], [5.0],
> > +AC_INIT([FixesProto], [6.0],
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > AM_MAINTAINER_MODE
> > diff --git a/fixesproto.txt b/fixesproto.txt
> > index 5903ac9..6f8c705 100644
> > --- a/fixesproto.txt
> > +++ b/fixesproto.txt
> > @@ -650,6 +650,100 @@ DestroyPointerBarrier
> >
> > Errors: Barrier
> >
> > +* XFIXES VERSION 6 OR BETTER ***
> > +
> > +13. Pointer Barriers Expansion
> > +
> > +This update extends pointer barriers to optionally allow the pointer
> > through
> > +when a threshold is reached. This can be useful for desktop environments
> > that
> > +wish to use a large region of the screen, such as an entire edge, to
> > provide a
> > +casual target while allowing determined movement to pass through.
> > +
> > +13.1 Types
> > +
> > + BarrierEvent: {Hit, ThresholdExceeded}
> > + BarrierEventID: CARD32
> > +
> > +13.2 Events
> > +
> > +BarrierNotify
> > +
> > + subtype:BarrierEvent
> > + window: WINDOW
> > + event-id: BarrierEventID
> > + barrier:BARRIER
> > + velocity: CARD32
> > + x, y: INT16
> > + raw-displacement: FP1616
> > + delta-t:INT16
> > + deviceid: INT16
> > +
> > +13.3 Requests
> > +
> > +SelectBarrierInput
> > +
> > + window: WINDOW
> > + event-mask: SETofBarrierEvent
> > +
> > +
> > + This request directs barrier events to the named window. Subtype
> > + indicates the trigger of the event, which is Hit when the barrier has
> > + prevented pointer movement and ThresholdExceeded when the barrier has
> > + been hit but has not prevented pointer movement due to the threshold
> > + being exceeded.
> > +
> > + Barrier is the barrier on which the event was triggered. (x,y) contain
> > + the coordinates of the pointer after restriction by any applicable
> > + barriers, and velocity is the unrestricted instantaneous velocity
> > + of the pointer, perpendicular to the barrier.
>
> how is velocity defined?
> (edit: found it below, this should be either in some common section or
> everywhere. You could just define a VELOCITY type and explain it there)
That makes sense, I'll do so.
>
> > +
> > + deviceid is the identifier of the device which caused the barrier
> > + event, raw-displacement and delta-t are the raw valuator (purpendicular
>
> I'm not sure what you raw-displacement here is, can you clarify?
>
Raw-displacement is exactly the value you'd get if you were subscribed
to XI 2 raw events and selected the valuator perpendicular to the
barrier.
It (and delta-t) are here so that a client can get a pre-acceleration
idea of the velocity and user behaviour if the client desires. This is
useful for clients to determine when they want to release the barrier.
> s/valuator/valuators
> typo: purpendicular
>
And I thought I'd spell-checked it. Oops :).
> > + to the barrier) and time-since-last-input-event for deviceid
> > + respectively.
> > +
> > + event-id is an identifier for this barrier event. A barrier event
> > + begins when the pointer is first restricted by the
[PULL 1.12] input fixes for 1.12
Particularly the timer fix and #47281 are important, both can send the server into an infinite loop. The following changes since commit ed33772a0d3ace5844e157ae78885ded000819ea: xfree86: workaround crash on close (2012-04-26 21:07:09 -0700) are available in the git repository at: git://people.freedesktop.org/~whot/xserver server-1.12-branch for you to fetch changes up to 90299556db24543bb7365e8c2897deca3aa219e7: dix: when disabling a device, release all buttons and keys (2012-05-03 11:24:44 +1000) Chase Douglas (1): TouchListenerAcceptReject: Warn and return early on bad listener index Peter Hutterer (3): os: make timers signal-safe dix: don't emulate scroll events for non-existing axes (#47281) dix: when disabling a device, release all buttons and keys dix/devices.c |2 ++ dix/getevents.c |3 +++ dix/touch.c |5 + os/WaitFor.c| 18 -- 4 files changed, 26 insertions(+), 2 deletions(-) pgpROLp8nvPcg.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
[PULL] XIQueryPointer fixes
The following changes since commit f3410b97cf9b48a47bee3d15d232f8a88e75f4ef: dix: when disabling a device, release all buttons and keys (2012-05-01 11:36:36 +1000) are available in the git repository at: git://people.freedesktop.org/~whot/xserver for-keith for you to fetch changes up to ee542b85590814ee25369babce1ad14feeb137af: Report touch emulated buttons in XIQueryPointer for XI 2.1 and earlier (2012-05-03 11:20:43 +1000) Chase Douglas (2): Report logical button state in ProcXIQueryPointer Report touch emulated buttons in XIQueryPointer for XI 2.1 and earlier Xi/xiquerypointer.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) pgp5OBdPxcu8L.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers wrote:
> ---
>
> I've got a corresponding xserver patch, but it needs updating for the
> Great Reindent of '12. Might as well get support for the protocol additions
> before fixing it up.
>
> A slightly different variant of this (it's gone through a number of iterations
> in conjunction with the Unity team) is used by the Unity shell as
> infrastructure
> for the one-launcher-per-display support, so there's evidence that it's a
> usable
> protocol.
>
> configure.ac |2 +-
> fixesproto.txt | 94
>
> xfixesproto.h | 59 +++
> xfixeswire.h | 23 +++--
> 4 files changed, 173 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index f85b802..07dd29a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -22,7 +22,7 @@ dnl
> dnl Process this file with autoconf to create configure.
>
> AC_PREREQ([2.60])
> -AC_INIT([FixesProto], [5.0],
> +AC_INIT([FixesProto], [6.0],
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> AM_INIT_AUTOMAKE([foreign dist-bzip2])
> AM_MAINTAINER_MODE
> diff --git a/fixesproto.txt b/fixesproto.txt
> index 5903ac9..6f8c705 100644
> --- a/fixesproto.txt
> +++ b/fixesproto.txt
> @@ -650,6 +650,100 @@ DestroyPointerBarrier
>
> Errors: Barrier
>
> +* XFIXES VERSION 6 OR BETTER ***
> +
> +13. Pointer Barriers Expansion
> +
> +This update extends pointer barriers to optionally allow the pointer through
> +when a threshold is reached. This can be useful for desktop environments
> that
> +wish to use a large region of the screen, such as an entire edge, to provide
> a
> +casual target while allowing determined movement to pass through.
> +
> +13.1 Types
> +
> + BarrierEvent: {Hit, ThresholdExceeded}
> + BarrierEventID: CARD32
> +
> +13.2 Events
> +
> +BarrierNotify
> +
> + subtype:BarrierEvent
> + window: WINDOW
> + event-id: BarrierEventID
> + barrier:BARRIER
> + velocity: CARD32
> + x, y: INT16
> + raw-displacement: FP1616
> + delta-t:INT16
> + deviceid: INT16
> +
> +13.3 Requests
> +
> +SelectBarrierInput
> +
> + window: WINDOW
> + event-mask: SETofBarrierEvent
> +
> +
> + This request directs barrier events to the named window. Subtype
> + indicates the trigger of the event, which is Hit when the barrier has
> + prevented pointer movement and ThresholdExceeded when the barrier has
> + been hit but has not prevented pointer movement due to the threshold
> + being exceeded.
> +
> + Barrier is the barrier on which the event was triggered. (x,y) contain
> + the coordinates of the pointer after restriction by any applicable
> + barriers, and velocity is the unrestricted instantaneous velocity
> + of the pointer, perpendicular to the barrier.
> +
> + deviceid is the identifier of the device which caused the barrier
> + event, raw-displacement and delta-t are the raw valuator (purpendicular
> + to the barrier) and time-since-last-input-event for deviceid
> + respectively.
> +
> + event-id is an identifier for this barrier event. A barrier event
> + begins when the pointer is first restricted by the barrier, and ends
> + with the first mouse event that is not restricted by the barrier.
> +
> + In the case of multiple overlapping barriers an event is sent for each.
are events triggered on barriers without velocity?
> +
> +CreatePointerBarrierVelocity
> +
> + barrier:BARRIER
> + drawable: DRAWABLE
> + x1, y2, x2, y2: INT16
> + directions: CARD32
> + velocity: CARD32
> + devices:LISTofDEVICEID
> +
> + Creates a pointer barrier along the line specified by the given
> + coordinates on the screen associated with the given drawable. This
> + has identical semantics to CreatePointerBarrier, except that the
> + barrier created will not block the pointer if the threshold
> + velocity is exceeded. The velocity is measured in px/sec perpendicular
> + to the barrier.
> +
> + Once the pointer has been stopped by the barrier it will remain blocked
> + for the duration of the barrier event.
> +
> + Errors: IDChoice, Window, Value, Device
> +
> +BarrierReleasePointer
> +
> + barrier:BARRIER
> + event-id: BarrierEventID
> +
> + Temporarily allow the pointer to pass through
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers wrote:
> ---
>
> I've got a corresponding xserver patch, but it needs updating for the
> Great Reindent of '12. Might as well get support for the protocol additions
> before fixing it up.
>
> A slightly different variant of this (it's gone through a number of iterations
> in conjunction with the Unity team) is used by the Unity shell as
> infrastructure
> for the one-launcher-per-display support, so there's evidence that it's a
> usable
> protocol.
looks good, a few minor clarifications are needed below. The main change I'd
like to see is a change to use generic events instead of a standard event.
we've hit the maximum event number in the past, adding another non-generic
event can cause us to stretch over the limit.
http://lists.x.org/archives/xorg-devel/2010-March/006716.html
> configure.ac |2 +-
> fixesproto.txt | 94
>
> xfixesproto.h | 59 +++
> xfixeswire.h | 23 +++--
> 4 files changed, 173 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index f85b802..07dd29a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -22,7 +22,7 @@ dnl
> dnl Process this file with autoconf to create configure.
>
> AC_PREREQ([2.60])
> -AC_INIT([FixesProto], [5.0],
> +AC_INIT([FixesProto], [6.0],
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> AM_INIT_AUTOMAKE([foreign dist-bzip2])
> AM_MAINTAINER_MODE
> diff --git a/fixesproto.txt b/fixesproto.txt
> index 5903ac9..6f8c705 100644
> --- a/fixesproto.txt
> +++ b/fixesproto.txt
> @@ -650,6 +650,100 @@ DestroyPointerBarrier
>
> Errors: Barrier
>
> +* XFIXES VERSION 6 OR BETTER ***
> +
> +13. Pointer Barriers Expansion
> +
> +This update extends pointer barriers to optionally allow the pointer through
> +when a threshold is reached. This can be useful for desktop environments
> that
> +wish to use a large region of the screen, such as an entire edge, to provide
> a
> +casual target while allowing determined movement to pass through.
> +
> +13.1 Types
> +
> + BarrierEvent: {Hit, ThresholdExceeded}
> + BarrierEventID: CARD32
> +
> +13.2 Events
> +
> +BarrierNotify
> +
> + subtype:BarrierEvent
> + window: WINDOW
> + event-id: BarrierEventID
> + barrier:BARRIER
> + velocity: CARD32
> + x, y: INT16
> + raw-displacement: FP1616
> + delta-t:INT16
> + deviceid: INT16
> +
> +13.3 Requests
> +
> +SelectBarrierInput
> +
> + window: WINDOW
> + event-mask: SETofBarrierEvent
> +
> +
> + This request directs barrier events to the named window. Subtype
> + indicates the trigger of the event, which is Hit when the barrier has
> + prevented pointer movement and ThresholdExceeded when the barrier has
> + been hit but has not prevented pointer movement due to the threshold
> + being exceeded.
> +
> + Barrier is the barrier on which the event was triggered. (x,y) contain
> + the coordinates of the pointer after restriction by any applicable
> + barriers, and velocity is the unrestricted instantaneous velocity
> + of the pointer, perpendicular to the barrier.
how is velocity defined?
(edit: found it below, this should be either in some common section or
everywhere. You could just define a VELOCITY type and explain it there)
> +
> + deviceid is the identifier of the device which caused the barrier
> + event, raw-displacement and delta-t are the raw valuator (purpendicular
I'm not sure what you raw-displacement here is, can you clarify?
s/valuator/valuators
typo: purpendicular
> + to the barrier) and time-since-last-input-event for deviceid
> + respectively.
> +
> + event-id is an identifier for this barrier event. A barrier event
> + begins when the pointer is first restricted by the barrier, and ends
> + with the first mouse event that is not restricted by the barrier.
event-id is unique per-device? per-server? per-something?
I assume the second, given that device id isn't required to release the
pointer, might be worth pointing out.
> +
> + In the case of multiple overlapping barriers an event is sent for each.
> +
> +CreatePointerBarrierVelocity
> +
> + barrier:BARRIER
> + drawable: DRAWABLE
> + x1, y2, x2, y2: INT16
> + directions: CARD32
> + velocity: CARD32
> + devices:LISTofDEVICEID
> +
> + Creates a pointer barrier along th
Re: [PATCH] dri2proto: Fix documented opcodes
On Wed, May 2, 2012 at 3:03 PM, Chad Versace wrote: > Fix the documented opcodes in dri2proto.txt to be consistent with the > actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It > looks like the opcodes were incorrect due to copy-paste errors). Looks correct to me. Kristian > CC: Kristian Høgsberg > Signed-off-by: Chad Versace > --- > dri2proto.txt | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/dri2proto.txt b/dri2proto.txt > index df763c7..7bde067 100644 > --- a/dri2proto.txt > +++ b/dri2proto.txt > @@ -658,7 +658,7 @@ A.2 Protocol Requests > ┌─── > DRI2GetBuffers > 1 CARD8 major opcode > - 1 3 DRI2 opcode > + 1 5 DRI2 opcode > 2 3 length > 4 DRAWABLE drawable > 4 n number of attachments > @@ -678,7 +678,7 @@ A.2 Protocol Requests > ┌─── > DRI2CopyRegion > 1 CARD8 major opcode > - 1 4 DRI2 opcode > + 1 6 DRI2 opcode > 2 3 length > 4 DRAWABLE drawable > 4 REGION region > @@ -695,7 +695,7 @@ A.2 Protocol Requests > ┌─── > DRI2GetBuffersWithFormat > 1 CARD8 major opcode > - 1 3 DRI2 opcode > + 1 7 DRI2 opcode > 2 3 length > 4 DRAWABLE drawable > 4 n number of attachments > @@ -715,7 +715,7 @@ A.2 Protocol Requests > ┌─── > DRI2SwapBuffers > 1 CARD8 major opcode > - 1 7 DRI2 opcode > + 1 8 DRI2 opcode > 2 8 length > 4 DRAWABLE drawable > ▶ > @@ -736,7 +736,7 @@ A.2 Protocol Requests > ┌─── > DRI2SwapBuffers > 1 CARD8 major opcode > - 1 7 DRI2 opcode > + 1 8 DRI2 opcode > 2 8 length > 4 DRAWABLE drawable > 4 CARD32 target_msc_hi > @@ -758,7 +758,7 @@ A.2 Protocol Requests > ┌─── > DRI2GetMSC > 1 CARD8 major opcode > - 1 7 DRI2 opcode > + 1 9 DRI2 opcode > 2 8 length > 4 DRAWABLE drawable > ▶ > @@ -777,7 +777,7 @@ A.2 Protocol Requests > ┌─── > DRI2WaitMSC > 1 CARD8 major opcode > - 1 7 DRI2 opcode > + 1 10 DRI2 opcode > 2 8 length > 4 DRAWABLE drawable > 4 CARD32 target_msc_hi > @@ -802,7 +802,7 @@ A.2 Protocol Requests > ┌─── > DRI2WaitSBC > 1 CARD8 major opcode > - 1 7 DRI2 opcode > + 1 11 DRI2 opcode > 2 8 length > 4 DRAWABLE drawable > 4 CARD32 swap_hi > @@ -823,7 +823,7 @@ A.2 Protocol Requests > ┌─── > DRI2SwapInterval > 1 CARD8 major opcode > - 1 7 DRI2 opcode > + 1 12 DRI2 opcode > 2 8 length > 4 DRAWABLE drawable > 4 CARD32 interval > -- > 1.7.10 > ___ 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] dri2proto: Fix documented opcodes
Fix the documented opcodes in dri2proto.txt to be consistent with the actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It looks like the opcodes were incorrect due to copy-paste errors). CC: Kristian Høgsberg --- dri2proto.txt | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/dri2proto.txt b/dri2proto.txt index df763c7..7bde067 100644 --- a/dri2proto.txt +++ b/dri2proto.txt @@ -658,7 +658,7 @@ A.2 Protocol Requests ┌─── DRI2GetBuffers 1 CARD8 major opcode - 1 3 DRI2 opcode + 1 5 DRI2 opcode 2 3 length 4 DRAWABLEdrawable 4 n number of attachments @@ -678,7 +678,7 @@ A.2 Protocol Requests ┌─── DRI2CopyRegion 1 CARD8 major opcode - 1 4 DRI2 opcode + 1 6 DRI2 opcode 2 3 length 4 DRAWABLEdrawable 4 REGION region @@ -695,7 +695,7 @@ A.2 Protocol Requests ┌─── DRI2GetBuffersWithFormat 1 CARD8 major opcode - 1 3 DRI2 opcode + 1 7 DRI2 opcode 2 3 length 4 DRAWABLEdrawable 4 n number of attachments @@ -715,7 +715,7 @@ A.2 Protocol Requests ┌─── DRI2SwapBuffers 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 8 DRI2 opcode 2 8 length 4 DRAWABLEdrawable ▶ @@ -736,7 +736,7 @@ A.2 Protocol Requests ┌─── DRI2SwapBuffers 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 8 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 target_msc_hi @@ -758,7 +758,7 @@ A.2 Protocol Requests ┌─── DRI2GetMSC 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 9 DRI2 opcode 2 8 length 4 DRAWABLEdrawable ▶ @@ -777,7 +777,7 @@ A.2 Protocol Requests ┌─── DRI2WaitMSC 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 10 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 target_msc_hi @@ -802,7 +802,7 @@ A.2 Protocol Requests ┌─── DRI2WaitSBC 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 11 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 swap_hi @@ -823,7 +823,7 @@ A.2 Protocol Requests ┌─── DRI2SwapInterval 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 12 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 interval -- 1.7.10 ___ 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 synaptics] Fix coasting for negative scroll directions
On 05/01/2012 05:21 PM, Peter Hutterer wrote:
> 1874094f0e99d8db319f6cf769ce5a25c9bc490c introduced negative scroll
> directions. Coasting assumed always-positive increments and triggered an
> endless scrolling loop.
>
> Reported-by: Matthias Clasen
> Signed-off-by: Peter Hutterer
> ---
> src/synaptics.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/synaptics.c b/src/synaptics.c
> index 6dc8004..77eb5be 100644
> --- a/src/synaptics.c
> +++ b/src/synaptics.c
> @@ -2625,7 +2625,8 @@ HandleScrolling(SynapticsPrivate *priv, struct
> SynapticsHwState *hw,
>
> if (priv->scroll.coast_speed_y) {
> double dtime = (hw->millis - priv->scroll.last_millis) / 1000.0;
> - double ddy = para->coasting_friction * dtime * para->scroll_dist_vert;
> + double ddy = para->coasting_friction * dtime *
> abs(para->scroll_dist_vert);
> +
> priv->scroll.delta_y += priv->scroll.coast_speed_y * dtime;
> delay = MIN(delay, POLL_MS);
> if (abs(priv->scroll.coast_speed_y) < ddy) {
> @@ -2638,7 +2639,7 @@ HandleScrolling(SynapticsPrivate *priv, struct
> SynapticsHwState *hw,
>
> if (priv->scroll.coast_speed_x) {
> double dtime = (hw->millis - priv->scroll.last_millis) / 1000.0;
> - double ddx = para->coasting_friction * dtime * para->scroll_dist_horiz;
> + double ddx = para->coasting_friction * dtime *
> abs(para->scroll_dist_horiz);
> priv->scroll.delta_x += priv->scroll.coast_speed_x * dtime;
> delay = MIN(delay, POLL_MS);
> if (abs(priv->scroll.coast_speed_x) < ddx) {
Yes, this looks correct now.
Reviewed-by: Chase Douglas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Configure fixes for Windows MinGW target
On Wed, 02 May 2012 13:37:06 +0100, Jon TURNEY wrote: > Thanks very much for spotting that. No problem; just keeping my machine running. > Jon TURNEY (1): > configure.ac: Make default configuration for MinGW disable unsupported > extensions and DDXs > > Ryan Pavlik (3): > configure.ac: auto-disable MITSHM if we lack IPC > configure.ac: MinGW doesn't have setuid binaries either. > configure.ac: on MinGW, link with ws2_32 instead of winsock2 Merged. f3410b9..1908272 master -> master -- keith.pack...@intel.com pgpdXOu5MRZWn.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Configure fixes for Windows MinGW target
On 02/05/2012 02:50, Keith Packard wrote: > On Tue, 01 May 2012 20:23:38 +0100, Jon TURNEY > wrote: > >> Ryan Pavlik (3): >> configure.ac: auto-disable MITSHM if we lack IPC > > This patch is broken, HAVE_SYSV_IPC is a config.h entry, not a > configure.ac variable. This seems to fix it for me: > > diff --git a/configure.ac b/configure.ac > index d6771ef..6a41ea8 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1003,7 +1003,7 @@ if test "x$COMPOSITE" = xyes; then > fi > > if test "x$MITSHM" = xauto; then > - MITSHM="$HAVE_SYSV_IPC" > + MITSHM="$ac_cv_sysv_ipc" > fi > AM_CONDITIONAL(MITSHM, [test "x$MITSHM" = xyes]) > if test "x$MITSHM" = xyes; then > Thanks very much for spotting that. I have amended that patch as suggested and re-pushed my branch. The following changes since commit f3410b97cf9b48a47bee3d15d232f8a88e75f4ef: dix: when disabling a device, release all buttons and keys (2012-05-01 11:36:36 +1000) are available in the git repository at: git://people.freedesktop.org/~jturney/xserver master for you to fetch changes up to 19082726cb2c69f53e9720904521e3c98f788bff: configure.ac: on MinGW, link with ws2_32 instead of winsock2 (2012-05-02 12:40:33 +0100) Jon TURNEY (1): configure.ac: Make default configuration for MinGW disable unsupported extensions and DDXs Ryan Pavlik (3): configure.ac: auto-disable MITSHM if we lack IPC configure.ac: MinGW doesn't have setuid binaries either. configure.ac: on MinGW, link with ws2_32 instead of winsock2 configure.ac | 15 +++ 1 files changed, 11 insertions(+), 4 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
Re: [PATCH] os: Add CryptoAPI as a choice of SHA1 implementation
Reviewed-by: Colin Harrison Tested-by: Colin Harrison This patch works well for me. However the line.. #define WIN32_LEAN_AND_MEAN in os/xsha1.c is superfluous as the code should be built with that defined elsewhere. Thanks, Colin Harrison ___ 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
