[RFC][PATCH v3 resourceproto 0/1] Protocol description of X Resource Extension version 1.2.
v1: Initial documentation of changes from version 1.1 to 1.2. v2: Version 1.2 takes resource cross references into account. v3: Version 1.1 has been reverse engineered from code to the document. Rami Ylimäki (1): Protocol description of X Resource Extension version 1.2. RESproto.txt | 452 ++ 1 files changed, 452 insertions(+), 0 deletions(-) create mode 100644 RESproto.txt ___ 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] xfree86: Fix rotation of 2-color non-interleaved cursor images
Cyril Brulebois k...@debian.org (17/11/2010): Aaron Plattner aplatt...@nvidia.com (16/11/2010): Could somebody with hardware that sets SOURCE_MASK_INTERLEAVE (e.g. Intel) please give this patch a try and verify that it doesn't break rotated cursors? Sounds OK here. For those wondering: as an Intel user, that doesn't sound like breaking rotated cursors. Hope it clarifies. Mraw, KiBi. signature.asc Description: Digital 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] fix xserver segfaulting in glxext.c:DrawableGone() (NULL pointer)
On Wed, Nov 17, 2010 at 07:53:30 +0100, Thierry Vignaud wrote: Hi I've attached a patch[1] against bug #31538 [2] that fix xserver segfaulting in glxext.c:DrawableGone() on NULL pointer. See stack trace there[3]. It's against xserver-1.7. xserver-1.9 doesn't trigger it anymore but I think it may still be relevant. That patch looks like perl, not C. Cheers, Julien ___ 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] fix xserver segfaulting in glxext.c:DrawableGone() (NULL pointer)
On 17 November 2010 13:57, Julien Cristau jcris...@debian.org wrote:
I've attached a patch[1] against bug #31538 [2] that fix xserver segfaulting
in
glxext.c:DrawableGone() on NULL pointer.
See stack trace there[3].
It's against xserver-1.7.
xserver-1.9 doesn't trigger it anymore but I think it may still be relevant.
That patch looks like perl, not C.
ahem...
--- glx/glxext.c.tv 2010-11-11 04:19:15.0 +0100
+++ glx/glxext.c2010-11-11 04:20:03.0 +0100
@@ -125,6 +125,8 @@
static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
{
__GLXcontext *c;
+ if (!glxPriv)
+ return;
for (c = glxAllContexts; c; c = c-next) {
if (c-isCurrent (c-drawPriv == glxPriv || c-readPriv ==
glxPriv)) {
___
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 XI 2.1 - xinput 2/3] Zero out entire mask when selecting for raw events
On 11/17/2010 12:24 AM, Peter Hutterer wrote: On Fri, Nov 12, 2010 at 05:35:16PM -0500, Chase Douglas wrote: From: Chase Douglas chase.doug...@ubuntu.com Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/test_xi2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/test_xi2.c b/src/test_xi2.c index fea36a8..30bb0fa 100644 --- a/src/test_xi2.c +++ b/src/test_xi2.c @@ -339,7 +339,7 @@ test_xi2(Display *display, } mask.deviceid = XIAllMasterDevices; -memset(mask.mask, 0, 2); +memset(mask.mask, 0, mask.mask_len); shouldn't the same be done for the XIGrabModifiers path about 15 lines up for consistency? Yep, I just missed it. I'll resend. Thanks, -- 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
[RFC XI 2.1 - xinput 2/3 v2] Zero out entire mask when selecting for different events
Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/test_xi2.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/test_xi2.c b/src/test_xi2.c index fea36a8..5b56397 100644 --- a/src/test_xi2.c +++ b/src/test_xi2.c @@ -324,7 +324,7 @@ test_xi2(Display*display, int nmods = sizeof(modifiers)/sizeof(modifiers[0]); mask.deviceid = 2; -memset(mask.mask, 0, 2); +memset(mask.mask, 0, mask.mask_len); XISetMask(mask.mask, XI_KeyPress); XISetMask(mask.mask, XI_KeyRelease); XISetMask(mask.mask, XI_ButtonPress); @@ -339,7 +339,7 @@ test_xi2(Display*display, } mask.deviceid = XIAllMasterDevices; -memset(mask.mask, 0, 2); +memset(mask.mask, 0, mask.mask_len); XISetMask(mask.mask, XI_RawKeyPress); XISetMask(mask.mask, XI_RawKeyRelease); XISetMask(mask.mask, XI_RawButtonPress); -- 1.7.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 XI 2.1 - xserver 7/9] Reorder AxisInfo elements
On 11/17/2010 01:11 AM, Peter Hutterer wrote:
On Fri, Nov 12, 2010 at 05:35:08PM -0500, Chase Douglas wrote:
From: Chase Douglas chase.doug...@ubuntu.com
Reorder elements so they can be uniform with the upcoming TouchAxisInfo
elements required for coordinate scaling.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
include/inputstr.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/inputstr.h b/include/inputstr.h
index 4d8ea12..b3c60b2 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -213,11 +213,11 @@ typedef struct _KeyClassRec {
typedef struct _AxisInfo {
int resolution;
-int min_resolution;
-int max_resolution;
int min_value;
int max_value;
Atomlabel;
+int min_resolution;
+int max_resolution;
CARD8 mode;
} AxisInfo, *AxisInfoPtr;
--
1.7.1
this is technically an ABI break, together with the masked_valuator exports
I'll won't merge this into master right now until we've figured out if it's
worth bumping the ABI again.
This one certainly isn't worth it by itself since it's only helpful for
MT stuff.
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
(the same applies to the valuator mask export patch, was too quick in
hitting send on that one ;)
The valuator mask helpers change is needed if we want masked vals in
evdev in 1.10.
I don't know what the guidelines are for ABI changes in the middle of
development. I see three scenarios:
1. Merge helper functions and don't bump ABI again. This seems
reasonable to me before the merge window closes, especially for
backwards compatible ABI changes like this one.
2. Bump the minor ABI number. Since the helper function addition is
backwards compatible, this is possible and shouldn't harm anyone.
Between 1 and 2 it's just a matter of whether we really care to bump the
ABI multiple times, even just minor bumps, during a merge cycle.
3. Bump the major ABI number. I don't see why we would want to do this
unless we care about ABI bumps in the middle of a merge cycle and we
pull in the AxisInfo change.
I know the above is rather self explanatory, but I have been wondering
about ABI policy in the middle of a merge cycle. This is all probably
documented somewhere and I've been too lazy :).
Thanks,
-- 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
Re: How to get a list of windows and process mapping
On Tue, Nov 16, 2010 at 3:44 PM, Adam Majer ad...@zombino.com wrote: Is there a method of getting a list of all the windows on a given display or screen? Is there a method of mapping these Windows to host/pid? Maybe having a look at xwininfo (and its sources) will help get you started? $ xwininfo -root -tree -wm ___ 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 XI 2.1 - inputproto] Add touch classes and events, bump to 2.1
On 11/17/2010 01:25 AM, Peter Hutterer wrote: On Fri, Nov 12, 2010 at 05:35:01PM -0500, Chase Douglas wrote: diff --git a/XI2.h b/XI2.h index 6ba1377..f3ee7f0 100644 --- a/XI2.h +++ b/XI2.h @@ -32,10 +32,12 @@ #define Dont_Check 0 #endif #define XInput_2_0 7 +#define XInput_2_1 8 coincidentally, that's a libXi-internal define that should be removed from the protocol headers. I've got the patch ready for this, leave this one as-is for now. Ok. --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.60]) -AC_INIT([InputProto], [2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [2.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) bump to version 2.0.99.1 is better for now, we can't possibly claim this is stable yet :) Good point! AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -- 1.7.1 I would _really_ like to see the XI2proto.txt patch for this too to see the semantics of these changes. Ok, I applied the big diff of the XI2proto.txt from your multitouch tree and modified it where appropriate. I deleted all references to grabbing and did not add any new grab-like semantics at this time. Reviewed-by: Peter Hutterer peter.hutte...@who-t.net for this patch, but that's without knowing wider implications based on the semantics. I've not added your tag since I added the XI2proto.txt changes. Please review again to be sure everything seems good. I'm going to assume that a Reviewed-by tag from you and Daniel is a mark of consensus agreement on the protocol changes laid out in the commit. I pushed the changes to my repo on fdo, and I'll send a new patch so we can do further inline review. Thanks, -- 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
[RFC XI 2.1 - inputproto] Add touch classes and events, bump to 2.1
Introduce multitouch support through a new TouchClass, as well as new
TouchBegin, TouchEnd and TouchMotion events. Bump to version 2.1.
Based on an initial patch by Daniel Stone (headers) and Peter Hutterer
(protocol documentation).
Signed-off-by: Daniel Stone dan...@fooishbar.org
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
XI2.h| 19 +-
XI2proto.h | 25
XI2proto.txt | 191 +-
configure.ac |2 +-
4 files changed, 231 insertions(+), 6 deletions(-)
diff --git a/XI2.h b/XI2.h
index 6ba1377..5d407ea 100644
--- a/XI2.h
+++ b/XI2.h
@@ -36,6 +36,7 @@
#define XI_2_Major 2
#define XI_2_Minor 0
+#define XI_2_1_Minor1
/* Property event flags */
#define XIPropertyDeleted 0
@@ -113,15 +114,23 @@
#define XISlaveKeyboard 4
#define XIFloatingSlave 5
-/* Device classes */
+/* Device classes: classes that are not identical to Xi 1.x classes must be
+ * numbered starting from 8. */
#define XIKeyClass 0
#define XIButtonClass 1
#define XIValuatorClass 2
+#define XITouchClass8
+#define XITouchValuatorClass9
/* Device event flags (common) */
/* Device event flags (key events only) */
#define XIKeyRepeat (1 16)
/* Device event flags (pointer events only) */
+#define XITouchPointer (1 24)
+
+/* Touch modes */
+#define XIDirectTouch 1
+#define XIDependentTouch2
/* XI2 event mask macros */
#define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)3] |= (1
((event) 7)))
@@ -151,7 +160,10 @@
#define XI_RawButtonPress15
#define XI_RawButtonRelease 16
#define XI_RawMotion 17
-#define XI_LASTEVENT XI_RawMotion
+#define XI_TouchBegin18
+#define XI_TouchEnd 19
+#define XI_TouchMotion 20
+#define XI_LASTEVENT XI_TouchMotion
/* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value
* as XI_LASTEVENT if the server is supposed to handle masks etc. for this
* type of event. */
@@ -177,5 +189,8 @@
#define XI_RawButtonPressMask(1 XI_RawButtonPress)
#define XI_RawButtonReleaseMask (1 XI_RawButtonRelease)
#define XI_RawMotionMask (1 XI_RawMotion)
+#define XI_TouchBeginMask(1 XI_TouchBegin)
+#define XI_TouchEndMask (1 XI_TouchEnd)
+#define XI_TouchMotionMask (1 XI_TouchMotion)
#endif /* _XI2_H_ */
diff --git a/XI2proto.h b/XI2proto.h
index 84574a5..418c23d 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -188,6 +188,31 @@ typedef struct {
uint16_tpad2;
} xXIValuatorInfo;
+/**
+ * Denotes multitouch capability on a device.
+ */
+typedef struct {
+uint16_ttype; /** Always TouchClass */
+uint16_tlength; /** Length in 4 byte units */
+uint16_tsourceid; /** source device for this class */
+uint8_t mode; /** DirectTouch or DependentTouch */
+uint8_t num_touches;/** Maximum number of touches */
+} xXITouchInfo;
+
+/**
+ * Denotes a multitouch valuator capability on a device.
+ * One XITouchValuatorInfo describes exactly one valuator (axis) on the device.
+ */
+typedef struct {
+uint16_ttype; /** Always TouchValuatorClass */
+uint16_tlength; /** Length in 4 byte units */
+uint16_tsourceid; /** source device for this class */
+uint16_tnumber; /** Valuator number*/
+Atomlabel; /** Axis label */
+FP3232 min;/** Min value */
+FP3232 max;/** Max value */
+uint32_tresolution; /** Resolutions in units/m */
+} xXITouchValuatorInfo;
/**
* Used to select for events on a given window.
diff --git a/XI2proto.txt b/XI2proto.txt
index 10f58c2..fd47643 100644
--- a/XI2proto.txt
+++ b/XI2proto.txt
@@ -1,6 +1,7 @@
The X Input Extension
Version 2.0
+Version 2.1
Peter Hutterer
peter.hutte...@redhat.com
@@ -31,6 +32,40 @@ used on applications employing the core protocol. XI2
addresses both of these
issues by enabling devices to be both extended and core devices and providing
device information in each event (with the exception of core events).
+1.1 X Input Extension version 2.1 (XI 2.1)
+XI 2.1 introduces support for multi-touch devices. The
Re: How to get a list of windows and process mapping
On 11/17/2010 06:41 PM, Trevor Woerner wrote: On Tue, Nov 16, 2010 at 3:44 PM, Adam Majerad...@zombino.com wrote: Is there a method of getting a list of all the windows on a given display or screen? Is there a method of mapping these Windows to host/pid? Maybe having a look at xwininfo (and its sources) will help get you started? $ xwininfo -root -tree -wm We are currently implementing a better mechanism to identify resource owners/clients with X resource extension v1.2: http://lists.x.org/archives/xorg-devel/2010-November/015538.html. It will still take a few weeks to implement that so with current X server versions you need to do it the xrestop/xwininfo way. -- Rami ___ 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 keyboard] Adjust to input ABI 12.
On 11/16/2010 07:11 PM, Peter Hutterer wrote: New PreInit prototype and a few other things. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Sorry, had this on my local tree and never pushed it, hence why I didn't notice the build breaks. Cheers, Peter src/kbd.c | 80 + 1 files changed, 59 insertions(+), 21 deletions(-) diff --git a/src/kbd.c b/src/kbd.c index e0b7003..62ce0c4 100644 --- a/src/kbd.c +++ b/src/kbd.c @@ -49,7 +49,11 @@ /* Used to know when the first DEVICE_ON after a DEVICE_INIT is called */ #define INITFLAG (1U 31) +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 static InputInfoPtr KbdPreInit(InputDriverPtr drv, IDevPtr dev, int flags); +#else +static int KbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags); +#endif static int KbdProc(DeviceIntPtr device, int what); static void KbdCtrl(DeviceIntPtr device, KeybdCtrl *ctrl); static void KbdBell(int percent, DeviceIntPtr dev, pointer ctrl, int unused); @@ -125,21 +129,52 @@ SetXkbOption(InputInfoPtr pInfo, char *name, char **option) } } +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 +static int +NewKbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags) Has this been test built against 12? I think you're missing a semicolon here. -- 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
Re: [PATCH mouse 0/3] ABI 12 fixes
On 11/16/2010 07:10 PM, Peter Hutterer wrote: oops, these were slumbering in my local tree but never got sent to the list. Fixing up the mouse driver for input ABI 12. 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
Re: Smooth scrolling again
On 11/14/10 22:52, Peter Hutterer wrote: On Sun, Nov 14, 2010 at 06:51:43PM +0100, Max Schwarz wrote: Are the drivers allowed to access the valuator structure (e.g. dev-valuator-axis[0].resolution = XY) or should I implement wrapper functions in the server to do that? It depends on whether the server can operate properly without wrappers, i.e. whether some complex state needs wrangling. In that particular case, I'm leaning slightly towards wrapping. That would mean something like xf86SetValuatorAxisResolution(DeviceIntPtr dev, int axnum, int min, int max, int current)? This method could directly send out the DeviceChangedEvent. Would that still be a layer violation? I'll add that to my patch in the next days. if possible, wrap it. it's much easier to work around issues than when each driver just mangles the struct directly. But I don't think you need a new call here, just re-using the existing InitValuatorAxisStruct should do. Srsly? I mean, that's initialization. Sure, git also has non/destructive initialization, but I'd rather have wrapped calls which optionally send events. That way one might also suppress superfluous events generated when modifying multiple axes. 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
Re: [RFC][PATCH v3 resourceproto 1/1] Protocol description of X Resource Extension version 1.2.
[Due to mail delivery trouble I've missed the previous discussion on this, as well as pretty much all other mail for the last week, so apologies if I missed something.] Rami Ylimäki wrote: +The protocol description of X Resource Extension version 1.1 has been +either lost or has never been written. This specification documents +version 1.1 based on reverse engineered library and server code. In +addition to that, a new 1.2 version of the extension is introduced. The currently shipped protocol is actually 1.0 if you look at the XResproto.h - the 1.1 in git was solely packaging cleanups and probably should have been called 1.0.3. Since we made that mistake, it makes sense for the new version to be 1.2, but the docs should still define 1.0 (and probably mention that 1.1 was the same as 1.0). A completely random thought: should device grabs be somehow exposed as well so it's easier to write a client to see who grabbed your mouse and failed to release it? (Perhaps as a resource with a made-up XID?) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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 keyboard] Adjust to input ABI 12.
Chase Douglas chase.doug...@canonical.com (17/11/2010): +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 +static int +NewKbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags) Has this been test built against 12? I think you're missing a semicolon here. Indeed, and it builds fine once the semicolon added. Mraw, KiBi. signature.asc Description: Digital 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: Smooth scrolling again
On Wednesday 17 November 2010 at 23:55:20, Simon Thum wrote: if possible, wrap it. it's much easier to work around issues than when each driver just mangles the struct directly. But I don't think you need a new call here, just re-using the existing InitValuatorAxisStruct should do. Srsly? I mean, that's initialization. Sure, git also has non/destructive initialization, but I'd rather have wrapped calls which optionally send events. That way one might also suppress superfluous events generated when modifying multiple axes. Yeah, I wondered about that, especially as I have to call xf86SetValuatorAxisNoIntegration() after xf86InitValuatorAxisStruct() again... I would propose specific methods for changing the resolution, axes ranges, etc., and one final call to send out events. Max ___ 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 keyboard] Adjust to input ABI 12.
On Wed, Nov 17, 2010 at 01:51:19PM -0500, Chase Douglas wrote: On 11/16/2010 07:11 PM, Peter Hutterer wrote: New PreInit prototype and a few other things. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Sorry, had this on my local tree and never pushed it, hence why I didn't notice the build breaks. Cheers, Peter src/kbd.c | 80 + 1 files changed, 59 insertions(+), 21 deletions(-) diff --git a/src/kbd.c b/src/kbd.c index e0b7003..62ce0c4 100644 --- a/src/kbd.c +++ b/src/kbd.c @@ -49,7 +49,11 @@ /* Used to know when the first DEVICE_ON after a DEVICE_INIT is called */ #define INITFLAG (1U 31) +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 static InputInfoPtr KbdPreInit(InputDriverPtr drv, IDevPtr dev, int flags); +#else +static int KbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags); +#endif static int KbdProc(DeviceIntPtr device, int what); static void KbdCtrl(DeviceIntPtr device, KeybdCtrl *ctrl); static void KbdBell(int percent, DeviceIntPtr dev, pointer ctrl, int unused); @@ -125,21 +129,52 @@ SetXkbOption(InputInfoPtr pInfo, char *name, char **option) } } +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 +static int +NewKbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags) Has this been test built against 12? I think you're missing a semicolon here. oops. I thought I had, but I must have only tested for ABI 12. Will do tests for both and re-send. thanks for catching this. Cheers, Peter ___ 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 XI 2.1 - xserver 7/9] Reorder AxisInfo elements
On Wed, Nov 17, 2010 at 10:53:16AM -0500, Chase Douglas wrote:
On 11/17/2010 01:11 AM, Peter Hutterer wrote:
On Fri, Nov 12, 2010 at 05:35:08PM -0500, Chase Douglas wrote:
From: Chase Douglas chase.doug...@ubuntu.com
Reorder elements so they can be uniform with the upcoming TouchAxisInfo
elements required for coordinate scaling.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
include/inputstr.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/inputstr.h b/include/inputstr.h
index 4d8ea12..b3c60b2 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -213,11 +213,11 @@ typedef struct _KeyClassRec {
typedef struct _AxisInfo {
int resolution;
-int min_resolution;
-int max_resolution;
int min_value;
int max_value;
Atom label;
+int min_resolution;
+int max_resolution;
CARD8 mode;
} AxisInfo, *AxisInfoPtr;
--
1.7.1
this is technically an ABI break, together with the masked_valuator exports
I'll won't merge this into master right now until we've figured out if it's
worth bumping the ABI again.
This one certainly isn't worth it by itself since it's only helpful for
MT stuff.
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
(the same applies to the valuator mask export patch, was too quick in
hitting send on that one ;)
The valuator mask helpers change is needed if we want masked vals in
evdev in 1.10.
I don't know what the guidelines are for ABI changes in the middle of
development. I see three scenarios:
there are no real guidelines beyond what I make up on the spot.
keith's approach to the video ABI is bump once per cyle.
I've outlined the ABI approaches here
http://www.mail-archive.com/xorg-devel@lists.x.org/msg14562.html
and just added a short paragraph to
http://wiki.x.org/wiki/XorgModuleABIVersions (remind me to update that when
needed :)
1. Merge helper functions and don't bump ABI again. This seems
reasonable to me before the merge window closes, especially for
backwards compatible ABI changes like this one.
2. Bump the minor ABI number. Since the helper function addition is
backwards compatible, this is possible and shouldn't harm anyone.
Between 1 and 2 it's just a matter of whether we really care to bump the
ABI multiple times, even just minor bumps, during a merge cycle.
3. Bump the major ABI number. I don't see why we would want to do this
unless we care about ABI bumps in the middle of a merge cycle and we
pull in the AxisInfo change.
I know the above is rather self explanatory, but I have been wondering
about ABI policy in the middle of a merge cycle. This is all probably
documented somewhere and I've been too lazy :).
fwiw, I don't really see a need to differ between major/minor ABI. It's just
a number and we have a fair way to go before we run out of integers. And not
having to remember which one was major/minor in the driver ifdefs is
helpful.
so for all I care, we can bump the major number again, but I'd like to do
this not immediately, but rather when we know that we likely won't need
another bump this cycle.
Since the major motivation here is the MT work and the changes aren't
immediately needed for other stuff, I'd like to hold this back on the MT
branch and then cherry-pick over when we have a clearer picture. Does this
make sense?
We have some time left in the devel cycle when we can merge the ABI bump (we
don't have to care about ABI stability until the last month).
Cheers,
Peter
___
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 XI 2.1 - xinput 2/3 v2] Zero out entire mask when selecting for different events
On Wed, Nov 17, 2010 at 10:42:38AM -0500, Chase Douglas wrote: Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/test_xi2.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/test_xi2.c b/src/test_xi2.c index fea36a8..5b56397 100644 --- a/src/test_xi2.c +++ b/src/test_xi2.c @@ -324,7 +324,7 @@ test_xi2(Display *display, int nmods = sizeof(modifiers)/sizeof(modifiers[0]); mask.deviceid = 2; -memset(mask.mask, 0, 2); +memset(mask.mask, 0, mask.mask_len); XISetMask(mask.mask, XI_KeyPress); XISetMask(mask.mask, XI_KeyRelease); XISetMask(mask.mask, XI_ButtonPress); @@ -339,7 +339,7 @@ test_xi2(Display *display, } mask.deviceid = XIAllMasterDevices; -memset(mask.mask, 0, 2); +memset(mask.mask, 0, mask.mask_len); XISetMask(mask.mask, XI_RawKeyPress); XISetMask(mask.mask, XI_RawKeyRelease); XISetMask(mask.mask, XI_RawButtonPress); -- 1.7.1 merged, thanks. Cheers, Peter ___ 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: driver/xf86-input-keyboard wants IDevPtr
On Mon, Nov 15, 2010 at 04:59:39PM -0500, Trevor Woerner wrote: Of the 10 input drivers of which build.sh is aware: driver/xf86-input-aiptek driver/xf86-input-evdev driver/xf86-input-joystick driver/xf86-input-vmmouse driver/xf86-input-acecad driver/xf86-input-keyboard driver/xf86-input-mouse driver/xf86-input-penmount driver/xf86-input-synaptics driver/xf86-input-void The following drivers fail to compile due to this same issue: driver/xf86-input-aiptek driver/xf86-input-joystick driver/xf86-input-acecad driver/xf86-input-keyboard driver/xf86-input-mouse driver/xf86-input-penmount driver/xf86-input-void In other words only the following successfully compile: driver/xf86-input-evdev driver/xf86-input-vmmouse driver/xf86-input-synaptics All from the same issue you mention. I had started trying to fix up the driver/xf86-input-aiptek driver to try to get it compiling again but ran into the issue that the semantics of InputDriverRec's PreInit function changed from returning a InputInfoPtr to returning a status. If it were simply a matter of search and replace with the appropriate ABI checks I could have handled it, but with the changing semantics I'm not so sure and would need more guidance. I've got patches ready for all but the penmount driver I think, just need to upstream them. IIRC the acecad patches are on the list waiting for some review lovin'. Cheers, Peter ___ 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: Why my touch screen can not work?
On Thu, Nov 18, 2010 at 09:28:47AM +0800, Leo wrote: Dear Peter: I attach my evtestxev log. it seems to work ok. But there's something intersting, I just repeat operation on the different place of touch screen. Evtest can distinguish the position, you can have a look at the log, the ABS coordinate keep changing, While XEV I run on my device, this test seems not as what we want, it can distinguish the BTN_PRESS BTN_RELEASE or motion, but the position never changed. what version of evdev are you running? have you tried git master and/or an older version of evdev? If it works, can you bisect to it, I don't see anything in the evtest stream that should make this device not work. I guess there's some place to transform the event as user want in Xorg. evtest may read from the /dev/input/event3 directly, it's ok. But XEV Which may depends on X11's transformation, so appears the different situation. Please give some hints, thanks [?] BTW: I can not open the LINK [?] http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Is there any other website ? no, I just wrote this up today and it seems to work here. Cheers, Peter 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Wed, Nov 17, 2010 at 09:34:49AM +0800, Leo wrote: I prepare to port Meego(Linux based) to my devkit8000, follow the porting guide http://wiki.meego.com/ARM/Meego_on_B...d_from_scratch http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch everything seems ok: show the home screen, launch the application, But there's problem about touch screen. Meego can not recognize my behavior. I'm not sure it's related with Xorg or driver. Here is my Xorg log: 59.837] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.837] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.841] (**) ADS7846 Touchscreen: Applying InputClass evdev touchscreen [ 59.842] (**) ADS7846 Touchscreen: always reports core events [ 59.842] (**) ADS7846 Touchscreen: Device: /dev/input/event3 [ 59.842] (--) ADS7846 Touchscreen: Found absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found x and y absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found absolute touchscreen [ 59.843] (II) ADS7846 Touchscreen: Configuring as touchscreen [ 59.843] (**) ADS7846 Touchscreen: YAxisMapping: buttons 4 and 5 [ 59.843] (**) ADS7846 Touchscreen: EmulateWheelButton: 4, EmulateWheelIner0 [ 59.845] (II) XINPUT: Adding extended input device ADS7846 Touchscreen () [ 59.851] (II) ADS7846 Touchscreen: initialized for absolute axes. [ 59.854] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.854] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.855] (**) ADS7846 Touchscreen: always reports core events [ 59.855] (**) ADS7846 Touchscreen: Device: /dev/input/mouse0 [ 59.855] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 59.856] (II) UnloadModule: evdev [ 59.856] (EE) PreInit returned NULL for ADS7846 Touchscreen [ 60.102] (NI) OMAPFBSaveScreen: Dim backlight? who has the experience about these kind of problem, pls talk to me! thanks very much does it work at all? do you see events come out of the device when you run evtest against it? as for the error message: http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Cheers, Peter ___ 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] xserver xf86PrintModeline(): print DisplayMode type bits.
I have to say that I'm not really sure of the reasoning behind this.
How does this really help? From reading modelines from different bug
reports over time, the most common issue seems to be not why is this
mode here but rather why is this supposedly valid mode being
rejected?
I wouldn't trust my opinion, since I haven't been around for too long.
You might want to ask one of the other regulars on the xorg-devel IRC.
type_bit flag origin
M_T_USERPREF U set by the Option PreferredMode
Can you make this a lowercase 'u'?
M_T_DRIVER e driver: EDID, flat panel native
M_T_USERDEF u configured zoom mode Ctrl+Alt+Keypad-{Plus,Minus}
Can you make this 'z' for zoom?
M_T_DEFAULT d VESA default
M_T_PREFERRED P driver preferred timing, also set by PreferredMode
Can you lowercase the 'p'? I ask all this because it's easier to read
when there's no confusing U and u for things.
M_T_BUILTIN b hardware fixed CRTC mode
Modeline 1600x1...@60x60.0 144.00 1600 1632 1792 1920 1200 1201 1204 1250
(75.0 kHz UP)
Modeline 1600x1200x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250
+hsync +vsync (75.0 kHz eP)
Modeline 1600x1...@50x50.0 120.00 1600 1628 1788 1920 1200 1201 1204 1250
(62.5 kHz)
What? Cryptic letters? No 'edid' or * for preferred or 'builtin'?
-xf86PrintModeline(int scrnIndex,DisplayModePtr mode)
+xf86PrintModeline(int scrnIndex, DisplayModePtr mode)
{
char tmp[256];
+ char tchar[] = UeudPb;
+ int tbit[] = { M_T_USERPREF, M_T_DRIVER, M_T_USERDEF,
+ M_T_DEFAULT, M_T_PREFERRED, M_T_BUILTIN };
+ char type[sizeof(tchar)+2];
+ int tlen = 0;
char *flags = xnfcalloc(1, 1);
+ if (mode-type) {
+ int i;
+
+ type[tlen++] = ' ';
+ for (i = 0; i sizeof(tchar); i++)
+ if (mode-type tbit[i])
+ type[tlen++] = tchar[i];
+ }
+ type[tlen++] = '\0';
Why not type[tlen]? tlen isn't going to be used again, so why increment it?
+
if (mode-HSkew) {
snprintf(tmp, 256, hskew %i, mode-HSkew);
add(flags, tmp);
@@ -318,12 +333,12 @@ #if 0
if (mode-Flags V_CLKDIV2) add(flags, vclk/2);
#endif
xf86DrvMsg(scrnIndex, X_INFO,
- Modeline \%s\x%.01f %6.2f %i %i %i %i %i %i %i %i%s
- (%.01f kHz)\n,
- mode-name, mode-VRefresh, mode-Clock/1000.,
mode-HDisplay,
- mode-HSyncStart, mode-HSyncEnd, mode-HTotal,
- mode-VDisplay, mode-VSyncStart, mode-VSyncEnd,
- mode-VTotal, flags, xf86ModeHSync(mode));
+ Modeline \%s\x%.01f %6.2f %i %i %i %i %i %i %i %i%s
+ (%.01f kHz%s)\n,
I'm probably being nitpicky at this point, but I can see this being
confusing if you just looked at this Wouldn't this result in things
like kHzEP?, until you look at 'type' and see that it's got a leading
space.
Why isn't there a space after the kHz, and the mode printed without a
leading space?
+ mode-name, mode-VRefresh, mode-Clock/1000.,
+ mode-HDisplay, mode-HSyncStart, mode-HSyncEnd, mode-HTotal,
+ mode-VDisplay, mode-VSyncStart, mode-VSyncEnd, mode-VTotal,
+ flags, xf86ModeHSync(mode), type);
free(flags);
}
#endif /* XORG_VERSION_CURRENT = 7.2.99.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
___
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 keyboard v2] Adjust to input ABI 12.
New PreInit prototype and a few other things.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Tested against pre and post ABI 12 xserver trees.
changes to v1:
- add missing semicolon
src/kbd.c | 80 +
1 files changed, 59 insertions(+), 21 deletions(-)
diff --git a/src/kbd.c b/src/kbd.c
index e0b7003..9c025ff 100644
--- a/src/kbd.c
+++ b/src/kbd.c
@@ -49,7 +49,11 @@
/* Used to know when the first DEVICE_ON after a DEVICE_INIT is called */
#define INITFLAG (1U 31)
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12
static InputInfoPtr KbdPreInit(InputDriverPtr drv, IDevPtr dev, int flags);
+#else
+static int KbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags);
+#endif
static int KbdProc(DeviceIntPtr device, int what);
static void KbdCtrl(DeviceIntPtr device, KeybdCtrl *ctrl);
static void KbdBell(int percent, DeviceIntPtr dev, pointer ctrl, int unused);
@@ -125,21 +129,52 @@ SetXkbOption(InputInfoPtr pInfo, char *name, char
**option)
}
}
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12
+static int
+NewKbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags);
+
static InputInfoPtr
KbdPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
{
InputInfoPtr pInfo;
-KbdDevPtr pKbd;
-MessageType from = X_DEFAULT;
-char *s;
if (!(pInfo = xf86AllocateInput(drv, 0)))
return NULL;
-/* Initialise the InputInfoRec. */
pInfo-name = dev-identifier;
-pInfo-type_name = XI_KEYBOARD;
pInfo-flags = XI86_KEYBOARD_CAPABLE;
+pInfo-conversion_proc = NULL;
+pInfo-reverse_conversion_proc = NULL;
+pInfo-private_flags = 0;
+pInfo-always_core_feedback = NULL;
+pInfo-conf_idev = dev;
+pInfo-close_proc = NULL;
+
+if (NewKbdPreInit(drv, pInfo, flags) == Success)
+{
+pInfo-flags |= XI86_CONFIGURED;
+return pInfo;
+}
+
+xf86DeleteInput(pInfo, 0);
+return NULL;
+}
+
+static int
+NewKbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags)
+#else
+static int
+KbdPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags)
+#endif
+{
+KbdDevPtr pKbd;
+MessageType from = X_DEFAULT;
+char *s;
+const char **defaults;
+int rc = Success;
+
+/* Initialise the InputInfoRec. */
+pInfo-type_name = XI_KEYBOARD;
pInfo-device_control = KbdProc;
/*
* We don't specify our own read_input function. We expect
@@ -147,33 +182,37 @@ KbdPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
*/
pInfo-read_input = NULL;
pInfo-control_proc = NULL;
-pInfo-close_proc = NULL;
pInfo-switch_mode = NULL;
-pInfo-conversion_proc = NULL;
-pInfo-reverse_conversion_proc = NULL;
pInfo-fd = -1;
pInfo-dev = NULL;
-pInfo-private_flags = 0;
-pInfo-always_core_feedback = NULL;
-pInfo-conf_idev = dev;
if (!xf86IsPc98())
-xf86CollectInputOptions(pInfo, kbdDefaults, NULL);
+defaults = kbdDefaults;
else
-xf86CollectInputOptions(pInfo, kbd98Defaults, NULL);
+defaults = kbd98Defaults;
+xf86CollectInputOptions(pInfo, kbdDefaults
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12
+, NULL
+#endif
+);
xf86ProcessCommonOptions(pInfo, pInfo-options);
-if (!(pKbd = calloc(sizeof(KbdDevRec), 1)))
-return pInfo;
+if (!(pKbd = calloc(sizeof(KbdDevRec), 1))) {
+rc = BadAlloc;
+goto out;
+}
pInfo-private = pKbd;
pKbd-PostEvent = PostKbdEvent;
-if (!xf86OSKbdPreInit(pInfo))
-return pInfo;
+if (!xf86OSKbdPreInit(pInfo)) {
+rc = BadAlloc;
+goto out;
+}
if (!pKbd-OpenKeyboard(pInfo)) {
-return pInfo;
+rc = BadMatch;
+goto out;
}
if ((s = xf86SetStrOption(pInfo-options, XLeds, NULL))) {
@@ -209,9 +248,8 @@ KbdPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
xf86Msg(from, %s: CustomKeycodes %s\n,
pInfo-name, pKbd-CustomKeycodes ? enabled : disabled);
- pInfo-flags |= XI86_CONFIGURED;
-
- return pInfo;
+out:
+ return rc;
}
static void
--
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 mouse v2] Use pInfo-options instead of conf-idev.
Because it doesn't really matter anyway, I think.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Reviewed-by: Chase Douglas chase.doug...@canonical.com
---
Stumbled across a bug before pushing when running against pre ABI 12.
Changes to v1:
- see xf86CollectInputOptions() handling in the src/mouse.c hunk
Chase, I left your Reviewed-by tag in there since it's the same patch except
for that line.
src/bsd_mouse.c |8
src/hurd_mouse.c |4 ++--
src/lnx_mouse.c |6 +++---
src/mouse.c |6 +-
src/sun_mouse.c | 20 +---
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/src/bsd_mouse.c b/src/bsd_mouse.c
index e288f38..94d4382 100644
--- a/src/bsd_mouse.c
+++ b/src/bsd_mouse.c
@@ -329,8 +329,8 @@ FindDevice(InputInfoPtr pInfo, const char *protocol, int
flags)
if (dev) {
/* Set the Device option. */
- pInfo-conf_idev-commonOptions =
- xf86AddNewOption(pInfo-conf_idev-commonOptions, Device, dev);
+ pInfo-options =
+ xf86AddNewOption(pInfo-options, Device, dev);
xf86Msg(X_INFO, %s: Setting Device option to \%s\\n,
pInfo-name, dev);
}
@@ -369,8 +369,8 @@ FindDevice(InputInfoPtr pInfo, const char *protocol, int
flags)
SYSCALL(fd = open(*pdev, O_RDWR | O_NONBLOCK));
if (fd != -1) {
/* Set the Device option. */
- pInfo-conf_idev-commonOptions =
- xf86AddNewOption(pInfo-conf_idev-commonOptions,
+ pInfo-options =
+ xf86AddNewOption(pInfo-options,
Device, *pdev);
xf86Msg(X_INFO, %s: found Device \%s\\n,
pInfo-name, *pdev);
diff --git a/src/hurd_mouse.c b/src/hurd_mouse.c
index 45b3cf2..e0ed126 100644
--- a/src/hurd_mouse.c
+++ b/src/hurd_mouse.c
@@ -183,8 +183,8 @@ FindDevice(InputInfoPtr pInfo, const char *protocol, int
flags)
return NULL;
close(fd);
-pInfo-conf_idev-commonOptions =
- xf86AddNewOption(pInfo-conf_idev-commonOptions, Device, path);
+pInfo-options =
+ xf86AddNewOption(pInfo-options, Device, path);
xf86Msg(X_INFO, %s: Setting Device option to \%s\\n, pInfo-name,
path);
diff --git a/src/lnx_mouse.c b/src/lnx_mouse.c
index 914b941..32b83b7 100644
--- a/src/lnx_mouse.c
+++ b/src/lnx_mouse.c
@@ -80,8 +80,8 @@ FindDevice(InputInfoPtr pInfo, const char *protocol, int
flags)
if (*pdev) {
close(fd);
/* Set the Device option. */
- pInfo-conf_idev-commonOptions =
- xf86AddNewOption(pInfo-conf_idev-commonOptions, Device, *pdev);
+ pInfo-options =
+ xf86AddNewOption(pInfo-options, Device, *pdev);
xf86Msg(X_INFO, %s: Setting Device option to \%s\\n,
pInfo-name, *pdev);
}
@@ -99,7 +99,7 @@ lnxMouseMagic(InputInfoPtr pInfo)
int i;
int proto = MOUSE_PROTO_UNKNOWN;
-dev = xf86SetStrOption(pInfo-conf_idev-commonOptions, Device, NULL);
+dev = xf86SetStrOption(pInfo-options, Device, NULL);
if (!dev) {
#ifdef DEBUG
ErrorF(xf86SetStrOption failed to return the device name\n);
diff --git a/src/mouse.c b/src/mouse.c
index fb9ccc8..e600474 100644
--- a/src/mouse.c
+++ b/src/mouse.c
@@ -923,7 +923,11 @@ MousePreInit(InputDriverPtr drv, IDevPtr dev, int flags)
pMse-autoProbe = FALSE;
/* Collect the options, and process the common options. */
-xf86CollectInputOptions(pInfo, pProto-defaults, NULL);
+/* need some special handling here. xf86CollectInputOptions will reset
+ * pInfo-options if the second argument is not-null. To re-merge the
+ * previously set arguments, pass the original pInfo-options in.
+ */
+xf86CollectInputOptions(pInfo, pProto-defaults, pInfo-options);
xf86ProcessCommonOptions(pInfo, pInfo-options);
/* Check if the device can be opened. */
diff --git a/src/sun_mouse.c b/src/sun_mouse.c
index 4749f88..95b45bc 100644
--- a/src/sun_mouse.c
+++ b/src/sun_mouse.c
@@ -259,8 +259,8 @@ vuidPreInit(InputInfoPtr pInfo, const char *protocol, int
flags)
if (buttons == 0) {
SYSCALL(i = ioctl(pInfo-fd, MSIOBUTTONS, buttons));
if (i == 0) {
- pInfo-conf_idev-commonOptions =
- xf86ReplaceIntOption(pInfo-conf_idev-commonOptions,
+ pInfo-options =
+ xf86ReplaceIntOption(pInfo-options,
Buttons, buttons);
xf86Msg(X_INFO, %s: Setting Buttons option to \%d\\n,
pInfo-name, buttons);
@@ -676,16 +676,14 @@ solarisMouseAutoProbe(InputInfoPtr pInfo, const char
**protocol,
/* Check to see if xorg.conf or HAL specified a device to use */
*device = xf86CheckStrOption(pInfo-options, Device, NULL);
if (*device == NULL) {
- *device = xf86CheckStrOption(pInfo-conf_idev-commonOptions,
-Device,
Re: [PATCH modular 2/3 (v3)] jhbuild: Support skipping packages on a per-architecture basis.
+# There might be better ways to detect the architecture. Patches welcome. The only thing I can think of would be the platform library. http://docs.python.org/library/platform.html. platform.machine is probably the way to do it. I'd bet it uses something like uname behind the scenes. But I'm okay with it. Reviewed-by: Jesse Adkins jesserayadk...@gmail.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
p690 needs to be removed.
It has a single commit to it, which adds a file called TEST which has the text 'TEST' inside of it. It's junk. ___ 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: [ANNOUNCE] xf86-video-glide 1.1.0
Guillem Jover wrote: Something else that's slightly annoying when doing autoreconf are the warnings due to invalid characters for the bug address in AC_INIT, specifically '?' and '=' in the bugzilla URL. autoconf 2.68 has fixed that bug: http://lists.gnu.org/archive/html/autotools-announce/2010-09/msg0.html http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=64000cf1f891b8c64b9ad12f7b0f06075ba403b7 -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: Why my touch screen can not work?
Sorry, forgot my attachment! 2010/11/18 Leo leo20090...@gmail.com Dear Peter: I attach my evtestxev log. it seems to work ok. But there's something intersting, I just repeat operation on the different place of touch screen. Evtest can distinguish the position, you can have a look at the log, the ABS coordinate keep changing, While XEV I run on my device, this test seems not as what we want, it can distinguish the BTN_PRESS BTN_RELEASE or motion, but the position never changed. I guess there's some place to transform the event as user want in Xorg. evtest may read from the /dev/input/event3 directly, it's ok. But XEV Which may depends on X11's transformation, so appears the different situation. Please give some hints, thanks [?] BTW: I can not open the LINK [?] http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Is there any other website ? 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Wed, Nov 17, 2010 at 09:34:49AM +0800, Leo wrote: I prepare to port Meego(Linux based) to my devkit8000, follow the porting guide http://wiki.meego.com/ARM/Meego_on_B...d_from_scratch http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch everything seems ok: show the home screen, launch the application, But there's problem about touch screen. Meego can not recognize my behavior. I'm not sure it's related with Xorg or driver. Here is my Xorg log: 59.837] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.837] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.841] (**) ADS7846 Touchscreen: Applying InputClass evdev touchscreen [ 59.842] (**) ADS7846 Touchscreen: always reports core events [ 59.842] (**) ADS7846 Touchscreen: Device: /dev/input/event3 [ 59.842] (--) ADS7846 Touchscreen: Found absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found x and y absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found absolute touchscreen [ 59.843] (II) ADS7846 Touchscreen: Configuring as touchscreen [ 59.843] (**) ADS7846 Touchscreen: YAxisMapping: buttons 4 and 5 [ 59.843] (**) ADS7846 Touchscreen: EmulateWheelButton: 4, EmulateWheelIner0 [ 59.845] (II) XINPUT: Adding extended input device ADS7846 Touchscreen () [ 59.851] (II) ADS7846 Touchscreen: initialized for absolute axes. [ 59.854] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.854] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.855] (**) ADS7846 Touchscreen: always reports core events [ 59.855] (**) ADS7846 Touchscreen: Device: /dev/input/mouse0 [ 59.855] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 59.856] (II) UnloadModule: evdev [ 59.856] (EE) PreInit returned NULL for ADS7846 Touchscreen [ 60.102] (NI) OMAPFBSaveScreen: Dim backlight? who has the experience about these kind of problem, pls talk to me! thanks very much does it work at all? do you see events come out of the device when you run evtest against it? as for the error message: http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Cheers, Peter 1E3.gif33A.gif-- Here is evtest output, I just download the source code and compile with arm-gcc Run on my device, that seems ok! Next part is my xev test. -- Input driver version is 1.0.0 Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0 Input device name: ADS7846 Touchscreen Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 330 (Touch) Event type 3 (Absolute) Event code 0 (X) Value 6153 Min0 Max 4095 Event code 1 (Y) Value 6152 Min0 Max 4095 Event code 24 (Pressure) Value 0 Min0 Max 255 Testing ... (interrupt to exit) Event: time 946685328.999538, type 1 (Key), code 330 (Touch), value 1 Event: time 946685328.999844, type 3 (Absolute), code 0 (X), value 6152 Event: time 946685328.66, type 3 (Absolute), code 1 (Y), value 6923 Event: time 946685329.57, type 3 (Absolute), code 24 (Pressure), value 254 Event: time 946685329.000149, -- Report Sync Event: time 946685329.094268, type 1 (Key), code 330 (Touch), value 0 Event: time 946685329.094299, type 3 (Absolute), code 24 (Pressure), value 0 Event: time 946685329.094329, -- Report Sync Event: time 946685336.278636, type 1 (Key), code 330 (Touch), value 1 Event: time 946685336.278880, type 3 (Absolute), code 0 (X), value 4867 Event: time 946685336.279002, type 3 (Absolute), code 1 (Y), value 7694 Event: time 946685336.279094, type 3 (Absolute), code 24 (Pressure), value 254 Event: time 946685336.279185, -- Report Sync Event: time 946685336.309272, type 1 (Key), code 330 (Touch),
Re: Why my touch screen can not work?
My evdev version is xf86-input-evdev-2.4.99.901. I still feel puzzled: 1. But why XEV can not get the right position?I test XEV in my ubuntu10.04, I can see the mouse's position changing. How does xserver's event flows? e.g: kernel-dev/input/eventX --read and analyzed by evdev--WM--app ??? 2. I google the my question, they say if we support touchscreen, we'd install tslib or evtouch, I dont know what's relation between these component, Can evdev handle the touch screen independently? or it may depends on the other such as tslib or anything else... 3. I can not access your blog, I dont know the information below meas what? Does it tell me, evdev has been removed, it can not work, or still handle the input events? [ 59.855] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 59.856] (II) UnloadModule: evdev [ 59.856] (EE) PreInit returned NULL for ADS7846 Touchscreen \ 4. can you paste your article, send to me? I try a lot , but still can not access. I very appreciate what you did! B.R Leo 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Thu, Nov 18, 2010 at 09:28:47AM +0800, Leo wrote: Dear Peter: I attach my evtestxev log. it seems to work ok. But there's something intersting, I just repeat operation on the different place of touch screen. Evtest can distinguish the position, you can have a look at the log, the ABS coordinate keep changing, While XEV I run on my device, this test seems not as what we want, it can distinguish the BTN_PRESS BTN_RELEASE or motion, but the position never changed. what version of evdev are you running? have you tried git master and/or an older version of evdev? If it works, can you bisect to it, I don't see anything in the evtest stream that should make this device not work. I guess there's some place to transform the event as user want in Xorg. evtest may read from the /dev/input/event3 directly, it's ok. But XEV Which may depends on X11's transformation, so appears the different situation. Please give some hints, thanks [?] BTW: I can not open the LINK [?] http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Is there any other website ? no, I just wrote this up today and it seems to work here. Cheers, Peter 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Wed, Nov 17, 2010 at 09:34:49AM +0800, Leo wrote: I prepare to port Meego(Linux based) to my devkit8000, follow the porting guide http://wiki.meego.com/ARM/Meego_on_B...d_from_scratch http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch everything seems ok: show the home screen, launch the application, But there's problem about touch screen. Meego can not recognize my behavior. I'm not sure it's related with Xorg or driver. Here is my Xorg log: 59.837] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.837] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.841] (**) ADS7846 Touchscreen: Applying InputClass evdev touchscreen [ 59.842] (**) ADS7846 Touchscreen: always reports core events [ 59.842] (**) ADS7846 Touchscreen: Device: /dev/input/event3 [ 59.842] (--) ADS7846 Touchscreen: Found absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found x and y absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found absolute touchscreen [ 59.843] (II) ADS7846 Touchscreen: Configuring as touchscreen [ 59.843] (**) ADS7846 Touchscreen: YAxisMapping: buttons 4 and 5 [ 59.843] (**) ADS7846 Touchscreen: EmulateWheelButton: 4, EmulateWheelIner0 [ 59.845] (II) XINPUT: Adding extended input device ADS7846 Touchscreen () [ 59.851] (II) ADS7846 Touchscreen: initialized for absolute axes. [ 59.854] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.854] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.855] (**) ADS7846 Touchscreen: always reports core events [ 59.855] (**) ADS7846 Touchscreen: Device: /dev/input/mouse0 [ 59.855] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 59.856] (II) UnloadModule: evdev [ 59.856] (EE) PreInit returned NULL for ADS7846 Touchscreen [ 60.102] (NI) OMAPFBSaveScreen: Dim backlight? who has the experience about these kind of problem, pls talk to me! thanks very much does it work at all? do you see events come out of the device when you run evtest against it? as for the error message: http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Cheers, Peter ___ 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: Why my touch screen can not work?
Dear Peter: I try the latest version later, thanks for all your reply. [?] B.R Leo 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Thu, Nov 18, 2010 at 10:40:45AM +0800, Leo wrote: My evdev version is xf86-input-evdev-2.4.99.901. I still feel puzzled: 1. But why XEV can not get the right position?I test XEV in my ubuntu10.04, I can see the mouse's position changing. How does xserver's event flows? e.g: kernel-dev/input/eventX --read and analyzed by evdev--WM--app ??? http://who-t.blogspot.com/2010/07/input-event-processing-in-x.html 2. I google the my question, they say if we support touchscreen, we'd install tslib or evtouch, I dont know what's relation between these component, Can evdev handle the touch screen independently? or it may depends on the other such as tslib or anything else... evdev will handle touchscreens and as I said, I don't really see an unusual event stream. that indicates that there may be a bug in the driver, or at least in the version you're running there. Have you tried running the latest git version? 3. I can not access your blog, I dont know the information below meas what? Does it tell me, evdev has been removed, it can not work, or still handle the input events? [ 59.855] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 59.856] (II) UnloadModule: evdev [ 59.856] (EE) PreInit returned NULL for ADS7846 Touchscreen \ 4. can you paste your article, send to me? I try a lot , but still can not access. I very appreciate what you did! the blog essentially says that you can ignore this warning, it's a misconfiguration that has no real effect. Cheers, Peter 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Thu, Nov 18, 2010 at 09:28:47AM +0800, Leo wrote: Dear Peter: I attach my evtestxev log. it seems to work ok. But there's something intersting, I just repeat operation on the different place of touch screen. Evtest can distinguish the position, you can have a look at the log, the ABS coordinate keep changing, While XEV I run on my device, this test seems not as what we want, it can distinguish the BTN_PRESS BTN_RELEASE or motion, but the position never changed. what version of evdev are you running? have you tried git master and/or an older version of evdev? If it works, can you bisect to it, I don't see anything in the evtest stream that should make this device not work. I guess there's some place to transform the event as user want in Xorg. evtest may read from the /dev/input/event3 directly, it's ok. But XEV Which may depends on X11's transformation, so appears the different situation. Please give some hints, thanks [?] BTW: I can not open the LINK [?] http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html Is there any other website ? no, I just wrote this up today and it seems to work here. Cheers, Peter 2010/11/18 Peter Hutterer peter.hutte...@who-t.net On Wed, Nov 17, 2010 at 09:34:49AM +0800, Leo wrote: I prepare to port Meego(Linux based) to my devkit8000, follow the porting guide http://wiki.meego.com/ARM/Meego_on_B...d_from_scratch http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch everything seems ok: show the home screen, launch the application, But there's problem about touch screen. Meego can not recognize my behavior. I'm not sure it's related with Xorg or driver. Here is my Xorg log: 59.837] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.837] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.841] (**) ADS7846 Touchscreen: Applying InputClass evdev touchscreen [ 59.842] (**) ADS7846 Touchscreen: always reports core events [ 59.842] (**) ADS7846 Touchscreen: Device: /dev/input/event3 [ 59.842] (--) ADS7846 Touchscreen: Found absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found x and y absolute axes [ 59.842] (--) ADS7846 Touchscreen: Found absolute touchscreen [ 59.843] (II) ADS7846 Touchscreen: Configuring as touchscreen [ 59.843] (**) ADS7846 Touchscreen: YAxisMapping: buttons 4 and 5 [ 59.843] (**) ADS7846 Touchscreen: EmulateWheelButton: 4, EmulateWheelIner0 [ 59.845] (II) XINPUT: Adding extended input device ADS7846 Touchscreen () [ 59.851] (II) ADS7846 Touchscreen: initialized for absolute axes. [ 59.854] (II) config/udev: Adding input device ADS7846 Touchscreen (/dev/i) [ 59.854] (**) ADS7846 Touchscreen: Applying InputClass default [ 59.855] (**) ADS7846 Touchscreen: always reports core events [ 59.855] (**) ADS7846 Touchscreen: Device: /dev/input/mouse0 [ 59.855] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
