Re: Possible regression: sluggish inputs

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 05/03/2014 07:38 PM, tbilles@gmx.com wrote:
> Hi,
> 
> On Saturday, 03 May 2014 at 10:00:38, Hans de Goede wrote:
> 
>> On 05/02/2014 07:03 PM, Tibor Billes wrote:
>>
>>> Hi,
>>>
>>> I've upgraded my 3.13.5 kernel to 3.14.2 and I noticed that
>>> sometimes my mouse is slow to react. By slow I mean the pointer on
>>> the screen doesn't follow its path smoothly, instead it jumps from
>>> one position to the next at only a few jumps per second rate. Like
>>> if the kernel could only process 2 or 3 position updates per second
>>> from the mouse. (As far as I can tell, the machine is in idle.)
>>> After experimenting a little I found out that the keyboard is also
>>> affected. Keystrokes are delayed, letters appearing in bursts. This
>>> behaviour (for both the mouse and the keyboard) lasts only for a
>>> couple of seconds, then it suddenly goes away and everything works
>>> as expected. I also noticed that this behaviour shows up after I
>>> haven't touched the mouse or the keyboard for short time (around 10
>>> seconds, but I didn't measure this).
>>
>>
>> What I think is happening is that you've auto screen dimming on
>> inactivity enabled in your desktop environment settings, which results
>> in trying to change the backlight after 10 seconds of inactivity. Then
>> the intel video driver likely directly writes to
>> /sys/class/backlight/acpi_video0/brightness and gets stuck in that
>> write because the acpi code gets stuck.
> 
> Did you figure out why the acpi code gets stuck?

No, I can read and write C fluently, and I'm also somewhat versed in the
kernel but debugging actual ACPI code is a skill I've yet to master
(note my patch only touches pure C-code).

> Sounds like it shouldn't do that :)

Agreed.

> I'm not a kernel developer so I can't do much about
> it, I'm just curious.


> 
>> I've seen this happen occasionally on my E6430 both with and without
>> the patch the bisect points too. I can trigger it by pressing
>> brightness up / down as fast as I can. Likely the dimming on
>> inactivity code is doing a much better job at sending brightness
>> change commands as fast as possible, making it easier to trigger this.
>> As for the commit you've bisected it too, it may be that that subtly
>> changes things to make the problem easier to trigger, 
> 
> I don't have auto screen dimming enabled, but there could be something
> else triggering it. Other than this, it all makes sense. The brightness
> up / down buttons always act slowly for me. I can too trigger the sluggish
> behaviour by pressing the brightness up or down buttons fast and
> simultaneously moving the mouse. So yes, your patch is not the cause
> of this, but for some reason it makes it easier to trigger. 
> 
>> but I distinctly remember having the same issue before I wrote that
>> patch.
> 
> Let me try this 'your patch reverted on top of 3.14.2' kernel for a few
> days to see if this behaviour shows up. Maybe I had it too, I just
> didn't notice, because it was less frequent.
> 
>> Have you tried updating your BIOS ?
> 
> No, I haven't. Have you tried it? Did it help? I'm reluctant to upgrade
> my BIOS, I've never done this before. I'm afraid I do something wrong
> and I end up with comupter that is unable to boot.

I've updated my BIOS and things seem to be better, but the issue is not
completely gone.

Regards,

Hans