David Dawes wrote:
>
> 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.
Yes. But I think it's rather a bug. Note that by deafult (without XLeds
option in the config file) all LEDs are protected from changes by applications
and the core protocol doesn't provide any way to get real LEDs state.
Thus the XGetKeyboardControl request just reflects attempts (unsuccessful with
deafult settings) of some applications to change the LEDs 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.
I agree. It would be good to add such suggestion into xsuite README.
> >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?
It is. Without XKB Xserver doesn't keep real LED state.
> >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.
I agree.
--
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
