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.