[PhilMo6]

Tested on a Wio Tracker L2 (the only one in this thread, so these are hardware results, not guesses). Both changes are confined to boards/seeedstudio-wio-tracker-l2/.

1. Display came up at the wrong rotation (platformio.ini)
   ROTATION=1 on this env produced glass rotation 2, because the rotation is applied twice on the LovyanGFX backend:

include/DisplayDrivers_User_Setup.h defines TFT_ROTATION as ROTATION + ROT_OFFSET when the board does not set it.
DisplayConfig.cpp seeds displayConfig.rotation from it, and lovyan.cpp passes that into LovyanGFX's cfg.offset_rotation.
Panel_LCD::setRotation() adds offset_rotation to the setRotation(ROTATION) that main.cpp issues.
Nobody saw it before because every other LovyanGFX env runs ROTATION=0, and all the DisplayDrivers device profiles pin TFT_ROTATION 0 (devices/README.md: "Rotation is not one of them"). This env describes its panel inline, so it is the one board the bridge reaches. The Arduino_GFX backend is not affected: its setRotation() is absolute.

Change: ROTATION=1 (the landscape the case is built for) with TFT_ROTATION=0, panel kept at its native 240x320. The result is internal rotation 1 = Panel_NV3031B MADCTL MY|MV, the same MADCTL Meshtastic and meshpunk reach on this panel with offset_rotation=1. Touch follows through hal_touch_read() unchanged: swap, then mirror X against 320, which is the hardware-verified (319 - raw_y, raw_x) mapping within a pixel.

Hardware: orientation and 4-corner touch correct.

You may prefer to fix the bridge itself (skip it under USE_LOVYANGFX, or stop lovyan.cpp from adding displayConfig.rotation to the offset) so the next LovyanGFX board with a non-zero ROTATION does not hit this. I kept the change to the board file.

2. A held finger chained presses into the next menu (interface.cpp)
   InputHandler() applied every hal_touch_read() on every pass. hal_touch_apply() raises touchPoint.pressed each call and the menus act on it without waiting for a release, so one tap selected a row and the same finger, still down, tapped whatever the submenu drew under it. Adding the 250 ms throttle the other touch boards use helped but still chained on a hold longer than 250 ms.

Change: apply once on the press edge; repeat only after the finger has been held 500 ms, then every 250 ms (hold-to-scroll on the +/- rows keeps working). While LongPress is set the finger is re-applied every pass as before, since launcherSelectHeld() reads touchPoint.pressed for the file browser's long-press detection. The GT911 is read every pass so the release is seen within one poll.

Hardware: menus no longer chain; hold-to-repeat works. Not a release-edge fix, so a finger held past half a second on a new menu still produces a press there, as on every other board.