[Arm-netbook] How best to get touch working on EOMA?

[Luke Kenneth Casson Leighton]

On Tue, Dec 10, 2013 at 8:48 AM, joem <joem at 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.