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.

[solarlnyx]

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.

I like the idea. I will try to find a use for it in a related project. I ran DietPi with FLTK/FLWM last year: https://www.youtube.com/watch?v=W4_v_CW-WSc  https://github.com/hatonthecat/linux_distro_tests

It would be ideal when something like taskel isn't sufficient: https://wiki.debian.org/tasksel I personally prefer something like synaptic package manager, or a "software center," which makes a distro a lot more accessible than command line only, but mainly because it can visualize all the related/sub packages in a tree diagram (especially with synaptic).   

[mung]

Which version exactly?

I just got a drone project and was think to get a gui, the last version of xfbdev for rpi was compiled so long ago and diverged so much I think maybe could do with an update, I think was 1.2xfree from about 2014 but I cannot remember.

I think was 1.3 though there were xinput problems etc 1.4 was not released though was in dev or maybe thats wrong?

Important for me :
* does it have unicode support
* rpi gles/GL shm support
* is it self compilable within TC with tcc

I actually not sure where the code is now, but I think I put some of it on TILCK when I made failed attempt at porting to that. I think should still compile on rpi(I am not going to search or show links).

I guess problem with 'linux' 'open' stuff is everyone got old and needs to earn a living which is not possible, when projects say 'share' what is mostly want is someone to offer free test/bugfix/support/admin, a thinkless task only wanted by the insane 

Anyways I am thankful to those that still idealistic enough to give stuff away, I doubt there is much new that really needs us to throw away our old tools(obviously there are some, but reading text/images, writing code/inputing data etc. I don't see much change), most soft development is just churn by the big companies to generate income by forced upgrade.

Was a .tcz created?

Perhaps we should all move Wayland 

[neonix]

Important for me :
* does it have unicode support

Xfbdev and Xvesa support only latin-1 languages ISO-8859-1. The only advantages from TinyX Xvesa is probably faster vesa vm68 mode than in Xorg vesa. Xfbdev an Xvesa are less buggy than Xorg but thare's not more advantages. Nowadays size of X-server is not so important.

[mung]

Important for me :
* does it have unicode support

Xfbdev and Xvesa support only latin-1 languages ISO-8859-1. The only advantages from TinyX Xvesa is probably faster vesa vm68 mode than in Xorg vesa. Xfbdev an Xvesa are less buggy than Xorg but thare's not more advantages. Nowadays size of X-server is not so important.

I am not sure what you mean ISO-8859-1 only?

I probably did not define what I meant sufficiently precisely, but I think maybe you do not understand the code points available, I think X(lib) supported widechar since R4(I could check that and am probably wrong but at least since R5). I think there is a Xwchar/Xchar16 datatype (or something like that?), but the code is probably only in Xlib and Xfonts as X just deals with glyphs(does it?).

I know the last version of Xfbdev I used on the rpi supported UTF8 and UCS16 but could only display the first 223 SBCS code pages. I think full unicode support requires a 6byte code point. I suppose what I really meant was color glyphs for emojis and support for more than 16bit chars. I am not too bothered about text direction and combining chars.

I think I had the gnu unifont in pcf on the last fbdev dist so there was support for most world languages, and most of the apps I used had UTF8 support, but I would like emoji display as emoji seem so prevasive thesedays.

*** I guess at least half of what I say here is partially incorrect as I have not fact checked and am going from vague memories, feel free to correct any inaccuracies(if you are sure I am innaccurate).