[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Tuatara:
*sigh* ... why do people still keep punching in random numbers into the registry without checking what the values could or should be? *sigh*

Ok ... before this gets out of hand, and other people start doing "silly" and "stupid" things with Priority256 ... especially without understanding what you're changing, READ THIS! Otherwise you WILL cause untold problems for your device.

http://msdn.microsoft.com/library/d...html/wce50conRealTimePrioritySystemLevels.asp

To give you the comparison for Windows XP ... just open Task Manager, select an application which is using 100% CPU, running at Normal Priority, and switch it to Real-Time. Then enjoy how "responsive" the one application is (unless it's accessing the video display and/or disk - i.e. try doing it to an explorer window file copy! ;-)). You'll enjoy a "locked" machine, and admire how you're unable to do anything else - even open the start menu! You may have to hard-reset your machine depending on the application you choose to make Real-Time.

THANKFULLY ... the Keyboard Driver (QwertyKey) has a FORCED time-delay in it (debounce delay) which ensures it can not take 100% CPU time, and through this ... and ONLY through this fact, it hasn't killed your device. Had you done this to ANY other device driver, I'm sure your device would need a hard-reset, and you could start re-installing everything again.

By raising the priority above everything ... ALL you are doing is making the QwertyKey device driver get serviced AHEAD of any other pending interrupt. While this MAY make a slight difference, it will only do so at the expense of EVERYTHING else in the OS. (Like WiFi, Network, USB, ActiveSync, Memory Management, Compaction, etc ...)

Yes, I have had the same issue, but there is a LIMIT to which you can go with the driver Priority in order to "fix" what is fundamentally a hardware and driver problem.

In my testing, and throughout the TuMa ROMs I've used 0x81 - or a priority of 129. This was carefully chosen to be below the Wave device (which was or should be set at 0x80 or 128 for best performance on the BA - again due to driver issues), so that sounds/rings happen at a higher priority than the keyboard. Yes, this is eventhough BOTH Priority256 values for these drivers were tweaked above the default recommendations from MSDN.

If you're finding that the keyboard is causing you grief, you could try inverting these two devices, and setting the keyboard HIGHER than the sound driver - i.e. to 0x7F or 127, and see if the system sound servicing is the cause of the keyboard stuttering delay. However, you may introduce stuttering into the sound output at this point ... i.e. even when you're NOT using the keyboard (which is most of the time).

At the ABSOLUTE HIGHEST level I would even consider, would be just below that of the touch-screen (0x6D). At this level (or above) would cause handwriting recognition issues, as the touch-screen would not be serviced at the correct rate to track the line drawings.

Never even consider going above the Power Manager Resume Priority Level ... if the driver supports power management, and is taking too much CPU, then the power management thread will never be able to "shut it down", and/or wake it up ... ever. Result = lockup.

So ... in summary:

QwertyKey: 0x81 ... or 0x7F to invert priorities

Wave Device: 0x80

I'd still like to test all this with the latest AKU3.x ROMs and see if the Priority settings are still valid, but for the moment, I'll assume that they are.

Good luck to anyone using priorities outside "sane" values ... you will create "priority inversion" conditions, where a driver is waiting on another driver to run, but it never will, since the priorities are reversed. You have been warned ... but enjoy playing with it anyways. Device recovery is only a hard-reset away.