Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: The Tiny X Server Fork Is Still Being Maintained

  1. #1
    Join Date
    Jan 2007
    Posts
    15,104

    Default The Tiny X Server Fork Is Still Being Maintained

    Phoronix: The Tiny X Server Fork Is Still Being Maintained

    The tinyx fork of the X.Org Server back from version 1.2.0 with Xvesa support and replaces XFree86 era code in some lightweight Linux distributions like Tiny Core Linux and Puppy. One of the developers has commented on the recent X Server security vulnerability that remained unresolved for more than two decades...

    http://www.phoronix.com/vr.php?view=MTU2NzA

  2. #2
    Join Date
    Aug 2012
    Posts
    496

    Default

    I wish XMir and Xwayland were based on TinyX. Just saying.

    (Assuming this fork has what current drivers and DE's need to run anyway)
    Last edited by dh04000; 01-10-2014 at 01:38 PM.

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

    Whee, apparently there's three different projects named TinyX now. The old Kdrive one, and two current ones. Ibidem's is https://github.com/idunham/tinyxserver AFAIK, which is different from the TC one linked in the article.

    For what it's worth, I didn't find the X code that bad. In fact I quite enjoyed it, it was the first time I got to delete close to a million lines of code. Made me feel really productive!

    I wish XMir and Xwayland were based on TinyX. Just saying.
    I believe both have removed rootless code as useless for normal users. Not too good a starting point for a rootless server like X[MW]*.

    (Assuming this fork has what current drivers and DE's need to run anyway)
    TinyX servers have the drivers integrated -> you can't use Xorg drivers on them. The goal is small binary size, supported drivers: Xvesa and Xfbdev.

  4. #4
    Join Date
    Nov 2011
    Posts
    287

    Default

    Quote Originally Posted by curaga View Post
    Whee, apparently there's three different projects named TinyX now. The old Kdrive one, and two current ones. Ibidem's is https://github.com/idunham/tinyxserver AFAIK, which is different from the TC one linked in the article.

    For what it's worth, I didn't find the X code that bad. In fact I quite enjoyed it, it was the first time I got to delete close to a million lines of code. Made me feel really productive!
    https://github.com/idunham/tinyxserver is my git repo, yes.
    To go with it, I use https://github.com/idunham/tinyxlib.
    The starting point was Amigo's project (http://distro.ibiblio.org/amigolinux...1-tiny-1.2.61/), which apparently was based off the xwoaf notes.
    technosaurus and goingnuts on the Puppy Linux forums did a bit of work on it (releasing the occasional snapshot), and I was rather disturbed at the idea of an X server that old without patches, so I went through the list of security issues for X and backported the fixes. And somewhere along the line Iguleder picked up the project; from what I understand, he referred to the TinyCore TinyX as a guide to getting it working on amd64.

    The relevant threads (that I recall off the top of my head) would be:
    http://www.murga-linux.com/puppy/viewtopic.php?t=62145
    http://www.murga-linux.com/puppy/viewtopic.php?t=51478
    http://www.murga-linux.com/puppy/viewtopic.php?t=78941
    http://www.murga-linux.com/puppy/viewtopic.php?t=89272

    I'm not sure where to point at, but a project known as "microsaurus" was also one of the projects that used it; one release was here:
    http://www.murga-linux.com/puppy/vie...72671&start=46
    The "bzImagegtk.tar.gz" is an archive containing the kernel, which contains the initrd, which is the OS.

  5. #5
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Exclamation Direction of Wayland

    I don't like the direction Wayland is going and the concept of having to write the same code for every new compositor over and over again.
    Today, if you want to write your own implementation, people tell you to just write a Weston-extension. If you don't want to, have fun writing thousands of LOC just to get started.
    Why don't the Wayland-devs once and for all offer some kind of libwayland-compositor implementing a basic compositor-interface while still offering old functionality (same applies to evdev, events and so on).

    I like to see projects like the Tiny X Server fork, because it shows that X is more flexible than you might think, after cutting out the legacy code.
    To be fair: Yes, in Wayland, every frame is perfect. But what's the price? Most compositors are just implemented with EGL, which requires DRI and accellerated graphics. Have fun setting this up on your embedded server.

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

    Hm, so I think this is the difference between the Puppy and TC forks, based on the above links.

    The TC fork aims to run everything sans bling, while the Puppy fork aims to be even smaller, but it does not run all apps (gtk2 was mentioned). Then there's the libc difference, with TC using glibc to be as compatible as possible, but the pupngo version using static musl.

  7. #7
    Join Date
    Jan 2014
    Posts
    1

    Default

    Quote Originally Posted by frign View Post
    Have fun setting this up on your embedded server.
    That's right - it's pretty much impossible to get Wayland to work in extremely restricted environment (without udev, *GL*, etc'). That's why I decided to port Tiny X and tinyxlib to x86_64 - this is the only portable Linux graphics stack I'm aware of, which can be built statically against musl and doesn't depend on acceleration. It wasn't hard to port - I just examined the diff against Tiny Core's code.

    The Tiny X Xfbdev is ~950 KB on x86_64, when built against musl. Pretty much any classic Xlib window manager works against it - I use Ratpoison.

  8. #8
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Cool Nice!

    Quote Originally Posted by Iguleder View Post
    That's right - it's pretty much impossible to get Wayland to work in extremely restricted environment (without udev, *GL*, etc'). That's why I decided to port Tiny X and tinyxlib to x86_64 - this is the only portable Linux graphics stack I'm aware of, which can be built statically against musl and doesn't depend on acceleration. It wasn't hard to port - I just examined the diff against Tiny Core's code.

    The Tiny X Xfbdev is ~950 KB on x86_64, when built against musl. Pretty much any classic Xlib window manager works against it - I use Ratpoison.
    Very cool!

    Yes, I will definitely check this out in the near future. Being a suckless developer, I'm especially interested in how that could work out in combination with dwm .
    We're discussing a dwm based on Wayland, but given dwm (and ratpoison) are so minimal and lean in regard to the need of compositing, Wayland is probably a step too far and really over-the-top given you have a minimal environment.

    What particularly annoys me is Weston's hard-dependency on PAM.

    Could you use some help on your tinyx- and tinyxlib-projects? I'd be eager to support you!

  9. #9
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by frign View Post
    Today, if you want to write your own implementation, people tell you to just write a Weston-extension. If you don't want to, have fun writing thousands of LOC just to get started.
    Why don't the Wayland-devs once and for all offer some kind of libwayland-compositor implementing a basic compositor-interface while still offering old functionality (same applies to evdev, events and so on).
    we did write a libwayland-compositor - it's called weston. and you can write plugins for it.

  10. #10
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by Iguleder View Post
    That's right - it's pretty much impossible to get Wayland to work in extremely restricted environment (without udev, *GL*, etc').
    weston runs perfectly well without (e)gl(es), running the pixman software renderer. works on top of drm/kms or fbdev.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •