Summary: | keyboard AutoRepeat option doesn't work | ||
---|---|---|---|
Product: | xorg | Reporter: | Grygoriy I. Fuchedzhy <gfuchedzhy> |
Component: | Input/evdev | Assignee: | Peter Hutterer <peter.hutterer> |
Status: | RESOLVED WONTFIX | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | CC: | pmachata, remi, sworddragon2 |
Version: | 7.4 (2008.09) | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Grygoriy I. Fuchedzhy
2009-10-05 15:09:41 UTC
see bug 17925 comment 38 for a possible workaround (In reply to comment #1) > see bug 17925 comment 38 for a possible workaround > This workaround doesn't work for evdev+hal. Tested with xorg-server 1.7.1 and xf86-input-evdev 2.3.0. Tested again with xorg-server 1.7.3 and xf86-input-evdev 2.3.1 -- no luck :( I see this problem too. I set a crazy repeat values: # lshal | sed -n '/input.product.*Keyboard/,+5p' input.product = 'Dell Dell USB Keyboard' (string) input.x11_driver = 'evdev' (string) input.x11_options.AutoRepeat = '1000 250' (string) input.xkb.layout = 'us,cz,ru' (string) input.xkb.model = 'evdev' (string) input.xkb.options = 'terminate:ctrl_alt_bksp,grp:switch,grp:alt_shift_toggle,grp_led:scroll' (string) ... yet the keyboard, when unplugged and re-plugged, has some sort of default repeat ratio. I took a peek in the sources. config/hal.c:device_added doesn't name that option explicitly (it does so for layout, model, etc.), but it sticks it into its option array anyway. NewInputDeviceRequest then adds all these options to IDevRec::commonOptions. hw/xfree86/common/xf86Option.c:xf86CollectInputOptions then copies this over to InputInfoPtr::config. Then I gave up, `config' is mentioned in too many places for me to sift through. That's all on Fedora 12, but has been the case since Fedora 11. Versions of packages that strike me as relevant: xorg-x11-server-common-1.7.1-7.fc12.x86_64 xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64 xorg-x11-drv-keyboard-1.4.0-2.fc12.x86_64 xorg-x11-drv-evdev-2.3.1-2.fc12.x86_64 xorg-x11-xkb-utils-7.4-6.fc12.x86_64 I hope you guys can apply educated guesses to match these to your components and their versions, I have very little idea how X packaging works. (In particular, the problem is that X doesn't get these settings after the computer wakes up from suspend. I can use xset just fine, but that doesn't apply the setting for new keyboards, and after suspend, all keyboards are essentially considered new.) (In reply to comment #5) > ...after the computer wakes up from suspend... > Suspend to ram/wake up doesn't modify keyboard rate on my machine. this option was only present in the keyboard driver and was removed before the keyboard-1.4.0 release. this option is simply uninterpreted now. for keyboard repeat settings, you need the session to set it for you, we now completely rely on the server for repeat keys, not on the driver hacks. sorry. (In reply to comment #7) > for keyboard repeat settings, you need the session to set it for you, we now > completely rely on the server for repeat > keys, not on the driver hacks. sorry. Ok, so what should I add to xorg.conf or xorg.conf.d/... to set keyboard rate to custom value? My current solution is 'xset r ...' in .xinitrc (In reply to comment #8) > Ok, so what should I add to xorg.conf or xorg.conf.d/... to set keyboard rate > to custom value? My current solution is 'xset r ...' in .xinitrc there is no xorg.conf option for this anymore, sorry. xset and whatever tools the desktop environment provide are the only option for now. > this option was only present in the keyboard driver and was removed before the > keyboard-1.4.0 release.
> this option is simply uninterpreted now. for keyboard repeat settings, you need > the session to set it for you, we now completely rely on the server for repeat > keys, not on the driver hacks. sorry.
Hasn't the server access to xorg.conf too? It would be really nice to have this option again if this would be technically possible in the way xorg is programmed. Otherwise I must look for another solution, likely with udev to catch even hotplug events.
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.