(In reply to Andreas Wettstein from comment #2)
> > Warning: Multiple interpretations of "Caps_Lock+AnyOfOrNone(all)"
> > Using last definition for duplicate fields
>
> > Warning: Multiple interpretations of "Shift_L+AnyOfOrNone(all)"
> > Using last definition for duplicate fields
>
> The latter comes from "assign_shift_left_action" in compat/misc, see the
> comment there why it is required.
>
> I think the proper way to get rid of this warning would be to specify the
> action associated to a keysym directly, not involving any "Any" patters in
> the compat, that is, instead of
>
> interpret Any+Lock {
> action= LockMods(modifiers=Lock);
> };
>
> interpret Any + Any {
> action= SetMods(modifiers=modMapMods);
> };
>
> (in compat/basic), use
>
> interpret Caps_Lock {
> action= LockMods(modifiers=Lock);
> };
>
> interpret Shift_L {
> action= SetMods(modifiers=Shift);
> };
> interpret Shift_R {
> action= SetMods(modifiers=Shift);
> };
>
> This might break some xmodmap setups of those very conservative user still
> using xmodmap...
> > Error: Key <HYPR> added to map for multiple modifiers
> > Using Mod2, ignoring Mod4.
> > Error: Key <MDSW> added to map for multiple modifiers
> > Using Mod3, ignoring Mod5.
>
> The former comes from "modifier_mapping" in symbols/level5, the latter from
> "lock" in the same file, or something similar. The purpose is associate the
> virtual modifiers LevelFive and NumLock to a real modifier, and this is done
> using keycodes HYPR and MDSW which are known not to be produced by hardware.
>
> A proper fix would be not to use virtual modifiers LevelFive and NumLock
> (and LevelThree and AltGr) at all, and use real modifiers directly. This
> would avoid the need of such hacks as the one in symbols/level5, without any
> disadvantage.
>
> However, the error messages state that the the modifiers are set up as
> desired. From the practical perspective, therefore, there is no pressing
> need for a change.
Ok, so these warnings are just "hey, this is not ideal, but it doesn't break so if you don't have a better way, just leave it"?
(In reply to Andreas Wettstein from comment #2) AnyOfOrNone( all)" L+AnyOfOrNone( all)" shift_left_ action" in compat/misc, see the modifiers= Lock); modifiers= modMapMods) ; modifiers= Lock); modifiers= Shift); modifiers= Shift);
> > Warning: Multiple interpretations of "Caps_Lock+
> > Using last definition for duplicate fields
>
> > Warning: Multiple interpretations of "Shift_
> > Using last definition for duplicate fields
>
> The latter comes from "assign_
> comment there why it is required.
>
> I think the proper way to get rid of this warning would be to specify the
> action associated to a keysym directly, not involving any "Any" patters in
> the compat, that is, instead of
>
> interpret Any+Lock {
> action= LockMods(
> };
>
> interpret Any + Any {
> action= SetMods(
> };
>
> (in compat/basic), use
>
> interpret Caps_Lock {
> action= LockMods(
> };
>
> interpret Shift_L {
> action= SetMods(
> };
> interpret Shift_R {
> action= SetMods(
> };
>
> This might break some xmodmap setups of those very conservative user still
> using xmodmap...
hmm, some Neo2 people are still using xmodmap: https:/ /wiki.neo- layout. org/browser# linux/xmodmap . So just leave this warning be?
> > Error: Key <HYPR> added to map for multiple modifiers
> > Using Mod2, ignoring Mod4.
> > Error: Key <MDSW> added to map for multiple modifiers
> > Using Mod3, ignoring Mod5.
>
> The former comes from "modifier_mapping" in symbols/level5, the latter from
> "lock" in the same file, or something similar. The purpose is associate the
> virtual modifiers LevelFive and NumLock to a real modifier, and this is done
> using keycodes HYPR and MDSW which are known not to be produced by hardware.
>
> A proper fix would be not to use virtual modifiers LevelFive and NumLock
> (and LevelThree and AltGr) at all, and use real modifiers directly. This
> would avoid the need of such hacks as the one in symbols/level5, without any
> disadvantage.
>
> However, the error messages state that the the modifiers are set up as
> desired. From the practical perspective, therefore, there is no pressing
> need for a change.
Ok, so these warnings are just "hey, this is not ideal, but it doesn't break so if you don't have a better way, just leave it"?