Re: eeti_ts

Re: eeti_ts

[Daniel Mack]

Hi Charles,

please never write to me personally only, but always keep appropriate
mailing lists in the loop (the linux-input list in that case), and hit
"reply to all" when following up.

On 11/10/2010 12:27 PM, Charles Seedle wrote:
> Does your kernel module eeti_ts access the touchscreen hardware directly
> or is it accessing the data through input (HID) ?

The EETI touchscreen we have is controlled and queried via its I2C
interface. The driver implements the protocol and exposes an Linux input
interface which is accessible from userspace.

The protocol reference we got is referenced in the comment block of the
first lines in this driver. You should first check whether your
controller is compatible.

> My current installation is using tkusb.ko to connect to the touchscreen.
> The calibration is quite bad and I am running on a

What module is that? I can't find it in the kernel mainline tree?

> Texas Instruments OMAP 3450 processor (ARM7) so the intel calibration
> tools can’t be used.

And I don't know about any calibration tools, especially from Intel (and
I'm surprised Intel has anything to do with EETI at all?).

All we needed was a very small input layer in user space to map the EETI
touchscreen coordinates to the actual display resolution, simply by
applying a factor to it, and I think there is also a static offset which
we need due to mechanical construction constraints of our hardware. The
driver can be told to invert any of the two axis (with a module
parameter), but you shouldn't need more than this.


Hope that helps,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eeti_ts

[Daniel Mack]

(please don't top-post)

On 11/12/2010 09:19 AM, Charles Seedle wrote:
> Daniel:
> After further study, I can't use the IC2 protocol. 
> The module tkusb.ko is for a usb based touchscreen. It is available 
> from the eeti website (ie. http://www.eeti.com/ or from www.hedus.com). 
> We used the tar file from Hedus. It seemed to be more complete. This is
> where
> I found intel processor based calibration tools). It has nothing to do with 
> the company Intel. 

Hmm, sorry, I'm afraid I can't help you. The touchscreen you have might
be totally incompatible to the one I wrote the driver for (ours has a
Cypress PSOC chip). I also don't know about the tools or tarballs you're
talking about, I haven't gotten any sources from EETI. The driver I
submitted is all written by myself, following the protocol specification
I pointed out in the comment block.

Let me know if you need any further information.

Daniel

> -----Original Message-----
> From: Daniel Mack [mailto:zonque@gmail.com] On Behalf Of Daniel Mack
> Sent: Wednesday, November 10, 2010 5:11 PM
> To: charles.seedle@rigaku.com
> Cc: linux-input@vger.kernel.org
> Subject: Re: eeti_ts
> 
> Hi Charles,
> 
> please never write to me personally only, but always keep appropriate
> mailing lists in the loop (the linux-input list in that case), and hit
> "reply to all" when following up.
> 
> On 11/10/2010 12:27 PM, Charles Seedle wrote:
>> Does your kernel module eeti_ts access the touchscreen hardware directly
>> or is it accessing the data through input (HID) ?
> 
> The EETI touchscreen we have is controlled and queried via its I2C
> interface. The driver implements the protocol and exposes an Linux input
> interface which is accessible from userspace.
> 
> The protocol reference we got is referenced in the comment block of the
> first lines in this driver. You should first check whether your
> controller is compatible.
> 
>> My current installation is using tkusb.ko to connect to the touchscreen.
>> The calibration is quite bad and I am running on a
> 
> What module is that? I can't find it in the kernel mainline tree?
> 
>> Texas Instruments OMAP 3450 processor (ARM7) so the intel calibration
>> tools can't be used.
> 
> And I don't know about any calibration tools, especially from Intel (and
> I'm surprised Intel has anything to do with EETI at all?).
> 
> All we needed was a very small input layer in user space to map the EETI
> touchscreen coordinates to the actual display resolution, simply by
> applying a factor to it, and I think there is also a static offset which
> we need due to mechanical construction constraints of our hardware. The
> driver can be told to invert any of the two axis (with a module
> parameter), but you shouldn't need more than this.
> 
> 
> Hope that helps,
> Daniel
>