How best to get touch working on EOMA?
I'm thinking may be a better bet is to have a mouse like generic USB gadget built. Then you would connect the resistive or capacitive panel to it, and it would convert the signals to standard mouse signals.
I've got touch signals being picked up by the drivers cubie but need to run some software to get it to cooperate with X - so a bit fiddly even if touch pins are available.
EOMA doesn't have the touch pins brought out, so having such a modular unit could benefit EOMAs and other similar boards.
On Monday, December 9, 2013 14:23:38 joem wrote:
I'm thinking may be a better bet is to have a mouse like generic USB gadget built. Then you would connect the resistive or capacitive panel to it, and it would convert the signals to standard mouse signals.
Usually the real trick is the multi-touch events and proper screen calibration with X. Having a generic USB gadget for this would be fantastic ...
EOMA doesn't have the touch pins brought out, so having such a modular unit could benefit EOMAs and other similar boards.
Agreed ..
On Mon, 2013-12-09 at 15:52 +0100, Aaron J. Seigo wrote:
On Monday, December 9, 2013 14:23:38 joem wrote:
I'm thinking may be a better bet is to have a mouse like generic USB gadget built. Then you would connect the resistive or capacitive panel to it, and it would convert the signals to standard mouse signals.
Usually the real trick is the multi-touch events and proper screen calibration with X. Having a generic USB gadget for this would be fantastic ...
EOMA doesn't have the touch pins brought out, so having such a modular unit could benefit EOMAs and other similar boards.
Agreed ..
Hmm.. it would need a switch to switch between normal mouse mode operation and multi-touch operation. The multi-touch operation would need a modified mouse driver I'm guessing. In the normal mouse position, there is no need for this extra driver, but in multi-touch position, the USB device would have to re-register as some other device so that driver can switch to multi-touch operation.
Sounds doable :)
That is two projects needing doing - generic switch mode power supply and generic touch to mouse converter.
On 2013-12-09 08:43, joem wrote:
That is two projects needing doing - generic switch mode power supply and generic touch to mouse converter.
Why pretend it's a mouse? evdev (kernel & xf86) has multitouch absolute-positioned cursor-handling code built in which doesn't care if the device in question is a mouse, touchpad, touchscreen, etc.. As far as I know, the device just has to advertise its inputs right, and it should be picked up. That said, Meego's mtev driver has been more competent on the X11 side in my experience.
What am I missing?
On Mon, 2013-12-09 at 10:02 -0700, N Shipp wrote:
On 2013-12-09 08:43, joem wrote:
That is two projects needing doing - generic switch mode power supply and generic touch to mouse converter.
Why pretend it's a mouse? evdev (kernel & xf86) has multitouch absolute-positioned cursor-handling code built in which doesn't care if the device in question is a mouse, touchpad, touchscreen, etc.. As far as I know, the device just has to advertise its inputs right, and it should be picked up. That said, Meego's mtev driver has been more competent on the X11 side in my experience.
What am I missing?
Pardon my ignorance, I am trying to get a resistive touch working. The 5" 800x480 display works with EOMA and Cubieboard. On cubieboard, there is a driver that works to read the resistive touch. Looking at the raw data coming out of the driver, it is working. But its seems more work needs to be done to tell X that that it must somehow connect with this driver.
So here is me thinking why all this hassle? I'd rather have a board that accepted a wide variety of capacitive and resistive panels and as a simple measure simply make it pretend its a mouse to get systems working more quickly.
Muti-touch is different from a mouse, hence need for a switch to switch between the two modes of operation.
(Probably, in the long run it won't be needed when software and hardware catches up with all the touch options out there for the big SoCs. There are plenty of lesser systems out there that are not powerful enough to process the signals and turn them into mouse like signals. So there is long term benefit to having a generic controller that turns resistive and capacitive input into mouse signals.)
On Tue, Dec 10, 2013 at 8:48 AM, joem joem@martindale-electric.co.uk wrote:
On Mon, 2013-12-09 at 10:02 -0700, N Shipp wrote:
On 2013-12-09 08:43, joem wrote:
That is two projects needing doing - generic switch mode power supply and generic touch to mouse converter.
Why pretend it's a mouse? evdev (kernel & xf86) has multitouch absolute-positioned cursor-handling code built in which doesn't care if the device in question is a mouse, touchpad, touchscreen, etc.. As far as I know, the device just has to advertise its inputs right, and it should be picked up. That said, Meego's mtev driver has been more competent on the X11 side in my experience.
What am I missing?
Pardon my ignorance, I am trying to get a resistive touch working. The 5" 800x480 display works with EOMA and Cubieboard. On cubieboard, there is a driver that works to read the resistive touch. Looking at the raw data coming out of the driver, it is working. But its seems more work needs to be done to tell X that that it must somehow connect with this driver.
So here is me thinking why all this hassle? I'd rather have a board that accepted a wide variety of capacitive and resistive panels and as a simple measure simply make it pretend its a mouse to get systems working more quickly.
then you want an arduino, along with the code that was supplied in the link that i found yesterday. this code, running on an arduino, puts the arduino's USB-client publish a "HID" endpoint. it reads the two ADCs and shoves any events over as USB HID events.
whilst this is one approach it _is_ very expensive and cost-ineffective. however if you are already going to be deploying an embedded controller (such as the one used in the arduino, just as an example) then you probably are going to have some ADCs spare, so there would be no extra "cost".
however if you want a quotes simple quotes modular approach then you're buggered. why? because to get low-cost modularity even a PIC is pricing-overkill.
Muti-touch is different from a mouse, hence need for a switch to switch between the two modes of operation.
not from the evdev perspective it is not. all HID devices end up in evdev. the only difference between keyboard, mouse, stylus and panel is in the sub-type of HID which ends up as a different class of evdev, and udev then knows to create symlinks for mouse0, mouse1, or whatever-is-needed.
anyway, go with what's easiest for you, joe: in the end it's about making things easy for people to play. personally i am quite happy to do mass-volume cost-reduction exercises because i understand both the software *and* hardware design aspects, but the rules for that are completely different from what you're endeavouring to provide.
l.
On Mon, Dec 9, 2013 at 2:52 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Monday, December 9, 2013 14:23:38 joem wrote:
I'm thinking may be a better bet is to have a mouse like generic USB gadget built. Then you would connect the resistive or capacitive panel to it, and it would convert the signals to standard mouse signals.
Usually the real trick is the multi-touch events and proper screen calibration with X. Having a generic USB gadget for this would be fantastic ...
on the flying squirrel i considered doing the conversion by having the I2C capacitive devices connected to the STM32F (and then to the ATSAM4SB on the rev3 board) but to be honest it's a lot of hassle. in the end, so as not to have to write any special linux kernel drivers, i went with just a plain I2C IC (built-in to the panel in order to reduce stray capacitance SNR leakage).
for those capacitive converter ICs that have USB, they already have linux kernel drivers: no work is needed there either.
for resistive ICs, the standards are either SPI or I2C - not USB. extra work, both in hardware and software, would be needed.
EOMA doesn't have the touch pins brought out, so having such a modular unit could benefit EOMAs and other similar boards.
ok for capacitive "keys", this is already done (in some form or other):
https://www.sparkfun.com/products/9695 https://www.sparkfun.com/products/10250
for capacitive touchpanels you *really* do not want to be getting individual ICs: the stray capacitance of having the IC far away from the actual panel is so far above the capacitive panel's capacitance that you get wildly inaccurate readings. therefore you should be looking at an FPC breakout board and just wiring directly up on the EOMA68 I2C bus. problem solved.
for resistive i'm having a little more difficulty tracking anything down, notably because most of sparkfun's stuff is designed for arduinos etc. etc. all of which have at least two ADC pins. so, you'd need to e.g. follow this:
http://make.larsi.org/electronics/TouchScreen/
and then get an I2C ADC Converter IC e.g. this:
http://www.ti.com/product/ads1000
(ok get 2 of those) plus a break-out board for a SOT-23 (or 2) and you're pretty much done.
the alternative is of course to use something like an arduino PIC, or one of those Freescale $0.40 embedded controllers. then, aaron, yes, absolutely: you'd be programming it (unless the source is already available like it is for many arduino-style project) to put it into USB HID mode.
but, if you're doing it as I2C then you'd need a linux driver kernel module on whatever EOMA-68 CPU Card is being used, reading the I2C bus but written as a mouse hid device. straightforward enough.
l.
-da
On Mon, Dec 9, 2013 at 2:23 PM, joem joem@martindale-electric.co.uk wrote:
How best to get touch working on EOMA?
you mean EOMA68?
almost most all capacitive panels are I2C. goodix ICs or futuretech (e.g. FT5306). these are already fully supported under linux: drivers are easy to find and many of them are already in the sunxi 3.4 kernel tree. i had to do a bit of searching for the one that goes with the flying squirrel's [current] chosen touchpanel, eventually found it in a rockchip kernel source tarball somewhere.
so, I2C is on EOMA68: therefore capacitive touchpanels are automatically not a problem. just remember that the pull-down for I2C is *already* done on the CPU Card.
resistive panels: that's a different matter. they're analogue, so you'd need either a dedicated IC or to do it yourself with a voltage source (or two?) and any IC that has a couple of ADCs (or three?). to be honest, i'd recommend just using a dedicated IC. the one i used to be familiar with is a TI TSC230somethingsomething.... TSC2200. oh. arse. it's SPI.
hmmm, let's see... http://www.ti.com/lsds/ti/data-converters/touch-screen-controller-products.p... I2C tum te tum.... exclude automotive parts... lowest-priced item iiiis:
http://www.ti.com/product/tsc2014
ta-daaa :) ok, if you prefer a QFN package you'd have to use the tsc2004 which is $1.75 not $1.30 in 1k volumes.
that's with 5 mins of searching. if you spent a bit more time looking i'm sure there would be lower-cost options easily found.
is there a linux kernel driver for the TSC2014 and the TSC2004? answer: yes. http://www.ti.com/tool/tsc2004-linux-drv
so that's sorted.
l.
On Mon, Dec 9, 2013 at 2:23 PM, joem joem@martindale-electric.co.uk wrote:
How best to get touch working on EOMA?
: you mean EOMA68?
: almost most all capacitive panels are I2C. goodix ICs or futuretech :(e.g. FT5306). these are already fully supported under linux: drivers :are easy to find and many of them are already in the sunxi 3.4 kernel :tree. i had to do a bit of searching for the one that goes with the :flying squirrel's [current] chosen touchpanel, eventually found it in :a rockchip kernel source tarball somewhere.
: so, I2C is on EOMA68: therefore capacitive touchpanels are :automatically not a problem. just remember that the pull-down for I2C :is *already* done on the CPU Card.
I got a couple of capacitive panels coming - will soon be able to try out the suggestions - thanks.
: resistive panels: that's a different matter. they're analogue, so :you'd need either a dedicated IC or to do it yourself with a voltage :source (or two?) and any IC that has a couple of ADCs (or three?). to :be honest, i'd recommend just using a dedicated IC. the one i used to :be familiar with is a TI TSC230somethingsomething.... TSC2200. oh. :arse. it's SPI. : : hmmm, let's see... :http://www.ti.com/lsds/ti/data-converters/touch-screen-controller-products.p... :I2C tum te tum.... exclude automotive parts... lowest-priced item :iiiis: : : http://www.ti.com/product/tsc2014 : : ta-daaa :) ok, if you prefer a QFN package you'd have to use the :tsc2004 which is $1.75 not $1.30 in 1k volumes. : : that's with 5 mins of searching. if you spent a bit more time :looking i'm sure there would be lower-cost options easily found. : :is there a linux kernel driver for the TSC2014 and the TSC2004? :answer: yes. http://www.ti.com/tool/tsc2004-linux-drv : : so that's sorted.
Good - I got at least resistive LCD 5" 50 screens sat on my desk to play with :)
On Mon, Dec 9, 2013 at 11:11 PM, joem joem@martindale-electric.co.uk wrote:
On Mon, Dec 9, 2013 at 2:23 PM, joem joem@martindale-electric.co.uk wrote:
I got a couple of capacitive panels coming - will soon be able to try out the suggestions - thanks.
do you know which make/models? do they have the ICs on a thin-film circuit already? if not... you're in for... a lot of cat-on-hot-nails dancing [i.e. if they're "bare" capacitive panels with say 10 horizontal lines and 15 vertical ones and no IC].
i _was_ going to do that with an STM32F (say) - one of the big ones: do the timings and set up an RC circuit manually then scan them from software. after realising quite how small the capacitance actually is on these panels, i am *really* glad i didn't go that route. FT, Goodix and Atmel have some hellishly-complex algorithms in the firmware of those ICs...
l.
On Mon, 2013-12-09 at 23:17 +0000, luke.leighton wrote:
On Mon, Dec 9, 2013 at 11:11 PM, joem joem@martindale-electric.co.uk wrote:
On Mon, Dec 9, 2013 at 2:23 PM, joem joem@martindale-electric.co.uk wrote:
I got a couple of capacitive panels coming - will soon be able to try out the suggestions - thanks.
do you know which make/models? do they have the ICs on a thin-film circuit already? if not... you're in for... a lot of cat-on-hot-nails dancing [i.e. if they're "bare" capacitive panels with say 10 horizontal lines and 15 vertical ones and no IC].
i _was_ going to do that with an STM32F (say) - one of the big ones: do the timings and set up an RC circuit manually then scan them from software. after realising quite how small the capacitance actually is on these panels, i am *really* glad i didn't go that route. FT, Goodix and Atmel have some hellishly-complex algorithms in the firmware of those ICs...
At present no idea what is coming - they are being sent by a factory interested in having their stuff deployed on allwinner Linux computers.
(As as aside, it would be good to out the "hellishly-complex" algorithms with an open sourced controller project. Everyone can benefit including those lumbered with hellish-complex algorithm design.)
arm-netbook@lists.phcomp.co.uk
-
Aaron J. Seigo -
joem -
Luke Kenneth Casson Leighton -
luke.leighton -
N Shipp