3 ms·

So can we revive any of these also abandoned alternatives? * Tiny X (Still Xorg just barebones and faster) - https://github.com/tinycorelinux/tinyx https://git

So can we revive any of these also abandoned alternatives? * Tiny X (Still Xorg just barebones and faster) - https://github.com/tinycorelinux/tinyx https://github.com/tinycorelinux/tinyx * Xynth - https://github.com/alperakcan/xynth https://github.com/alperakcan/xynth * Nano-X / MicroWindows - http://microwindows.org/ http://microwindows.org/ (Seems still active? Just needs some modern GUI ports.) * DirectFB (Needs modern driver support) - https://web.archive.org/web/20120118003245/http://www.directfb.org/ https://web.archive.org/web/20120118003245/http://www.direct... * SVGALib (Needs modern driver support) - https://github.com/akosela/svgalib https://github.com/akosela/svgalib * FBUI (Needs porting to modern kernels) - https://github.com/8l/fbui https://github.com/8l/fbui

moonchild 6y ago
> Tiny X Probably not, because: > Design choices [...] no gl
pengaru 6y ago
You left out GGI/KGI. But most of this stuff is basically irrelevant in a post-KMS/DRM linux world. So few apps were ever written targeting directfb and libggi it's as if they never existed. SVGAlib apps frequently performed direct hardware access requiring root and disrupting graphics hardware state WRT other graphical apps like X or fb. Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA. For such apps where source is available, it's better to just port to something like SDL.
- anthk 6y ago
  I think directdb stuff is KMS/DRM compatible. Mplayer on the fbdev2 driver works perfectly. So is DirectFB Links. >Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA. Or a wrapper trapping SVGAlib calls to SDL/SDL2.
  - pengaru 6y ago
    > Or a wrapper trapping SVGAlib calls to SDL/SDL2. That works for programs limiting their operations to SVGAlib calls. As I mentioned, but you omitted in the citation: > SVGAlib apps frequently performed direct hardware access requiring root ... How do you trap those directly accessing VGA IO ports via inb/outb instructions? I clearly recall writing modex routines in assembly for SVGAlib demos, and I'm pretty sure I wasn't the only ex-DOS graphics coder doing that to make things happen on Linux in the 90s.
    - anthk 6y ago
      If X.org has an X86 BIOS emulator for weird systems, an SDL2 SVGALIB trap could do those pretty fast.

moonchild 6y ago

> Tiny X Probably not, because: > Design choices [...] no gl

pengaru 6y ago

You left out GGI/KGI. But most of this stuff is basically irrelevant in a post-KMS/DRM linux world. So few apps were ever written targeting directfb and libggi it's as if they never existed. SVGAlib apps frequently performed direct hardware access requiring root and disrupting graphics hardware state WRT other graphical apps like X or fb. Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA. For such apps where source is available, it's better to just port to something like SDL.

anthk 6y ago
I think directdb stuff is KMS/DRM compatible. Mplayer on the fbdev2 driver works perfectly. So is DirectFB Links. >Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA. Or a wrapper trapping SVGAlib calls to SDL/SDL2.
- pengaru 6y ago
  > Or a wrapper trapping SVGAlib calls to SDL/SDL2. That works for programs limiting their operations to SVGAlib calls. As I mentioned, but you omitted in the citation: > SVGAlib apps frequently performed direct hardware access requiring root ... How do you trap those directly accessing VGA IO ports via inb/outb instructions? I clearly recall writing modex routines in assembly for SVGAlib demos, and I'm pretty sure I wasn't the only ex-DOS graphics coder doing that to make things happen on Linux in the 90s.
  - anthk 6y ago
    If X.org has an X86 BIOS emulator for weird systems, an SDL2 SVGALIB trap could do those pretty fast.