Why Cypress does not upstream its trackpad driver?

Why Cypress does not upstream its trackpad driver?

[Ozan Çağlayan]

Hi,

This driver [0] was written with a cooperation of Cypress, Dell and
Canonical Engineers within the last 3-4 months. It is very nice that
Cypress as a vendor cooperated with Canonical (Because Canonical works
with Dell for their Project Sputnik and Dell XPS13 is used as the main
hardware for that project and Dell XPS13 has this type of trackpad,
Bingo!), and I am also glad that Ubuntu users benefits from this
driver.

The driver brings multi-touch scrolling, disable-while-tapping and
makes Fn+Fx touchpad disable/enable work for not only Dell XPS13 but
for all laptops having this trackpad (My Lenovo Ultrabook U300s for
example, I tested the patches on fedora 17's 3.6 kernel and it works
quiet nice)

But what I am not getting that why NOBODY from Cypress/Canonical/Dell
isn't bothering to push this driver to upstream?
Is it too hard? I don't think so as the patches are quite non-invasive
and small.

Is the only distribution around is Ubuntu?
Is the only laptop sold in the world is Dell XPS13 with an Ubuntu?

I'm not trying to be impolite but it hurts me to see that a vendor
produces an open-source driver for its device but makes use of it only
through a specific distribution.

If Cypress is just beginning developing open-source drivers for their
devices, I hope that after this mail they will be much sensitive about
the issue and push their drivers even before the release of their
devices to make user experience flawless.

(I googled and searched the archives of LKML and linux-input but
couldn't find a discussion or patch series about the driver. If I
missed it, ignore the whole stuff above)

[0]: http://patchwork.ozlabs.org/patch/178903/

-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
--
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: Why Cypress does not upstream its trackpad driver?

[Kamal Mostafa]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

On Tue, 2012-11-06 at 17:47 -0500, Ozan Çağlayan wrote:
> Hi,
> 
> This driver [0] was written with a cooperation of Cypress, Dell and
> Canonical Engineers within the last 3-4 months. It is very nice that
> Cypress as a vendor cooperated with Canonical (Because Canonical works
> with Dell for their Project Sputnik and Dell XPS13 is used as the main
> hardware for that project and Dell XPS13 has this type of trackpad,
> Bingo!), and I am also glad that Ubuntu users benefits from this
> driver.
> 
> The driver brings multi-touch scrolling, disable-while-tapping and
> makes Fn+Fx touchpad disable/enable work for not only Dell XPS13 but
> for all laptops having this trackpad (My Lenovo Ultrabook U300s for
> example, I tested the patches on fedora 17's 3.6 kernel and it works
> quiet nice)
> 
> But what I am not getting that why NOBODY from Cypress/Canonical/Dell
> isn't bothering to push this driver to upstream?


In fact, Canonical is working on preparing the Cypress PS/2 trackpad
driver for submitting upstream.


> Is it too hard? I don't think so as the patches are quite non-invasive
> and small.


Your estimate of the work/risk involved not withstanding, I chose to
deploy this experimental driver in stages -- first in the oem-specific
"Sputnik project" kernel, then (recently) in the main Ubuntu kernel,
then finally (soon) upstream -- so as to minimize regressions while
shaking out the bugs.  For example, the version to which you linked does
include a regression (breaks some ALPS touchpads) which we discovered
only after deploying in Ubuntu.

I expect to submit the Cypress driver upstream within two weeks.  Of
course, my work on the driver is (and has been) publicly available[1].

 -Kamal Mostafa <kamal@canonical.com>

[1] The latest version of this driver is represented by the patch set:
    http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-quantal.git&a=search&h=HEAD&st=commit&s=Cypress+PS%2F2


> 
> Is the only distribution around is Ubuntu?
> Is the only laptop sold in the world is Dell XPS13 with an Ubuntu?
> 
> I'm not trying to be impolite but it hurts me to see that a vendor
> produces an open-source driver for its device but makes use of it only
> through a specific distribution.
> 
> If Cypress is just beginning developing open-source drivers for their
> devices, I hope that after this mail they will be much sensitive about
> the issue and push their drivers even before the release of their
> devices to make user experience flawless.
> 
> (I googled and searched the archives of LKML and linux-input but
> couldn't find a discussion or patch series about the driver. If I
> missed it, ignore the whole stuff above)
> 
> [0]: http://patchwork.ozlabs.org/patch/178903/
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: Why Cypress does not upstream its trackpad driver?

[Troy Abercrombia]

Hello Kamal

Unfortunately, We're not able to upstream the driver as it would be denied because it changes the Linux mouse structure framework.

Thanks
Troy
-----Original Message-----
From: Kamal Mostafa [mailto:kamal@canonical.com]
Sent: Wednesday, November 07, 2012 10:32 AM
To: Ozan Çağlayan
Cc: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org; dmitry.torokhov@gmail.com; customercare; mario_limonciello@dell.com
Subject: Re: Why Cypress does not upstream its trackpad driver?

On Tue, 2012-11-06 at 17:47 -0500, Ozan Çağlayan wrote:
> Hi,
>
> This driver [0] was written with a cooperation of Cypress, Dell and
> Canonical Engineers within the last 3-4 months. It is very nice that
> Cypress as a vendor cooperated with Canonical (Because Canonical works
> with Dell for their Project Sputnik and Dell XPS13 is used as the main
> hardware for that project and Dell XPS13 has this type of trackpad,
> Bingo!), and I am also glad that Ubuntu users benefits from this
> driver.
>
> The driver brings multi-touch scrolling, disable-while-tapping and
> makes Fn+Fx touchpad disable/enable work for not only Dell XPS13 but
> for all laptops having this trackpad (My Lenovo Ultrabook U300s for
> example, I tested the patches on fedora 17's 3.6 kernel and it works
> quiet nice)
>
> But what I am not getting that why NOBODY from Cypress/Canonical/Dell
> isn't bothering to push this driver to upstream?


In fact, Canonical is working on preparing the Cypress PS/2 trackpad driver for submitting upstream.


> Is it too hard? I don't think so as the patches are quite non-invasive
> and small.


Your estimate of the work/risk involved not withstanding, I chose to deploy this experimental driver in stages -- first in the oem-specific "Sputnik project" kernel, then (recently) in the main Ubuntu kernel, then finally (soon) upstream -- so as to minimize regressions while shaking out the bugs.  For example, the version to which you linked does include a regression (breaks some ALPS touchpads) which we discovered only after deploying in Ubuntu.

I expect to submit the Cypress driver upstream within two weeks.  Of course, my work on the driver is (and has been) publicly available[1].

 -Kamal Mostafa <kamal@canonical.com>

[1] The latest version of this driver is represented by the patch set:
    http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-quantal.git&a=search&h=HEAD&st=commit&s=Cypress+PS%2F2


>
> Is the only distribution around is Ubuntu?
> Is the only laptop sold in the world is Dell XPS13 with an Ubuntu?
>
> I'm not trying to be impolite but it hurts me to see that a vendor
> produces an open-source driver for its device but makes use of it only
> through a specific distribution.
>
> If Cypress is just beginning developing open-source drivers for their
> devices, I hope that after this mail they will be much sensitive about
> the issue and push their drivers even before the release of their
> devices to make user experience flawless.
>
> (I googled and searched the archives of LKML and linux-input but
> couldn't find a discussion or patch series about the driver. If I
> missed it, ignore the whole stuff above)
>
> [0]: http://patchwork.ozlabs.org/patch/178903/
>


This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.

Re: Why Cypress does not upstream its trackpad driver?

[richard -rw- weinberger]

On Thu, Nov 8, 2012 at 12:13 AM, Troy Abercrombia <ta@cypress.com> wrote:
> Hello Kamal
>
> Unfortunately, We're not able to upstream the driver as it would be denied because it changes the Linux mouse structure framework.

Then write a sane driver or submit patches which add the features you
need in the Linux input device framework...

-- 
Thanks,
//richard

Re: Why Cypress does not upstream its trackpad driver?

[David Solda]

Kamal,

My name is Dave Solda and I would be happy to answer any other questions that you have. Troy's response is correct however as in order to support the default Linux mouse class, our firmware would also have to be modified to do so, which cannot be done in system. Our packet protocol maxes out at an 8 byte packet, which requires a change to the Linux standard in this case.

Our goal in working with canonical was to provide something on Linux that would support multi-touch and not only have default single finger movement supported.

If I am mistaken and he Linux kernel would accept this, then we can proceed to upstream, however all indications we have is that this patch would be rejected.  If you (or others on from the locus alias) have any inputs, I would be happy to receive them.

Dave



On Nov 8, 2012, at 7:13 AM, "Troy Abercrombia" <ta@cypress.com> wrote:

> Hello Kamal
>
> Unfortunately, We're not able to upstream the driver as it would be denied because it changes the Linux mouse structure framework.
>
> Thanks
> Troy
> -----Original Message-----
> From: Kamal Mostafa [mailto:kamal@canonical.com]
> Sent: Wednesday, November 07, 2012 10:32 AM
> To: Ozan Çağlayan
> Cc: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org; dmitry.torokhov@gmail.com; customercare; mario_limonciello@dell.com
> Subject: Re: Why Cypress does not upstream its trackpad driver?
>
> On Tue, 2012-11-06 at 17:47 -0500, Ozan Çağlayan wrote:
>> Hi,
>>
>> This driver [0] was written with a cooperation of Cypress, Dell and
>> Canonical Engineers within the last 3-4 months. It is very nice that
>> Cypress as a vendor cooperated with Canonical (Because Canonical works
>> with Dell for their Project Sputnik and Dell XPS13 is used as the main
>> hardware for that project and Dell XPS13 has this type of trackpad,
>> Bingo!), and I am also glad that Ubuntu users benefits from this
>> driver.
>>
>> The driver brings multi-touch scrolling, disable-while-tapping and
>> makes Fn+Fx touchpad disable/enable work for not only Dell XPS13 but
>> for all laptops having this trackpad (My Lenovo Ultrabook U300s for
>> example, I tested the patches on fedora 17's 3.6 kernel and it works
>> quiet nice)
>>
>> But what I am not getting that why NOBODY from Cypress/Canonical/Dell
>> isn't bothering to push this driver to upstream?
>
>
> In fact, Canonical is working on preparing the Cypress PS/2 trackpad driver for submitting upstream.
>
>
>> Is it too hard? I don't think so as the patches are quite non-invasive
>> and small.
>
>
> Your estimate of the work/risk involved not withstanding, I chose to deploy this experimental driver in stages -- first in the oem-specific "Sputnik project" kernel, then (recently) in the main Ubuntu kernel, then finally (soon) upstream -- so as to minimize regressions while shaking out the bugs.  For example, the version to which you linked does include a regression (breaks some ALPS touchpads) which we discovered only after deploying in Ubuntu.
>
> I expect to submit the Cypress driver upstream within two weeks.  Of course, my work on the driver is (and has been) publicly available[1].
>
> -Kamal Mostafa <kamal@canonical.com>
>
> [1] The latest version of this driver is represented by the patch set:
>    http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-quantal.git&a=search&h=HEAD&st=commit&s=Cypress+PS%2F2
>
>
>>
>> Is the only distribution around is Ubuntu?
>> Is the only laptop sold in the world is Dell XPS13 with an Ubuntu?
>>
>> I'm not trying to be impolite but it hurts me to see that a vendor
>> produces an open-source driver for its device but makes use of it only
>> through a specific distribution.
>>
>> If Cypress is just beginning developing open-source drivers for their
>> devices, I hope that after this mail they will be much sensitive about
>> the issue and push their drivers even before the release of their
>> devices to make user experience flawless.
>>
>> (I googled and searched the archives of LKML and linux-input but
>> couldn't find a discussion or patch series about the driver. If I
>> missed it, ignore the whole stuff above)
>>
>> [0]: http://patchwork.ozlabs.org/patch/178903/
>

This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.

Re: Why Cypress does not upstream its trackpad driver?

[David Daney]

On 11/07/2012 03:30 PM, David Solda wrote:
> Kamal,
>
> My name is Dave Solda and I would be happy to answer any other questions that you have. Troy's response is correct however as in order to support the default Linux mouse class, our firmware would also have to be modified to do so, which cannot be done in system. Our packet protocol maxes out at an 8 byte packet, which requires a change to the Linux standard in this case.
>
> Our goal in working with canonical was to provide something on Linux that would support multi-touch and not only have default single finger movement supported.
>
> If I am mistaken and he Linux kernel would accept this, then we can proceed to upstream, however all indications we have is that this patch would be rejected.  If you (or others on from the locus alias) have any inputs, I would be happy to receive them.
>

Really you should ask yourselves:

1) What benefit do you enjoy by keeping the code out of the upstream kernel?

2) What are the benefits of having a driver for your hardware in the 
upstream kernel?

If 2 > 1, then the course of action seems obvious.

Doing nothing because of some perceived impediment doesn't help anybody.

David Daney

> Dave
>
>
>
> On Nov 8, 2012, at 7:13 AM, "Troy Abercrombia" <ta@cypress.com> wrote:
>
>> Hello Kamal
>>
>> Unfortunately, We're not able to upstream the driver as it would be denied because it changes the Linux mouse structure framework.
>>
>> Thanks
>> Troy
>> -----Original Message-----
>> From: Kamal Mostafa [mailto:kamal@canonical.com]
>> Sent: Wednesday, November 07, 2012 10:32 AM
>> To: Ozan Çağlayan
>> Cc: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org; dmitry.torokhov@gmail.com; customercare; mario_limonciello@dell.com
>> Subject: Re: Why Cypress does not upstream its trackpad driver?
>>
>> On Tue, 2012-11-06 at 17:47 -0500, Ozan Çağlayan wrote:
>>> Hi,
>>>
>>> This driver [0] was written with a cooperation of Cypress, Dell and
>>> Canonical Engineers within the last 3-4 months. It is very nice that
>>> Cypress as a vendor cooperated with Canonical (Because Canonical works
>>> with Dell for their Project Sputnik and Dell XPS13 is used as the main
>>> hardware for that project and Dell XPS13 has this type of trackpad,
>>> Bingo!), and I am also glad that Ubuntu users benefits from this
>>> driver.
>>>
>>> The driver brings multi-touch scrolling, disable-while-tapping and
>>> makes Fn+Fx touchpad disable/enable work for not only Dell XPS13 but
>>> for all laptops having this trackpad (My Lenovo Ultrabook U300s for
>>> example, I tested the patches on fedora 17's 3.6 kernel and it works
>>> quiet nice)
>>>
>>> But what I am not getting that why NOBODY from Cypress/Canonical/Dell
>>> isn't bothering to push this driver to upstream?
>>
>>
>> In fact, Canonical is working on preparing the Cypress PS/2 trackpad driver for submitting upstream.
>>
>>
>>> Is it too hard? I don't think so as the patches are quite non-invasive
>>> and small.
>>
>>
>> Your estimate of the work/risk involved not withstanding, I chose to deploy this experimental driver in stages -- first in the oem-specific "Sputnik project" kernel, then (recently) in the main Ubuntu kernel, then finally (soon) upstream -- so as to minimize regressions while shaking out the bugs.  For example, the version to which you linked does include a regression (breaks some ALPS touchpads) which we discovered only after deploying in Ubuntu.
>>
>> I expect to submit the Cypress driver upstream within two weeks.  Of course, my work on the driver is (and has been) publicly available[1].
>>
>> -Kamal Mostafa <kamal@canonical.com>
>>
>> [1] The latest version of this driver is represented by the patch set:
>>     http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-quantal.git&a=search&h=HEAD&st=commit&s=Cypress+PS%2F2
>>
>>
>>>
>>> Is the only distribution around is Ubuntu?
>>> Is the only laptop sold in the world is Dell XPS13 with an Ubuntu?
>>>
>>> I'm not trying to be impolite but it hurts me to see that a vendor
>>> produces an open-source driver for its device but makes use of it only
>>> through a specific distribution.
>>>
>>> If Cypress is just beginning developing open-source drivers for their
>>> devices, I hope that after this mail they will be much sensitive about
>>> the issue and push their drivers even before the release of their
>>> devices to make user experience flawless.
>>>
>>> (I googled and searched the archives of LKML and linux-input but
>>> couldn't find a discussion or patch series about the driver. If I
>>> missed it, ignore the whole stuff above)
>>>
>>> [0]: http://patchwork.ozlabs.org/patch/178903/
>>
>
> This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{����zX��\x17��ܨ}���Ơz�&j:+v���\a����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f��^jǫy�m��@A�a��\x7f�\f0��h�\x0f�i\x7f
>

--
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: Why Cypress does not upstream its trackpad driver?

[Dmitry Torokhov]

Hi David,

On Wednesday, November 07, 2012 06:30:11 PM David Solda wrote:
> Kamal,
> 
> My name is Dave Solda and I would be happy to answer any other questions
> that you have. Troy's response is correct however as in order to support
> the default Linux mouse class, our firmware would also have to be modified
> to do so, which cannot be done in system. Our packet protocol maxes out at
> an 8 byte packet, which requires a change to the Linux standard in this
> case.

I am unable to parse this... I do not believe anyone asks you to change
your firmware and if your protocol needs 8 bytes to transmit device state -
that's fine.

> Our goal in working with canonical was to provide something on Linux that
> would support multi-touch and not only have default single finger movement
> supported.
 
> If I am mistaken and he Linux kernel would accept this, then we can proceed
> to upstream, however all indications we have is that this patch would be
> rejected.  If you (or others on from the locus alias) have any inputs, I
> would be happy to receive them.

This really depends on whether the changes to the psmouse framework make
sense or not. Please start submitting patches for review/discussion and
we can go from there.

Thanks.

-- 
Dmitry

RE: Why Cypress does not upstream its trackpad driver?

[David Solda]

Dmitry, all,

To clarify my comment.  Our protocol utilizes 8 bytes which are needed in our driver.  In order for the Linux system to accept 8 bytes of data, the Linux psmouse system driver is required to be modified.  Without this modification, the driver that you are referring to will not work correctly.  The psmouse system driver change that would be required is the item that would be rejected.

I appreciate your comments and of course, if the driver could be upstreamed, it would (we already have I2C drivers updstreamed for Chrome systems), but there is a difference here.

I will again look into the possibility of what you are requesting, however, the changes are extremely low if not zero that it will be accepted.

Dave

-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Wednesday, November 07, 2012 4:16 PM
To: David Solda
Cc: Troy Abercrombia; Kamal Mostafa; Ozan Çağlayan; linux-kernel@vger.kernel.org; linux-input@vger.kernel.org; customercare; mario_limonciello@dell.com
Subject: Re: Why Cypress does not upstream its trackpad driver?

Hi David,

On Wednesday, November 07, 2012 06:30:11 PM David Solda wrote:
> Kamal,
>
> My name is Dave Solda and I would be happy to answer any other
> questions that you have. Troy's response is correct however as in
> order to support the default Linux mouse class, our firmware would
> also have to be modified to do so, which cannot be done in system. Our
> packet protocol maxes out at an 8 byte packet, which requires a change
> to the Linux standard in this case.

I am unable to parse this... I do not believe anyone asks you to change your firmware and if your protocol needs 8 bytes to transmit device state - that's fine.

> Our goal in working with canonical was to provide something on Linux
> that would support multi-touch and not only have default single finger
> movement supported.

> If I am mistaken and he Linux kernel would accept this, then we can
> proceed to upstream, however all indications we have is that this
> patch would be rejected.  If you (or others on from the locus alias)
> have any inputs, I would be happy to receive them.

This really depends on whether the changes to the psmouse framework make sense or not. Please start submitting patches for review/discussion and we can go from there.

Thanks.

--
Dmitry

This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
--
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: Why Cypress does not upstream its trackpad driver?

[Ben Gamari]

David Solda <dso@cypress.com> writes:

> Dmitry, all,
>
> To clarify my comment.  Our protocol utilizes 8 bytes which are needed
> in our driver.  In order for the Linux system to accept 8 bytes of
> data, the Linux psmouse system driver is required to be modified.
> Without this modification, the driver that you are referring to will
> not work correctly.  The psmouse system driver change that would be
> required is the item that would be rejected.
>
> I appreciate your comments and of course, if the driver could be
> upstreamed, it would (we already have I2C drivers updstreamed for
> Chrome systems), but there is a difference here.
>
> I will again look into the possibility of what you are requesting,
> however, the changes are extremely low if not zero that it will be
> accepted.
>
You are speaking to the people who ultimately decide whether your change
will be accepted or not. Currently there is no way anyone could know
whether the desired change is acceptable as no patch has been
submitted. 

Send a patch with the (minimal, well-organized) needed changes and the
matter can be discussed from there. If the changes are sane and well
justified, then there's little reason why they can't be accepted.

Cheers,

- Ben

Re: Why Cypress does not upstream its trackpad driver?

[Dmitry Torokhov]

On Wed, Nov 07, 2012 at 10:45:31PM -0500, Ben Gamari wrote:
> David Solda <dso@cypress.com> writes:
> 
> > Dmitry, all,
> >
> > To clarify my comment.  Our protocol utilizes 8 bytes which are needed
> > in our driver.  In order for the Linux system to accept 8 bytes of
> > data, the Linux psmouse system driver is required to be modified.
> > Without this modification, the driver that you are referring to will
> > not work correctly.  The psmouse system driver change that would be
> > required is the item that would be rejected.
> >
> > I appreciate your comments and of course, if the driver could be
> > upstreamed, it would (we already have I2C drivers updstreamed for
> > Chrome systems), but there is a difference here.
> >
> > I will again look into the possibility of what you are requesting,
> > however, the changes are extremely low if not zero that it will be
> > accepted.
> >
> You are speaking to the people who ultimately decide whether your change
> will be accepted or not. Currently there is no way anyone could know
> whether the desired change is acceptable as no patch has been
> submitted. 
> 
> Send a patch with the (minimal, well-organized) needed changes and the
> matter can be discussed from there. If the changes are sane and well
> justified, then there's little reason why they can't be accepted.

OK, so I looked at the psmouse changes briefly and indeed some of them
will not be accepted, because they are really ... weird. Surely if your
device produces command responses in excess of 6 bytes that is currently
the limit in libps2 module the easiest way would be increasing the
buffer in struct ps2dev.

The rest of psnouse-base changes are OK (and indeed because protocol
types are exported to userspace and thus form ABI new definitions has to
go to the end of the list); the driver itself needs bunch cleanups.
Henrik needs to see it as well.

It looks like you are trying to implement both relative and absolute
modes of operation, but we only want absolute as it provides best
experience.

Please post the patches and we'll go form there.

Thanks.

-- 
Dmitry

RE: Why Cypress does not upstream its trackpad driver?

[David Solda]

Dmitry,

The change you are referring to is the one that I was mentioning.

The "absolute mode" is the only mode of our module that produces multiple fingers.  We do not communicate relative position for more than one finger.  The 8 byte packet is only used in the Absolute Mode, you are right, however, this packet contains the necessary information for determining the position of 2 fingers on the Trackpad.  Hence the reason why I stated that a Firmware change (complete architectural and protocol rewrite) on our side would be need to comply with the 6 byte maximum limit.

So, the only method that I have available right now to upstream something that wouldn't be rejected (as you stated below) is either an architectural overhaul (which I cannot launch at this time), or single finger position tracking only.

Any other thoughts are appreciated, but the 8 bytes packet is needed for our multi-finger detection and communication scheme that is implemented.

Dave

-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Wednesday, November 07, 2012 11:42 PM
To: Ben Gamari
Cc: David Solda; Troy Abercrombia; Kamal Mostafa; Ozan Çağlayan; linux-input@vger.kernel.org; customercare; mario_limonciello@dell.com
Subject: Re: Why Cypress does not upstream its trackpad driver?

On Wed, Nov 07, 2012 at 10:45:31PM -0500, Ben Gamari wrote:
> David Solda <dso@cypress.com> writes:
>
> > Dmitry, all,
> >
> > To clarify my comment.  Our protocol utilizes 8 bytes which are
> > needed in our driver.  In order for the Linux system to accept 8
> > bytes of data, the Linux psmouse system driver is required to be modified.
> > Without this modification, the driver that you are referring to will
> > not work correctly.  The psmouse system driver change that would be
> > required is the item that would be rejected.
> >
> > I appreciate your comments and of course, if the driver could be
> > upstreamed, it would (we already have I2C drivers updstreamed for
> > Chrome systems), but there is a difference here.
> >
> > I will again look into the possibility of what you are requesting,
> > however, the changes are extremely low if not zero that it will be
> > accepted.
> >
> You are speaking to the people who ultimately decide whether your
> change will be accepted or not. Currently there is no way anyone could
> know whether the desired change is acceptable as no patch has been
> submitted.
>
> Send a patch with the (minimal, well-organized) needed changes and the
> matter can be discussed from there. If the changes are sane and well
> justified, then there's little reason why they can't be accepted.

OK, so I looked at the psmouse changes briefly and indeed some of them will not be accepted, because they are really ... weird. Surely if your device produces command responses in excess of 6 bytes that is currently the limit in libps2 module the easiest way would be increasing the buffer in struct ps2dev.

The rest of psnouse-base changes are OK (and indeed because protocol types are exported to userspace and thus form ABI new definitions has to go to the end of the list); the driver itself needs bunch cleanups.
Henrik needs to see it as well.

It looks like you are trying to implement both relative and absolute modes of operation, but we only want absolute as it provides best experience.

Please post the patches and we'll go form there.

Thanks.

--
Dmitry

This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
--
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: Why Cypress does not upstream its trackpad driver?

[Ozan Çağlayan]

On Thu, Nov 8, 2012 at 10:09 AM, David Solda <dso@cypress.com> wrote:

>
> Any other thoughts are appreciated, but the 8 bytes packet is needed for our multi-finger detection and communication scheme that is implemented.
>
> Dave

I'm glad that I've created some sort of molecular excitation by
heating up the peoples involved ;) Hope to see the patches around.

Thanks all.
Ozan Caglayan

Re: Why Cypress does not upstream its trackpad driver?

[Dmitry Torokhov]

David,

On Thu, Nov 08, 2012 at 03:09:36AM -0500, David Solda wrote:
> Dmitry,
> 
> The change you are referring to is the one that I was mentioning.
> 
> The "absolute mode" is the only mode of our module that produces
> multiple fingers.  We do not communicate relative position for more
> than one finger.  The 8 byte packet is only used in the Absolute Mode,
> you are right, however, this packet contains the necessary information
> for determining the position of 2 fingers on the Trackpad.  Hence the
> reason why I stated that a Firmware change (complete architectural and
> protocol rewrite) on our side would be need to comply with the 6 byte
> maximum limit.
> 
> So, the only method that I have available right now to upstream
> something that wouldn't be rejected (as you stated below) is either an
> architectural overhaul (which I cannot launch at this time), or single
> finger position tracking only.
> 
> Any other thoughts are appreciated, but the 8 bytes packet is needed
> for our multi-finger detection and communication scheme that is
> implemented.
> 

First of all, please do not top-post.

I thought I was clear that if you need 8-byte packets just change size
in struct ps2dev to be 8 bytes instead of current 6 and as far as I can
see that will solve your problem. There is no need to change firmware,
re-architecture protocol or doing anything else.

Thanks.

-- 
Dmitry

Re: Why Cypress does not upstream its trackpad driver?

[Robert Hancock]

On 11/07/2012 06:26 PM, David Solda wrote:
> Dmitry, all,
>
> To clarify my comment.  Our protocol utilizes 8 bytes which are needed in our driver.  In order for the Linux system to accept 8 bytes of data, the Linux psmouse system driver is required to be modified.  Without this modification, the driver that you are referring to will not work correctly.  The psmouse system driver change that would be required is the item that would be rejected.
>
> I appreciate your comments and of course, if the driver could be upstreamed, it would (we already have I2C drivers updstreamed for Chrome systems), but there is a difference here.
>
> I will again look into the possibility of what you are requesting, however, the changes are extremely low if not zero that it will be accepted.

Why? If drivers were kept out of the kernel because the hardware they 
are designed to run requires strange things or was badly designed, there 
would be a lot fewer drivers in the kernel than there are today. 
Firmware and hardware frequently does bizarre or nonsensical things and 
we just have to deal with it.

>
> Dave
>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Wednesday, November 07, 2012 4:16 PM
> To: David Solda
> Cc: Troy Abercrombia; Kamal Mostafa; Ozan Çağlayan; linux-kernel@vger.kernel.org; linux-input@vger.kernel.org; customercare; mario_limonciello@dell.com
> Subject: Re: Why Cypress does not upstream its trackpad driver?
>
> Hi David,
>
> On Wednesday, November 07, 2012 06:30:11 PM David Solda wrote:
>> Kamal,
>>
>> My name is Dave Solda and I would be happy to answer any other
>> questions that you have. Troy's response is correct however as in
>> order to support the default Linux mouse class, our firmware would
>> also have to be modified to do so, which cannot be done in system. Our
>> packet protocol maxes out at an 8 byte packet, which requires a change
>> to the Linux standard in this case.
>
> I am unable to parse this... I do not believe anyone asks you to change your firmware and if your protocol needs 8 bytes to transmit device state - that's fine.
>
>> Our goal in working with canonical was to provide something on Linux
>> that would support multi-touch and not only have default single finger
>> movement supported.
>
>> If I am mistaken and he Linux kernel would accept this, then we can
>> proceed to upstream, however all indications we have is that this
>> patch would be rejected.  If you (or others on from the locus alias)
>> have any inputs, I would be happy to receive them.
>
> This really depends on whether the changes to the psmouse framework make sense or not. Please start submitting patches for review/discussion and we can go from there.
>
> Thanks.
>
> --
> Dmitry
>
> This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
> --
> 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
>

--
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: Why Cypress does not upstream its trackpad driver?

[Cruz Julian Bishop]

On 08/11/12 10:26, David Solda wrote:
> Dmitry, all,
>
> To clarify my comment.  Our protocol utilizes 8 bytes which are needed in our driver.  In order for the Linux system to accept 8 bytes of data, the Linux psmouse system driver is required to be modified.  Without this modification, the driver that you are referring to will not work correctly.  The psmouse system driver change that would be required is the item that would be rejected.

In this case, would a solution that involves submitting two separate 
patches be suitable?

For example, an initial patch set to psmouse that allows an arbitrary 
number of bytes be
  (accepted? used?), while keeping a default value to allow the other 
old drivers to keep working,
and then another patch set with the new driver utilizing the first patch 
set?

Sorry if this doesn't make any sense - I've been working with generics 
and abstract class structure
in Java for the last few weeks, and forget what parts are possible in C 
and which parts are not.

Keep up the good work. Even if it's a driver that needs a change, it's 
still an open-source driver! Be happy :)

>
> I appreciate your comments and of course, if the driver could be upstreamed, it would (we already have I2C drivers updstreamed for Chrome systems), but there is a difference here.
>
> I will again look into the possibility of what you are requesting, however, the changes are extremely low if not zero that it will be accepted.
>
> Dave
>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Wednesday, November 07, 2012 4:16 PM
> To: David Solda
> Cc: Troy Abercrombia; Kamal Mostafa; Ozan Çağlayan; linux-kernel@vger.kernel.org; linux-input@vger.kernel.org; customercare; mario_limonciello@dell.com
> Subject: Re: Why Cypress does not upstream its trackpad driver?
>
> Hi David,
>
> On Wednesday, November 07, 2012 06:30:11 PM David Solda wrote:
>> Kamal,
>>
>> My name is Dave Solda and I would be happy to answer any other
>> questions that you have. Troy's response is correct however as in
>> order to support the default Linux mouse class, our firmware would
>> also have to be modified to do so, which cannot be done in system. Our
>> packet protocol maxes out at an 8 byte packet, which requires a change
>> to the Linux standard in this case.
> I am unable to parse this... I do not believe anyone asks you to change your firmware and if your protocol needs 8 bytes to transmit device state - that's fine.
>
>> Our goal in working with canonical was to provide something on Linux
>> that would support multi-touch and not only have default single finger
>> movement supported.
>> If I am mistaken and he Linux kernel would accept this, then we can
>> proceed to upstream, however all indications we have is that this
>> patch would be rejected.  If you (or others on from the locus alias)
>> have any inputs, I would be happy to receive them.
> This really depends on whether the changes to the psmouse framework make sense or not. Please start submitting patches for review/discussion and we can go from there.
>
> Thanks.
>
> --
> Dmitry
>
> This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
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