Impossible to set certain evdev event codes as capabilities for device output.

[pastaq]

So this issue I brought up in #296 has come up again. There is a specific use case for @hphilm new overlay that expects/responds to HAPPY_TRIGGER_5 for open/close of the window. By default this button on the Zotac Zone uses F18, which is currently mapped to QuickAccess2, which then gets translated by the default profile to Screenshot. I told him the best way forward would be to have his overlay load a new profile with HappyTrigger5 as the output event. Unfortunately, because of the previously linked change and the insistence that valid evdev outputs aren't a capability, there is currently no way to actually do that without refactoring it and possibly breaking other devices.

I'll open a PR to address this but the idea that named buttons aren't capabilities is frankly bullshit. There is no other straightforward way to emit these events otherwise.

[hphilm]

Seems RightPaddle1 issues HT5 ...

[ShadowApex]

@hphilm instead of trying to map this event to HAPPY_TRIGGER_5, you should instead be translating this event in a profile to a dbus event that your overlay software can listen for. E.g.

kind: DeviceProfile

...

mapping:
  - name: Quick Access 2
    source_event:
      gamepad:
        button: QuickAccess2
    target_events:
      - dbus: ui_my_custom_event

@pastaq For the future maintainability of inputplumber, I strongly disagree with adding HAPPY_TRIGGER_X as a capability in inputplumber. It goes against the core purpose of the capability system, which is to provide a way to assign meaning and intent to different inputs that are carried across different devices. The HAPPY_TRIGGER_X event codes are the antithesis to this purpose.

If we truly want to support users to be able to create their own virtual target device that emits HAPPY_TRIGGER_X events, then this would be better accomplished using a target-side capability mapping (similar to the source-side capability map v2) as @blindedone1458 suggested in their comment instead of shoehorning in these event codes that have no real world meaning into the capability system.

[hphilm]

As far as I see it that HAPPY_TRIGGER_X events are only part of the Xbox controllers:

input/event/evdev.rs

    match event_type {
        EventType::SYNCHRONIZATION => Capability::Sync,
        EventType::KEY => match KeyCode::new(code) {
            ...
            KeyCode::BTN_TRIGGER_HAPPY5 => {
                Capability::Gamepad(Gamepad::Button(GamepadButton::RightPaddle1))
            }
            KeyCode::BTN_TRIGGER_HAPPY6 => {
                Capability::Gamepad(Gamepad::Button(GamepadButton::RightPaddle2))
            }
            KeyCode::BTN_TRIGGER_HAPPY7 => {
                Capability::Gamepad(Gamepad::Button(GamepadButton::LeftPaddle1))
            }
            KeyCode::BTN_TRIGGER_HAPPY8 => {
                Capability::Gamepad(Gamepad::Button(GamepadButton::LeftPaddle2))
            }
            KeyCode::BTN_TRIGGER_HAPPY9 => {
                Capability::Gamepad(Gamepad::Button(GamepadButton::RightPaddle3))
            }
            KeyCode::BTN_TRIGGER_HAPPY10 => {
                Capability::Gamepad(Gamepad::Button(GamepadButton::LeftPaddle3))
            }
            ...
match capability {
    Capability::None => vec![],
    Capability::NotImplemented => vec![],
    Capability::Sync => vec![0],
    Capability::DBus(_) => vec![],
    Capability::Gamepad(gamepad) => match gamepad {
        Gamepad::Button(btn) => match btn {
            ....
            GamepadButton::LeftPaddle1 => vec![KeyCode::BTN_TRIGGER_HAPPY7.0],
            GamepadButton::LeftPaddle2 => vec![KeyCode::BTN_TRIGGER_HAPPY8.0],
            GamepadButton::LeftPaddle3 => vec![KeyCode::BTN_TRIGGER_HAPPY10.0],
            GamepadButton::RightPaddle1 => vec![KeyCode::BTN_TRIGGER_HAPPY5.0],
            GamepadButton::RightPaddle2 => vec![KeyCode::BTN_TRIGGER_HAPPY6.0],
            GamepadButton::RightPaddle3 => vec![KeyCode::BTN_TRIGGER_HAPPY9.0],

So only when xbox-elite is used you will get a BTN_TRIGGER_HAPPY_X output, which can be seen in evtest.

So what could be ui_my_custom_event in your example?

kind: DeviceProfile
...

mapping:
  - name: Quick Access
    source_event:
      gamepad:
        button: QuickAccess2
    target_events:
      - dbus: ui_my_custom_event
 ```

[ShadowApex]

As far as I see it that HAPPY_TRIGGER_X events are only part of the Xbox controllers:

The HAPPY_TRIGGER_X events are only used by the virtual Xbox controllers so far. Many different devices like flight sticks, etc. will emit those HAPPY_TRIGGER_X events. The reason these event codes were added to the kernel in the first place was just a way to support input devices with lots of buttons:
torvalds/linux@cf2f765

How those buttons are used is arbitrary and vary wildly from device to device. HAPPY_TRIGGER_5 on one device may be completely different from HAPPY_TRIGGER_5 on another device.

So what could be ui_my_custom_event in your example?

The dbus event name is arbitrary, you can name it whatever you'd like. We have some predefined events you can use if you want (defined here ), but you can name the event whatever you want. In the example I posted previously, when the QuickAccess2 button is pressed, the device will emit a ui_my_custom_event event over dbus.

E.g. you can use busctl to see those events emitted over dbus:

sudo busctl monitor org.shadowblip.InputPlumber | grep -A2 ui_my_custom_event

[hphilm]

OK, so the application looking for an event has to monitor inputplumber via busctl. So it is not possible to define for example BTN_TRIGGER_HAPPY20 somehow to be issued and you can see that in evtest? Currently our code looks like that:

use input_linux::{AbsoluteAxis, AbsoluteEvent, EventKind, InputEvent, Key, KeyEvent};
use slint::platform::Key as SlintKey;

pub fn translate_button(event: InputEvent) -> Option<SlintKey> {
    let mut key_press = None;
    if event.kind == EventKind::Key && event.value != 0 {
        let key = unsafe { KeyEvent::from_event(&event) };
        match key.key {
            Key::ButtonEast => key_press = Some(SlintKey::Escape),
            Key::ButtonSouth => key_press = Some(SlintKey::Return),
            Key::ButtonTriggerHappy5 => key_press = Some(SlintKey::MetaR),
            Key::Record => key_press = Some(SlintKey::MetaR),
            _ => {}
        }
    }

    if event.kind == EventKind::Absolute && event.value == 1 || event.value == -1 {
        let key = unsafe { AbsoluteEvent::from_event(&event) };
        let v = key.value;
        match key.axis {
            AbsoluteAxis::Hat0Y if v == -1 => key_press = Some(SlintKey::UpArrow),
            AbsoluteAxis::Hat0Y if v == 1 => key_press = Some(SlintKey::DownArrow),
            AbsoluteAxis::Hat0X if v == 1 => key_press = Some(SlintKey::RightArrow),
            AbsoluteAxis::Hat0X if v == -1 => key_press = Some(SlintKey::LeftArrow),
            _ => {}
        }
    }
    key_press
}

[ShadowApex]

OK, so the application looking for an event has to monitor inputplumber via busctl.

The busctl command is just a command-line tool to interact with DBus. What you want to do is use something like the zbus crate (if your application is using Rust) to connect to InputPlumber and listen for those events over DBus.

So it is not possible to define for example BTN_TRIGGER_HAPPY20 somehow to be issued and you can see that in evtest?

No, and you shouldn't be trying to do this if you don't have to. What you're trying to do is exactly the reason we have the ability to emit events over DBus.