Re: [ANNOUNCE] xfs 1.1.2
On 3/2/12 9:39 AM, Andreas Radke wrote: FTBS here ar ArchLinux: make[2]: Entering directory `/build/src/xfs-1.1.2' CC atom.o CC cache.o CC charinfo.o In file included from difs/charinfo.c:66:0: ./include/difs.h:45:13: error: conflicting types for 'MakeAtom' /usr/include/X11/fonts/fontmisc.h:55:13: note: previous declaration of 'MakeAtom' was here ./include/difs.h:46:12: warning: redundant redeclaration of 'ValidAtom' [-Wredundant-decls] /usr/include/X11/fonts/fontmisc.h:56:12: note: previous declaration of 'ValidAtom' was here ./include/difs.h:47:15: warning: redundant redeclaration of 'NameForAtom' [-Wredundant-decls] /usr/include/X11/fonts/fontmisc.h:57:14: note: previous declaration of 'NameForAtom' was here make[2]: *** [charinfo.o] Error 1 make[2]: Leaving directory `/build/src/xfs-1.1.2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/xfs-1.1.2' make: *** [all] Error 2 Yeah, needs a newer libXfont release, by which I mean, libXfont needs a release. - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXfont 1.4.5
libXfont provides the core of the legacy X11 font system, handling the index files (fonts.dir, fonts.alias, fonts.scale), the various font file formats, and rasterizing them. It is used by the X servers, the X Font Server (xfs), and some font utilities (bdftopcf for instance), but should not be used by normal X11 clients. X11 clients access fonts via either the new API's in libXft, or the legacy API's in libX11. This release includes several bug fixes, including updates to better handle fonts compressed with compress(1), cleanups for compiler warnings, and improvements for the developer documentation. Alan Coopersmith (7): Remove configure comment about synchronizing version numbers Strip trailing whitespace Add const attributes to fix gcc -Wwrite-strings warnings Add _X_ATTRIBUTE_PRINTF to *Error/*Warning functions taking printf formats Fix printf warnings about incorrect argument types Use * precision notation instead of computing sprintf format strings libXfont 1.4.5 Gaetan Nadon (4): devbook.am: maintenance update from docbook.am docs: use the fullrelvers; entity to set X11 release information doc: refactor legal text for multi licensing copyrights doc: fix typo in copyright statement Joerg Sonnenberger (2): Do proper input validation to fix for CVE-2011-2895. Fix empty statement in if conditional. Matt Dew (1): 1 - fix the capitalization of the ID attriutes to match either the Olli Vertanen (1): libxfont: An uninitialized pointer causes a crash if pcf header is corrupted. Tomas Hoger (1): Support compress files with maxbits 12 git tag: libXfont-1.4.5 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.4.5.tar.bz2 MD5: 6851da5dae0a6cf5f7c9b9e2b05dd3b4 SHA1: 0bf3cb8aa192ab96bbaf384d1a4a00d15a40171e SHA256: bbf96fb80b6b95cdb1dc968085082a6e668193a54cd9d6e2af669909c0cb7170 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.4.5.tar.gz MD5: a54dea0debecf232a346c22e71d76836 SHA1: 9b88310bac0a81783789a62f426202a921bab5ee SHA256: d0eaa0b180b09986532ef4c2eba94a77c246fce7b8f263b8c45bb6dae30dc4e0 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpbEX2aDIZps.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XDrawLine and optimization
On 3/2/12 4:21 PM, Christopher Howard wrote: I don't have much (any?) Xlib programming savvy, but before diving headlong into the Programming Manual I was hoping to get some perspective. There is a particular application I use pretty often, and one of the things it does is to draw filled line graphs on the screen, which it does by calling XDrawLine() with the appropriate parameters for each data point. Looking at the code, I was curious if I could optimize this, by first drawing everything into some kind of local memory buffer and then passing that into some Xlib function all at once. However, since XDrawLine() presumably draws the lines into a buffer anyway, I'm wondering if there are any realistic gains (or any gains at all) to be had by such an approach. Might or might not help. It really depends more what kind of lines you're drawing - in particular what the GC state is you're using to draw them and the characteristics of the surface you're drawing to - and which driver you're using. Can you give more detail? - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XDrawLine and optimization
On 03/02/2012 12:41 PM, Adam Jackson wrote:
On 3/2/12 4:21 PM, Christopher Howard wrote:
I don't have much (any?) Xlib programming savvy, but before diving
headlong into the Programming Manual I was hoping to get some
perspective. There is a particular application I use pretty often, and
one of the things it does is to draw filled line graphs on the screen,
which it does by calling XDrawLine() with the appropriate parameters for
each data point. Looking at the code, I was curious if I could optimize
this, by first drawing everything into some kind of local memory buffer
and then passing that into some Xlib function all at once.
However, since XDrawLine() presumably draws the lines into a buffer
anyway, I'm wondering if there are any realistic gains (or any gains at
all) to be had by such an approach.
Might or might not help. It really depends more what kind of lines
you're drawing - in particular what the GC state is you're using to draw
them and the characteristics of the surface you're drawing to - and
which driver you're using. Can you give more detail?
- ajax
The code is from conky.c in conky-1.8.1. Before the loop it does one
code:
--
XSetLineAttributes(display, window.gc, 1, LineSolid,
CapButt, JoinMiter);
--
And each actual line draw is preceded by a call to XSetForeground (the
color changes in different parts of the graph).
I'm not yet much familiar with how graphics contexts are set up in Xlib
but I think this is what you are referring to:
code:
--
void create_gc(void)
{
XGCValues values;
values.graphics_exposures = 0;
values.function = GXcopy;
window.gc = XCreateGC(display, window.drawable,
GCFunction | GCGraphicsExposures, values);
}
--
--
frigidcode.com
indicium.us
signature.asc
Description: OpenPGP digital signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: XDrawLine and optimization
On 2012-03-02 17:03, Christopher Howard wrote: On 03/02/2012 12:41 PM, Adam Jackson wrote: On 3/2/12 4:21 PM, Christopher Howard wrote: I don't have much (any?) Xlib programming savvy, but before diving headlong into the Programming Manual I was hoping to get some perspective. There is a particular application I use pretty often, and one of the things it does is to draw filled line graphs on the screen, which it does by calling XDrawLine() with the appropriate parameters for each data point. Looking at the code, I was curious if I could optimize this, by first drawing everything into some kind of local memory buffer and then passing that into some Xlib function all at once. However, since XDrawLine() presumably draws the lines into a buffer anyway, I'm wondering if there are any realistic gains (or any gains at all) to be had by such an approach. Might or might not help. It really depends more what kind of lines you're drawing - in particular what the GC state is you're using to draw them and the characteristics of the surface you're drawing to - and which driver you're using. Can you give more detail? - ajax The code is from conky.c in conky-1.8.1. Before the loop it does one code: -- XSetLineAttributes(display, window.gc, 1, LineSolid, CapButt, JoinMiter); -- If you use a line width of 0 (not 1) it is more likely that the driver can use hardware acceleration (although this is more likely applicable to older drivers). If you can use XRenderCompositeTrapezoids instead of XDrawLine, this may be faster with newer drivers. As a bonus, XRender optionally provides antialiasing. (A library such as Cairo http://cairographics.org/ will be much easier to use than bare XRender). And each actual line draw is preceded by a call to XSetForeground (the color changes in different parts of the graph). That's going to hurt if you're using a remote server. Xlib won't be able to coalesce the lines into a single request, so the app will be using a lot of bandwidth (36 bytes per line, if I've added it up right). So if you're drawing a million lines (I'm not familiar with conky, but it's not unreasonable for some applications) it uses less bandwidth to draw it yourself and do a PutImage at the end, unless your buffer is larger than 8 megapixels or so. On a local server, it doesn't make as much difference. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Review compose key sequence patches January 3rd and 6th
On 2012-02-22 17:32, Pander wrote: On 2012-02-22 16:31, Alan Coopersmith wrote: On 02/22/12 03:12 AM, Pander wrote: On 2012-02-22 01:26, James Cloos wrote: [Did I already send a review?] No not yet. Thanks for following up on this. Some initial thoughts: +Multi_key 0 c : © copyright # COPYRIGHT SIGN Is it really useful to use0 (zero) for that whenO (majuscule oh) ando (miniscule oh) are already there? This allows users to enter copyright sign without using SHIFT.c 0 of0 c would be the fastest way to enter this sign which is used regularly. This also applies to the next less often used signs. How is that any faster or less involving of the shift key than the current Multi_key o c ? Indeed not faster than that one. It is an alternative way, which is as fast but also possible in reverse order, which the o c is not. The compose key sequences with 0 (zero) for §, ¤ and © originate from gtk-compose-lookaside.txt which is being maintained by Simos Xenitellis. Simon, can you give additional justification for the following 12 lines: +Multi_key 0 c : © copyright # COPYRIGHT SIGN +Multi_key 0 C : © copyright # COPYRIGHT SIGN +Multi_key c 0 : © copyright # COPYRIGHT SIGN +Multi_key C 0 : © copyright # COPYRIGHT SIGN +Multi_key s 0 : § section # SECTION SIGN +Multi_key 0 s : § section # SECTION SIGN +Multi_key S 0 : § section # SECTION SIGN +Multi_key 0 S : § section # SECTION SIGN +Multi_key 0 X : ¤ currency # CURRENCY SIGN +Multi_key X 0 : ¤ currency # CURRENCY SIGN +Multi_key 0 x : ¤ currency # CURRENCY SIGN +Multi_key x 0 : ¤ currency # CURRENCY SIGN Or are you willing to drop them from gtk-compose-lookaside.txt? Note that §, ¤ and © already have enough exiting compose key sequences and the ones under consideration are not the most obvious sequences for these characters. In case of dropping them from gtk-compose-lookaside.txt they will also be dropped from my X-GTK-consolidation patch. Regards, Pander PS I have made a simple Python script that used while preparing the patch for finding inconsistencies in Compose.pre. You can find it here http://pastebin.com/5nzQK8n4 and you will see the number of warnings and errors drop by applying the patch. A new patch for final review has been submitted here: https://bugs.freedesktop.org/show_bug.cgi?id=18751 The 10 lines which were labelled as not needed have been removed. The new patch has been made against git head of 2012-03-02. Please do a final review this patch and the patch: https://bugs.freedesktop.org/show_bug.cgi?id=44312 on which were no comments. Again, this will eliminate much of the differences between GTK and X11 compose key sequences which is long overdue. Please contact me if I can be of any assistance. Regards, Pander ___ 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: Review compose key sequence patches January 3rd and 6th
On 03/ 2/12 07:52 AM, Pander wrote: A new patch for final review has been submitted here: https://bugs.freedesktop.org/show_bug.cgi?id=18751 While we're not always speedy at review on xorg-devel, patches mailed to the list tend to get reviewed and applied months or years faster than those stuck in bugzilla. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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 01/10] dri2: Fix can_exchange() to allow page-flipping on more mesa versions.
On Mar 1, 2012, at 9:37 PM, Daniel Stone wrote: Hi, On 1 March 2012 18:11, Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: can_exchange() returns false and thereby prevents page flipping on some drawables where page flipping would work fine. This due to non-matching drawable depths values between front buffer pixmap and back buffer pixmap, because front buffer pixmaps inherit the depth of the screen, typically 24 bits, whereas the depth value of back buffer pixmaps for a given RGB8 or RGBA8 visual depends on the mesa version in use, either 24 bits or 32 bits. Use bitsPerPixel instead of depth to decide if drawable is flippable. This will still catch really incompatible formats like 32 bpp vs. 16 bpp buffers. In theory, shouldn't this be a format-compatibility check, so you don't (unlikely though it is) attempt to flip to a BGR drawable on an RGB configuration, or a drawable on 0565? Cheers, Daniel Yes, i think that would be the best solution, in theory. But i don't think the info is easily available to the ddx? However, i didn't search very hard. -mario ___ 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:xfs] Require libXfont = 1.4.5 to avoid prototype mismatch errors for MakeAtom
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- configure.ac |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index c2ab820..f9400d7 100644 --- a/configure.ac +++ b/configure.ac @@ -130,7 +130,8 @@ AC_CHECK_FUNCS([daemon]) # Checks for pkg-config packages # - xproto = 7.0.17 required for _X_NORETURN in X11/Xfuncproto.h -PKG_CHECK_MODULES(XFS, xproto = 7.0.17 xfont xtrans) +# - xfont = 1.4.5 required for matching MakeAtom prototypes in fontmisc.h +PKG_CHECK_MODULES(XFS, xproto = 7.0.17 xfont = 1.4.5 xtrans) # Transport selection macro from xtrans.m4 XTRANS_CONNECTION_FLAGS -- 1.7.3.2 ___ 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 xf86-input-synaptics v4 00/10] ClickPad support
Change since v3: * Disable ClickPad support unless a physical right button is present. This ensures we don't disable click action support, which many people rely on. Hopefully we can revert this change once we figure out a way to enable ClickPad and click action support at the same time. * When ClickPad is enabled, click actions are disabled by setting the property values to 0. This ensures transparency for the user, and allows the user to override if they really want to. * Multiple soft button implementation fixes from review of previous patch. Note that due to changes in patches, all of these patches need new Reviewed-by tags. The patches may be pulled from: git://people.freedesktop.org/~cndougla/xf86-input-synaptics clickpad-v2 -- Chase ___ 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 xf86-input-synaptics v4 01/10] Add clickpad device property
Add it as a writable device property. We may not know how to probe some
clickpads so allow the user to override it. It is currently not hooked
up to anything yet.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
include/synaptics-properties.h |3 +++
man/synaptics.man | 10 ++
src/properties.c |7 +++
src/synaptics.c|1 +
src/synapticsstr.h |1 +
tools/synclient.c |1 +
6 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/include/synaptics-properties.h b/include/synaptics-properties.h
index c550cef..140f14b 100644
--- a/include/synaptics-properties.h
+++ b/include/synaptics-properties.h
@@ -49,6 +49,9 @@
#define SYNAPTICS_PROP_TAP_DURATIONS Synaptics Tap Durations
/* 8 bit (BOOL) */
+#define SYNAPTICS_PROP_CLICKPAD Synaptics ClickPad
+
+/* 8 bit (BOOL) */
#define SYNAPTICS_PROP_TAP_FAST Synaptics Tap FastTap
/* 32 bit */
diff --git a/man/synaptics.man b/man/synaptics.man
index b6b1dce..8edc2f0 100644
--- a/man/synaptics.man
+++ b/man/synaptics.man
@@ -143,6 +143,12 @@ Maximum time (in milliseconds) for detecting a double tap.
Property:
The duration of the mouse click generated by tapping. Property: Synaptics Tap
Durations
.TP 7
+.BI Option \*qClickPad\*q \*q boolean \*q
+Whether the device is a click pad. A click pad device has button(s) integrated
+into the touchpad surface. The user must press downward on the touchpad in
order
+to generated a button press. This property may be set automatically if a click
+pad device is detected at initialization time. Property: Synaptics ClickPad
+.TP 7
.BI Option \*qFastTaps\*q \*q boolean \*q
Makes the driver react faster to a single tap, but also makes double
clicks caused by double tapping slower. Property: Synaptics Tap FastTap
@@ -785,6 +791,10 @@ Properties supported:
duration of a single click.
.TP 7
+.BI Synaptics ClickPad
+8 bit (Bool).
+
+.TP 7
.BI Synaptics Tap FastTap
8 bit (BOOL).
diff --git a/src/properties.c b/src/properties.c
index 0a52801..38f21b2 100644
--- a/src/properties.c
+++ b/src/properties.c
@@ -58,6 +58,7 @@ Atom prop_finger= 0;
Atom prop_tap_time = 0;
Atom prop_tap_move = 0;
Atom prop_tap_durations = 0;
+Atom prop_clickpad = 0;
Atom prop_tap_fast = 0;
Atom prop_middle_timeout= 0;
Atom prop_twofinger_pressure= 0;
@@ -189,6 +190,8 @@ InitDeviceProperties(InputInfoPtr pInfo)
values[2] = para-click_time;
prop_tap_durations = InitAtom(pInfo-dev, SYNAPTICS_PROP_TAP_DURATIONS,
32, 3, values);
+prop_clickpad = InitAtom(pInfo-dev, SYNAPTICS_PROP_CLICKPAD, 8, 1,
+ para-clickpad);
prop_tap_fast = InitAtom(pInfo-dev, SYNAPTICS_PROP_TAP_FAST, 8, 1,
para-fast_taps);
prop_middle_timeout = InitAtom(pInfo-dev, SYNAPTICS_PROP_MIDDLE_TIMEOUT,
32, 1, para-emulate_mid_button_time);
@@ -392,7 +395,11 @@ SetProperty(DeviceIntPtr dev, Atom property,
XIPropertyValuePtr prop,
para-single_tap_timeout = timeouts[0];
para-tap_time_2 = timeouts[1];
para-click_time = timeouts[2];
+} else if (property == prop_clickpad) {
+if (prop-size != 1 || prop-format != 8 || prop-type != XA_INTEGER)
+return BadMatch;
+para-clickpad = *(BOOL*)prop-data;
} else if (property == prop_tap_fast)
{
if (prop-size != 1 || prop-format != 8 || prop-type != XA_INTEGER)
diff --git a/src/synaptics.c b/src/synaptics.c
index 4784157..4f6b65f 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -534,6 +534,7 @@ static void set_default_parameters(InputInfoPtr pInfo)
pars-tap_move = xf86SetIntOption(opts, MaxTapMove, tapMove);
pars-tap_time_2 = xf86SetIntOption(opts, MaxDoubleTapTime, 180);
pars-click_time = xf86SetIntOption(opts, ClickTime, 100);
+pars-clickpad = xf86SetIntOption(opts, ClickPad, FALSE);
pars-fast_taps = xf86SetBoolOption(opts, FastTaps, FALSE);
pars-emulate_mid_button_time = xf86SetIntOption(opts,
EmulateMidButtonTime, 75);
pars-emulate_twofinger_z = xf86SetIntOption(opts, EmulateTwoFingerMinZ,
emulateTwoFingerMinZ);
diff --git a/src/synapticsstr.h b/src/synapticsstr.h
index ba1eb13..8f33b95 100644
--- a/src/synapticsstr.h
+++ b/src/synapticsstr.h
@@ -125,6 +125,7 @@ typedef struct _SynapticsParameters
int single_tap_timeout;/* timeout to recognize a single
tap */
int tap_time_2;/* max. tapping time for double
taps */
int click_time;/* The duration of a single click */
+Bool clickpad; /* Device is a has integrated
buttons */
Bool fast_taps;/* Faster reaction to single taps */
int emulate_mid_button_time; /* Max time between left and right
button presses to
[PATCH xf86-input-synaptics v4 02/10] Check for clickpad property
However, only enable it by default if a right button is physically
present. Clickpad support conflicts with click action support, so the
user would be left without right button support if there is no physical
right button.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
src/eventcomm.c |7 +++
src/synaptics.c |7 ++-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/eventcomm.c b/src/eventcomm.c
index 6147e41..60be6fe 100644
--- a/src/eventcomm.c
+++ b/src/eventcomm.c
@@ -713,6 +713,7 @@ static void
event_query_touch(InputInfoPtr pInfo)
{
SynapticsPrivate *priv = (SynapticsPrivate *)pInfo-private;
+SynapticsParameters *para = priv-synpara;
struct eventcomm_proto_data *proto_data = priv-proto_data;
struct mtdev *mtdev;
int i;
@@ -730,6 +731,12 @@ event_query_touch(InputInfoPtr pInfo)
return;
}
+if (rc = 0 BitIsOn(prop, INPUT_PROP_BUTTONPAD))
+{
+xf86IDrvMsg(pInfo, X_INFO, found clickpad property\n);
+para-clickpad = TRUE;
+}
+
mtdev = mtdev_new_open(pInfo-fd);
if (!mtdev)
{
diff --git a/src/synaptics.c b/src/synaptics.c
index 4f6b65f..64e87da 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -488,6 +488,11 @@ static void set_default_parameters(InputInfoPtr pInfo)
palmMinWidth = priv-minw + range * (10.0/16);
emulateTwoFingerMinW = priv-minw + range * (7.0/16);
+/* Clickpad conflicts with click actions, disable by default unless there
+ * is a physical right button. */
+if (pars-clickpad !priv-has_right)
+pars-clickpad = 0;
+
/* Enable tap if we don't have a phys left button */
tapButton1 = priv-has_left ? 0 : 1;
tapButton2 = priv-has_left ? 0 : 3;
@@ -534,7 +539,7 @@ static void set_default_parameters(InputInfoPtr pInfo)
pars-tap_move = xf86SetIntOption(opts, MaxTapMove, tapMove);
pars-tap_time_2 = xf86SetIntOption(opts, MaxDoubleTapTime, 180);
pars-click_time = xf86SetIntOption(opts, ClickTime, 100);
-pars-clickpad = xf86SetIntOption(opts, ClickPad, FALSE);
+pars-clickpad = xf86SetIntOption(opts, ClickPad, pars-clickpad); /*
Probed */
pars-fast_taps = xf86SetBoolOption(opts, FastTaps, FALSE);
pars-emulate_mid_button_time = xf86SetIntOption(opts,
EmulateMidButtonTime, 75);
pars-emulate_twofinger_z = xf86SetIntOption(opts, EmulateTwoFingerMinZ,
emulateTwoFingerMinZ);
--
1.7.9
___
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 xf86-input-synaptics v4 03/10] Disable click action functionality for clickpads by default
Clickpad press-and-drag with two fingers will break click actions.
Disable them for these devices by default until a good solution is found
for letting both functionalities co-exist.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
src/properties.c | 14 ++
src/synaptics.c | 11 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/properties.c b/src/properties.c
index 38f21b2..11b4156 100644
--- a/src/properties.c
+++ b/src/properties.c
@@ -400,6 +400,20 @@ SetProperty(DeviceIntPtr dev, Atom property,
XIPropertyValuePtr prop,
return BadMatch;
para-clickpad = *(BOOL*)prop-data;
+
+/* ClickPad support conflicts with click action support. Reset click
+ * actions. The user can override afterwards if they really want. */
+if (para-clickpad)
+{
+CARD8 values[3] = {};
+
+para-click_action[F1_CLICK1] = 0;
+para-click_action[F2_CLICK1] = 0;
+para-click_action[F3_CLICK1] = 0;
+
+XIChangeDeviceProperty(dev, prop_clickaction, XA_INTEGER, 8,
+ PropModeReplace, 3, values, TRUE);
+}
} else if (property == prop_tap_fast)
{
if (prop-size != 1 || prop-format != 8 || prop-type != XA_INTEGER)
diff --git a/src/synaptics.c b/src/synaptics.c
index 64e87da..f1b76ee 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -428,7 +428,7 @@ static void set_default_parameters(InputInfoPtr pInfo)
int pressureMotionMinZ, pressureMotionMaxZ;/* pressure */
int palmMinWidth, palmMinZ;/* pressure */
int tapButton1, tapButton2, tapButton3;
-int clickFinger1, clickFinger2, clickFinger3;
+int clickFinger1 = 0, clickFinger2 = 0, clickFinger3 = 0;
Bool vertEdgeScroll, horizEdgeScroll;
Bool vertTwoFingerScroll, horizTwoFingerScroll;
int horizResolution = 1;
@@ -500,9 +500,12 @@ static void set_default_parameters(InputInfoPtr pInfo)
/* Enable multifinger-click if only have one physical button,
otherwise clickFinger is always button 1. */
-clickFinger1 = 1;
-clickFinger2 = (priv-has_right || priv-has_middle) ? 1 : 3;
-clickFinger3 = (priv-has_right || priv-has_middle) ? 1 : 2;
+if (!pars-clickpad)
+{
+clickFinger1 = 1;
+clickFinger2 = (priv-has_right || priv-has_middle) ? 1 : 3;
+clickFinger3 = (priv-has_right || priv-has_middle) ? 1 : 2;
+}
/* Enable vert edge scroll if we can't detect doubletap */
vertEdgeScroll = priv-has_double ? FALSE : TRUE;
--
1.7.9
___
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 xf86-input-synaptics v4 04/10] Add cumulative_d{x, y} to SynapticsHwState
These values will be used for clickpad press and drag with two fingers.
While the clickpad button is not pressed, cumulative_d{x,y} will match x
and y values. Once the clickpad button is pressed, cumulative_d{x,y}
will be updated with the relative motion of each active touch on the
touchpad. This allows for dragging with one finger while another finger
stays stationary holding the clickpad button down.
This is an easier and less latent approach than trying to guess which
touch was the dragging touch.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
src/eventcomm.c | 35 +--
src/synproto.c |2 ++
src/synproto.h |2 ++
test/fake-symbols.c |5 +
4 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/src/eventcomm.c b/src/eventcomm.c
index 60be6fe..a1f334b 100644
--- a/src/eventcomm.c
+++ b/src/eventcomm.c
@@ -526,6 +526,18 @@ SynapticsReadEvent(InputInfoPtr pInfo, struct input_event
*ev)
return rc;
}
+static Bool
+EventTouchSlotPreviouslyOpen(SynapticsPrivate *priv, int slot)
+{
+int i;
+
+for (i = 0; i priv-num_active_touches; i++)
+if (priv-open_slots[i] == slot)
+return TRUE;
+
+return FALSE;
+}
+
static void
EventProcessTouchEvent(InputInfoPtr pInfo, struct SynapticsHwState *hw,
struct input_event *ev)
@@ -566,8 +578,20 @@ EventProcessTouchEvent(InputInfoPtr pInfo, struct
SynapticsHwState *hw,
int map = proto_data-axis_map[ev-code - ABS_MT_TOUCH_MAJOR];
valuator_mask_set(hw-mt_mask[slot_index], map, ev-value);
if (slot_index = 0)
-valuator_mask_set(proto_data-last_mt_vals[slot_index], map,
- ev-value);
+{
+ValuatorMask *mask = proto_data-last_mt_vals[slot_index];
+int last_val = valuator_mask_get(mask, map);
+
+if (EventTouchSlotPreviouslyOpen(priv, slot_index))
+{
+if (ev-code == ABS_MT_POSITION_X)
+hw-cumulative_dx += ev-value - last_val;
+else if (ev-code == ABS_MT_POSITION_Y)
+hw-cumulative_dy += ev-value - last_val;
+}
+
+valuator_mask_set(mask, map, ev-value);
+}
}
}
#endif
@@ -609,6 +633,13 @@ EventReadHwState(InputInfoPtr pInfo,
SynapticsResetTouchHwState(hw);
+/* Reset cumulative values if buttons were not previously pressed */
+if (!hw-left !hw-right !hw-middle)
+{
+hw-cumulative_dx = hw-x;
+hw-cumulative_dy = hw-y;
+}
+
while (SynapticsReadEvent(pInfo, ev)) {
switch (ev.type) {
case EV_SYN:
diff --git a/src/synproto.c b/src/synproto.c
index 0426e8f..e945f1e 100644
--- a/src/synproto.c
+++ b/src/synproto.c
@@ -120,6 +120,8 @@ SynapticsCopyHwState(struct SynapticsHwState *dst,
dst-x = src-x;
dst-y = src-y;
dst-z = src-z;
+dst-cumulative_dx = src-cumulative_dx;
+dst-cumulative_dy = src-cumulative_dy;
dst-numFingers = src-numFingers;
dst-fingerWidth = src-fingerWidth;
dst-left = src-left;
diff --git a/src/synproto.h b/src/synproto.h
index 89392ac..29e8f3b 100644
--- a/src/synproto.h
+++ b/src/synproto.h
@@ -53,6 +53,8 @@ struct SynapticsHwState {
int x; /* X position of finger */
int y; /* Y position of finger */
int z; /* Finger pressure */
+int cumulative_dx; /* Cumulative delta X for clickpad dragging */
+int cumulative_dy; /* Cumulative delta Y for clickpad dragging */
int numFingers;
int fingerWidth;
diff --git a/test/fake-symbols.c b/test/fake-symbols.c
index 7f3f0ac..65fad46 100644
--- a/test/fake-symbols.c
+++ b/test/fake-symbols.c
@@ -461,6 +461,11 @@ _X_EXPORT void valuator_mask_free(ValuatorMask **mask)
{
}
+_X_EXPORT int valuator_mask_get(const ValuatorMask *mask, int valuator)
+{
+return 0;
+}
+
_X_EXPORT void valuator_mask_set(ValuatorMask *mask, int valuator, int data)
{
}
--
1.7.9
___
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 xf86-input-synaptics v4 06/10] Disable scrolling when beginning a clickpad press
There really isn't a point to scrolling while a clickpad is pressed. In particular, the clickpad button areas and the horizontal edge scrolling areas overlap, so horizontal edge scrolling must be disabled. Also, performing two finger scrolling while a third finger presses the button would require us to inhibit touch events until four touches are present. That is enough reason to disable two finger scrolling as well. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/synaptics.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/synaptics.c b/src/synaptics.c index cdc45c7..35adbed 100644 --- a/src/synaptics.c +++ b/src/synaptics.c @@ -1855,6 +1855,12 @@ HandleTapProcessing(SynapticsPrivate *priv, struct SynapticsHwState *hw, } break; case TS_CLICKPAD_MOVE: + /* Disable scrolling once a button is pressed on a clickpad */ + priv-vert_scroll_edge_on = FALSE; + priv-horiz_scroll_edge_on = FALSE; + priv-vert_scroll_twofinger_on = FALSE; + priv-horiz_scroll_twofinger_on = FALSE; + /* Assume one touch is only for holding the clickpad button down */ if (hw-numFingers 1) hw-numFingers--; -- 1.7.9 ___ 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 xf86-input-synaptics v4 08/10] Add soft button areas property
Some clickpad devices have button areas painted on them. Set this
property to the area of the right and middle buttons to enable proper
click actions when clicking in the areas.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
include/synaptics-properties.h |3 +
man/synaptics.man | 22 +
src/properties.c | 24 +
src/synaptics.c| 186
src/synapticsstr.h |1 +
src/synproto.h |2 +
tools/synclient.c |9 ++
7 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/include/synaptics-properties.h b/include/synaptics-properties.h
index 140f14b..8c20a0c 100644
--- a/include/synaptics-properties.h
+++ b/include/synaptics-properties.h
@@ -158,6 +158,9 @@
/* 32 bit, 4 values, left, right, top, bottom */
#define SYNAPTICS_PROP_AREA Synaptics Area
+/* 32 bit, 4 values, left, right, top, buttom */
+#define SYNAPTICS_PROP_SOFTBUTTON_AREAS Synaptics Soft Button Areas
+
/* 32 Bit Integer, 2 values, horizontal hysteresis, vertical hysteresis */
#define SYNAPTICS_PROP_NOISE_CANCELLATION Synaptics Noise Cancellation
diff --git a/man/synaptics.man b/man/synaptics.man
index 8edc2f0..aaec35f 100644
--- a/man/synaptics.man
+++ b/man/synaptics.man
@@ -518,6 +518,20 @@ AreaBottomEdge option to any integer value other than
zero. If supported by the
server (version 1.9 and later), the edge may be specified in percent of
the total height of the touchpad. Property: Synaptics Area
.
+.TP
+.BI Option \*qSoftButtonAreas\*q \*q RBL RBR RBT RBB MBL MBR MBT MBB \*q
+Enable soft button click area support on ClickPad devices. The first four
+parameters define the area of the right button, and the second four parameters
+define the area of the middle button. The areas are defined by the left, right,
+top, and bottom edges as sequential values of the property. If any edge is set
+to 0, the button is assumed to extend to infinity in the given direction.
+.
+When the user performs a click within the defined soft button areas, the right
+or middle click action is performed.
+.
+The use of soft button areas is disabled by setting all the values for the area
+to 0. Property: Synaptics Soft Button Areas
+.
.SH CONFIGURATION DETAILS
.SS Area handling
@@ -927,6 +941,14 @@ default.
32 bit, 4 values, left, right, top, bottom. 0 disables an element.
.TP 7
+.BI Synaptics Soft Button Areas
+The Right and middle soft button areas are used to support right and middle
+click actions on a ClickPad device. Providing 0 for all values of a given
button
+disables the button area.
+
+32 bit, 8 values, RBL, RBR, RBT, RBB, MBL, MBR, MBT, MBB.
+
+.TP 7
.BI Synaptics Capabilities
This read-only property expresses the physical capability of the touchpad,
most notably whether the touchpad hardware supports multi-finger tapping and
diff --git a/src/properties.c b/src/properties.c
index 11b4156..355b6af 100644
--- a/src/properties.c
+++ b/src/properties.c
@@ -92,6 +92,7 @@ Atom prop_gestures = 0;
Atom prop_capabilities = 0;
Atom prop_resolution= 0;
Atom prop_area = 0;
+Atom prop_softbutton_areas = 0;
Atom prop_noise_cancellation= 0;
Atom prop_product_id= 0;
Atom prop_device_node = 0;
@@ -300,6 +301,16 @@ InitDeviceProperties(InputInfoPtr pInfo)
values[3] = para-area_bottom_edge;
prop_area = InitAtom(pInfo-dev, SYNAPTICS_PROP_AREA, 32, 4, values);
+values[0] = para-softbutton_areas[0][0];
+values[1] = para-softbutton_areas[0][1];
+values[2] = para-softbutton_areas[0][2];
+values[3] = para-softbutton_areas[0][3];
+values[4] = para-softbutton_areas[1][0];
+values[5] = para-softbutton_areas[1][1];
+values[6] = para-softbutton_areas[1][2];
+values[7] = para-softbutton_areas[1][3];
+prop_softbutton_areas = InitAtom(pInfo-dev,
SYNAPTICS_PROP_SOFTBUTTON_AREAS, 32, 8, values);
+
values[0] = para-hyst_x;
values[1] = para-hyst_y;
prop_noise_cancellation = InitAtom(pInfo-dev,
@@ -725,6 +736,19 @@ SetProperty(DeviceIntPtr dev, Atom property,
XIPropertyValuePtr prop,
para-area_right_edge = area[1];
para-area_top_edge= area[2];
para-area_bottom_edge = area[3];
+} else if (property == prop_softbutton_areas)
+{
+int *areas;
+
+if (prop-size != 8 || prop-format != 32 || prop-type != XA_INTEGER)
+return BadMatch;
+
+areas = (int*)prop-data;
+if (!SynapticsIsSoftButtonAreasValid(areas))
+return BadValue;
+
+memcpy(para-softbutton_areas[0], areas, 4 * sizeof(int));
+memcpy(para-softbutton_areas[1], areas + 4, 4 * sizeof(int));
} else if (property == prop_noise_cancellation) {
INT32 *hyst;
if (prop-size != 2 || prop-format != 32 || prop-type != XA_INTEGER)
diff --git a/src/synaptics.c b/src/synaptics.c
index
[PATCH xf86-input-synaptics v4 09/10] Don't use linear regression when calculating touchpad motion deltas
The results depend on the data rate of the device. A device with a higher data rate, and thus lower individual deltas, will behave differently with the regression calculation. This can be verified on Synaptics semi-mt clickpads. The data rate is halved when two or more touches are on the device. When trying to press a button and drag the cursor with another touch, the motion will feel faster than dragging with only one touch on the device. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/synaptics.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/synaptics.c b/src/synaptics.c index 202ae9b..e80dff8 100644 --- a/src/synaptics.c +++ b/src/synaptics.c @@ -2163,9 +2163,8 @@ get_delta(SynapticsPrivate *priv, const struct SynapticsHwState *hw, int x_edge_speed = 0; int y_edge_speed = 0; -/* HIST is full enough: priv-count_packet_finger 3 */ -*dx = estimate_delta(hw-x, HIST(0).x, HIST(1).x, HIST(2).x); -*dy = estimate_delta(hw-y, HIST(0).y, HIST(1).y, HIST(2).y); +*dx = hw-x - HIST(0).x; +*dy = hw-y - HIST(0).y; if ((priv-tap_state == TS_DRAG) || para-edge_motion_use_always) get_edge_speed(priv, hw, edge, x_edge_speed, y_edge_speed); @@ -2234,7 +2233,7 @@ ComputeDeltas(SynapticsPrivate *priv, const struct SynapticsHwState *hw, * POLL_MS declaration. */ delay = MIN(delay, POLL_MS); -if (priv-count_packet_finger = 3) /* min. 3 packets, see get_delta() */ +if (priv-count_packet_finger = 1) goto out; /* skip the lot */ if (priv-moving_state == MS_TRACKSTICK) -- 1.7.9 ___ 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 xf86-input-synaptics v4 10/10] Ignore motion during touch count changes on semi-mt devices
Semi-mt devices do not track touches. The locations of touches are
unknown, we only have the bounding box of two of them. We the number of
fingers changes, the bounding box coordinates may change as well, but
the cumulative relative motion updates at that instant are invalid.
To work around this, ignore changes in cumulative relative motion if the
touch count changes.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
src/synaptics.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/synaptics.c b/src/synaptics.c
index e80dff8..ff3c32e 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -1589,6 +1589,14 @@ ReadInput(InputInfoPtr pInfo)
SynapticsResetTouchHwState(hw);
while (SynapticsGetHwState(pInfo, priv, hw)) {
+ /* Semi-mt device touch slots do not track touches. When there is a
+* change in the number of touches, we must disregard the temporary
+* motion changes. */
+ if (priv-has_semi_mt hw-numFingers != priv-hwState-numFingers) {
+ hw-cumulative_dx = priv-hwState-cumulative_dx;
+ hw-cumulative_dy = priv-hwState-cumulative_dy;
+ }
+
SynapticsCopyHwState(priv-hwState, hw);
delay = HandleState(pInfo, hw, hw-millis, FALSE);
newDelay = TRUE;
--
1.7.9
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH synaptics] Implement a workaround for Elantech touchpads
On 03/01/2012 05:21 PM, Peter Hutterer wrote: From: Peter Zotovwhitequ...@whitequark.org All Elantech touchpads report the number of fingers explicitly, and at least the v3 version of the hardware can report any pressure values down to zero. This interferes with the tap detection hysteresis, which is required for dumb touchpads. This commit implements a vendor-specific workaround for Elantech touchpads which sets the FingerLow and FingerHigh options to 1 by default, effectively disabling the hysteresis mechanism. Signed-off-by: Peter Zotovwhitequ...@whitequark.org Reviewed-by: Peter Huttererpeter.hutte...@who-t.net Makes sense to me. Reviewed-by: Chase Douglas chase.doug...@canonical.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
[PATCH:xhost] Rework si:type:value code to remove need for shadowed namelen variable
Fixes gcc warning:
xhost.c:453:6: warning: declaration of ‘namelen’ shadows a previous local
xhost.c:339:9: warning: shadowed declaration is here
Also removes unnecessary malloc and memcpy by just using the string
pointers we already have, since XAddHost XRemoveHost will copy the
specified length of text from the strings to the Xlib request buffer
before returning, not relying on nil termination.
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
xhost.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/xhost.c b/xhost.c
index cf05d59..736d0ef 100644
--- a/xhost.c
+++ b/xhost.c
@@ -450,7 +450,7 @@ change_host(Display *dpy, char *name, Bool add)
if (family == FamilyServerInterpreted) {
XServerInterpretedAddress siaddr;
- int namelen, rc;
+ int rc;
cp = strchr(name, ':');
if (cp == NULL || cp == name) {
@@ -461,21 +461,14 @@ change_host(Display *dpy, char *name, Bool add)
}
ha.family = FamilyServerInterpreted;
ha.address = (char *) siaddr;
- namelen = strlen(name);
- siaddr.type = malloc(namelen);
- if (siaddr.type == NULL) {
- return 0;
- }
- memcpy(siaddr.type, name, namelen);
+ siaddr.type = name;
siaddr.typelength = cp - name;
- siaddr.type[siaddr.typelength] = '\0';
- siaddr.value = siaddr.type + siaddr.typelength + 1;
- siaddr.valuelength = namelen - (siaddr.typelength + 1);
+ siaddr.value = ++cp;
+ siaddr.valuelength = strlen(cp);
if (add)
rc = XAddHost(dpy, ha);
else
rc = XRemoveHost(dpy, ha);
- free(siaddr.type);
printf( %s %s%s\n, name, rc == 1 ? : failed when ,
add ? add_msg : remove_msg);
if (rc != 1)
--
1.7.3.2
___
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
[ANNOUNCE] libICE 1.0.8
libICE provides the API for the Inter-Client Exchange protocol. This release fixes a number of issues found by static analysis and compiler warnings, and includes a large set of cleanups and improvements to the DocBook format specs for the protocol and docs for the API. Alan Coopersmith (18): config: Remove unnecessary calls from configure.ac config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS Convert src/process.c from malloc + sprintf to asprintf Use correct string pointer in asprintf() fallback Add AC_USE_SYSTEM_EXTENSIONS to make asprintf() visible in GNU libc Resync fallback asprintf with updated version put into xrdb Fix reads outside array bounds in error handlers IceWritePad: Zero fill pad bytes used when buffer is full Strip trailing whitespace Fix gcc -Wwrite-strings warnings in _IceDefaultErrorHandler Fix gcc -Wwrite-strings warnings in _IceError* functions constify arguments to IceGetAuthFileEntry Fix gcc -Wwrite-strings warnings in AuthNames handling Fix gcc -Wwrite-strings warnings in process.c Remove ancient workaround for System V/386 Release 4.2 compiler bug Constify protocol, vendor release string args to IceRegisterForProtocol* Plug minor memory leak in unusual path through ProcessConnectionSetup libICE 1.0.8 Gaetan Nadon (19): config: HTML file generation: use the installed copy of xorg.css config: remove unrequired AC_HEADER_STDC config: comment, minor upgrade, quote and layout configure.ac config: splitting ICE and XTRANS compiler options is not required Docbook: change the book id to match the xml file basename Documentation: add Docbook external references support doc: xorg-sgml-doctools package at version 1.7 is required Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element ICElib doc: remove empty revision list and specify the doc version number ice.xml: fix orphan affiliation ice.xml: version number is 1.1, not 1.0 specs: use the fullrelvers; entity to set X11 release information specs: remove orphan corpname specs: use DocBook suggested markup for Copyrights specs: remove productnumber which is not used by default As of 1997, X Window System is a trademark of The Open Group. Matt Dew (3): add id attributes to funcsynopsis to allow other docs to olink to them Cleanup IDs and links in doc informaltable cleanup Paulo Zanoni (2): Use docbookx.dtd version 4.3 for all docs Remove useless line from a table in specs/ice.xml git tag: libICE-1.0.8 http://xorg.freedesktop.org/archive/individual/lib/libICE-1.0.8.tar.bz2 MD5: 471b5ca9f5562ac0d6eac7a0bf650738 SHA1: ddb14df8bbc43df7322978f5f9f802936e2a7324 SHA256: 24a991284d02ff0c789bc8d11ad2e4dffe144cb70f24e28f9ce3e8b1ee08b71e http://xorg.freedesktop.org/archive/individual/lib/libICE-1.0.8.tar.gz MD5: 4b8dae73fce37e994c3a6fa05d6db7ca SHA1: 22aa5898443e0652337f80796a3a33dc67cab8b6 SHA256: 8332018b07ec38a4a35a360b39f7391c58d053ce5f676aa457b1a686b0277cc0 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpPs9NY3epJQ.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
