Automatic target

[sezanzeb]

@jonasBoss I'm thinking about how to implement key_up at the moment. The idea below won't work for this, but maybe it's still interesting. What do you think about an "automatic" target uinput mode?

    def write(self, event, target_uinput):
        """write event to target uinput"""
        uinput = self.get_uinput(target_uinput, event)
        if not uinput:
            raise inputremapper.exceptions.UInputNotAvailable(target_uinput)

        if not uinput.can_emit(event):
            raise inputremapper.exceptions.EventNotHandled(event)

        uinput.write(*event)
        uinput.syn()

    def get_uinput(self, name, event=None):
        """UInput with name

        Or None if there is no uinput with this name.

        Parameters
        ----------
        name
            Uniqe name of the uinput device.
        event
            Used to figure out the correct uinput in automatic mode.
        """
        if name == AUTO_UINPUT_TARGET:
            assert event is not None

            for device in self.devices:
                if device.can_emit(event):
                    return device

            return None

        return self.devices.get(name)

[jonasBoss]

I don't think the automatic target is useful. It is totally possible to have multiple devices with the same capabilities. The automatic target might lead to confusion and unexpected results. With the new Injection system creating a mapping without a target will raise an exception.

About the key_up macro: I don't think a macro is the right place to implement this feature. We might want to forward a key-up also on other actions that get triggered by a combination. E.g.: Shift_L+a -> b should write a lowercase b.

In the new Injection system I forward Key-up events from the CombinationHandler by default. We could add a Mapping property for that.

[sezanzeb]

We might want to forward a key-up also on other actions that get triggered by a combination. E.g.: Shift_L+a -> b should write a lowercase b.

but there won't be a key-up that can be forwarded until the combination is released. Do you mean that a new key-up event is generated and injected?

[sezanzeb]

if_single might require some work if the trigger is released before the macro starts

[sezanzeb]

a use-case for not releasing the trigger might be in games. There could be a mapping that triggers a different skill if W is held. In the game, the character should most likely continue to run though so W should not be released.

• 1: not mapped, default skill
• W + 1: different skill because running forward
• W: not mapped

By default, should it behave the way it is now to not break compatibility? A property for the mapping (release_trigger?) as you suggested would have the great benefit of working with the KEY_A + KEY_B syntax.

[jonasBoss]

Do you mean that a new key-up event is generated and injected?

exactly:

class CombinationHandler(MappingHandler):
    def forward_release(self, forward: evdev.UInput) -> None:
        """forward a button release for all keys if this is a combination

        this might cause duplicate key-up events but those are ignored by evdev anyway
        """
        if len(self.mapping.event_combination) == 1:
            return
        for event in self.mapping.event_combination:
            forward.write(*event.type_and_code, 0)
        forward.syn()

This function gets called as soon as a the combination is triggered before the event is passed on to other handlers.

if_single might require some work if the trigger is released before the macro starts

I am not sure, why do you think so?

By default, should it behave the way it is now to not break compatibility?

I think having the release as a default is better. I assume that is the more common use-case. Also not releasing behaves differently on X and Wayland. The default should behave the same in both environments.

[sezanzeb]

I am not sure, why do you think so?

It's probably it's fine, was thinking about it from the wrong angle

I think having the release as a default is better

There could be a checkbox in the GUI for "Release Trigger" or something, and a migration to uncheck it for all existing mappings to not break anything

[jonasBoss]

I totally see the point of having some kind of automatic target it would enhance the user experience.

But I think implementing that on the backend is the wrong approach due to reasons I mentioned earlier. Automatic targets on the backend could also brake mappings in the future if we choose to add more uinputs.

However that doesn't mean we can not have a automatic-target-like feature on the frontend. maybe we can have a target suggestion in the frontend, which selects a valid target if the user chooses so.

[NikitaGolovaniuk]

I am not sure how those things works but current situation looks weird as for me. We can change input from mouse to keyboard or keyboard to mouse but why we cant change input from mouse to all device? Like mouse click to keyboard and mouse and joystics mixed macroses.

[Matafou]

Hi there
+1 automatic device should definitely not be in backend, but multi-device macros should definitely be. Currently key(h).key(BTN_LEFT) does not seem to work.

[Matafou]

(novice user point of view though)

[jonasBoss]

The problem is partly how linux desktops (X11, Wayland) treat different devices. Essentially a mouse can only have mouse buttons, and a keyboard can only have keyboard keys.

If we try to create a virtual mouse with all the mouse buttons, axis and also with keyboard keys the desktop would not know what kind of device that is and will ignore it.
This is extends also to individual applications: there are many games which can only be used by a single controller or either a controller or mouse and keyboard, but not both.
This is why we create individual devices for those, and why you need to select the target device for each mapping.

There are ideas how we could still implement this: #310

[Matafou]

Selecting one device per event emitted seems perfectly sensible (and a very sane invariant imho). But it does not prevent one macro to emit different events to different devices. The suggested with_device() would be a nice implementation of that indeed.
Thanks for the feedback!