asus-numpad

asus-numpad copied to clipboard

Problem is my keyboard is Turkish and buttons are not correctly working. If change my layout to English UK, it works without any problem. So this problem can be caused in any other keyboard layouts which are different then English.

This layout should work properly but as i said because of keyboard layout, "equal" behave like minus and "dot" behave like "comma".

My idea about solution is. Keeping code in fixed layout even OS has different layout. Maybe we can use ASCII.

Looks like asus-numberpad-driver uses X11 APIs to query the actual keys- https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L365-L392

We would need to do something similar to get this to work.

For a quick and dirty solution, you could clone this repo and edit the source code yourself (replacing the KPDOT value with the correct one for your layout).

Looks like asus-numberpad-driver uses X11 APIs to query the actual keys- https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L365-L392

We would need to do something similar to get this to work.

For a quick and dirty solution, you could clone this repo and edit the source code yourself (replacing the KPDOT value with the correct one for your layout).

i fixed "equal" with KEY_KPEQUAL, trying to find right dot :D.

Btw we can solve this problem with downloading "xdotool" and using with system calls.

Command::new("xdotool")
    .args(&["keydown", &format!("{}", ascii_code)])
    .spawn()
    .expect("Failed to execute xdotool");

Command::new("xdotool")
    .args(&["keyup", &format!("{}", ascii_code)])
    .spawn()
    .expect("Failed to execute xdotool");

like this. But most probably we can find some better solution.

trying to find right dot

You could probably get this by adding a print(key) after https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L377 to log the final key codes that get used.

Okay "KEY_SLASH" is "dot". It makes sense when we compare Turkish and English keyboard. Also if there is someone who want to find right key,

Install evtest sudo evtest select right device { In mine there were 2 keyboard. If I select 20 which is physical keyboard, it just prints all keys but if I select 2 which is, , Translated set, it captures and show what i press.

}

then change in code, you can find buttons in https://docs.rs/input-event-codes/latest/input_event_codes/index.html

trying to find right dot

You could probably get this by adding a print(key) after https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L377 to log the final key codes that get used.

also this solution makes sense.

@Tahinli xdotool looks like the wrapper above functions that I use in the code mentioned by @iamkroot - anyway remember still it is X11 lib dependency so does not support distros with Wayland

@Tahinli xdotool looks like wrapper above functions what I use in code mentioned by @iamkroot - so it might be cleaner solution use it - but I have no exp - anyway remember still it is X11 lib dependency so does not support distros with Wayland I guess

It can be as you said. So in this situation, just need to find universal solution. I think it can be ascii, we just need to simulate button press with ascii codes.

Just to add our recent findings at asus-numberpad-driver, I'd like to say that getting the correct keys is possible using libxkbcommon which has both Wayland and X11 bindings.

Just some info from my side, using a swiss-german keyboard layout, I also had the problem that the equal sign gave something else, in my case the deadcaret. I'm on an Asus UX433FLC with wayland on Arch with plasma 6 at the moment (new system, actually old and cheap 2nd hand from work) and I used the M433IA layout. (Note that I used wev, the wayland equivalent of xev to find out what the touchpad-keypad-equal was sending.)

Then I considered that the regular equal sign on us_int is where the deadcaret is on de_ch with deadkeys.

So I also found that using KPEQUAL instead of EQUAL fixes that problem. Unfortunately I went through all the work to find that the solution was here already... ;-)

Anyway, please change EQUAL to KPEQUAL and add that the UX433FLC (written on the back, the UEFI thinks its a UX434) works with the M433IA layout. And most of all, thanks for the good work!!

@aRTee42 I've added this in #29 (this still has to be marged)

Thank you!