fix: remove unnecessary screen width rounding in ChangeScreenSize

[hiroTamada]

Summary

• Removes the Go-level s.Width = s.Width - (s.Width % 8) rounding in ChangeScreenSize that was silently truncating requested widths (e.g. 390 → 384)
• Makes XCreateScreenMode return the actual dimensions that libxcvt produced via in/out pointer parameters, so the Go caller uses the correct width for XSetScreenConfiguration
• Fixes the mode name in XCreateScreenModeInfo to use libxcvt's actual output dimensions instead of the original request, preventing name/geometry mismatches

Context

The rounding was originally added to match libxcvt's CVT convention of producing widths as multiples of 8. However, CVT is a timing standard for generating timing parameters for physical monitors — not a hard requirement of X.Org or the Xorg dummy driver used for virtual displays. The rounding made it impossible to use non-multiple-of-8 resolutions like 390x844 for mobile viewports, even when valid modelines existed in xorg.conf, because Neko would turn 390 into 384 before ever searching for a mode.

Now the resolution flow is:

1. Exact match — if a pre-defined modeline exists in xorg.conf for the exact requested dimensions (e.g. 390x844), XSetScreenConfiguration finds and uses it directly.
2. Dynamic creation — if no match, XCreateScreenMode dynamically creates a new mode via libxcvt and reports the actual dimensions back to the caller.

Verified

Tested end-to-end in a headful chromium-headful container:

• Requested 390x844@25Hz via the kernel-images API
• xrandr confirmed display at exactly 390x844_25 (using a manually crafted modeline in xorg.conf that bypasses CVT rounding)
• CDP verification confirmed screen.width=390, screen.height=844, innerWidth=390, innerHeight=807 (37px app-mode title bar)

---

Note

Medium Risk
Touches XRandR mode selection/creation and changes the resolution-setting flow, which could affect display configuration behavior across environments, but the change is localized to the Xorg wrapper.

Overview
ChangeScreenSize no longer truncates widths to a multiple of 8 before attempting to apply a screen mode; it now tries to set the exact requested dimensions first and only creates a new mode if no existing mode matches.

XCreateScreenMode is updated to take width/height as in/out pointers so the caller receives libxcvt’s actual generated dimensions, and XCreateScreenModeInfo now names modes using those actual dimensions to avoid name/geometry mismatches.

^{Written by Cursor Bugbot for commit 3f90ca6. This will update automatically on new commits. Configure here.}

[Sayan-]

generally lgtm! how'd you test these changes?

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Missing round-up-to-8 fallback step before mode creation

Medium Severity

The PR description documents a 3-step fallback (exact match → round-up to nearest multiple of 8 → dynamic creation), but ChangeScreenSize only implements steps 1 and 3. The round-up step is missing: after the exact XSetScreenConfiguration fails, the code jumps directly to XCreateScreenMode instead of first trying the width rounded up to the nearest multiple of 8. This means if a pre-configured mode like 392×844 already exists and 390×844 is requested, libxcvt will create a duplicate 392×844 mode instead of reusing the existing one, causing mode proliferation on every such request.