Re: Microchip Touchscreen Driver Submissions

Re: Microchip Touchscreen Driver Submissions

[Dmitry Torokhov]

Hi Steve,

On Wed, Dec 01, 2010 at 03:01:58PM -0700, Steve.Grahovac@microchip.com wrote:
> Hi Dmitry,
> 
>  
> 
> We are looking to add Linux kernel support for three of our UART/RS-232
> touchscreen controller protocols.

Great! It is always nice when manufacturer is committed to support their
products on Linux.

> I was wondering if I might ask for
> your help on how I might best integrate them into the mainstream kernel.

Normally all code submission is done in patch form and sent (in case of
input drivers) to linux-input@vger.kernel.org (and please CC me as
well). Note that list does not accept HTML (only plain text) and if you
are using Outlook/Exchange you may get into issue with it replacing
tabs with spaces and otherwise mangling mails. I recommend using mutt or
similar MUA for patch submuission.

Please take a look and Documentation/SubmittingPatches in the kernel
source tree for the format and requirements on patches. One of the things I
need to apply your code ito my tree (and eventually mainline) is your
"Signed-off-by: ..." tag.

> 
>  
> 
> The attached bundle includes the following files:
> 
>  
> 
> mchpar1xxx.c - This file is for support of the Microchip AR1XXX
> touchscreen controllers .
> 
>  
> 
> mchptsharc.c - This file is for support of the Microchip TSHARC series
> of touchscreen controllers.  There is already a hampshire.c that
> correctly supports the protocol.  I would like to request that the
> "hampshire.c" filename is renamed to "tsharc.c" or "mchptsharc.c" since
> the "Hampshire" as a company no longer exists (Hampshire was acquired by
> Microchip).  If the renaming of the file is not possible, could we
> submit the "mchptsharc.c" file that basically supports the same protocol
> but has the Microchip or TSHARC labeling?

Adjusting Kconfig/Makefile to show the new name should be OK, and even
renaming the source file, but I'd prefer leaving the rest as is (i.e.
not changing names in the code, etc).

Please send a patch.

> 
>  
> 
> mchppcapmt.c - This file is for support of the Microchip Projected
> Capacitive Multi-Touch series of touchscreen controllers.  The
> ABS_MT_TRACKING_ID events were used, but I did not make use the MT slots
> protocol. I could spend additional time to convert to MT slots (if
> preferred) since our protocol reports an ID in the packet, but I'm not
> sure if it's necessary.

It is not necessary but it cuts down on the bandwidth that is needed to
transmit state to userspace so it is nice to have.

> I verified the multi-touch was being reported
> correctly by use of the pymt python multi-touch draw application.  For
> touchscreen emulation,  I did notice an issue where touch events seemed
> to be properly sent as evdev packets by the mchppcapmt kernel module,
> however Xorg 7.5 did not process these touch events correctly since the
> cursor moved but there were no click events (I'm guessing this is an
> Xorg issue, but not 100 percent sure).  Are you familiar with any
> multi-touch touchscreen emulation issues with Xorg?

Multitouch support is work in progress on all levels of our stack, I
think Henrik is in a better position to answer this question.

Thanks.

-- 
Dmitry

Re: Microchip Touchscreen Driver Submissions

[Henrik Rydberg]

>

>> I verified the multi-touch was being reported
>> correctly by use of the pymt python multi-touch draw application.  For
>> touchscreen emulation,  I did notice an issue where touch events seemed
>> to be properly sent as evdev packets by the mchppcapmt kernel module,
>> however Xorg 7.5 did not process these touch events correctly since the
>> cursor moved but there were no click events (I'm guessing this is an
>> Xorg issue, but not 100 percent sure).  Are you familiar with any
>> multi-touch touchscreen emulation issues with Xorg?
> 
> Multitouch support is work in progress on all levels of our stack, I
> think Henrik is in a better position to answer this question.


There are a number of things that can go wrong, anywhere from the kernel driver,
whether mtdev is used or not (latest pymt has mtdev support), which X driver is
in use, and what distro is being used.

For driver tests, the mtview program (http://bitmath.org/code/mtview/) has been
used successfully during development of some drivers, since it does not depend
on the higher levels of the stack. Combined with evtest, it is usually possible
to find the point-and-click problems.

If you do find an error higher up the stack, providing a test case using the
utouch-evemu project is very valuable, since it allows the hardware and the
exact situation to be emulated and explicitly tested on any machine.

Thanks,
Henrik

RE: Microchip Touchscreen Driver Submissions

[Steve.Grahovac]

Thanks Hendrik for your help.  I will use this application as a testbed
for verifying events for multi-touch kernel modules.

Would you happen to know the appropriate way to download the source for
this?  I tried both cloning it's git repository and also tried clicking
on the URL but unfortunately I was unable to gain access.

>If you do find an error higher up the stack, providing a test case
using the
utouch-evemu project is very valuable, since it allows the hardware and
the
exact situation to be emulated and explicitly tested on any machine.

That sounds like a nice tool.  If I can reproduce using this issue using
emulated events, I'll submit a case.

Best regards,

Steve Grahovac
Sr. Software Engineer
Microchip Technology, Inc.
9055 N. 51st Street Suite H
Brown Deer, WI 53223 USA
Steve.Grahovac@microchip.com
Ph: 414.355.4675
FX: 414.355.4775




-----Original Message-----
From: Henrik Rydberg [mailto:rydberg@euromail.se] 
Sent: Thursday, December 02, 2010 3:55 AM
To: Dmitry Torokhov
Cc: Steve Grahovac - C13916; Linux Input
Subject: Re: Microchip Touchscreen Driver Submissions

>

>> I verified the multi-touch was being reported
>> correctly by use of the pymt python multi-touch draw application.
For
>> touchscreen emulation,  I did notice an issue where touch events
seemed
>> to be properly sent as evdev packets by the mchppcapmt kernel module,
>> however Xorg 7.5 did not process these touch events correctly since
the
>> cursor moved but there were no click events (I'm guessing this is an
>> Xorg issue, but not 100 percent sure).  Are you familiar with any
>> multi-touch touchscreen emulation issues with Xorg?
> 
> Multitouch support is work in progress on all levels of our stack, I
> think Henrik is in a better position to answer this question.


There are a number of things that can go wrong, anywhere from the kernel
driver,
whether mtdev is used or not (latest pymt has mtdev support), which X
driver is
in use, and what distro is being used.

For driver tests, the mtview program (http://bitmath.org/code/mtview/)
has been
used successfully during development of some drivers, since it does not
depend
on the higher levels of the stack. Combined with evtest, it is usually
possible
to find the point-and-click problems.

If you do find an error higher up the stack, providing a test case using
the
utouch-evemu project is very valuable, since it allows the hardware and
the
exact situation to be emulated and explicitly tested on any machine.

Thanks,
Henrik