5 ms·

Tinyx – Resurrected Xvesa from the depths of Git history

peter_d_sherman 3y ago
Related: Low-level VESA/VGA routines: https://github.com/tinycorelinux/tinyx/tree/master/kdrive/vesa https://github.com/tinycorelinux/tinyx/tree/master/kdrive/ve...
rkeene2 3y ago
I had more luck with KDrive for a minimal but functional X server (for an OS installer in my case).
HeckFeck 3y ago
Is this any relation to Nano-X? http://microwindows.org/ http://microwindows.org/
- oso2k 3y ago
  No. TinyX is an XServer, it only talks to VESA compatible graphics hardware and provides an X11 interface. It's intended for PCs. Nano-X is a graphics library that can talk to frame buffers, graphics hardware, or an XServer and can provide some level of X11 interface as well as a Win32 API. It's intended for embedded machines.
  - vidarh 3y ago
    It's also provides a standalone graphics server, not just a library. I used it for a bit 25 years ago when we were using it as the GUI for a Linux based tablet because X took too much memory...
    - oso2k 3y ago
      Does it provide a graphics server in the absence of all the X11 foundation libs? TBH, I've only played with microwindows in DOS, OSX with XQuartz, and Linux with X11.
      - vidarh 3y ago
        Yes. With the caveat that my knowledge of Nano-X is about 20 years out of date: It very specifically is not X, though the API is close to the Xlib API, and there's a shim that provides some X11 compatibility, and of course on the backend there's an X11 driver. But it only requires a driver that can handle a minimum of reading/setting individual pixels and draw horizontal and vertical lines and manage the palette (of course if whatever you're drawing on supports more than that, you'll get far better performance if you implement e.g. blits). We were using it without any shims, and had a very tiny GUI lib running directly against the Nano-X API, and contracted Opera to port their browser to it as well to use on our tablet. It was a fun project, but way too early - the hardware we built was beautiful but so extremely constrained, leading to put a huge effort into shrinking everything. Never made it to mass production.
- peter_d_sherman 3y ago
  Interesting link! If we look at this directory: https://github.com/ghaerr/microwindows/tree/master/src/drivers https://github.com/ghaerr/microwindows/tree/master/src/drive... Most notably the source files that start with 'scr_', and of those most notably: scr_sdl2.c, scr_win32.c, scr_x11.c, scr_djvesa.c, scr_fb.c -- we see that this windowing system can apparently run on top of an existing windowing system, whether that system is SDL2, Win32, X11, VESA, Linux's framebuffer -- or several others. Which makes it interesting and worthy of study... Note that I am sure there are probably a whole lot of other windowing systems out there that also support these, let's call them "back-end" (for lack of better terminology) pre-existing windowing systems. In other words, a windowing system -- on top of another windowing system... Sort of like running X on top of Win32, or Win32 on top X... But the posibilities of higher level and lower level windowing system are really unlimited -- mix and match, basically... In conclusion -- excellent link!
  - oso2k 3y ago
    Also works on DOS w/djgpp.
hkt 3y ago
I came across this recently while looking at buildroot and tinycorelinux. I'm still working on it but tinyX+awesome is my target for a kind of minimum-viable-system. I love software that I can conceivably learn enough about to contribute to without giving up my life, and tinyX (and awesome) both tick those boxes. As a broader observation, it is encouraging to see things like this on HN as my (perhaps flawed) assumption is that generally small software is efficient software. I for one have had enough of my UX standing still because of code sprawl, and I wish we could get back to a time when a few hundred MHz or less was enough for most things.
- pengaru 3y ago
  > I wish we could get back to a time when a few hundred MHz or less was enough for most things. Modern display resolutions and color depths alone are responsible for a huge part of why that's no longer the case. And most people aren't interested in giving that up...
  - makapuf 3y ago
    Sure I like nice hidpi antialiased, slightly shadowed buttons with translucency, but I kind of like pixel embracing UIs (nice pixel fonts with no AA are quite legible to me). I'm on and off on writing a tiny 4 colors desktop with simple remote abilities..
snvzz 3y ago
Not a fan of the license change. Deliberately making the software less useful drains the preservation value the project would otherwise provide.
- LoganDark 3y ago
  > Deliberately making the software less useful Well, I'm sure you'll be happy to find that GPL3 does not make any software any less useful. It just means that if you want to extend the software, you must distribute source code with it. Any entity which finds this unacceptable doesn't deserve to be using this software anyway. It becomes more useful because it encourages people to distribute source code that they may not have otherwise.
  - altairprime 3y ago
    > if you want to extend the software, you must distribute source code with it Incorrect. GPLv3 does not require source code distribution if you choose to only distribute your extensions to third parties that are under a current contract to you to operate or modify the work or any derivative thereof on your behalf and to destroy all copies of your extensions at the conclusion of the contracted operational and/or modification work. I’m surprised that $1 modification contracts for GPLv3 works are uncommon. Open source isn’t free! (I am not your lawyer, this is not legal advice.)
    - TeMPOraL 3y ago
      Isn't this how using GPL-ed code in commercial contexts work? You don't have to share sources with the outsiders if you don't ship the program to the outsiders - and your employees and contractors are bound by their contracts to share neither the proprietary extensions nor the resulting program with the outside world. Note that SaaS means you're not shipping backend software to users, which created a loophole that has a special GPL variant patching it.
      - davorak 3y ago
        altairprime's idea seems to be to sell the software to your users, but hire them as contractors to modify the gpl code so they can not redistribute it themselves. So on perm saas where the on perm operators are technical hired for $1 so the software was never legally distributed to the company that hired the on perm saas service. Seems dubious to me.
stefanos82 3y ago
Oh my, you've just brought up some amazing memories from my past time as systems administrator! I would setup SliTaz [1] on some ancient hardware and worked right out of the box with very little RAM. I have had so much fun using this distro! Here's the link where you can read about xvesa support in SliTaz: https://doc.slitaz.org/en:guides:xorg-xvesa https://doc.slitaz.org/en:guides:xorg-xvesa [1] https://slitaz.org/en/ https://slitaz.org/en/
- ang_cire 3y ago
  Damn, slitaz... That's a blast from the past. Right next to bb4win and openshell in my childhood OS explorations.
  - stefanos82 3y ago
    Indeed a blast from the past, well said @ang_cire!
yjftsjthsd-h 3y ago
> no xkb; it's bloat when console keymaps suffice So on the pro side, that sounds like you could just configure your keyboard layout once and have it work everywhere, which would be nice. On the con side, I'm not aware of a way to switch console keymaps on the fly; setxkbmap lets me configure a hotkey that switches layouts instantly, which is really handy. Or am I misunderstanding the impact?
- lotharcable 3y ago
  Ideally you'd have a programmable keyboard. That way it keeps the OS configuration down to a absolute minimum. It is just easier that way. Especially if you want to use multiple OSes and such things.
  - yjftsjthsd-h 3y ago
    Well yes, ideally I would prefer to be able to implement things in firmware (especially chording), but since I mostly use laptops I'm a bit stuck. And yes, I can probably use things like keyd to work around it, but it seems a bit unreasonable to require that level of mucking around in order to switch keyboard layouts.
  - deleted 3y ago
    [deleted]
- vidarh 3y ago
  That'd be a non-starter to me. I switch between US and Norwegian layouts depending on which language I'm writing, and while I could "just" map the additional Norwegian characters to other combinations, I don't want to.
anthk 3y ago
If this worked under MirBSD it could resurrect some 386 and 486's. Also, there's is a pocketchip-like computer based on a 486 sx I think. http://www.mirbsd.org/ http://www.mirbsd.org/
badsectoracula 3y ago
Sounds neat but wouldn't using DRM be better than fbdev nowadays? AFAIK (from having played around with DRM recently-ish and with fbdev years ago) it should be possible to abstract the "get a framebuffer" part (IIRC fbdev didn't have much of an API and all of it can be mapped to DRM).

Related: Low-level VESA/VGA routines: https://github.com/tinycorelinux/tinyx/tree/master/kdrive/vesa https://github.com/tinycorelinux/tinyx/tree/master/kdrive/ve...

rkeene2 3y ago

I had more luck with KDrive for a minimal but functional X server (for an OS installer in my case).

HeckFeck 3y ago

Is this any relation to Nano-X? http://microwindows.org/ http://microwindows.org/

oso2k 3y ago
No. TinyX is an XServer, it only talks to VESA compatible graphics hardware and provides an X11 interface. It's intended for PCs. Nano-X is a graphics library that can talk to frame buffers, graphics hardware, or an XServer and can provide some level of X11 interface as well as a Win32 API. It's intended for embedded machines.
- vidarh 3y ago
  It's also provides a standalone graphics server, not just a library. I used it for a bit 25 years ago when we were using it as the GUI for a Linux based tablet because X took too much memory...
  - oso2k 3y ago
    Does it provide a graphics server in the absence of all the X11 foundation libs? TBH, I've only played with microwindows in DOS, OSX with XQuartz, and Linux with X11.
    - vidarh 3y ago
      Yes. With the caveat that my knowledge of Nano-X is about 20 years out of date: It very specifically is not X, though the API is close to the Xlib API, and there's a shim that provides some X11 compatibility, and of course on the backend there's an X11 driver. But it only requires a driver that can handle a minimum of reading/setting individual pixels and draw horizontal and vertical lines and manage the palette (of course if whatever you're drawing on supports more than that, you'll get far better performance if you implement e.g. blits). We were using it without any shims, and had a very tiny GUI lib running directly against the Nano-X API, and contracted Opera to port their browser to it as well to use on our tablet. It was a fun project, but way too early - the hardware we built was beautiful but so extremely constrained, leading to put a huge effort into shrinking everything. Never made it to mass production.
peter_d_sherman 3y ago
Interesting link! If we look at this directory: https://github.com/ghaerr/microwindows/tree/master/src/drivers https://github.com/ghaerr/microwindows/tree/master/src/drive... Most notably the source files that start with 'scr_', and of those most notably: scr_sdl2.c, scr_win32.c, scr_x11.c, scr_djvesa.c, scr_fb.c -- we see that this windowing system can apparently run on top of an existing windowing system, whether that system is SDL2, Win32, X11, VESA, Linux's framebuffer -- or several others. Which makes it interesting and worthy of study... Note that I am sure there are probably a whole lot of other windowing systems out there that also support these, let's call them "back-end" (for lack of better terminology) pre-existing windowing systems. In other words, a windowing system -- on top of another windowing system... Sort of like running X on top of Win32, or Win32 on top X... But the posibilities of higher level and lower level windowing system are really unlimited -- mix and match, basically... In conclusion -- excellent link!
- oso2k 3y ago
  Also works on DOS w/djgpp.

hkt 3y ago

I came across this recently while looking at buildroot and tinycorelinux. I'm still working on it but tinyX+awesome is my target for a kind of minimum-viable-system. I love software that I can conceivably learn enough about to contribute to without giving up my life, and tinyX (and awesome) both tick those boxes. As a broader observation, it is encouraging to see things like this on HN as my (perhaps flawed) assumption is that generally small software is efficient software. I for one have had enough of my UX standing still because of code sprawl, and I wish we could get back to a time when a few hundred MHz or less was enough for most things.

pengaru 3y ago
> I wish we could get back to a time when a few hundred MHz or less was enough for most things. Modern display resolutions and color depths alone are responsible for a huge part of why that's no longer the case. And most people aren't interested in giving that up...
- makapuf 3y ago
  Sure I like nice hidpi antialiased, slightly shadowed buttons with translucency, but I kind of like pixel embracing UIs (nice pixel fonts with no AA are quite legible to me). I'm on and off on writing a tiny 4 colors desktop with simple remote abilities..

snvzz 3y ago

Not a fan of the license change. Deliberately making the software less useful drains the preservation value the project would otherwise provide.

LoganDark 3y ago
> Deliberately making the software less useful Well, I'm sure you'll be happy to find that GPL3 does not make any software any less useful. It just means that if you want to extend the software, you must distribute source code with it. Any entity which finds this unacceptable doesn't deserve to be using this software anyway. It becomes more useful because it encourages people to distribute source code that they may not have otherwise.
- altairprime 3y ago
  > if you want to extend the software, you must distribute source code with it Incorrect. GPLv3 does not require source code distribution if you choose to only distribute your extensions to third parties that are under a current contract to you to operate or modify the work or any derivative thereof on your behalf and to destroy all copies of your extensions at the conclusion of the contracted operational and/or modification work. I’m surprised that $1 modification contracts for GPLv3 works are uncommon. Open source isn’t free! (I am not your lawyer, this is not legal advice.)
  - TeMPOraL 3y ago
    Isn't this how using GPL-ed code in commercial contexts work? You don't have to share sources with the outsiders if you don't ship the program to the outsiders - and your employees and contractors are bound by their contracts to share neither the proprietary extensions nor the resulting program with the outside world. Note that SaaS means you're not shipping backend software to users, which created a loophole that has a special GPL variant patching it.
    - davorak 3y ago
      altairprime's idea seems to be to sell the software to your users, but hire them as contractors to modify the gpl code so they can not redistribute it themselves. So on perm saas where the on perm operators are technical hired for $1 so the software was never legally distributed to the company that hired the on perm saas service. Seems dubious to me.

stefanos82 3y ago

Oh my, you've just brought up some amazing memories from my past time as systems administrator! I would setup SliTaz [1] on some ancient hardware and worked right out of the box with very little RAM. I have had so much fun using this distro! Here's the link where you can read about xvesa support in SliTaz: https://doc.slitaz.org/en:guides:xorg-xvesa https://doc.slitaz.org/en:guides:xorg-xvesa [1] https://slitaz.org/en/ https://slitaz.org/en/

ang_cire 3y ago
Damn, slitaz... That's a blast from the past. Right next to bb4win and openshell in my childhood OS explorations.
- stefanos82 3y ago
  Indeed a blast from the past, well said @ang_cire!

yjftsjthsd-h 3y ago

> no xkb; it's bloat when console keymaps suffice So on the pro side, that sounds like you could just configure your keyboard layout once and have it work everywhere, which would be nice. On the con side, I'm not aware of a way to switch console keymaps on the fly; setxkbmap lets me configure a hotkey that switches layouts instantly, which is really handy. Or am I misunderstanding the impact?

lotharcable 3y ago
Ideally you'd have a programmable keyboard. That way it keeps the OS configuration down to a absolute minimum. It is just easier that way. Especially if you want to use multiple OSes and such things.
- yjftsjthsd-h 3y ago
  Well yes, ideally I would prefer to be able to implement things in firmware (especially chording), but since I mostly use laptops I'm a bit stuck. And yes, I can probably use things like keyd to work around it, but it seems a bit unreasonable to require that level of mucking around in order to switch keyboard layouts.
- deleted 3y ago
  [deleted]
vidarh 3y ago
That'd be a non-starter to me. I switch between US and Norwegian layouts depending on which language I'm writing, and while I could "just" map the additional Norwegian characters to other combinations, I don't want to.

anthk 3y ago

If this worked under MirBSD it could resurrect some 386 and 486's. Also, there's is a pocketchip-like computer based on a 486 sx I think. http://www.mirbsd.org/ http://www.mirbsd.org/

badsectoracula 3y ago

Sounds neat but wouldn't using DRM be better than fbdev nowadays? AFAIK (from having played around with DRM recently-ish and with fbdev years ago) it should be possible to abstract the "get a framebuffer" part (IIRC fbdev didn't have much of an API and all of it can be mapped to DRM).