> The same is true if there is no EEPROM present but the EEPROM > is enabled. Anyway, I disabled my EEPROM by pulling the SEL4 > pin high because I don't need/want it (yet).
The same is done by my hardware guy. In my case, there is no EEPROM attached ... but he didn't pull up this pin up, until I found out what happend. For the EEPROM: I actually don't care if the calibration data is written somewhere in my filesystem or in some proprietary EEPROM. If you create gadgets with unwritable filesystems, e.g. cramfs, then you might care. But I didn't, and therefore didn't bother implementing any support for calibration on the driver-level. I'm doing that completely from userspace. > I started to do some more error handling, but it's propably > not worth doing so if the driver(s) has only limited > functionality (and no userspace app using it). Who says that the driver has no user space app? All touchscreen events that you get are exported via /dev/input/eventX to user space and there are plenty of apps that utilize this info. I wrote a (company inside) tool that reads /dev/input/eventXX, calibrates them and injects those events into X11 via the XTest extension. But for newer X.Org release you can also use xserver-input-event driver. My approach has just the benefit that I can "SIGHUP" my driver any time to re-calibrate, I don't need to restart X for this, which is cumbersome. So, please add error handling and post your patch :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
