Peter Hutterer | 1 Mar 02:51 2010
Picon

Re: [PATCH] dix: Use DeliverGrabbedEvent for implicit passive grabs (#25400)

On Wed, Feb 24, 2010 at 08:04:57PM -0800, Keith Packard wrote:
> On Thu, 25 Feb 2010 12:49:21 +1000, Peter Hutterer
<peter.hutterer@...> wrote:
> 
> > Bonus point - CheckPassiveGrabsOnWindows suddenly becomes a lot lesss
> > complicated.
> 
> Yeah, and makes it far more obvious that it's following the spec.
> 
> > Keith, I'll leave that in your court, please apply to master as you see fit,
> > I won't include it in my pull requests to avoid duplication.
> 
> This looks pretty good; I'll review it with the protocol spec, but I'd
> like to also know if you happen to have run the test suite over the new
> code?

no, not yet. I'm still battling with the test suite on my virtual machines
and on an older box.

once I have a suitable installation, I'll likely post the xtest logs but at
this point I cannot offer this yet.

Cheers,
  Peter
Zhang, Xing Z | 1 Mar 03:08 2010
Picon

RE: Where to get timestamp for selection?

Thanks Jamey and Yann Droneaud

> 
> I think xorg <at> lists.x.org is the preferred place for this kind of
> question, but that's OK.
[Wing]  I will move to xorg <at> lists.x.org next time :)

> 
> On Fri, Feb 26, 2010 at 12:45 AM, Zhang, Xing Z <xing.z.zhang <at> intel.com>
> wrote:
> > From Xlib manual, Chapter 10.4 “Event Processing Overview”, event mask
> > for SelectionRequest is “N.A” as well as other selection events. If I
> > want to listen a SelectionRequest event by XWindowEvent, what value I
> > should specify in parameter event_mask? NoEventMask?
> 
> As far as I can tell from reading WinEvent.c and evtomask.c in
> libX11/src/, you can't get selection events with XWindowEvent.
> 
> I've been on a quiet crusade to convince people to quit writing X
> clients that process events out-of-order anyway. :-) XNextEvent and
> XPending are OK, but I believe the other event functions should never
> have been in Xlib.

[Wing] It is clear now. This also makes me understand why WM (e.g
MatchBox) uses XNextEvent to process events.

> 
> And naturally I think you should be using XCB rather than Xlib for new
> code, which would mean you'd have to look at events in-order. :-)
[Wing] Thank you for pointing out this. I didn't know there is a replacement of Xlib
(Continue reading)

Oliver McFadden | 1 Mar 08:42 2010
Picon

One missing patch from Rami's ARM backtrace series.

Hi,

I'm sending this on behalf of Rami as it doesn't seem to have been included into
the tree with the other ARM backtrace patches. It's related to the already
included commits:

5b9a52be7e975e59e0bbc6b43539ecaff96b2ecd
ca364ca82a760d8e5347a6f9f79636c9a5e4e03f
(etc)

Perhaps it was never sent, or was lost in someones inbox...

[PATCH] os: Prevent backtrace from being stopped in noreturn functions.

Regards,
-- Oliver.
Oliver McFadden | 1 Mar 08:42 2010
Picon

[PATCH] os: Prevent backtrace from being stopped in noreturn functions.

From: Ylimaki Rami (EXT-Vincit/Tampere) <ext-rami.ylimaki@...>

There are two noreturn functions in the X server: FatalError and
AbortServer. Having any of those two functions in the middle of a call
stack will prevent unwinding the program properly and stops the
backtrace at those functions in gdb.

The file containing FatalError and AbortServer, os/log.c, has to be
compiled with the -mapcs-frame option on ARM to get proper
backtraces. Automake imposes its own restrictions on compiling
individual source files with different options. The recommended way to
do this is to put os/log.c into a convenience library and add this
library inside os/libos.la. See the documentation of GNU Automake
manual, version 1.11.1, section 27.8 Per-Object Flags Emulation, for
details.

Signed-off-by: Rami Ylimaki <ext-rami.ylimaki@...>
---
 configure.ac   |    3 +++
 os/Makefile.am |   15 +++++++++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index b9c7574..acedf74 100644
--- a/configure.ac
+++ b/configure.ac
 <at>  <at>  -315,6 +315,9  <at>  <at>  AC_CHECK_HEADER([execinfo.h],[
     ])]
 )

(Continue reading)

Cyril Brulebois | 1 Mar 02:11 2010
Picon

[PATCH] Fix null pointer dereference in xf86_reload_cursors().

Upon resume, X may try to dereference a null pointer, which has been
reported in Debian bug #507916 (http://bugs.debian.org/507916).

Jim Paris came up with a patch which solves the problem for him. Here's
a (hopefully) fixed version of his patch (without the typo).

Cc: Jim Paris <jim@...>
Signed-off-by: Cyril Brulebois <kibi@...>
---
 hw/xfree86/modes/xf86Cursors.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index 385848b..d6e747f 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
 <at>  <at>  -611,7 +611,7  <at>  <at>  xf86_reload_cursors (ScreenPtr screen)
     cursor_screen_priv = dixLookupPrivate(&screen->devPrivates,
 					  xf86CursorScreenKey);
     /* return if HW cursor is inactive, to avoid displaying two cursors */
-    if (!cursor_screen_priv->isUp)
+    if (!cursor_screen_priv || !cursor_screen_priv->isUp)
 	return;

     scrn = xf86Screens[screen->myNum];
--

-- 
1.7.0
Daniel Stone | 1 Mar 09:20 2010

Re: [PATCH] os: Prevent backtrace from being stopped in noreturn functions.

On Mon, Mar 01, 2010 at 09:42:58AM +0200, Oliver McFadden wrote:
> There are two noreturn functions in the X server: FatalError and
> AbortServer. Having any of those two functions in the middle of a call
> stack will prevent unwinding the program properly and stops the
> backtrace at those functions in gdb.
> 
> The file containing FatalError and AbortServer, os/log.c, has to be
> compiled with the -mapcs-frame option on ARM to get proper
> backtraces. Automake imposes its own restrictions on compiling
> individual source files with different options. The recommended way to
> do this is to put os/log.c into a convenience library and add this
> library inside os/libos.la. See the documentation of GNU Automake
> manual, version 1.11.1, section 27.8 Per-Object Flags Emulation, for
> details.

Hi,
This needs a test for GCC at the least; might be easiest to just compile
a trivial int main(...) { return 0; } with -mapcs-frame, and if
compilation succeeds, then use it.

Cheers,
Daniel
Bradley T. Hughes | 1 Mar 11:50 2010
Picon

Re: multitouch

On 02/27/2010 02:25 PM, ext Matthew Ayres wrote:
>>> This basically hits the nail right on the head. How do we know the
>>> context of the touch points in the absence of essential information?
>>
>> We can't. not within the X server. hence the need to find a solution that is
>> generic enough that it can forward data to context-aware clients but
>> specific enough that you can have more than one such client running at any
>> time.
>
> The impression I get from reading through this thread is that the
> simplest (and therefore possibly best) approach to grouping touch
> events is to group them according to which X window they intersect.
> That is, where a second touch event takes place in the same window as
> the first, it is part of the same master device; where it takes place
> elsewhere, it is another master device.  I'm not sure why this would
> not be a useful assumption.

I like this idea (and this is similar what I did in Qt when trying to 
determine context for a touch-point), the only concern is that Peter and 
others have comment on how expensive it is to add/remove master devices.

>>> But this kind of operation is really application dependent, isn't
>>> it? I mean, the application would have to decide what the user is
>>> trying to do based on the starting/current/final location of the
>>> touch points...
>>
>> correct. and that is one of the reasons why I want any context-specific
>> information processing (i.e. gestures) in the client. the server cannot have
>> enough information to even get started.
>
(Continue reading)

Guillem Jover | 1 Mar 11:53 2010

Re: [PATCH] os: Prevent backtrace from being stopped in noreturn functions.

Hi!

On Mon, 2010-03-01 at 09:42:58 +0200, Oliver McFadden wrote:
> From: Ylimaki Rami (EXT-Vincit/Tampere) <ext-rami.ylimaki@...>
> diff --git a/configure.ac b/configure.ac
> index b9c7574..acedf74 100644
> --- a/configure.ac
> +++ b/configure.ac
>  <at>  <at>  -315,6 +315,9  <at>  <at>  AC_CHECK_HEADER([execinfo.h],[
>      ])]
>  )
>  
> +dnl arm needs additional compiler flags for proper backtraces
> +AM_CONDITIONAL(ARM_BACKTRACE, [test "x$build_cpu" = xarm])

I think you mean host_cpu here.

regards,
guillem
Oliver McFadden | 1 Mar 12:09 2010
Picon

Re: [PATCH] os: Prevent backtrace from being stopped in noreturn functions.

On Mon, 2010-03-01 at 11:53 +0100, ext Guillem Jover wrote:
> Hi!
> 
> On Mon, 2010-03-01 at 09:42:58 +0200, Oliver McFadden wrote:
> > From: Ylimaki Rami (EXT-Vincit/Tampere) <ext-rami.ylimaki@...>
> > diff --git a/configure.ac b/configure.ac
> > index b9c7574..acedf74 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> >  <at>  <at>  -315,6 +315,9  <at>  <at>  AC_CHECK_HEADER([execinfo.h],[
> >      ])]
> >  )
> >  
> > +dnl arm needs additional compiler flags for proper backtraces
> > +AM_CONDITIONAL(ARM_BACKTRACE, [test "x$build_cpu" = xarm])
> 
> I think you mean host_cpu here.

Oh, yes. I actually didn't write this patch and just sent it for review.
There are a couple of issues that either myself or Rami will fix. I'll
try to look at it later today.

Probably this went unnoticed due to building in scratchbox.
Daniel Stone | 1 Mar 12:22 2010

Re: multitouch

Hi,

On Mon, Mar 01, 2010 at 11:50:49AM +0100, Bradley T. Hughes wrote:
> On 02/27/2010 02:25 PM, ext Matthew Ayres wrote:
>> The impression I get from reading through this thread is that the
>> simplest (and therefore possibly best) approach to grouping touch
>> events is to group them according to which X window they intersect.
>> That is, where a second touch event takes place in the same window as
>> the first, it is part of the same master device; where it takes place
>> elsewhere, it is another master device.  I'm not sure why this would
>> not be a useful assumption.
>
> I like this idea (and this is similar what I did in Qt when trying to  
> determine context for a touch-point), the only concern is that Peter and  
> others have comment on how expensive it is to add/remove master devices.

Not to mention the deeply unpleasant races -- unless you grab
XGrabServer, which is prohibitively expensive and extremely anti-social.

If you really need multiple devices, how hard is it to group events
together when they come from separate devices? I'm guessing it can't be
that hard: you'd be tracking _less state_, and it'd be _more
predictable_.  How a hybrid system is easier for anyone is honestly
beyond me, but hey.

I still think a multi-level device hierachy would be helpful, thus
giving us 'subdevice'-alike behaviour.  So if we were able to go:
MD 1 ->
        Touchpad 1 ->
                      Finger 1
(Continue reading)


Gmane