Twas brillig at 10:12:14 16.03.2010 UTC+10 when peter.hutte...@who-t.net did
gyre and gimble:
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.
PH Good idea. Do you
On Tue, Mar 16, 2010 at 12:04:53PM +0600, Mikhail Gusarov wrote:
Twas brillig at 10:12:14 16.03.2010 UTC+10 when peter.hutte...@who-t.net did
gyre and gimble:
New 'precompiled' subdir is added to xkb data dir, allowing to
pre-compile keymaps to be loaded when server starts and hence
Twas brillig at 16:18:07 16.03.2010 UTC+10 when peter.hutte...@who-t.net did
gyre and gimble:
Not for my case, I don't have xkbcomp at all, as it needs Xlib
(which I managed to avoid entirely so far).
Ha! Damn. Never thought about it :) Sre it will work just fine. Still
bit of time will be
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
Keith Packard kei...@keithp.com 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
On Mon, Mar 15, 2010 at 5:12 PM, Peter Hutterer
peter.hutte...@who-t.net 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,
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.
snip
+int ret = snprintf(keymapName, keymapNameLen,
+
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
2010/3/16 Francisco Jerez curroje...@riseup.net:
Keith Packard kei...@keithp.com 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
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
On 12.03.2010 16:29, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
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
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
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 simon.t...@gmx.de
Am 16.03.2010 04:59, schrieb Peter Hutterer:
Touchpads that have physical
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
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
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
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
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
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
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
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 *
On Tue, 16 Mar 2010 22:10:57 +0100 Henrik Rydberg rydb...@euromail.se 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
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
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
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
http://bugs.freedesktop.org/show_bug.cgi?id=25112
Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com
---
config/Xresources.cpp |2 +-
greeter/Login.c |6 +-
greeter/verify.c | 12 +++-
xdm.man.cpp |2 ++
4 files changed, 15 insertions(+), 7
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
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
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
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
On Wed, 17 Mar 2010 03:22:20 +0200 Daniel Stone dan...@fooishbar.org 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_
On Mon, 15 Mar 2010 12:55:11 +0100 Benjamin Tissoires tisso...@cena.fr 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
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 peter.hutte...@who-t.net
---
src/synaptics.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
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
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
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
36 matches
Mail list logo
