General improvements to XConfig (Focused on FB drivers and QEMU/KVM).

[b-aaz]

l'm creating this PR for general improvements and fixes to XConfig after my interactions with user's issues and reading the script.
The first problem was the issues users faced on QEMU, which was caused by XConfig defaulting to the QXL/SPICE driver that has known issues and crashes on both X.Org/XLibre and on Linux/BSD..., until that is solved by either upstream XConfig should default to the frame-buffer derives.

Next, XConfig uses an odd algorithm when using / falling back to FB drivers (VESA, SCFB).
So this is how VESA and SCFB should be chosen:

VESA: Should be chosen when the system has booted in legacy BIOS mode / has not access to the EFI FB through VT, it should be never force enabled when a kernel KMS driver is loaded (Would cause an irrecoverable black screen in that scenario).
SCFB: Should be chosen when the system has booted in UEFI mode and has access to the EFI FB.

When these drivers are installed, the X server automatically arbitrates between the two, if the system is booted in either UEFI or BIOS modes, so instead of force enabling only the SCFB driver, when no other driver is found, the script should instead keep both of the *-vesa-* and *-scfb-* drivers and let the server choose what it finds fit.

I have already applied this change for the setup_scfb / setup_vesa options and distilled them into setup_fb, but I think this should be applied for the bhyve/hyperv/safe options too, in all these cases the system can be booted both in BIOS/UEFI* mode so both VESA and SCFB drivers should be available for the server to choose from. A dedicated config is not needed in these cases. and the ones provided actually do more harm my limiting the available resolutions and modes.

• BHyve is currently only limited to UEFI because of a depricated firmware, but that firmware could get added back in the future.

Some other misc points I found:

1. The /xdrivers directory can be turned into a local repository with pkg repo during the image generation and added to the pkg repo configuration with a file:/// URI and disabled by default, this would simplify the script and for installing packages from /xdrivers it could simply been enabled when doing pkg install with the -r flag.
2. pkg-static might be a better choice in this script in place of pkg
3. The NVIDIA 304 driver support should be removed since it has been deprecated and broken for a long time.
4. Grouping all the pkg remove actions in a single call of pkg can speed up the deletion by removing the pkg invocation overhead. This can be done by adding the packages to be removed to a string and then "committing" the removal of them with a single call of pkg.
5. For input, choosing libinput should be an one solution fits all, so the mouse, kbd and evdev drivers can probably be removed from the equation altogether.

Summary by Sourcery

Improve XConfig’s default graphics configuration and cleanup legacy driver handling.

New Features:

• Unify framebuffer driver setup so XConfig exposes both VESA and SCFB for environments that can boot via BIOS or UEFI.
• Adjust XConfig’s defaults to favor framebuffer drivers over problematic QXL/SPICE on virtualized setups like QEMU/KVM.

Bug Fixes:

• Resolve crashes on QEMU and similar environments by no longer defaulting to the unstable QXL/SPICE driver.
• Fix incorrect framebuffer driver fallback logic so VESA is not forced when kernel KMS drivers are active and SCFB is used appropriately on UEFI systems.

Enhancements:

• Simplify GPU driver configuration by removing deprecated and broken NVIDIA 304 support and related SCFB-specific config.
• Streamline package management in XConfig by preferring pkg-static and consolidating package removals to reduce overhead.
• Prepare for using a local /xdrivers pkg repository and simplify input handling by standardizing on libinput instead of legacy mouse/kbd/evdev drivers.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Refactors XConfig’s graphics configuration to prefer safer framebuffer-based drivers (SCFB/VESA) instead of QXL/SPICE on virtualized setups, unifies framebuffer setup handling across presets, and cleans up package/input driver management, including removal of deprecated NVIDIA 304 support.

File-Level Changes

Change	Details	Files
Refactor framebuffer driver selection to avoid QXL/SPICE defaults and let Xorg arbitrate between SCFB and VESA across physical and virtual environments (including bhyve/hyperv/safe presets).	Change default driver logic in the main XConfig script to stop preferring QXL/SPICE on QEMU/KVM and instead fall back to framebuffer drivers Unify setup_scfb and setup_vesa into a single setup_fb path that installs/enables both SCFB and VESA so Xorg can choose based on BIOS vs UEFI/EFI framebuffer availability Apply the unified framebuffer selection logic to additional presets (bhyve/hyperv/safe) so they no longer force a single FB driver or overly restrictive modes Remove the dedicated SCFB-only configuration file and rely on server-side arbitration between SCFB and VESA	bin/xconfig cardDetect/XF86Config.scfb
Simplify and harden X-related package management, including support for a local /xdrivers repo, pkg-static usage, and batched removals.	Adjust package installation to be compatible with turning /xdrivers into a local pkg repository (file:/// URI, disabled by default, selectively enabled via -r) Prefer pkg-static over pkg for installation/removal operations in the script for more robust usage in constrained environments Batch package removals into a single pkg invocation by collecting targets into one command to reduce process startup overhead	bin/xconfig
Clean up deprecated or legacy driver configuration, including NVIDIA 304 and legacy input drivers, in favor of libinput-only setups where possible.	Remove or stop configuring support for the deprecated and broken NVIDIA 304 driver series Standardize on libinput for input handling and drop explicit configuration/installation of legacy mouse, kbd, and evdev input drivers where they are no longer needed	bin/xconfig

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[ericbsd]

Some other misc points I found:

1. The /xdrivers directory can be turned into a local repository with pkg repo during the image generation and added to the pkg repo configuration with a file:/// URI and disabled by default, this would simplify the script and for installing packages from /xdrivers it could simply been enabled when doing pkg install with the -r flag.

This would probably need modification in ghostbsd-build.

2. pkg-static might be a better choice in this script in place of pkg

Yes, this is a good idea.

3. The NVIDIA 304 driver support should be removed since it has been deprecated and broken for a long time.

I did remove it from ghostbsd-build. I might have forgotten to remove it here. Yes it can be remove.

4. Grouping all the pkg remove actions in a single call of pkg can speed up the deletion by removing the pkg invocation overhead. This can be done by adding the packages to be removed to a string and then "committing" the removal of them with a single call of pkg.

That too is a good idea.

5. For input, choosing libinput should be a one solution fits all, so the mouse, kbd, and evdev drivers can probably be removed from the equation altogether.

I thought we did need evdev for touch screens. Is it not the case anymore?

[sourcery-ai]

Hey - I've left some high level feedback:

• Now that SCFB/VESA configuration is unified, check for and simplify any remaining code paths or options that still assume separate setup_scfb/setup_vesa behavior so the logic is consistently single-sourced.
• When switching to framebuffer defaults on QEMU/KVM, ensure the selection logic is based on runtime capability detection (e.g., EFI vs legacy and presence of KMS) rather than only hypervisor presets so that physical hardware and other hypervisors aren’t unintentionally forced into suboptimal drivers.
• If you standardize on pkg-static and local /xdrivers repos, consider centralizing all package install/remove calls in one helper so that future changes to the repo URI or pkg tool only need to be updated in a single place.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Now that SCFB/VESA configuration is unified, check for and simplify any remaining code paths or options that still assume separate `setup_scfb`/`setup_vesa` behavior so the logic is consistently single-sourced.
- When switching to framebuffer defaults on QEMU/KVM, ensure the selection logic is based on runtime capability detection (e.g., EFI vs legacy and presence of KMS) rather than only hypervisor presets so that physical hardware and other hypervisors aren’t unintentionally forced into suboptimal drivers.
- If you standardize on `pkg-static` and local `/xdrivers` repos, consider centralizing all package install/remove calls in one helper so that future changes to the repo URI or pkg tool only need to be updated in a single place.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}