Hello,
Mark Vojkovich wrote:
> On Mon, 19 Jan 2004, David Dawes wrote:
>
> > >Tests for XChangeKeyboardControl
> > >Test 9: FAIL
> > >Test 10: FAIL
> >
> > That has been showing up for a while. It should be followed up.
>
> That's been showing up for a couple years. It's a regression.
I think the tests are incorrect. Both tests try to set keyboard LEDs (using
XChangeKeyboardControl) then read the LEDs state (XGetKeyboardControl) and
compare values. The difference between the tests is that the first one tries
to change some of LEDs (uses some mask) and the second one tries to set all
LEDs together (without specifying a particular LED number).
But some LEDs can be protected from their change by client application and
reflect keyboard state only.
The man about {Change|Get}KeyboardControl tells:
XChangeKeyboardControl - "...the state of that leds is changed, if possible.."
XGetKeyboardControl - "...each bit set to 1 in led_mask indicates an LED that
is lit...". (Note "if possible" and "an LED that is lit".)
I understand it as Get returns the actual state of LEDs, those that are not
protected and were changed by Change and those that are protected but are
switched on reflecting the keyboard state.
But the tests, obviously, are written in assumption that Get should return the
LED state exactly as it was written into keyboard by Change call. It means all
LEDs should be unprotected (it is not by default) or the keyboard control
structure keeps values written by XChangeKeyboardControl call(s) and at the
XGetKeyboardControl request just returns this record instead of real state
of LEDs.
BTW, the "fix" for this "regression" is very simple. We just have to remove
one line in dix/devices.c where the LEDs mask field of the keyboard controls
structure is being reloaded with the actual LEDs state. The tests will be
passed with success. But there will not be any way (in the core protocol)
to know the real state of LEDs.
> >
> > >Tests for XRebindKeysym
> > >Test 1: FAIL
> >
> > The XRebindKeysym failure goes away if XKB is disabled.
>
> Yes, it's a XKB problem/feature.
It is a feature. :)
This problem can be fixed easy too with 'one word patch'. But there is one
unclear thing there.
The RebindKeysym mechanism allows to tie any string to a keysym or a combination
of keysym and a set of modifiers. The binding itself works well, the problem
is the modifiers set interpretation.
For example, we have a key with two keysyms [a A] and want to bind two different
strings to combiantions Alt+a and Alt+A. How should we specify the second
combination - Alt + 'A', Alt + Shift + 'a' or Alt + Shift + 'A'?
The core protocol's assumes the third variant, i.e. takes the keysym figured
out with taking in account the Shift modifier but also checks all modifiers
obtained from the key event.
But the XKB-aware XLookupString 'consumes' all modifiers used at the keysym
choosing and hide them from the routine that checks string_to_key bindins,
i.e. it expects that the combiantion is just Alt + 'A'.
BTW, this behavour can be swithed on/off with a special 'client side XKB' flag
but by default XLookupString 'eats' consumed modifiers.
Thus the problem is what modifiers set should the bindings check routine use.
Shoud it always be the original 'state' field from the key event or the
consumed modifiers may be removed from a consideration. If we require there
a full compatibility with the core protocol the answer is obvious. But some
calls in XKB-aware Xlib already have differences from core protocol ones.
And the first form of that combination seems to me more logical (IMHO,
of course).
Side note: I wonder if anybody (anything) uses this 'rebind keysym' feature
anywhere.
On the other hand the test itself could be changed. One way is to make it
XKB-aware and make it set the needed flag (that turns the XLookupString
behavior to the 'core protocol like' one). Another way is don't use the Shift
modifier (that can be 'eaten' under some circumstance) there. All other
modifiers (except Caps) would be interpreted equaly in both (with/without XKB)
cases.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
