Hi Dmitry, On Fri, Aug 5, 2011 at 4:24 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: > I've started looking at this, but my first problem is that when the > input layer asks atkbd to turn off LEDs, atkbd schedules a workqueue > item to undertake this work. However, as there is no synchronization, > this work only seems to get executed during or after system resume. > This makes it hard to catch with such a scheme. Any ideas? I've looked closer, and am keeping my eyes open for other options too. During suspend of the input layer, input_dev_suspend() calls input_dev_toggle(dev, false) which turns off LEDs and sounds. On the XO laptops, we don't have LEDs, nor sounds, and we don't have num lock, scroll lock or caps lock keys. So the suspend code does nothing - there are no lights to turn off. So far so good. Moving to the resume case: input_dev_resume() calls input_reset_device(). This calls input_dev_toggle(dev, true), which asks atkbd to turn the non-existent keyboard LEDs off. I guess this is harmless and is unlikely to be the cause of the problems which led us to need to disable this code in light of the following: After calling input_dev_toggle(), input_dev_resume() does this: /* * Keys that have been pressed at suspend time are unlikely * to be still pressed when we resume. */ spin_lock_irq(&dev->event_lock); input_dev_release_keys(dev); spin_unlock_irq(&dev->event_lock); We definitely don't want this to happen in our case, where we have maintained full control and power of the device during suspend/resume. This particular important code snippet would not even have been disabled by your suggestion of blocking data transfer at the i8042-level. So, I think we need a new approach at solving this, and I think it has to be one that interacts at the input_dev layer. Thoughts? Thanks, Daniel -- 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
