~tmccombs

Recent activity

Re: wev keycodes don't match 9 days ago

From Thayne to ~sircmpwn/public-inbox

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
>

Re: wev keycodes don't match 15 days ago

From Thayne to ~sircmpwn/public-inbox

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

wev keycodes don't match 19 days ago

From Thayne McCombs to ~sircmpwn/public-inbox

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.