On Mon, 24 May 2010, Rafi Rubin wrote: > I've written a calibration tool for my touch screen that works well from user > space (just sends a few commands over usb telling the digitizer to recalibrate > and reset itself). I've been running that with the ntrig and usbhid modules > unloaded. > > Now I'm trying to translate that to something in the kernel which I can run just > by poking a sysfs node. However as I sort of expected, it doesn't actually work > quite right. I've been seeing something like this: > > - From user space: > S Ii:3:002:2 -115:2 94 < > C Ii:3:002:2 0:2 94 = 033fbc07 0000a014 f012ce01 68010100 000c0701 00000000 > 00fa0096 00000b00 > > kernel space: > S Ii:3:002:2 -115:2 94 < > C Ii:3:002:2 -2:2 0 > > What sort of calls should I wrap the calibration code with? And what exactly are you doing from the sysfs-triggered code? I'd guess that simply calling usb_control_msg() should be enough, but without actually seeing the working userspace version and its (non-working) kernel-side counterpart, it's really a little bit difficult to tell. > Also, the process seems to involve telling the digitizer to go off and run > calibration, and then interrupting it after a while. I've been using a number > of microseconds dumped to the sysfs node for that. Is there any harm in using > "msleep(val);"? Depends on the context. If called from context that can safely sleep, it's fine. -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
