lkml.org 
[lkml]   [2014]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Possible regression: sluggish inputs
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


\
 
 \ /
  Last update: 2014-05-03 21:01    [W:0.057 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site