Re: [bisected regression] Touchpad "paste" stops working aftersuspend to RAM

From: Carlos R. Mafra
Date: Tue Oct 13 2009 - 19:21:07 EST


[restoring Cc: list]

On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
>
> Could you please try this patch (again if you could post dmesg that
> would be great). Thank you!

The patch quoted below also fixes the problem. I attached the
syslog with i8042.debug (with a s2ram in the middle) to the
bugzilla:

http://bugzilla.kernel.org/show_bug.cgi?id=14392

(cool! the address above was pasted with the touchpad,
so it is really working :-)

Thanks Dmitry!

>
> Input: atkbd - postpone restoring LED/repeat rate at resume
>
> From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
>
> We need to postpone restoring LED state and typematic settings until
> keyboard is finished reconnecting upon resume. Normally driver core
> and PM infrastructure takes care of proper ordering and dependencies,
> but or case actual reconnect is done asynchronously from kseriod.
> So while driver core thinks that keyboard was resumed and it is time
> to let input core run it's resume handlers in reality keyboard is not
> ready yet. The solution is to keep rescheduling work that adjusts LED
> and rate settings until keyboard is fully enabled.
>
> Reported-by: Carlos R. Mafra <crmafra2@xxxxxxxxx>
> Signed-off-by: Dmitry Torokhov <dtor@xxxxxxx>
> ---
>
> drivers/input/keyboard/atkbd.c | 19 +++++++++++++++----
> 1 files changed, 15 insertions(+), 4 deletions(-)
>
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index a45157d..022f3cb 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -574,11 +574,22 @@ static void atkbd_event_work(struct work_struct *work)
>
> mutex_lock(&atkbd->event_mutex);
>
> - if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
> - atkbd_set_leds(atkbd);
> + if (!atkbd->enabled) {
> + /*
> + * Serio ports are resumed asynchronously so while driver core
> + * thinks that device is already fully operational in reality
> + * it may not be ready yet. In this case we need to keep
> + * rescheduling till reconnect completes.
> + */
> + schedule_delayed_work(&atkbd->event_work,
> + msecs_to_jiffies(100));
> + } else {
> + if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
> + atkbd_set_leds(atkbd);
>
> - if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
> - atkbd_set_repeat_rate(atkbd);
> + if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
> + atkbd_set_repeat_rate(atkbd);
> + }
>
> mutex_unlock(&atkbd->event_mutex);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/