On Wed, Jan 21, 2004 at 12:06:50PM +0600, Ivan Pascal wrote:
> 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.
Where does the LED state get resynced with the DDX? The only place that
I see the LED state synced with the DDX is at init time. If I disable
XKB, 'xset q' doesn't report changes to the real LED state.
Those tests work OK for me now if I disable XKB. I don't think it is
unreasonable to do the core protocol tests with XKB disabled.
>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.
It is being loaded with the XKB's LED state, isn't it?
>> > >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.
That sounds reasonable to me. It would also be nice to add some XKB tests
to the test suite.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
