~sircmpwn/public-inbox

6 3

wev keycodes don't match

Details
Message ID
<3c34e66cfe22ba1ec7ab54a5aeadbb1319d741b1.camel@gmail.com>
DKIM signature
pass
Download raw message
When I run `wev -f wl_keyboard` and press the escape key I get the
following output:

14:     wl_keyboard] key: serial: 10219; time: 7928051; key: 1; state:
0 (released)
                      sym: Escape       (65307), utf8: ''

I would expect the key to be a keycode that corresponds to the keycode
needed in the bindcode command in sway which I think is the code used
in the keycodes mapping for xkb. However, it seems to be off by 8. So
in order to add a mapping based on the keycode I need "bindcode 9" not
"bindcode 1". The same is true for every other key I've tried.
Details
Message ID
<QqN5dLK-tcMv4TE1LfKv4gOOSyMgLRukrSO1FsAW9zAo-Si_dLxdp_x9icyWx-ROMX1oWVdX8jV0bmY6OSignHBEFPuj2BaQqicIrEC43UQ=@emersion.fr>
In-Reply-To
<3c34e66cfe22ba1ec7ab54a5aeadbb1319d741b1.camel@gmail.com> (view parent)
DKIM signature
pass
Download raw message
Yes, there is an offset between Linux keys and XKB keys. See
wl_keyboard_key:

    uint32_t keycode = state == WL_KEYBOARD_KEY_STATE_PRESSED ? key + 8 : 0;

I don't know which kind wev should print.
Details
Message ID
<C0CLVW8DJIDB.FTB2WQ64WRWY@cirno>
In-Reply-To
<QqN5dLK-tcMv4TE1LfKv4gOOSyMgLRukrSO1FsAW9zAo-Si_dLxdp_x9icyWx-ROMX1oWVdX8jV0bmY6OSignHBEFPuj2BaQqicIrEC43UQ=@emersion.fr> (view parent)
DKIM signature
pass
Download raw message
Since the offset is explicitly encoded into the protocol spec (rather
than an implementation detail), I reckon that wev should print the
corrected value.
Details
Message ID
<ILwS_wps_6SJ-HdfjgZ6GgSELh7JOrIkhSP_BfoU-m7QSp6wjosn_IJKiUL-lqq2wOFeYxsgtbR5Ag7ouvviLlyUkYUkvDJWp-efF1YSpz8=@emersion.fr>
In-Reply-To
<C0CLVW8DJIDB.FTB2WQ64WRWY@cirno> (view parent)
DKIM signature
pass
Download raw message
On Monday, February 3, 2020 3:41 PM, Drew DeVault <sir@cmpwn.com> wrote:

> Since the offset is explicitly encoded into the protocol spec (rather
> than an implementation detail), I reckon that wev should print the
> corrected value.

I don't see the offset being hardcoded in the spec. I think the offset
is hardcoded in XKB.

Submitted [1] to clarify the spec.

[1]: https://gitlab.freedesktop.org/wayland/wayland/merge_requests/58
Details
Message ID
<CALbpH+jFnchWa=b7=GAK6g9ZDsY9QB6BDOZQ9LfBm+qAtrrf1w@mail.gmail.com>
In-Reply-To
<ILwS_wps_6SJ-HdfjgZ6GgSELh7JOrIkhSP_BfoU-m7QSp6wjosn_IJKiUL-lqq2wOFeYxsgtbR5Ag7ouvviLlyUkYUkvDJWp-efF1YSpz8=@emersion.fr> (view parent)
DKIM signature
pass
Download raw message
> I don't know which kind wev should print.

Maybe both? Labeled as evdev keycode and xkb keycode?
Although having two keycodes listed might be confusing. On the other
hand only listing one is confusing if the other one is the one you
want. :shrug:

On Mon, Feb 3, 2020 at 7:50 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Monday, February 3, 2020 3:41 PM, Drew DeVault <sir@cmpwn.com> wrote:
>
> > Since the offset is explicitly encoded into the protocol spec (rather
> > than an implementation detail), I reckon that wev should print the
> > corrected value.
>
> I don't see the offset being hardcoded in the spec. I think the offset
> is hardcoded in XKB.
>
> Submitted [1] to clarify the spec.
>
> [1]: https://gitlab.freedesktop.org/wayland/wayland/merge_requests/58
Details
Message ID
<sYG6M2qxHLp0IGSRvbQnMCVqo6R8oLDiRj3k-_AJ4cBVEvtpVu3mHkcpbtViHNmNw6UIfe0qoLeKHjN5AImX1DbfgrnkY-tVBWSag6Pjkxs=@emersion.fr>
In-Reply-To
<CALbpH+jFnchWa=b7=GAK6g9ZDsY9QB6BDOZQ9LfBm+qAtrrf1w@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
The discussion on the Wayland merge request highlight that:

- The raw keycodes printed by wev are platform-specific, they are Linux
  event codes "by chance" on our machines
- The only way to interpret an opaque keycode is to feed it to a keymap
- The XKB text format V1 (the only XKB keymap format) takes keycodes
  with an offset of 8

It may make sense to print both the raw keycodes in any case, and to
also print XKB keycodes in case the keymap has the right format.
Details
Message ID
<CALbpH+g11B9w8tf1QGHEGxriQFQHHmQYomu-NPMEmca0uWpEjQ@mail.gmail.com>
In-Reply-To
<sYG6M2qxHLp0IGSRvbQnMCVqo6R8oLDiRj3k-_AJ4cBVEvtpVu3mHkcpbtViHNmNw6UIfe0qoLeKHjN5AImX1DbfgrnkY-tVBWSag6Pjkxs=@emersion.fr> (view parent)
DKIM signature
pass
Download raw message
That makes sense. I do know of at least one application (alacritty)
that uses raw scan codes to configure using numeric keycodes (as
opposed to a fix set of symbols).

On Mon, Feb 10, 2020 at 4:24 PM Simon Ser <contact@emersion.fr> wrote:
>
> The discussion on the Wayland merge request highlight that:
>
> - The raw keycodes printed by wev are platform-specific, they are Linux
>   event codes "by chance" on our machines
> - The only way to interpret an opaque keycode is to feed it to a keymap
> - The XKB text format V1 (the only XKB keymap format) takes keycodes
>   with an offset of 8
>
> It may make sense to print both the raw keycodes in any case, and to
> also print XKB keycodes in case the keymap has the right format.