### System details

Omarchy 4.0.0-1 (Quattro), Hyprland 0.56.2, Xwayland 24.1.13  
Samsung Galaxy Book NP950QED, Intel i7-1260P, Iris Xe  
eDP-1 `1920x1080` @ 142 DPI (340×190 mm). Packaged `scale = "auto"` landed on **1.5**, then later recomputed as **2** after Hyprland reloads.

### What's wrong?

Packaged Quattro defaults put three scale layers in disagreement. This is a default-config bug, not an app-specific one. Native Wayland GTK/Qt is mostly fine.

**Defaults involved**

```lua
-- config/hypr/monitors.lua
local omarchy_gdk_scale = 2
local omarchy_monitor_scale = "auto"
hl.env("GDK_SCALE", tostring(omarchy_gdk_scale))
hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })
```

```lua
-- default/hypr/envs.lua
xwayland = { force_zero_scaling = true }
```

On this 1080p HiDPI laptop:

| Layer | Size the client is told |
|---|---|
| Hyprland layout | Logical `1280×720` when auto is 1.5 (`1920 / 1.5`) |
| XWayland (`force_zero_scaling`) | Physical `1920×1080`, 1:1 pixels |
| Session env | `GDK_SCALE=2` for every child |

X11 and Java AWT do not use the Wayland scale path. They see a 1920-wide X screen **and** honor `GDK_SCALE=2` (and sometimes `sun.java2d.uiScale`).

**Measured effect**

- A client whose 1× minimum width is 765 advertised `WM_NORMAL_HINTS` min width **1530** (`765 × 2`).
- Extra in-window chrome (sidebar, inspector, plugin panel) adds more width.
- The requested size exceeds 1920.
- A tiling compositor will not shift the toplevel left the way Plasma does, so the extra pixels hang off the right edge of the panel.

Same class of clients: Swing/AWT IDEs and tools, GTK forced onto X11, Flatpaks that inherit the session env, some Wine helpers.

**Auto scale is also unstable here.** With `scale = "auto"` this panel flipped between 1.5 and 2 across Hyprland reloads (no `omarchy hyprland monitor scaling` in the audit log). `omarchy-hyprland-monitor-scaling` steps `1 → 1.25 → 1.6 → 2`, so 1.5 is not a sticky preset. Pinning `omarchy hyprland monitor scaling 1.5` made the desktop the right size again, but that command still persists `GDK_SCALE` as `int(scale + 0.5)` → **2**, so the XWayland/Java overflow remains.

### Steps to reproduce

1. Quattro defaults: `scale = "auto"`, `force_zero_scaling = true`, `GDK_SCALE=2`.
2. 1080p laptop where auto is 1.5 (or pin 1.5).
3. Launch any Java AWT or X11-only app.
4. `xprop` → `WM_NORMAL_HINTS` minimum sizes are 2× the toolkit's 1× values.
5. Open extra chrome that adds width.
6. Compare with Plasma, or with `GDK_SCALE=1` in that process only.

### Expected

XWayland / Java clients size against the physical 1920×1080 X screen. Extra chrome lays out inside the panel.

### Workaround

Override **only** the XWayland/Java process. Do not change global `GDK_SCALE` (Wayland GTK still wants it):

```bash
GDK_SCALE=1 GDK_DPI_SCALE=1 JAVA_TOOL_OPTIONS=-Dsun.java2d.uiScale=1 <command>
```

For Flatpaks: `flatpak override --user` with the same env vars.

### Suggested default

Stop hardcoding `GDK_SCALE=2` while monitor scale is `"auto"`.

1. Derive `GDK_SCALE` from the applied monitor scale, **or**
2. Export `GDK_SCALE` only for Wayland GTK, and leave XWayland / Java at 1 when `force_zero_scaling` is on.

Related: #2824 (Java over-scaled), #758 (1080p `GDK_SCALE=2` guide), #6911 (Quattro reset `monitors.lua` to `GDK_SCALE=2`).

The companion AWT-popup tiling issue (class-only rules stretch `win0` tooltips over the whole client) is a separate default gap, with a patch in #7020.