5 ms·

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

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)

kevin_thibedeau 2y ago
Xorg is Xfree86 with a cleaned up build system.
- immibis 2y ago
  Xorg is a fork of XFree86 with many, many changes. Some XFree86 code is retained as one possible backend.
- asveikau 2y ago
  One of the most user visible things they did, though, was make it work better if you didn't have a config file.
  - pjmlp 2y ago
    The fun of manually writing modfiles and hoping for the best with startx.
  - hulitu 2y ago
    > 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.
immibis 2y ago
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.
- heeen2 2y ago
  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
  - immibis 2y ago
    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.
    - heeen2 2y ago
      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 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-weston.html https://wayland.pages.freedesktop.org/weston/toc/running-wes...
devit 2y ago
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.
mjg59 2y ago
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.
- kevingadd 2y ago
  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.
  - exikyut 2y ago
    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 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.
    - mjg59 2y ago
      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.
int_19h 2y ago
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?
- marcodiego 2y ago
  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.
  - mjg59 2y ago
    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)
- ok123456 2y ago
  I remember the "generic" VGA driver having horrible default settings that resulted in 300x200 at 16 colors.
  - kijiki 2y ago
    320x200 at 256 colors. X doesn't support any depth lower than 8bit, so VGA 640x480 wouldn't work.
    - mjg59 2y ago
      X does, modern X apps may not.
    - Zardoz84 2y ago
      I remember that Xfree86 allowed 1 bit (B&W) modes
    - maximilianburke 2y ago
      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 https://www.xfree86.org/4.8.0/vga.4.html
devops99 2y ago
[dead]
bayindirh 2y ago
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/ https://www.xkcd.com/963/).

kevin_thibedeau 2y ago

Xorg is Xfree86 with a cleaned up build system.

immibis 2y ago
Xorg is a fork of XFree86 with many, many changes. Some XFree86 code is retained as one possible backend.
asveikau 2y ago
One of the most user visible things they did, though, was make it work better if you didn't have a config file.
- pjmlp 2y ago
  The fun of manually writing modfiles and hoping for the best with startx.
- hulitu 2y ago
  > 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.

immibis 2y ago

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.

heeen2 2y ago
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
- immibis 2y ago
  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.
  - heeen2 2y ago
    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 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-weston.html https://wayland.pages.freedesktop.org/weston/toc/running-wes...

devit 2y ago

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.

mjg59 2y ago

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.

kevingadd 2y ago
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.
- exikyut 2y ago
  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 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.
  - mjg59 2y ago
    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.

int_19h 2y ago

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?

marcodiego 2y ago
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.
- mjg59 2y ago
  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)
ok123456 2y ago
I remember the "generic" VGA driver having horrible default settings that resulted in 300x200 at 16 colors.
- kijiki 2y ago
  320x200 at 256 colors. X doesn't support any depth lower than 8bit, so VGA 640x480 wouldn't work.
  - mjg59 2y ago
    X does, modern X apps may not.
  - Zardoz84 2y ago
    I remember that Xfree86 allowed 1 bit (B&W) modes
  - maximilianburke 2y ago
    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 https://www.xfree86.org/4.8.0/vga.4.html

devops99 2y ago

[dead]

bayindirh 2y ago

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/ https://www.xkcd.com/963/).