> 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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
