jmcneill:
Key repeat is handled entirely by the console or the X server (depending on which environment you're in). In X you'd normally control repeat rate with "xset r rate X Y" where X is the delay for starting repeat and Y is the delay between repeats. Unfortunately it doesn't look like the X server in pdaXrom supports that extension. Perhaps Sash can suggest another way to control repeat rate in X? For the console, delay and rate are normally set by the "kbdrate" program. Doesn't look like we have that utility, so perhaps I'll look into building it for inclusion in the zkbdd ipk.
trichmon:
For your | = $ problem, could you let me know keyboard type and if it's happening in the console or in X (or both)?
Hrw:
I understand where you're coming from. It is worth pointing out that one of the reasons for the many flavors of IRK is that its design makes it a fairly complicated matter to add support for an additional keyboard. My zkbdd design does a number of things to specifically address that problem. Eventually I hope to get to the point where drivers can be written as "scripts" that "plug-in" to zkbdd at run-time (no compiling necessary).
As for kbdd, unfortunately kbdd suffers from a lack of good system design so unless the maintainers are open to a major code restructuring, a merge is unlikely. On top of that, it's still too early in development to consider a merge. My code is far too Zaurus specific. That's been a purposeful decision to make it easier for me to isolate and correct defects in the early releases. However, if real world testing reveals that I'm on the right track with my design, I'll eventually re-architect the code yet again with a two stage scancode conversion process (keyboard -> intermediate -> target). At that point the keyboard drivers would be "common" and only the backend final scancode conversion would be target specific.
When (and if) that happens, the kbdd folks may wish to migrate kbdd to my code base. If not then we'll have two competing projects and users can decide which one is superior. Forking in open source projects can be good when the fork takes the code in substantially different directions (as opposed to just being minor tweaks of the upstream project). Note that since I'm keeping the command line interface "compatible" with kbdd, GUI apps to control it (like GPE) shouldn't care which "driver" the users pick.
