# Xorg 1.19.7 driver autodetection: test package

This is a test build of the OpenIndiana Hipster X server, Xorg 1.19.7. It
fixes how Xorg picks a video driver when no KMS driver is active. You install
it into a **new, disposable boot environment** and boot that environment
**once**.

> **Going back is a reboot.** The test boot environment is activated for the
> next boot only. Your current boot environment stays the default throughout.
> If the screen stays black or anything else looks wrong, restart the machine
> (power-cycle it if you have to). It comes back up in your normal system.

- Pull request: [OpenIndiana/oi-userland#27965](https://github.com/OpenIndiana/oi-userland/pull/27965)
- Related report: [illumos Redmine #18500](https://www.illumos.org/issues/18500) (HP EliteBook 820 G2, UEFI)
- PR head: `0bbe7561afd152c8f5c7fc51baf37077fc2b55c9`
- Package build and runtime-tested source: `77ad974c1cf4ab7eaa9bc9fbe451c9ea1cac17aa`

The PR head only removes a standalone test file; its production inputs are
identical to the package build. See [source details](SOURCE-REVISIONS.txt).

## What changed

Recent Hipster builds treated the illumos bitmap console (`illumos_fb`) as
proof that the machine has no legacy video BIOS. When Xorg saw that console,
it dropped the `vesa` driver and used the generic `illumosfb` framebuffer
driver. However, the bitmap console appears with BIOS VBE *and* with UEFI
GOP. On many machines the video BIOS is still there, so `vesa` would have
worked. `illumosfb` cannot change modes. It keeps whatever resolution the
firmware chose, often 1024×768.

With this build, Xorg chooses as follows:

1. **`modesetting`** if the default DRM device has KMS connectors.
2. Otherwise **the usual PCI drivers and `vesa`** if a legacy video BIOS is
   present, or if the check is inconclusive.
3. **`illumosfb`** only for a bitmap console on a machine that definitely has
   no legacy video BIOS (pure UEFI/GOP). This case worked before, and it
   should keep working.

A `Device` section that names a driver still takes precedence. If you added
`/etc/X11/xorg.conf.d/10-vesa.conf` as a workaround, it continues to work.

## Who this test is for

**Useful:** up-to-date Hipster systems running the stock Xorg 1.19.7 with
**no active KMS driver**, in particular:

- machines that boot with BIOS, or with UEFI plus CSM (legacy video BIOS);
- machines that lost their usual resolution after a recent update and now
  run `illumosfb`;
- the HP EliteBook 820 G2 from Redmine #18500, and similar UEFI laptops.

**Also useful, as a regression check:** pure UEFI machines with no video BIOS.
They should still end up on `illumosfb`.

**Not a reproducer:** machines with a working KMS driver. Automatic
selection prefers `modesetting` on those machines; an explicit driver
configuration still takes precedence. They are outside the reported
BIOS/framebuffer regression.

**Do not install this** if you run the newer Xorg 21.1 graphics stack. This
kit is for 1.19.7 only. Stay on 21.1; do not downgrade. This kit does not
enable, select or switch any DRM driver stack, and you should not do that as
part of this test.

## What has been tested so far

These results come from virtual machines running a test image built from the
same packages. No physical machine has been tested yet. That is what this
test is for.

| Firmware / machine | Automatic choice | With a driver configured explicitly | Keyboard |
| --- | --- | --- | --- |
| SeaBIOS, standard VGA (KVM) | `vesa`, 1920×1200 | `10-vesa.conf`: `vesa`, 1920×1200 | US layout kept; Y key gives `y` |
| OVMF UEFI, standard VGA (KVM) | `illumosfb`, 1024×768 | `illumosfb`, 1024×768 | US layout kept; Y key gives `y` |
| Native bhyve, pure UEFI | `illumosfb`, 1024×768 | `illumosfb`, 1024×768 | US layout kept; Y key gives `y` |

Virtio GPU / KMS activation was not part of this test.

**About the keyboard.** Some users reported keyboard changes together with
the resolution change. Their cause is still unknown. The tests above only
use a US layout and virtual key presses. This build may not fix keyboard
symptoms, so before-and-after observations of your real layout help a lot.

## Download

From <https://dlc.openindiana.org/isos/hipster/test/xorg-autodetect-20261020/>

| File | Purpose |
| --- | --- |
| `xorg-autodetect-1.19.7-20261020.p5p` | The package archive (2,867,200 bytes) |
| `xorg-autodetect-1.19.7-20261020.p5p.sha256sum` | Its checksum |
| `SHA256SUMS` | Checksums for the kit files (excluding this list) |
| `README.md` | This document |
| `SOURCE-REVISIONS.txt` | Package provenance and test evidence |

SHA-256 of the archive:

```
2f9f8761117bfa75c88c31eccebd01a6112ff490cb66d12b9974a87602e55a0c
```

The archive holds two packages, both for the standard `openindiana.org`
publisher, so no publisher needs to be added:

- `x11/server/xorg@1.19.7-2026.0.0.17:20261019T201107Z`
- `x11/server/xserver-common@1.19.7-2026.0.0.17:20261019T201109Z`

It includes Xorg’s bundled modules, including modesetting. There are no
separate driver packages or kernel packages. It needs a current Hipster system
(OS packages at build 23324 or later). You do not have to check that by
hand: on an older system, the dry run in step 3 stops. In that case update
the system the usual way first, then start again.

## The test, step by step

Plan for about half an hour and two reboots. Back up anything you cannot lose.
This procedure never changes your default boot environment, but it is still
a test of a system component.

Steps marked **as root** need a root shell, for example `sudo -s` on a default
installation. Steps marked **as your user** run in a terminal in your normal
desktop session. Run the commands one block at a time. **If any command
prints an error, stop there** and report what you saw.

### 1. Record how things are now

**As your user**, in your normal desktop session:

```sh
mkdir -p ~/xorg-test/before && cd ~/xorg-test/before
pkg list -v x11/server/xorg > pkg.txt
uname -v > uname.txt
xrandr > xrandr.txt
setxkbmap -query > setxkbmap.txt
ls -l /etc/X11/xorg.conf.d /dev/dri > config.txt 2>&1
grep -i driver /etc/X11/xorg.conf /etc/X11/xorg.conf.d/*.conf > drivers.txt 2>&1
cp /var/log/Xorg.0.log .
```

Also note in words: the screen resolution you get, the resolution you
expect, your keyboard layout, if you use more than one screen which are
on and how they are arranged, and whether typing (for example `y`, `z`,
punctuation, copy and paste) behaves as it should.

In `pkg.txt`, the version should be `1.19.7-2026.0.0.16`. **Stop here** if it
shows `21.1`, or `1.19.7-2026.0.0.17` or later: this kit is not for your
system.

On a default installation your home directory is a separate dataset that
every boot environment sees. If yours is not, or you are not sure, copy
`~/xorg-test` to a USB stick or another machine before each reboot.

Missing `/dev/dri` or Xorg configuration files can leave “not found” messages
in the evidence files; that is useful information, not an install failure.

### 2. Download and verify

**As your user:**

```sh
mkdir -p /var/tmp/xorg-autodetect-test && cd /var/tmp/xorg-autodetect-test
curl -fLO https://dlc.openindiana.org/isos/hipster/test/xorg-autodetect-20261020/xorg-autodetect-1.19.7-20261020.p5p
curl -fLO https://dlc.openindiana.org/isos/hipster/test/xorg-autodetect-20261020/SHA256SUMS
digest -a sha256 xorg-autodetect-1.19.7-20261020.p5p
grep '  xorg-autodetect-1.19.7-20261020.p5p$' SHA256SUMS
```

Both commands must print the checksum shown in the download section above.
If they do not, stop.

### 3. Create the test boot environment and install into it

**As root.** Open one root shell and **stay in it until you reboot in
step 4**. The commands use the shell variables `M` and `TESTBE`, which exist
only in that shell.

First look at your boot environments:

```sh
beadm list
```

Exactly one boot environment should be marked `NR`: it is running now
(`N`) and boots by default (`R`). Write its name down. That is your recovery
boot environment, and nothing below changes it. **Stop** if `N` and `R` are
on different boot environments, or if any boot environment is marked `T`
(another temporary activation is pending).

Now set the two names. Pick a test boot environment name that `beadm list`
does not show yet; the example uses `xorg-autodetect-test-1`.

```sh
M=/mnt/xorg-autodetect-test
TESTBE=xorg-autodetect-test-1
```

Create a fresh mount point, create the boot environment and mount it. Each
command runs only if the previous one succeeded:

```sh
mkdir "$M" &&
beadm create "$TESTBE" &&
beadm mount "$TESTBE" "$M" &&
echo "READY: $TESTBE mounted at $M"
```

If you do not see `READY`, stop and report what you saw. Do not reuse an
existing directory or boot environment name.

Unlock the version of the two Xorg packages **in the mounted test
environment only**:

```sh
pkg -R "$M" change-facet \
    facet.version-lock.x11/server/xorg=false \
    facet.version-lock.x11/server/xserver-common=false
```

Then do a dry run. The dry run installs nothing:

```sh
pkg -R "$M" install -nv --deny-new-be --no-backup-be --no-be-activate \
    -g /var/tmp/xorg-autodetect-test/xorg-autodetect-1.19.7-20261020.p5p \
    'x11/server/xorg@1.19.7-2026.0.0.17:20261019T201107Z' \
    'x11/server/xserver-common@1.19.7-2026.0.0.17:20261019T201109Z'
```

Read the plan. It should **update exactly two packages**, `x11/server/xorg`
and `x11/server/xserver-common`, to `1.19.7-2026.0.0.17`. **Stop here** if
the plan:

- installs or removes any package, or updates anything else (kernel,
  libraries or other OS packages);
- reports a conflict or an error, or says that a constraint or
  incorporation prevents it;
- says there is nothing to do.

Do not work around this with `pkg update`, `--reject`, or by changing other
facets, incorporations or publishers. Report the output instead, then unmount
the test environment and leave it inactive:

```sh
beadm unmount "$TESTBE"
```

If the plan looks right, install with the same options, without `-n`:

```sh
pkg -R "$M" install -v --deny-new-be --no-backup-be --no-be-activate \
    -g /var/tmp/xorg-autodetect-test/xorg-autodetect-1.19.7-20261020.p5p \
    'x11/server/xorg@1.19.7-2026.0.0.17:20261019T201107Z' \
    'x11/server/xserver-common@1.19.7-2026.0.0.17:20261019T201109Z'
pkg -R "$M" list -v x11/server/xorg x11/server/xserver-common
```

Both packages must now show `1.19.7-2026.0.0.17`.

**Only if you use `10-vesa.conf`:** park it, **in the test environment
only**, so the first boot shows the automatic choice. The block refuses to
overwrite an earlier parked copy:

```sh
test ! -e "$M/etc/X11/10-vesa.conf.parked" &&
mv "$M/etc/X11/xorg.conf.d/10-vesa.conf" "$M/etc/X11/10-vesa.conf.parked" &&
echo PARKED
```

Do not continue unless you see `PARKED`; a refused move may print no error.

Leave every other file in `xorg.conf.d` and any `xorg.conf` where it is. If
one of them names a `Driver` (see `drivers.txt` from step 1), Xorg uses that
driver and skips autodetection. That is fine. Mention it in your report
rather than deleting the file.

### 4. Boot the test environment once

**As root**, in the same shell:

```sh
beadm unmount "$TESTBE" &&
beadm activate -t "$TESTBE" &&
beadm list
```

Check the list: your recovery boot environment must still be marked `NR`,
and the test environment must be marked `T` (next boot only). If it does not
look like that, **do not reboot**. Clear the temporary activation, check
again and report what you saw:

```sh
beadm activate -T "$TESTBE"
beadm list
```

If the list looks right, save your work and reboot:

```sh
reboot -p
```

`-p` makes the reboot go through the firmware and boot loader instead of a
fast reboot.

### 5. Record how things are in the test environment

Log in as usual. **Before you change anything**, check the boot environments
**as root**:

```sh
beadm list
```

The test environment should be marked `N` and your recovery boot environment
`R`. If `R` is not on your recovery boot environment, stop and report it
before rebooting. Write the list into your report.

Then, **as your user**, repeat step 1 into a new directory:

```sh
mkdir -p ~/xorg-test/after && cd ~/xorg-test/after
pkg list -v x11/server/xorg > pkg.txt
uname -v > uname.txt
xrandr > xrandr.txt
setxkbmap -query > setxkbmap.txt
ls -l /etc/X11/xorg.conf.d /dev/dri > config.txt 2>&1
grep -i driver /etc/X11/xorg.conf /etc/X11/xorg.conf.d/*.conf > drivers.txt 2>&1
cp /var/log/Xorg.0.log .
grep 'illumos framebuffer' Xorg.0.log
```

On a machine with a legacy video BIOS, the last command should print:

```
illumos framebuffer: legacy video BIOS present; retaining vesa
```

On a pure UEFI machine with no legacy video BIOS, it should print:

```
illumos framebuffer: legacy video BIOS absent; using illumosfb fallback
```

If a configuration file names a driver, or a KMS driver is active, the check
is skipped and the command may print nothing.

Note the resolution, screen arrangement and keyboard behaviour again, in the
same words as before.

### 6. Optional: compare with `10-vesa.conf`

Only if you parked `10-vesa.conf` in step 3, and not if step 5 printed
`legacy video BIOS absent` (`vesa` cannot work without a video BIOS).

**As root**, in the running test environment, put the file back. Then
restart the login screen. This ends your desktop session, so save your work
first.

```sh
test ! -e /etc/X11/xorg.conf.d/10-vesa.conf &&
mv /etc/X11/10-vesa.conf.parked /etc/X11/xorg.conf.d/10-vesa.conf &&
echo RESTORED
```

Do not restart LightDM unless you see `RESTORED`.

```sh
svcadm restart lightdm
```

Log in again and record a third set into `~/xorg-test/vesa-conf` with the
commands from step 5.

## Return to your normal system

**As root**, reboot. Because the activation was temporary, the machine boots back into
your recovery boot environment. Do not activate the test environment again
for a second boot.

```sh
reboot -p
```

Confirm with `beadm list` (as root) that your recovery boot environment is
marked `NR` again. The test environment stays on disk, inactive. Please keep
it for follow-up questions. It only costs disk space, and you can remove it
later with `beadm destroy` once you no longer need it.

**If the test environment does not come up**, for example with a black
screen or a hung login, just reset the machine. The next boot uses your
recovery boot environment. You can also choose a boot environment from the
boot loader's *Boot Environments* menu.

## Reporting

Please comment on
[oi-userland#27965](https://github.com/OpenIndiana/oi-userland/pull/27965).
If you have the HP EliteBook 820 G2, please also add your results to
[Redmine #18500](https://www.illumos.org/issues/18500).

Include:

- [ ] Machine model and graphics hardware (`prtconf -d | grep -i display` may help)
- [ ] Firmware mode: BIOS, UEFI with CSM, or pure UEFI
- [ ] Whether a KMS driver was active (`/dev/dri` in `config.txt`)
- [ ] Driver and resolution **before** and **after** (from `Xorg.0.log` and `xrandr.txt`)
- [ ] The `illumos framebuffer:` line from step 5, or that there was none
- [ ] Keyboard layout and typing behaviour before and after (`setxkbmap.txt` plus your own words)
- [ ] `drivers.txt`, the files in `xorg.conf.d`, and whether you ran the `10-vesa.conf` comparison
- [ ] `beadm list` output from steps 4 and 5
- [ ] The dry-run output from step 3 if it did not look as expected
- [ ] The `before/` and `after/` directories, attached or linked (the Xorg logs are the most useful part)

A report saying "it worked, nothing changed" is useful too, especially from
pure UEFI and KMS machines.