[PATCH 1/4] xkb: LockMods can lock another group on key release #865

[Daniel Stone]

Hi,
I still think this is the correct approach, and want to finish up an
implementation with testcases in xkbcommon to make sure it doesn't do
anything surprising, as well as checking that old xkbcommon and xkbcomp
still parse it right.

On 9 January 2013 00:46, Peter Hutterer <peter.hutterer at who-t.net> wrote:

> ok, I looked at all four and they do look good and look like they do what
>  they should. The only two comments I have at this point are:
> * where are the bytes guaranteed to be zero? Not questioning, I just want
> to
>   double-check and it's outside the patch contexts
> * XkbModAction increases by 2 bytes. this is really my main worry here,
>   it is semi-public API. from a protocol POV it's fine because XKbAction
>   forces it to 8 bytes anyway so none of the protocol parsers should be
>   affected (fwiw, xcb would need an update here as well)
>
> So really, the only danger we have here is potentially breaking clients
> that
> expect XkbModAction to be 6 bytes, because of whatever reason. The safest
> approach would be to add a new struct here (XkbModAction2) and use that
> everywhere to avoid this issue. Daniel, any opinion?
>

So yeah, we'd probably need to add an XkbModAction2 here, which wouldn't be
an ABI break, so no problem.  However, XkbSetMap (and XkbSetCompatMap) need
to know whether or not those last two bytes are going to be valid when they
see XkbSA_LockMods, or potentially uninitialised garbage.  Similarly, both
libX11 and its users are going to need to know when reading an XkbDescRec
(and XkbCompatMapRec) whether those two bytes are valid.  But we can't
assume that all users have been updated, so introducing a new action type
for reading (e.g. XkbGetMap and friends) is out of the question.  Here's
what I think would work:
  - bump the protocol minor version to 1.1, specifying that the extra bytes
will be ignored on the wire for all earlier versions, but must be valid for
1.1;
  - bump the XKB library version in libX11 to 1.1;
  - always return correct values (either 0 for nothing, or a valid value)
for the new two bytes in actions with library version 1.1;
  - accept new action values (e.g. XkbSA_SetMods2) in XkbSetMap and friends
starting with 1.1, but noting that clients must explicitly check the
version and not send these actions to 1.0 libraries.

Alternately:
  - forget it ever happened for XkbSetMap and XkbGetMap: don't report those
extended bytes to clients, and ignore them on inbound requests;
  - introduce a new wire request which allows users to get and set the map
via its textual representation, which also neatly gives us extended
keycodes over the wire;
  - recommend clients use xkbcommon to parse the textual map.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130109/40e396f7/attachment.html>