By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1349 - Make keyboard delay easier to make match any common BIOS setting (a multiple of 50)
Summary: Make keyboard delay easier to make match any common BIOS setting (a multiple ...
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.x [Trinity]
Hardware: All All
: P5 enhancement
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2012-11-28 18:28 CST by Felix Miata
Modified: 2018-07-29 09:12 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Preliminary patch to better support keyboard repeat feature (8.37 KB, patch)
2012-12-08 17:18 CST, Darrell 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2012-11-28 18:28:07 CST 
(mostly copied from https://bugs.kde.org/show_bug.cgi?id=279201 )

Most PC BIOS that offer keyboard repeat and delay settings offer delay options only in multiples of 50, so that's what mine are always set to when offered, and what my fingers are used to. I wish all apps to obey this, but naturally KDE couldn't be bothered to respectfully initialize its settings using these values. So the least TDE could do is make it less difficult to match the BIOS. The reason it's hard now, same as as far back as my use of KDE went, more than a decade, is it initialized to 660, more than double the highest value I've ever seen a BIOS offer, and it only increments or decrements via the scroller to change increments of +50/-50 from the current value. To reach 250, either the value window must be selected and then a number typed in, or one must first drag the slider all the way to the left or right to get the value onto a multiple of 50, after which the scroller can be used to shift it to 250. Those who actually want some odd multiple of 10 ought to be the ones who have to take the more difficult steps to reach their goals. For all others the initial value should either start at some multiple of 50, or allow finer scroller adjustments so that 250 can be reached from the initial value using the scroller. Even better would be for TDE to read the BIOS settings and offer them as initial values, or offer a checkbox to simply say use the BIOS settings (and same for NUMLOCK).
Comment 1 Darrell 2012-11-29 14:04:57 CST 
I agree there should be a check box control to use the BIOS that sets the keyboard controls to those values. When that check box is enabled the other controls are disabled/ghosted.

In the mean time:

Changing the repeat increment to 10 is doable.

Changing the default from 660 to 250 is doable.

The changes would be made in tdebase/kxkb/kcmmisc.cpp.
Comment 2 Darrell 2012-11-29 14:06:15 CST 
I agree with adding a radio button control to set NumLock the same as the BIOS.
Comment 3 Darrell 2012-12-08 17:18:54 CST 
Created attachment 1043 [details]
Preliminary patch to better support keyboard repeat feature

I created a preliminary patch. Some observations and comments:

* The defaults in X are 500 msec delay and 30 characters/sec. Seems those are reasonable numbers to set as defaults in Trinity too. Unlike 660, 500 is a multiple of 50 and resolves part of the original problem description.

* When enabled in a fresh profile, Trinity should first query and inherit any AutoRepeat settings set in xorg.conf before using the hard-coded defaults in kcmmisc.cpp of 500 and 30. This does not happen. I set the xorg.conf AutoRepeat settings to 250 and 50. With a new profile, Trinity instead defaulted to the hard-coded defaults of 500 and 30.

* The delay slider uses a logarithmic scale. I have no idea why and see no purpose for that rather than using a normal linear slider. The preliminary patch changes the slider to linear.

* With the patch, when the delay is set to 250 msecs in kcminputrc and kcontrol is then opened, the slider indicator is set to 500 msecs. Setting the value in kcminputrc to 249 or 251 msecs results in the slider indicator being correctly positioned when kcontrol is opened. This is a weird bug as only 250 seems to have this problem. The problem is the same with the logarithmic scale too.

Adding a "Use BIOS settings" check box check box should only mean reading the BIOS and updating the slider and spin box accordingly. I don't know how to read the BIOS or whether Trinity or other system headers include such a function. Pulling that data from the BIOS should override any xorg.conf AutoRepeat settings.

Summary:

* Use the same 500/30 defaults as X (completed with current preliminary patch).

* Use xorg.conf AutoRepeat settings to configure a fresh profile before using the hard-coded defaults.

* Replace the logarithmic scale with a linear scale (completed with current preliminary patch).

* Verify the 250 msec bug no longer exists with a linear scale.

* Add support to read the BIOS settings (check box added in preliminary patch but no support).
Comment 4 Darrell 2013-03-02 21:38:52 CST 
Patch in attachment 1043 [details] pushed to GIT in commit 8f1fb61e.

The patch does not fully resolve this bug report. Refer to Comment 3 for details.
Comment 5 Michele Calgaro 2014-04-12 08:30:16 CDT 
Changing status back to NEW for too long inactivity
Comment 6 Felix Miata 2015-02-24 19:19:40 CST 
Behavior in R14 seems close enough to my request in comment 0 to call this fixed.
Comment 7 Michele Calgaro 2015-02-25 17:56:45 CST 
> Darrell
> The patch does not fully resolve this bug report.

> Felix
> Behavior in R14 seems close enough to my request in comment 0 to call this 
> fixed.

Darrell, could you check if you still have the problem on your side? Since Felix seems happy, if you are also happy we could close the bug. Otherwise we will leave it open.
Comment 8 Darrell 2015-02-25 19:18:01 CST 
I haven't looked at this in two years. Reading comment 3 indicates the original patch was nominal at most.
Comment 9 Michele Calgaro 2018-07-29 09:12:57 CDT 
Initial reporter (Felix) seems happy with the current status of this bug. Closing as resolved.
Feel free to reopen it if you think something is still missing.