Table of Contents
BackTrack 4 resolution settings: the historical command and a current diagnostic method
Correction dated 1 September 2026: This post originally appeared in 2011 and offered only
xrandr -s 1024x768. That command remains useful as a historical record for an old X11 session, but BackTrack 4 was based on Ubuntu 8.10 and has long been unsupported; its successor, Kali Linux, launched in 2013. Do not use BackTrack 4 as a current, networked security workstation. For a security-testing environment, obtain a supported release from an official Kali site and test only systems for which you have explicit authorization.
The short answer
- Preserving an old BackTrack 4 VM: treat it only as an isolated research archive. Take a snapshot, leave networking disabled by default, store no real credentials, and do not replenish it from old mirror sites.
- A current X11/Xorg session: use
xrandr --queryto learn the real output name and available modes, then name the output and mode explicitly. - A Wayland session: prefer the desktop environment or compositor's display settings. What
xrandrsees is often the Xwayland compatibility layer, not a reliable control surface for physical outputs. - A VM or remote desktop: resolution may be controlled by a virtual graphics device, guest integration, the remote session, or a virtual X server rather than a physical HDMI/DP connector.
Why the 2011 command sometimes worked
The old post first listed modes:
xrandr
It then temporarily selected an existing size:
xrandr -s 1024x768
xrandr is the command-line configuration utility for the X Resize and Rotate extension. In a simple, single-screen X11 environment, -s can select a screen configuration by size. It does not identify a particular output, however, so it becomes ambiguous with multiple displays, rotation, scaling, and modern desktop layouts. It usually changes only the current X session and is not a general Wayland configuration method.
Step one: identify the current session type
Ask the desktop session what type it reports:
printf '%sn' "${XDG_SESSION_TYPE:-unknown}"
x11: continue with the XRandR workflow below.wayland: skip to the Wayland section.- Blank or
unknown: do not guess. Establish whether this is a local desktop, SSH shell, container, VM console, or remote desktop session.
The environment variable is a diagnostic clue, not a security boundary. Over SSH, also establish which display session the command would reach; do not modify an unknown user's session blindly as an administrator.
X11/Xorg: read before changing
1. List connection state and known modes
xrandr --query
The output may contain lines such as eDP-1 connected, HDMI-1 connected, or Virtual-1 connected; the indented sizes below an output are its known modes. An asterisk normally marks the current mode and a plus sign the preferred mode. Names differ between machines, so use the values shown by your own query.
2. Name the output, mode, and refresh rate explicitly
This is a syntax example only. Use it unchanged only if HDMI-1, 1920x1080, and 60 all appear in your query result:
xrandr --output HDMI-1 --mode 1920x1080 --rate 60
Record the old setting first so it can be restored if the display becomes unusable. Do not run an untested display command remotely, because it may temporarily make the current session invisible. For a laptop panel, replace the example output with the real internal-panel name shown by the query.
3. Prefer desktop settings for persistence
Current desktop environments normally remember each output's layout, scaling, and preferred mode. Configure it in the system display panel first and verify it after signing in again. A startup script containing a hard-coded xrandr command depends on output names, connection order, and timing; it can fail after changing a port, dock, or driver.
For an old X11 archival system that must be preserved, consider a per-user session startup entry only after a snapshot and rollback path exist and the exact command has been tested manually. Do not copy an unfamiliar xorg.conf or random modeline merely to fix resolution.
Wayland: let the compositor manage physical displays
In the Wayland architecture, the compositor manages input and output. Xwayland is an X server that runs as a Wayland client to support X11 applications. Consequently, xrandr in a Wayland session may expose Xwayland's logical view rather than physical connectors it can reconfigure.
Use the GNOME, KDE Plasma, or relevant compositor display panel for resolution, scaling, and refresh rate. If an option is missing, record the desktop/compositor, graphics hardware, kernel, display protocol, cable or dock, and errors reported by display settings or system logs; then consult the relevant project's official documentation. Do not try to bypass the compositor with an X11 command.
If the desired mode is absent
A mode missing from xrandr --query is not necessarily “one command away.” Narrow down the cause in this order:
- Confirm the display is marked
connected, then check its selected input, cable, adapter, and dock. - Within the display and interface limits, try a lower resolution or refresh rate that the query actually lists.
- Check whether the system read the display identification data (EDID) and whether kernel/graphics logs report a link or driver error.
- In a VM, inspect the virtual graphics adapter, dynamic-resize setting, and publisher-provided integration tools compatible with that guest; do not download a “universal graphics driver” from a third-party site.
- Under noVNC, VNC, RDP, or a nested desktop, determine whether the remote service's launch parameters or virtual framebuffer sets the canvas size.
Adding a modeline manually requires accurate display timings, interface capability, and driver support. Copying arbitrary cvt or xrandr --newmode commands from the web can produce a blank screen or an unsupported signal, so this article does not provide a hardware-independent modeline.
A safe boundary for BackTrack 4
Kali's official history says BackTrack 4 was released in 2010 on the already unsupported Ubuntu 8.10 base; BackTrack 5 was the last BackTrack release, after which Kali Linux continued the project. An old system lacks continuing security fixes, so connecting it to ordinary networks, entering current credentials, or browsing for downloads expands the risk.
If old software must be reproduced:
- use a VM copy with no private data, and save a snapshot and file hashes first;
- disable networking, shared clipboard, shared folders, USB passthrough, and host credentials by default;
- if networking is essential to the research, use a controlled isolated network and document the allowed purpose and traffic boundary;
- do not use old tools for unauthorized scanning, intrusion, or account access;
- restore a clean snapshot afterward and do not carry unknown files back to the host.
Quick decision table
| Situation | Appropriate starting point | Avoid |
|---|---|---|
| Current X11 desktop | Run xrandr --query, then use real output and mode names | Guessing the output or selecting an unlisted mode |
| Current Wayland desktop | Desktop/compositor display settings | Treating XRandR as a physical-output controller |
| Current VM | VM display controls and official guest integration | Random drivers or host modelines forced into the guest |
| Remote desktop/noVNC | Remote service or virtual-X canvas dimensions | Assuming the remote session has a physical HDMI output |
| BackTrack 4 archive | Isolated VM, snapshots, least privilege | Routine networking, stored credentials, or unauthorized testing |
Primary sources
- Official Kali Linux history: from BackTrack to Kali
- Kali Linux's ten-year retrospective: BackTrack 4/5 and the transition to Kali
- X.Org: the XRandR project and command-line configuration utility
- Wayland documentation: Xwayland is an X server running as a Wayland client
- The official Kali Linux sites list
The old command remains here so a 2011 search result can still be understood. A current solution should identify the session type, actual output, runtime environment, and supported software instead of copying one historical command into every Linux desktop.
