← Back to team overview

ubuntu-x-swat team mailing list archive

[Bug 36812]

 

(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.

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/36812

Title:
  Keyboard layout change on hotkeys press instead of release and do not
  work well with shortcuts

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions