Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

SVGA support aside, it will never cease to astound me that you can load Windows 3.x on a modern standards-supporting PC and get basic VGA working out-of-the-box but you cannot do the same on modern Linux/BSD to get a basic software-accelerated VGA framebuffer supported by Xorg/Wayland if you don't have the right drivers installed (and the correct configuration files manually set up).

(the dead xfree86 project was probably the closest attempt to making this "just work" though it had a long way to go; this approach was not preserved in the Xorg fork)

View on HN

Xfree86 never did anything different to Xorg here. If you boot via CSM on a modern PC (which is really not something you should do, but, well) you should get Xorg running with the VBE backend using x86emu to execute the video BIOS, and if you boot via EFI you should get modesetting running on top of efifb using whatever mode your firmware and bootloader left you in.

But note that this is actually easier for 16 or 32 bit operating systems! Setting VESA modes involves making a real mode 16 bit call (there's nominally a 32 bit entry point for VESA but it was specced late in the standard's life and basically nobody implements a working version), and once you're running in 64-bit mode you've lost the ability to do vm86 so calling 16 bit code from userland becomes impossible. This is why x86emu is required (basically we read the video BIOS code and then run it under an x86 emulator), and it's not always perfect.

I just wanna say that "we read the video BIOS code and then run it under an x86 emulator" sounds like some truly heroic effort by a bunch of engineers and I'm glad they did the work. I hope the people involved are proud of it.

IIRC, the reason it needed to be a VM in the first place was because X (simplifying a bit) "started" at Sun, running on PowerPC boxen. (Here's another subthread mentioning the same thing - https://news.ycombinator.com/item?id=42597613)

I agree it was an engineering marvel, IMO only less impressive than the CPU implemented in JPEG instructions for Pegasus.

X was originally an MIT development, and had no intrinsic ties to the underlying hardware (Sun implemented something called NeWS which ended up losing to X in the long run). Different vendors took the reference code and added device specific code to work, but this was an era where your hardware vendor was also your OS vendor so that was fairly transparent for most users. At this point almost every CPU architecture had their own expansion bus so there wasn't really any way you could plug a card intended for one machine into another. The vendor X server worked just fine.

And then PCI became ubiquitous and it was much cheaper to plug a PC card into a machine than buy an overpriced one from Sun or DEC or whatever, and people were starting to run Linux or *BSD instead of the vendor OS, and suddenly there was an incentive to be able to run graphics card x86 init code even on other CPU architectures.

I ended up stealing the concept and the code to make Ubuntu's usplash boot splash app work on 64-bit, which is an entirely different story.

> X (simplifying a bit) "started" at Sun, running on PowerPC boxen.

It didn’t. The X Windows system (https://en.wikipedia.org/wiki/X_Window_System) started at MIT and is from 1984, PowerPC (https://en.wikipedia.org/wiki/PowerPC) from 1992.

Wrong on both accounts, neither Sun nor PowerPC were relevant to X Windows appearance into computing world.

Windows NT did this too. And it was the work of one engineer. (although that engineer was Dave Cutler…)

Linux supports vgafb/vesafb so this is possible if the distribution is configured appropriately.

I think some/most distributions might not enable it out of the box because it would generally result in a low performance/quality experience and the user not realizing what the problem is, and nowadays almost all GPUs are supported natively, so nobody has invested in writing code to show a "Using unaccelerated VGA/VESA, you may want to fix this" popup.

It's been a very long time, but I recall X having a generic VGA driver that "just worked". Are you saying that's not there anymore?

Not only that, I remember X.org source tree had a bult-in x86 emulator so VGA bios of some PCI video cards could be run on Solaris.

Technically not related to Solaris, since Solaris x86 existed and you wouldn't need it there, but yes, this was used on Sparc and any other CPU unable to run the card BIOS (including 64-bit x86 Linux, since virtual 8086 mode goes away when you're on long mode)

I remember the "generic" VGA driver having horrible default settings that resulted in 300x200 at 16 colors.

320x200 at 256 colors. X doesn't support any depth lower than 8bit, so VGA 640x480 wouldn't work.

I remember that Xfree86 allowed 1 bit (B&W) modes

X does, modern X apps may not.

X absolutely supports depths of 1 and 4 bits per pixel, along with 8bpp, with its VGA server: https://www.xfree86.org/4.8.0/vga.4.html

Thanks for the correction.

I hadn't thought of 1bpp because it isn't interesting on VGA hardware. But you're absolutely right about 4bpp having been a thing.

I just had a look at the install of ancient NetBSD I have running on my Pocket386, and the X server in there (which is XFree86 3.x) does have a generic VGA driver that does 640x480 at 16 colors just fine. I'm not sure what the "default settings" would be in this context since X that old doesn't even start without a proper XF86Config.

Old would mean mid-90s XFree86.

That's exactly what I'm talking about here, as well. NetBSD 1.2 is from 1996.

Generic VGA doesn't generally exist on EFI platforms, the firmware doesn't program the card into a state where the VGA registers are going to do anything useful. You should get a working unaccelerated framebuffer from the firmware, though.

X11 has a "VESA" driver since forever, however its performance scales badly since number of pixels to process grows rapidly with the resolution.

Bootable Linux distributions I use at work (GRML and Clonezilla mainly) automatically resize to the native resolution of the screen or virtual KVM during boot with KMS support, and they work really well. Anaconda (RedHat and derivatives' installer) and Debian's installer also scales to native resolution on boot.

GUI installers use VESA over X11 directly.

> xfree86 project was probably the closest attempt to making this "just work"...

XOrg fork has "configless boot" for a long time. I don't maintain a config file for a very long time now, and I'm happier than ever (see https://www.xkcd.com/963/).

Xorg is Xfree86 with a cleaned up build system.

Xorg is a fork of XFree86 with many, many changes. Some XFree86 code is retained as one possible backend.

One of the most user visible things they did, though, was make it work better if you didn't have a config file.

The fun of manually writing modfiles and hoping for the best with startx.

> One of the most user visible things they did, though, was make it work better if you didn't have a config file.

Most of the times. On my new Ryzen, it didn't.

It's specialization. Windows 3.x runs with a GUI on an IBM PC. XFree86-era Linux runs with any UI on an IBM PC. Xorg-era Linux runs with any UI on any computer. Therefore you have to specify what kind of configuration you require, and don't get it out of the box. But note that every distribution that runs on IBM PCs with a VGA GUI does come with that configuration out of the box, because they are re-specialized for that system.

And Wayland requires a GPU as far as I know, since the entire protocol is based on passing GPU memory buffers around and compositing then. Deleting the backwards compatibility for software rendering was half the point of creating Wayland.

Wayland does not require a GPU and the baseline protocol is just shared memory buffers. The protocol requires file descriptor for said buffers and getting gpu drivers to support mapping gpu memory to file descriptors is what allowed Wayland to become efficient through zero copy and just passing handles from clients to compositors

The Wayland base protocol is completely unusable since it does nothing by itself. Doing useful work with Wayland requires more stuff, like a GPU driver.

It requires a GPU in the same sense that windows 3.1 or dos or whatever else requires a GPU to convert the contents of a memory buffer to a signal that a display can actually display.

But you can also just encode the result of your composition to a h264 stream and send that over the network if you so desire. no GPU required in this case.

> The simplest means of getting pixels from client to compositor, and the only one enshrined in wayland.xml, is wl_shm — shared memory. Simply put, it allows you to transfer a file descriptor for the compositor to mmap with MAP_SHARED, then share pixel buffers out of this pool. Add some simple synchronization primitives to keep everyone from fighting over each buffer, and you have a workable — and portable — solution.

https://wayland-book.com/surfaces/shared-memory.html

> [weston] Available back-ends:

> drm – run stand-alone on DRM/KMS and evdev (recommend) (DRM kernel doc)

> wayland – run as a Wayland application, nested in another Wayland compositor instance

> x11 – run as a x11 application, nested in a X11 display server instance

> rdp – run as an RDP server without local input or output

> headless – run without input or output, useful for test suite

> pipewire – run without input, output into a PipeWire node

https://wayland.pages.freedesktop.org/weston/toc/running-wes...

Reply on news.ycombinator.com