While poking around 20954, and comparing it to the stock fuze build 19971 or whatever it is, I noticed that at some point in the 20xxx series there were several registry keys added pertaining to In-Call recording, tried fiddling with them a bit but don't see anything specific kicking in.. maybe someone else wants to tinker!
Code:
[HKEY_LOCAL_MACHINE\System\AudioRecording]
"Enabled"=dword:1
[HKEY_CURRENT_USER\Software\Microsoft\Voice]
"AllowInCallRecording"=dword:1
"EnableCallRecordMenuItem"=dword:1
I might be wrong on the HKLM\HKCU parts, try adding them to both.. no idea where the menu option is supposed to show up either, but i'd assume the dialer since it's cprog.exe that checks for these
Also, there are new keys in the 20xxx series pertaining to Gestures, which are now supported by WinMo itself, mimicing some of the features available in HTC's TouchFlo (and probably performing better, too, )
Code:
[HKEY_CURRENT_USER\ControlPanel\Gestures\Touch]
"Disabled"=dword:0 ; 0 for disabled, allows multi-select, 1 for enabled, doesn't work so hot with multi-select
"ScrollFriction" ; unknown default value or units
"ScrollInterval" ; unknown default value or units
"Multiplier" ; unknown default value or units
"Length" ; unknown default value or units
"Multiplier" ; unknown default value or units
"Tolerance" ; unknown default value or units
"Timeout" ; unknown default value or units
[HKEY_LOCAL_MACHINE\SYSTEM\GWE\TouchFilter]
"FastestTapTime" ; unknown default value or unit of measure, guess=units in ms
"MaxTapSpan" ; unknown default value or unit of measure, guess=units in pixels
"MaxTouchFilterDelay" ; unknown default value or unit of measure, guess=units in ms
More new stuff:
Code:
[HKEY_LOCAL_MACHINE\SYSTEM\GDI\GLYPHCACHE]
"Limit0"=dword:12000 ; unknown, "limit" key controls font cache, limit0 may be a secondary font cache or..?
[HKEY_LOCAL_MACHINE\ControlPanel\Power]
"DynamicChargeicon"=dword:1 ; set to 0 for normal "plugged in" icon when on ac/usb power, set to 1 for blinking battery icon to indicate charging
[HKEY_CURRENT_USER\ControlPanel\Phone]
"EnableTextResponse"=dword:1 ; unknown
"DisableGSMNetworkSelection"=dword:0 ; unknown, but you can guess from its name
[HKEY_LOCAL_MACHINE\Software\Microsoft\SIClnt]
"ShowAllSIPopups"=dword:1 ; imagine this has something to do with SI/SL messages from provider, see http://msdn.microsoft.com/en-us/library/ms890494.aspx
"HideMediumSIPopups"=dword:0 ; see above
[HKEY_LOCAL_MACHINE\System\Inbox\Settings]
"ShowReplySMSSK1"=dword:1 ; unknown
"MsgClassMenuOrder" ; unknown default or units of mesaure
[HKEY_LOCAL_MACHINE\System\Inbox\Settings\OEM]
"CustomEventHandler" ; unknown
[HKEY_LOCAL_MACHINE\Software\Microsoft\Inbox\Settings]
"ReminderAllDay"=dword:1 ; unknown
[HKEY_LOCAL_MACHINE\System\Inbox\AutoConfiguration]
"DefaultDestinationNetworkGUID" ; unknown, probably directs sms/mms/email to use a specific connection (i.e. wap.cingular vs. ims.cingular vs. isp.cingular) - value is most likely a string that matches the connection GUID
[HKEY_CURRENT_USER\Software\Microsoft\Inbox]
"DisableAutoSSL"=dword:0 ; unknown
[HKEY_LOCAL_MACHINE\Software\Microsoft\Pim\Contacts]
"SIMNewContact" ; unknown
[HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms]
"TcpRttVarAdjustment" ; unknown, probably a dynamic RTT prediction
"TcpSmoothRttAdjustment" ; see above, probably toggle dword 0/1
If a value doesn't work, try swapping HKCU for HKLM and vice versa, I jotted these down as I was going along looking for other things, and left that part off
New sound category:
Code:
[HKEY_CURRENT_USER\ControlPanel\Sounds\CallStart]
IE Mobile 6:
Code:
[HKEY_LOCAL_MACHINE\Security\Internet Explorer]
"MSHTML"=dword:0 ; 0 for old IE, 1 for IE Mobile 6
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Settings]
"Always Use My Font Size"=dword:1 ; overrides absolute font sizes on webpages, uses menu setting for font sizes
Prototype UI? Removes the start button and x button..
Code:
[HKEY_LOCAL_MACHINE\Adaptation]
"PROTOTYPE"=dword:1
yah ive seen that "record call" option in monx's roms..doesnt work but has a start and a stop option in the pop up righ softkey menu while in the dialer..
Does he get the record call option from the same registry edits or another method?
not sure..ill pm him or you can if you want
bump for IE 6 Mobile toggle
bump for prototype UI
Bump for a useful IE Mobile 6 key that makes xda-devs alot easier to read on ie mobile 6:
Code:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Settings]
"Always Use My Font Size"=dword:1 ; overrides absolute font sizes on webpages, uses menu setting for font sizes
[HKEY_LOCAL_MACHINE\Adaptation]
"PROTOTYPE"=dword:1
this was not present for me in 20954, and doesn't do anything when added.... I tried in HKCU too...
Search for string "PROTOTYPE" type unicode in \SYS\Shell\shell32.exe\S000
If you don't have it, you must have a different version of 20954 than me? Works here (note it needs a soft reset)
in Comm Manager, turning 3G Icon "OFF" will activate GPRS only.. whereas turning it "ON" will make it to Auto.. can u pls advise me how to make it 3G only instead of Auto when turning it "ON"?
coz i want to 'force' my device to use 3G only in my area.thx
comm manager is written by htc, not microsoft, and thus is outside the scope of this thread.
Hi all,
I tried searching but cannot find anything on this, so as my first post, here goes...
I have a Touch Diamond with official ROM (WM6.1). I want to get over the known "issue" that with the device set to pin lock after 0 minute timeout, it still locks automatically after 1 minute of idle time.
Of course, I found an answer on this forum, see, for example http://forum.xda-developers.com/showthread.php?t=291868: in the registry, set AEFrequencyType to 2 (instead of 1), which works as hoped as far as the device is concerned... it no longer auto-locks after any amount of time, but locks instead whenever it goes into standby.
The issue is this: Activesync no longer requires the pin to connect to the device and without pin can read ALL files from its memory, even if the phone is locked at the time. Setting AEFrequencyType back to 1 forces Activesync to require the pin even if it is not locked when it is plugged in to the computer. Does anyone know a way to force Activesync to require the pin... of course, I am looking for a setting on the device, not the PC, as I want to make it hard for anyone who might steal the phone (or if I lose it!) to read the data on the device.
In case anyone is wondering, I also found another workaround. Having set the pin timeout to some large time, like 30 minutes, I can then use a pin locking program, Zenyee's 'Pin Lock.exe', and create a wakeup event notification with Dotfred's Task Manager (seems very useful app for free!). This works, until I run FlexMail, which seems to intercept these notifications and prevent it from locking!! So, I have to override a soft key on the home screen to run the pin lock, then hit the power button to put the device into standby. Not too bad, but there must be a better way...!
Thanks in advance,
Martin
Just a quick follow up for anyone who may be interested. FlexMail DOES NOT intercept the wakeup events... however, because it causes a little processing to be done, it seems it can delay the device from sleeping for a while (a minute or two) whenever a full synchronisation is performed. So, the wakeup event, whilst normally quick to activate, can sometimes take a minute before becoming effective.
However, I now have a workable solution for me. Just as I said above, I set my Pin Lock timeout to something large, like 30 minutes. However, instead of relying solely on wakeup events, I have now installed Gyrator 2 (http://forum.xda-developers.com/showthread.php?t=427805) which is an excellent application for many reasons... I particularly like being able to identify the window class/title using the stylus-in event to identify the in-focus window! More importantly, for this issue, it has the option to both Pin Lock and Suspend the device whenever a certain criteria is met. For me, this is when it is held face down for a second. So, now I just do this instead of hitting the power button and I'm guaranteed to have the device Pin Locked on next wakeup. ActiveSync also requires the Pin as AEFrequencyType is the default value of 1. A perfectly workable solution.
All the best,
Martin
I strongly suggest you take this towards the Diamond section as knowledge about specific problems in specific devices are usually conversed over at that specific section.. more than here.
Thanks, but I think this is WM6/WM6.1 specific, not Diamond specific. The problem with AEFrequencyType set to 1 giving a timeout even with zero minutes is known and seems to be device independent. I just found that setting it to 2 to fix this timeout issue, as many people do, seems to prevent ActiveSync from requiring the PIN as well! Not a good result.
That said, my workaround solution is probably Diamond specific, sorry! Perhaps I should post in the original thread that I found out about the AEFrequencyType registry tweak?
All the best,
Martin
10/19/11 Update: Added patches for the recently released GB sources to keyboard_patches-GB.tar.gz.
7/9/11 Update: New patch to export the "column-switch delay", which allows for much decreased CPU utilization/much better efficiency. See below for details.
3/23/11 Update: Add alternate "timer delay" patch to enable runtime configuration of keypad_timer delay. See below for details.
Attached is a kernel source patch that fixes the EB13 hardware keyboard dropped/skipped key press problem, at least for twice-pressed keys. It restores DI18-level responsiveness for the hardware keyboard.
I know dropped keypresses on the hardware keyboard has been a problem for a long time, even with DI18. There are likely multiple factors at play here, and this patch only corrects one of them. However, DK28/EB13 are particularly bad at dropping twice-pressed keys, and hopefully this patch alleviates this issue for most folks who experience it.
Bug details:
Sesquipedalian points out in one of the General threads concerning the issue that EB13 often drops twice-pressed letters on the hardware keyboard. For example, if one types "hello", often "helo" is emitted.
Yesterday I performed some timing tests and discovered that the EB13 keyboard driver delays 1/10th of a second (100 ms) between reporting "key_press" & "key_release" events. Unfortunately this delay is on the order of human muscle response, and when folks press the same letter twice in that 100 ms, the kernel will only be able to acknowledge one of the presses.
Keyboard driver background:
The Epic's keyboard driver is located at drivers/input/keyboard/victory/s3c-keypad.c in the EB13 kernel sources.
On initialization, the driver establishes an interrupt handler (s3c_keypad_isr) for keyboard ("keypad") events, which is executed whenever the kernel is interrupted with a key press. During an interrupt, the handler starts a timer (keypad_timer) to expire after "3 * HZ/100" jiffies (27 ms), and clears the interrupt request. The driver actually figures out which key was pressed/released in a separate routine that executes after the timer expires. Also, the interrupt is not immediately reenabled, so if a second keyboard event (either a key press or release) comes in before the timer expires, nothing additional happens.
When keypad_timer expires, the keypad_timer_handler function is invoked. This routine scans through each of the six "columns" (which roughly corresponds to the rows) of the keyboard looking for key presses & releases. In doing so, the driver delays 0.3 ms to ensure each column switch is accepted by the hardware, so the enitre routine should take rougly 1.8 ms to execute. This is actually quite a long time (but not inappropriately so) relative to the clockspeed of the processor, which is partly why the scanning is done outside the keyboard interrupt where operations "that take a while" are discouraged. So this isn't a bad setup, even if it might appear a bit unusual at first.
The end of the scanning routine (keypad_timer_handler) checks to see if any keys are currently held down, and if so it restarts keypad_timer. It must do this, becuase if a key is pressed & released "quickly", before the timer actually expires, then a release interrupt would never be generated (even if the interrupt was immediately reenabled). Hence, if a key is pressed & released "quickly", it is detected by the scanning routine after the second timer expiration. It's likely that the keybord only generates an interrupt on key press, so the timer is necessary to detect key releases. While a key is held down, the scanning routine keeps resetting the timer. Once a key release is detected, the timer is deactivated and the interrupt reenabled.
The bug:
Now, the problem is that keypad_timer, when restarted by the scanning routine, is set to expire after "HZ/10" jiffies (98 ms). This is an unusually long waiting time--four times as long as the original timer. If the same key is pressed twice in this interval, the scanning routine will pick it up only as a single press/release pair. If multiple, different keys are pressed in this interval, I believe the scanning routine will pick all of them up, but not necessarilly in the right order.
So the fix is to change the keypad_timer's restart expiration time to something more reasonable, like the 27 ms used by the interrupt handler. This decreases the waiting time to one in which it's unlikely that someone will be able to press multiple, or repeatedly press a key. As it turns out, that's exactly what DI18 does, so we know it works. It's totally unclear why Samsung changed it.
Oh well.
Edit: Originally I thought keys were latched, so press events would be detected by the scanning routine even if the key is released before keypad_timer expires. They're most certainly not though, the scanning routine likely polls the instantenous key (up or down) state, so a key press must be held for at least 27 ms so that the scanning may complete after the interrupt is serviced. If a key is held shorter than this, it will not be detected.
3/23/11: Alternate "timer delay" patch:
Also attached is an alternate patch that supercedes the original. It allows for runtime configuration of the keypad_timer delay via a sysfs exported timer_delay variable.
The current delay may be read with:
Code:
cat /sys/devices/platform/s3c-keypad/timer_delay
and a new delay may be set with:
Code:
echo N > /sys/devices/platform/s3c-keypad/timer_delay
where N is the delay in jiffies.
A delay of "1" yields the shortest timer, and the most responsive keypad possible, whereas a delay of "256" (1 second) (in most kernels) is the longest allowed. At that point the keyboard is already useless since any keypress results in either repeated characters or the "alternate character popup".
In most kernels (where HZ=256), the default delay is "7" (27 ms), which is the same as the original patch and DI18. A delay of "16" (63 ms) approximates the behavior of stock EB13/EC05.
Basically, the delay is the minimum amount of time one must hold a key down for a keypress to register. It's also the maxmimum time the kernel believes a key is "held down" after it's let go. For example, with a delay of "7" one must hold a key down for 27 ms to register as pressed, and no-more-than 55 ms later does the key register as being released.
Or for a better example, with a delay of "128" one must hold a key down for half a second, and once registered, the key is "held down" for an additional half a second. Which almost guarantees an application-level repeated keypress or the alternate character popup.
Ideally one would start with a delay of "7" and reduce by one until the timer is fast enough for your typing rate that you no longer have dropped keypresses. Although many folks will find that a delay of "7" is fast enough for them.
7/9/11: New "column-switch delay" patch:
Attached are two (mutually exclusive) patches to export the "column-switch delay" (column_delay) in addition to the timer_delay variable. The first applies against stock EC05 and supercedes all previous patches. The second (alt patch) applies against stock EC05 with the previous timer_delay patch already applied and should be used for custom kernels already containing that patch.
The column-switch delay is the amount of time, in µs, that the driver delays while switching between the six keyboard "columns" (actually rows) in the keyboard scaning routine. A delay is necessary to ensure that the column switch has been performed by the hardware before scanning a new column, otherwise ghost keypresses result.
However, the 300 µs delay specified by Samsung is very inefficient, particularly for "reasonable" timer_delay values. With theimpaler747's suggested timer_delay of 5, the keyboard driver, while holding a key down, consumes 9.7% of CPU time (empirically tested), at any clock rate. This is quite-likely responsible for folks' previous complaints that use of the hardware keyboard causes audio skips, poor game performance, decreased battery life, etc.
This patch allows this (default) 300 µs delay value to be modified through a sysfs exported column_delay variable. Similar to the timer_delay, it may be read with:
Code:
cat /sys/devices/platform/s3c-keypad/column_delay
and a new delay may be set with:
Code:
echo N > /sys/devices/platform/s3c-keypad/column_delay
where N is the delay in µs.
A delay of "1" is the most efficient (only 0.02% CPU utilization) but results in ghost key presses. In testing, I've found ghosting to disappear at delays of "3" and above. To provide some buffer, I've been using (and recommend) a delay of "5" for both column_delay and timer_delay values for the past week, and I've not run into any issues.
At a delay of "5", the keyboard driver is far more efficient, consuming only 0.2% of CPU time while keys are held. This hopefully translates into less stuttering/performance problems and better battery life.
Testing on other devices is needed (and appreciated!) to find a reasonable delay where ghosting doesn't appear, assuming that "5" is too low on some devices. Even delays of "10" and "50" (comparable to other keyboard drivers) result in ~0.3% and 1.7% CPU utilization respectively, which is much better than the Samsung default.
Mirror links:
GB kernel patches: keyboard_patches-GB.tar.gz
Column-switch & timer delay patch: epic_keypad_delays-EC05.diff (for stock EC05)
Column-switch & timer delay patch: epic_keypad_delays_alt-EC05.diff (for kernels with timer delay patch already applied)
Historical links:
Timer delay patch: epic_keypad_timer_delay-EB13.diff
Original patch: epic_keypad_timer_fix-EB13.diff
Nice work!
Wow , nice work! I wish we had people as smart as you working @ Samsung or Sprint.
Sent from my SPH-D700 using XDA App
Nice WORK!!!
Since you have this fix, this will definetly improve it a little, now u just need to find a fix to fix all missed letters.
Great Job, cant wait for an updated kernal with this in it.
Our poor developers on here work so hard to clean up manufactures phones issues and bugs and do an amazing job. They should fire everyone at samsung and hire all the devlopers here. lol
great job! so i take it this is both not necessary and not even compatible with DI18?
Well... downloaded Genocides kernel, was able to compile it after getting the toolchain and everything. Worked great. Loaded it on my zip, flashed it..
Kernel doesn't boot and suddenly my SD card is unreadable.. LOL! Guess I'll leave it to the pro's as I try to recover some data off my SD card...
Tried Genocides kernel flash zip, still didn't work, dang.
Lol , sorry I dont know why that is funny to me. Hope you get it working!
Sent from my SPH-D700 using XDA App
This fix seems to be worse as the special key popup is even more noticeable than before. Perhaps a change in timing would be better. Maybe Samsung changed this in response to complaints of the popup coming up when unwanted.
Sent from Bonsai 6.0.3
TheDub said:
Nice work!
Building Genocide with this patch applied for all interested testers...
Rodderick will need to be the one to officially include it in HIS! Kernel but now we all have something we can test... will post link when it's done compiling.
Click to expand...
Click to collapse
Rodderik is already all over it broham. =]
TheDub said:
Well... downloaded Genocides kernel, was able to compile it after getting the toolchain and everything. Worked great. Loaded it on my zip, flashed it..
Kernel doesn't boot and suddenly my SD card is unreadable.. LOL! Guess I'll leave it to the pro's as I try to recover some data off my SD card...
Tried Genocides kernel flash zip, still didn't work, dang.
Click to expand...
Click to collapse
thats my bad your sdcard got nuked it has to do with the i9000 having and internal and external sdcard storage...for now use my modified initramfs and not the new ported one on my git (says not to use i9000 initramfs in README on github)
mkasick thx for the info and i will put it in the kernel immediately and test
Now fix the QAOL bug
Sent from my SPH-D700 using Tapatalk
Top Nurse said:
This fix seems to be worse as the special key popup is even more noticeable than before.
Click to expand...
Click to collapse
I've seen mention of this before, but I'm not particularly familiar with the issue.
When the does the special key popup happen (besides long-pressing a letter)? Can you give an example that would somewhat-reliably recreate the problem?
mkasick the patch works beautifully! one note you might want to mention is any kernel developers that attempt to change the Kconfig or CONFIG_HZ=256 (it is set to 256 here but the Kconfig sets it to 1000 anyway) then that will throw this timer off (patched or not)
i think samsung missed the CONFIG_HZ=256 being used in the Kconfig...if we used the config's value in original settings (256/10) then that would give us 25.6 where as your patch is giving us 30 (3*1000/100)...i may fix this later but using your diff patch for now...thanks again
mkasick said:
I've seen mention of this before, but I'm not particularly familiar with the issue.
When the does the special key popup happen (besides long-pressing a letter)? Can you give an example that would somewhat-reliably recreate the problem?
Click to expand...
Click to collapse
Typing two letters quickly brings up the popup. Also the arrow keys act somewhat funny.
Sent from Bonsai 6.0.3
I will install this as soon as there is a Kernel that has it.
Nice work!
I hate to be "THAT" guy but..
If you press and old A for about a second you get that popup everyone is referring to.
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
It was a known issue in DI18 I believe, that it would come up to frequently, Samsung probably fixed it by increasing that timer..
On genocide .3a and my rom I can't produce the hello bug reliably, the missed keys seem completely random and happen very very rarely with Swype gone.
Just a thought.
Originally Posted by TheDub View Post
Nice work!
Building Genocide with this patch applied for all interested testers...
Rodderick will need to be the one to officially include it in HIS! Kernel but now we all have something we can test... will post link when it's done compiling.
Rodderik is already all over it broham. =]
Click to expand...
Click to collapse
Nice to see, mine was a horrible fail anyways lol! but hey I was bored and you can't hurt anything by trying
TheDub said:
I hate to be "THAT" guy but..
If you press and old A for about a second you get that popup everyone is referring to.
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
It was a known issue in DI18 I believe, that it would come up to frequently, Samsung probably fixed it by increasing that timer..
On genocide .3a and my rom I can't produce the hello bug reliably, the missed keys seem completely random and happen very very rarely with Swype gone.
Just a thought.
Nice to see, mine was a horrible fail anyways lol! but hey I was bored and you can't hurt anything by trying
Click to expand...
Click to collapse
i never new that would pop up til u just told me, i guess i dont type multiple "A's" often..
Forcystos said:
Now fix the QAOL bug
Click to expand...
Click to collapse
I wasn't sure what this was. Then I saw this post which describes it. Amusing.
Sadly I don't think it's an easy fix. This bug is known as ghosting, and it's due to the way the keyboard matrix works. If you simultaneously press keys in two different rows ("columns" in driver-speak), e.g., Q & A, pressing L is ambiguous. The hardware, since it lacks diodes, can't differentiate between L & O. Basically, if multiple buttons are pressed simultaneously all bets are off.
If this was a serious issue, as in folks were seeing spurious keypresses when not intentionally trying to perturb the hardware, we could fix it by modifying the keyboard driver to just ignore all press events when multiple columns have non-zero key masks. Basically this would result in simultaneous key presses not registering, whether they're in conflict or not.
Rodderik said:
one note you might want to mention is any kernel developers that attempt to change the Kconfig or CONFIG_HZ=256 ... then that will throw this timer off (patched or not)
Click to expand...
Click to collapse
I don't think it should. Keep in mind that jiffies (the unit timers use) are defined in terms of CONFIG_HZ anyways. Specifically, HZ=CONFIG_HZ (in kernel space), and time_in_seconds = time_in_jiffies/HZ.
So a delay of (3*HZ/100) is nominally 30 ms regardless of HZ. It only deviates because it's integer division, so while (3*1000/100) = 30 ms, (3*256/100) is 23 27 ms (edit: foolish math! multiply before divide). For the most part, it shouldn't matter too much.
Rodderik said:
(it is set to 256 here but the Kconfig sets it to 1000 anyway) then that will throw this timer off (patched or not)
Click to expand...
Click to collapse
Wait what? CONFIG_HZ is 256 in both my .config and autoconf.h. Is there some bug I'm not aware of that resets it to 1000, or are you using 1000 in your config?
Rodderik said:
i think samsung missed the CONFIG_HZ=256 being used in the Kconfig...
Click to expand...
Click to collapse
I think they used CONFIG_HZ=200 in DI18, and it was changed to 256 for Froyo. The Linux default (on i386 anways) is 250 IIRC. I'm not sure why Samsung bothered to change it, maybe it's a upstream thing. But 200 vs 250 vs 256 is somewhat arbitrary anyways.
Top Nurse said:
Typing two letters quickly brings up the popup. Also the arrow keys act somewhat funny.
Click to expand...
Click to collapse
Hmm, I tried to induce both of these but I can't seem to. Any other thoughts on it?
davidrules7778 said:
i never new that would pop up til u just told me, i guess i dont type multiple "A's" often..
Click to expand...
Click to collapse
Please don't take my first comments as criticism of any kind! Just discussing the topic at hand
I don't type multiple A's either but when changing that timer to be much shorter does that make the time required to hold down A to produce that pop up shorter as well?
I saw a few people report that it makes it more noticeable (accidental pop ups).
TheDub said:
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
Click to expand...
Click to collapse
Ah, no, different timer. Changing the duration of keypad_timer merely changes how often the kernel keyboard driver checks to see if a key has been released. But if you hold a key down for 5 seconds, the kernel won't report a key_release event until 5 seconds after the key_press event. In the interim, other stuff might be happening like the "special character popup", or a key-repeat timer--but those are IME/app level and not controlled by the kernel.
If anything, this patch should strictly help. Say the "special character popup" happens after holding down a key for 0.5 seconds (it's about this). Previously, if you held a key down for 0.43 s, the release might not be detected until after 0.5 s and the popup would happen. Now, if you hold a key down for 0.43 s, the release would be detected no later than 0.46 s, and the popup won't show.
Think of it this way: a shorter keypad_timer results in more accurate key event timing, but (somewhat negligibly) increases CPU load due to having to run the scan routine more often.