Xorg 1.19.7 driver autodetection

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.

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.

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 dlc.openindiana.org/isos/hipster/test/xorg-autodetect-20261020/

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

In your normal desktop session:

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

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. If they do not, stop.

3. Create the test boot environment and install into it

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:

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.

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:

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:

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:

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'

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

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:

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

In the same shell:

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).

beadm activate -T "$TESTBE"
beadm list

If the list looks right, save your work and reboot. -p makes the reboot go through the firmware and boot loader instead of a fast reboot.

reboot -p

5. Record how things are in the test environment

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

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 repeat step 1 into a new directory:

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).

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

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.

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

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.

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.

Reporting

Please comment on oi-userland#27965. If you have the HP EliteBook 820 G2, please also add your results to Redmine #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.