Re: Debugging keyboard overlay+xbindkeys

2016-11-05 Thread Mihail Konev 
On Sun, Nov 06, 2016 at 12:37:44AM +0500, Mihail Konev wrote:
> The only reason not to use arrow-keysyms-on-levels is that
> MonoDevelop, Java apps, VTE do not recognize them as "arrows",
> i.e. you cannot shift-select, or shift-scroll.
> 
> A possible solution to avoid abovementioned indirection when
> defining "arrow layers" would be to have ShiftModsOnly flag,
> which would then be put onto arrow keysyms.
> This is only a workaround around broken clients, of course.
Maybe java does this correctly.

As for VTE, it is xfce4-terminal that has broken shift-scroll:
it resets the position each time when pressing Level3 shift modifier.
I.e. it assumes that Shift is the only shifting modifier possible.

ShiftModsOnly should have been named "ShiftIsTheOnlyModifier".
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-05 Thread Mihail Konev 
On Sat, Nov 05, 2016 at 03:43:49AM +0500, Mihail Konev wrote:
> On Sat, Nov 05, 2016 at 03:26:54AM +0500, Mihail Konev wrote:
> > E.g. you cannot have caps+y be 'yen' and 'YEN' easily.
> (Assuming that Unicode 'yen' does not capitalize to 'YEN').
> E.g. caps+y -> ':' ; caps+Y -> '@' .

Correct version:
E.g. you cannot have caps+y be 'a' and 'b' easily.

You have to define a "putaside" keycode to them at levels 1 and 2,
and then .overlay1= into it.

Similarly with the RedirectKey action.

The only reason not to use arrow-keysyms-on-levels is that
MonoDevelop, Java apps, VTE do not recognize them as "arrows",
i.e. you cannot shift-select, or shift-scroll.

A possible solution to avoid abovementioned indirection when
defining "arrow layers" would be to have ShiftModsOnly flag,
which would then be put onto arrow keysyms.
This is only a workaround around broken clients, of course.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-05 Thread wettstae 
> Question is, was it there for 22 years cause it's unfixable or because
> nobody uses overlay? :)

I guess Mihail is right, overlays are certainly little used.  I do use
overlays myself, but only as as lock, where the bug is not likely to
occur.

You might want to look at Redirect actions, another XKB feature that
allows to pretend to applications that another key than the physical one
has been pressed.  They are more flexible than overlays, and they work
fine.

Andreas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-04 Thread Mihail Konev 
On Sat, Nov 05, 2016 at 03:26:54AM +0500, Mihail Konev wrote:
> But maybe I'm wrong and there are applications of this functionality.
Didn't read the 'distro' paragraph ;)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-04 Thread Mihail Konev 
On Sat, Nov 05, 2016 at 03:26:54AM +0500, Mihail Konev wrote:
> E.g. you cannot have caps+y be 'yen' and 'YEN' easily.
(Assuming that Unicode 'yen' does not capitalize to 'YEN').
E.g. caps+y -> ':' ; caps+Y -> '@' .
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-04 Thread Mihail Konev 
On Fri, Nov 04, 2016 at 08:41:28PM +0100, Mariusz Mazur wrote:
> Question is, was it there for 22 years cause it's unfixable or because
> nobody uses overlay? :)
Rather the latter, as overlay does not play nicely with shifts and
non-'simple' characters.
E.g. you cannot have caps+y be 'yen' and 'YEN' easily.
That's the reason to use levels instead (and not care about this bug).

But maybe I'm wrong and there are applications of this functionality.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-04 Thread Mariusz Mazur 
Question is, was it there for 22 years cause it's unfixable or because
nobody uses overlay? :)

2016-11-04 19:33 GMT+01:00  :
>> - press caps
>> - press f
>> - release caps
>> - wait
>> - release f
>
> In xserver/xkb/xkbPrKeyEv.c, there is a bug that prevents key
> press/release to be tracked properly for keys with overlays, in case
> such a key is down while the overlay state changes.  There is even a
> comment (from 9/11/94) that mentions the problem.
>
> Andreas
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-04 Thread wettstae 
> - press caps
> - press f
> - release caps
> - wait
> - release f

In xserver/xkb/xkbPrKeyEv.c, there is a bug that prevents key
press/release to be tracked properly for keys with overlays, in case
such a key is down while the overlay state changes.  There is even a
comment (from 9/11/94) that mentions the problem.

Andreas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-04 Thread Mariusz Mazur 
2016-11-03 22:20 GMT+01:00 Ran Benita :
>> 4. Defined caps+f to send XF86LaunchA to start a new terminal window
>> (among other similar shortcuts, like ones for switching virtual
>> desktops, but caps+f is the worst offender, so I'll focus on that).
>
> Nice hack.

Some ground work, a gui and such multi-layer keyboard rebindings could
become standard in many a linux distro.

> Just a guess, but maybe you are hitting this?
> https://cgit.freedesktop.org/xorg/xserver/tree/xkb/xkbPrKeyEv.c?id=xorg-server-1.18.99.902#n134
>
> Try running `xbindkeys --verbose` and see its output on key
> press/relase? The problem is in one of xserver, libX11 or xbindkeys,
> this would help narrow it down.

I know the issue isn't xbindkeys-specific, since I can also trigger a
form of it both on lxde and kde4.

Ha, bingo! While writing a reply I've been poking around it again and
found a fully reliable trigger in xbindkeys. It might just well be the
code you've linked to. Here's how to do it:

Relevant changes to keymap:

 interpret Overlay1_Enable+AnyOfOrNone(all) {
-action= LockControls(controls=Overlay1);
+action= SetControls(controls=Overlay1);
 };

 key  {
 type= "ALPHABETIC",
+overlay1= ,
 symbols[Group1]= [   f,   F ]
 };

-key  { [   Caps_Lock ] };
+key  { [   Overlay1_Enable ] };

-modifier_map Lock {  };



Contents of .xbindkeysrc:

"echo hi"
XF86LaunchA


Now run "xbindkeys -n -v" and in the exact order:
- press caps
- press f
- release caps
- wait
- release f

Voila. (Tested on two separate systems.)

Now, is there any chance of this getting a fix?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Debugging keyboard overlay+xbindkeys

2016-11-03 Thread Ran Benita 
On Thu, Nov 03, 2016 at 01:22:03PM +0100, Mariusz Mazur wrote:
> What I did:
> 1. Switched the overlay key to act as a modifier.
>  interpret Overlay1_Enable+AnyOfOrNone(all) {
> -action= LockControls(controls=Overlay1);
> +action= SetControls(controls=Overlay1);
> 
> 2. Bound it to caps lock.
> 3. Defined caps+hjkl to act as arrow keys.
> 4. Defined caps+f to send XF86LaunchA to start a new terminal window
> (among other similar shortcuts, like ones for switching virtual
> desktops, but caps+f is the worst offender, so I'll focus on that).

Nice hack.

> It would seem using the overlay mechanism the way I do messes with
> whatever mechanism xbindkeys/lxde use for intercepting keyboard
> shortcuts. Does anybody have any suggestions on any tools/approaches I
> could use to try to debug this further? Or is this mechanism something
> so ancient that there's hope of getting it to work correctly?

Just a guess, but maybe you are hitting this?
https://cgit.freedesktop.org/xorg/xserver/tree/xkb/xkbPrKeyEv.c?id=xorg-server-1.18.99.902#n134

Try running `xbindkeys --verbose` and see its output on key
press/relase? The problem is in one of xserver, libX11 or xbindkeys,
this would help narrow it down.

xbindkeys, for some reason, matches keysym bindings strangely; instead
of converting keycodes to keysyms and comparing the keysyms, it converts
the keysyms to keycodes and compares keycodes. This is lossy and can
cause the wrong binding to match. However, I don't think this is the
issue in the scenario you describe, unless you have some other keys
which map to XF86LaunchA.

Ran
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel