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@xxxxxxxxx] Sent: Wednesday, November 07, 2012 11:42 PM To: Ben Gamari Cc: David Solda; Troy Abercrombia; Kamal Mostafa; Ozan Çağlayan; linux-input@xxxxxxxxxxxxxxx; customercare; mario_limonciello@xxxxxxxx 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
