Re: [PATCH] evdev: Support the Calibration string option.
2009/11/19 Peter Hutterer peter.hutte...@who-t.net: i don't actually know how evtouch works internally, last time I tried it didn't build against 1.7 at which point I lost interest. It doesn't seem to be very actively maintained (unless google hides the active upstream from me). When I looked into the touchscreen situation sometime back, I arrived at the conclusion that 'evtouch' is being maintained (to the extend that it compiles) by the Debian X hackers. No development seems to be going on. I don't know how many features evtouch provides aside from dejittering and the right-click emulation (both of which would be perfectly appropriate for evdev btw). I don't work with touchscreens any more (change of job), so I can't help out here. But it did want to mention that the 'evdev' driver is really easy to read and modify, so Tias, if Peter is willing to accept these features in 'evdev', then I would really recommend that you port them from 'evtouch' to 'evdev'. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: generic touchscreen calibration
Hi, 2009/9/10 Tias t...@ulyssis.org: In the end, I had to hack up the ancient tkxinput because it was the only device independent calibrator (it uses Xinput to read the coordinates). On the other hand, I was impressed by the simplicity of the calibrator that Soren Hauberg sent to this list in july (thread titled 'Evdev touchscreen calibration?'), although it was written for usbtouchscreen driven devices specifically. I figured that a generic calibration program should be device independent when reading calibration data, and device dependent in how to use the data. I've adapted Soren's calibrator to do exactly this: it reads the current calibration from Xinput. When the usbtouchscreen driver is used, it dynamically changes the calibration. Otherwise it prints the new calibration data in xorg.conf format on stdout. Other actions would be possible too, like rewriting the xorg.conf directly, maybe even use some new evdev/Xinput2 goodness ? It's been quite a while since I was working on this (I changed job, so I never got to finish this), so my comments might not actually be true. First, I'd like to add that I'm glad you're spending time on resurecting my old code. Thanks :-) Second, part of this code was added before the 'evdev' X11 driver got support for touchscreens. This driver allows you to set the calibration parameters at run-time without making changes to xorg.conf (hence no restart of X). I think the calibration tool should use this instead of working with xorg.conf. Third, the code that interacts with the 'usbtouchscreen' kernel module should probably be dropped. It's tied too much to some specific hardware. Since the parameters can just be handled by the 'evdev' X11 driver, I don't think kernel interaction is needed anymore. Let me know if you need anything from me, Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Evdev touchscreen calibration?
2009/7/22 Florian Echtler f...@butterbrot.org:
I've recently written an input event driver for a touchscreen, and it's
working out-of-the box with the evdev driver. However, the scaling is a
bit off, so I'd like to do a four-point calibration and set the Evdev
Axis Calibration property accordingly. Is there a tool which does that?
I've only found ts_calibrate so far, which is just for framebuffer
devices.
I wrote some code a while back that should compute the calibration
parameters, and it's just running inside X (I'm attaching the code).
It doesn't actually set the parameters as that wasn't supported at the
time, but you should be able to do this in run-time these days.
Søren
/*
* Copyright © 2008 Soren Hauberg
*
* Permission to use, copy, modify, distribute, and sell this software
* and its documentation for any purpose is hereby granted without
* fee, provided that the above copyright notice appear in all copies
* and that both that copyright notice and this permission notice
* appear in supporting documentation, and that the name of Red Hat
* not be used in advertising or publicity pertaining to distribution
* of the software without specific, written prior permission. Red
* Hat makes no representations about the suitability of this software
* for any purpose. It is provided as is without express or implied
* warranty.
*
* THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
* NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
* OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
* Authors:
* Soren Hauberg (haub...@gmail.com)
*/
/*
* This program performs calibration of a touchscreen that uses the 'usbtouchscreen'
* Linux kernel module. A calibration consists of finding the following parameters:
*
* 'flip_x'
* a boolean parameter that determines if the x-coordinate should be flipped.
*
* 'flip_y'
* same as 'flip_x' except for the y-coordinate.
*
* 'swap_xy'
* a boolean parameter that determines if the x and y-coordinates should
* be swapped.
*
* 'min_x', 'max_x', 'min_y', and 'max_y'
* the minimum and maximum x and y values that the screen can report. In principle
* we could get these parameters by letting the user press the corners of the
* screen. In practice this doesn't work, because the screen doesn't always have
* sensors at the corners. So, what we do is we ask the user to press points that
* have been pushed a bit closer to the center, and then we extrapolate the
* parameters.
*/
#include cstring
#include gtkmm/main.h
#include gtkmm/window.h
#include gtkmm/drawingarea.h
#include cairomm/context.h
/* Number of points the user should click */
const int num_points = 4;
/* Number of blocks. We partition we screen into 'num_blocks' x 'num_blocks'
* rectangles of equal size. We then ask the user to press points that are
* located at the corner closes to the center of the four blocks in the corners
* of the screen. The following ascii art illustrates the situation. We partition
* the screen into 8 blocks in each direction. We then let the user press the
* points marked with 'O'.
*
* +--+--+--+--+--+--+--+--+
* | | | | | | | | |
* +--O--+--+--+--+--+--O--+
* | | | | | | | | |
* +--+--+--+--+--+--+--+--+
* | | | | | | | | |
* +--+--+--+--+--+--+--+--+
* | | | | | | | | |
* +--+--+--+--+--+--+--+--+
* | | | | | | | | |
* +--+--+--+--+--+--+--+--+
* | | | | | | | | |
* +--+--+--+--+--+--+--+--+
* | | | | | | | | |
* +--O--+--+--+--+--+--O--+
* | | | | | | | | |
* +--+--+--+--+--+--+--+--+
*/
const int num_blocks = 8;
/* Names of the points */
enum {
UL = 0, /* Upper-left */
UR = 1, /* Upper-right */
LL = 2, /* Lower-left */
LR = 3 /* Lower-right */
};
/* Output ranges. The final output will be scaled to [0, range_x] x [0, range_y] */
const int range_x = 1023;
const int range_y = 1023;
/* The file to which the calibration parameters are saved. (XXX: is this distribution dependend?) */
const char *modprobe_conf_local = /etc/modprobe.conf.local;
/* Prefix to the kernel path where we can set the parameters */
const char *module_prefix = /sys/module/usbtouchscreen/parameters;
/* Names of kernel parameters */
const char *p_range_x = range_x;
const char *p_range_y = range_y;
const char *p_min_x = min_x;
const char *p_min_y = min_y;
const char *p_max_x = max_x;
const char *p_max_y = max_y;
const char *p_transform_xy = transform_xy;
const char *p_flip_x = flip_x;
const char *p_flip_y = flip_y;
const char *p_swap_xy = swap_xy;
/* Threshold to keep the same point from
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Well, the issue is precision which is affected by double-scaling (we have an integer intermediary scale). You could also tackle that by having the imed scale large (1024). Just a quick thought: double-scaling means we transform one coordinate from [a, b] to [c, d] in the driver, and then from [c, d] to [e, f] in the server, right? Here [a, b] is determined by the hardware. What if we choose [c, d] equal to [e, f] ? Then the scaling in the server would be from [e, f] to [e, f] i.e. a unit scaling, which I assume doesn't affect the precision (if it does, then we could let the server check if the scaling is a unit-scaling, and only perform the actual scaling if it is not). Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: 2008/10/24 Peter Hutterer [EMAIL PROTECTED]: Hmm, yeah then I don't see an alternative to double scaling. But, hey, as long as it only happens on touch screens then I think it'll be okay, as it doesn't happen on ordinary devices. May may want to try if you can avoid double-scaling for non-runtime calibrated devices. E.g. if calibration data from HAL/xorg.conf is OK, you can put it in the axis struct and only double-scale when runtime calibration data is different. But that's probably harder also. I assume performance really isn't an issue here. I'd say the main issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Well, the issue is precision which is affected by double-scaling (we have an integer intermediary scale). You could also tackle that by having the imed scale large (1024). Precision! Ah yes, I hadn't thought about that. I'm used to using a finger with touch screens, so precision isn't really a term that's been in my mind. Thanks for pointing it out. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/24 Peter Hutterer [EMAIL PROTECTED]: it can be combined, if you specify the correct min/max range in the config (or you let it get picked up from the kernel). Then the driver doesn't need scaling, the server does it. For calibration, that doesn't work. Or to be more precise, it only works if you restart the server with the calibrated values. Otherwise, you need a separate (duplicate) scaling mechanism in the driver. Hmm, yeah then I don't see an alternative to double scaling. But, hey, as long as it only happens on touch screens then I think it'll be okay, as it doesn't happen on ordinary devices. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/10/7 Peter Hutterer [EMAIL PROTECTED]: Did you actually apply these two patches? They don't appear when I checkout git, but perhaps I'm looking at the wrong branch or something. no, not yet. You said you're going to get some more face-time with the touchscreen so I was hoping you'd give me some testing feedback. Okay, just wasn't sure if I missed anything. I had a little time to test today, and things didn't work that well for me. I tried using the parameters (min_x, max_x, ...) that worked with my original patches, and evtouch, and they did not provide a good calibration. I wasn't able to track down the problem, so I don't really know what to report. I'm guessing that the problem is that both evtouch and my suggested changes scaled the output to [0, 1023] x [0, 1023], which isn't what happens in the current code path. But as I said, I wasn't able to track down the problem in the short amount of time I had. Hopefully, I'll get more time with the touch screen in the near future, but I'm not sure when. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/10/1 Peter Hutterer [EMAIL PROTECTED]: Ok, I took your patches, split them up and fiddled with them a bit. Great, Thanks! I'm hoping to get an hour or so with the touch screen on friday. Then I'll test, to make sure things are working. Also, I hope to borrow a different touch screen from my cousin, such that I can test on different hardware. Thanks, Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
2008/10/1 Clemens Kirchgatterer [EMAIL PROTECTED]: Everybody: does anybody have any thought on where I should host my calibration code? isn't there something in tslib already? I've found two calibration programs online. One came without a license, making it non-free software, and the other one had a non-so-nice gui, where you had to move your stylus all the way up the corners of the screen (this one I couldn't present to a custumor). These programs seems to have the problem that they require direct access to the touchscreen device, which means X can't have access to it (at least not when using evdev). Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Peter Hutterer [EMAIL PROTECTED]: evdev already has the code for device properties in e.g. draglock.c. Best to just check it but maybe wait a day or so, I have changes in the pipe that restructure the use of DP in evdev. The API is the same, but the handler registration is a bit different. So, I'm looking into this code at the moment. First question: does this require an X server from git? I'm using what's in Ubuntu Intripid, which should be v. 7.4. Just to figure out the basics of the 'xinput' tool, I tried to set the Middle Button Timeout of my external usb mouse, as explained in http://who-t.blogspot.com/2008/07/input-device-properties.html. I get: $ xinput --list-props Logitech USB-PS/2 Optical Mouse Device 'Logitech USB-PS/2 Optical Mouse': X Error of failed request: BadDevice, invalid or uninitialized input device Major opcode of failed request: 146 (XInputExtension) Minor opcode of failed request: 37 () Serial number of failed request: 13 Current serial number in output stream: 13 Does this mean I need a newer server? Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
Okay, here's my latest attempt at a patch. I've renamed flip_[x|y]
to invert_[x|y] and moved them into EvdevRec, I've removed
swap_xy, and I've moved the reading of parameters to PreInit.
I hope that's what you wanted. If not let me know. I'm hoping to have
access to the touch screen for an hour or two on friday, so I can do a
bit more testing/development at that time.
Thanks,
Søren
evdev.c.patch7
Description: Binary data
evdev.h.patch2
Description: Binary data
Makefile.am.patch0
Description: Binary data
/*
* Copyright © 2008 Soren Hauberg
*
* Permission to use, copy, modify, distribute, and sell this software
* and its documentation for any purpose is hereby granted without
* fee, provided that the above copyright notice appear in all copies
* and that both that copyright notice and this permission notice
* appear in supporting documentation, and that the name of Red Hat
* not be used in advertising or publicity pertaining to distribution
* of the software without specific, written prior permission. Red
* Hat makes no representations about the suitability of this software
* for any purpose. It is provided as is without express or implied
* warranty.
*
* THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
* NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
* OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
* Authors:
* Soren Hauberg ([EMAIL PROTECTED])
*/
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include xf86.h
#include xf86Xinput.h
#include X11/Xatom.h
#include exevents.h
#include evdev-properties.h
#include evdev.h
#define TRANSFORM(X, MIN_X, DELTA_X, RANGE_X) \
(DELTA_X == 0) ? X : ((RANGE_X * (X - MIN_X))/DELTA_X)
int EvdevTransformTouchX(EvdevPtr pEvdev, int value)
{
int abs_x, delta;
delta = pEvdev-touchscreen.max_x - pEvdev-touchscreen.min_x;
abs_x = TRANSFORM(value, pEvdev-touchscreen.min_x, delta, pEvdev-max_x);
return abs_x;
}
int EvdevTransformTouchY(EvdevPtr pEvdev, int value)
{
int abs_y, delta;
delta = pEvdev-touchscreen.max_y - pEvdev-touchscreen.min_y;
abs_y = TRANSFORM(value, pEvdev-touchscreen.min_y, delta, pEvdev-max_y);
return abs_y;
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Does touchpads have buttons?
Hi, I'm trying to differentiate touchpads from touchscreens in the evdev driver. Both types of devices has absolute axis, and emit the BTN_TOUCH signal. So, I need something else to tell them apart. Unfortunately, I don't have access to a touchpad (the only one I have is broken), so I can't figure out if such a device has other interesting properties. So, my question is: does touchpads have buttons, i.e. do they emit BTN_LEFT? Touchscreens don't (at least the ones using the 'usbtouchscreen' kernel module doesn't), so I might be able to use this as a differentiator. Thanks, Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Simon Thum [EMAIL PROTECTED]:
Søren Hauberg wrote:
Ahh, I (think I) see. The attached patch should handle this. It also
adds support for clicking the screen, and for my setup it works quite
I meant this:
case EV_ABS:
+abs = 1;
switch (ev.code) {
case ABS_X:
- pEvdev-abs_x = value;
- abs = 1;
you're assigning abs = 1 even if none of the absolute axes the device
advertises has a meaning to the driver. Given you later rely on it, that's
going to bust someone. Or is that intentional?
Ohh, that? That's just me being stupid :-) I've changed it back to the
way it was. This stuff is new to me, so I'm doing this by trial and
error, to get to know the system.
use device properties (that's what I've been told they're called) to
set these parameters, how would I go about doing that?
Look at EvdevInitProperties(). Touchscreen-specifics should be only
available on
touchscreens, of course.
This stuff seems to only be in git. It's not in any releases, right?
Regarding BTN_TOUCH: If you're getting a range here, you're better off with
a hysteresis to decide a button press/release. Synaptics does that, for
example.
I don't quite understand (to me 'hysteresis' is part of the Canny edge
detector in image processing -- I have no idea what it means here).
The information I seem to get from the kernel is (BTN_TOUCH, 1) when
the stylus is pressed to the screen, and (BTN_TOUCH, 0) when the
stylus is removed. When I move the stylus around (when its pressed
onto the screen), I don't get any BTN_TOUCH's.
Søren
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Søren Hauberg [EMAIL PROTECTED]: Or - even better, you hook into the default case of the switch statement for BTN_TOUCH and let the already existing code handle buttons, draglock, etc. (right now you're missing out on this). I tried only to break from the switch statement if we're not using a touch screen. That way, BTN_TOUCH should be handled by the default case if we're on a touch screen. This, however, seemed to kill the X server. I haven't had the time to debug it. Just a quick follow-up. I can actually make this work, by setting ev.code = BTN_LEFT. This is fine with me, as I think a touch should be treated like a left button press. However, it might be worth figuring out why the X server dies when the default case has to handle BTN_TOUCH. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Don't know how to use device
Hi All,
In an effort to be able to hack on the latest evdev driver I thought
I'd update to the latest Ubuntu beta, to get a system that supports
the latest X. I have the problem that my touchscreen is not recognized
by X at startup. In /var/log/Xorg.0.log I see the following
(II) Loading /usr/lib/xorg/modules/input//evdev_drv.so
(II) Module evdev: vendor=X.Org Foundation
compiled for 1.5.0, module version = 2.0.99
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.1
(**) TSC-10 DM TSC-10 DM: always reports core events
(**) TSC-10 DM TSC-10 DM: Device: /dev/input/event6
(II) TSC-10 DM TSC-10 DM: Found x and y absolute axes
(II) TSC-10 DM TSC-10 DM: Found absolute touchpad
(WW) TSC-10 DM TSC-10 DM: Don't know how to use device
(II) UnloadModule: evdev
(EE) PreInit returned NULL for TSC-10 DM TSC-10 DM
(EE) config/hal: NewInputDeviceRequest failed
This hotplug stuff is quite new to me, so I don't really know how to
debug this. Any thoughts? I can mention that 'hal-device' contains the
following:
31: udi = '/org/freedesktop/Hal/devices/usb_device_afa_3e8_noserial_if0_logicald
ev_input'
input.product = 'TSC-10 DM TSC-10 DM' (string)
button.has_state = false (bool)
linux.device_file = '/dev/input/event6' (string)
input.x11_driver = 'evdev' (string)
linux.sysfs_path = '/sys/class/input/input6/event6' (string)
input.originating_device =
'/org/freedesktop/Hal/devices/usb_device_afa_3e8_noserial_if0'
(string)
info.subsystem = 'input' (string)
info.parent =
'/org/freedesktop/Hal/devices/usb_device_afa_3e8_noserial_if0'
(string)
info.product = 'TSC-10 DM TSC-10 DM' (string)
info.addons.singleton = { 'hald-addon-input' } (string list)
info.udi =
'/org/freedesktop/Hal/devices/usb_device_afa_3e8_noserial_if0_logicaldev_input'
(string)
info.category = 'input' (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'input' (string)
info.capabilities = { 'input', 'button', 'input.mouse' } (string list)
input.device = '/dev/input/event6' (string)
Thanks,
Søren
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Don't know how to use device
2008/9/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: 2008/9/26 Simon Thum [EMAIL PROTECTED]: Thanks, I've played a bit around with it, and the attached patch at least makes the touchscreen recognisable. I doubt this is the right thing to do, but it's enough to give me a start. Looks OK, though you got the patch wrong. Ohh, that was embarrassing. But hey, it wasn't meant for inclusion as it was too hacky anyway :-) Try to actually use git, it's really better. If possible, I'd like to avoid this, as I currently already have to work with SVN and Mercurial. Adding yet another revision control system in my mind, would probably confuse the hell out of me... Also, maybe you can make the touchscreen case a bit narrower, i.e. check for BTN_TOUCH or so. The attached patch does this. I think this illustrates the problem that I can't really tell touchscreens and touchpads apart. They are both devices that have absolute axes, and emits the BTN_TOUCH signal. I assume it will be necessary to be able to differentiate between these two kinds of devices at some point? Søren evdev.patch2 Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: handling BTN_TOUCH in evdev driver
2008/9/22 Adam Jackson [EMAIL PROTECTED]: On Mon, 2008-09-22 at 08:56 +0200, Søren Hauberg wrote: Hi, I've making some changes tu the usbtouchscreen module to handle calibration stuff (see another thread on this list). This module currently emits BTN_TOUCH whenever the user touches the screen (I haven't changed this). When I'm using the evdev X driver to handle the touch screen I can move the cursor just fine, but I can't click any buttons in GUI's such as KDE or GNOME. If I instead use the evtouch X11 driver this works fine. So, it seems the evtouch and the evdev drivers handle BTN_TOUCH differently. Is there a reason why the evdev driver handles BTN_TOUCH as it does, or is it simply because nobody has tested it with a touchscreen? If the current behavior is on purpose, then I don't think my approach with changing the kernel driver and relying on evdev in X will work. How does evtouch distinguish between I want to move the cursor here and I want to click here? Since I'm quite new to X, I find the evtouch code [1] quite hard to read, so I cannot tell for sure. It does treat it differently than BTN_LEFT, though. If I move my stylus around on the KDE desktop (with 'evtouch') it only moves the cursor -- it does not try to select the icons on the desktop, like it would if I was moving a mouse around with the left button down. I'm not sure this is a particular good behavior, though... Other than that, there's no particularly deep reason to not treat BTN_TOUCH as a click in evdev. I did test evdev with a touchscreen, but apparently the one I had would give you distinct events for BTN_LEFT versus BTN_TOUCH. I guess that also depends on the kernel. The 'usbtouchscreen' kernel module only sends BTN_TOUCH, but I don't know about other modules in the kernel. Anyway, I have two goals, 1) get a short term solution, that'll work right now, and 2) get a long term solution that'll reduce the amount of patches we have to maintain in the company. As the short term solution, I've changed 'usbtouchscreen' to send BTN_LEFT instead of BTN_TOUCH, and this works perfectly fine for me. So, for me, changing 'evdev' to treat BTN_TOUCH like BTN_LEFT would be wonderful. I don't know about other touchscreens, though... Thanks, Søren [1] http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evtouch.git;a=blob;f=evtouch.c;h=c004846d2086224bca382a549483c949fb3c99e3;hb=HEAD ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: handling BTN_TOUCH in evdev driver
2008/9/23 Matthew Garrett [EMAIL PROTECTED]: On Tue, Sep 23, 2008 at 09:18:02AM +0200, Søren Hauberg wrote: I guess that also depends on the kernel. The 'usbtouchscreen' kernel module only sends BTN_TOUCH, but I don't know about other modules in the kernel. Anyway, I have two goals, 1) get a short term solution, that'll work right now, and 2) get a long term solution that'll reduce the amount of patches we have to maintain in the company. As the short term solution, I've changed 'usbtouchscreen' to send BTN_LEFT instead of BTN_TOUCH, and this works perfectly fine for me. So, for me, changing 'evdev' to treat BTN_TOUCH like BTN_LEFT would be wonderful. I don't know about other touchscreens, though... BTN_TOUCH isn't just used for touchscreens. For example, touchpads send it to indicate finger position. It's purely to indicate that an input event has been received at that location - treating it as BTN_LEFT by default would break existing use cases. It sounds like changing usbtouchscreen to send both events (at least optionally) would be more reasonable, but you'd probably want to discuss that with upstream. So, is BTN_TOUCH even the right thing to send? It seems to me like a touchpad and a touchscreen are so wildly different things, that they should be sending the same signal. Perhaps it would be wise to introduce a BTN_SCREENTOUCH or something similar? Of course, I can try to persuade the kernel people that it's just fine to send BTN_LEFT instead of BTN_TOUCH, but I'm guessing its a hard sell (BTN_TOUCH does sound like something a touchscreen would send...) Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
2008/9/22 Peter Hutterer [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 01:29:58PM +0200, Søren Hauberg wrote: I do have a follow-up question (you can't get rid of me that easy :-) ). I have modified the 'usbtouchscreen' kernel module such that it can use calibration parameters. With this in place, my touchscreen works in X with the 'evdev' driver, i.e. out of the box. Do you guys think this is the right approach to handling touchscreens in GNU/Linux, or would you prefer an X driver for handling touchscreens? I plan on posting the kernel patch to the kernel list on Monday unless anybody here thinks the problem should be solved in X instead of the kernel. I'd prefer the fix in the kernel module, as it keeps the X drivers to a minimum. This is also the conclusion I came to, because the changes to the kernel are fairly small. Also, it should help touch screen users who aren't using X. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
2008/9/18 Peter Hutterer [EMAIL PROTECTED]: On Wed, Sep 17, 2008 at 06:46:17AM -0700, Hauberg wrote: Now, my problem is that X seems to somehow accelerate the output from the 'usbtouchscreen' module, so that when I move my finger to the left, the cursor moves about twice as far to the left as my finger did. This does not correspond to the output from the 'usbtouchscreen' module. So, I'm a bit confused here: does X place the cursor at the position outputted by the kernel, or does it do some fancy things? after a quick 30s peek into the evtouch driver: it always inits x/y with a range of [0-1024]. you'd need to change this (in EVTouchPreInit) to reflect the real range of the coordinates you post from the driver module. I don't see this in the evtouch driver, but since I don't know much about X, this just might be my ignorance showing :-) In general, I really want to avoid using the evtouch driver as it is unmaintained. The only development on this driver appears to be done by the Debian people. So the actual place to get the evtouch source code is not the evtouch website, but actually the Debian package. This difference could also explain why I don't see the 1024 stuff in EVTouchPreInit. But I don't think I've been clear enough in my description of our system. One way to get a functional setup is to use the 'usbtouchscreen' kernel module and the evtouch X11 driver. This works fine for everyday use, but it is hard to perform calibration. Another way to get a potentially working setup (this is what I'm working on) is to alter the 'usbtouchscreen' kernel module such that it can read the calibration data, and actually provide actual screen coordinates. I have this working, such that I can give the kernel my calibration parameters, and it will emit mouse events that corresponds to actual screen coordinates. If I use the 'evdev' X11 driver to handle these mouse events the cursor moves faster (I think that's the best word I've got) than the output from the kernel. Instead of using the 'evdev' X11 driver I can use the evtouch driver, and tell it not to use the calibration data, and that works. But then I haven't gotten rid of the evtouch driver, which is my main motivation. all events are posted as absolute from the evtouch driver (xf86PostMotionEvent, xf86PostButtonEvent), which means they will get scaled by the server into the screen space, i.e. if the screen has a resolution is 2048, this means that the device coordinate 512 will map to the screen coordinate 1024. This could be the reason for your scaling issue. Setting up the axes with the right values should fix that. alternatively, you could make sure the kernel driver pre-scales to a range of 0-1024. I've tried to make the kernel send events with x in [0, 1023] and y in [0, 1023], but that still behaves quite poorly. I'm sorry that I can't give a better explanation, but I know sooo little about X that I simply don't have the terminology. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
