fbcli should clearly warn the user that a non-existent event is not recognised

DESCRIPTION: Typing fbcli --event no-such-event should make it clear to the user that the event has not been found. If someone makes a typo or wrongly guesses the name of an event, it's misleading to state that the event has been triggered and that 'return' can be pressed to end the feedback. The risk is that the user thinks that there is a bug in led/vibra/sound rather than an error due to typing a non-existent event name.

REPRODUCE:

$ fbcli --event message-new-sms
Triggering feedback for event 'message-new-sms'
Press <RETURN> to end feedback right away.
$ fbcli --event no-such-event
Triggering feedback for event 'no-such-event'
Press <RETURN> to end feedback right away.

The message-new-sms event correctly gives a vibration and sound. The no-such-event event gives no led/vibra/sound feedback, but the user is informed on the command line that the (non-existent) event was triggered as if it had been recognised. The second line about pressing RETURN also gives the impression that the event is valid.

CONTEXT:

• Mobian/trixie
• Pinephone v1.2

$ dpkg -l |grep -E "feedbackd|lfb|systemd"
ii  dbus-user-session                     1.14.10-1                            arm64        simple interprocess messaging system (systemd --user integration)
ii  feedbackd                             0.2.1-1                              arm64        DBus service for haptic/visual/audio feedback
ii  feedbackd-common                      0.2.1-1                              all          Shared files for feedbackd
ii  feedbackd-device-themes               0.0.r3-1                             all          Device specific themes for Feedbackd
ii  gir1.2-lfb-0.0:arm64                  0.2.1-1                              arm64        GObject introspection data for libfeedback
ii  libnss-resolve:arm64                  254.1-3                              arm64        nss module to resolve names via systemd-resolved
ii  libnss-systemd:arm64                  254.1-3                              arm64        nss module providing dynamic user and group name resolution
ii  libpam-systemd:arm64                  254.1-3                              arm64        system and service manager - PAM module
ii  libsystemd-dev:arm64                  254.1-3                              arm64        systemd utility library - development files
ii  libsystemd-shared:arm64               254.1-3                              arm64        systemd shared private library
ii  libsystemd0:arm64                     254.1-3                              arm64        systemd utility library
ii  systemd                               254.1-3                              arm64        system and service manager
ii  systemd-dev                           254.1-3                              all          systemd development files
ii  systemd-resolved                      254.1-3                              arm64        systemd DNS resolver
ii  systemd-sysv                          254.1-3                              arm64        system and service manager - SysV compatibility symlinks
ii  systemd-zram-generator                1.1.2-3                              arm64        Systemd unit generator for zram devices
ii  wake-mobile                           1.8-1                                arm64        Proof-of-concept alarm app that uses systemd timers to wake up the system

DISCUSSION: I couldn't spend more time trying to work out the gnome/glib way of defining what seems to be a C macro LFB_IS_EVENT in libfeedback/lfb-event.c, so I can't propose a MR - sorry. grep --color -r LFB_IS_EVENT . in the top of the source tree doesn't show any line that appears to be a macro definition.

RELATED:

• The fallback from a-b-c to a-b to a at #23 seems like a good idea. In that case the user should be warned that a-b-c is not recognised, and, say, a-b is being triggered instead; and only tell the user that the event is totally unrecognised if neither a-b nor a are recognised as events.