Bug 97057 - 2.18 breaks compose:ralt option on secondary russian layout (us,ru)
Summary: 2.18 breaks compose:ralt option on secondary russian layout (us,ru)
Status: RESOLVED FIXED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
: 98495 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-07-23 09:37 UTC by Natrio
Modified: 2016-12-11 01:42 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Natrio 2016-07-23 09:37:13 UTC
On 2.17 .XCompose by option compose:ralt works fine on both primary US and secondary Russian layouts.

My keyboard settings (without compose):
---  /etc/X11/xorg.conf.d/99-keyboard.conf ---
 Section "InputClass"
    Identifier             "Keyboard Defaults"
    MatchIsKeyboard        "yes"
    Option                 "XkbLayout" "us, ru"
    Option                 "XkbOptions" "grp:caps_toggle, grp_led:scroll, terminate:ctrl_alt_bksp"
 EndSection
----------------------------------------------

In xmodmap's dump it looks like this.
Before setting compose up:
 $ xmodmap -pke|grep 108
 keycode 108 = Alt_R Meta_R Alt_R Meta_R

Setting Right Alt compose:
 $ setxkbmap -option compose:ralt
 $ xmodmap -pke|grep 108
 keycode 108 = Multi_key Multi_key Multi_key Multi_key

On 2.18 compose:ralt works on US layout, on primary Russian (ru,us), but NOT on secondary Russian (us,ru).
Dump before setting compose up:
 $ xmodmap -pke|grep 108
 keycode 108 = Alt_R Meta_R ISO_Level3_Shift

Setting Right Alt compose:
 $ setxkbmap -option compose:ralt
 $ xmodmap -pke|grep 108
 keycode 108 = Multi_key Multi_key ISO_Level3_Shift

As you see, for successful working compose on both layouts, we need "Multi_key" in words #1 and #3 , but since 2.18 it has "ISO_Level3_Shift" in word #3, regardless of assigning Compose to Right Alt.

It can be workarounded by direct xmodmap command:
 $ xmodmap -e "keycode 108 = Multi_key Multi_key Multi_key Multi_key"

and I found the new line in file /usr/share/X11/xkb/symbols/ru ("Windows layout" at beginning):
-------
     key <AB10> { [      period,       comma  ] };
     key <BKSL> { [   backslash,       slash  ] };
+
+    include "level3(ralt_switch)"
 };
-------
Commenting out this line also fixes the problem.
Comment 1 Sergey V. Udaltsov 2016-09-13 23:50:21 UTC
we need RALT for the 3rd level in order to access the Ruble character. See 
https://cgit.freedesktop.org/xkeyboard-config/commit/?id=85845be3a51f1ae790902b2b4c837d11382f50d8
Comment 2 Nikolaj Šujskij 2016-09-14 15:06:39 UTC
(In reply to Sergey V. Udaltsov from comment #1)
> we need RALT for the 3rd level in order to access the Ruble character. See 
> https://cgit.freedesktop.org/xkeyboard-config/commit/
> ?id=85845be3a51f1ae790902b2b4c837d11382f50d8

But this breaks Compose key for all the people who set it to right Alt!  Including those who have no idea what is 3rd level and never use it.  I could switch to rctrl no problem myself, but for thousands of users this is and will be a major frustration.  You have a working setup (I had my for about 7 years), it may well have an entry for ruble sign, and SUDDENLY it's broken without any apparent reason.  *And* you have no idea what's to blame (kudos to Gentoo Xorg maintainer, who suspected xkeyboard-config update).
Comment 3 Sergey V. Udaltsov 2016-09-14 23:20:07 UTC
I can understand your anger, but the rule is that if we have any keysyms on level 3, we have to provide the switcher to that level, typically ralt. There are pros and cons to having (and not having) that rule. Luckily, ralt is not the only key that can be used as Compose. And please keep in mind that Windows users are used to have ralt+8 as ruble. The least surprize for them was to have it available here. No ideal solution.
Comment 4 Natrio 2016-09-15 15:24:02 UTC
(In reply to Sergey V. Udaltsov from comment #3)
> No ideal solution.
Yes. There are right and wrong solutions.
You can break one option for another one, like this hardcoded switch:

> include "level3(ralt_switch)"

or you can give people a choice.
Comment 5 Sergey V. Udaltsov 2016-09-15 15:34:05 UTC
It is a philosophical question. Giving choice is definitely good, but there is another value: solution that works out of the box without extra tweaking, with expected behaviour. As I said, pros and cons.
Comment 6 Natrio 2016-09-15 16:02:29 UTC
(In reply to Sergey V. Udaltsov from comment #5)
> It is a philosophical question.
Is the hardcoding a philosophical question?
So, yes, in a sense.
Hardcoded schemes is a philosofy of the Windows Way.

However, I'm not talking about philosophy, but about replacing the optional setting 
>> compose:ralt
by the non-optional hardcoded surrogate
>> include "level3(ralt_switch)"

Is the "level3" strongly requires hardcoding?
Comment 7 Sergey V. Udaltsov 2016-09-15 16:20:28 UTC
As I explained earlier, if we introduce l3 in some variant, we require some l3 switcher in the same variant.
Comment 8 Natrio 2016-09-15 17:50:44 UTC
I found it.

$ grep -r 'lv3:' /usr/share/X11/xkb/rules/base.lst 
  lv3:switch           Right Ctrl
  lv3:menu_switch      Menu
  lv3:win_switch       Any Win key
  lv3:lwin_switch      Left Win
  lv3:rwin_switch      Right Win
  lv3:alt_switch       Any Alt key
  lv3:lalt_switch      Left Alt
  lv3:ralt_switch      Right Alt
  lv3:ralt_switch_multikey Right Alt, Shift+Right Alt key is Compose
  lv3:ralt_alt         Right Alt key never chooses 3rd level
  lv3:enter_switch     Enter on keypad
  lv3:caps_switch      Caps Lock
  lv3:bksl_switch      Backslash
  lv3:lsgt_switch      &lt;Less/Greater&gt;
  lv3:caps_switch_latch Caps Lock chooses 3rd level, acts as onetime lock when pressed together with another 3rd-level-chooser
  lv3:bksl_switch_latch Backslash chooses 3rd level, acts as onetime lock when pressed together with another 3rd-level-chooser
  lv3:lsgt_switch_latch &lt;Less/Greater&gt; chooses 3rd level, acts as onetime lock when pressed together with another 3rd-level-chooser

https://cgit.freedesktop.org/xkeyboard-config/commit/symbols/us?id=50a7d5d6d5ef12289887336120c3c6cc6c0cb7ba
-    include "level3(ralt_switch)"
+    // do NOT hardcode this switch; use lv3:ralt_switch option instead!
+    //include "level3(ralt_switch)"

So, level3 already WAS an option.
"lv3:ralt_switch" was already available, we HAD a choice.
But someone decided that the choice is a bad thing, good thing is the hardcode, but "works out of the box".
Just except US layout: they were able to revert this patch.
Comment 9 Sergey V. Udaltsov 2016-09-15 21:15:21 UTC
I gave it a thought. Ok. let it be so. There was a precedent.
Comment 10 Gleb Rostov 2016-10-12 19:19:16 UTC
Too bad that we had to turn off. People used before Windows will be expected to enter his mark on the right Alt. For myself, still leave the line: include "level3 (ralt_switch)". This is useful, I often write the cost is not just a number and signed the currency in which this thing can be bought / sold. It is important.
Comment 11 Nikolaj Šujskij 2016-10-12 19:24:46 UTC
(In reply to Gleb Rostov from comment #10)
> Too bad that we had to turn off. People used before Windows will be expected
> to enter his mark on the right Alt. For myself, still leave the line:
> include "level3 (ralt_switch)". This is useful, I often write the cost is
> not just a number and signed the currency in which this thing can be bought
> / sold. It is important.

I'm not completely sure I understand you, but anybody including you can add `lv3:ralt_switch` to her/his XKB option and enter as much rouble signs as one likes.
Comment 12 Natrio 2016-10-12 20:22:34 UTC
(In reply to Gleb Rostov from comment #10)
> Too bad that we had to turn off. People used before Windows will be expected
> to enter his mark on the right Alt. For myself, still leave the line:
> include "level3 (ralt_switch)". This is useful, I often write the cost is
> not just a number and signed the currency in which this thing can be bought
> / sold. It is important.

It's may be strange, but there is no any pre-hardcoded language switches, as some people expects to be. But you CAN configure it to Ctrl+Shift, Alt+Shift, CapsLock, etc. It also can be pre-configured by distro, but NOT unchangeable hardcoded "as expected". If you still need to set "grp:alt_shift_toggle" option, you always can also set "lv3:ralt_alt". And yes, it also may be pre-configured by distros, if the maintainers will want to support these expectations.
Comment 13 Gleb Rostov 2016-10-13 06:14:26 UTC
Natrio,if I understand correctly, then here is your thesis:
1) you use a layout in Russian called WINKEYS, but want it to be complete copy of this very layout of Windows
2)you want to layout, which is a copy of the layout of Windows was inadequate for all because you are comfortable to use right alt other purposes
3) you advise a man accustomed to the standard windows-layout to use a different key, but do not want to use another free key for their own purposes. and you do not want to just remove the line at about Alt.

it turns out that this is hypocrisy. and all you want to instill in place already used the standard opinion.
I see only one way out - to make a full copy of the layout Windows, because so it was conceived. and you personally for their own purposes or to use a different layout on their own line to remove the hated you, or use a different key for their own purposes.
Comment 14 Natrio 2016-10-13 06:49:35 UTC
(In reply to Gleb Rostov from comment #13)
> and you do not want to just remove the line at about Alt.
I can't JUST remove hardcoded line from /usr/share/* files without maintaining an alternative build of "xkeyboard-config" package.
Comment 15 Gleb Rostov 2016-10-13 07:01:20 UTC
(In reply to Natrio from comment #14)
> (In reply to Gleb Rostov from comment #13)
> > and you do not want to just remove the line at about Alt.
> I can't JUST remove hardcoded line from /usr/share/* files without
> maintaining an alternative build of "xkeyboard-config" package.

I detail everything described above. In addition, many layouts using the right alt for their own purposes. at the moment you want to change the standard for itself. if not so much like that used in the windows of alt to enter, so make convenient for your personal layout. but the layout WINKEYS should be what it is called and not someone's personal opinion.
Comment 16 Natrio 2016-10-13 07:34:02 UTC
(In reply to Gleb Rostov from comment #15)
> I detail everything described above. In addition, many layouts using the
> right alt for their own purposes. at the moment you want to change the
> standard for itself. if not so much like that used in the windows of alt to
> enter, so make convenient for your personal layout. but the layout WINKEYS
> should be what it is called and not someone's personal opinion.

The layout is simply "ru", there is no way to choose it without "winkeys" or other specific variantns.

The key swithes CAN be pre-defined normally, without hardcoding, but you want to do it by wrong way.
Comment 17 Nikolaj Šujskij 2016-10-13 07:52:49 UTC
winkeys variant was created long before Windows started using right Alt for rouble sign, and nobody promised `ru(winkeys)` to follow what Microsoft does.  And I don't want my tried'n'true keyboard options (used for best part of 10 years) broken for newbies who are afraid to configure their keyboard themselves.
Comment 18 Michal Suchanek 2016-10-13 08:59:45 UTC
The level3(ralt_switch) is configured as an option in rules.

That should be sufficient to make it visible and usable in keyboard configuration tools.

That's xkeyboard-config's work.

Making it the default is distribution's work. There are different defaults that work for different people.

The option must be configurable so different layouts work for different people.
Comment 19 pogonyshev 2016-11-12 20:28:54 UTC
I traced down bug 98495 to this change. I'm not smart enough to understand all the pros and cons you discussed here, but is there a way I could have XKB work as before, with AltGR in Russian layout while pressed temporarily switching back to English layout?
Comment 20 Mihail Konev 2016-12-11 01:42:50 UTC
*** Bug 98495 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.