On Thu, Nov 17, 2011 at 04:12:38PM -0000, drem wrote:
> The input devices are as they should in my previous post (re-checked).
> My programming skills in general (and kernel in particular) are VERY basic. I added this line:
> printk("\nalps.c: raw data: %x", psmouse->packet[psmouse->pktcnt - 1]);
> where you told me; recompiled and looked at dmesg. I noticed "ff" starts a group of 6 so I separated them.
> Results are in raw_alps_xt
That's perfect, thanks.
I think the trackstick data starts two packets after what you
identified, i.e. the packets ending with 0x7f. The touchpad data looks
vary much like what I called a version 2 device in my recent updates to
the ALPS driver, and since you say it works fine I think it's safe to
assume that it's the same format. The trackstick data doesn't seem to
match the expected format for these devices though, and I can see why
the stray clicks are being generated. The question is whether there's
some missing initialization to get it into the expected format or if the
trackstick format will have to be reverse engineered. Either one is a
bit of a trial-and-error process, and it will be difficult for me to
help you much without having hardware to work with myself. I think
reverse-engineering the packet format is probably easier (watch how the
raw data changes as you move the trackstick in different directions and
try to determine which parts of the data correspond to which pieces of
information).
There is one technique you might be able to try to see if some kind of
different initialization is needed. If you have a copy of windows you
can install it in a virtual machine using a modified version of qemu or
virtualbox, install the Dell driver for your hardware, and sniff the
PS/2 protocol data being passed between the touchpad and the Windows
driver. I'll work on getting some instructions for doing this written up
and post a link to it when I'm finished in case you're interested in
trying it.
I do think you should leave out the ALPS_PS2_INTEREAVED. I don't think
it's needed, and there's a slight chance it could cause errors in some
cases.
On Thu, Nov 17, 2011 at 04:12:38PM -0000, drem wrote: >packet[ psmouse- >pktcnt - 1]);
> The input devices are as they should in my previous post (re-checked).
> My programming skills in general (and kernel in particular) are VERY basic. I added this line:
> printk("\nalps.c: raw data: %x", psmouse-
> where you told me; recompiled and looked at dmesg. I noticed "ff" starts a group of 6 so I separated them.
> Results are in raw_alps_xt
That's perfect, thanks.
I think the trackstick data starts two packets after what you
identified, i.e. the packets ending with 0x7f. The touchpad data looks
vary much like what I called a version 2 device in my recent updates to
the ALPS driver, and since you say it works fine I think it's safe to
assume that it's the same format. The trackstick data doesn't seem to
match the expected format for these devices though, and I can see why
the stray clicks are being generated. The question is whether there's
some missing initialization to get it into the expected format or if the
trackstick format will have to be reverse engineered. Either one is a
bit of a trial-and-error process, and it will be difficult for me to
help you much without having hardware to work with myself. I think
reverse-engineering the packet format is probably easier (watch how the
raw data changes as you move the trackstick in different directions and
try to determine which parts of the data correspond to which pieces of
information).
There is one technique you might be able to try to see if some kind of
different initialization is needed. If you have a copy of windows you
can install it in a virtual machine using a modified version of qemu or
virtualbox, install the Dell driver for your hardware, and sniff the
PS/2 protocol data being passed between the touchpad and the Windows
driver. I'll work on getting some instructions for doing this written up
and post a link to it when I'm finished in case you're interested in
trying it.
I do think you should leave out the ALPS_PS2_ INTEREAVED. I don't think
it's needed, and there's a slight chance it could cause errors in some
cases.