Found the problem with the 2.6.29 N810 keyboard regression in this commit:
commit c83702a764c3099df50f215b8e79e07344e34a1a
Author: Felipe Balbi <[email protected]>
Date: Thu Feb 19 12:29:40 2009 +0000
input: lm8323: get rid of useless debug macro
we can use dev_vdbg() which is only true when VERBOSE is enabled.
Part of this commit removed the "default" values for platform parameters, but
set the N810's size_y to 8 instead of the earlier default of 12. Changing this
to 12 (patch to follow) fixes the keyboard regression. Note, the total keys on
the N810 is in fact under 64, so 8x8 seems correct. Not sure why it doesn't
work like that in practise. I did notice a curious line in the driver that
might (or might not) be related/wrong...
drivers/input/keyboard/lm8323.c line 353:
int keysize = (lm->size_x << 4) | lm->size_y;
Shouldn't this be lm->size_x * lm->size_y?
Luke
On Sat, Jun 06, 2009 at 11:51:34PM +0200, ext Luke-Jr wrote:
> Found the problem with the 2.6.29 N810 keyboard regression in this commit:
> commit c83702a764c3099df50f215b8e79e07344e34a1a
> Author: Felipe Balbi <[email protected]>
> Date: Thu Feb 19 12:29:40 2009 +0000
> input: lm8323: get rid of useless debug macro
> we can use dev_vdbg() which is only true when VERBOSE is enabled.
>
> Part of this commit removed the "default" values for platform parameters, but
> set the N810's size_y to 8 instead of the earlier default of 12. Changing this
> to 12 (patch to follow) fixes the keyboard regression. Note, the total keys on
> the N810 is in fact under 64, so 8x8 seems correct. Not sure why it doesn't
> work like that in practise. I did notice a curious line in the driver that
> might (or might not) be related/wrong...
>
> drivers/input/keyboard/lm8323.c line 353:
> int keysize = (lm->size_x << 4) | lm->size_y;
>
> Shouldn't this be lm->size_x * lm->size_y?
Are you sure that was the commit that changed it ?
that commit is only getting rid of the debug() macro and making use of
dev_vdbg().
If you had just followed git blame you'd see that was already the
default value on n810's lm8323 platform_data since the initial import of
that code into linux-omap.
I do recall testing my patches on n810 before sending them upstream and
they were working. How are you testing this ? which tree are you using ?
did you try changing that keysize calculation ? Do you see irqs comming?
Any debugging messages ?
--
balbi
On Saturday 06 June 2009 05:42:04 pm Felipe Balbi wrote:
> Are you sure that was the commit that changed it ?
> that commit is only getting rid of the debug() macro and making use of
> dev_vdbg().
Oops, looks like I put the wrong commit at fault. The correct one is:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-
omap-2.6.git;a=commit;h=bb739803dce613ed58e8b35ae52af439ab7496bf
> If you had just followed git blame you'd see that was already the
> default value on n810's lm8323 platform_data since the initial import of
> that code into linux-omap.
According to the removed code in the above commit, the default value (outside
of and not specified in n810's lm8323 platform_data) was 12.
> I do recall testing my patches on n810 before sending them upstream and
> they were working. How are you testing this ? which tree are you using ?
I am testing the latest Linux-OMAP kernel on my N810 with Nokia's flasher and
--load --boot options. (Userspace is Gentoo)
> did you try changing that keysize calculation ?
No, I wanted to get the opinion of someone who knows how that code actually is
supposed to work before I try randomly changing things I don't understand.
> Do you see irqs comming? Any debugging messages ?
There were no debugging messages when the broken keys were pressed, nor did a
dbg I added to the driver get triggered for them.
Luke
Hi,
On Sun, Jun 07, 2009 at 01:15:35AM +0200, ext Luke-Jr wrote:
> > did you try changing that keysize calculation ?
>
> No, I wanted to get the opinion of someone who knows how that code actually is
> supposed to work before I try randomly changing things I don't understand.
>
> > Do you see irqs comming? Any debugging messages ?
>
> There were no debugging messages when the broken keys were pressed, nor did a
> dbg I added to the driver get triggered for them.
looks like we're gonna need one of the original writes to take a look at
this. I don't know the chip that well and don't have enough time to look
for the docs...
but I still suggest you try changing that line and see what happens
though
--
balbi