I noticed that, at least on my system, XkbGetKeyboardByName returns NULL when the 'names' argument is NULL and the 'which' argument is XkbGBN_KeyNameMask. A NULL is also returned if 'names' points to a valid XkbComponentNamesRec whose every component is NULL. However, according to the XKB Library Specification, page 219:

"If a required component has not been specified in the names structure (the corresponding field is NULL ), the server substitutes the expression "%", resulting in the component values being taken from device_spec."

It seems to me that XkbGetKeyboardByName should return a valid XkbDescPtr even if the 'names' is NULL or filled with NULLs. Since it doesn't, it make XkbGetKeyboard useless when dealing with key names, since XkbGetKeyboard calls XkbGetKeyboardByName with 'names' = NULL.

Another thing I noticed was that XkbGetKeyboardByName does not write a correct value to XkbDescRec.names.num_keys, even though the 'keys' field seems to contain the valid values. As far as I know, the specification does not say that the field would be filled by XkbGetKeyboardByname, but I think that's just an error in the specification. On the other hand, the specification does say that XkbGetNames fills the 'num_keys' field when called with 'which'=XkbKeyNamesMask. The implementation, however, leaves/sets the 'num_keys' to zero.

Am I doing something wrong, or are these flaws in the specification / implementation? I've added a simple example program that shows the problem.

Attachment: xkb1.c
Description: Binary data

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to