Where is the default repeat rate for xset stored

@Patkos Csaba: It changed: now the default is that you don't have to configure anything at all and it works automagically. In a certain way, adding setxkbmap to .xinitrc became way easier than changing the server configuration.

Nowadays you can plug an USB keyboard or mouse and have X11 add it and recognize it, no need to rely on /dev/mice or something like that.

Now I've experienced the issue and, IMHO, the perfect solution would be some way to tell Xorg to inherit the new keyboard settings from the currently connected keyboard or to tell setxkbmap to set the options as the server default for current and future keyboards.

So far, I did not find any way to do so. The only way to avoid running setxkbmap/xmodmap again is to edit the default settings employed by hald when configuring new devices, see the freebsd documentation, §6.4.2 (some paragraphs below the section header, has two examples of setting keyboard defaults). See also "option 2" at Klaas Teschauer's tutorial on the hal migration. There's also a question on Stackoverflow with links about triggering a script on hardware additions, if you prefer to do it that way.

This will probably take several steps/iterations, and the Q&A format isn't a good fit. Please update your question with more information if you are stuck, and ping me in a comment to this answer. I'll edit my answer then.

From the description it sounds like the mapping of special keys to key events is done in the keyboard, so programming must happen in the keyboard, and not in a driver.

There are various open source USB sniffer for Windows, e.g. usbpcap or the older usbsnoop, google will probably find more, and tutorials how to use them.

In principle, you'll need to record the communication while programming different special keys with different key sequences with the programming software. Then look at the packets, compare them, and see which bytes change for different special keys or programmed sequences. Guess the protocol, replay it in a self-written program using libusb on Linux.

As your keyboard is HID, and HID is highly standardized, we have a bit of help. Familiarize yourself with the HID documentation (or at least look up those parts you need). Each HID device comes with a descriptor, and the descriptor describes all possible interaction with the device according to the HID standard. If this is how the keyboard is programmed, and if there are not too many "vendor-specific" fields, we may guess the protocol directly.

You can read the descriptor in two ways.

(1) If your kernel has debugfs enabled, as root do

mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/hid/device_id/rdesc

where device_id is the id if your keyboard. This will show the raw descriptor as hex bytes, and how the kernel parses it. If the kernel parse is not enough, try hidrd to convert the raw descriptor.

(2) Issue HIDIOCGRDESCSIZE and HIDIOCGRDESC ioctls on the hidraw device (look in dmesg to find it for your keyboard). The samples/hidraw/hid-example.c in the Linux kernel source explains how to do that, or use a ready-made tool like usbhid-dump.

Ideally you'll see some feature or output description(s) that is/are related to the programming. You may still have to snoop the software tools if too many of the described fields are unclear or marked "vendor-specific".