From: Stelian Pop <stelian@popies.net>
To: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: linuxppc-dev@ozlabs.org, johannes@sipsolutions.net,
debian-powerpc@lists.debian.org,
linux-kernel <linux-kernel@vger.kernel.org>,
Parag Warudkar <kernel-stuff@comcast.net>
Subject: Re: PowerBook5,8 - TrackPad update
Date: Fri, 02 Dec 2005 15:28:31 +0100 [thread overview]
Message-ID: <1133533712.23129.25.camel@localhost.localdomain> (raw)
In-Reply-To: <20051130234653.GB15102@hansmi.ch>
Le jeudi 01 décembre 2005 à 00:46 +0100, Michael Hanselmann a écrit :
> On Wed, Nov 30, 2005 at 11:39:17PM +0100, Michael Hanselmann wrote:
> > The patch is attached for easier use.
>
> There was a mistake in it due to which the mouse button wouldn't work.
> Fixed in the now attached patch.
Is this version really working well on the new Powerbooks ? From what
I've seen in this thread there are still issues and it's still a work in
progress, so it may be too early to integrate the changes in the kernel.
Also, some other comments on the code itself:
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
While the relayfs code is ok for debugging, I'm wondering if it should be left in the final version at all.
+ int is0215; /* is the device a 0x0215? */
No need for that, just use udev->descriptor.idProduct == 0x0215 (in a macro perhaps)
+ int overflowwarn; /* overflow warning printed? */
I would use a static variable in the case -OVERFLOW: block here.
+ dev->xy_cur[i++] = dev->data[19];
+ dev->xy_cur[i++] = dev->data[20];
+ dev->xy_cur[i++] = dev->data[22];
+ dev->xy_cur[i++] = dev->data[23];
There is obviously a pattern here:
for (i = 0; i < 15; i++)
dev->xy_cur[i] = dev->data[ 19 + (i * 3) / 2 ]
I'm wondering if the same formula doesn't apply for more X and Y sensors (like 16 X
and 16 Y sensors on the old Powerbooks, 26 for the 17" models)
+#if 0
+ /* Some debug code */
+ for (i = 0; i < dev->urb->actual_length; i++) {
+ printk("%2x,", (unsigned char)dev->data[i]);
+ }
+ printk("\n");
+#endif
Please dump that.
+ /* Prints the read values */
+ if (debug > 1) {
+ printk("appletouch: X=");
+ for (i = 0; i < 15; i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk(" Y=");
+ for (i = ATP_XSENSORS; i < (ATP_XSENSORS + (9 - 1)); i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk("\n");
+ }
What is the point in doing this since the dbg_dump is called a few lines
later ? Best is to modify dbg_dump to know about the new number of
sensors...
+ printk(KERN_INFO "appletouch: atp_probe found interrupt "
+ "in endpoint: %d\n", int_in_endpointAddr);
Why is this useful to know ?
+ if (dev->is0215) {
+ dev->datalen = 64;
+ } else {
+ dev->datalen = 81;
+ }
Braces are not needed here.
PS: please inline the patch instead of attaching it to the mail, it's
much more easy to quote it that way.
Stelian.
--
Stelian Pop <stelian@popies.net>
WARNING: multiple messages have this Message-ID (diff)
From: Stelian Pop <stelian@popies.net>
To: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: Parag Warudkar <kernel-stuff@comcast.net>,
debian-powerpc@lists.debian.org,
linux-kernel <linux-kernel@vger.kernel.org>,
linuxppc-dev@ozlabs.org, johannes@sipsolutions.net
Subject: Re: PowerBook5,8 - TrackPad update
Date: Fri, 02 Dec 2005 15:28:31 +0100 [thread overview]
Message-ID: <1133533712.23129.25.camel@localhost.localdomain> (raw)
In-Reply-To: <20051130234653.GB15102@hansmi.ch>
Le jeudi 01 décembre 2005 à 00:46 +0100, Michael Hanselmann a écrit :
> On Wed, Nov 30, 2005 at 11:39:17PM +0100, Michael Hanselmann wrote:
> > The patch is attached for easier use.
>
> There was a mistake in it due to which the mouse button wouldn't work.
> Fixed in the now attached patch.
Is this version really working well on the new Powerbooks ? From what
I've seen in this thread there are still issues and it's still a work in
progress, so it may be too early to integrate the changes in the kernel.
Also, some other comments on the code itself:
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
While the relayfs code is ok for debugging, I'm wondering if it should be left in the final version at all.
+ int is0215; /* is the device a 0x0215? */
No need for that, just use udev->descriptor.idProduct == 0x0215 (in a macro perhaps)
+ int overflowwarn; /* overflow warning printed? */
I would use a static variable in the case -OVERFLOW: block here.
+ dev->xy_cur[i++] = dev->data[19];
+ dev->xy_cur[i++] = dev->data[20];
+ dev->xy_cur[i++] = dev->data[22];
+ dev->xy_cur[i++] = dev->data[23];
There is obviously a pattern here:
for (i = 0; i < 15; i++)
dev->xy_cur[i] = dev->data[ 19 + (i * 3) / 2 ]
I'm wondering if the same formula doesn't apply for more X and Y sensors (like 16 X
and 16 Y sensors on the old Powerbooks, 26 for the 17" models)
+#if 0
+ /* Some debug code */
+ for (i = 0; i < dev->urb->actual_length; i++) {
+ printk("%2x,", (unsigned char)dev->data[i]);
+ }
+ printk("\n");
+#endif
Please dump that.
+ /* Prints the read values */
+ if (debug > 1) {
+ printk("appletouch: X=");
+ for (i = 0; i < 15; i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk(" Y=");
+ for (i = ATP_XSENSORS; i < (ATP_XSENSORS + (9 - 1)); i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk("\n");
+ }
What is the point in doing this since the dbg_dump is called a few lines
later ? Best is to modify dbg_dump to know about the new number of
sensors...
+ printk(KERN_INFO "appletouch: atp_probe found interrupt "
+ "in endpoint: %d\n", int_in_endpointAddr);
Why is this useful to know ?
+ if (dev->is0215) {
+ dev->datalen = 64;
+ } else {
+ dev->datalen = 81;
+ }
Braces are not needed here.
PS: please inline the patch instead of attaching it to the mail, it's
much more easy to quote it that way.
Stelian.
--
Stelian Pop <stelian@popies.net>
next prev parent reply other threads:[~2005-12-02 15:00 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 21:43 PowerBook5,8 - TrackPad update Parag Warudkar
2005-11-15 23:06 ` Benjamin Herrenschmidt
2005-11-15 23:12 ` Parag Warudkar
[not found] ` <111520052143.16540.437A5680000BE8A60000409C220076369200009A9B9CD3040A 029D0A05@comcast.net>
2005-11-16 12:02 ` Johannes Berg
2005-11-21 23:57 ` Parag Warudkar
2005-11-21 23:57 ` Parag Warudkar
2005-11-22 0:08 ` Parag Warudkar
2005-11-22 0:08 ` Parag Warudkar
2005-11-22 12:51 ` Johannes Berg
2005-11-22 12:51 ` Johannes Berg
2005-11-29 0:06 ` Michael Hanselmann
2005-11-29 0:06 ` Michael Hanselmann
2005-11-29 6:11 ` Parag Warudkar
2005-11-29 7:50 ` Michael Hanselmann
2005-11-29 7:50 ` Michael Hanselmann
2005-11-29 10:38 ` Johannes Berg
2005-11-29 10:38 ` Johannes Berg
2005-11-29 16:11 ` Parag Warudkar
2005-11-29 16:11 ` Parag Warudkar
2005-11-30 11:17 ` Johannes Berg
2005-11-30 11:17 ` Johannes Berg
2005-11-30 22:39 ` Michael Hanselmann
2005-11-30 22:39 ` Michael Hanselmann
2005-11-30 23:46 ` Michael Hanselmann
2005-11-30 23:46 ` Michael Hanselmann
2005-12-02 14:28 ` Stelian Pop [this message]
2005-12-02 14:28 ` Stelian Pop
2005-12-04 22:42 ` Michael Hanselmann
2005-12-04 22:42 ` Michael Hanselmann
2005-12-06 3:38 ` Andy Botting
2005-12-06 3:38 ` Andy Botting
2005-12-06 21:12 ` Michael Hanselmann
2005-12-06 21:12 ` Michael Hanselmann
2005-12-09 23:33 ` Michael Hanselmann
2005-12-09 23:33 ` Michael Hanselmann
2005-12-23 23:59 ` Benjamin Herrenschmidt
2005-12-23 23:59 ` Benjamin Herrenschmidt
2005-12-24 11:52 ` René Nussbaumer
2005-12-24 11:52 ` René Nussbaumer
2005-12-24 20:17 ` Pavel Machek
2005-12-24 20:17 ` Pavel Machek
2005-12-24 22:27 ` Benjamin Herrenschmidt
2005-12-24 22:27 ` Benjamin Herrenschmidt
2005-12-24 23:19 ` Pavel Machek
2005-12-24 23:19 ` Pavel Machek
2005-12-25 0:33 ` Benjamin Herrenschmidt
2005-12-25 0:33 ` Benjamin Herrenschmidt
2005-12-25 0:52 ` Dmitry Torokhov
2005-12-25 0:52 ` Dmitry Torokhov
-- strict thread matches above, loose matches on Subject: below --
2005-11-16 15:40 Parag Warudkar
2005-11-16 15:43 Parag Warudkar
2005-11-16 15:49 ` Johannes Berg
2005-11-16 16:07 Parag Warudkar
2005-11-16 16:13 ` Johannes Berg
2005-11-29 6:17 Parag Warudkar
2005-12-02 17:02 Parag Warudkar
2005-12-02 17:02 ` Parag Warudkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1133533712.23129.25.camel@localhost.localdomain \
--to=stelian@popies.net \
--cc=debian-powerpc@lists.debian.org \
--cc=johannes@sipsolutions.net \
--cc=kernel-stuff@comcast.net \
--cc=linux-kernel@hansmi.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.