[HN Gopher] Tinyx - resurrected Xvesa from the depths of Git his...
___________________________________________________________________
Tinyx - resurrected Xvesa from the depths of Git history
Author : peter_d_sherman
Score : 30 points
Date : 2023-06-27 20:53 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| snvzz wrote:
| Not a fan of the license change.
|
| Deliberately making the software less useful drains the
| preservation value the project would otherwise provide.
| yjftsjthsd-h wrote:
| In what case would the license change impact anything? You want
| to make proprietary changes to the X server?
| LoganDark wrote:
| > 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 wrote:
| * * *
| stefanos82 wrote:
| 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/
| rkeene2 wrote:
| I had more luck with KDrive for a minimal but functional X server
| (for an OS installer in my case).
| peter_d_sherman wrote:
| Related:
|
| Low-level VESA/VGA routines:
|
| https://github.com/tinycorelinux/tinyx/tree/master/kdrive/ve...
| HeckFeck wrote:
| Is this any relation to Nano-X? http://microwindows.org/
| peter_d_sherman wrote:
| 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!
| oso2k wrote:
| 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 wrote:
| 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...
| hkt wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-27 23:00 UTC)