[Bug 1245473] Re: Binding ctrl+shift, alt+shift, etc for switching keyboard layout makes shortcuts with ctrl+shift, etc not working in any program
Bug Watch Updater
1245473 at bugs.launchpad.net
Fri Jun 8 21:22:26 UTC 2018
Launchpad has imported 200 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=865.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2004-07-14T02:58:37+00:00 Shift-cmpd2 wrote:
I used to use Ctrl-Shift combination to switch keyboard layouts (ru <--> us)
but in this case i cant use any of the Ctrl-Shift-* hotkeys in any software i try.
I noticed, that the keyboard layout becomes swithced as soon an both keys are DOWN --
pressing any other key is not treated as Ctrl-Shift-<key> combination.
For example -- in Windows i also use Ctrl-Shift to switch layouts, but there, the layout
becomes switched only when both SHIFT and CTRL keys are UP, and no other key was
pressed while they were down -- in that case the hole combination is treates as
Ctrl-Shift-<key> combination, and the layout is not changed.
see also: http://bugs.kde.org/show_bug.cgi?id=59303
I use the following lines in XF86Config:
Section "InputDevice"
Driver "Keyboard"
Identifier "Keyboard[0]"
Option "Protocol" "Standard"
Option "XkbLayout" "us,ru"
Option "XkbModel" "pc104"
Option "XkbOptions" "grp:ctrl_shift_toggle"
Option "XkbRules" "xfree86"
Option "XkbVariant" ",winkeys"
EndSection
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/0
------------------------------------------------------------------------
On 2004-07-25T13:56:15+00:00 Kristian Hoegsberg wrote:
*** Bug 731 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/1
------------------------------------------------------------------------
On 2006-05-19T04:47:14+00:00 Erik Andrén wrote:
Are you able to reproduce this issue with a current version of xorg?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/2
------------------------------------------------------------------------
On 2006-06-01T16:56:02+00:00 Daniel Stone wrote:
yep, it's still a current issue. reasonably non-trivial fix, though. we could
probably hijack PKE for this.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/3
------------------------------------------------------------------------
On 2006-08-02T16:33:27+00:00 Shift-cmpd2 wrote:
(In reply to comment #2)
> Are you able to reproduce this issue with a current version of xorg?
playing with current xorg 7.1 on SuSE 10.1, taken from SuSE repositories.
it still behaves the same.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/4
------------------------------------------------------------------------
On 2007-02-27T01:23:43+00:00 Daniel Stone wrote:
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA
contact so bugs don't get lost in future.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/5
------------------------------------------------------------------------
On 2007-04-17T08:25:24+00:00 Daniel Stone wrote:
*** Bug 10662 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/6
------------------------------------------------------------------------
On 2007-05-02T16:17:16+00:00 nonZero wrote:
Reproduced on Ubuntu 7.04.
I would be happy to beta test patches were group change occurs at release, and
only if no other key combination was pressed, i.e:
in my configuration alt+shift chages group.
alt+shift+tab should go back a window and NOT change a group.
currently it changes a group and do goes a window forward!
Thanx,
nonZero
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/7
------------------------------------------------------------------------
On 2007-08-17T12:43:29+00:00 Alon Bar-Lev wrote:
I have the same issue with Hebrew layout...
<Alt><Shift><Tab> changes language on <Alt><Shift> key-down and not go back window as expected.
Well... long time until I thought I should file a bug... :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/8
------------------------------------------------------------------------
On 2007-08-21T07:13:56+00:00 Daniel Stone wrote:
*** Bug 12085 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/9
------------------------------------------------------------------------
On 2007-12-03T09:40:12+00:00 Tsdh wrote:
I use
Option "XkbOptions" "ctrl:nocaps"
and have related problems. When I want to type a keybinding like C-M-a
(C = Control, M = Meta (Alt)) and type it by first pressing Control,
then Alt and then "a" it's translated to C-a. The Alt is blocked when I
hit Control first. xev shows this order of events:
KP-C, KP-a, KR-a, KP-M, KR-M, KR-C
where KP stands for KeyPress and KR for KeyRelease. If I comment out
the Option line from above in my xorg.conf, all works fine.
If I type C-M-a by first pressing Alt, then Control and then "a" it
works, too.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/10
------------------------------------------------------------------------
On 2008-01-20T12:45:51+00:00 Zukoff wrote:
This bug will touch all EX-WINDOWS users that use more then one language
in their system. It was the major drawback when i found it.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/11
------------------------------------------------------------------------
On 2008-04-12T05:20:35+00:00 Alon Bar-Lev wrote:
Hello Xorg developers,
Can you please look at this issue?
It is very important to fix this for regular users to be able to use this environment.
It basically effects all multi-language users, and regular users are not able to accept the keydown/keyup explanations...
Thanks!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/12
------------------------------------------------------------------------
On 2008-05-20T16:36:19+00:00 Peter Hutterer wrote:
*** Bug 16041 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/13
------------------------------------------------------------------------
On 2008-05-21T01:43:07+00:00 Maciej Pilichowski wrote:
Hmm, I am not that sure my report is a duplicate -- but if yes,
differences:
* I don't do any layout switching, I have only single layout
* issue I described has nothing to do with pressing or releasing
* the problem is that you can assign shift key to keyboard shortcuts
like shift+F1 but you cannot assign alt key (shift level3) to such
combinations -- in other words, such key can generate only characters
(specified in layout) but beside that it is a dead key
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/14
------------------------------------------------------------------------
On 2008-05-21T03:51:20+00:00 Daniel Stone wrote:
On Wed, May 21, 2008 at 01:43:08AM -0700, bugzilla-daemon at freedesktop.org wrote:
> Hmm, I am not that sure my report is a duplicate -- but if yes, differences:
>
> * I don't do any layout switching, I have only single layout
>
> * issue I described has nothing to do with pressing or releasing
>
> * the problem is that you can assign shift key to keyboard shortcuts like
> shift+F1 but you cannot assign alt key (shift level3) to such combinations --
> in other words, such key can generate only characters (specified in layout) but
> beside that it is a dead key
Yes, Fn keys acting differently is another bug, but one that's fixable
by changing the keyboard layout definition of Ctrl+Alt.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/15
------------------------------------------------------------------------
On 2008-05-21T04:04:58+00:00 Maciej Pilichowski wrote:
Daniel, thank you for the answer. Further clarification (just in case):
a) F1 was just an example -- alt+left, alt+enter, alt+<anything not
defined as character> is not working.
b) I don't use ctrl+alt, I use only alt (for getting special characters,
in fact since alt is a key I cannot use anymore (*) I cannot use
alt+ctrl anywhere by definition)
c) alt also is an example, in general it is shift level 3 key, it could
be meta key as well
(*) sorry for using term "dead key", it has special meaning in X (other
than I meant)
In short my wish is:
alt+c --> ć (character)
alt+f --> alt+f (key combo; so I could use in KDE as a keyboard shortcut)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/16
------------------------------------------------------------------------
On 2008-10-10T11:24:58+00:00 Alon Bar-Lev wrote:
Hello,
Is there any news for this one?
It is very annoying issue.
Thanks!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/17
------------------------------------------------------------------------
On 2008-10-31T18:12:06+00:00 Daniel Stone wrote:
*** Bug 18333 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/18
------------------------------------------------------------------------
On 2008-11-11T13:07:56+00:00 Mike Ponomarenko wrote:
this is really annoying bug to me. I can't use Eclipse IDE for
programming, because all hotkeys use either ctrl+shift+something or
ant+shift. In other words instead of refactoring I get russian letters
which replace my code.
I cant switch to different (like caps lock) swith mode, since I use both
linux and windows too often, and it is very inconvenient to use
different methods.
Is there a way I can help coding it? any narration from where I should
start in sources?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/19
------------------------------------------------------------------------
On 2008-11-12T20:35:47+00:00 Peter Hutterer wrote:
xserver/xkb/xkbActions.c is where the action handling happens. There is little
documentation aside from the XKB protocol spec, so you need to dig through the
code to figure out what actually happens.
The entry point for xkb is ProcessKeyboardEvent, it's the first function
called when a keyboard event occurs. Anthing before doesn't matter to you.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/20
------------------------------------------------------------------------
On 2009-02-23T16:33:22+00:00 Alexander Kojevnikov wrote:
Does someone work on this? It's a very annoying bug, a lot of Emacs
shortcuts don't work because of it.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/21
------------------------------------------------------------------------
On 2009-02-25T01:03:13+00:00 Peter Hutterer wrote:
> --- Comment #21 from Alexander Kojevnikov <alexander at kojevnikov.com> 2009-02-23 16:33:22 PST ---
> Does someone work on this?
Not that I know of. Any help would be much appreciated.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/22
------------------------------------------------------------------------
On 2009-03-06T03:16:52+00:00 Eugene wrote:
Can we solve this problem?
I've made some digg about key codes, may be this can be helpful?
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/292260/comments/6
Does anybody know: Russian distros like AltLinux or AspLinux have this poblem? Perhaps we can take some code from there?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/23
------------------------------------------------------------------------
On 2009-03-08T09:40:36+00:00 Purkrtadam wrote:
--- Introduction
I'd like to discuss this problem in more detail and hopefully add some
ideas. For the sake of concreteness, I'm mostly discussing the
"Alt+Shift bound to layout switch and preventing other Alt+Shift
keyboard shortcuts" case.
After some research, I have the feeling that the problem is in the XKB
protocol itself and not in its implementation, which just correctly
adheres to a deficient specification. It is the XKB protocol that needs
to be extended to properly cover the requested behaviour. Seems to me
that currently one can bind actions only to keypresses (please correct
me if I'm wrong).
Admittedly, the fix is non-trivial. But it would be worth it; the
current behaviour is clumsy and limiting and (as has been said before)
e.g. disallows the use of "Alt+Shift+Tab" shortcut, commonly used to
switch among open windows, when "Alt+Shift" is used to switch between
layouts (that's actually how I found this bug - searching why
Alt+Shift+Tab doesn't work).
--- Definition of "multi-key-press-release sequence"
Definition: A "multi-key-press-release sequence" (MKPR seq. for short)
is a sequence of key presses and key releases occuring on a keyboard. It
begins and ends with all keys on keyboard up. During the sequence, there
must always be at least one key down.
--- The desired behaviour - the simple case with two layouts
Initial state: no key is pressed on the keyboard, two layouts are set in
the X server (us,cz), layout "us" selected (locked)
The user's intention: to select (lock) the "cz" layout
Action taken - a four step MKPR sequence:
1) press (and hold) Alt 2) press Shift 3) release Shift 4) release Alt
The expected behaviour/response: The release of all keys (i.e. step 4)
would trigger the selection (and locking) of "cz" layout.
Current behaviour/response: The layout gets changed after step 2).
Moreover, XKB then somehow forgets that Shift is still held down and
acts as if only Alt was held down. This precludes even the reachability
of any shortcut containing "Alt+Shift" combination.
Note on expected behaviour/response: If any key other than Alt or Shift
is pressed during the time when Alt was held down, no layout change
should occur. In other words, pressing any other key than "Shift" or
"Alt" would completely disqualify the MKPR sequence being formed from
being a candidate for layout switching.
--- Slight extension
Consider this MKPR seq.:
1) press and hold Alt 2) press Shift 3) release Alt 4) release Shift
That should switch the layout too, as well as this other two
possibilities:
1) press and hold Shift 2) press Alt 3) release Alt 4) release Shift
1) press and hold Shift 2) press Alt 3) release Shift 4) release Alt
Unsure: What about the following MKPR seq?
1) press and hold Alt 2) press Shift 3) release Alt 4) press Alt 5)
release Shift 6) release Alt
Should this do something special? (probably not, maybe it should not do
anything at all)
--- What if there are more than two layouts (e.g. 4 layouts?)
It would be IMHO practical, if the switching among layouts with
Alt+Shift could work similarly as Alt+Tab switching between windows in
XFCE/GNOME/KDE etc., i.e. there would be some internal recency list,
enabling to quickly switch between two most recently used layouts. I.e.
press and hold Alt and then press/release Shift multiple times to walk
through the possible layouts list, ordered by the time they were last
used (more recent first). Release of Alt would then mean "switch to the
selected layout". Pressing Esc (or any other key) during the hold of Alt
would mean "cancel the switching, leave the current layout".
How would the user be notified about the currently selected "candidate"
for switching to during the selection? One possibility is e.g. showing
the "layout candidate" in notification area (interaction with desktop
environment required).
--- Conclusion
To sum things up, it would be great if the XKB could be extended to
cover the notion of "multi-key-press-release" sequence and its use as a
trigger for (e.g.) changing keyboard layout.
The "recency-aware" layout switching among more than two layouts seems
to me as a good idea also.
--- REFERENCES, some starting points for XKB hacking
http://www.xfree86.org/current/XKBproto.pdf - The XKB Extension: Protocol Specification
http://www.xfree86.org/current/XKB-Config.html - How to configure XKB
/usr/share/X11/xkb/symbols/group - this is the file where e.g.
"Alt+Shift" layout switching is defined, namely this part
** beginning of excerpt
partial modifier_keys
xkb_symbols "alt_shift_toggle" {
virtual_modifiers Alt;
key <LALT> {
symbols[Group1]= [ NoSymbol, ISO_Prev_Group ],
virtualMods= Alt
};
key <RALT> {
symbols[Group1]= [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
key <LFSH> {
type[Group1]="PC_ALT_LEVEL2",
symbols[Group1]= [ Shift_L, ISO_Prev_Group ]
};
key <RTSH> {
type[Group1]="PC_ALT_LEVEL2",
symbols[Group1]= [ Shift_R, ISO_Next_Group ]
};
};
** end of excerpt
Some useful commands:
"setxkbmap -option" clears all options
"setxkbmap -v 10 -layout us,cz -option grp:alt_shift_toggle" - setup two layouts, with alt+shift switching between them
"setxkbmap -print -v 10" - print current XKB settings
Try to change e.g. "Shift_R" to "A" in the above mentioned part of
/usr/share/X11/xkb/symbols/group, save and then run "setxkbmap us,cz
-option grp:alt_shift_toggle" - right shift then should produce the
letter "A".
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/24
------------------------------------------------------------------------
On 2009-03-08T09:51:33+00:00 Purkrtadam wrote:
another good article about XKB
http://pascal.tsu.ru/en/xkb/setup.html
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/25
------------------------------------------------------------------------
On 2009-03-08T12:36:10+00:00 nonZero wrote:
(In reply to comment #24)
> Action taken - a four step MKPR sequence:
> 1) press (and hold) Alt 2) press Shift 3) release Shift 4) release Alt
.
.
.
> It would be IMHO practical, if the switching among layouts with Alt+Shift could
> work similarly as Alt+Tab switching between windows in XFCE/GNOME/KDE etc.,
> i.e. there would be some internal recency list, enabling to quickly switch
> between two most recently used layouts. I.e. press and hold Alt and then
To make this happen, the event should be triggered following step 3.
So, basically what needed to be done is whenever a key is pressed, key combination should be matched against the current pressed keys, and if a combination is met exactly, we should only set a flag for this combination - and not actually fire the event.
Whenever a key is released, this flag is checked - if the flag was set, the event shoud be fired and the flag should be cleared.
Whenever a key is pressed, the flag should also be cleared, so:
Example A:
Step Action Flag
---- ----------------------------- ----
0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Shift released - EVENT FIRED 0
4 Alt released 0
Example B:
Step Action Flag
---- ----------------------------- ----
0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Tab Pressed 0
4 Tab released 0
5 Shift released 0
6 Alt released 0
Example C:
Step Action Flag
---- ----------------------------- ----
0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Shift released - EVENT FIRED 0
4 Shift Pressed - match! 1
5 Shift released - EVENT FIRED 0
6 Alt released 0
Example D: (very strange case, unexpected, just for "fun")
Step Action Flag
---- ----------------------------- ----
0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Tab Pressed 0
4 Tab released 0
5 Shift released 0
4 Shift Pressed - match! 1
5 Shift released - EVENT FIRED 0
6 Alt released 0
I think this is good enough for 99% of the cases.
I did not dive into the protocol, but I have a feeling that adding such a flag is not a big deal, and does not require a rewrite, but please, correct me if I am wrong.
Udi
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/26
------------------------------------------------------------------------
On 2009-03-08T16:11:10+00:00 Purkrtadam wrote:
> To make this happen, the event should be triggered following step 3.
>.
>.
> So, basically what needed to be done is whenever a key is pressed, key
> combination should be matched against the current pressed keys, and if a
> combination is met exactly, we should only set a flag for this combination -
> and not actually fire the event.
> Whenever a key is released, this flag is checked - if the flag was set, the
> event shoud be fired and the flag should be cleared.
>.
>.
> I think this is good enough for 99% of the cases.
Good idea with the flag, and you are probably right that your solution would solve 99% of the cases (since lot of people affected by this probably use just two layouts - US and their national one - at least that is my situation).
Anyway I would be definitely for incorporating the "recency-awareness"
into the switching of keyboard layouts. It would be very handy in the
case when there is need to switch among more than two layouts.
I know I'm straying quite a bit from the original problem now, since this is definitely a request for extension, but I think it's still in close relation, so let me explain the idea in more detail.
--- First introduce some shorthands
<key> down = press <key> and hold it down
<key> up = release <key>
<key> hit = press <key> and immediately release it
--- What do I mean by "recency-aware" switching and why is it a good idea
Basically it's the type of switching that is used for switching among
windows in XFCE/GNOME/KDE, so let's first describe how that works. For
example, let's open four applications in say XFCE - first app1, then
app2, then app3 and finally app4. By that, subsequently app1 app2 app3
and app4 gets focused (i presume that when the app is opened, it gathers
focus). So now app4 is focused. Suppose we want to switch to app2. What
one can do is:
1) Alt down
2) Tab down - now a list of applications appears, showing the applications in this order: app4, app3(selected), app2, app1 - it's the order in which they had been lastly focused
3) Tab up
4) Tab down - now app2 gets selected in the applist
5) Tab up
6) Alt up - this release triggers the actual switch, so applist disappears and app2 gets focused; also, the applist gets reordered (internally) - the apps in it are now in this sequence: app2 (currently=most recently focused), app4, app3, app1 (focused longest time ago)
Now suppose we want to switch back from app2 to app4 (typical scenario:
app2 is an editor in which one edits a webpage and app4 is a web browser
used for testing that page). With recency-aware applist, this can be
done easily, thanks to the clever rearrangement of apps in it:
1) Alt down
2) Tab down - list of application appears: app2, app4(selected), app3, app1
3) Tab up
4) Alt up - app4 gets focused
If the list didn't get rearranged (and was still app4,app3,app2,app1)
one would need to hit tab twice to get back to app4 (assuming wrap
arround). But with recency awareness, it's just "down Alt + hit Tab + up
Alt" et voila.
Compare this to e.g. tab switching in Firefox which, by default, is just
rudimentary; no recency awareness there. Ctrl+Tab is just "switch one
tab to the right", Ctrl+Shift+Tab "switch one tab to the left".
Switching back and forth between a pair of tabs, using only keyboard, is
not easily accomplished, especially if the tabs aren't next to each
other. And even if they are next to each other, each time you switch you
have to think about "am I now in the left or in the right tab? should I
switch to the right or to the left?" With recency-awareness, it would be
just "down Ctrl, hit Tab, up Ctrl" to switch back and forth. I don't
want to critize Firefox here. I just want to illustrate how handy the
recency awareness in switching can be.
--- Back to recency-aware layout switching - explanation by example
It's basically a direct analogy of recency-aware window switching, with
one subtlety - the (optional) dialog appears after the first release of
Shift, not the first press.
Let's have four keyboard layouts set in the X server -
'us','cz','de','fr' (ordered from most recently used/locked to the
longest-ago locked); i.e. the 'us' layout is the one currently locked,
and 'fr' has not been used for the longest time. Now let's say we want
to switch to the 'fr' layout. It would work in this way:
1) Alt down
2) Shift down
3) Shift up - now the actual layout switch would begin; in cooperation with desktop environment, some dialog window should (optionally) also appear, displaying the (in our case four) available layouts, with the most recently used layout ('us') on the first place, and the second layout ('cz') selected.
schematically: [ us, *cz, de, fr ] - selection indicated by asterisk here
It is important that the dialog for switching should appear only by now,
after the first release of Shift. It could be confusing if the dialog
appeared after step 2) since Alt down followed by Shift down can be just
beginning of some Alt+Shift+something shorcut (e.g. Alt+Shift+Tab).
4) Shift down - now the 'de' would get selected: [ us, cz, *de, fr ]
The cycling in the list is now triggered by the press, since we now
presume that the user wants to switch layouts, it's ok now to have
feedback on press.
5) Shift up - nothing happens, 'de' stays selected
6) Shift down - 'fr' gets selected: [ us, cz, de, *fr ]
7) Shift up - nothing happens, 'fr' stays selected
Note: up until now, no actual change of the layout has occured! It's
just the selection of the layout we intend to lock that takes place so
far. Shift is used to walk (or, rather, cycle) through the list of
available layouts as Tab is used to cycle through the list of available
windows. The selection of the new layout can be cancelled by pressing
e.g. "esc" (similarly as the switching of window can be cancelled by
"esc").
8) Alt up - only this release triggers the actual locking of the new, in
our case 'fr' layout. The list of layouts disappears, internally it gets
rearranged to this state: 'fr', 'us', 'cz', 'de'.
Subsequently with "down Alt + hit Shift + up Alt" one could switch back
to 'us' layout etc.
So this is my proposal for keyboard layout switch. It requires changes
in the XKB and also in the desktop environments (to display the layout
selection window), but the result would be well worth the effort IMO.
Regards,
Adam
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/27
------------------------------------------------------------------------
On 2009-04-04T02:25:09+00:00 Vasa Maximov wrote:
(In reply to comment #27)
> So this is my proposal for keyboard layout switch. It requires changes in the
> XKB and also in the desktop environments (to display the layout selection
> window), but the result would be well worth the effort IMO.
+1 to Adam's idea. This is how it should work.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/28
------------------------------------------------------------------------
On 2009-04-20T21:47:02+00:00 smwed wrote:
Five years the problem remains not solved.
Developers have no problems with switching of keyboard layouts and
hotkeys?
(Sorry for my english)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/29
------------------------------------------------------------------------
On 2009-04-21T06:22:34+00:00 Eugene wrote:
(In reply to comment #29)
> Five years the problem remains not solved.
>
> Developers have no problems with switching of keyboard layouts and hotkeys?
>
> (Sorry for my english)
>
Looks like Russian and Slavic users are mainly affected. :(
What about Adam's idea? It looks very good.
Can anybody realize it? Unfortunately I'm not an Xorg developer :(
Is it possible to make it as a patch? or specific branch?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/30
------------------------------------------------------------------------
On 2009-05-12T11:44:09+00:00 smwed wrote:
www.xneur.ru - switch layouts on key release!
No problem for hotkeys!
xneur - daemon
gxneur - gui for gnome
kxneur - gui on QT for KDE
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/31
------------------------------------------------------------------------
On 2009-05-12T12:27:59+00:00 Mahaniok wrote:
Oleg, this blatant self-promotion doesn't make sense here, since the app
can't solve the issue. I wasted my time installing it, and there is
simply no way to set "Ctrl-Shift" as a combination to switch layouts in
it.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/32
------------------------------------------------------------------------
On 2009-05-12T12:37:22+00:00 smwed wrote:
(In reply to comment #32)
> Oleg, this blatant self-promotion doesn't make sense here, since the app can't
> solve the issue. I wasted my time installing it, and there is simply no way to
> set "Ctrl-Shift" as a combination to switch layouts in it.
>
It's not my programm! And no self-promotion!
1. Delete all layoute switch settings on gnome
2. Set at xneur ctrl+shift for Rotate Layout
Result:
ctrl+shift = layout swither
ctrl+shift+... = you hotkey.
It works for me, must can work for you. try.
(sorry for my english)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/33
------------------------------------------------------------------------
On 2009-05-12T12:46:05+00:00 Mahaniok wrote:
hi Oleg,
sorry for my wrong comment, if that's not your program. But
1) there is no "RotateLayout" option there. at least in 0.9.4
2) even if there was, people can't set ctrl-shift regardless of side as binding; you need to choose, left ctrl-shift or right ctrl-shift.
so, unfortunately, it doesn't seem to be a nice solution.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/34
------------------------------------------------------------------------
On 2009-05-12T12:57:32+00:00 smwed wrote:
(In reply to comment #34)
> hi Oleg,
>
> sorry for my wrong comment, if that's not your program. But
> 1) there is no "RotateLayout" option there. at least in 0.9.4
Oh, sorry. "RotateLayouts" The option has appeared in version 0.9.5 (It
is accessible in svn, but non-stable)
> 2) even if there was, people can't set ctrl-shift regardless of side as
> binding; you need to choose, left ctrl-shift or right ctrl-shift.
>
The author now works over it
> so, unfortunately, it doesn't seem to be a nice solution.
Other variants simply are not present.
The problem is not solved five years.
I just try to help.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/35
------------------------------------------------------------------------
On 2010-01-25T01:34:48+00:00 Oded Arbel wrote:
Oleg: I tried xneur and it obviously solves some problem for someone,
but not this problem for me. For once it doesn't play nice with X.org
(if I understand correctly it takes over keyboard input completely and
handles it on its own), for second it only supports a small subset of
languages supported in X.org and for third its way too complicated.
Adam Purkrt discussion about the changes required, and nonZero's idea
for implementation look like a very good thing to implement. I
understand from Adam Purkrt's comments that this suggestion conflicts
with the specification of the XKB protocol - Is that correct? and if so
- can it be implemented regardless in X.org or does the X.org
development process calls for the specification to first be changed?
Also regarding the recency list idea described in Adam Purkrt's last
comment - I think that the idea in itself is good but the
implementation, especially the part where the system should switch from
responding to RELEASE event to use PRESS events instead, is way
complicated and we should start by getting the "switch on release"
working first so that layout switching can actually be done without
interfering with shortcuts, and do optimization later.
I'm not an X.org developer, but I'm a programmer by trade and if this
can be fixed in X.org (see my previous questions), I would really like
to try to put in a fix according to Adam's and nonZero's suggestions. I
just wouldn't like to invest a lot of work in this only to find its all
for naught, so I'd appreciate some feedback from the developers first
(Daniel?) if this is even feasible to do in the X.org code base (i.e.
without getting into a large protocol specification process).
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/36
------------------------------------------------------------------------
On 2010-01-25T02:30:09+00:00 anarsoul wrote:
(In reply to comment #36)
> Also regarding the recency list idea described in Adam Purkrt's last comment -
> I think that the idea in itself is good but the implementation, especially the
> part where the system should switch from responding to RELEASE event to use
> PRESS events instead, is way complicated and we should start by getting the
> "switch on release" working first so that layout switching can actually be done
> without interfering with shortcuts, and do optimization later.
It's not so easy to handle release event instead of press, Xorg handles
ctrl+shift combination as _one_ key, so AFAIR release means _both_ ctrl
and shift released.
> I'm not an X.org developer, but I'm a programmer by trade and if this can be
> fixed in X.org (see my previous questions), I would really like to try to put
> in a fix according to Adam's and nonZero's suggestions. I just wouldn't like to
> invest a lot of work in this only to find its all for naught, so I'd appreciate
> some feedback from the developers first (Daniel?) if this is even feasible to
> do in the X.org code base (i.e. without getting into a large protocol
> specification process).
Daniel is now working on XKB2, so fixing/changing XKB1 has no sense :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/37
------------------------------------------------------------------------
On 2010-01-25T04:22:19+00:00 Oded Arbel wrote:
(In reply to comment #37)
> It's not so easy to handle release event instead of press, Xorg handles
> ctrl+shift combination as _one_ key, so AFAIR release means _both_ ctrl and
> shift released.
I'm not sure why you say that - xev detects CTRL and SHIFT
independently.
> Daniel is now working on XKB2, so fixing/changing XKB1 has no sense :)
Will XKB2 address this issue? I've looked for information on XKB2 on the
web and there is very little information to be found except that it aims
to handle input-methods better and that it won't bee in the next X.org
release (after missing the last three as well).
So this is another area where I would appreciate some feed back from
developers - if XKB2 realistic for X.org 1.9, then maybe I should help
out with that. Otherwise, I don't see what's wrong with fixing XKB1 for
1.9 even if only for this release.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/38
------------------------------------------------------------------------
On 2010-01-25T05:12:52+00:00 anarsoul wrote:
(In reply to comment #38)
> I'm not sure why you say that - xev detects CTRL and SHIFT independently.
You did not notice ISO_Next_Group which appears when CTRL and SHIFT
pressed at same time.
> Will XKB2 address this issue? I've looked for information on XKB2 on the web
> and there is very little information to be found except that it aims to handle
> input-methods better and that it won't bee in the next X.org release (after
> missing the last three as well).
I don't know :) I didn't find any info about XKB2 too.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/39
------------------------------------------------------------------------
On 2010-01-25T05:48:59+00:00 Oded Arbel wrote:
(In reply to comment #39)
> (In reply to comment #38)
> > I'm not sure why you say that - xev detects CTRL and SHIFT independently.
>
> You did not notice ISO_Next_Group which appears when CTRL and SHIFT pressed at
> same time.
Oh, I though you meant CTRL+SHIFT as in the actual keys, not as "the
keyboard layout switching combination you currently have set" (which is
not CTRL+SHIFT in my system).
Indeed it does - but that is internal to the XKB implementation and the
reason for this bug and not something inherent to X.org itself (other
then the XKB part). And we want to change that.
Also, notice that the current implementation looks like this:
1. hold down <1st key of combination>: you get "KeyPress <1st key>"
2. hold down <2nd key of combination>: you get "KeyPress ISO_Prev_Group" (or ISO_Next_Group. I get "prev", not sure why - maybe its a GNOME thing).
3. release <2nd key of combination>: you get "KeyRelease ISO_Prev_Group".
4. release <1st key of combination>: you get "KeyRelease <1st key>"
On the other hand, notice how the current implementation handles a different release order (take it from after step 2 above):
3. release <1st key of combination>: you get "KeyRelease <1st key>"
4. release <2nd key of combination>: you get "KeyRelease <2nd key>"
So in effect, with the alternate sequence, you get a <1st key> press and
release, but only ISO_sth_Group press and only <2nd key> release. As I
was trained to change layouts quickly, I cannot always guarantee that I
release the keys in the order they were pressed, and releasing them out
of order causes some problems like the notorious "sticky keys" issue.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/40
------------------------------------------------------------------------
On 2010-01-25T05:51:11+00:00 Nick Andrik wrote:
First of all I have the same problem (while switching to greek layout).
A simple solution I see on this is to act only on release events and
only if the previous event was a press. Like this all the situations in
comment: #26 are handled correctly.
The things needed from the implementation point of view are:
- A variable (e.g. previous_event_type) which tells us if the previous event was a "press" one which should get updated on every event
- A way to find what combination of keys has just been released (I guess this is already there, for the "has just been pressed" case).
I tried to take a look in the xkbActions.c file (xorg-server-1.7.3.902) but I could not find the ProcessKeyboardEvent function mentioned on comment: #20.
Any info on this? I could try to create a patch for this but I need the correct pointers on where to look.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/41
------------------------------------------------------------------------
On 2010-01-25T06:08:42+00:00 anarsoul wrote:
(In reply to comment #41)
> I tried to take a look in the xkbActions.c file (xorg-server-1.7.3.902) but I
> could not find the ProcessKeyboardEvent function mentioned on comment: #20.
> Any info on this? I could try to create a patch for this but I need the correct
> pointers on where to look.
It seems it's in xkbPrKeyEv.c now
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/42
------------------------------------------------------------------------
On 2010-01-25T10:00:48+00:00 James H. Cloos Jr. wrote:
> you get "KeyPress ISO_Prev_Group" (or ISO_Next_Group. I get "prev",
not sure why
The xkb rules send ISO_Next_Group if you press the relevent keys in one
order and ISO_Prev_Group if you press them in the other order.
Eg, given group(ctrls_toggle), LCtrl+RCtrl does next and RCtrl+LCtrl
does prev.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/43
------------------------------------------------------------------------
On 2010-01-26T00:30:09+00:00 Oded Arbel wrote:
(In reply to comment #43)
> > you get "KeyPress ISO_Prev_Group" (or ISO_Next_Group. I get "prev", not sure why
>
> The xkb rules send ISO_Next_Group if you press the relevent keys in one
> order and ISO_Prev_Group if you press them in the other order.
>
> Eg, given group(ctrls_toggle), LCtrl+RCtrl does next and RCtrl+LCtrl does prev.
>
More likely its something to do with left/right: I have ALT+SHIFT set as
the group toggle, and I get ISO_Prev_Group regardless of the order I
hold down ALT and SHIFT on the left side of the keyboard, but
ISO_Next_Group regardless of the order that I hold down ALT and SHIFT on
the right side of the keyboard.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/44
------------------------------------------------------------------------
On 2010-02-07T14:17:20+00:00 Ilya Murav'jov wrote:
Created attachment 33142
This patch is to resolve the issue; it is for "trunk" Xorg sources.
Please try to patch Xorg from git://anongit.freedesktop.org/git/xorg/xserver
and comment if the patch works for you.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/45
------------------------------------------------------------------------
On 2010-02-07T15:34:53+00:00 Nick Andrik wrote:
Hello Ilya,
I have just used your patch towards the current Ubuntu karmic version of xorg and it works! The only "issue" was just some offsets in the file:
Applying patch 200-fix-key-pressing
patching file xkb/xkbActions.c
Hunk #1 succeeded at 385 (offset 60 lines).
Hunk #2 succeeded at 1249 (offset 86 lines).
Is it ok for you if I forward the patch also to the ubuntu bug here:
https://bugs.launchpad.net/xorg-server/+bug/36812
until it is officially included in an xserver-xorg release?
Many many thanks!
Nick
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/46
------------------------------------------------------------------------
On 2010-02-07T15:37:36+00:00 Nick Andrik wrote:
Just a note, karmic's version is 1.6.4
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/47
------------------------------------------------------------------------
On 2010-02-07T16:01:25+00:00 Ilya Murav'jov wrote:
(In reply to comment #46)
> Hello Ilya,
>
> Is it ok for you if I forward the patch also to the ubuntu bug here:
> https://bugs.launchpad.net/xorg-server/+bug/36812
> until it is officially included in an xserver-xorg release?
>
> Many many thanks!
> Nick
>
I forgot to note that "switch on release" is hard coded and cant be turned off.
So I am not sure it is good for wide using now. I think there will be the full solution and then ...
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/48
------------------------------------------------------------------------
On 2010-02-07T16:04:51+00:00 Nick Andrik wrote:
> I forgot to note that "switch on release" is hard coded and cant be turned off.
> So I am not sure it is good for wide using now. I think there will be the full
> solution and then ...
You mean for the case that someone wants to keep the old behavior?
I may ask why to want this, but I guess the people here we are a bit biased :-P
I could propose it as a solution that can be adopted for the people to
try.
Thanks again!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/49
------------------------------------------------------------------------
On 2010-02-07T16:14:17+00:00 Ilya Murav'jov wrote:
(In reply to comment #49)
>
> You mean for the case that someone wants to keep the old behavior?
> I may ask why to want this, but I guess the people here we are a bit biased :-P
>
> I could propose it as a solution that can be adopted for the people to try.
>
> Thanks again!
>
Yes, I mean that.
You're welcome.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/50
------------------------------------------------------------------------
On 2010-02-10T09:54:56+00:00 Oded Arbel wrote:
I've installed this patch on Ubuntu 9.10, Ubuntu 10.04 (alpha) and
Fedora 12. On all these the patch works great and I see no problems for
my use - which is granted not overly complex: two keyboard layouts with
ALT+SHIFT to switch and I'm using a lot of keyboard shortcuts in many
applications.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/51
------------------------------------------------------------------------
On 2010-02-10T11:21:18+00:00 Alon Bar-Lev wrote:
WORKING!
xorg-server-1.6.5
Thank you so much Ilya!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/52
------------------------------------------------------------------------
On 2010-02-13T08:40:01+00:00 Mike Ponomarenko wrote:
just tested in kubuntu 9.1 using packages from PPA's: works just as I
want it to work, so I am able to use eclipse IDE hotkeys, and that will
not cause undesired layout change.
Thanks!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/53
------------------------------------------------------------------------
On 2010-02-15T06:29:26+00:00 Eugene wrote:
Thank you!
How can I test this on my Ubuntu laptop? Is it packed in some packages or I need to compile it manually?
Can you provide an instruction, please?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/54
------------------------------------------------------------------------
On 2010-02-15T07:09:23+00:00 Nick Andrik wrote:
(In reply to comment #54)
> Thank you!
>
> How can I test this on my Ubuntu laptop? Is it packed in some packages or I
> need to compile it manually?
> Can you provide an instruction, please?
>
Take a look here:
https://bugs.launchpad.net/xorg-server/+bug/36812
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/55
------------------------------------------------------------------------
On 2010-03-22T14:08:41+00:00 Ori Avtalion wrote:
Excuse me in advance if I don't use xkb terminology. :)
Shouldn't the fix be more generic, and apply to all "modifier" keys
(such as ctrl, shift, alt, super) and not just layout/group switching
actions?
For example, I want to be able to map the Super key to an action (which
is currently impossible, AFAIK).
The logic should be something like this:
on key release:
if the released key was a modifier, and all the pressed keys are modifiers:
Fire the event
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/56
------------------------------------------------------------------------
On 2010-03-22T14:36:28+00:00 Ilya Murav'jov wrote:
(In reply to comment #56)
> Shouldn't the fix be more generic, and apply to all "modifier" keys (such as
> ctrl, shift, alt, super) and not just layout/group switching actions?
>
> For example, I want to be able to map the Super key to an action (which is
> currently impossible, AFAIK).
>
> The logic should be something like this:
>
> on key release:
> if the released key was a modifier, and all the pressed keys are modifiers:
> Fire the event
>
XKB deals with concrete, well known "actions", only. What event do you want to fire with Super?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/57
------------------------------------------------------------------------
On 2010-03-22T16:19:47+00:00 Ori Avtalion wrote:
(In reply to comment #57)
> XKB deals with concrete, well known "actions", only. What event do you want to
> fire with Super?
>
I was thinking of the functionality in gnome-keybinding-properties. I
thought its shortcomings were due to xkb, but apparently I was wrong :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/58
------------------------------------------------------------------------
On 2010-03-25T20:35:59+00:00 Daniel Stone wrote:
On Sun, Feb 07, 2010 at 02:17:25PM -0800, bugzilla-daemon at freedesktop.org wrote:
> --- Comment #45 from Ilya Murav'jov <muravev at yandex.ru> 2010-02-07 14:17:20 PST ---
> Created an attachment (id=33142)
> --> (http://bugs.freedesktop.org/attachment.cgi?id=33142)
> This patch is to resolve the issue; it is for "trunk" Xorg sources.
>
> Please try to patch Xorg from git://anongit.freedesktop.org/git/xorg/xserver
> and comment if the patch works for you.
The patch looks pretty much fine to me, except that I'd just hardcode
release-only and don't try to make it configurable. I'm not entirely
sure about the bit marked with KLUDGE, and would like to find a better
way to do it, but if that's fixed (I'll try to have a look this weekend
or next, depending on time), my only objection to merging it is that it
explicitly contradicts the spec. I'm not entirely convinced that's a
dealbreaker though.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/59
------------------------------------------------------------------------
On 2010-04-29T12:43:05+00:00 Paulo Zanoni wrote:
Ping? No new patch versions? Will this be applied?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/60
------------------------------------------------------------------------
On 2010-05-05T08:58:17+00:00 Alexander Pavlov wrote:
The patch works like a charm for me Ubuntu Karmic, 9.10. Daniel please
do apply it. It makes a broken thing (shortcuts) work for multilingual
users and doesn't harm others.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/61
------------------------------------------------------------------------
On 2010-05-12T14:38:34+00:00 Ilya Murav'jov wrote:
I've found something wrong with the patch: the keyboard starts to type capital letters with no Shift and CapsLock after changing the layout (Ctrl+Shift). That behaviour cant be always reproduced. Like so:
яzЯzяZЯzzяzяZяzЯzяZяzяzяzяzяZя
Not good ...
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/62
------------------------------------------------------------------------
On 2010-07-04T16:52:34+00:00 Ethan Shalev wrote:
(In reply to comment #62)
> I've found something wrong with the patch: the keyboard starts to type capital
> letters with no Shift and CapsLock after changing the layout (Ctrl+Shift). That
> behaviour cant be always reproduced. Like so:
> яzЯzяZЯzzяzяZяzЯzяZяzяzяzяzяZя
>
> Not good ...
Have you managed to solve this? or discover a pattern, like under what circumstances this occurs?
If it doesn't happen too often, I'd be in favor of rolling out this patch, and closing this bug before it enters its 7th year.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/63
------------------------------------------------------------------------
On 2010-07-05T11:41:51+00:00 Ilya Murav'jov wrote:
(In reply to comment #63)
> (In reply to comment #62)
> > I've found something wrong with the patch: the keyboard starts to type capital
> > letters with no Shift and CapsLock after changing the layout (Ctrl+Shift). That
> > behaviour cant be always reproduced. Like so:
> > яzЯzяZЯzzяzяZяzЯzяZяzяzяzяzяZя
> >
> > Not good ...
>
> Have you managed to solve this? or discover a pattern, like under what
> circumstances this occurs?
> If it doesn't happen too often, I'd be in favor of rolling out this patch, and
> closing this bug before it enters its 7th year.
No. Unfortunately, it is difficult to get rid of it:
- much worse repeatable under debug
- it is repeatable only on my working machine, not one I use for debugging Xorg (notebook)
At first everything was fine until I started playing with keyboard
settings (gnome-keyboard-properties -> Layouts -> Layout Options). Wait
a minute ... Ahhhh, things go wrong if "Use keyboard LED to show
alternative layout"->ScrollLock is on! That is why I couldn't reproduce
it on my notebook (it doesn't have keyboard LEDs). Mmm, it is much
better now :)
As for the patch, you can use Oded Arbel' repository to try it without building
Xorg yourself, http://launchpad.net/~oded-geek/+archive/xorg-patches .
P.S. I am not a developer of Xorg so I could not commit anything. On the
other hand, the devs seems to be not interested too. nobody cares :(
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/64
------------------------------------------------------------------------
On 2010-07-12T15:31:57+00:00 Vasa Maximov wrote:
Ilya, SPASIBO for the patch and hint with http://launchpad.net/~oded-
geek/+archive/xorg-patches
Patch works perfectly - no side effects, everything goes as expected on
Ubuntu 10.04
For me keyboard shortcuts are vital, and I've been waiting for this fix
since 2001 - when i first met linux. Thank you VERY much!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/65
------------------------------------------------------------------------
On 2010-08-30T11:28:38+00:00 Bas-bmail wrote:
Applied the patch to xorg-server-1.7.7 (Mandriva 2010.1). Works as a
charm. Looking forward to having this patch upstream.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/66
------------------------------------------------------------------------
On 2010-10-12T12:17:30+00:00 Nick Andrik wrote:
Ilya, did you debug the problem with the led as you described in #64?
Also, Daniel (the responsible for the patches to get accepted if I
understood correctly) raised some concerns on #59. Do you think you
could address them? I believe after that the patch will get accepted.
What do you think?
Thanks a lot for you contribution
Nick
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/67
------------------------------------------------------------------------
On 2010-10-12T12:43:55+00:00 Ilya Murav'jov wrote:
(In reply to comment #67)
> Ilya, did you debug the problem with the led as you described in #64?
>
> Also, Daniel (the responsible for the patches to get accepted if I understood
> correctly) raised some concerns on #59. Do you think you could address them? I
> believe after that the patch will get accepted.
>
> What do you think?
>
I didn't debug #64; I don't see something wrong with #59.
I think the opposite,- as I understand from a few conversations Daniel
do not accept the patch because of some policy. So improvements don't
make sense, and I am somewhat disappointed.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/68
------------------------------------------------------------------------
On 2010-10-12T15:10:46+00:00 Vasa Maximov wrote:
(In reply to comment #67)
> Ilya, did you debug the problem with the led as you described in #64?
As for #64: I have used this gnome setting (ScrollLock to indicate
layout) all the time since comment #65 and haven't experienced any
issues. Except minor: scrollLock key is not able to control ScrollLock
LED (who even cares?). I can't remember how it worked before patch, but
pretty sure - that's Gnome behavior.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/69
------------------------------------------------------------------------
On 2010-10-12T15:16:30+00:00 Nick Andrik wrote:
I believe scrollLock LED is used from gnome(?) to indicate the alternative layout.
At least this is how it works on me with the ubuntu xorg (without the patch from ilya)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/70
------------------------------------------------------------------------
On 2010-10-14T20:44:20+00:00 Nick Andrik wrote:
After Vasa, comment I made some exploration of the scroll lock issue and
in both cases (patched X or unpatched X) the behavior is exactly the
same.
The led can be used to indicate the alternative layout (from gnome's
settings) and it works as advertised: it switches on/off as long as the
layout changes.
Even if the above functionality is disabled, still the Scroll Lock key makes no difference in gnome. I suspect that scroll lock mode never gets enabled.
I tested it in virtual consoles (Ctrl+Alt+F1) and it works like Ctrl+S (pause any console output), while in gnome (tested in xterm and gnome-terminal) the scroll lock key does absolutely nothing.
Daniel, is there anything else needed for the patch to get accepted in the official branch?
Thanks a lot.
Nick
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/71
------------------------------------------------------------------------
On 2010-10-14T20:45:05+00:00 Nick Andrik wrote:
After Vasa's comment, I made some exploration of the scroll lock issue
and in both cases (patched X or unpatched X) the behavior is exactly the
same.
The led can be used to indicate the alternative layout (from gnome's
settings) and it works as advertised: it switches on/off as long as the
layout changes.
Even if the above functionality is disabled, still the Scroll Lock key makes no difference in gnome. I suspect that scroll lock mode never gets enabled.
I tested it in virtual consoles (Ctrl+Alt+F1) and it works like Ctrl+S (pause any console output), while in gnome (tested in xterm and gnome-terminal) the scroll lock key does absolutely nothing.
Daniel, is there anything else needed for the patch to get accepted in the official branch?
Thanks a lot.
Nick
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/72
------------------------------------------------------------------------
On 2010-10-15T19:05:46+00:00 Alexander Kojevnikov wrote:
Just to confirm that Ilya's patch from comment 45 completely fixes the
problem without any noticeable side-effects. I'm running X11R7.5 under
FreeBSD 8.1
Daniel, could you review and eventually commit the patch? This bug is
quite annoying.
Thank you!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/73
------------------------------------------------------------------------
On 2010-12-03T03:32:59+00:00 Dave Walker wrote:
Hi,
Is there an update on the status of this bug please?
Kind Regards,
Dave Walker
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/74
------------------------------------------------------------------------
On 2010-12-03T08:39:30+00:00 Simos Xenitellis wrote:
(In reply to comment #74)
> Hi,
>
> Is there an update on the status of this bug please?
>
My guess is that this bug is stuck at the point where the patch needs
extensive and explicit testing.
Some users tested this on their system, however they should to come up
with a more rigorous description of what they have tested.
Things to test would include
1. Describe which shortcut you use to switch layouts (Alt+Shift, Shift+Shift, etc)
2. Mention outcome when using with Firefox, OpenOffice, Inkscape, some GTK+ and QT apps.
3. Is there any problem when using IBus? Check the shortcuts that activate/deactivate/switch layout in IBus.
4. how long you have been using your Linux with this patch applied.
5. GTK+ allows to type arbitrary Unicode characters with Ctrl+Shift+u <HEX codepoint>. Does this continue to work?
6. An important test case is to use Inkscape and switch layouts with Alt+Shift. Presumably, Alt+Shift+xyz is a type of valid shortcuts in Inkscape, and affected by this bug. Is this now solved?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/75
------------------------------------------------------------------------
On 2010-12-04T08:40:00+00:00 Bas-bmail wrote:
(In reply to comment #75)
> (In reply to comment #74)
> > Hi,
> >
> > Is there an update on the status of this bug please?
> >
>
> My guess is that this bug is stuck at the point where the patch needs extensive
> and explicit testing.
>
> Some users tested this on their system, however they should to come up with a
> more rigorous description of what they have tested.
>
> Things to test would include
> 1. Describe which shortcut you use to switch layouts (Alt+Shift, Shift+Shift,
> etc)
> 2. Mention outcome when using with Firefox, OpenOffice, Inkscape, some GTK+ and
> QT apps.
> 3. Is there any problem when using IBus? Check the shortcuts that
> activate/deactivate/switch layout in IBus.
> 4. how long you have been using your Linux with this patch applied.
> 5. GTK+ allows to type arbitrary Unicode characters with Ctrl+Shift+u <HEX
> codepoint>. Does this continue to work?
> 6. An important test case is to use Inkscape and switch layouts with Alt+Shift.
> Presumably, Alt+Shift+xyz is a type of valid shortcuts in Inkscape, and
> affected by this bug. Is this now solved?
I guess most people are just satisfied with this patch, which,
obviously, works great. Therefore nobody really cares if it would go
upstream or not, because, obviously, it won't (otherwise, tell me, how
much longer it should take to accept this patch?).
Also, the "things to test would include" items look like the author
hasn't even tested the patch, otherwise, he wouldn't have any of those
concerns.
Thank you.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/76
------------------------------------------------------------------------
On 2010-12-04T18:23:33+00:00 Alexander Kojevnikov wrote:
(In reply to comment #76)
> I guess most people are just satisfied with this patch, which, obviously, works
> great.
It does indeed, just look as the number of comments confirming it.
> Also, the "things to test would include" items look like the author hasn't even
> tested the patch, otherwise, he wouldn't have any of those concerns.
I went ahead and did the tests grandfather mentioned:
(In reply to comment #75)
> 1. Describe which shortcut you use to switch layouts (Alt+Shift, Shift+Shift,
> etc)
Alt+Shift, I guess that's what most people use (it's a Windows default
too)
> 2. Mention outcome when using with Firefox, OpenOffice, Inkscape, some GTK+ and
> QT apps.
No issues whatsoever. Tested it on ArchLinux and on FreeBSD.
> 3. Is there any problem when using IBus? Check the shortcuts that
> activate/deactivate/switch layout in IBus.
Is it for CJK input? Never used it.
> 4. how long you have been using your Linux with this patch applied.
Linux almost since this patch has been submitted, FreeBSD - for 3
months.
> 5. GTK+ allows to type arbitrary Unicode characters with Ctrl+Shift+u <HEX
> codepoint>. Does this continue to work?
Yes: ☺ ♫ ⊥
> 6. An important test case is to use Inkscape and switch layouts with Alt+Shift.
> Presumably, Alt+Shift+xyz is a type of valid shortcuts in Inkscape, and
> affected by this bug. Is this now solved?
Yes, also some Emacs shortcuts were affected by this bug (e.g. M-> and
M-<) and now work fine.
I really hope this patch gets committed, the keyboard input *is* broken
without it for users who use multiple keyboard layouts. I personally
don't mind patching xorg-server manually, but I guess most users do.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/77
------------------------------------------------------------------------
On 2010-12-05T00:16:37+00:00 Oded Arbel wrote:
(In reply to comment #75)
> Things to test would include
> 3. Is there any problem when using IBus? Check the shortcuts that
> activate/deactivate/switch layout in IBus.
Input methods may be a problem as i dont think anyone who is interested in this is using IM. I dont know why - maybe IM users dont use layout switching shortcuts, maybe they don't use shortcuts at all? But that is
A good reason to apply this patch to X.org's trunk - until that is done we cant get any serious testing of this feature as the only people that encounter the patch are the people that come looking for it specifically and all those fall into a set of well defined parameters.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/78
------------------------------------------------------------------------
On 2011-01-06T16:04:59+00:00 Ilya Murav'jov wrote:
The patch has been applied in Ubuntu, just now.
Today is a good day. :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/79
------------------------------------------------------------------------
On 2011-01-08T05:52:26+00:00 Oded Arbel wrote:
The following comments were made by Peter Hutterer (an X.org input developer) on the corresponding bug in RedHat bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=660254 ):
(In reply to comment #6)
> implementing this behaviour requires guesswork that I'm not sure is safe in a
> number of setups.
...
> afaict, the desired behaviour for a ctrl+shift groupchange is:
> ctrl down → set Control modifier
> shift down → set Shift modifier
> if (other key pressed)
> send event Contrl+Shift+<other key>
> else if (ctrl || shift released)
> change group
>
> The XKB map for left control in this case is:
> key <LCTL> { [ Control_L, ISO_Next_Group ] };
> So whenever ISO_Next_Group is pressed, you still need to know which modifier to
> set in case the group action isn't executed. The XkbSA_SetMod, XkbSA_LockMod,
> etc. actions provide the modifiers set for a given key, hence why it works
> currently. This information comes from the client when the xkb map is loaded
> and is used to trigger the modifier flags for a given key. The XkbSA_LockGroup
> behaviour (which is triggered at ISO_Next_Group) does not have this field
> (adding it would break ABI), so you need to guess which modifiers to set if you
> didn't trigger this action. This is the main stumbling point that I found and
> if you look at Ilya's patch that's where he needs the big hack that I'm not
> comfortable at all with it.
>
> Now, I don't know if there are layouts where the modifier mask would be
> different on the second level as opposed to the first (and Ilya's hack or a
> similar attempt would fail completely) but there's so many layouts that it'll
> take a while to get through them all.
Ilya - this is hardly my area of expertise, so if you can address these
issues - either by commenting here, on the RedHat bugzilla or by
changing the patch - I would greatly appreciate that.
Thanks to all the people who are involved, and lets keep the
communication channels open :-)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/80
------------------------------------------------------------------------
On 2011-01-08T14:32:10+00:00 Ilya Murav'jov wrote:
(In reply to comment #80)
Ok, I try to answer here, but I should note that I don't remember full details
(because it was more than half a year ago).
> The following comments were made by Peter Hutterer (an X.org input developer)
> on the corresponding bug in RedHat bugzilla (
> https://bugzilla.redhat.com/show_bug.cgi?id=660254 ):
> (In reply to comment #6)
> > implementing this behaviour requires guesswork that I'm not sure is safe in a
> > number of setups.
> ...
> > afaict, the desired behaviour for a ctrl+shift groupchange is:
> > ctrl down → set Control modifier
> > shift down → set Shift modifier
> > if (other key pressed)
> > send event Contrl+Shift+<other key>
> > else if (ctrl || shift released)
> > change group
> >
> > The XKB map for left control in this case is:
> > key <LCTL> { [ Control_L, ISO_Next_Group ] };
> > So whenever ISO_Next_Group is pressed, you still need to know which modifier to
> > set in case the group action isn't executed. The XkbSA_SetMod, XkbSA_LockMod,
> > etc. actions provide the modifiers set for a given key, hence why it works
> > currently. This information comes from the client when the xkb map is loaded
> > and is used to trigger the modifier flags for a given key. The XkbSA_LockGroup
> > behaviour (which is triggered at ISO_Next_Group) does not have this field
> > (adding it would break ABI), so you need to guess which modifiers to set if you
> > didn't trigger this action. This is the main stumbling point that I found and
> > if you look at Ilya's patch that's where he needs the big hack that I'm not
> > comfortable at all with it.
I do not agree. You do not need to know/guess which modifiers to set - whenever
ISO_Next_Group is pressed I just don't execute it immediately but delay it till a key release (by the means of _XkbNextFreeFilter()/_XkbApplyFilters() ). Btw, that trick was suggested by Daniel Stone (somewhere on the mail list).
And I want to note that where I comment ":KLUDGE:" I mean a different
thing: in theory that branch of code should do the same thing as the
switch in XkbHandleActions() ; but, in practice I see (and want) only
XkbSA_SetMods action (so kludge here is copy-n-paste from
XkbHandleActions() ).
> >
> > Now, I don't know if there are layouts where the modifier mask would be
> > different on the second level as opposed to the first (and Ilya's hack or a
> > similar attempt would fail completely) but there's so many layouts that it'll
> > take a while to get through them all.
(do not understand properly the above, sorry) The only situation the patch fails
(just behaves old way, and nothing more!) is when switching is set up as just one key like "Right Alt". That is because of the line
fake_state.mods = 0;
, mods here is 0 anyway => we can't block XkbSA_LockGroup .
Anyway, nobody wants more,- but only (de facto standard) Ctrl+Shift and
Alt+Shift on release. I think this is the situation where the practice
begins and the theory ends.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/81
------------------------------------------------------------------------
On 2011-04-07T12:31:45+00:00 T-artem wrote:
I'm confused. This bug is now 7 years old and it's still not fixed? What
year of desktop Linux are we talking about when basic things in Linux
are largely broken?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/82
------------------------------------------------------------------------
On 2011-04-07T16:15:42+00:00 Peter Hutterer wrote:
(In reply to comment #82)
> I'm confused. This bug is now 7 years old and it's still not fixed? What year
> of desktop Linux are we talking about when basic things in Linux are largely
> broken?
thanks. empty rhetoric is the greatest way of motivating developers.
This bug just dropped to the bottom of my priority list again.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/83
------------------------------------------------------------------------
On 2011-04-07T23:59:18+00:00 T-artem wrote:
(In reply to comment #83)
> thanks. empty rhetoric is the greatest way of motivating developers. This bug
> just dropped to the bottom of my priority list again.
Peter, I'm terribly sorry for rending the air. Please, consider
resolving this bug ASAP since there are thousands of people affected by
it. I won't drop another comment here ever.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/84
------------------------------------------------------------------------
On 2011-04-08T01:05:27+00:00 Bas-bmail wrote:
(In reply to comment #84)
> (In reply to comment #83)
> > thanks. empty rhetoric is the greatest way of motivating developers. This bug
> > just dropped to the bottom of my priority list again.
>
> Peter, I'm terribly sorry for rending the air. Please, consider resolving this
> bug ASAP since there are thousands of people affected by it. I won't drop
> another comment here ever.
You don't have to excuse. You have more rights to be pissed off than a
developer who puts an obvious and already proved (by time) to work patch
to the end of his TODO list.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/85
------------------------------------------------------------------------
On 2011-04-08T03:13:41+00:00 Daniel Stone wrote:
On Fri, Apr 08, 2011 at 01:05:34AM -0700, bugzilla-daemon at freedesktop.org wrote:
> --- Comment #85 from kyak <bas at bmail.ru> 2011-04-08 01:05:27 PDT ---
> (In reply to comment #84)
> > (In reply to comment #83)
> > > thanks. empty rhetoric is the greatest way of motivating developers. This bug
> > > just dropped to the bottom of my priority list again.
> >
> > Peter, I'm terribly sorry for rending the air. Please, consider resolving this
> > bug ASAP since there are thousands of people affected by it. I won't drop
> > another comment here ever.
>
> You don't have to excuse. You have more rights to be pissed off than a
> developer who puts an obvious and already proved (by time) to work patch to the
> end of his TODO list.
Already proven to break the XKB specification, yes.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/86
------------------------------------------------------------------------
On 2011-04-08T12:52:19+00:00 DmitryKX wrote:
Can we pay to speed up the fixing of this bug?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/87
------------------------------------------------------------------------
On 2011-04-08T13:10:46+00:00 Oded Arbel wrote:
(In reply to comment #86)
> Already proven to break the XKB specification, yes.
Hi Daniel. I've seen this comment about breaking the XKB specification
in several places and - I'm really not trying to be contrary - I looked
at the protocol specs here
http://www.x.org/releases/current/doc/kbproto/xkbproto.html and I can't
understand how this behavior change contradicts the spec.
Now - I'm not a trained X11 developer, and I'm not even that good at
reading specs, so I would really appreciate it if you can point me at
the section relevant to the breakage you discuss, so I can be more
informed about the issue.
Thanks in advance.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/88
------------------------------------------------------------------------
On 2011-04-08T13:18:04+00:00 T-artem wrote:
(In reply to comment #87)
> Can we pay to speed up the fixing of this bug?
I second this motion.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/89
------------------------------------------------------------------------
On 2011-04-11T08:40:34+00:00 Ilya Murav'jov wrote:
(In reply to comment #88)
> (In reply to comment #86)
> > Already proven to break the XKB specification, yes.
>
> Hi Daniel. I've seen this comment about breaking the XKB specification in
> several places and - I'm really not trying to be contrary - I looked at the
> protocol specs here http://www.x.org/releases/current/doc/kbproto/xkbproto.html
> and I can't understand how this behavior change contradicts the spec.
>
> Now - I'm not a trained X11 developer, and I'm not even that good at reading
> specs, so I would really appreciate it if you can point me at the section
> relevant to the breakage you discuss, so I can be more informed about the
> issue.
>
> Thanks in advance.
Hi Oded,
It is not in XKBproto but in XKBlib spec. You can see the only assertion
against changing layout on release in general (and the patch in
particular) in ftp://ftp.x.org/pub/X11R7.0/doc/PDF/XKBlib.pdf, "Table
16.4 Group Action Types", the last item XkbSA_LockGroup, citing:
"
1. If the XkbSA_GroupAbsolute is set in the flags field, key press events set the locked keyboard group to the group specified by the group_XXX field. Otherwise, key press events add the group specified by the group_XXX field to the locked keyboard group. In either case, the resulting locked and effective keyboard groups are brought back into range depending on the value of the groups_wrap field of the con-trols structure.
2. A key release has no effect.
"
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/90
------------------------------------------------------------------------
On 2011-04-18T11:58:35+00:00 Michal Ambroz wrote:
I would vote for this change as well.
I understand that it is not aligned with 13 years old standard and I am
sorry for that. Still I see changing group on press breaking much many
things than changing it on release. Maybe it is time to modify this
library specification, because there is a good reason for that. Do you
see any reason not to do it - other than there exists 13 years old
library specification?
Best regards
Michal Ambroz
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/91
------------------------------------------------------------------------
On 2011-08-22T07:14:34+00:00 N3ocort3x wrote:
For Gentoo and derivatives users, a working solution for patching is
described here:
https://bugs.gentoo.org/show_bug.cgi?id=379827
Bug report description includes guidance for how an ebuild file for
automatic patching of XkbActions.c can be achieved, and an example
ebuild file that applies Ilya's patch to Gentoo version of xorg-
server-1.10.3 as attachment is also provided by Lance Poore.
I am using the patched version happily now without having any problems.
Please consider including the patch in upstream. I am sure it would make
thousands of desktop Linux users' lives easier.
Thanks Ilya! and thanks to Lance in the name of Gentoo Linux multilingual keyboard users.
Happy patching :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/92
------------------------------------------------------------------------
On 2011-08-22T07:21:31+00:00 Alon Bar-Lev wrote:
Long ago a bug was opened for this issue.
https://bugs.gentoo.org/show_bug.cgi?id=304375
On Mon, Aug 22, 2011 at 5:14 PM, <bugzilla-daemon at freedesktop.org> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=865
>
> --- Comment #92 from youagree <n3ocort3x at gmail.com> 2011-08-22 07:14:34 PDT ---
> For Gentoo and derivatives users, a working solution for patching is described
> here:
>
> https://bugs.gentoo.org/show_bug.cgi?id=379827
>
> Bug report description includes guidance for how an ebuild file for automatic
> patching of XkbActions.c can be achieved, and an example ebuild file that
> applies Ilya's patch to Gentoo version of xorg-server-1.10.3 as attachment is
> also provided by Lance Poore.
>
> I am using the patched version happily now without having any problems. Please
> consider including the patch in upstream. I am sure it would make thousands of
> desktop Linux users' lives easier.
>
> Thanks Ilya! and thanks to Lance in the name of Gentoo Linux multilingual
> keyboard users.
> Happy patching :)
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/93
------------------------------------------------------------------------
On 2011-08-22T13:04:17+00:00 N3ocort3x wrote:
(In reply to comment #93)
> Long ago a bug was opened for this issue.
>
> https://bugs.gentoo.org/show_bug.cgi?id=304375
>
And marked as "resolved upstream". Which is just not true, at least
according to the ebuilds. Havent taken a look at the code itself, but
can you currently point to any existing xorg source repository with the
patch applied or where xorg server has the same functionality issue
cured?
Thanks
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/94
------------------------------------------------------------------------
On 2011-09-25T16:12:17+00:00 Jeremy Huddleston wrote:
Lots of CCs ... I'm gonna bring this into the tracker to see if there's
something we can eventually do about this in a way that won't break backwards
compatibility.
Daniel, do you have any thoughts about how this could be done by extending XKB
rather than breaking it?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/95
------------------------------------------------------------------------
On 2011-12-25T23:54:41+00:00 Aharel wrote:
(In reply to comment #90)
> (In reply to comment #88)
> > (In reply to comment #86)
> > > Already proven to break the XKB specification, yes.
> > ...
>
> It is not in XKBproto but in XKBlib spec. You can see the only assertion
> against changing layout on release in general (and the patch in particular) in
> ftp://ftp.x.org/pub/X11R7.0/doc/PDF/XKBlib.pdf, "Table 16.4 Group Action
> Types", the last item XkbSA_LockGroup, citing:
>
> "
> 1. If the XkbSA_GroupAbsolute is set in the flags field, key press events set
> ....
> 2. A key release has no effect.
> "
Thanks again Ilya!
First for providing the patch, and then for high-lighting exactly where the XKB standard made what we now know to be a bad choice. Happens. No one's perfect. Not even the wisdom of the Xfree86 crowd.
Anyone know whether / how the standard can be brought up to date, so it joins us in the new millennium?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/96
------------------------------------------------------------------------
On 2011-12-27T21:57:31+00:00 Jeremy Huddleston wrote:
Deferring to 1.13 as this is functional change
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/97
------------------------------------------------------------------------
On 2012-04-01T11:04:34+00:00 Bas-bmail wrote:
The patch doesn't apply anymore to latest xorg. Could someone update it,
please?
I tried to just blindly port this patch, but it seems to cause problems
with Caps Lock (it can't be switched off once switched on). So something
has changed.
Could someone with xorg knowledge have a look please?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/98
------------------------------------------------------------------------
On 2012-04-10T10:59:43+00:00 Bas-bmail wrote:
Sorry, it was my overlook. THe patch works just fine, just needed more
attention adapting to latest sources.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/99
------------------------------------------------------------------------
On 2012-04-10T11:01:13+00:00 Bas-bmail wrote:
Created attachment 59741
The same patch, but based on 1.12.0.902
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/100
------------------------------------------------------------------------
On 2012-06-03T03:16:12+00:00 Powerman-asdf wrote:
While this patch solve conflict between keyboard layout switching hotkey
and other hotkeys, it doesn't fix this issue in general. For example, in
one have hotkey defined for Win key (a.k.a. Super_L), and for
Win+something, the first hotkey handler will always run when Win key
DOWN, thus pressing Win+something will result in executing both Win and
Win+something handlers.
It should be fixed in same way: process current key combination on first
UP event after a sequence of DOWN events, not on first DOWN.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/101
------------------------------------------------------------------------
On 2012-06-23T12:55:39+00:00 Alon Bar-Lev wrote:
Created attachment 63378
xorg-server-1.12.2-xkb-switch-on-release.patch
Some code style modifications.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/102
------------------------------------------------------------------------
On 2012-08-19T15:30:36+00:00 Julius Schwartzenberg wrote:
This patch breaks the keyboard layout switcher from KDE3 and Trinity. It
works correctly with the layout switcher in KDE4. Have other people
tested this patch with other layout switchers? What are the results?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/103
------------------------------------------------------------------------
On 2012-08-24T08:24:05+00:00 Oded Arbel wrote:
(In reply to comment #103)
> This patch breaks the keyboard layout switcher from KDE3 and Trinity. It works
> correctly with the layout switcher in KDE4. Have other people tested this patch
> with other layout switchers? What are the results?
This works fine with all switchers shipped on Ubuntu (gnome, unity,
kde4, etc.).
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/104
------------------------------------------------------------------------
On 2012-08-27T08:06:11+00:00 Murz wrote:
Oded Arbel, how did you test this patch on Ubuntu? Can you give me some
link to PPA or deb files for testing?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/105
------------------------------------------------------------------------
On 2012-08-27T10:06:58+00:00 RussianNeuroMancer wrote:
> how did you test this patch on Ubuntu?
It's already merged. You may just install latest Ubuntu to check this patch in action. Personally I doesn't have any troubles with this patch too (KDE4, Unity).
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/106
------------------------------------------------------------------------
On 2012-10-02T19:40:01+00:00 Spitzak-k wrote:
As in comment 101, the current behavior of X prevents a lot of
interesting usage of shift keys as shortcuts.
A Windows-only compose key program uses the "ctrl" key as the compose
key. This is apparently impossible to do in X input methods because you
can only bind actions to the press of "ctrl". What is wanted is an
action if "ctrl" is pressed and released without hitting any other keys.
I think this can be solved more easily. For any "shift" key, you can
bind actions to them, but they are only triggered if you press & release
the shift key. All other keys trigger bound actions when they are
pressed. The keyboard switching is NOT a special case.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/107
------------------------------------------------------------------------
On 2012-10-02T20:23:48+00:00 kitaets wrote:
I don't know what they have done in Ubuntu but 12.04 understands both
press and release. Layout switching happens on release. If you press Alt
you see the global menu and after release HUD uppears. Looks like
everything has been fixed. But if you use Ctrl or Alt for layout
switching you still can't use this key for anything more, it's
"exclusived" :( So ridiculous.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/108
------------------------------------------------------------------------
On 2012-10-03T14:52:19+00:00 Oded Arbel wrote:
(In reply to comment #108)
> I don't know what they have done in Ubuntu but 12.04 understands both press
> and release. Layout switching happens on release.
Ubuntu have simply applied Ilya's patch (one of the revisions attached
here) to fix the layout switching problem.
> If you press Alt you see
> the global menu and after release HUD uppears.
This is a different behavior and one that works with the pristine X.org
server - the ALT key, when used without any other shift keys, fires
"down" when pressed and "up" when released. The Ubuntu HUD listens for
this sequence and triggers when ALT is used like that without any other
shift key.
The problematic behavior (as documented in this lengthy bug report -
kitates, please read the discussion), is that when you press down on the
second shift key, X.org fires the keyboard layout change (problem 1) and
also immediately fires the "up" event for the second shift key, even
though the user is still holding the key down (problem 1).
Problem 1 means that when the user wants to use <shift1>+<shift2>+<key>
as a keyboard shortcut (when "shift1" and "shift2" are the shift keys
used for layout switching, for example ALT+SHIFT or CTRL+ALT), then the
user will inadvertently also trigger a layout switching that wasn't
supposed to happen.
Problem 2 means that the actual keyboard shortcut will never actually
trigger because when the user holds down <key>, even though all keys are
physically held down X.org only acknowledges that <shift1> and <key> are
held down.
> Looks like everything has
> been fixed. But if you use Ctrl or Alt for layout switching you still can't
> use this key for anything more, it's "exclusived" :( So ridiculous.
It shouldn't work like that - I've tested the Ubuntu built X.org (with
Ilya's patch) and it worked properly when using CTRL+ALT as the keyboard
switching. It was immediately after the patch got accepted (at 11.04)
but as ALT+SHIFT still works fine, I don't see a reason everything
shouldn't continue to work (though I don't have access to an Ubuntu
machine ATM to test).
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/109
------------------------------------------------------------------------
On 2012-10-04T19:10:22+00:00 Wettstae wrote:
(In reply to comment #107)
> A Windows-only compose key program uses the "ctrl" key as the compose key.
> This is apparently impossible to do in X input methods because you can only
> bind actions to the press of "ctrl".
Of course this is possible. Compose is unrelated to actions in the XKB
meaning of the term. It is not only possible, it is even implemented in
the XIM compose code. You can put
<Control_L><a><e> : ae
and similar stuff in your .XCompose, and your left control key acts as a
Compose key. But you need the latest libX11 for this.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/110
------------------------------------------------------------------------
On 2012-10-14T09:55:17+00:00 Bas-bmail wrote:
I'm really disappointed this change didn't make it to 1.13.
I'm sick and tired of applying this patch after each xorg update.
How many users (and years) do you need to finally accept this change?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/111
------------------------------------------------------------------------
On 2012-10-14T15:17:34+00:00 Wettstae wrote:
I believe the most serious objection with this request is that it
violates the XKB specification (see the description of SA_LockGroup in
section 6.3 of "The X Keyboard Extension: Protocol Specification").
In the same specification, in section 4.0 of appendix D ("Protocol
Encoding"), we see in the description of SA_LockGroup that there are
still 5 unused bits in the flags field. My proposal in to use one of
these bits decide whether to lock groups on press or release. By
default (bit is zero), lock groups on press as the protocol
specification demands. If the flag is one, lock groups on release. So
by default, we would conform to the specification, and add the
alternative behaviour as a new possibility beyond the specification.
There are some usage implications. One must use 'Private' do create
actions with the new flag set (until xkbcomp is updated as well), and
one needs support in xkeyboard-config to make the new feature usable for
non-XKB-hackers.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/112
------------------------------------------------------------------------
On 2012-10-14T16:33:59+00:00 Bas-bmail wrote:
(In reply to comment #112)
> I believe the most serious objection with this request is that it violates
> the XKB specification (see the description of SA_LockGroup in section 6.3 of
> "The X Keyboard Extension: Protocol Specification").
>
> In the same specification, in section 4.0 of appendix D ("Protocol
> Encoding"), we see in the description of SA_LockGroup that there are still 5
> unused bits in the flags field. My proposal in to use one of these bits
> decide whether to lock groups on press or release. By default (bit is
> zero), lock groups on press as the protocol specification demands. If the
> flag is one, lock groups on release. So by default, we would conform to the
> specification, and add the alternative behaviour as a new possibility beyond
> the specification.
>
> There are some usage implications. One must use 'Private' do create actions
> with the new flag set (until xkbcomp is updated as well), and one needs
> support in xkeyboard-config to make the new feature usable for
> non-XKB-hackers.
Thanks Andreas, your answer pretty much clarifies everything for me!
Your proposal is very correct, no doubt. Does it mean that once your
proposal is implemented all 3rd-party keyboard switchers (like those in
Gnome and KDE) would have to be updated to make use of this new
possibility?
Anyway, as i see it, there are two ways to go:
1) The long way - making things right and according to specification. This would take from very long to forever (this is the way we've been going for the last 8 years with this bug report).
2) Take a short way - let the common sense win over specification and make everybody happy.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/113
------------------------------------------------------------------------
On 2012-10-14T18:15:30+00:00 Wettstae wrote:
> Your proposal is very correct, no doubt. Does it mean that once your
> proposal is implemented all 3rd-party keyboard switchers (like those in
> Gnome and KDE) would have to be updated to make use of this new possibility?
As far as I understand, KDE and Gnome all use xkeyboard-config, and just
provide their own GUI. If this is understanding is correct, the changes
to xkeyboard-config would be sufficient.
> Anyway, as i see it, there are two ways to go:
> 1) The long way - making things right and according to specification. This
> would take from very long to forever (this is the way we've been going for
> the last 8 years with this bug report).
Assuming the existing patch is correct, adding the additional check for
the flag is just a few lines. The changes to xkeyboard-config would be
fairly simple. Assuming we grab bit 3 for the new flag, in xkeyboard-
config/compat/iso9995, change the current definition:
interpret ISO_Next_Group {
useModMapMods= level1;
virtualModifier= AltGr;
action= LockGroup(group=+1);
}
to
interpret ISO_Next_Group {
useModMapMods= level1;
virtualModifier= AltGr;
action= Private(type=6, data[0]=16, data[1]=1);
}
(untested, of course), and similarly for ISO_Prev_Group,
ISO_First_Group, and ISO_Last_Group. I do not know wether the action
bound to keysyms is standardised; even if it is not, it might be a good
idea to make the above redefinition conditional.
> 2) Take a short way - let the common sense win over specification and make
> everybody happy.
Believe it or not, I would be unhappy when the specification would be
broken. Also remember that the attitudes in this discussion are not
necessarily representative of all X users, as the users satisfied with
the current behaviour do not have any reason to even know about this
discussion.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/114
------------------------------------------------------------------------
On 2012-10-17T18:54:28+00:00 kitaets wrote:
(In reply to comment #109)
> (In reply to comment #108)
> > Looks like everything has
> > been fixed. But if you use Ctrl or Alt for layout switching you still can't
> > use this key for anything more, it's "exclusived" :( So ridiculous.
>
> It shouldn't work like that - I've tested the Ubuntu built X.org (with
> Ilya's patch) and it worked properly when using CTRL+ALT as the keyboard
> switching. It was immediately after the patch got accepted (at 11.04) but as
> ALT+SHIFT still works fine, I don't see a reason everything shouldn't
> continue to work (though I don't have access to an Ubuntu machine ATM to
> test).
Oded Arbel, I repeat: Ctrl OR Alt. OR, not AND. I use right Alt for
layout switching so I can't use it for any other purpose.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/115
------------------------------------------------------------------------
On 2012-10-28T14:55:03+00:00 Ilya Murav'jov wrote:
(In reply to comment #115)
> > It shouldn't work like that - I've tested the Ubuntu built X.org (with
> > Ilya's patch) and it worked properly when using CTRL+ALT as the keyboard
> > switching. It was immediately after the patch got accepted (at 11.04) but as
> > ALT+SHIFT still works fine, I don't see a reason everything shouldn't
> > continue to work (though I don't have access to an Ubuntu machine ATM to
> > test).
>
> Oded Arbel, I repeat: Ctrl OR Alt. OR, not AND. I use right Alt for layout
> switching so I can't use it for any other purpose.
Hi,
Actually, the patch works for key shortcuts with two or more buttons (like ALT+SHIFT, but not Alt or Ctrl alone). It is not done intentionally.
Despite the fact that there is a possibility to improve current patch behaviour for needs like yours I don't think it should be improved for all possible cases -
there are many other things to be done to make the world a better place.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/116
------------------------------------------------------------------------
On 2012-10-28T16:37:40+00:00 Wettstae wrote:
Created attachment 69198
LockMods can lock another group
This patch follows a different route: It extends modifier locking,
rather than changing how group lock works. Extending has the advantage
that the previous behaviour is maintained, and the patch does not
violate the X Keyboard Protocol Specification. Extending modifier
locking rather than group locking has the advantage that we do not need
the "Kludge" of the other patch, as we can pass the modifiers that we
want to set, rather then relying on heuristics.
The disadvantage over the existing patch is that we must change the
keymap.
Here are three examples. The left alt key is to switch to the next
layout when it is pressed and released before any other key is pressed.
key <LALT> {
repeat= No,
type= "TWO_LEVEL",
symbols[Group1]= [ Alt_L, Meta_L ],
actions[Group1]= [ Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1),
Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
};
Similarly, shifting group with Shift+Right Alt (where Shift is pressed
first):
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/117
------------------------------------------------------------------------
On 2012-10-28T16:39:09+00:00 Wettstae wrote:
Similarly, shifting group with Shift+Right Alt (where Shift is pressed
first):
key <RALT> {
repeat= No,
type= "TWO_LEVEL",
symbols[Group1]= [ Alt_R, Meta_R ],
actions[Group1]= [ SetMods(modifiers=Mod1),
Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
};
Shifting group with Shift+Left Control:
key <LCTL> {
repeat= No,
type= "TWO_LEVEL",
symbols[Group1]= [ Control_L, Control_L ],
actions[Group1]= [ SetMods(modifiers=Control),
Private(type=3,data[0]=1,data[1]=4,data[2]=4,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
};
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/118
------------------------------------------------------------------------
On 2012-10-28T17:06:28+00:00 Powerman-asdf wrote:
(In reply to comment #117)
> Similarly, shifting group with Shift+Right Alt (where Shift is pressed first):
Is this mean your patch won't work when Alt (or Ctrl) is pressed before Shift?
AFAIK most people press Ctrl, then Shift, then either release them (to switch layout) or press A-Z when they need Ctrl-Shift-something hotkey.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/119
------------------------------------------------------------------------
On 2012-10-28T17:49:19+00:00 Wettstae wrote:
> Is this mean your patch won't work when Alt (or Ctrl) is pressed before
> Shift?
It does not mean that. I just restricted to three examples. There is
no problem to rewrite all options that xkeyboard-config offers to switch
groups to take advantage of the patch.
> AFAIK most people press Ctrl, then Shift, then either release them (to
> switch layout) or press A-Z when they need Ctrl-Shift-something hotkey.
In this case, one needs to remap the shift key. For the left shift key:
key <LFSH> {
repeat= No,
type[Group1]="PC_CONTROL_LEVEL2",
symbols[Group1]= [ Shift_L, Shift_L ],
actions[Group1]= [ SetMods(modifiers=Shift),
Private(type=3,data[0]=1,data[1]=1,data[2]=1,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
};
For the right shift key it works similarly. If combined with the third
example above, it will make the order of Shift and Control irrelevant.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/120
------------------------------------------------------------------------
On 2012-10-29T08:43:43+00:00 Wettstae wrote:
Created attachment 69213
LockMods can lock another group
My previous patch does not properly account for absolute group
specification. The revised patch corrects this.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/121
------------------------------------------------------------------------
On 2012-11-02T02:36:20+00:00 Nick Andrik wrote:
Just to add something as a reply on comment #114:
Ubuntu has applied this patch already since 06 Jan 2011 all versions
till nowadays, as you can see in the changelogs here:
http://packages.ubuntu.com/quantal/xserver-xorg-core
Select "Ubuntu Changellog" and then search for "208_switch_on_release.diff".
Even after almost two years, there has been noone to file a bug report
that this change breaks anything. I believe this is quite a good
indication that Ilya's patch is already safe enough.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/122
------------------------------------------------------------------------
On 2013-04-11T06:57:56+00:00 Nicola Koshak wrote:
It is xorg-server 1.14, year 2013, and the bug still exists.
Do something with it already...
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/123
------------------------------------------------------------------------
On 2013-04-11T13:15:51+00:00 Eugene-shalygin+bugzilla-fdo wrote:
I wonder, bearing in mind the fact that Ubuntu has the patch for the
problem, will Mir be the first Linux display server which implemet this
feature? :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/124
------------------------------------------------------------------------
On 2013-04-11T13:35:18+00:00 T-artem wrote:
(In reply to comment #124)
> I wonder, bearing in mind the fact that Ubuntu has the patch for the
> problem, will Mir be the first Linux display server which implement this
> feature? :)
You've wandered far off.
Both Mir and Wayland have a completely different input architecture -
they simply don't have this problem from the very beginning.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/125
------------------------------------------------------------------------
On 2013-04-28T19:53:26+00:00 Headcrabextra wrote:
I've just installed OpenSuse 12.3 and met face to face with this bug.
Very frustrating, because of it I can't open last closed tab in chromium
with ctrl+shift+t.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/126
------------------------------------------------------------------------
On 2014-02-03T07:17:57+00:00 Igor Gnatenko wrote:
any news here?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/140
------------------------------------------------------------------------
On 2014-02-03T07:19:53+00:00 Murz wrote:
Igor Gnatenko, I partly solve my problem via KSuperKey app http://kde-apps.org/content/show.php?content=154569
so maybe it solve your needs too.
But I also waiting fix for this issue in xkb.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/141
------------------------------------------------------------------------
On 2014-09-06T20:30:17+00:00 Purkrtadam wrote:
As far as I can tell, it is already clear that XKB specifications needs
to be extended for this to be cleanly solved. While Ilya's hack works
for many people, and as much as I would like to see this fixed, I
understand why it is unacceptable to the developers. So, trying to delve
into XKB specs now; this page seems to be a good starting point to me:
https://wiki.archlinux.org/index.php/X_KeyBoard_extension
Also (as suggested by the author), copying info here from https://bugzilla.redhat.com/show_bug.cgi?id=660254
Peter Hutterer 2011-01-05 22:07:57 EST
there is two problems with the "tiny" patch you mentioned. one, it's an
_explicit_ violation of the XKB specification (see section 4.4). two,
implementing this behaviour requires guesswork that I'm not sure is safe
in a number of setups.
Peter Hutterer 2011-01-06 17:12:05 EST
(In reply to comment #4)
> But: doesn't fixing of a huge problem have a priority over preservation of a
> "holy spec"?
it's a matter of figuring out the side-effects. a specification is a behaviour promise, in this case in place for 15 years or so. a lot of users and apps rely on the promised behaviour (in general, not necessarily this specific issue) and breaking it is a dangerous thing because you may not know what else you break.
this is why we're hesitant to break the behaviour on purpose.
note that i'm not claiming that there is no problem, i'm just saying
it's the balance between a known problem and introducing new bugs that
potentially break current applications.
> > two,
> > implementing this behaviour requires guesswork that I'm not sure is safe in a
> > number of setups.
>
> What guesswork do you mean? Which setups can present problems?
> BTW, I'm 100% sure that Ilya Murav'jev (patch author) will be glad to
> cooperate.
afaict, the desired behaviour for a ctrl+shift groupchange is:
ctrl down → set Control modifier
shift down → set Shift modifier
if (other key pressed)
send event Contrl+Shift+<other key>
else if (ctrl || shift released)
change group
The XKB map for left control in this case is:
key <LCTL> { [ Control_L, ISO_Next_Group ] };
So whenever ISO_Next_Group is pressed, you still need to know which modifier to set in case the group action isn't executed. The XkbSA_SetMod, XkbSA_LockMod, etc. actions provide the modifiers set for a given key, hence why it works currently. This information comes from the client when the xkb map is loaded and is used to trigger the modifier flags for a given key. The XkbSA_LockGroup behaviour (which is triggered at ISO_Next_Group) does not have this field (adding it would break ABI), so you need to guess which modifiers to set if you didn't trigger this action. This is the main stumbling point that I found and if you look at Ilya's patch that's where he needs the big hack that I'm not comfortable at all with it.
Now, I don't know if there are layouts where the modifier mask would be
different on the second level as opposed to the first (and Ilya's hack
or a similar attempt would fail completely) but there's so many layouts
that it'll take a while to get through them all.
> And leaving the design bug because of purist reason looks really
strange...
there's two-ish ppl working on input at them moment, both are badly
overloaded because there's a lot of bugs and plenty new features that
ppl cry out for. so this bug has less to do with purist reasons, it's
more along the lines of "i've got so many things to do that don't break
the spec, they get priority".
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/159
------------------------------------------------------------------------
On 2014-09-07T00:01:09+00:00 Oded Arbel wrote:
(In reply to comment #129)
> As far as I can tell, it is already clear that XKB specifications needs to
> be extended for this to be cleanly solved. While Ilya's hack works for many
> people, and as much as I would like to see this fixed, I understand why it
> is unacceptable to the developers.
...
> there's two-ish ppl working on input at them moment, both are badly
> overloaded because there's a lot of bugs and plenty new features that ppl
> cry out for. so this bug has less to do with purist reasons, it's more along
> the lines of "i've got so many things to do that don't break the spec, they
> get priority".
So I understand that this issue is currently not worked on by Xorg
developers.
Priorities are a good thing, and I'm currently comfortable with the
pragmatic approach of the downstream distributions applying Ilya's patch
in their packages (which works fine for a lot of happy users who have
reported as such - I have yet to hear a report where Ilya's patch is not
improving behavior for multi-language users).
Still:
1) Its a good idea to have the pragmatic patch set maintained in this
bug report - even if it will never be applied to upstream Xorg, simply
as a central point for downstream distributors to get access to a
reasonable workaround until a "correct" solution is available.
2) It will be a real shame if this issue, that is actively discussed by
the community for 10 years now and is hurting a lot of users, will be
ignored for another 10 years. In the mean time XKB2 - that was supposed
to be the solution to all our problems - was relegated from "being
worked on" to "being thought on" to "being dreamed of" (around 2010) and
now appears to have fallen to the status of "it will never be important
enough".
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/160
------------------------------------------------------------------------
On 2014-09-07T15:53:33+00:00 Purkrtadam wrote:
xkb should be extended to be able to recognize a sequence of key presses
and key releases and fire action upon it. Again, this would be an
extension, not a violation of current standard.
Currently, the group switching is defined in
/usr/share/X11/xkb/symbols/group with parts like
partial modifier_keys
xkb_symbols "lalt_lshift_toggle" {
virtual_modifiers Alt;
key <LALT> {
symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
key <LFSH> {
type[Group1]="PC_ALT_LEVEL2",
symbols[Group1] = [ Shift_L, ISO_Next_Group ]
};
};
The following is what this part of the file would look like after
appropiate changes in xkb code:
xkb_sequences "lalt_lshift_toggle" {
sequence { keydown <LALT>, keydown <LFSH>, keyup <LFSH> } = ISO_Next_Group;
sequence { keydown <LFSH>, keydown <LALT>, keyup <LALT> } = ISO_Next_Group;
}
For this to work
1) http://www.x.org/docs/XKB/XKBproto.pdf need to be extended with a small chapter
2) http://cgit.freedesktop.org/xorg/xserver/tree/xkb - code the run time check for sequences; changes to xkm format required
3) http://cgit.freedesktop.org/xorg/app/xkbcomp/tree/ - code the parsing of "xkb_sequences", "keydown", and "keyup" keywords
At least this is my impression after a day of investigation. I know this seems like unnecessarily big change compared to Ilya's patch. But, basically, that is what I mean by "clean solution". Unfortunatelly, it is more of a "dream solution", since I feel I will hardly be able to code this..
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/161
------------------------------------------------------------------------
On 2014-09-07T17:38:19+00:00 Wettstae wrote:
Allowing arbitrary sequences to decide which action to take would
certainly be powerful, but quite some effort, also for specification
(think about multiple matching sequences).
In comment #117 I suggested an extension to the specification that is
restricted to the enhancement request at hand. But even this change
would need a protocol bump. This is where this proposal is stuck.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/162
------------------------------------------------------------------------
On 2014-09-10T19:44:22+00:00 Purkrtadam wrote:
Found partial workaround today.
It _is_ possible to setup xkb so that the group (i.e. layout) switch
occurs on <Shift>+<Alt> (which means press and hold Shift, then press
Alt - order matters) - and still <Alt>+<Shift>+<something> (first alt,
then shift, then something) shortcuts work. All this without the need to
recompile xserver.
Here's what I did:
$ setxkbmap us,cz
(just load the layouts I want to the server, switching not working yet)
$ xkbcomp $DISPLAY xkbdesc
(list the xkb description from server to a file named "xkbdesc")
Now two little changes to xkbdesc:
change1:
key <LALT> { [ Alt_L, Meta_L ] };
to
key <LALT> { [ Alt_L, ISO_Next_Group ] };
change2:
key <RALT> {
type[group1]= "TWO_LEVEL",
type[group2]= "ONE_LEVEL",
symbols[Group1]= [ Alt_R, Meta_R ],
symbols[Group2]= [ ISO_Level3_Shift ]
};
to
key <RALT> {
type[group1]= "TWO_LEVEL",
type[group2]= "TWO_LEVEL",
symbols[Group1]= [ Alt_R, ISO_Next_Group ],
symbols[Group2]= [ ISO_Level3_Shift, ISO_Next_Group ]
};
then
$ xkbcomp xkbdesc $DISPLAY
(load kbdesc to the server; ignore the warnings)
and voila! Shift+Alt (in that order) switches us<->cz keyboard and
Alt+Shift+Tab works like it should.
I was actually quite surprised when I found this.
PS: Next time you start X, you can do just the last step, supposed you
keep the xkbdesc file.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/164
------------------------------------------------------------------------
On 2014-10-04T16:00:15+00:00 Purkrtadam wrote:
Perhaps easier variant of the above workaround pertaining Alt+Shift is
to comment out the following (eight) lines in
/usr/share/X11/xkb/symbols/group
first change (search for "lalt_lshift"):
partial modifier_keys
xkb_symbols "lalt_lshift_toggle" {
virtual_modifiers Alt;
key <LALT> {
symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
// key <LFSH> {
// type[Group1]="PC_ALT_LEVEL2",
// symbols[Group1] = [ Shift_L, ISO_Next_Group ]
// };
};
second change (~15 lines below):
partial modifier_keys
xkb_symbols "ralt_rshift_toggle" {
virtual_modifiers Alt;
key <RALT> {
symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
// key <RTSH> {
// type[Group1]="PC_ALT_LEVEL2",
// symbols[Group1] = [ Shift_R, ISO_Next_Group ]
// };
};
then load the keymap, in my case
$ setxkbmap us,cz -option grp:alt_shift_toggle
or set it through gui (Change layout option=Alt+Shift in XFCE), or just
restart X server if you've already done so
Now <shift>+<left alt> (*in that order*, i.e. first press and hold any shift, then press left alt) switches keyboard layout
<alt>+<shift> (first alt, then shift) works as a modifier (i.e.
shortcuts work), and does nothing in itself
<alt>+<shift>+<tab> works as it should
It would be nice to actually have a separate "rule" for this - titled "Shift+LAlt", available with -grp:shift_lalt_toggle, but unfortunatelly I don't know how to modify the rules files..
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/166
------------------------------------------------------------------------
On 2015-07-25T15:57:47+00:00 Oded Arbel wrote:
Currently, Alon Bar-Lev's patch (xorg-server-1.12.2-xkb-switch-on-
release.patch) applies cleanly against Xorg 1.17.2 from Fedora 22, but
apparently has no effect - with `setxkbmap -print` output like this:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+ledscroll(group_lock)" };
xkb_symbols { include "pc+us+il(lyx):2+us:3+inet(evdev)+group(alt_shift_toggle)" };
xkb_geometry { include "pc(pc105)" };
};
Holding ALT+SHIFT (without releasing) immediately changes the layout.
I've build a copr package for this that can be found in copr under
guss77/xorg-patches, if you want to test drive.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/173
------------------------------------------------------------------------
On 2015-07-25T16:05:26+00:00 Oded Arbel wrote:
(In reply to Oded Arbel from comment #135)
> Currently, Alon Bar-Lev's patch
> (xorg-server-1.12.2-xkb-switch-on-release.patch) applies cleanly against
> Xorg 1.17.2 from Fedora 22, but apparently has no effect
ּsorry, my bad - I was mistaken. Apparently the problem has something to
do with GNOME's new layout switching handling. If I set "Modifiers-only
switch to next source" to "Disabled" in the keyboard shortcut editor,
then run
setxkbmap -option grp:switch,grp:alt_shift_toggle
Everything works fine with the patch.
So, we actually have two problems now, with layout switching kicking on
on release - both the broken XKB protocol and the broken GNOME handling
of "modifier-only" layout switching.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/174
------------------------------------------------------------------------
On 2016-04-05T13:49:08+00:00 StingX wrote:
Created attachment 122717
xorg-server-1.18.3-xkb-switch-on-release.patch
Here is the patch from ubuntu, that can be merged into the current
debian sid version of xorg-server (1.18.3-1).
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/180
------------------------------------------------------------------------
On 2016-09-24T00:18:29+00:00 Alon Bar-Lev wrote:
Created attachment 126752
xorg-server-1.18.4-xkb-switch-on-release.patch
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/182
------------------------------------------------------------------------
On 2016-09-24T01:04:00+00:00 Alon Bar-Lev wrote:
Created attachment 126753
xorg-server-1.18.4-xkb-switch-on-release.patch
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/183
------------------------------------------------------------------------
On 2017-02-23T09:06:44+00:00 Bas-bmail wrote:
Created attachment 129860
The same patch, but based on 1.19.1
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/185
------------------------------------------------------------------------
On 2017-02-23T09:17:26+00:00 Jan Pohanka wrote:
(In reply to kyak from comment #140)
> Created attachment 129860 [details] [review]
> The same patch, but based on 1.19.1
You are missing dereference in XkbSA_LockMods case...
> case XkbSA_LockMods:
>+ filter = _XkbNextFreeFilter(xkbi);
>+ sendEvent=_XkbFilterLockMods(xkbi, filter, key, act);
>+ break;
> case XkbSA_LockGroup:
> filter = _XkbNextFreeFilter(xkbi);
>- *sendEvent = _XkbFilterLockState(xkbi, filter, key, act);
>+ *sendEvent = _XkbFilterLockGroup(xkbi, filter, key, act);
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/186
------------------------------------------------------------------------
On 2017-02-23T09:51:17+00:00 Bas-bmail wrote:
Not really.. This is something that has changed from 1.18 to 1.19.
"act" is now already passed as reference to XkbActionGetFilter.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/187
------------------------------------------------------------------------
On 2017-02-23T09:54:37+00:00 Jan Pohanka wrote:
(In reply to kyak from comment #142)
I mean dereferencing sendEvent pointer.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/188
------------------------------------------------------------------------
On 2017-02-23T10:02:44+00:00 Bas-bmail wrote:
Created attachment 129861
The same patch, but based on 1.19.1 (fixed)
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/189
------------------------------------------------------------------------
On 2017-02-23T10:03:24+00:00 Bas-bmail wrote:
You are right, thanks for pointing that out. Updated patch attached.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/190
------------------------------------------------------------------------
On 2017-03-02T13:43:04+00:00 Beaux-monde-s wrote:
Try, please, apply your patch, assign the left Ctrl as switching key and
then to save something in the kate editor (or other) using Ctrl+S...
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/191
------------------------------------------------------------------------
On 2017-04-15T16:45:22+00:00 tlk wrote:
(In reply to Serge Roussak from comment #146)
> Try, please, apply your patch, assign the left Ctrl as switching key and
> then to save something in the kate editor (or other) using Ctrl+S...
You mean to say the new patch doesn't work for you? Please be more
clear.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/192
------------------------------------------------------------------------
On 2017-04-15T20:51:08+00:00 Beaux-monde-s wrote:
Yes, exactly. If I assign the left Ctrl as the switching key, then if I
try to save a file in a text editor with the Ctrl+S, I got the "s" char
in the file.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/193
------------------------------------------------------------------------
On 2017-04-16T08:07:42+00:00 tlk wrote:
(In reply to Serge Roussak from comment #148)
> Yes, exactly. If I assign the left Ctrl as the switching key, then if I try
> to save a file in a text editor with the Ctrl+S, I got the "s" char in the
> file.
And the layout switching - does it occur when you press Ctrl+s? Could
you please test with Ctrl+Shift?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/194
------------------------------------------------------------------------
On 2017-04-19T07:45:41+00:00 Beaux-monde-s wrote:
(In reply to Oleg from comment #149)
>
> And the layout switching - does it occur when you press Ctrl+s? Could you
> please test with Ctrl+Shift?
No, it does not. Currently I could not to test multi-keys switching
combinations.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/195
------------------------------------------------------------------------
On 2017-04-19T14:45:59+00:00 tlk wrote:
Did the old patch work for you? I mean could you switch the layout
pressing Ctrl while combos like Ctrl-S also worked as expected?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/196
------------------------------------------------------------------------
On 2017-04-19T15:00:35+00:00 Beaux-monde-s wrote:
(In reply to Oleg from comment #151)
> Did the old patch work for you? I mean could you switch the layout pressing
> Ctrl while combos like Ctrl-S also worked as expected?
Which patch do you mean when you say "old"?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/197
------------------------------------------------------------------------
On 2017-04-19T16:15:35+00:00 tlk wrote:
(In reply to Serge Roussak from comment #152)
> (In reply to Oleg from comment #151)
> > Did the old patch work for you? I mean could you switch the layout pressing
> > Ctrl while combos like Ctrl-S also worked as expected?
>
> Which patch do you mean when you say "old"?
The one that was made for Xorg versions prior to 1.19
https://bugs.freedesktop.org/attachment.cgi?id=126753
The whole problem is that 1.19 needs a new one - this is the one
provided by kyak https://bugs.freedesktop.org/attachment.cgi?id=129861
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/198
------------------------------------------------------------------------
On 2017-04-19T19:03:45+00:00 Beaux-monde-s wrote:
(In reply to Oleg from comment #153)
> (In reply to Serge Roussak from comment #152)
> > (In reply to Oleg from comment #151)
> > > Did the old patch work for you? I mean could you switch the layout pressing
> > > Ctrl while combos like Ctrl-S also worked as expected?
> >
> > Which patch do you mean when you say "old"?
>
> The one that was made for Xorg versions prior to 1.19
> https://bugs.freedesktop.org/attachment.cgi?id=126753
>
> The whole problem is that 1.19 needs a new one - this is the one provided by
> kyak https://bugs.freedesktop.org/attachment.cgi?id=129861
I have used the last one with the xorg-server v.1.19.3.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/199
------------------------------------------------------------------------
On 2017-04-27T14:32:57+00:00 kolya wrote:
Dear xorg developers. This is an old bug. In fact this is a 13 years old bug. And it has been at least 7 years since this bug had a patch to fix it.
Yes, existing patch breaks specification. But one would seem that the fact that patch existed for 7 years and was applied by default by popular distributions without users` complains would suggest that existing patch is a practical solution to the problem despite breaking theoretical (and as discussed here - not well thought through) specification.
There is now once more spike of activity here - probably because Ubuntu 17.04 was released recently which dropped this patch because it was not compatible with newer xorg. kyak has provided an updated patch, but it would take a lot of time for distributions to pick it up and then circle would repeat with next xorg version.
Yes, there has been a few heated discussions around this patch and XKB
specification. And yes, specifications are important, but this is really
annoying problem for people with more than one keyboard layout. Annoying
to the point of making xorg really unusable for some groups of people.
So is there any chance to get more practical with this bug?
For example, kyak's patch has a function 'xkbSwitchGroupOnRelease' that
is a stub to make new behaviour controllable by configuration. Would
xorg maintainers find this patch acceptable to upstream if that function
read value from some environment variable and only turned new behaviour
on if it was set?
I feel like it would allow XKB spec to stay and also would allow users
affected by this problem to solve it without recompiling xorg - which
average user would struggle to do.
Looking forward to your reply.
Thanks!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/200
------------------------------------------------------------------------
On 2017-04-27T18:24:59+00:00 Ran Benita wrote:
Nikolay,
First, background: I am not a xorg developer, but I develop the XKB
library used by most Wayland compositors (xkbcommon). The behavior there
is the same.
IMO it is worth having a discussion about the behavior. A nice thing
about XKB is that it has a specification. It is easier to discuss
behavioral changes against a spec than hard-to-understand X code, or 150
comments bugs. Therefore, my proposal for you (or anyone else who is
interested in changing the behavior) is to provide a patch against the
spec. Even if the actual spec will never change, I still think that a
clear proposal, which also considers possible side effects, is the first
step forward here.
The current spec and the most relevant section is here:
https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
The current source for the above spec is in the kbproto repository here:
https://cgit.freedesktop.org/xorg/proto/kbproto/tree/specs/ch06.xml?id=kbproto-1.0.7#n586
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/201
------------------------------------------------------------------------
On 2017-04-27T18:56:25+00:00 Oded Arbel wrote:
The issue of fixing the spec was raised before, and the answer thn was:
(Vasily Khoruzhick from comment #37)
> Daniel is now working on XKB2, so fixing/changing XKB1 has no sense :)
As far as I know, XKB2 was never released, not even as a draft.
Are you saying that the situation has changed and changes to XKB are now
welcome?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/202
------------------------------------------------------------------------
On 2017-04-27T19:23:53+00:00 Ran Benita wrote:
No, I am only talking about myself, as a developer of xkbcommon; as I
said, I am not a xorg developer so I cannot speak for that. I do not
really mind if the spec is actually changed or not, what I am interested
in is:
1. A clear and precise description of the proposed change.
2. A serious consideration of how other parts of the spec may be affected by the change.
You know how you want it to behave, so just write it down in the form a
patch against the spec. Then we can discuss further, with the goal of
reaching a solution in xkbcommon, at least. Let me know if you (or
anyone else who wants to do it) need any help.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/203
------------------------------------------------------------------------
On 2017-04-29T10:25:10+00:00 Wettstae wrote:
Created attachment 131147
Proposed extension of the XKB protocol.
> Therefore, my proposal for you (or anyone else who is interested in changing the behavior) is to provide a patch against the spec.
That is a very good proposal. The patch formalises my proposal from comment #112. An implementation was posted it the following thread:
https://lists.x.org/archives/xorg-devel/2012-November/034427.html
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/204
------------------------------------------------------------------------
On 2017-04-29T11:47:41+00:00 Ran Benita wrote:
Thanks Andreas, I had missed this in the previous discussion.
First, I must say it's a very clever hack :)
I have not looked at it deeply yet, but I have some initial questions:
- Can you describe a bit how you imagine the changes to xkeyboard-config
would look with this approach?
- Do you think this can be done in a backwards compatible way? As far as
xkbcommon is concerned, I am only interested in this scenario: old
library (unaware of the new LockMods options) & new keymap (in textual
form, modified with the new flags).
X has more compatibility concerns,
xkbcomp/client/server/libxkbfile/protocol/Xlib/etc, but allow me to
ignore that for now.
BTW: xkbcommon already supports noLock/noUnlock in LockMods (unlike
xkbcomp), based on your work[1]. So I hope the approach does not rely on
these not already working :)
[1]
https://github.com/xkbcommon/libxkbcommon/commit/7c5e79159b5f5cd533a078c7672705e2ffa0a798
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/205
------------------------------------------------------------------------
On 2017-04-29T18:25:12+00:00 Wettstae wrote:
> - Can you describe a bit how you imagine the changes to xkeyboard-config
> would look with this approach?
We would need changes wherever we want the new behaviour. I would prefer to create new options for group switching, rather than modifying existing options. Comments #117 and #118 show examples. Basically, I imagine we use explicit action specifications. However, unless as shown in the examples, with changes to xkbcomp, one could write 'LockMods' with an 'group' option, rather than using the cryptic 'Private' actions.
> - Do you think this can be done in a backwards compatible way? As far as
> xkbcommon is concerned, I am only interested in this scenario: old library
> (unaware of the new LockMods options) & new keymap (in textual form,
> modified with the new flags).
Certainly, an old library or application would get parse errors when it encountered the new options in textual form.
If xkeyboard-config adds new options rather than modifying old ones,
users could just keep using the old options until they upgraded the
library/application. If the library/application parses only used stuff,
that would circument transitional compatibility issues. For an old
xkbcomp with a new xkeyboard-config, I believe that would work.
As I far as remember, xkbcommon intentionally does not support
'Private'; otherwise, using it could help during the transition.
> X has more compatibility concerns,
Yes. Peter's main concern was that some tools might create binary forms of a layout where the two bytes that now get a meaning are not zero, but set to some random values (zero is fine, as it will have no effect in the new interpretation). His idea was to bump the protocol version, but that is beyond my capabilities, so I gave up at this point. Anyway, current xkbcomp puts the bytes to zero, so the combination of an old xkbcomp with new X-server would be no problem, ever without the precaution of a protocol version bump.
> BTW: xkbcommon already supports noLock/noUnlock in LockMods (unlike xkbcomp),
> based on your work[1]. So I hope the approach does not rely on these not
> already working :)
With my proposal, xkbcomp should be touched anyway, and this is just one of three occasions where I unsuccessfully tried to get noLock/noUnlock supported in xkbcomp.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/206
------------------------------------------------------------------------
On 2017-08-14T20:04:50+00:00 Freedesktop-x wrote:
(In reply to Nikolay from comment #155)
> There is now once more spike of activity here - probably because Ubuntu
> 17.04 was released recently which dropped this patch because it was not
> compatible with newer xorg. kyak has provided an updated patch, but it would
> take a lot of time for distributions to pick it up and then circle would
> repeat with next xorg version.
On Ubuntu 16.04.03 LTS I just went from using Unity to Gnome. With some
back and forth with lightdm vs. gdm and the screen lock issues I got
things working more or less until I stumbled over what probably are the
ripples of this old bug (and I couldn't agree more with Nikolay and his
comment).
I had two keyboard layouts running with Unity, and as everybody seems to
have, I used Alt-Shift to switch layouts, just like on my Windows
laptop. And like almost everyone else, I of course have Alt-Shift-Tab
set for cycling backwards through windows (after jumping through all
sorts of hoops to tell the window manager not to group windows of the
same app...).
I reported my issue at https://bugzilla.gnome.org/show_bug.cgi?id=786257
which obviously was the wrong place. And now I found this bug here.
I haven't taken the time to understand all the details, so I apologize
for the outside perspective. Yet, I am of the opinion that it should be
possible to define shortcuts such that they trigger their event only
upon release, not upon press, because as noted by everyone else here it
makes it impossible to define "release" shortcuts that are "prefixes" of
other shortcuts, and this is a severe limitation that becomes highly
practically relevant for the usual keyboard layout switching shortcut
that just so happens to be a prefix of the usual window backwards
switching shortcut.
There have been much worse backward incompatibilities in Linux. And
while I hate seeing things break by such changes, here my very personal
view is that should this really present a problem that cannot be solved
in a backward-compatible way (e.g., by letting users distinguish between
"release" and "press" shortcut definitions) then so be it. What is this
compared to deprecating X11, then xorg and at some point also
Wayland...?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/209
------------------------------------------------------------------------
On 2017-10-13T21:39:36+00:00 Kof-box wrote:
After the next update of the package "xserver-xorg-input-evdev-
hwe-16.04" (with dependencies) from the version "1: 2.10.2-1ubuntu1 ~
16.04.1" to the version "1: 2.10.5-1ubuntu1 ~ 16.04.1 ", in the KDE
shell, the language switch does not happen when the keys are released,
but when pressed.
Distributions on which this problem was repeated:
neon-useredition-20171012-1018-amd64
kubuntu-16.04.3-desktop-amd64
kubuntu-17.04-desktop-amd64
Distributions in which there is no such problem:
ubuntu-16.04.3-desktop-amd64
ubuntu-17.04-desktop-amd64 (but there is no such package)
When setting the switch to Ctrl-Shift, you can not quickly select text
with the "Ctrl-Shift-Arrows" keys. However, you do not want to have
outdated xorg packages. Extremely uncomfortable, help!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/214
------------------------------------------------------------------------
On 2017-10-13T21:54:20+00:00 Yanpas wrote:
Me too very upset about this bug: there is patch for several yers - no
one cares. I suggest compromise: add autotools|meson option to enable
this feature. At least every distro would be able to decide whether they
want to provide nonstandard behavior.
I also see that this bug is assigned but nothing happens.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/215
------------------------------------------------------------------------
On 2017-10-14T01:54:35+00:00 Kovács Viktor wrote:
Why don't you change your layout switcher key-combination? You can set
up another key-combinations for russian and different key-combination
for english keyboard,too. That's KDE's problem, that allow choose
frequently used key combinations.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/216
------------------------------------------------------------------------
On 2017-10-14T02:21:59+00:00 Ztirfe Elgnid wrote:
With all due respect, I hope this is not the usual response to X bugs. I
do not think it is unreasonable to ask that shortcuts be made available
from the set of control keys, since this is a very widespread feature
across operating systems. I have used Kubuntu for the past several
years, and made use of the alt-shift key combination to toggle between
the English and Greek keyboard layouts. After the recent KDE change I
find this bug affecting my workflow, interrupting various keyboard
combinations involving the use of those modifiers. I think it is
appropriate to call this a bug in xkb's behaviour.
I wholeheartedly understand that X developers are more thinly stretched
than most, and that this bug—despite its labeled importance—does not
have as extreme a disruptive impact as many other bugs. I have no desire
to complain of the amount of time this bug has spent open and demand
that it be fixed. I would however request that this bug not be closed,
as it is indeed a bug and the responsibility of xkb.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/217
------------------------------------------------------------------------
On 2017-10-14T03:29:21+00:00 Kovács Viktor wrote:
The main keyword the KDE interface programming philosophy called Quick Time. Windows use message queue, and uses built togheter windows manager with the os hardly. Qt enables for programs override every reactions, "answered" the user actions. Under xcfe desktop manager main program override subprograms actions, for example, midnight commander is not closeable pressed f10 key, it override the main window. KDE close midnight commander pressing f10 key.
Xkb layouts can not to do anything with this problem.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/218
------------------------------------------------------------------------
On 2017-10-14T03:44:06+00:00 Ztirfe Elgnid wrote:
This bug is not exclusive to KDE. I use XFCE on a different machine as
well, and encounter the bug there. Various people in this thread have
reported it in other WMs. Is there a reason why the solution should not
be, as the title says, that XKB kick its hotkeys on release rather than
press?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/219
------------------------------------------------------------------------
On 2017-10-14T05:58:24+00:00 Kovács Viktor wrote:
Who invite me this blog?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/220
------------------------------------------------------------------------
On 2017-10-14T06:26:48+00:00 Alon Bar-Lev wrote:
(In reply to Kovács Viktor from comment #165)
> Why don't you change your layout switcher key-combination? You can set up
> another key-combinations for russian and different key-combination for
> english keyboard,too. That's KDE's problem, that allow choose frequently
> used key combinations.
This has nothing to do with KDE, but lack of functionality of xkb.
There is universal key sequence to switch layout which is common to most
operating systems, once this sequence is selected, functionality is
lost.
Comment#161 summaries the options to actually solve the issue, until
resolved people should be able to land here to apply the patch which I
use for 10 years.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/221
------------------------------------------------------------------------
On 2017-10-14T18:02:20+00:00 Kovács Viktor wrote:
Created attachment 134843
KDE keyboard layout switcher screenshot
Sorry, I'm Hungarian.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/222
------------------------------------------------------------------------
On 2017-10-14T18:07:25+00:00 Kovács Viktor wrote:
Original problem was, that Shishakov uses ctrl+shift keyboard layout keycombination, and it not works, because it can be used in hotkeys.
Why do not change It? It is much easier thing, I think.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/223
------------------------------------------------------------------------
On 2017-10-14T18:23:22+00:00 Maciej Pilichowski wrote:
@Kovács Viktor, this report is not only about "original" problem, but
all the problems affected by current implementation. I described other
one with modifier for national characters, once you define such key you
cannot use it as shortcut modifier.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/224
------------------------------------------------------------------------
On 2017-10-14T18:29:30+00:00 Yanpas wrote:
High, Viktor!
I'm using Ctrl+Shift for twelve years since Win XP. I use this
combintaion on my win machines. So it's definetely not an option for me.
Since I use Cyrillic layout I switch layouts frequently (people using
Latin layouts are less affected). Imagine saving action shortcut
"Ctrl+S" combintaion would be replaced with something like "Alt+R" in
your favourite text editor.
I'm also sure that no one will complain if the patch will be merged. And
I do not understand why should we follow the standard if this standard
makes living uncomfortable.
BTW according to previous comments wayland implentations suffer from
this bug too despite they do not depend on Xorg-server. Do we need
separate patch for libxcb and libxcbcommon?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/225
------------------------------------------------------------------------
On 2017-10-14T19:17:52+00:00 Kovács Viktor wrote:
I understand, that you must switch between Russian and English layout.
The programs uses latin-based hotkeys, I did understand. In my opinion,
in the future would be change, if the translator projects "translate"
the hotkeys, for example to cyrillyc letters, too. (then won't need
switches between layouts so frequently) We (Hungarians) will run into
that problems on the future, when we will want to write old Hungarian
texts. This is a runic-like right-to-left script. My question is, do you
use Windows yet, or you uses already only Linux? You can choose switcher
combination closely positioned with ctrl and shift. If you buy a new
laptop, it could be happen, that the keyboard metrics not exactly same
as on previous one.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/226
------------------------------------------------------------------------
On 2017-10-14T19:33:08+00:00 Yanpas wrote:
I use both Windows and Linux. BTW Many people don't have a choise of the
OS on their jobs.
I may provide a patch that would make it available to switch the
behaviour in the runtime (I guess a line in xorg.conf would be fine). So
we don't break the standard, people don't need to recompile xorg every
time and patch developers don't need to adapt the patch.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/227
------------------------------------------------------------------------
On 2017-10-15T04:32:54+00:00 Bas-bmail wrote:
(In reply to Yan Pas from comment #176)
> I use both Windows and Linux. BTW Many people don't have a choise of the OS
> on their jobs.
>
> I may provide a patch that would make it available to switch the behaviour
> in the runtime (I guess a line in xorg.conf would be fine). So we don't
> break the standard, people don't need to recompile xorg every time and patch
> developers don't need to adapt the patch.
You should get developers' feedback about this approach first. If they
are not willing to merge the patch that works via xorg.conf, you will
only waste your time.
>From the other hand side, you will probably waste your time anyway.
Developers talk about the "standard", and explicitely suggest sending patches to standard instead of patching xorg (read previous comments). And when such patch for the standard gets attached to this bug report, what happens? Nothing.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/228
------------------------------------------------------------------------
On 2017-10-15T13:22:14+00:00 Kovács Viktor wrote:
(In reply to Vitaly Shishakov from comment #0)
> I used to use Ctrl-Shift combination to switch keyboard layouts (ru <--> us)
>
> but in this case i cant use any of the Ctrl-Shift-* hotkeys in any software
> i try.
>
> I noticed, that the keyboard layout becomes swithced as soon an both keys
> are DOWN --
> pressing any other key is not treated as Ctrl-Shift-<key> combination.
>
> For example -- in Windows i also use Ctrl-Shift to switch layouts, but
> there, the layout
> becomes switched only when both SHIFT and CTRL keys are UP, and no other key
> was
> pressed while they were down -- in that case the hole combination is treates
> as
> Ctrl-Shift-<key> combination, and the layout is not changed.
>
> see also: http://bugs.kde.org/show_bug.cgi?id=59303
>
>
>
> I use the following lines in XF86Config:
>
> Section "InputDevice"
> Driver "Keyboard"
> Identifier "Keyboard[0]"
> Option "Protocol" "Standard"
> Option "XkbLayout" "us,ru"
> Option "XkbModel" "pc104"
> Option "XkbOptions" "grp:ctrl_shift_toggle"
> Option "XkbRules" "xfree86"
> Option "XkbVariant" ",winkeys"
> EndSection
Kubuntu grants Control+Shift+K combination. Is it acceptable?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/229
------------------------------------------------------------------------
On 2017-10-15T14:46:32+00:00 Ztirfe Elgnid wrote:
(In reply to Kovács Viktor from comment #178)
> Kubuntu grants Control+Shift+K combination. Is it acceptable?
The question is not, largely speaking, about whether there is any
shortcut available. The question is largely specifically about shortcuts
such as Ctrl+Shift or Alt+Shift, which due to this bug will interfere
with other shortcuts and applications. Users such as myself are
accustomed to using these shortcuts, and they should be expected to
work.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/230
------------------------------------------------------------------------
On 2017-10-15T18:24:02+00:00 Kovács Viktor wrote:
(In reply to Zebediah Figura from comment #179)
> (In reply to Kovács Viktor from comment #178)
> > Kubuntu grants Control+Shift+K combination. Is it acceptable?
>
> The question is not, largely speaking, about whether there is any shortcut
> available. The question is largely specifically about shortcuts such as
> Ctrl+Shift or Alt+Shift, which due to this bug will interfere with other
> shortcuts and applications. Users such as myself are accustomed to using
> these shortcuts, and they should be expected to work.
Yes, I was thinking about it before you answered. I tested RCtrl+RShift
combination, and it has no conflicts with hotkeys. There are possibility
of XKeyboard-config, I used it before a keyboard layout:
caps_switch_latch. It works when capslock pushed, but not released. I
just thinking, I am in a black room. But it cannot do anything with
hotkeys. I think, that problem is a miner-like. X-windows have messages
keypress and release, but in my opinion, it should be adopt all windows
manager. I will read the according X11 header files first, I promiss.
After that I come back again, could we step to an easy way or not.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/231
------------------------------------------------------------------------
On 2017-11-28T19:47:12+00:00 Kovács Viktor wrote:
Sorry, on newer Linux you can set up hot key combination for that
problem as graphical UI settings, older Linux versions will not be
updated. May I close It?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/239
------------------------------------------------------------------------
On 2017-11-28T20:05:41+00:00 Jan Pohanka wrote:
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?
With all respect to you... Why do you want to close well described bug
moreover that it has good proposed solution? This issue affects multiple
users using multiple keyboard layouts and merging available patch
probably won't cause any problems to the rest of people that does not
use layout switchig.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/240
------------------------------------------------------------------------
On 2017-11-28T20:43:15+00:00 Kof-box wrote:
(In reply to Jan Pohanka from comment #182)
> (In reply to Kovács Viktor from comment #181)
> > Sorry, on newer Linux you can set up hot key combination for that problem as
> > graphical UI settings, older Linux versions will not be updated. May I close
> > It?
>
> With all respect to you... Why do you want to close well described bug
> moreover that it has good proposed solution? This issue affects multiple
> users using multiple keyboard layouts and merging available patch probably
> won't cause any problems to the rest of people that does not use layout
> switchig.
Sorry, but where do you see "good proposed solution"? Please, please
show me that solution.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/241
------------------------------------------------------------------------
On 2017-11-28T21:04:28+00:00 Powerman-asdf wrote:
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated.
What exactly "newer Linux" is supposed to mean? I'm using yesterday's
updated Gentoo Linux with xorg-server-1.19.5 and Fluxbox - is it counts
as "newer"? Or by "newer Linux" you mean something like "modern KDE
only"?
(In reply to k0fe from comment #183)
> Sorry, but where do you see "good proposed solution"? Please, please show me
> that solution.
There is a patch, working good enough for years without creating any new
(practical) issues. In comment #161 is was proposed to make it
configurable option to make everyone happy and let users choose between
using compliant protocol or working hotkeys.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/242
------------------------------------------------------------------------
On 2017-11-28T22:23:27+00:00 Kof-box wrote:
(In reply to Alex Efros from comment #184)
> (In reply to Kovács Viktor from comment #181)
> > Sorry, on newer Linux you can set up hot key combination for that problem as
> > graphical UI settings, older Linux versions will not be updated.
>
> What exactly "newer Linux" is supposed to mean? I'm using yesterday's
> updated Gentoo Linux with xorg-server-1.19.5 and Fluxbox - is it counts as
> "newer"? Or by "newer Linux" you mean something like "modern KDE only"?
>
> (In reply to k0fe from comment #183)
> > Sorry, but where do you see "good proposed solution"? Please, please show me
> > that solution.
>
> There is a patch, working good enough for years without creating any new
> (practical) issues. In comment #161 is was proposed to make it configurable
> option to make everyone happy and let users choose between using compliant
> protocol or working hotkeys.
Where is the link to the patch? Where is the instruction like how to
apply this patch? And how can this comment be used by an ordinary user
(without knowledge of programming) to solve this problem?
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/243
------------------------------------------------------------------------
On 2017-11-28T22:57:38+00:00 Powerman-asdf wrote:
(In reply to k0fe from comment #185)
> (In reply to Alex Efros from comment #184)
> > There is a patch, working good enough for years without creating any new
> > (practical) issues. In comment #161 is was proposed to make it configurable
> > option to make everyone happy and let users choose between using compliant
> > protocol or working hotkeys.
>
> Where is the link to the patch? Where is the instruction like how to apply
> this patch? And how can this comment be used by an ordinary user (without
> knowledge of programming) to solve this problem?
As an ordinary Gentoo Linux user, I:
- download patch attached to this issue named "The same patch, but based on 1.19.1 (fixed)" into directory /etc/portage/patches/x11-base/xorg-server/
- run `emerge xorg-server` to reinstall Xorg with this patch applied
- restart X to enjoy working hotkeys :)
If users of other Linux distributions have issues with this - probably
they just didn't use "newer Linux". </sarcasm>
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/244
------------------------------------------------------------------------
On 2017-11-29T14:54:14+00:00 Daniel Stone wrote:
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?
Please do not close this bug. If you do not want to receive any further
updates on it, you can unsubscribe by removing yourself from the Cc
list.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/245
------------------------------------------------------------------------
On 2017-12-07T00:30:55+00:00 Mim-t wrote:
(In reply to Alex Efros from comment #186)
> (In reply to k0fe from comment #185)
> > (In reply to Alex Efros from comment #184)
> > > There is a patch, working good enough for years without creating any new
> > > (practical) issues. In comment #161 is was proposed to make it configurable
> > > option to make everyone happy and let users choose between using compliant
> > > protocol or working hotkeys.
> >
> > Where is the link to the patch? Where is the instruction like how to apply
> > this patch? And how can this comment be used by an ordinary user (without
> > knowledge of programming) to solve this problem?
>
> As an ordinary Gentoo Linux user, I:
> - download patch attached to this issue named "The same patch, but based on
> 1.19.1 (fixed)" into directory /etc/portage/patches/x11-base/xorg-server/
> - run `emerge xorg-server` to reinstall Xorg with this patch applied
> - restart X to enjoy working hotkeys :)
>
> If users of other Linux distributions have issues with this - probably they
> just didn't use "newer Linux". </sarcasm>
I'd like to thank you! And great thanks to kyak for the patch!
I confirm that it works for me on "older" Gentoo and xorg-server 1.9.5.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/249
------------------------------------------------------------------------
On 2017-12-07T02:37:53+00:00 Ztirfe Elgnid wrote:
There seems to have been a proposed protocol extension (comment #159
etc.) Can anyone shed light, for the outside user, as to the current
status of this proposal? Thanks.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/250
------------------------------------------------------------------------
On 2017-12-10T10:07:26+00:00 Wettstae wrote:
(In reply to Zebediah Figura from comment #189)
> Can anyone shed light, for the outside user, as to the current status of
> this proposal? Thanks.
No news since. Apart from the formal proposal, there are some old patches for its implementation:
https://lists.x.org/archives/xorg-devel/2012-November/034427.html
https://lists.x.org/archives/xorg-devel/2012-November/034430.html
https://lists.x.org/archives/xorg-devel/2012-November/034429.html
https://lists.x.org/archives/xorg-devel/2012-November/034431.html
https://lists.x.org/archives/xorg-devel/2012-November/034428.html
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/251
------------------------------------------------------------------------
On 2017-12-11T09:59:25+00:00 Daniel Stone wrote:
(In reply to Andreas Wettstein from comment #190)
> No news since. Apart from the formal proposal, there are some old patches
> for its implementation:
> https://lists.x.org/archives/xorg-devel/2012-November/034427.html
> https://lists.x.org/archives/xorg-devel/2012-November/034430.html
> https://lists.x.org/archives/xorg-devel/2012-November/034429.html
> https://lists.x.org/archives/xorg-devel/2012-November/034431.html
> https://lists.x.org/archives/xorg-devel/2012-November/034428.html
Here's what I think we would need to do in order to not break old clients:
https://lists.freedesktop.org/archives/xorg-devel/2013-January/035049.html
Another, probably better, way to do it would be to define a new flag
like XkbSA_HasGroupFlags inside the XkbModAction flags field when
group_flags and group_XXX are valid rather than potentially garbage.
That would avoid the whole version-negotiation nightmare, as nothing
appears to be too picky about extra flags being defined.
Five years later, it would also be good to have support inside
libxkbcommon (which has a pretty decent test suite) and xcb-proto for
the flags.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/252
------------------------------------------------------------------------
On 2017-12-15T19:51:24+00:00 Beaux-monde-s wrote:
(In reply to Alex Efros from comment #184)
> There is a patch, working good enough for years without creating any new
> (practical) issues. In comment #161 is was proposed to make it configurable
> option to make everyone happy and let users choose between using compliant
> protocol or working hotkeys.
(In reply to Aliaksei Urbanski from comment #188)
> I'd like to thank you! And great thanks to kyak for the patch!
> I confirm that it works for me on "older" Gentoo and xorg-server 1.9.5.
I could to say, that this patch does not work exactly as expected. See,
please, my comment #146 for explanation. So I think, this thread could
not be closed.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/253
------------------------------------------------------------------------
On 2018-02-16T12:17:53+00:00 David-cortes-rivera wrote:
Another user here voting for this bug to get patched OFFICIALLY from
upstream.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/257
------------------------------------------------------------------------
On 2018-02-24T16:17:00+00:00 Norbert wrote:
Did you changed your opinion after for years of not fixing this bug?
Users still need this functionality (see https://community.ubuntu.com/t
/keyboard-layout-switching-problems-and-poll/2876 and
https://askubuntu.com/q/1009352/66509 as examples).
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/259
------------------------------------------------------------------------
On 2018-02-24T16:19:05+00:00 Norbert wrote:
All current Ubuntu versions are affected and RHEL too. And nobody cares.
14 years of doing nothing. My congratulations!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/260
------------------------------------------------------------------------
On 2018-02-26T10:49:54+00:00 Daniel Stone wrote:
(In reply to Daniel Stone from comment #191)
> Another, probably better, way to do it would be to define a new flag like
> XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and
> group_XXX are valid rather than potentially garbage. That would avoid the
> whole version-negotiation nightmare, as nothing appears to be too picky
> about extra flags being defined.
>
> Five years later, it would also be good to have support inside libxkbcommon
> (which has a pretty decent test suite) and xcb-proto for the flags.
This comment lays out the best way forward for anyone interested to fix
this bug. It shouldn't be too difficult, but personally I haven't worked
on X11 for quite some time.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/261
------------------------------------------------------------------------
On 2018-03-02T14:40:56+00:00 Norbert wrote:
Just tested simple idea on Ubuntu 16.04.4 LTS with MATE DE.
Out-the-box it has Xorg 1.18.4 which perfectly allow user to set for example <Ctrl+Shift> keyboard shortcut for keyboard layout switching.
But when I install HWE on 16.04 LTS I get newer Xorg 1.19.5.
Debian 8 (Xorg 1.16.4) and 9 (Xorg 1.19.2) have this problem too (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891915 ).
So versions 1.16.4, 1.19.2 and 1.19.5 should be patched to bring
<Ctrl+Shift> keyboard shortcut functionality back.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/262
------------------------------------------------------------------------
On 2018-03-05T05:53:26+00:00 Kovács Viktor wrote:
Did somebody tested Russian rulemak keyboard layout? It is between the
extra layouts. It is based on russian layout with latin letters. I' m
not a russian man, but I think, just testing first is a good idea!
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/263
------------------------------------------------------------------------
On 2018-03-05T06:33:38+00:00 7-andrew-0 wrote:
Viktor, could you please elaborate how exactly that may be useful here?
I would also like to ask you to make sure you contribute useful content
to this discussion, or if you cannot, resist from posting. I don’t think
it helps anyone to to support flamewars in this bug report, or even make
the discussion longer than necessary.
Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-
daemon/+bug/1245473/comments/264
** Bug watch added: KDE Bug Tracking System #59303
https://bugs.kde.org/show_bug.cgi?id=59303
** Bug watch added: Red Hat Bugzilla #660254
https://bugzilla.redhat.com/show_bug.cgi?id=660254
** Bug watch added: Gentoo Bugzilla #379827
https://bugs.gentoo.org/show_bug.cgi?id=379827
** Bug watch added: Gentoo Bugzilla #304375
https://bugs.gentoo.org/show_bug.cgi?id=304375
** Bug watch added: GNOME Bug Tracker #786257
https://bugzilla.gnome.org/show_bug.cgi?id=786257
** Bug watch added: Debian Bug tracker #891915
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891915
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1245473
Title:
Binding ctrl+shift, alt+shift, etc for switching keyboard layout makes
shortcuts with ctrl+shift, etc not working in any program
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-settings-daemon/+bug/1245473/+subscriptions
More information about the kubuntu-bugs
mailing list