usb keyboard settings (repeat rate and delay) reset on plugin

Recreatable 100% on Karmic Alpha 6 LiveCD.

$ uname -a
Linux ubuntu 2.6.31-9-generic #29-Ubuntu SMP Sun Aug 30 17:39:26 UTC 2009 x86_64 GNU/Linux

$ gnome-about --version
GNOME gnome-about 2.27.91

$ lsusb | grep Keyboard
Bus 006 Device 004: ID 046d:c503 Logitech, Inc. Cordless Mouse+Keyboard Receiver

Correction, recreatable on Karmic Alpha 5 LiveCD. Haven't tested 6 yet (obviously).

Okay, 100% recreatable on Karmic Alpha 6 LiveCD. (Actually 6, not 5, this time. :-) )

Probably should add the other jazz:

$ uname -a
Linux ubuntu 2.6.31-10-generic #34-Ubuntu SMP Wed Sep 16 01:09:15 UTC 2009 x86_64 GNU/Linux

$ gnome-about --version
GNOME gnome-about 2.27.92

$ lsusb | grep Keyboard
Bus 005 Device 002: ID 046d:c503 Logitech, Inc. Cordless Mouse+Keyboard Receiver

reassigned to package xkeyboard-config

i can confirm this in karmic beta

I also have this same problem on Karmic Beta installing updates daily until Oct. 30.

jon@ubuntu:~/workspace/lrgit$ uname -a
Linux ubuntu 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16
14:05:01 UTC 2009 x86_64 GNU/Linux

jon@ubuntu:~/workspace/lrgit$ gnome-about --version
GNOME gnome-about 2.28.1

jon@ubuntu:~/workspace/lrgit$ lsusb | grep Keyboard
Bus 006 Device 013: ID 0a81:0205 Chesen Electronics Corp.
 PS/2 Keyboard+Mouse Adapter
Bus 006 Device 012: ID 05f3:0007 PI Engineering, Inc. Kin
esis Advantage PRO MPC/USB Keyboard

I have exactly this problem in Karmic (up-to-date) with my wireless external keyboard (Logitech). I think there are keyboards that forget these settings when connection is lost. Sometimes this also occurs after a sleep-resume without unplugging the keyoard.

I wonder how many folks use an external keyboard like this and change their settings? Not /that/ many, I imagine. Too bad that it thus isn't papercut material ... Thanks for checking on this, Oliver.

Yes, I also thought about adding it as papercut. Many users with docking stations might be affected too. But they don't realize it, unless they change the default settings for key delay and rate.

I marked 2 duplicates, and the bugs mentioned in the description of this bug (about changing keyboard layout) might have a similar cause. I hope that gives it enough importance to be fixed for 10.04 (LTS).

I confirm that this bug still exists in Lucid 10.04 alpha 2 (as of 13th January 2010).

This bug happens to me multiple times a day. I then call up the keyboard preferences move the slider a little and move it back, then I can resume work, otherwise the repeat rate is unbearably slow. Does anyone have any idea what the process is for debugging how to fix this? I would look into it myself if I could get a handle on how to debug it. I'm using karmic currently.

As a workaround you may just set the rate again with the command:
  gconftool-2 -s -t int /desktop/gnome/peripherals/keyboard/rate <RATE>
To get the current <RATE> you can do:
  gconftool-2 -g /desktop/gnome/peripherals/keyboard/rate

Each time your keyboard is slow again, you can invoke the first command in a Terminal. Or you can add it as user-defined applet to your gnome panel. Or you can add it in "gnome-volume-properties" as an action to be taken whenever a keyboard is (re-)detected - this is fully automatic then and works best for me. "gnome-volume-properties" can be found in gnome menu "System - Preferences". If not, you may have to install "gnome-volume-manager" first.

The commands have to be on one line only, so try:

gconftool-2 -s -t int /desktop/gnome/peripherals/keyboard/rate 38

Having to enter a command is lame. Especially one with so much pre-knowledge required about what goes on and the path to the setting. Are users expected to search the bug-database with just the right keywords to find this ticket in order to fix this on their setups? If a default action can be created for attaching keyboards, and it indeed fixes the problem, why not at least ship Ubuntu with the action already pre-configured?

My comment #13 does not solve but hide the problem - it is a work-around. The kernel/driver/Xorg is supposed to resend rate and delay when a keyboard hardware lost them due to power loss. I'd call it chaotic to leave this to a user-space program.

Me too, hope a proper fix will make it into 10.04 (LTS). You can help at least by adding yourself as "affected by this bug". If more people are affected, we could add this bug to the 100-papercut-project.

Oliver, you wouldn't happen to know where to report this bug upstream? I've spent about 20 minutes googling around, but I'm not coming up with much luck. However, to get something fixed in a distro, the first thing someone will do is report it upstream. We can at least get the ball rolling if someone knows how/where to do that.

Excellent workaround Oliver, Thanks! That is what I was looking for. For me I first used "xset -q" to find my current keyboard settings and now I use "xset r rate 208 83" in the gnome-volume-properties setting for keyboard command. I was trying to write a udev rule before you commented, but was unsucceful. Kevin, I also think it would be a good idea to get this reported upstream, but I don't know how to do it either. I have googled around about the problem and it seems like it may be a bug in xorg. Some other people have have issues with their modmap files not getting rerun -- it might be related. I have also used the "udevadm monitor" command to watch the notification events when a keyboard is pulled out and inserted.

@Kevin: It is difficult to decide where to report this bug. But I agree, we should do this.
@radostyle: glad to hear it works for you, too! Whether the problems with modmap files are related or not, we should treat this bug isolated, because the fixes might be different.

IMHO xset is a candidate to fix:
  1 xset r rate 300 36 , unplug/replug keyboard , xset q => delay,rate=660,25
  2 after replugging external keyboard becomes 660,25, but internal one stays at 300,36
  3 replugging while in a console (ctrl+alt+F1) doesn't change anything - unless I switch to X (ctrl+alt+F7)!
  4 xset r rate 300 39 , xset q => 300,40 (this is perhaps a hardware limitation)

But this all looks like xset stores the values in the keyboard hardware only and sometimes chooses the wrong (external) one to read them from. If that's right then only gconftool-2 stores these values reliably. Then an udev-rule calling gconftool-2 would be a valid fix, if that's possible at all. I found a solution for a similar issue here: http://ubuntuforums.org/archive/index.php/t-1282582.html

Anyway if you agree, I will report this issue to gnome.org AND freedesktop.org with links to each other, so that well-informed people can help to decide where to fix it.

Oliver, I think you've done some good research. In light of the fact that no one watching this thread seems to know to where to report the bug, I support your idea to report it to both upstream parties. Good idea. Please go for it. Thanks much for your attention to this.

I opened a new bug on freedesktop.org and summarized all facts/links:
https://bugs.freedesktop.org/show_bug.cgi?id=26293

I found and marked another 2 duplicates here on Launchpad. And even on gnome.org there were already 2 duplicates, where I then added a comment:
https://bugzilla.gnome.org/show_bug.cgi?id=585222#c7

Thank you for your kind feedback, Kevin and radostyle!
Now let's hope, a fix will make it into Lucid.

Excellent work, Oliver. Now (don't) spam you're friends and get 'em to mark it "affects me too". ;-)
/me crosses fingers for the Lucid fix

Yeah, it's amazing how much easier (and more fun) it is to help out when folks actually, you know, appreciate your input. :-) It's sometimes hard to be noticeably appreciative over the web, as most communication is text. Good stuff!

On gnome.org a promising fix is discussed. (see https://bugzilla.gnome.org/show_bug.cgi?id=610245)

@Sebastien: please tell, why did you change status back to incomplete? On gnome.org they seem near to fixing it (https://bugzilla.gnome.org/show_bug.cgi?id=610245)

because as stated upstream the bug should be fixed for a while in libxklavier so if users still have the issue it's a different bug

I understand Sergeys comment that libxklavier generates X-new-device events and these events are processed by gnome-settings-daemon. The problem of this bug seems that neither g-s-d nor anything else takes care of reapplying the user settings to a new keyboard. According to Peter Hutterer (https://bugs.freedesktop.org/show_bug.cgi?id=26293#c2) this has to be fixed in gnome.

I think with 4 duplicates and another 2 on gnome.org every aspect of the problem should be clear for status 'Confirmed'. 'Incomplete' would mean 'needs more info', is it?

Meanwhile I can confirm that it is still reproducible with a Live-CD of Lucid alpha 3.

The bug is incomplete because it needs to be sent to GNOME by somebody having the issue, the current GNOME watch is a closed bugs so it needs a new one

The issue is easily reproducable. If you have a second USB keyboard, just attach it and it will have the problem. If you have a notebook with PS/2 internal keyboard, that one will always be the primary keyboard, just attach a second USB keyboard. For example, anyone with a KVM attached to a notebook will have this problem. I've been having it, because I had a second PS/2 keyboard attached to one of my computers, which is then the internal primary keyboard. When I use the KVM, with the USB keyboard attached that I actually use, I will have this issue always when switching computers via the KVM.

It's really sad to see that the more composed of several software projects a Linux distribution is, the harder the struggle for quality assurance, since noone feels responsible or capable to fix even simple bugs.

@stippi: I agree that quality really matters. Recently Ubuntu is more about adding new features and introducing whole frameworks like pulseaudio, rtkit, XAA-EXA-UXA, to name a few. But saying that nobody feels responsible is strange. It's open-source - we all are responsible! And everybody writing on Launchpad already does a good job to improve things.

@Sebastien: the current GNOME watch is 'RESOLVED' / 'FIXED' and Sergey now replied that the patch of Bastien Nocera (https://bugzilla.gnome.org/show_bug.cgi?id=610245#c1) has already been tested successfully! So the status of this bug report should be 'In Progress', isn't it?? And then the fixed g-s-d finally could be included into Lucid.

> Recently Ubuntu is more about adding new features and introducing

not really, those come from upstream and are not really driven by Ubuntu but let's not discuss that there

> has already been tested successfully! So the status of this bug report should be 'In Progress', isn't it??

there is no change upstream which are not in the upstream version, so either the bug is fixed in lucid and should be closed or the issue is not fixed as you seem to suggest and should be reopened in the GNOME bug tracker

Thanks to justify this. Then I will check ASAP, if Bastien Nocera's patch is in g-s-d of latest Lucid.

(You're right - no discussion here about 'features or quality'. Ubuntu as my favorite OS is great in both aspects. I just wanted to encourage stippi and others that if something is bad, every single user or bug comment may help. It's not just the business of a few 'responsible' people)

I checked Bastiens patch, it fixes this bug! For details see https://bugzilla.gnome.org/show_bug.cgi?id=610245#c10

The patch is not in the source of g-s-d 2.29.91.1 (Lucid as of yesterday). I guess it is not yet committed on gnome.org. So we have to wait for that.

thank you for looking at that, the bug is closed because libxklavier is supposed to do the same thing, seems it's buggy though because our version is built using libxi and it doesn't work for you

This bug was fixed in the package gnome-settings-daemon - 2.29.92-0ubuntu2

---------------
gnome-settings-daemon (2.29.92-0ubuntu2) lucid; urgency=low

  * debian/patches/07_dont_display_autostart.patch:
    - don't show the gnome-settings-daemon autostart in the session capplet,
      the description is confusing and it's a required component (lp: #146918)
  * debian/patches/92_keyboard_settings_update.patch:
    - upstream change to apply xkb settings to newly connected keyboards
      (lp: #427168)
 -- Sebastien Bacher <email address hidden> Wed, 10 Mar 2010 00:15:32 +0100

Does this mean there is a place to test this, is a fix in Ubuntu somewhere? Btw, thank you Oliver for all your work on this.

I am glad to be helpful in fixing this bug. A big thank you goes to Bastien Nocera from upstream who did the actual patch to fix this!

@radostyle: Yes, it will be patched with one of the next updates in Lucid (enable lucid-proposed!) and probably also in Karmic (enable karmic-backported!). If you want to test it now, then have a look at https://bugzilla.gnome.org/show_bug.cgi?id=610245#c10

> the next updates in Lucid (enable lucid-proposed!)

lucid is not stable yet so there is no extra source to enable it will go to lucid stock

I am still experiencing this issue in latest updated Xubuntu Maverick. My Xubuntu is only being updated since Feisty - could there be any problem?

I will update my machine in about a week, and will run through this as a test. I always do a fresh install of my system partition rather than the update procedure I gather you've done. I don't expect there to be a difference, but we'll know for sure then.

Darn, I was hoping this would be fixed, especially after Oliver's good work (and upstream too!)

Hi,

It seems that the problem re-appeared with a very recent update in 10.04.2,
with gnome-settings-daemon 2.30.1-0ubuntu1.1

My keyboard looses the keyboard repeat after waking up from suspend.

Yours,
Steffen

the most recent lucid update for gnome-settings-daemon was in novembre, that seems an another issue

Sebastian: right, I was able to confirm that the update 2.6.32-29 -> 2.6.32-30 causes the problem.
I opened #735294 for that.

Yours,
Steffen

Bug is still happening on Ubuntu 20.04.1 LTS.
I'm using an external Apple Alu Keyboard.
The interesting thing is, that repeat rate and delay are correct for the internal keyboard of the notebook but they are wrong for the plugged in keyboard.

If I go into settings and set it again it is correct for this session. But it will be reset on the next time.

I am also experiencing this bug on 20.04.1 LTS.

As with the previous comment, the internal keyboard of the laptop works correctly with the delay/speed settings I've set. However my primary keyboard, a USB keyboard, loses the delay/speed settings once the laptop restarts or resumes from sleep/hibernation.

I can confirm that toggling repeat keys off and on again fixes the issue temporarily for the current session.

> I can confirm that toggling repeat keys off and on again fixes the issue temporarily for the current session.

Also changing the repeat speed.

It would be nice if this toggling would be possible from CLI.
This way I wouldn't have to go in the settings every time my computer woke up from sleep.

@Alexander Adam you can toggle from the cli like so:

xset r rate 250

Replace 250 with your desired repeat rate.

Please can we re-open this issue?

This regression may not get attention because the issue is currently marked as fixed.

I have opened a new bug here: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1910981