What are comparisons of Xenocara with Xorg, and perhaps Wayland

S

sidetone

I have never used Xenocara, and haven't used OpenBSD.

What are benefits or comparisons for Xenocara over Xorg? I've heard about security benefits. What about ease of configuration for file or driver access? Also, are there desktop performance benefits? Or are there improvements in dependencies, including build dependencies?

Also, anything regarding the future or present of Wayland in any way related or could be related to Xorg or any derivative, including pieces of it to be used alongside Xorg or possibly in the future Xenocara. Anything also related to Xenocara, and Xorg derivatives or forks...

I've wondered about Xenocara and Wayland for a while. Thread the-no-future-of-x-org-freebsd-becomes-headless.91235, which for immediate clarification, the title is incorrect, prompted me to start a thread about this. Xorg is maintained by both FreeDesktop.org (of the Linux Foundation) as a fork, and still under the original X.org Foundation, regardless of what Redhat does.
 
From www.xenocara.org:
"Xenocarais the name chosen for the version of X included in OpenBSD. It is currently based on X.Org 7.7 and its dependencies.

The goal of Xenocara is to provide a framework to host local modifications and to automate the build of the modular X.Org components, including 3rd party packages and some software maintained by OpenBSD developers. It is not a fork. We are tracking X.Org modifications and try to push back our changes whenever they are good for upstreams too.

To learn more about Xenocara, read this old article on Undeadly or listen to that BSD Talk interview."
 
Xenocara the way it is, builds with BSD make. However, for any customizations, it additionally requires gmake, other GNU toolchain components and Python. Xenocara uses an older version of libxcb, or it would need other building tools and dependencies.

cwm and fvwm 2.2.5 are also maintained by Xenocara. These window managers plus twm are under the app directory. https://github.com/openbsd/xenocara/tree/master/
 
sidetone said:
Xenocara the way it is, builds with BSD make.
Click to expand...
This is only relevant for smooth integration with some BSD base system ... something FreeBSD doesn't want to do anyways, for good reasons. [1]

sidetone said:
However, for any customizations, it additionally requires gmake, other GNU toolchain components and Python. Xenocara uses an older version of libxcb, or it would need other building tools and dependencies.
Click to expand...
No, it doesn't use an "older" xcb. It contains pre-generated xcb source. Most of xcb's source is auto-generated from X11 protocol descriptions in XML. The tool to generate these sources is written in python. That's why on any update of xcb, some manual steps (install python etc, run the generation tool, check in the new generated source) is required, as python is not available in OpenBSD base.

In a nutshell, Xenocara is "just" OpenBSD's fork of Xorg which aims to integrate it smoothly with OpenBSD base. It isn't meant as a standalone fork though, Xorg updates are pulled regularly and local OpenBSD changes are pushed back when applicable.

[1] While working on my Xmoji tool, I experienced the wonders of "X11 in base". In my case, I had "fun" with a freetype not supporting png. Background is that Xorg comes with Xft for a LONG time, a library to add client-side rasterization of scalable (ttf, otf) fonts, rendering them with XRender, to overcome the core X11 fonts limitations which only work with bitmap fonts. Xft uses freetype for the actual rasterizing, so freetype must be included with Xorg. Freetype has *optional* png support using libpng, you'll need that for some color fonts, like the "Noto Color Emoji" font. Although my code doesn't use Xft (which is based on the traditional Xlib), it does do the same thing with xcb, using freetype directly. It worked fine on FreeBSD and Linux systems I tried, it broke on OpenBSD and manually building it on NetBSD was problematic. The reason was X11 in base. Both OpenBSD and NetBSD don't want to have libpng in base, but are forced (see above) to have freetype in base. NetBSD at least offers freetype also from ports, where it is "full featured", and has some complex magic in pkgsrc to make sure ports always link the version from ports. For OpenBSD, I had to offer a way to bundle building a full-featured freetype and link it statically....
 
You must log in or register to reply here.
Back
Top