Offering Xfbdev from XFree86 on PiCore

[CNK]

As part of a project I'm working on I fixed a bunch of ARM/modern-Linux incompatibilities in the old XFree86 X server, so that now I have a version that runs on the Raspberry Pi. This includes the Tiny X framebuffer server Xfbdev, which currently isn't available on PiCore. Looking through the forum it seems that Tiny Core's stripped down version of Xorg's Xfbdev was tested on PiCore during initial development, but found to be unstable and therefore scrapped. I've tested my XFree86 Xfbdev on a Pi Zero and a Pi Zero 2 and not experienced any crashes, although the mouse acceleration needed some fiddling and still seems a little laggy (might just be to do with the wireless mouse I'm using).

I've tested a few programs, including Firefox running from a PC in a remote window (PiCore's firefox.tcz seg. faults for me on the Pi Zero 2 regardless of the X server used). Also Dillo, "Links -g", aterm, xeyes, twm. It seems stable. I've only tested on the composite video output so far though.

The current extension that I've got, which needs some minor modification to account for font paths, is 500KB, so that compares well with the xorg-server.tcz extension which is 2.63MB and depends on mesa.tcz which is 2.85MB. It's bigger than Tiny Core's Xfbdev extensions on x86 (340KB) and x86_64 (356KB) though, but has all the original Tiny X features like TCP support.

Anyway I thought it might be useful for people looking to start X faster on a Raspberry Pi. On the other hand it's not using Tiny Core's Tiny X codebase, so maybe that's too confusing (could name it something like xf86-Xfbdev.tcz though). Also the configuration might not work as well as on PC because PiCore seems to assume that Xorg is the only server available (jwm.tcz depends on Xorg.tcz, for example). It also lacks the Raspberry Pi optimised framebuffer driver that the Xorg server uses.

Basically, if there's interest then when I have time I can try to build a good extension for it. Or if it's not wanted because it'll cause confusion or something, then I won't. So let me know.

[neonix]

I love Xfbdev becouse it works on GPUs that are not officially supported by Linux, but what's the point to create Xfbdev for Raspberry Pi if all Raspberry models have support for GPU hardware acceleration?

[CNK]

I love Xfbdev becouse it works on GPUs that are not officially supported by Linux

Well I don't want to break up a love affair, but that's not really anything that Xorg (or the full XFree86) can't do for you. You just need to configure Xorg to load the "fbdev" (framebuffer) driver and it will also work with GPUs that don't have dedicated X drivers. The full X servers with fbdev also support GLX for many 3D applications (using software rendering), which Xfbdev doesn't.

The TinyX servers are basically stripped-down versions of the full X server glued to one particular driver from the full-size X server. So the fbdev driver becomes Xfbdev, and the vesa driver (on x86) becomes Xvesa (there are also hardware-specific TinyX drivers). The advantage is that this means they're smaller and faster than the full X server running the same drivers, and this difference is quite significant.

Maybe Xfbdev is easier to configure because there's only one driver option so you never need to tell X what driver to use in xorg.conf, but that's really not the point of it.

but what's the point to create Xfbdev for Raspberry Pi if all Raspberry models have support for GPU hardware acceleration?

The point is as I said, faster loading time so a Pi, eg. in an embedded application (which might not have any fancy graphics), can boot faster. People have complained here before about the time it takes to load Xorg on a Pi, Xfbdev should load a lot faster for them. In fact this seems more relevent on the Pis these days (especially the Zeros) than on PC where performance of modern hardware is much better (although I recently set up TC 14 on an old PC where I still appreciated the quick start-up time of Xvesa). However nobody has replied here so I'm guessing either they all need one of the features that the full Xorg server offers, or they weren't really serious. Anyway I take it that I was wrong about my idea of there being a demand, so unless I really feel like mucking about with it again, I won't go to the effort of submitting extensions (on the other hand I also take it that nobody would object if I did).

[Paul_123]

A nice stripped down version might be interesting.  Getting Firefox to run a simple kiosk mode.  NoThing 3d or accelerated.

[aus9]

Hi CNK
I have updated privately jwm with Xorg but not submitted as other things to do. I have no problem if you would like to submit jwm built on your video driver. I will see if Paul_123 would allow me to then submit later, a jwm-Xorg.

[CNK]

My reference to JWM is about the .dep file rather than the extension itself. As proven by me running the existing extensions for Dillo and aterm, the Xfbdev X server works with libX11.tcz from PiCore 13.1.0 and the other Xorg libraries (like it works on x86 and x86_64).

The issue is that whereas on x86 jwm.tcz.dep looks like this:

Code: [Select]

libXpm.tcz
libXmu.tcz
libXinerama.tcz
librsvg.tcz
fribidi.tcz

On armv6 it looks like this:

Code: [Select]

Xorg.tcz
libXpm.tcz
librsvg.tcz

The Xorg extension is used instead of individual libraries. This pulls in the libraries as dependenciess of Xorg, but also installs xorg-server.tcz, which is useless if you intend to run Xfbdev. The assumption has been that there will only ever be Xorg available on PiCore, never any other X servers like on x86 (Xfbdev.tcz and Xvesa.tcz) and x86_64 (Xfbdev.tcz).

Hence I wasn't sure if the PiCore devs even want other X servers, because it might complicate how they've done dependencies (and maybe even some scripts). But no programs should need to be recompiled to work with Xfbdev on piCore, besides the GLX issue (which is the same on x86 Xfbdev/Xvesa and many programs such as Firefox (which detects whether GLX is available or not) run fine with that).

[aus9]

No worries I look at it later. on private update of jwm piCore64-14.x we will get

Code: [Select]

P=jwm
readelf -d $P/usr/local/bin/$P | grep 'NEEDED'
#[libX11.so.6] libX11         Xorg
#[libpng16.so.16] libpng       "
#[libjpeg.so.62] libjpeg-turbo "
#[libXft.so.2]                libXft
#[libXrender.so.1] libXrender libXft
#[libXpm.so.4] libXpm
#[libXinerama.so.1] libXinerama Xorg
#[libz.so.1][libc.so.6][ld-linux-aarch64.so.1] TCB

echo 'Xorg.tcz
libXft.tcz
libXpm.tcz      ' > $P.tcz.dep
in case you wondering I have not attempted to remove Xorg and run it with more dep lines as above. This was based on a post from Juanito that I inferred for a basic setup needed Xorg in the boot list

[Paul_123]

In general, dep files should list dependencies at the lowest level needed.  Avoid grouping deps into a higher level.

CNK.    Aus9 is only playing with aarch64 right now, so if you would like to work on some armvxx extensions, that is fine.  Just make a specific proposal.

Paul



 

[neonix]

You have to be aware that with each year more new software won't be compatible with Xfbdev. Xvesa don't support x86 and there's no volunteers to develope new TinyX versions.

Most people, I believe, use Raspberry Pi as headless system. If you don't want to send extension, you could publish howto.

[neonix]

Someone should create something like Xorg-fbdev.tcz that will works without configuration process, with standard xorg.conf that works with most hardware. And only one driver fbdev.

There was also Xorg-vesa in the repo many years ago, but I don't remember if it require "Xorg -reconfigure" procedure. Such extensuon that don't need reconfiguration process would be good for people who are beginners.

I don't use most of major Linux distros becouse Xorg configuration process was very anoing, if you don't have supported GPU. That's why I use minimalistic distros.

There could be also a shortcut "Xorg -reconfigure" -> "xorgconf".

BTW.
Few years ago I propose to create Xvesa-desktop.tcz, Xfbdev-desktop.tcz, and Xorg-desktop.tcz that will install wbar Xlibs Xprogs fltkwm aterm and Xserver.

[CNK]

CNK.    Aus9 is only playing with aarch64 right now, so if you would like to work on some armvxx extensions, that is fine.  Just make a specific proposal.

My proposal is to just to submit an extension called Xfbdev.tcz, not to rework the dependencies for any extensions that needlessly pull in xorg-server.tcz.

It would be nice if maintainers of those extensions, or the distro devs, would edit those deps to work like the eqiuivalent extensions in the PC version of Tiny Core. However initially I would just add a note in the Xfbdev.tcz.info file that users need to edit dep files themselves in order to avoid loading lots of unnecessary extensions.

You have to be aware that with each year more new software won't be compatible with Xfbdev.

As mentioned in the first post, this Xfbdev isn't based on the same sources as the x86/x86_64 extensions, and I believe it might not have as many compatibility issues as those more stripped-down versions, at the expense of being larger in size.

Anyway I think there's a lot of software in PiCore that will continue to run fine with it for a long time.

Most people, I believe, use Raspberry Pi as headless system.

OK, you may be right because it's been months and nobody has said this will solve a problem for them.

The Xorg-fbdev.tcz etc. ideas are probably something that should be discussed in one of the x86 or x86_64 sub-forums. I believe Juanito 'designs' the Xorg extensions for PC.