[Lenovo Yoga Tab 3 Plus ROMs, Kernels, Recoveries, ] vladimiroltean:
Hate to break it to you, but rotating the recovery framebuffer is an operation that is quite a bit more involved than setting "TW_THEME := landscape" (assuming that's what you were trying to say).

Did you even bother to look at the patches linked in the top post? What about this one:

From 2a8821faf98f8c26a88e9bbe8a8a6d31015b938b Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <olteanv@gmail.com>
Date: Tue, 3 Jul 2018 00:04:03 +0300
Subject: [PATCH] TW_HWROTATION: add flag to handle hardware-rotated display
panels

* The existence of TW_HWROTATION that implements this feature at the
level of calls to libpixelflinger API closely mirrors the existence of
ro.sf.hwrotation for surfaceflinger in LineageOS.
* A brute-force approach was previously attempted via the
BOARD_HAS_FLIPPED_SCREEN makefile flag. That code iterated over the
active display surface in a double-buffered setup, and performed a
"smart" memcpy from the UI drawing surface (gr_draw) onto the display
surface. The problem was that, without heavy loop optimizations, that
code could have never scaled for 90 and 270 degree rotation.
I tried and you could literally see the for loop with the naked eye
while the display surface was updating.
* That code is now gone, but support for BOARD_HAS_FLIPPED_SCREEN := true
is still there (now means TW_HWROTATION := 180).
* This patch relies on the assumption that it is impossibly difficult
and non-portable to rotate whole framebuffer display surfaces, in a
way that is not dependent upon the graphics backend (adf, fbdev, drm,
overlay etc). Therefore, it identifies the rendering primitives that
the TWRP graphics stack exposes to the GUI application above, and
implements hwrotation inside each of those calls instead:
- gr_line(), gr_fill() - 2D geometric shapes (lines, rectangles)
- gr_blit() - graphical image resources
- gr_ttf_textExWH() - font rendering
- gr_fb_width(), gr_fb_height() - framebuffer resolution
* The gist is to keep the backend and framebuffer (dimensions, row size
etc) unchanged (because making changes there is asking for trouble),
but present an altogether different reality to the calling API,
according to the compile-time constant TW_HWROTATION.
* All (x, y) API coordinates and shapes are transformed before being
actually rendered as (x_disp, y_disp) display coordinates.
* With TW_HWROTATION := 90 or 270 you can turn a landscape device into
a portrait one, because the GUI is fooled by the reversed dimensions
reported by gr_fb_width() and gr_fb_height() and renders the UI as
for a different device.
* For blit and text rendering operations, figuring out the transformed
coordinates in display space is not enough, as the surfaces that are
to be rendered have to be rotated themselves. This is handled by
allocating an intermediary rotated surface on each rendering
operation (not ideal), so the code with the intermediary surface
is compiled out for the TW_HWROTATION := 0 case.
* This is still not as bad as rotating the whole framebuffer though, and
on a msm8976 device the performance hit is not even noticeable (for
software rendering).
* Currently there is no attempt to make a connection between the
TW_HWROTATION and the { RECOVERY_TOUCHSCREEN_SWAP_XY,
RECOVERY_TOUCHSCREEN_FLIP_X, RECOVERY_TOUCHSCREEN_FLIP_Y } settings.

Change-Id: Ic8966ad5360c8a499649fdb16e242286640fd992
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>