Doesn't work on Wayland about kanata HOT 16 CLOSED

Just tried keyd in Wayland session on my desktop, and can confirm that it works.

from kanata.

The log statements with kanata::oskbd::linux are from this function:

    pub fn write_key(&mut self, key: OsCode, value: KeyValue) -> Result<(), io::Error> {
        let key_ev = KeyEvent::new(key, value);
        let input_ev = key_ev.into();
        log::debug!("input ev: {:?}", input_ev);
        self.write(input_ev)?;

        let sync = InputEvent::new(
            &TimeVal {
                tv_sec: 0,
                tv_usec: 0,
            },
            &EventCode::EV_SYN(EV_SYN::SYN_REPORT),
            0,
        );
        self.write(sync)?;

        Ok(())
    }

The program does write the keycodes to uinput, so it seems it's getting ignored somehow.

I looked through another project (keyd) which claims to be cross-desktop (though I haven't tried it myself) to see if it's doing anything special for wayland, but couldn't spot anything from a quick scan.

from kanata.

One thought I had is that kanata doesn't care to put valid values in the time fields of the InputEvent. Maybe X doesn't care about that while Wayland does.

from kanata.

I'll try keyd in a spare moment, and tell if it works with Wayland. I'll also check if something is logged in system log, maybe compositor gets keycodes but discards them for some reason, as you suggested.

from kanata.

I tested out KDE under wayland via plasma-workspace-wayland in an Ubuntu 20.04 VM and kanata behaves as expected when I switch the DE to Plasma (Wayland).

I'm not a DE expert so not sure what would be different between this env and yours.

from kanata.

That's interesting. I tried to run kanata under Wayland on my two machines, desktop with Arch Linux, and laptop with Manjaro ARM. Perhaps Ubuntu has some additional package that is required to work? I'll try Ubuntu in VM, and if it works, I'll compare Wayland Ubuntu and Arch Wayland packages.

from kanata.

Well, I've downloaded Kubuntu 22.04 LTS, installed it in VirtualBox, and plasma-workspace-wayland. I allowed VirtualBox to get control of keyboard device, and kanata works in X11 session, and doesn't work in Wayland. You're using Ubuntu 20.02, perhaps it makes difference here.. I couldn't find anything interesting related to kanata.

from kanata.

I'll look more into how keyd initializes and writes to uinput when I have some time.

from kanata.

I couldn't spot any major differences between how keyd and kanata initialize uinput. They follow the same sequence of syscalls but with some minor changes in values, which I think should be irrelevant.

I also tried ubuntu 22.04 on wayland in a VM and was able to cause an issue. Not sure if it's related to the issue you're experiencing though.

I found that specifically, the enter key stopped working when starting kanata in the terminal. However, adding a sleep, e.g. sleep 1; kanata --debug resulted in the enter key successfully working afterwards. I assume the issue I discovered is related to the non-neutral state of the keyboard when kanata starts up.

All other keys other than enter worked as expected though.

I've created a branch that matches some of the values in the uinput init more closely to keyd. It also checks for error return codes in all syscalls now; the old code wasn't checking the returned ints from syscalls.

I somehow doubt any of these syscalls are failing on your system though; I don't see why changing desktop environment would affect syscalls that affect /dev/ files.

from kanata.

I'm happy to say that code in wayland-fix-testing fixes the issue for me! Thank you very much! I'll bisect that change to narrow down the line that makes kanata work for me.

I found that specifically, the enter key stopped working when starting kanata in the terminal. However, adding a sleep, e.g. sleep 1; kanata --debug resulted in the enter key successfully working afterwards. I assume the issue I discovered is related to the non-neutral state of the keyboard when kanata starts up.

I've noticed this problem as well, but it isn't related I think. I've been starting kanata with second keyboard - when I run kanata with same keyboard, sometimes it works normally, often kanata acts as if CTRL key was permanently pressed. I can be 'fixed' by pressing randomly CTRL keys. Once I managed to crash kanata bashing at random keys, though. It's somewhat annoying during testing, but is not that much of problem when kanata would be started at startup, I think (it has to be yet confirmed).

I have also one unrelated problem, namely not all symbols that are available in kmonad are understood by kanata. I'll prepare MR with all the missing symbols. You can see some of these that I needed for my config that I extracted from my prior kmonad config here. I think it will be best for compatibility to add all kmonad key aliases.

from kanata.

Problem is caused by

from kanata.

Key 578 is KEY_JOURNAL, which is an "Application Launch" type button. From a grep in the wayland tests, some keyboards do actually use this, and seems like kanata intercepting it breaks things in Wayland. Interesting!

 rg KEY_JOURNAL
test/litest-device-asus-rog-gladius.c
295:    EV_KEY, KEY_JOURNAL,

test/litest-device-keyboard-razer-blade-stealth.c
290:    EV_KEY, KEY_JOURNAL,

test/litest-device-anker-mouse-kbd.c
170:    EV_KEY, KEY_JOURNAL,

test/litest-device-keyboard-razer-blackwidow.c
292:    EV_KEY, KEY_JOURNAL,

test/litest-device-mouse-roccat.c
168:    EV_KEY, KEY_JOURNAL,

I'll prepare MR with all the missing symbols. You can see some of these that I needed for my config that I extracted from my prior kmonad config here. I think it will be best for compatibility to add all kmonad key aliases.

Sounds good to me!

from kanata.

Key 578 is KEY_JOURNAL, which is an "Application Launch" type button. From a grep in the wayland tests, some keyboards do actually use this, and seems like kanata intercepting it breaks things in Wayland. Interesting!

For loop range is exclusive, so it breaks at 577 which is KEY_TASKMANAGER, I think, but yes, this is interesting/unexpected. Apparently it is keyboard specific, given you were unable to reproduce it with your hardware. For me, both Pinebook Pro, and SPC Gear GK530 keyboards doesn't work. I also have one QMK-enabled keyboard that I haven't tested, and few other old keyboards somewhere. I will try them (if I find them!), to see if kanata would work of any of them while this key is intercepted.

from kanata.

I stand corrected, indeed problem starts from KEY_JOURNAL upwards. for key in 0..uinput_sys::KEY_JOURNAL { fixes problem for me, but I don't know if that is correct general fix for everyone, as I'm not familiar enough with how input on Linux works.

from kanata.

I'm fine with a fix to limit the loop range to 256 or KEY_JOURNAL. It doesn't affect my workflow and I don't think kanata has any named keys yet that output a keycode higher than 256 even in your latest PR.

from kanata.

I've created #22 for fixing this bug, let me know what you think.

from kanata.