Re: [RFC] Multitouch support, step one

2010-03-16 Thread Peter Hutterer 
On Tue, Mar 16, 2010 at 02:42:15PM +0100, Henrik Rydberg wrote:
> Peter Hutterer wrote:
> > On Mon, Mar 15, 2010 at 03:41:24PM +0100, Henrik Rydberg wrote:
> >>> Preamble:
> >>> Multi-touch as defined in this proposal is limited to single input-point
> >>> multi-touch. This is suitable for indirect touch devices (e.g. touchpads)
> >>> and partially suited for direct touch devices provided a touch is 
> >>> equivalent
> >>> to a single-gesture single-application input.
> >> User-space applications need tools to *use* MT devices, not route raw data 
> >> from
> >> the devices to the application. The latter is not much more complicated 
> >> than
> >> opening a file, and everyone can do that already. Thus, unless there is a 
> >> model
> >> for how MT devices work and interact with other MT devices, I see little 
> >> point
> >> in having an X protocol at all.
> > 
> > The main reason is that applications, for better or worse, use X as their
> > input source. Our job is to get the data to the right client, without too
> > much processing going on. For clients to go around the server by opening the
> > kernel device files directly will cause issues in the long run, especially
> > when you have multiple applications running.
> 
> Thank you for addressing my concerns. The details you describe below form a
> logical and complete proposal, which is agreeable in its own right.
> 
> However, I must insist on continuing this discussion, because my gut
> tells me we are moving slightly in the wrong direction. Here are the main 
> reasons:
> 
> 1. User space wants details, but also consistent behavior for all devices
> supporting multitouch.
> 
> 2. The kernel interface is bandwidth-consuming by necessity, but there is no
> need for the X protocol to be.
> 
> 3. Support for multitouch in X does exist already, so there is no need to 
> start
> from zero when discussing it (http://bitmath.org/code/multitouch/).
> 
> 4. The hard limit of 256 guarantees something new will have to be done for
> multi-user multitouch, in essence pushing the problem forward.
> 
> 5. Squeezing MT into the valuator concept is generally crippling, since it 
> does
> not map very well to the underlying contact concept.
> 
> What follows is a longer version of these five points, and below that is a
> proposal for how I believe it should be done.
> 
> ---
> 
> 1. Consistent behavior for all devices
> 
> The hardware stack supporting multitouch is diverse, and several different
> mechanisms and abstraction levels exists. The tracking ID is a good example. 
> It
> may or may not be present in the driver output, and it may work poorly even if
> it exists. Thus, in order to support hardware consistently, there must be a
> middle layer outside of the kernel, parsing the driver data and patching it up
> to produce the same level of detail for all devices. This task can be quite
> complicated and uses some cpu, so having it in one place is imperative. 
> Luckily,
> there exists such a solution in the multitouch X driver (see link above). This
> code can either be broken out as a standalone module or be placed in the X 
> core.
> If there is a license issue, it can be resolved for the benefit of the X
> community. In the text below, this piece of code will be referred to as the
> contact driver.

I think this is where we mostly agree, maybe not it wording but in spirit.
I want the data to come out of the protocol in a generic fashion, or at
least generalised up to a point that clients can work with it. 
IMO dealing with touchpoint (or "contact") width and height can be left to
the clients. what the driver should however do is assign tracking IDs. I
don't think this approach would be useful without being able to track
touchpoints.

 
> 2. Bandwidth reduction should be made as early as possible
> 
> The MT events from the kernel are non-filtered, bypassing the normal input
> filtering by necessity. Duplicating this behavior further into the food chain
> would be a mistake. After parsing the MT stream in the contact driver, the 
> event
> stream can be filtered substantially, thereby restoring bandwidth usage to
> something more similar to non-mt devices.

I don't understand what you mean by filtering here. Can you detail this?

> 3. The contact driver produces the more digested contact events
> 
> The contact driver takes the flora of driver MT events and produces a 
> consistent
> stream of contact events. The contact event stream is less 
> bandwidth-consuming,
> and follows the init-move-destroy concept we discussed last summer, if you
> recall. We are still talking about a low-level stream, there are no gesture or
> other high-level derivatives. Just a consistent stream of data.

Same as above. You've worked more with the kernel's multitouch interface
than I did. can you give us an example of what the data from the kernel
would look like and how it would be "digested"?

> 4. ABI, memory and cpu burden for nothing
> 
> Although the currently hard limit of

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Peter Hutterer 
On Wed, Mar 17, 2010 at 03:22:20AM +0200, Daniel Stone wrote:
> Hi,
> 
> On Mon, Mar 15, 2010 at 04:56:05PM +1000, Peter Hutterer wrote:
> > Core requires us to always send x/y
> 
> Er, I don't think it does _always_ require it.

It doesn't _require_ it from the driver's POV but we always fill it in for
the events. So we can either make it up in the driver, or fill it in from
cached values in the server. Even XI events always have root x/y set.

> > hence for core emulation we should
> > always include _some_ coordinates that are easily translated. While the
> > server does caching of absolute values, I think it would be worthwile to
> > always have an x/y coordinate _independent of the touchpoints_ in the event.
> > The driver can decide which x/y coordinates are chosen if the first
> > touchpoint becomes invalid.
> 
> Why not just use the first touchpoint for x/y, and when it goes away, no
> more core x/y is sent? Principle of least surprise and all that.

that requires some careful handling of the core events - since some of them
will need to be emulated as button press events too. essentially we need to
ensure that the press and release events are balanced out.
 
Cheers,
  Peter

> > Hence, the example with 4 valuators above becomes a device with 6 valuators
> > instead. x/y and the two coordinate pairs as mentioned above. If extra data
> > is provided by the kernel driver, these pairs are simple extended into
> > tuples of values, appropriately labeled.
> 
> Yep.
> 
> This all looks fine, really, and doesn't require terribly much work.
> Multi-focus multi-touch is a bit further off, but hey, none of us can
> even particularly describe how it should work, so I don't think it's
> such a pressing issue. :)

___
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] dix: if owner-events is true for passive grabs, add the window mask (#25400)

2010-03-16 Thread Peter Hutterer 
A client requesting a GrabModeSync button grab, owner-events true, with only
the ButtonRelease mask set would never receive the press event even if the
grab window had the ButtonPress mask set.

The protocol requires that if owner-events is true, then the delivery mask
is the combination of the grab mask + the window event mask.

X.Org Bug 25400 

Signed-off-by: Peter Hutterer 
Tested-by: Jim Ramsay 
---
Keith,

I know this isn't the patch you wanted, but the testing results are
significantly less abysimal than the nicer DeliverGrabbedEvents patch. So
far, it seems to work for all but CDE (see bugreport).

So I'd rather have a fix that works for most clients than the current
situation (and we've been carring this fix in Fedora for a while now too).

Cheers,
  Peter

 dix/events.c |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index c085a75..c0f35ec 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -3579,6 +3579,8 @@ CheckPassiveGrabsOnWindow(
 xE = &core;
 count = 1;
 mask = grab->eventMask;
+if (grab->ownerEvents)
+mask |= pWin->eventMask;
 } else if (match & XI2_MATCH)
 {
 rc = EventToXI2((InternalEvent*)event, &xE);
@@ -3600,6 +3602,24 @@ CheckPassiveGrabsOnWindow(
 mask = 
grab->xi2mask[device->id][((xGenericEvent*)xE)->evtype/8];
 else if (event->type == XI_Enter || event->type == XI_FocusIn)
 mask = grab->xi2mask[device->id][event->type/8];
+
+if (grab->ownerEvents && wOtherInputMasks(grab->window))
+{
+InputClientsPtr icp =
+wOtherInputMasks(grab->window)->inputClients;
+
+while(icp)
+{
+if (rClient(icp) == rClient(grab))
+{
+int evtype = (xE) ? ((xGenericEvent*)xE)->evtype : 
event->type;
+mask |= icp->xi2mask[device->id][evtype/8];
+break;
+}
+
+icp = icp->next;
+}
+}
 } else
 {
 rc = EventToXI((InternalEvent*)event, &xE, &count);
@@ -3611,6 +3631,22 @@ CheckPassiveGrabsOnWindow(
 continue;
 }
 mask = grab->eventMask;
+if (grab->ownerEvents && wOtherInputMasks(grab->window))
+{
+InputClientsPtr icp =
+wOtherInputMasks(grab->window)->inputClients;
+
+while(icp)
+{
+if (rClient(icp) == rClient(grab))
+{
+mask |= icp->mask[device->id];
+break;
+}
+
+icp = icp->next;
+}
+}
 }
 
(*grabinfo->ActivateGrab)(device, grab, currentTime, TRUE);
-- 
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

[PATCH synaptics] After closing the fd, reset it to -1.

2010-03-16 Thread Peter Hutterer 
A DeviceOff() followed by DeviceClose() (which calls DeviceOff()) would try
to close the fd twice, in addition to calling various hooks.

Signed-off-by: Peter Hutterer 
---
 src/synaptics.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/synaptics.c b/src/synaptics.c
index ad2397f..f9db81c 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -842,6 +842,7 @@ DeviceOff(DeviceIntPtr dev)
priv->comm.buffer = NULL;
}
xf86CloseSerial(local->fd);
+   local->fd = -1;
 }
 dev->public.on = FALSE;
 return Success;
-- 
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: [RFC] Multitouch support, step one

2010-03-16 Thread The Rasterman 
On Mon, 15 Mar 2010 12:55:11 +0100 Benjamin Tissoires  said:

> >>> XI2 allows devices to change at runtime. Hence a device may add or remove
> >>> valuators on-the-fly as touchpoints appear and disappear. There is a
> >>> chance of a race condition here. If a driver decides to add/remove
> >>> valuators together with the touchpoints, a client that skips events may
> >>> miss out. e.g. if a DeviceChanged event that removes an axis is followed
> >>> by one that adds an axis, a client may only take the second one as
> >>> current, thus thinking the axis was never removed. There is nothing in
> >>> the XI2 specs that prohibits this. Anyways, adding removing axes together
> >>> with touchpoints seems superfluous if we use the presence of an axis as
> >>> indicator for touch. Rather, I think a device should be set up with a
> >>> fixed number of valuators describing the default maximum number of
> >>> touchpoints. Additional ones can be added at runtime if necessary.
> >>
> >> agreed. i really see this having a fixed # of touch points - and not
> >> changing - unless you literally unplug/plug in new hardware that has
> >> different features (has more or less in the way of touch point support).
> 
> We can have a fixed number of touch point but send only the required 
> ones. So agreed too. The point is: how many touch point do we have. The 
> kernel knows how many touches a device can send as the data are not 
> serialized. But after that, we have no idea of how many touches the 
> device support.
> 
> With the mask system (or the packing of the touches at the beginning), 
> we will send only the right number of touches, but the description will 
> be very heavy. If each point has 5 axes (trackingID, x, y, width, height 
> for instance) we will have 50 valuators if we support 10 touches ;-) By 
> the way, it's not the point here.

this is what i'm concerned about. there are touch surfaces that now support 10
touches - AND they can give you not just x,y but radius (x and y) too. so 10
touch points -> 40 valuators. already blown the 36 valuator limit - and we
havent added yet more things like tracking id, separate pressure, angle etc.
properties. multiple devices with valuators for these touch params will handle
this. anyway - that's my concern for now.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.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: [RFC] Multitouch support, step one

2010-03-16 Thread The Rasterman 
On Wed, 17 Mar 2010 03:22:20 +0200 Daniel Stone  said:

> Hi,
> 
> On Mon, Mar 15, 2010 at 04:56:05PM +1000, Peter Hutterer wrote:
> > Core requires us to always send x/y
> 
> Er, I don't think it does _always_ require it.
> 
> > hence for core emulation we should
> > always include _some_ coordinates that are easily translated. While the
> > server does caching of absolute values, I think it would be worthwile to
> > always have an x/y coordinate _independent of the touchpoints_ in the event.
> > The driver can decide which x/y coordinates are chosen if the first
> > touchpoint becomes invalid.
> 
> Why not just use the first touchpoint for x/y, and when it goes away, no
> more core x/y is sent? Principle of least surprise and all that.

that's what i'd expect. first touchpoint == core emulation. even if apps are
listening to both core and xi2 - they will "expect" core emulation and can
either choose to ignore core events OR ignore first touch point and let core
events work for that (this is the least surprising for toolkits and apps as
they all already handle core events etc.)

> > Hence, the example with 4 valuators above becomes a device with 6 valuators
> > instead. x/y and the two coordinate pairs as mentioned above. If extra data
> > is provided by the kernel driver, these pairs are simple extended into
> > tuples of values, appropriately labeled.
> 
> Yep.
> 
> This all looks fine, really, and doesn't require terribly much work.
> Multi-focus multi-touch is a bit further off, but hey, none of us can
> even particularly describe how it should work, so I don't think it's
> such a pressing issue. :)

agreed. right now we have a definite use case and requirement for mt for "1
client". first touch sets window grab for all mt input and that window gets
delivered the xi2 events for all the mt input - regardless where extra touches
happen. that works for me at any rate. i'm happy with that.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.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: [RFC] Multitouch support, step one

2010-03-16 Thread Daniel Stone 
Hi,

On Mon, Mar 15, 2010 at 03:41:24PM +0100, Henrik Rydberg wrote:
> > Multi-touch as defined in this proposal is limited to single input-point
> > multi-touch. This is suitable for indirect touch devices (e.g. touchpads)
> > and partially suited for direct touch devices provided a touch is equivalent
> > to a single-gesture single-application input.
> 
> User-space applications need tools to *use* MT devices, not route raw data 
> from
> the devices to the application. The latter is not much more complicated than
> opening a file, and everyone can do that already. Thus, unless there is a 
> model
> for how MT devices work and interact with other MT devices, I see little point
> in having an X protocol at all.

This is true, but we actually want to punt responsibility to the clients
here; some kind of common gesture-recognition library would be nice to
avoid duplicate work.

> The number of dimensions also increases dramatically, as pointed out by Mr.
> Poole. It makes much more sense to define contacts as multiple instances of 
> the
> same thing, than to define each new contact as potentially something 
> completely
> different.

Sure, but we don't have the knowledge to classify it as such.  So it
means that we'd have to send the event to the client, then have the
client make probably multiple round trips to update the grouping.  And
since the server doesn't have anything meaningful to do with the
grouping, the only benefit would be in the state the client sees.  This
would be pretty disastrous for latency.

> The idea of adding and removing contacts dynamically I believe is a good 
> idea. A
> contact has a set of attributes (x, y, etc). Why not provide a clean interface
> for the contacts as a concept, rather than mapping the not-so-independent x 
> and
> y values into separate dynamic entities? As an example of the smallest
> meaningful dynamic entity:
> 
> struct Contact {
>   int tracking_id;
>   float x, y;
>   etc etc...
> };

The x, y, etc are the valuators and you have a tracking ID, so Peter's
proposed API seems to fit this (it'd be nice if the server only
_actually_ recycled tracking numbers when all buttons/fingers were up,
or somesuch).

> > Core requires us to always send x/y, hence for core emulation we should
> > always include _some_ coordinates that are easily translated. While the
> > server does caching of absolute values, I think it would be worthwile to
> > always have an x/y coordinate _independent of the touchpoints_ in the event.
> > The driver can decide which x/y coordinates are chosen if the first
> > touchpoint becomes invalid.
> 
> Seconded, but the single-touch x/y coordinates are properties of a contact
> group, not of a single contact. Example:
> 
> struct ContactGroup {
>   int group_id;
>   float x, y;
>   ContactList list;
>   etc etc...
> };

Yep, and if the toolkit is doing the grouping internally, then the
toolkit can handle this.  As I said, this could be a common library.

> > A device exposing several axes _and_ multitouch axes will need to be
> > appropriately managed by the driver. In this case, the "right" thing to do
> > is likely to expose non-MT axes first and tack the MT axes onto the back.
> > Some mapping may need to be added.
> > 
> > The future addition of real multitouch will likely require protocol changes.
> > These changes will need to include a way of differentiating a device that
> > does true multitouch from one that does single-point multi-touch.
> > 
> > That's it, pretty much (well, not much actually). Feel free to poke holes
> > into this proposal.
> 
> Ok, in conclusion, my two cents are: Do not add MT functionality as evaluators
> in X, but implement a proper Contact interface from the start.

Valuators are the lowest common denominator interface we can implement.
If we develop something better on top that we can move into the protocol
without completely blowing input response time out of the water, then we
can look at that and deprecate the use of valuators for MT.

Cheers,
Daniel


pgp2IcpqbYS6l.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Daniel Stone 
Hi,

On Mon, Mar 15, 2010 at 04:56:05PM +1000, Peter Hutterer wrote:
> Core requires us to always send x/y

Er, I don't think it does _always_ require it.

> hence for core emulation we should
> always include _some_ coordinates that are easily translated. While the
> server does caching of absolute values, I think it would be worthwile to
> always have an x/y coordinate _independent of the touchpoints_ in the event.
> The driver can decide which x/y coordinates are chosen if the first
> touchpoint becomes invalid.

Why not just use the first touchpoint for x/y, and when it goes away, no
more core x/y is sent? Principle of least surprise and all that.

> Hence, the example with 4 valuators above becomes a device with 6 valuators
> instead. x/y and the two coordinate pairs as mentioned above. If extra data
> is provided by the kernel driver, these pairs are simple extended into
> tuples of values, appropriately labeled.

Yep.

This all looks fine, really, and doesn't require terribly much work.
Multi-focus multi-touch is a bit further off, but hey, none of us can
even particularly describe how it should work, so I don't think it's
such a pressing issue. :)

Cheers,
Daniel


pgpziqoOI5FT8.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Henrik Rydberg 
> Now *that* is a deal-breaker.

that was meant to read "ice-breaker", what a freudian slip...

Henrik

___
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] Multitouch support, step one

2010-03-16 Thread Henrik Rydberg 
Daniel Stone wrote:
> Hi,
> 
> On Tue, Mar 16, 2010 at 01:36:32PM +1000, Peter Hutterer wrote:
>> I expect so too. Right now, MAX_VALUATORS is a simple #define that can be
>> arbitrarily changed. Except that like so many defines we need to ensure that
>> actually changing it doesn't cause regression in code that expects it to be
>> exactly 36 (I just checked again, it's actually 36, not 32)
> 
> Indeed.
> 
>> The only hard limit I can think of is 256 which is what the XI1 protocol
>> limits it to.
> 
> Even then, you can just deliver the first 256 to XI1 clients and still
> deliver UINT_MAX to XI2 clients. *shrug*

Now *that* is a deal-breaker. It basically removes concern number four on my
list. So if disregarding number five as artistic taste, one could inject the
valuators from the contact driver, adressing number one, two and three on the
list, and we would be done.

How about that.

Henrik

___
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: keyboard bell woes (ignores xset)

2010-03-16 Thread Jeremy Huddleston 
Alright, well I opened https://bugs.freedesktop.org/show_bug.cgi?id=27118 for 
whoever wants to fix it...

Thanks, Peter.

On Mar 16, 2010, at 16:52, Peter Hutterer wrote:

> On Tue, Mar 16, 2010 at 04:37:31PM -0700, Jeremy Huddleston wrote:
>> I started looking into this because a user reported that XQuartz was still
>> beeping in his xterm even though he uses 'xset -b' ... it turns out that
>> xterm is using XkbBell() rather than XBell().  Even with 'xset -b', the
>> audible bell is still calling DDXRingBell() with volume = 50...
>> 
>> I made a reduced test case that does:
>> 
>> XBell(dpy, 0);// No beep with 'xset -b'
>> XkbBell(dpy, 0, 0, None); // Beep with vol=50 with 'xset -b'
>> 
>> shouldn't these be the same?
> 
> I think so. This may be some wierd interaction between core and XKB with the
> bell feedback classes though, where XKB slips through the cracks because on
> some device the base is still on the default. No idea on the details though.
> 
> Cheers,
>  Peter
> 
>> On Mar 16, 2010, at 15:30, Peter Hutterer wrote:
>> 
>>> On Tue, Mar 16, 2010 at 01:12:54PM -0700, Jeremy Huddleston wrote:
 Actually, as I read this again, I noticed that it is behaving as per the 
 spec:
 
 XBell(dpy, 100) with base = 0:
 base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100
 
 XBell(dpy, 100) with base = 100:
 base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100
 
 So... this just seems a bit deceptive... if 'xset -b' is supposed to mute
 the keyboard bell, why was XBell() designed to work around this?
>>> 
>>> I think you need to ask the question the other way round - why does 
>>> xset -b provide a functionality that XBell() can route around. I'm pretty
>>> sure XBell() was there first :)
>>> 
>>> Looks like to really disable the bell for core requests you need to call
>>> XkbSetControls() with the XkbAudibleBellMask. That way it can only be
>>> overridden by a forced XkbBell() request, not by any core requests.
>>> xset at this point doesn't do xkb but I don't se why it couldn't.
>>> 
>>> Cheers,
>>> Peter
>>> 
>>> 
 On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:
 
> I turn off the bell using 'xset -b' :
> ~ $ xset -q | grep bell
> bell percent:  0bell pitch:  400bell duration:  100
> 
> but when I do XBell(dpy, 100), the bell still rings at volume 100.
> 
> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
> arg=0x115b71100, something=0) at devices.c:498
> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', 
> name=0, pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
> 
> Shouldn't the bell percent set by 'xset' be multiplied by the volume 
> passed to XBell?  From XBell(3):
> 
> """
> The XBell function rings the bell on the keyboard on the specified 
> display, if possible.  The specified
> volume is relative to the base volume for the keyboard.  If the value 
> for the percent argument is not in
> the range -100 to 100 inclusive, a BadValue error results.  The 
> volume at which the bell rings when the
> percent argument is nonnegative is:
> 
>base - [(base * percent) / 100] + percent
> 
> The volume at which the bell rings when the percent argument is 
> negative is:
> 
>base + [(base * percent) / 100]
> """
> 
> --Jeremy
>>> 
>>> ___
>>> 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



smime.p7s
Description: S/MIME cryptographic 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:xdm] Check for allowRootLogin on PAM and non-OpenBSD passwd authentication backends

2010-03-16 Thread Alan Coopersmith 
http://bugs.freedesktop.org/show_bug.cgi?id=25112

Signed-off-by: Alan Coopersmith 
---
 config/Xresources.cpp |2 +-
 greeter/Login.c   |6 +-
 greeter/verify.c  |   12 +++-
 xdm.man.cpp   |2 ++
 4 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/config/Xresources.cpp b/config/Xresources.cpp
index 4e362df..f5866cf 100644
--- a/config/Xresources.cpp
+++ b/config/Xresources.cpp
@@ -23,7 +23,7 @@ xlogin*login.translations: #override BS
 
 xlogin*greeting: Welcome to CLIENTHOST
 xlogin*namePrompt: \040\040\040\040\040\040\040Login:
-xlogin*fail: Login incorrect
+xlogin*fail: Login incorrect or forbidden by policy
 
 XHASHif WIDTH > 800
 xlogin*greetFont: -adobe-helvetica-bold-o-normal--24-240-75-75-p-138-iso8859-1
diff --git a/greeter/Login.c b/greeter/Login.c
index 86e3d44..6ddb8df 100644
--- a/greeter/Login.c
+++ b/greeter/Login.c
@@ -197,11 +197,7 @@ static XtResource resources[] = {
offset(passwdPrompt), XtRString, "Password:  "},
 {XtNfail, XtCFail, XtRString, sizeof (char *),
offset(failMsg), XtRString,
-#if defined(sun) && defined(SVR4)
- "Login incorrect or not on system console if root"
-#else
- "Login incorrect"
-#endif
+   "Login incorrect or forbidden by policy"
 },
 {XtNchangePasswdMessage, XtCChangePasswdMessage, XtRString,
sizeof (char *), offset(passwdChangeMsg), XtRString,
diff --git a/greeter/verify.c b/greeter/verify.c
index 73493ca..6e3f14b 100644
--- a/greeter/verify.c
+++ b/greeter/verify.c
@@ -350,6 +350,16 @@ Verify (struct display *d, struct greet_info *greet, 
struct verify_info *verify)
return 0;
}
 
+   /*
+* Only accept root logins if allowRootLogin resource is not false
+*/
+   if ((p->pw_uid == 0) && !greet->allow_root_login) {
+   Debug("root logins not allowed\n");
+   if (greet->password != NULL)
+   bzero(greet->password, strlen(greet->password));
+   return 0;
+   }
+
 # if defined(sun) && defined(SVR4)
/* Solaris: If CONSOLE is set to /dev/console in /etc/default/login,
   then root can only login on system console */
@@ -467,7 +477,6 @@ Verify (struct display *d, struct greet_info *greet, struct 
verify_info *verify)
 #  ifdef KERBEROS
 done:
 #  endif
-#  ifdef __OpenBSD__
/*
 * Only accept root logins if allowRootLogin resource is set
 */
@@ -476,6 +485,7 @@ done:
bzero(greet->password, strlen(greet->password));
return 0;
}
+#  ifdef __OpenBSD__
/*
 * Shell must be in /etc/shells
 */
diff --git a/xdm.man.cpp b/xdm.man.cpp
index 6b65694..011d8d1 100644
--- a/xdm.man.cpp
+++ b/xdm.man.cpp
@@ -1045,6 +1045,8 @@ drawn in hiColor and shdColor.
 If set to ``false'', don't allow root (and any other user with uid = 0) to
 log in directly.
 The default is ``true''.
+This setting is only checked by some of the authentication backends at this
+time.
 .IP "\fBxlogin.Login.allowNullPasswd\fP"
 If set to ``true'', allow an otherwise failing password match to succeed
 if the account does not require a password at all.
-- 
1.5.6.5

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: keyboard bell woes (ignores xset)

2010-03-16 Thread Peter Hutterer 
On Tue, Mar 16, 2010 at 04:37:31PM -0700, Jeremy Huddleston wrote:
> I started looking into this because a user reported that XQuartz was still
> beeping in his xterm even though he uses 'xset -b' ... it turns out that
> xterm is using XkbBell() rather than XBell().  Even with 'xset -b', the
> audible bell is still calling DDXRingBell() with volume = 50...
> 
> I made a reduced test case that does:
> 
> XBell(dpy, 0);// No beep with 'xset -b'
> XkbBell(dpy, 0, 0, None); // Beep with vol=50 with 'xset -b'
> 
> shouldn't these be the same?

I think so. This may be some wierd interaction between core and XKB with the
bell feedback classes though, where XKB slips through the cracks because on
some device the base is still on the default. No idea on the details though.

Cheers,
  Peter

> On Mar 16, 2010, at 15:30, Peter Hutterer wrote:
> 
> > On Tue, Mar 16, 2010 at 01:12:54PM -0700, Jeremy Huddleston wrote:
> >> Actually, as I read this again, I noticed that it is behaving as per the 
> >> spec:
> >> 
> >> XBell(dpy, 100) with base = 0:
> >> base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100
> >> 
> >> XBell(dpy, 100) with base = 100:
> >> base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100
> >> 
> >> So... this just seems a bit deceptive... if 'xset -b' is supposed to mute
> >> the keyboard bell, why was XBell() designed to work around this?
> > 
> > I think you need to ask the question the other way round - why does 
> > xset -b provide a functionality that XBell() can route around. I'm pretty
> > sure XBell() was there first :)
> > 
> > Looks like to really disable the bell for core requests you need to call
> > XkbSetControls() with the XkbAudibleBellMask. That way it can only be
> > overridden by a forced XkbBell() request, not by any core requests.
> > xset at this point doesn't do xkb but I don't se why it couldn't.
> > 
> > Cheers,
> >  Peter
> > 
> > 
> >> On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:
> >> 
> >>> I turn off the bell using 'xset -b' :
> >>> ~ $ xset -q | grep bell
> >>> bell percent:  0bell pitch:  400bell duration:  100
> >>> 
> >>> but when I do XBell(dpy, 100), the bell still rings at volume 100.
> >>> 
> >>> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
> >>> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
> >>> arg=0x115b71100, something=0) at devices.c:498
> >>> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
> >>> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', 
> >>> name=0, pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
> >>> 
> >>> Shouldn't the bell percent set by 'xset' be multiplied by the volume 
> >>> passed to XBell?  From XBell(3):
> >>> 
> >>> """
> >>>  The XBell function rings the bell on the keyboard on the specified 
> >>> display, if possible.  The specified
> >>>  volume is relative to the base volume for the keyboard.  If the 
> >>> value for the percent argument is not in
> >>>  the range -100 to 100 inclusive, a BadValue error results.  The 
> >>> volume at which the bell rings when the
> >>>  percent argument is nonnegative is:
> >>> 
> >>> base - [(base * percent) / 100] + percent
> >>> 
> >>>  The volume at which the bell rings when the percent argument is 
> >>> negative is:
> >>> 
> >>> base + [(base * percent) / 100]
> >>> """
> >>> 
> >>> --Jeremy
> > 
> > ___
> > 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

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Daniel Stone 
Hi,

On Tue, Mar 16, 2010 at 01:36:32PM +1000, Peter Hutterer wrote:
> I expect so too. Right now, MAX_VALUATORS is a simple #define that can be
> arbitrarily changed. Except that like so many defines we need to ensure that
> actually changing it doesn't cause regression in code that expects it to be
> exactly 36 (I just checked again, it's actually 36, not 32)

Indeed.

> The only hard limit I can think of is 256 which is what the XI1 protocol
> limits it to.

Even then, you can just deliver the first 256 to XI1 clients and still
deliver UINT_MAX to XI2 clients. *shrug*

Cheers,
Daniel


pgpjmrLMI6eBR.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: keyboard bell woes (ignores xset)

2010-03-16 Thread Jeremy Huddleston 
I started looking into this because a user reported that XQuartz was still 
beeping in his xterm even though he uses 'xset -b' ... it turns out that xterm 
is using XkbBell() rather than XBell().  Even with 'xset -b', the audible bell 
is still calling DDXRingBell() with volume = 50...

I made a reduced test case that does:

XBell(dpy, 0);// No beep with 'xset -b'
XkbBell(dpy, 0, 0, None); // Beep with vol=50 with 'xset -b'

shouldn't these be the same?


On Mar 16, 2010, at 15:30, Peter Hutterer wrote:

> On Tue, Mar 16, 2010 at 01:12:54PM -0700, Jeremy Huddleston wrote:
>> Actually, as I read this again, I noticed that it is behaving as per the 
>> spec:
>> 
>> XBell(dpy, 100) with base = 0:
>> base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100
>> 
>> XBell(dpy, 100) with base = 100:
>> base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100
>> 
>> So... this just seems a bit deceptive... if 'xset -b' is supposed to mute
>> the keyboard bell, why was XBell() designed to work around this?
> 
> I think you need to ask the question the other way round - why does 
> xset -b provide a functionality that XBell() can route around. I'm pretty
> sure XBell() was there first :)
> 
> Looks like to really disable the bell for core requests you need to call
> XkbSetControls() with the XkbAudibleBellMask. That way it can only be
> overridden by a forced XkbBell() request, not by any core requests.
> xset at this point doesn't do xkb but I don't se why it couldn't.
> 
> Cheers,
>  Peter
> 
> 
>> On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:
>> 
>>> I turn off the bell using 'xset -b' :
>>> ~ $ xset -q | grep bell
>>> bell percent:  0bell pitch:  400bell duration:  100
>>> 
>>> but when I do XBell(dpy, 100), the bell still rings at volume 100.
>>> 
>>> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
>>> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
>>> arg=0x115b71100, something=0) at devices.c:498
>>> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
>>> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
>>> pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
>>> 
>>> Shouldn't the bell percent set by 'xset' be multiplied by the volume passed 
>>> to XBell?  From XBell(3):
>>> 
>>> """
>>>  The XBell function rings the bell on the keyboard on the specified 
>>> display, if possible.  The specified
>>>  volume is relative to the base volume for the keyboard.  If the value 
>>> for the percent argument is not in
>>>  the range -100 to 100 inclusive, a BadValue error results.  The volume 
>>> at which the bell rings when the
>>>  percent argument is nonnegative is:
>>> 
>>> base - [(base * percent) / 100] + percent
>>> 
>>>  The volume at which the bell rings when the percent argument is 
>>> negative is:
>>> 
>>> base + [(base * percent) / 100]
>>> """
>>> 
>>> --Jeremy
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Multitouch support, step one

2010-03-16 Thread The Rasterman 
On Tue, 16 Mar 2010 22:10:57 +0100 Henrik Rydberg  said:

> Olivier Galibert wrote:
> > On Tue, Mar 16, 2010 at 02:42:15PM +0100, Henrik Rydberg wrote:
> >> 1. User space wants details, but also consistent behavior for all devices
> >> supporting multitouch.
> > 
> > On that aspect, wouldn't it make sense to have a user-side gesture
> > manager process with the same kind of status the window manager has?
> > It could generate synthetic events with new types such as zoom in/out,
> > rotate, etc, but also decide when to forward simple clics, drags...
> > 
> > Ultimately, it's where multiplayer experiments could be done.
> > 
> >   OG.
> 
> That would be interesting, yes. Regarding the gestures, there seems to be a
> general consensus that a library and/or various drivers/managers can work
> together to produce all sorts of fun multitouch and multiuser effects. We only
> need to get the underlying contact interface in place first -- in one form or
> the other.

actually it makes  no sense doing this in a generic sense - not a gesture
manager. it would need LOTS of context. what parts of a window are sensitive to
which gestures, events etc. etc. etc. and what they mean, how and so on - and
that is intrinsically linked TO content. a library toolkits can use to help
recognise gestures - sure. a toolkit - or a whole app knows its content well
enough to make these decisions, but you can't do the gesture stuff without
having context.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.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: keyboard bell woes (ignores xset)

2010-03-16 Thread Peter Hutterer 
On Tue, Mar 16, 2010 at 01:12:54PM -0700, Jeremy Huddleston wrote:
> Actually, as I read this again, I noticed that it is behaving as per the spec:
> 
> XBell(dpy, 100) with base = 0:
> base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100
> 
> XBell(dpy, 100) with base = 100:
> base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100
> 
> So... this just seems a bit deceptive... if 'xset -b' is supposed to mute
> the keyboard bell, why was XBell() designed to work around this?

I think you need to ask the question the other way round - why does 
xset -b provide a functionality that XBell() can route around. I'm pretty
sure XBell() was there first :)

Looks like to really disable the bell for core requests you need to call
XkbSetControls() with the XkbAudibleBellMask. That way it can only be
overridden by a forced XkbBell() request, not by any core requests.
xset at this point doesn't do xkb but I don't se why it couldn't.

Cheers,
  Peter
 
 
> On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:
> 
> > I turn off the bell using 'xset -b' :
> > ~ $ xset -q | grep bell
> >  bell percent:  0bell pitch:  400bell duration:  100
> > 
> > but when I do XBell(dpy, 100), the bell still rings at volume 100.
> > 
> > #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
> > #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
> > arg=0x115b71100, something=0) at devices.c:498
> > #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
> > kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
> > pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
> > 
> > Shouldn't the bell percent set by 'xset' be multiplied by the volume passed 
> > to XBell?  From XBell(3):
> > 
> > """
> >   The XBell function rings the bell on the keyboard on the specified 
> > display, if possible.  The specified
> >   volume is relative to the base volume for the keyboard.  If the value 
> > for the percent argument is not in
> >   the range -100 to 100 inclusive, a BadValue error results.  The 
> > volume at which the bell rings when the
> >   percent argument is nonnegative is:
> > 
> >  base - [(base * percent) / 100] + percent
> > 
> >   The volume at which the bell rings when the percent argument is 
> > negative is:
> > 
> >  base + [(base * percent) / 100]
> > """
> > 
> > --Jeremy

___
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] Multitouch support, step one

2010-03-16 Thread Henrik Rydberg 
Olivier Galibert wrote:
> On Tue, Mar 16, 2010 at 02:42:15PM +0100, Henrik Rydberg wrote:
>> 1. User space wants details, but also consistent behavior for all devices
>> supporting multitouch.
> 
> On that aspect, wouldn't it make sense to have a user-side gesture
> manager process with the same kind of status the window manager has?
> It could generate synthetic events with new types such as zoom in/out,
> rotate, etc, but also decide when to forward simple clics, drags...
> 
> Ultimately, it's where multiplayer experiments could be done.
> 
>   OG.

That would be interesting, yes. Regarding the gestures, there seems to be a
general consensus that a library and/or various drivers/managers can work
together to produce all sorts of fun multitouch and multiuser effects. We only
need to get the underlying contact interface in place first -- in one form or
the other.

Henrik
___
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] Multitouch support, step one

2010-03-16 Thread Henrik Rydberg 
Benjamin Tissoires wrote:
> I do not want to break this discussion, but I think that the work you
> mentioned is a little bit aside of the original subject.
> 
> I rapidly had a look at the code and it seems to be a driver for
> trackpads with multitouch enabled. It's really a good job, but I thought
> the original proposal of Peter was to treat 'all' multitouch devices,
> including multitouch-screen.

That is just plain wrong and a red herring. The driver handles all MT event
drivers, there is no difference between touch pads and touch screens in that
respect.

> 
> Personally, I would say that the work you mentioned is of great
> interest, and has to co-exist with the work we are making in this
> thread. But I think it is not enough broad as you treat only a sub-case
> of mt.

Another red herring. The discussion here is about the kernel MT events, and how
to make use of them outside the kernel. Since I wrote the kernel MT protocol, we
can safely assume the scope of the MT events is well represented in the proposed
Contact Driver.

> 
> I will now comment some of your speach...
> 
> Le 16/03/2010 14:42, Henrik Rydberg a écrit :
>> Peter Hutterer wrote:
>>> [snip]
>>
>> 1. Consistent behavior for all devices
>>
>> The hardware stack supporting multitouch is diverse, and several
>> different
>> mechanisms and abstraction levels exists. The tracking ID is a good
>> example. It
>> may or may not be present in the driver output, and it may work poorly
>> even if
>> it exists. Thus, in order to support hardware consistently, there must
>> be a
>> middle layer outside of the kernel, parsing the driver data and
>> patching it up
>> to produce the same level of detail for all devices. This task can be
>> quite
>> complicated and uses some cpu, so having it in one place is
>> imperative. Luckily,
>> there exists such a solution in the multitouch X driver (see link
>> above). This
>> code can either be broken out as a standalone module or be placed in
>> the X core.
>> If there is a license issue, it can be resolved for the benefit of the X
>> community. In the text below, this piece of code will be referred to
>> as the
>> contact driver.
> 
> really like the idea of offering the same interface for all devices. But
> it may just be a piece of code that can be reused by all the different
> drivers (I think it's what you already got, even if I did not found the
> tracking for N-Trig-like devices)

There is no plan to incorporate software finger tracking in the kernel. The
simple solution is to collect the data from the kernel drivers, patch them up to
the same level using the mentioned code (ntrig has a tracking id thus no extra
work for that device), then present it via X to userland. In other words, the
Contact Driver.

> 
>>
>> 2. Bandwidth reduction should be made as early as possible
>>
>> The MT events from the kernel are non-filtered, bypassing the normal
>> input
>> filtering by necessity. Duplicating this behavior further into the
>> food chain
>> would be a mistake. After parsing the MT stream in the contact driver,
>> the event
>> stream can be filtered substantially, thereby restoring bandwidth
>> usage to
>> something more similar to non-mt devices.
>>
> 
> It depends on the different uses. In case of a single user trackpad, ok.
> In case of a large multitouch display, not sure.

This is also wrong, the filtering depends on the signal-to-noise ratio of the
device.

> 
>> 3. The contact driver produces the more digested contact events
>>
>> The contact driver takes the flora of driver MT events and produces a
>> consistent
>> stream of contact events. The contact event stream is less
>> bandwidth-consuming,
>> and follows the init-move-destroy concept we discussed last summer, if
>> you
>> recall. We are still talking about a low-level stream, there are no
>> gesture or
>> other high-level derivatives. Just a consistent stream of data.
>>
> 
> You mean that the client can directly talk to the contact driver?

If the contact driver is an integral part of X, that would more or less be the 
case.

> 
>> 4. ABI, memory and cpu burden for nothing
>>
>> Although the currently hard limit of valuators most likely can be
>> programmed
>> away, it just feels wrong to burden all other applications with the
>> additional
>> memory and cpu usage implied by raising a comfortable limit to
>> something much
>> higher, only to satisfy the request of a completely different
>> interface, which
>> strains the existing concept to the limit of breakage.
>>
> 
> ~256 valuators should be enough as long as we don't have device that
> reports more than 20 touches. (I think that the current limit of the
> devices is around 10)
> The point is that 32 axes is not enough for multitouch. We want it to be
> raised at 256 (the hard limit if I read correctly), but we don't know
> the side-effects.

Famous last words... 256 is a number close enough to the *first* use case that
it will most certainly bite "us" soon enough.

> 
>> 5. Use app

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Olivier Galibert 
On Tue, Mar 16, 2010 at 02:42:15PM +0100, Henrik Rydberg wrote:
> 1. User space wants details, but also consistent behavior for all devices
> supporting multitouch.

On that aspect, wouldn't it make sense to have a user-side gesture
manager process with the same kind of status the window manager has?
It could generate synthetic events with new types such as zoom in/out,
rotate, etc, but also decide when to forward simple clics, drags...

Ultimately, it's where multiplayer experiments could be done.

  OG.
___
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: keyboard bell woes (ignores xset)

2010-03-16 Thread Jeremy Huddleston 
Actually, as I read this again, I noticed that it is behaving as per the spec:

XBell(dpy, 100) with base = 0:
base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100

XBell(dpy, 100) with base = 100:
base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100

So... this just seems a bit deceptive... if 'xset -b' is supposed to mute the 
keyboard bell, why was XBell() designed to work around this?


On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:

> I turn off the bell using 'xset -b' :
> ~ $ xset -q | grep bell
>  bell percent:  0bell pitch:  400bell duration:  100
> 
> but when I do XBell(dpy, 100), the bell still rings at volume 100.
> 
> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
> arg=0x115b71100, something=0) at devices.c:498
> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
> pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
> 
> Shouldn't the bell percent set by 'xset' be multiplied by the volume passed 
> to XBell?  From XBell(3):
> 
> """
>   The XBell function rings the bell on the keyboard on the specified 
> display, if possible.  The specified
>   volume is relative to the base volume for the keyboard.  If the value 
> for the percent argument is not in
>   the range -100 to 100 inclusive, a BadValue error results.  The volume 
> at which the bell rings when the
>   percent argument is nonnegative is:
> 
>  base - [(base * percent) / 100] + percent
> 
>   The volume at which the bell rings when the percent argument is 
> negative is:
> 
>  base + [(base * percent) / 100]
> """
> 
> --Jeremy
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Benjamin Tissoires 
I do not want to break this discussion, but I think that the work you 
mentioned is a little bit aside of the original subject.


I rapidly had a look at the code and it seems to be a driver for 
trackpads with multitouch enabled. It's really a good job, but I thought 
the original proposal of Peter was to treat 'all' multitouch devices, 
including multitouch-screen.


In that case, I don't think this driver is appropriate as it only 
delivers one cursor move (thus reducing the bandwidth) which is really 
good in a trackpad case.


Personally, I would say that the work you mentioned is of great 
interest, and has to co-exist with the work we are making in this 
thread. But I think it is not enough broad as you treat only a sub-case 
of mt.


I will now comment some of your speach...

Le 16/03/2010 14:42, Henrik Rydberg a écrit :

Peter Hutterer wrote:

[snip]


1. Consistent behavior for all devices

The hardware stack supporting multitouch is diverse, and several different
mechanisms and abstraction levels exists. The tracking ID is a good example. It
may or may not be present in the driver output, and it may work poorly even if
it exists. Thus, in order to support hardware consistently, there must be a
middle layer outside of the kernel, parsing the driver data and patching it up
to produce the same level of detail for all devices. This task can be quite
complicated and uses some cpu, so having it in one place is imperative. Luckily,
there exists such a solution in the multitouch X driver (see link above). This
code can either be broken out as a standalone module or be placed in the X core.
If there is a license issue, it can be resolved for the benefit of the X
community. In the text below, this piece of code will be referred to as the
contact driver.


really like the idea of offering the same interface for all devices. But 
it may just be a piece of code that can be reused by all the different 
drivers (I think it's what you already got, even if I did not found the 
tracking for N-Trig-like devices)




2. Bandwidth reduction should be made as early as possible

The MT events from the kernel are non-filtered, bypassing the normal input
filtering by necessity. Duplicating this behavior further into the food chain
would be a mistake. After parsing the MT stream in the contact driver, the event
stream can be filtered substantially, thereby restoring bandwidth usage to
something more similar to non-mt devices.



It depends on the different uses. In case of a single user trackpad, ok. 
In case of a large multitouch display, not sure.



3. The contact driver produces the more digested contact events

The contact driver takes the flora of driver MT events and produces a consistent
stream of contact events. The contact event stream is less bandwidth-consuming,
and follows the init-move-destroy concept we discussed last summer, if you
recall. We are still talking about a low-level stream, there are no gesture or
other high-level derivatives. Just a consistent stream of data.



You mean that the client can directly talk to the contact driver?


4. ABI, memory and cpu burden for nothing

Although the currently hard limit of valuators most likely can be programmed
away, it just feels wrong to burden all other applications with the additional
memory and cpu usage implied by raising a comfortable limit to something much
higher, only to satisfy the request of a completely different interface, which
strains the existing concept to the limit of breakage.



~256 valuators should be enough as long as we don't have device that 
reports more than 20 touches. (I think that the current limit of the 
devices is around 10)
The point is that 32 axes is not enough for multitouch. We want it to be 
raised at 256 (the hard limit if I read correctly), but we don't know 
the side-effects.



5. Use appropriate data structures to solve the problem

By defining a handful of contact api functions, operating on simple structures,
the whole problem of forward compatibility with multi-user multitouch can be
solved in one go, without changing a single bit in the existing interfaces. Yes,
it means a new interface, but the functionality is new, so this is the way it
should be.

---

X Multitouch Support Proposal
-

Introduction


Back in summer 2009, when this was discussed informally between some in the
present party, the general structure that emerged was a split into a low level
protocol and a gesture library, here citing two of the formulations:


Henrik Rydberg:
X multipointer via init-move-destroy to X gesture driver
X gesture driver via enhanced X events to X application

Peter Hutterer:
X server ->  protocol ->  application
   |->   x gesture library


The change I am proposing today simply means inserting the contact driver
discussed above before or in conjunction with the X server in Peter's chain:

kernel ->  [contact driver | X server] ->  protocol ->  applicati

keyboard bell woes (ignores xset)

2010-03-16 Thread Jeremy Huddleston 
I turn off the bell using 'xset -b' :
~ $ xset -q | grep bell
  bell percent:  0bell pitch:  400bell duration:  100

but when I do XBell(dpy, 100), the bell still rings at volume 100.

#0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
#1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
arg=0x115b71100, something=0) at devices.c:498
#2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514

Shouldn't the bell percent set by 'xset' be multiplied by the volume passed to 
XBell?  From XBell(3):

"""
   The XBell function rings the bell on the keyboard on the specified 
display, if possible.  The specified
   volume is relative to the base volume for the keyboard.  If the value 
for the percent argument is not in
   the range -100 to 100 inclusive, a BadValue error results.  The volume 
at which the bell rings when the
   percent argument is nonnegative is:

  base - [(base * percent) / 100] + percent

   The volume at which the bell rings when the percent argument is negative 
is:

  base + [(base * percent) / 100]
"""

--Jeremy



smime.p7s
Description: S/MIME cryptographic 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] revert an XQuartz patch that doesn't seem to be needed any more

2010-03-16 Thread Jeremy Huddleston 
I'm not quite sure any more why this was needed, but DDXRingBell() is called 
from CoreKeyboardBell(), and I don't want to ring the bell three times.  This 
results in our DDXRingBell() getting called just once per XBell().

The following changes since commit 67a8c659f25218904bae64aac6e98e326c90330b:
  Roland Scheidegger (1):
hw/xfree86: move reference counting out of the UseHWCursor[ARGB] 
functions

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (1):
  Revert "XQuartz: Explicitly pass a bellProc to make XBell() work again."

 hw/xquartz/quartzKeyboard.c |8 +---
 1 files changed, 1 insertions(+), 7 deletions(-)



smime.p7s
Description: S/MIME cryptographic 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 evdev] When labeling a device as touchpad, only check for LMR buttons.

2010-03-16 Thread Simon Thum 
I have touchpads two in rare useage but neither has a third button. If
the kernel detects presses or advertises a middle btn for whatever
reason, why rely on it?

Aside from that,

reviewed-by: Simon Thum 

Am 16.03.2010 04:59, schrieb Peter Hutterer:
> Touchpads that have physical buttons have either LMR or BTN_TOOL_FINGER.
> Other buttons in the range evdev recognises shouldn't be taken into account
> here - they skew the detection towards touchpads and away from touchscreens.
> 
> Fedora Bug 571639
> 
> Signed-off-by: Peter Hutterer 
> ---
>  src/evdev.c |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/src/evdev.c b/src/evdev.c
> index 3051462..b532639 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -1767,6 +1767,7 @@ static int
>  EvdevProbe(InputInfoPtr pInfo)
>  {
>  int i, has_rel_axes, has_abs_axes, has_keys, num_buttons, has_scroll;
> +int has_lmr; /* left middle right */
>  int kernel24 = 0;
>  int ignore_abs = 0, ignore_rel = 0;
>  EvdevPtr pEvdev = pInfo->private;
> @@ -1809,6 +1810,7 @@ EvdevProbe(InputInfoPtr pInfo)
>  has_abs_axes = FALSE;
>  has_keys = FALSE;
>  has_scroll = FALSE;
> +has_lmr = FALSE;
>  num_buttons = 0;
>  
>  /* count all buttons */
> @@ -1823,6 +1825,10 @@ EvdevProbe(InputInfoPtr pInfo)
>  }
>  }
>  
> +has_lmr = TestBit(BTN_LEFT, pEvdev->key_bitmask) ||
> +TestBit(BTN_MIDDLE, pEvdev->key_bitmask) ||
> +TestBit(BTN_RIGHT, pEvdev->key_bitmask);
> +
>  if (num_buttons)
>  {
>  pEvdev->flags |= EVDEV_BUTTON_EVENTS;
> @@ -1895,7 +1901,7 @@ EvdevProbe(InputInfoPtr pInfo)
>  }
>  } else if (TestBit(ABS_PRESSURE, pEvdev->abs_bitmask) ||
>  TestBit(BTN_TOUCH, pEvdev->key_bitmask)) {
> -if (num_buttons || TestBit(BTN_TOOL_FINGER, 
> pEvdev->key_bitmask)) {
> +if (has_lmr || TestBit(BTN_TOOL_FINGER, 
> pEvdev->key_bitmask)) {
>  xf86Msg(X_INFO, "%s: Found absolute touchpad.\n", 
> pInfo->name);
>  pEvdev->flags |= EVDEV_TOUCHPAD;
>  memset(pEvdev->old_vals, -1, sizeof(int) * 
> pEvdev->num_vals);

___
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] Evdev and acceleration

2010-03-16 Thread Simon Thum 
Hi,

the hack that is pointer acceleration's init parts bit me. Currently,
this is done during driver calls into xf86InitValuatorDefaults(..., 0).
But since I increased exposure to driver details by fiddling with the
feedback class (see 032f97808c65771a07bac748212cf6457a5d1660), I managed
to cut off evdev, which initializes the feedback class _after_ the
valuators.

Net effect: Evdev devices can't have accel settings tuned using config
fragments ATM. X.org 1.7 is unaffected.

I attached a small patch which brings evdev in line with others. Of
course, the proper fix would be to make pointer accel's initialization
sane. But that would require changes to many drivers, and I'm too
swamped for that ATM.

Since the fix is unintrusive, I propose it as a tempoary solution. And I
pledge to fix things later that year :)

Cheers,

Simon
>From c935b1d8e5a49f22354d96c9863c4b73e9b9acf7 Mon Sep 17 00:00:00 2001
From: Simon Thum 
Date: Tue, 16 Mar 2010 16:00:21 +0100
Subject: [PATCH] move feedback initialization up

This allows the backend to propery initialize the feedback from options,
as it works with most other drivers. This is the hacky equivalent of
fixing the initialization of pointer acceleration, which would require
changes to most drivers.
---
 src/evdev.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 3051462..63927db 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1299,6 +1299,9 @@ EvdevAddRelClass(DeviceIntPtr device)
GetMotionHistorySize(), Relative))
 return !Success;
 
+if (!InitPtrFeedbackClassDeviceStruct(device, EvdevPtrCtrlProc))
+return !Success;
+
 for (axis = REL_X; axis <= REL_MAX; axis++)
 {
 int axnum = pEvdev->axis_map[axis];
@@ -1315,9 +1318,6 @@ EvdevAddRelClass(DeviceIntPtr device)
 
 xfree(atoms);
 
-if (!InitPtrFeedbackClassDeviceStruct(device, EvdevPtrCtrlProc))
-return !Success;
-
 pInfo->flags |= XI86_POINTER_CAPABLE;
 
 return Success;
-- 
1.6.4.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] xkb: Check and load precompiled .xkm during startup if available

2010-03-16 Thread Pat Suwalski 

On 16/03/10 09:58 AM, Pat Suwalski wrote:

I wrote a very similar patch, but I based the name of the
cached/precompiled file on a sha1 hash of source file.


Actually, I had forgotten that in the most recent revision of my method, 
I got tired of patching the X server.


Instead, I wrote the attached wrapper to xkbcomp (with a packaging 
diversion of the actual xkbcomp to xkbcomp.real). That way, I didn't 
have to patch anything.


Ideally, this methodology would be in the real xkbcomp, and then the 
rather ugly parameter parsing could be avoided. I'm sure it's error 
prone; this program is only meant to react to the "-xkm" switch and pass 
everything else along.


In my testing, this was enough to get just about all of the performance 
advantage of the patch to the X server itself. Timing tests didn't show 
any difference, in fact.


--Pat
#include 
#include 
#include 
#include 
#include 

#include 

#define CACHEPATH "/var/cache/xkb"

int main(int argc, char *argv[])
{
  int i, intercept = 0;
  char buf[4096];
  unsigned char shasum[20];
  char filename[256];
  char fullfilename[256];
  char *infile = NULL;
  char *outfile = NULL;
  int filesize = 0;
  size_t len;

  /* Simple parameter checking that at least passes the X.org server uses. */
  for (i=1; i___
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: Xext: Fix cursor reference counting hazard.

2010-03-16 Thread Roland Scheidegger 
On 12.03.2010 16:29, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> Make sure the reference count of the new cursor is increased before the old
> one is decreased, otherwise bad things will happen if they're one and the
> same and the reference count is 1 initially. Not sure this can actually happen
> here, but better safe than sorry.
> 
> Signed-off-by: Michel Dänzer 

Reviewed-by: Roland Scheidegger 

> ---
>  Xext/saver.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Xext/saver.c b/Xext/saver.c
> index 2549e8a..aa2e614 100644
> --- a/Xext/saver.c
> +++ b/Xext/saver.c
> @@ -620,10 +620,10 @@ CreateSaverWindow (ScreenPtr pScreen)
>   FreeResource (pWin->drawable.id, RT_NONE);
>   return FALSE;
>   }
> + pAttr->pCursor->refcnt++;
>   if (pWin->optional->cursor)
>   FreeCursor (pWin->optional->cursor, (Cursor)0);
>   pWin->optional->cursor = pAttr->pCursor;
> - pAttr->pCursor->refcnt++;
>   pWin->cursorIsNone = FALSE;
>   CheckWindowOptionalNeed (pWin);
>   mask |= CWCursor;

___
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] Multitouch support, step one

2010-03-16 Thread Henrik Rydberg 
Peter Hutterer wrote:
> On Mon, Mar 15, 2010 at 03:41:24PM +0100, Henrik Rydberg wrote:
>>> Preamble:
>>> Multi-touch as defined in this proposal is limited to single input-point
>>> multi-touch. This is suitable for indirect touch devices (e.g. touchpads)
>>> and partially suited for direct touch devices provided a touch is equivalent
>>> to a single-gesture single-application input.
>> User-space applications need tools to *use* MT devices, not route raw data 
>> from
>> the devices to the application. The latter is not much more complicated than
>> opening a file, and everyone can do that already. Thus, unless there is a 
>> model
>> for how MT devices work and interact with other MT devices, I see little 
>> point
>> in having an X protocol at all.
> 
> The main reason is that applications, for better or worse, use X as their
> input source. Our job is to get the data to the right client, without too
> much processing going on. For clients to go around the server by opening the
> kernel device files directly will cause issues in the long run, especially
> when you have multiple applications running.

Thank you for addressing my concerns. The details you describe below form a
logical and complete proposal, which is agreeable in its own right.

However, I must insist on continuing this discussion, because my gut
tells me we are moving slightly in the wrong direction. Here are the main 
reasons:

1. User space wants details, but also consistent behavior for all devices
supporting multitouch.

2. The kernel interface is bandwidth-consuming by necessity, but there is no
need for the X protocol to be.

3. Support for multitouch in X does exist already, so there is no need to start
from zero when discussing it (http://bitmath.org/code/multitouch/).

4. The hard limit of 256 guarantees something new will have to be done for
multi-user multitouch, in essence pushing the problem forward.

5. Squeezing MT into the valuator concept is generally crippling, since it does
not map very well to the underlying contact concept.

What follows is a longer version of these five points, and below that is a
proposal for how I believe it should be done.

---

1. Consistent behavior for all devices

The hardware stack supporting multitouch is diverse, and several different
mechanisms and abstraction levels exists. The tracking ID is a good example. It
may or may not be present in the driver output, and it may work poorly even if
it exists. Thus, in order to support hardware consistently, there must be a
middle layer outside of the kernel, parsing the driver data and patching it up
to produce the same level of detail for all devices. This task can be quite
complicated and uses some cpu, so having it in one place is imperative. Luckily,
there exists such a solution in the multitouch X driver (see link above). This
code can either be broken out as a standalone module or be placed in the X core.
If there is a license issue, it can be resolved for the benefit of the X
community. In the text below, this piece of code will be referred to as the
contact driver.

2. Bandwidth reduction should be made as early as possible

The MT events from the kernel are non-filtered, bypassing the normal input
filtering by necessity. Duplicating this behavior further into the food chain
would be a mistake. After parsing the MT stream in the contact driver, the event
stream can be filtered substantially, thereby restoring bandwidth usage to
something more similar to non-mt devices.

3. The contact driver produces the more digested contact events

The contact driver takes the flora of driver MT events and produces a consistent
stream of contact events. The contact event stream is less bandwidth-consuming,
and follows the init-move-destroy concept we discussed last summer, if you
recall. We are still talking about a low-level stream, there are no gesture or
other high-level derivatives. Just a consistent stream of data.

4. ABI, memory and cpu burden for nothing

Although the currently hard limit of valuators most likely can be programmed
away, it just feels wrong to burden all other applications with the additional
memory and cpu usage implied by raising a comfortable limit to something much
higher, only to satisfy the request of a completely different interface, which
strains the existing concept to the limit of breakage.

5. Use appropriate data structures to solve the problem

By defining a handful of contact api functions, operating on simple structures,
the whole problem of forward compatibility with multi-user multitouch can be
solved in one go, without changing a single bit in the existing interfaces. Yes,
it means a new interface, but the functionality is new, so this is the way it
should be.

---

X Multitouch Support Proposal
-

Introduction


Back in summer 2009, when this was discussed informally between some in the
present party, the general structure that emerged was a split into a low level
protocol

Re: [PATCHv10 4/5] dri2: Support the DRI2InvalidateBuffers event.

2010-03-16 Thread Kristian Høgsberg 
2010/3/16 Francisco Jerez :
> Keith Packard  writes:
>
>> I want to get this patch sequence merged, can someone point me at a
>> repository that I can pull it in from?
>
> Kristian, are you OK with v10? If so, could you gather the whole patch
> series in your personal tree?

Yes, the series look good and I've updated my branch:

  git://people.freedesktop.org/~krh dri2-invalidate

I wanted to fix the remaining mesa intel regressions before sending
out a pull request, but at this point I'm sure the problem is in mesa
and that the X server invalidate patches are fine.  I can reproduce
the mesa breakage with and without the X server patches and it bisects
back to my mesa commit d4496278.

Kristian
___
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] A few Cygwin/X patches

2010-03-16 Thread Jon TURNEY 

Hi Keith,

A few minor/cosmetic XWin fixes.  Please consider pulling into master.

Thanks.

The following changes since commit 67a8c659f25218904bae64aac6e98e326c90330b:
  Roland Scheidegger (1):
hw/xfree86: move reference counting out of the UseHWCursor[ARGB] 
functions


are available in the git repository at:

  git://anongit.freedesktop.org/~jturney/xserver master

Colin Harrison (2):
  Xming: Dead code removal
  Xming: Warning fixes

Jon TURNEY (2):
  Cygwin/X: Fix thinko in mount option checking
  Cygwin/X: Tidy up some cosmetic issues in log strings

Yaakov Selkowitz (1):
  Cygwin/X: Allow the default log location to be configurable

 configure.ac |1 +
 dix/registry.c   |2 +-
 hw/xwin/InitOutput.c |   24 
 hw/xwin/Makefile.am  |1 -
 hw/xwin/win.h|2 +-
 hw/xwin/winauth.c|2 +-
 hw/xwin/winclipboardthread.c |2 +-
 hw/xwin/winconfig.c  |2 +-
 hw/xwin/winerror.c   |9 +++-
 hw/xwin/winglobals.c |4 +-
 hw/xwin/winkeybd.c   |   86 --
 hw/xwin/winkeybd.h   |8 ---
 hw/xwin/winkeymap.h  |  136 --
 hw/xwin/winmultiwindowwm.c   |8 +-
 hw/xwin/winprocarg.c |2 +-
 hw/xwin/winscrinit.c |2 +-
 hw/xwin/winshaddd.c  |4 +-
 hw/xwin/winshadddnl.c|2 +-
 hw/xwin/winwindowswm.c   |   10 +---
 include/xwin-config.h.in |2 +
 os/osdep.h   |2 +-
 21 files changed, 40 insertions(+), 271 deletions(-)
 delete mode 100644 hw/xwin/winkeymap.h
___
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] xkb: Check and load precompiled .xkm during startup if available

2010-03-16 Thread Pat Suwalski 

On 15/03/10 06:45 PM, Mikhail Gusarov wrote:

New 'precompiled' subdir is added to xkb data dir, allowing to pre-compile
keymaps to be loaded when server starts and hence avoid running xkbcomp, saving
a bit of time.





+int ret = snprintf(keymapName, keymapNameLen,
+   "%s/precompiled/%s-%s-%s-%s-%s.xkm",
+   XkbBaseDirectory,
+   names->keycodes ? names->keycodes : "def",
+   names->types ? names->types : "def",
+   names->compat ? names->compat : "def",
+   names->symbols ? names->symbols : "def",
+   names->geometry ? names->geometry : "def");


Is that name robust enough?

I wrote a very similar patch, but I based the name of the 
cached/precompiled file on a sha1 hash of source file.


That way, even if the contents of xkb-data change (upgrade, or 
whatever), the change is noticed.


--Pat
___
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] xkb: Check and load precompiled .xkm during startup if available

2010-03-16 Thread Dan Nicholson 
On Mon, Mar 15, 2010 at 5:12 PM, Peter Hutterer
 wrote:
> On Tue, Mar 16, 2010 at 04:45:51AM +0600, Mikhail Gusarov wrote:
>> New 'precompiled' subdir is added to xkb data dir, allowing to pre-compile
>> keymaps to be loaded when server starts and hence avoid running xkbcomp, 
>> saving
>> a bit of time.
>
> Good idea. Do you have any numbers on how much time this actually saves?
> IIRC we only run xkbcomp once at the moment and then re-used the cached
> values. Is skipping this one run beneficial?

When I was profiling this before for the caching patch, the initial
run hurt. Especially since it was synchronous because it was for the
core keyboard and was then part of the init process. On my machine it
was about 0.5 seconds on a cold start:

http://lists.freedesktop.org/archives/xorg/2009-January/042150.html

> What happens if xkeyboard-config is updated after an xkm has been
> precompiled? Do the users need to recompile? This is my main worry, it'll
> make triaging of nonworking keyboard layouts quite tricky.

You could stat the xkb directory or the rules file and skip the xkm
file if it was older. For real crack, you could rebuild the xkm file
if newer xkb files are found, but this would break for people who
explicitly built the keymap on another host.

I don't think there's any way to be smart and safe here. I think the
best you could do is document this option as "use at your own risk"
and spit a warning in the log if the xkm file appears to be older than
the xkb-config files.

--
Dan
___
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: [PATCHv10 4/5] dri2: Support the DRI2InvalidateBuffers event.

2010-03-16 Thread Francisco Jerez 
Keith Packard  writes:

> I want to get this patch sequence merged, can someone point me at a
> repository that I can pull it in from?

Kristian, are you OK with v10? If so, could you gather the whole patch
series in your personal tree?


pgpITtxpMrg3J.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Multitouch support, step one

2010-03-16 Thread Simon Thum 
Am 15.03.2010 23:02, schrieb Peter Hutterer:
> On Mon, Mar 15, 2010 at 06:34:48PM +0100, Simon Thum wrote:
>> I also see the inherent racyness here, but I guess one could work that
>> out by a few routines in libXi which support the MT conventions hammered
>> out here. For example, a routine which skims through events and helps to
>> associate axis labels to events such that races are prevented. I
>> wouldn't worry about things not forbidden in the current spec, as MT so
>> far seems to involve some constraints on how clients interact with the
>> serer anyway.
> 
> This is less a libXi issue as more an issue in how clients may handle the
> events. It's in fact quite similar to how motion events can be treated.
> XIDeviceChangedEvents describe the state of a device as current when the
> event was generated. A client that sees multiple events from the same device
> in the queue may thus skip to the last one to get the info. Not much you can
> do in libXi.
Yes. But that wasn't what I tried to say :)

I wanted to suggest that libXi (or libXfancyMT) provides a purely optional
reference implementation which avoids those issues and can be reused.
Much like everything
X.org is a reference impl, yes, but sill...

IMO, since your approach essentially 'tunnels' the Xi spec, such issues
need more care.

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