Second screen and OSD: the rest of the batch

Custom panel background. Theme / library / black covered three of the four
asks; "an own background" needed a picker. Takes the persistable read grant
like the library's own picker -- without it the URI works until the process
restarts and then resolves to nothing, which reads as the background
disappearing on its own. Darkened by the same scrim as the library backdrop,
because an arbitrary photo has no obligation to be dark and tile text still
has to be readable.

Clock and battery move into a status bar across the top instead of being two
grid cells. Same information, but it stops the clock competing for space with
the things you actually press, and the grid gets two cells back.

The rest of the in-game OSD's figures reach the panel: VPS, EE / GS / GPU
load and frame time. These were not missing by choice -- getFPS() was the
only figure with a way across the JNI boundary, so the panel could show
frames and a percentage of nominal and nothing else. PerformanceMetrics
already computed all of it for the overlay. Each getter returns 0 with no VM
rather than the last value, so an idle panel reads as idle instead of frozen
on whatever the last game was doing.

Tile height is now settable. Columns already decided width -- tiles split the
row equally, so choosing columns IS choosing width, and a second width
control would only be a way to disagree with it. Height had no control at
all, which is why a panel could only ever be as tall as its text.

A display can be told to stay out of it. "The second screen also still
appears on the external monitor when connected via usbc" is not a bug by the
display-picking rule -- a USB-C monitor is a perfectly good second display --
so this records a preference instead of guessing: the panel's own Not-this-
screen tile drops the display it is on, and settings can re-enable them.
Keyed by display NAME, since ids are reassigned across replugs. Guessing from
internal-vs-external would have been wrong anyway; Android has no stable
public display type before API 34.

Device temperatures on the performance overlay, which is where they were
asked for. The core cannot read a temperature -- there is no portable API,
and on Android the only route is a vendor-specific sysfs the app layer
already discovers for the panel -- so the app pushes the values in and the
overlay draws what it was given. Atomics because the writer is a UI-thread
poll and the reader is the GS thread. A sensor that could not be read is
omitted rather than drawn as a zero.

pcsx2/ImGui/ImGuiOverlays.cpp

@@ -492,6 +492,25 @@ __ri void ImGuiManager::DrawPerformanceOverlay(float& position_y, float scale, f
 #if defined(__ANDROID__)
 			if (const u32 skip = GSGetManualFrameSkip(); skip > 0)
 				s_speed_line.append_format("{}SKIP: {}", s_speed_line.empty() ? "" : " | ", skip);
+
+			// Device thermals, pushed in from the Android side (Cotcho: "temp sensor on
+			// applicable device as part of stats OSD"). The core cannot read them itself --
+			// there is no portable API, and on Android the only route is a vendor-specific
+			// sysfs the app layer already discovers. So this draws what it was given and knows
+			// nothing about where it came from; a sensor that could not be read is simply
+			// absent rather than shown as a zero.
+			if (Armsx2Thermals::show.load(std::memory_order_relaxed))
+			{
+				const float cpu_t = Armsx2Thermals::cpu.load(std::memory_order_relaxed);
+				const float gpu_t = Armsx2Thermals::gpu.load(std::memory_order_relaxed);
+				const float bat_t = Armsx2Thermals::battery.load(std::memory_order_relaxed);
+				if (cpu_t > ARMSX2_THERMAL_NONE)
+					s_speed_line.append_format("{}CPU {:.0f}\xc2\xb0", s_speed_line.empty() ? "" : " | ", cpu_t);
+				if (gpu_t > ARMSX2_THERMAL_NONE)
+					s_speed_line.append_format("{}GPU {:.0f}\xc2\xb0", s_speed_line.empty() ? "" : " | ", gpu_t);
+				if (bat_t > ARMSX2_THERMAL_NONE)
+					s_speed_line.append_format("{}BAT {:.0f}\xc2\xb0", s_speed_line.empty() ? "" : " | ", bat_t);
+			}
 #endif
 
 			if (GSConfig.OsdShowFPS)
@@ -2065,6 +2084,18 @@ void SaveStateSelectorUI::ShowSlotOSDMessage()
 }
 
 #ifdef __ANDROID__
+// Device temperatures, written by the Android app layer and read by the perf overlay above.
+// Atomics because the writer is a UI-thread poll and the reader is the GS thread; relaxed
+// because these are three independent display values with no ordering relationship to
+// anything -- a torn read would at worst show one stale number for one frame.
+namespace Armsx2Thermals
+{
+	std::atomic<float> cpu{ARMSX2_THERMAL_NONE};
+	std::atomic<float> gpu{ARMSX2_THERMAL_NONE};
+	std::atomic<float> battery{ARMSX2_THERMAL_NONE};
+	std::atomic<bool> show{false};
+} // namespace Armsx2Thermals
+
 namespace {
 	// Reload-immune snapshot of the Android UI's OSD choice. VMManager::ApplySettings
 	// re-derives EmuConfig.GS from the layered settings interface (base + per-game) every

pcsx2/ImGui/ImGuiOverlays.h

@@ -59,3 +59,25 @@ namespace InputRecordingUI
 }
 
 extern InputRecordingUI::InputRecordingData g_InputRecordingData;
+
+#ifdef __ANDROID__
+#include <atomic>
+
+/// Sentinel for "this sensor could not be read". Below any real temperature, so a single
+/// comparison distinguishes absent from cold without a second flag per value.
+#define ARMSX2_THERMAL_NONE (-1000.0f)
+
+/// Device temperatures for the performance overlay.
+///
+/// The core has no way to read these: there is no portable API, and on Android the only route
+/// is a vendor-specific sysfs whose zone names and units differ per SoC. The app layer already
+/// discovers all that for the second-screen panel, so it pushes the values in here and the
+/// overlay just draws them. Written from a UI-thread poll, read on the GS thread.
+namespace Armsx2Thermals
+{
+	extern std::atomic<float> cpu;
+	extern std::atomic<float> gpu;
+	extern std::atomic<float> battery;
+	extern std::atomic<bool> show;
+} // namespace Armsx2Thermals
+#endif