Re: Driver Question - evdev
Je == Johnson, Je je.john...@lmco.com writes: Hi, Je I?ve got a Barco monitor that I?m using the touch screen Je configuration. I?ve got a couple of questions concerning the Je configuration: Out of interest, what monitor is this? Je 1. The ?xorg.conf? was setup to use the ?evdev? driver and it?s Je working. But I?m not sure how the startup of ?X? is calling this Je driver? I do not see with ?lsmod? that the driver is loaded? Don't confuse the kernel evdev interface (/dev/input/eventX) with the X evdev input driver. Je 2. When I disable/enable or turn off the monitor the Je ?/dev/input/event#? changes and I have to update the xorg.conf Je file and restart X. Any other way to handle these changing events? Yes, if you unplug (or turn off) the monitor the touchscreen gets disconnected. Like Adam says, if this is a singlehead setup then you can match on product/vendor id. For multihead we don't have any really good options yet (see recent discussion on xorg-devel). -- Bye, Peter Korsgaard ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: getting device path or sysfs name of input device
Tias == Tias t...@ulyssis.org writes: Hi, Tias So my question is: Tias - how can I ask the Xserver for the sysfs name of a device Tias (having its XID) Tias - equivalently: how can I ask for the input device path (I can Tias then use udevadm to find the sysfs name) I recently sent a patch to the server to expose the device path as an xinput property: http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/7730/ And one to evdev to expose the output of the EVIOCGPHYS ioctl (useful as unique key, other info can be looked up by using it as a key in /proc/bus/input/devices: http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/7729 -- Bye, Peter Korsgaard ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] evdev: add 3x3 transformation matrix xinput property for multi-head handling
For absolute input devices (E.G. touchscreens) in multi-head setups, we
need a way to bind the device to an randr output. This adds the
infrastructure to evdev to allow us to do so.
The X server scales input coordinates to the dimensions of the shared
(total) frame buffer, so to restrict motion to an output we need to
scale/rotate/translate device coordinates to a subset of the frame buffer
before passing them on to the X server.
This is done here using a 3x3 transformation matrix, which is applied to
the device coordinates using homogeneous coordinates, E.G.:
[ c0 c1 c2 ] [ x ]
[ c3 c4 c5 ] * [ y ]
[ c6 c7 c8 ] * [ 1 ]
Notice: As input devices have varying input ranges, the coordinates are first
scaled to the [0..1] range for generality, and afterwards scaled back up.
E.G. for a dual head setup (using same resolution) next to each other, you
would want to scale the X coordinates of touchscreen connected to the
both heads by 50%, and translate (offset) the coordinates of the rightmost
head by 50%, or in matrix form:
left: right:
[ 0.5 0 0 ] [ 0.5 0 0.5 ]
[ 0 1 0 ] [ 0 1 0 ]
[ 0 0 1 ] [ 0 0 0 ]
Which can be done using xinput:
xinput set-prop left --type=float Evdev Coordinate Transformation Matrix \
0.5 0 0 0 1 0 0 0 1
xinput set-prop right --type=float Evdev Coordinate Transformation Matrix \
0.5 0 0.5 0 1 0 0 0 1
This is general enough to replace the various tweaks we have in evdev
(InvertX/Y, Calibration, SwapAxes), but I have left them for now.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
include/evdev-properties.h |7 ++
man/evdev.man | 13
src/evdev.c| 138 +++-
src/evdev.h|2 +
4 files changed, 159 insertions(+), 1 deletions(-)
diff --git a/include/evdev-properties.h b/include/evdev-properties.h
index 7df2876..7417a5b 100644
--- a/include/evdev-properties.h
+++ b/include/evdev-properties.h
@@ -66,4 +66,11 @@
/* BOOL */
#define EVDEV_PROP_SWAP_AXES Evdev Axes Swap
+/* Coordinate transformation matrix */
+/* FLOAT, 9 values in row-major order, coordinates in 0..1 range: */
+/* [c0 c1 c2] [x] */
+/* [c5 c4 c5] * [y] */
+/* [c6 c7 c8] [1] */
+#define EVDEV_PROP_TRANSFORM Evdev Coordinate Transformation Matrix
+
#endif
diff --git a/man/evdev.man b/man/evdev.man
index 49ab12c..21d7aa4 100644
--- a/man/evdev.man
+++ b/man/evdev.man
@@ -161,6 +161,15 @@ originally reported by the kernel (e.g. touchscreens). The
scaling to the
custom coordinate system is done in-driver and the X server is unaware of
the transformation. Property: Evdev Axis Calibration.
.TP 7
+.BI Option \*qTransformationMatrix\*q \*q c0 c1 c2 c3 c4 c5 c6 c7 c8 \*q
+Applies the 3x3 transformation matrix defined by c0..c8 in row-major
+order to the device coordinates before passing them on to the X
+server. The coefficients are floating point values, and the
+coordinates are scaled to the 0..1 range before transformed. This
+feature can be used to restrict absolute devices (e.g. touchscreens)
+to specific outputs in multi-head setups. Property: Evdev Coordinate
+Transformation Matrix.
+.TP 7
.B Option \*qMode\*q \*qRelative\*q\fP|\fP\*qAbsolute\*q
Sets the mode of the device if device has absolute axes.
The default value for touchpads is relative, for other absolute.
@@ -196,6 +205,10 @@ driver.
4 32-bit values, order min-x, max-x, min-y, max-y or 0 values to disable
in-driver axis calibration.
.TP 7
+.BI Evdev Coordinate Transformation Matrix
+9 floating point values, defining the coordinate transformation matrix
+in row-major order.
+.TP 7
.BI Evdev Axis Inversion
2 boolean values (8 bit, 0 or 1), order X, Y. 1 inverts the axis.
.TP 7
diff --git a/src/evdev.c b/src/evdev.c
index 0678edf..c21ba0d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -32,6 +32,8 @@
#endif
#include xorg-server.h
+#include math.h
+
#include X11/keysym.h
#include X11/extensions/XI.h
@@ -119,6 +121,7 @@ static Atom prop_calibration = 0;
static Atom prop_swap = 0;
static Atom prop_axis_label = 0;
static Atom prop_btn_label = 0;
+static Atom prop_transform = 0;
#endif
/* All devices the evdev driver has allocated and knows about.
@@ -347,6 +350,35 @@ EvdevQueueButtonClicks(InputInfoPtr pInfo, int button, int
count)
}
}
+static int
+EvdevClip(InputInfoPtr pInfo, float f, int axis)
+{
+EvdevPtr pEvdev = pInfo-private;
+int v;
+
+v = lroundf(f);
+
+if (v pEvdev-absinfo[axis].maximum)
+v = pEvdev-absinfo[axis].maximum;
+else if (v pEvdev-absinfo[axis].minimum)
+v = pEvdev-absinfo[axis].minimum;
+
+return v;
+}
+
+static void
+EvdevTransformAbsolute(InputInfoPtr pInfo, int v[MAX_VALUATORS])
+{
+EvdevPtr pEvdev = pInfo-private;
+float x, y, *t = pEvdev-transform;
+
+x = t[0]*v[0] + t[1]*v[1] + t[2];
+y = t[3]*v[0] + t[4]*v[1] + t[5];
+
+v[0] = EvdevClip(pInfo, x, ABS_X);
+v[1] = EvdevClip(pInfo, y
Re: touchscreens in multiscreen setups
Keith == Keith Packard kei...@keithp.com writes: Old thread, but I unfortunately couldn't work on it before now - The issue is about binding touchscreen events to a randr output Original thread is here: http://thread.gmane.org/gmane.comp.freedesktop.xorg/40071 Keith It would need to be tied to an output, not a crtc. And, what Keith we'd need to do is let the input device know which output it is Keith associated with, and then provide a helper function to translate Keith coordinates relative to that output. That could deal with output Keith transforms as well. I don't see how xf86XInputSetScreen has much Keith to do with this though, other than having that be used as a hint Keith to go lookup the output property in the config file? So just to make sure I get it all (this is the first time I hack on X) - I'll need to: - Add an XInput property to evdev to assign a screen number / randr output name to a device - Add an API to forward this info to the server (xf86XInputSetOutput?) - Translate the raw coordinates in GetPointerEvents() if that flag is set (POINTER_OUTPUT?), and optionally ignore event if output is disabled. Correct? - randr notification. with screens being added and removed, there's no driver interface that I know of that input drivers can use to get notified about this stuff. Obviously the simple thing to do would be to handle this stuff in the server - if a screen goes away the device defaults back to whatever screen is still there. this would be without the driver knowing though - not ideal. Keith It seems like xf86PostMotionEventP could deal with this internally, Keith by having the device know which output it was associated with and having Keith that code deal with finding the transform and doing the right Keith thing. Input devices not associated with an output would not be Keith transformed, and input devices associated with disabled outputs could Keith either be ignored (?) or have their output untransformed. -- Bye, Peter Korsgaard ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: touchscreens in multiscreen setups
Peter == Peter Hutterer peter.hutte...@who-t.net writes: Hi, Peter I don't think either is a particularly large undertaking, so Peter it's worth tackling if you have the hardware and the test setups Peter to actually do it. Thanks - I do. I'm going on holidays from Tuesday on, but I'm back at work where I have access to multiple NW (and other) touchscreens the first week of January. -- Bye, Peter Korsgaard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: touchscreens in multiscreen setups
Keith == Keith Packard kei...@keithp.com writes: Hi, Keith I'd say tablets and touch screens should report raw device coordinates Keith and let the X server transform them as appropriate. It'd be really cool Keith if we could make all absolute devices report position in floating point Keith using a [0..1] range on each axis. I think. The X server would then Keith transform those as appropriate. I think all that would take is a new Keith PostMotionEvent function that took doubles instead of ints; fixed Keith drivers would use that, broken drivers would continue to report Keith coordinates as they do today. Does this also include calibration? Some touchscreens apply calibration parameters in firmware (like nextwindow), so the coordinates you receive are already calibrated, whereas others provide raw coordinates and we need to do calibration in software. It would be nice to have generic calibration support in evdev, instead of doing this different for each touchscreen. Related to this is how/where to store calibration parameters. Notice that it sometimes is needed to recalibrate at runtime (E.G. on resolution change if you don't have your screen set for scale to fullscreen / don't keep aspect). -- Bye, Peter Korsgaard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SHA1 implementations
Julien == Julien Cristau jcris...@debian.org writes: Hi, Julien On Fri, 2009-04-03 at 07:55 -0700, Alan Coopersmith wrote: I'd also rather see the Sha1 helper function moved to a file under the os dir and shared by both render/glyph.c this code instead of duplicating the code here and giving people two places to make the same updates when adding new sha1 library implementations. Julien Because of openssl's license being kind of crazy, and Julien libgnutls being part of debian's base install, I'm Julien considering switching our builds to libgcrypt. Would a patch Julien to do that[0] be acceptable upstream? Wouldn't it be a lot simpler to just add the libmd implementation in the server and be done with it? -- Bye, Peter Korsgaard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] libFS: use memmove instead of bcopy
bcopy is marked as legacy in SuSv3 and not available in the default
configuration of uClibc. Replace with memmove proposed by SuSv3.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
src/FSOpenServ.c |2 +-
src/FSlibInt.c |2 +-
src/FSlibint.h |4 ++--
src/FSlibos.h|2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
Index: libFS-1.0.0/src/FSOpenServ.c
===
--- libFS-1.0.0.orig/src/FSOpenServ.c
+++ libFS-1.0.0/src/FSOpenServ.c
@@ -197,7 +197,7 @@
errno = ENOMEM;
return (FSServer *) 0;
}
- bcopy(ad, alts[i].name, altlen);
+ memmove(alts[i].name, ad, altlen);
alts[i].name[altlen] = '\0';
ad += altlen + ((4 - (altlen + 2)) 3);
}
Index: libFS-1.0.0/src/FSlibInt.c
===
--- libFS-1.0.0.orig/src/FSlibInt.c
+++ libFS-1.0.0/src/FSlibInt.c
@@ -1127,7 +1127,7 @@
longlen;
{
if (svr-bufptr + (len) = svr-bufmax) {
- bcopy(data, svr-bufptr, (int) len);
+ memmove(svr-bufptr, data, (int) len);
svr-bufptr += ((len) + 3) ~3;
} else {
_FSSend(svr, data, len);
Index: libFS-1.0.0/src/FSlibint.h
===
--- libFS-1.0.0.orig/src/FSlibint.h
+++ libFS-1.0.0/src/FSlibint.h
@@ -285,7 +285,7 @@
#else
#define Data(svr, data, len) \
if (svr-bufptr + (len) = svr-bufmax) {\
- bcopy(data, svr-bufptr, (int)len);\
+ memmove(svr-bufptr, data, (int)len); \
svr-bufptr += ((len) + 3) ~3;\
} else\
_FSSend(svr, data, len)
@@ -337,7 +337,7 @@
#define STARTITERATE(tpvar,type,start,endcond,decr) \
{ register char *cpvar; \
for (cpvar = (char *) start; endcond; cpvar = NEXTPTR(cpvar,type), decr) { \
-type dummy; bcopy (cpvar, (char *) dummy, SIZEOF(type)); \
+type dummy; memmove ((char *) dummy, cpvar, SIZEOF(type));
\
tpvar = (type *) cpvar;
#define ENDITERATE }}
Index: libFS-1.0.0/src/FSlibos.h
===
--- libFS-1.0.0.orig/src/FSlibos.h
+++ libFS-1.0.0/src/FSlibos.h
@@ -228,7 +228,7 @@
#endif
#if (MSKCNT4)
-#define COPYBITS(src, dst) bcopy((caddr_t) src, (caddr_t) dst, sizeof(FdSet))
+#define COPYBITS(src, dst) memmove((caddr_t) dst, (caddr_t) src, sizeof(FdSet))
#define CLEARBITS(buf) bzero((caddr_t) buf, sizeof(FdSet))
#define MASKANDSETBITS(dst, b1, b2) \
{ int cri;\
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
