Tinyx – Resurrected Xvesa from the depths of Git history

https://github.com/tinycorelinux/tinyx

by peter_d_sherman • 3 years ago

118 57 3 years ago

github.com

peter_d_sherman2• 3 years ago

Low-level VESA/VGA routines:

https://github.com/tinycorelinux/tinyx/tree/master/kdrive/ve...

rkeene2• 3 years ago

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

HeckFeck• 3 years ago

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

oso2k3• 3 years 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.

vidarh3• 3 years 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...

peter_d_sherman2• 3 years ago

Interesting link!

If we look at this directory:

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!

oso2k3• 3 years ago

Also works on DOS w/djgpp.

hkt• 3 years 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• 3 years 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• 3 years 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..

snvzz2• 3 years ago

Not a fan of the license change.

Deliberately making the software less useful drains the preservation value the project would otherwise provide.

LoganDark3• 3 years 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.

altairprime4• 3 years 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.)

sudobash13• 3 years ago

It just means that if you want to extend the software, you must distribute source code with it.

It means a lot more than that. The most significant difference in my line of work is the anti-tivoization requirements. Essentially if you ship this software in a device, you must allow the user to change the software/firmware on that device. I do embedded Linux work for several different clients, and they are almost never OK with this. So I have to be careful to never use GPLv3 software.

Not that I agree completely with the OP. I love when I can customize the firmware on devices I get (that is almost a precondition for my purchasing it), and I wish more manufacturers were OK with it.

yjftsjthsd-h3• 3 years ago

In what case would the license change impact anything? You want to make proprietary changes to the X server?

sudobash13• 3 years ago

It could be significant in embedded devices due to the anti-tivoization requirements of the GPLv3.

asveikau• 3 years ago

I feel like the historical culture of X development is permissive licenses and proprietary Unix vendors developing closed solutions on top. It was deliberately like that. So this feels like a departure.

wang_li2• 3 years ago

It's not clear that they can change the license. For example in dix/dixfonts.c it says:

Copyright (c) 1991, 1997 Digital Equipment Corporation, Maynard, Massachusetts. >Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software. >The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Given the various GPL theories of tainting linked code and that this requires specific permissions be included with the program, not sure they can put a GPL license on the overall resulting product.

lmm2• 3 years ago

including without limitation the rights to ... sublicense ... the Software.

Sounds like they can distribute that code under the GPL, provided they include the notice (which is OK from the GPL PoV since it doesn't frustrate what the GPL provides). That particular code continues to be available under its original license. The whole is available under the GPL. Licenses are permission to do things that would otherwise be prohibited by copyright; there's no problem with having extra permission or multiple kinds of permission. What part do you think would be a problem?

ddevault• 3 years ago

That's not quite how it works, you can relicense stuff under GPL and your distribution and any changes you made are GPL'd but the original remains MIT.

https://writefreesoftware.org/learn/participate/derived-work...

https://writefreesoftware.org/learn/participate/copyright-ow...

appleflaxen• 3 years ago

If you need to be exempted from the GPL v3 requirements, then pay the license holders for a different license. If you offer them enough they will probably come to the table.

Meanwhile, everyone without that need will benefit from the protections that GPL v3 provide.

NonEUCitizen• 3 years ago

The README mentions this other project:

https://github.com/idunham/tinyxserver

which has an XServer.man file that mentions X11/MIT-like license, but otherwise doesn't state a license for the project as a whole.

stefanos822• 3 years 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

[1] https://slitaz.org/en/

ang_cire• 3 years ago

Damn, slitaz... That's a blast from the past. Right next to bb4win and openshell in my childhood OS explorations.

stefanos822• 3 years ago

Indeed a blast from the past, well said @ang_cire!

yjftsjthsd-h3• 3 years 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• 3 years 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-h3• 3 years 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.

vidarh3• 3 years 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.

anthk2• 3 years 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/

badsectoracula3• 3 years 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).

Tinyx – Resurrected Xvesa from the depths of Git history

Related Stories