mirror of
https://github.com/meshtastic/firmware.git
synced 2026-11-04 21:34:26 -05:00
* fix(games): correct the high-score announcement argument order GAMES_HIGH_SCORE_STRING is "New %s high score %lu by %s!" but the arguments were passed as (name, initials, score): the initials string was formatted through %lu and the score integer through %s. That is a format/argument mismatch, so the announcement printed garbage at best and dereferenced the score as a pointer at worst. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(input): report which physical gamepad button produced an event A joystick event only carried the action it was mapped to, so a consumer could not tell two buttons apart once they shared one action, and games were limited to the handful of actions the broker defines. Carry the originating evdev button code in InputEvent::kbchar, encoded into a reserved 0xC0..0xDF range that misses printable ASCII and every INPUT_BROKER_MSG_ value (SystemCommands switches on kbchar without looking at inputEvent, so a collision there would reboot the node rather than move a paddle). D-pad events are axes, not buttons, and keep leaving kbchar at 0 -- which is exactly what lets a consumer tell stick from button. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(portduino): let one joystick action bind several buttons Input.JoystickButtons took a single evdev code per action, so a pad's A and Y could not both select, and the shoulder buttons could not sit alongside the D-pad. Accept a list of codes as well as a bare scalar; the config writer inverts its code->action map back out, emitting a list only where an action has more than one button. ConfigCheck gains a real checker for the section (it was previously waved through as free-form) covering the three ways a mapping silently does nothing: an action name the driver does not know, an evdev name where the numeric code belongs, and one code claimed by two actions. Two fixtures and shell-test cases cover the clean list form and those three faults. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(games): use the gamepad's extra buttons, and return home when idle Games now receive the physical button alongside the action, so a pad with more than two usable buttons controls more than two things: - Snake: a shoulder button mapped to left/right turns relative to the snake's heading (L counter-clockwise, R clockwise) while the D-pad keeps steering absolutely. The two are told apart by kbchar, not by hardcoding one pad's codes. - Breakout: the ball now rides the paddle after each serve until the player fires it with B or A, so a life is not lost to a ball already in flight when the player looks up. The paddle also keeps its position between lives. A game can claim BACK for the duration (Game::wantsBackButton) so B serves instead of pausing, and releases it once the ball is live. - Start (BTN_BASE4 / BTN_START) is mapped to select like any other button, so it launches games and drives the menus; inside a running game GamesModule picks it out of kbchar and pauses instead. Separately, the games frame no longer holds a walked-away device hostage: after 15 s with no input it returns to the home frame, so the device still reads as a Meshtastic node. The timer is suspended while a picker or banner is up (e.g. high-score initials entry, which the input handler never sees) so it cannot yank the user out mid-entry. Screen::isInteractionBusy() generalises the old module-intercept check -- modal module, intercepting module, game, or an open interactive overlay -- and MessageRenderer uses it before popping an incoming-message banner. A transient banner REPLACES an active overlay, so an arriving message could otherwise discard a half-entered high score. The message is still stored, its thread still selected, and the unread indicator still set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ui): compose freetext on the on-screen keyboard from a gamepad A gamepad can drive the on-screen keyboard but cannot type, so on a host with a joystick and no configured keyboard device the OSK is the only way to compose freetext. Set osk_found there, and gate the "Freetext" menu entries on whether the device can enter text at all (physical keyboard, OSK, or touchscreen virtual keyboard) rather than on kb_found alone -- those entries were hidden on exactly the devices that needed them. The OSK prompt that CannedMessageModule already had inline in the message selector becomes showOnScreenKeyboard(), so the menu path can reach it too. Menus call in from a banner callback and the banner is torn down as soon as that callback returns, which would take the keyboard down with it, so the menu path defers the launch to runOnce(). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(games): address review on frame fallback and joystick input gating Breakout: the paddle suppression was far too broad. aLinuxJoystick is constructed on every Linux host whether or not a gamepad is configured (InputBroker.cpp), so `aLinuxJoystick && kbchar == 0` was true everywhere and swallowed LEFT/RIGHT from the keyboard, trackball and ExpressLRS -- on a host with no joystick attached at all. Gate on the stick actually driving the paddle instead: LinuxJoystick assigns heldX before it emits and only auto-repeats while heldX is set, so every axis LEFT/RIGHT arrives with a zone held and nothing else does. kbchar == 0 still distinguishes an axis from a shoulder button mapped to left/right, which must keep nudging the paddle. Screen: showHomeFrame() did nothing when the home frame was hidden, since setFrames() only assigns positions.home for !hiddenFrames.home. That stranded the games inactivity bounce on the frame it was trying to leave. Fall back to the messages frame, which setFrames() always adds. Test: rename test_ballWaitsOnPaddleUntilLaunched to test_ball_waitsOnPaddleUntilLaunched, matching the repo convention and its neighbours in the file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(games): give games the whole InputEvent so Breakout can identify the source Follow-up to review on #11917. The previous narrowing still could not tell sources apart: kbchar == 0 is shared by the joystick's D-pad axis and by every other driver that sends a bare LEFT/RIGHT, so while the D-pad was held a keyboard or touchscreen press was still discarded. heldXZone() proves the axis is driving, not that this particular event came from it. Pass the event itself to Game::handleInput() rather than (ev, kbchar). Games that only care about the action read event->inputEvent; Snake keeps using kbchar for shoulder steering; Breakout now also checks event->source against LinuxJoystick's origin name, so only that driver's own axis repeats are suppressed. Chose the event over a third positional parameter so the signature does not have to grow again the next time a game needs something the event already carries. All three conditions in Breakout are load-bearing: source says it came from this gamepad, kbchar == 0 says it is the axis rather than a shoulder button mapped to left/right, and heldXZone() != 0 says the axis is what is driving right now so tick() already has it covered. LinuxJoystick::originName() exposes the name the driver stamps into InputEvent::source, alongside the existing heldXZone()/heldYZone() accessors. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
70 lines
2.7 KiB
C++
70 lines
2.7 KiB
C++
#pragma once
|
|
// Linux evdev gamepad/joystick input. Only compiled on Linux portduino targets;
|
|
// macOS / non-Linux builds have no <linux/input.h> or epoll. Unlike LinuxInput
|
|
// (keyboard, EV_KEY only) this decodes the D-pad from EV_ABS axes as well.
|
|
#if ARCH_PORTDUINO && defined(__linux__)
|
|
#include "InputBroker.h"
|
|
#include "concurrency/OSThread.h"
|
|
#include <linux/input.h>
|
|
#include <map>
|
|
#include <stdint.h>
|
|
#include <sys/epoll.h>
|
|
|
|
#define JOY_MAX_EVENTS 10
|
|
|
|
// Default button map when config.yaml has no [Input] JoystickButtons override.
|
|
// Codes confirmed by evdev capture on a 0079:0011 "USB Gamepad".
|
|
#define JOY_BTN_A BTN_THUMB // 0x121 -> INPUT_BROKER_SELECT
|
|
#define JOY_BTN_B BTN_THUMB2 // 0x122 -> INPUT_BROKER_CANCEL
|
|
#define JOY_AXIS_CENTER 127 // D-pad resting value
|
|
#define JOY_AXIS_LOW 64 // below this -> "min" edge (0)
|
|
#define JOY_AXIS_HIGH 192 // above this -> "max" edge (255)
|
|
|
|
// D-pad auto-repeat while a direction is held (typematic).
|
|
#define JOY_REPEAT_DELAY_MS 400 // hold this long before repeats start
|
|
#define JOY_REPEAT_INTERVAL_MS 150 // then repeat this often
|
|
|
|
class LinuxJoystick : public Observable<const InputEvent *>, public concurrency::OSThread
|
|
{
|
|
public:
|
|
explicit LinuxJoystick(const char *name);
|
|
void init(); // Registers this source with the InputBroker
|
|
void deInit(); // Strictly for cleanly "rebooting" the binary on native
|
|
|
|
// Current held D-pad zone, updated the instant the axis moves (independent of the typematic
|
|
// auto-repeat). -1 = left/up edge, 0 = centered, +1 = right/down edge. Lets a game poll for
|
|
// smooth continuous control instead of waiting for the slow repeat events.
|
|
int heldXZone() const { return heldX; }
|
|
int heldYZone() const { return heldY; }
|
|
|
|
// The name this driver stamps into InputEvent::source. Lets a consumer tell an event that came
|
|
// from this gamepad from one that came from a keyboard or touchscreen carrying the same action.
|
|
const char *originName() const { return _originName; }
|
|
|
|
protected:
|
|
virtual int32_t runOnce() override;
|
|
|
|
private:
|
|
void emitEvent(input_broker_event event, unsigned char kbchar = 0);
|
|
|
|
const char *_originName;
|
|
bool firstTime = true;
|
|
|
|
// evdev button code -> broker event, built from config (or defaults) in init().
|
|
std::map<int, input_broker_event> buttonMap;
|
|
|
|
struct epoll_event events[JOY_MAX_EVENTS];
|
|
struct epoll_event ev;
|
|
int fd = -1;
|
|
int epollfd = -1;
|
|
|
|
// D-pad auto-repeat state: currently held zone per axis (-1 / 0 / +1) and the
|
|
// next millis() timestamp at which to re-emit while the direction is held.
|
|
int heldX = 0;
|
|
int heldY = 0;
|
|
uint32_t nextRepeatX = 0;
|
|
uint32_t nextRepeatY = 0;
|
|
};
|
|
extern LinuxJoystick *aLinuxJoystick;
|
|
#endif
|