On Thu, Feb 26, 2004 at 09:27:52PM -0500, Todd E. Johnson wrote:I found one that works great, and I have made a simple text howto so this may eventually help other touchscreen users which want to rely on evdev:
Unfortunately, the X11 mouse driver only seems capable of handling relative data rather than absolute. Hopefully some one will create a suitable X11 driver capable of accepting absolute data from Linux Input. If anyone is aware of one, please let me know. Otherwise, I will most likely begin some work on a patch for GPM.
I don't know of any, but that doesn't rule out the possibility.
http://groomlakelabs.com/grandamp/code/microtouch/Linux-Input-USB-Touchscreen-HowTo.txt
Patch will be forthcomming...
+Y is inverted, and the device has a total possible resolution of 0 - 65535.
+
+Y is inverted by the driver by:
+
+ input.absmin[ABS_Y] = MTOUCHUSB_MAX_YC;
+ input.absmax[ABS_Y] = MTOUCHUSB_MIN_YC;
Do it by inverting the values, please. While this works in most cases,
the direction of the axes in Linux input drivers is defined to be
compatible with USB HID spec.
Yes, it send an async. report with X/Y Compensated data as well as X/Y Raw data. (See "Coordinate Data Report 1" [page 17] in http://www.3m.com/3MTouchSystems/downloads/PDFs/19-264v20.pdf) I was under the impression that most touchscreens have the ability to do this (USB && Serial), otherwise my request below does not make much sence. If you really prefer, I can remove the compensated data from the picture and provide the raw data to input. What can be used in the userspace to calibrate? I just wanted to be really sure first...
+Currently there is no way to calibrate the device via this driver.
The touchscreen has some internal calibration? This would be the first
one I've seen so far. Calibration and conversion to screen coordinates
is currently expected to happen in userspace, and the driver is supposed
to return raw values from the device.
If you answer, "DO IT!" to the above, then nevermind...
Perhaps +at some point an abstract function will be placed into evdev so generic +functions like calibrations, resets, and vendor information can be requested +(And the drivers would handle the vendor specific tasks).
If that's proven to be needed, yes.
Unfortunately I left this in for now since 3M appears to have released multiple USB controllers which use the same/similar firmware. I can remove this as well if you like, and simply wait for people to say "I have a 3M/Microtouch USB touchscreen, but it will not work with the driver...
+
+ if (vendor != -1 && product != -1) {
+ info("%s - User specified USB Touch -- Vend:Prod - %x:%x",
+ __FUNCTION__, vendor, product);
+ }
+
+ for (ix = 0; ix < sizeof (mtouchusb_devices) /
+ sizeof (struct usb_device_id); ix++) {
+ if ((udev->descriptor.idVendor ==
+ mtouchusb_devices [ix].idVendor) &&
+ (udev->descriptor.idProduct ==
+ mtouchusb_devices [ix].idProduct)) {
+ valid_device = 1;
+ break;
+ }
+ }
+
+ if (udev->descriptor.idVendor == vendor &&
+ udev->descriptor.idProduct == product) { /* User specified */
+ valid_device = 1;
+ }
This is not very nice, but I suspect it's unavoidable if you need to specify the ID as module parameters.
--
Regards,
Todd E. Johnson
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
