2008-05-04 09:05:31     Kdrive Xfbdev server instead of microwindows

2008-05-04 09:05:31     Kdrive Xfbdev server instead of microwindows

Konstantin Hartwich (GERMANY)

Message: 55464   

hi

has anyone considered using Kdrive Xfbdev (TinyX former), lightweight windowsmanager like matchbox and GTK as GUI toolkit.?

this appears to me to be one of the closest choices in terms of using a whole bunch of already existing software for X11 sistems. just needs recompile. i could imageine that the blackfins not only tend to used in "simple" DSP envirenment but also need to have kind of a portable gui environment (think of remote connection to your BF board if needed.). To me it appears that the microwindows stuff, though beeing that lightweigth is way too inapropriate in such areas. need of using nxlib to fix X11 compatibility is just a first aid procedure. but where a clean build GUI is needed, we still might need to stick to old X11 standards, thus using Kdrive stuff.  (to get an idea of speed: download any of the kdrive using distros, i.e. DamnSmallLinux as livecd, 50 MB). considering that  1 MB or 2 more of ram is not  that expensive now, it might be a nice and feature providing investment.

so, has anyboidy tried to adopt Xfbdev into current uClinux distro?

QuoteReplyEditDelete

2008-05-20 11:38:00     Re: Kdrive Xfbdev server instead of microwindows

Konstantin Hartwich (GERMANY)

Message: 56060   

I have been trying to compile latest git repository of xorg (for the kdrive Xfbdev Xserver), to use for uClinux, went almost trough hell with it. now there is a running binary of Xfbdev, around 1,3 mb, stripped. i think it could be even less taking in count more things one doesnt need.

the only problem is that when it starts up it seems not to be able to recognize the fb0 framebuffer, it has a problem with mmap.reports:

root:/> Xfbdev

ERROR: mmap framebuffer fails!: No such device

Fatal server error:

no screens found

root:/>

i turned to the source code (if anyone has got the code: xserver/hw/kdrive/fbdev/fbdev.c) and found out that only mmaping goes wrong. the file is accessable. nano-X is starting up freely on that.

so anyone with a hint what it could be? i"d love to have Xfbdev as alternative to microwindows..thus having real remote X..

if intereseted, i will post the changes to the repository tree and the "build process"

greets

QuoteReplyEditDelete

2008-05-20 14:38:37     Re: Kdrive Xfbdev server instead of microwindows

Michael Hennerich (GERMANY)

Message: 56062   

Simply change the mmap flags in xorg.

to PROT_READ|PROT_WRITE, MAP_PRIVATE

nano-X uses

PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FILE

I think on svn trunk this or any chnage is no longer necessary since we changed the fb driver local mmap flags.

-Michael

QuoteReplyEditDelete

2008-05-20 14:44:04     Re: Kdrive Xfbdev server instead of microwindows

Michael Hennerich (GERMANY)

Message: 56063   

And yes - please post your patch set.

-Michael

QuoteReplyEditDelete

2008-05-21 18:23:07     Re: Kdrive Xfbdev server instead of microwindows

Konstantin Hartwich (GERMANY)

Message: 56108   

Thank you michael, this was exactly the thing. actually i was looking in the wrong c file of nano-X sources..

there were no changes applied to nanox/clientfb.c but this is not the file to look at (I compared sources of distrib to the originals), but zou have to look at the drivers/scr_fb.c for those who are looking for it.

It compiled successfully.

NEXT POST WILL BE KIND OF LARGE. SORRY. There is the howto compile the Xfbdev.

greets

QuoteReplyEditDelete

2008-05-21 19:05:17     Re: Kdrive Xfbdev server instead of microwindows

Konstantin Hartwich (GERMANY)

Message: 56109   

Howto build Kdrive Xfbdev (former TinyX) Server

Having strived all over the net to find a howto on (cross)compiling Xorg modular tree, there was far too few infos, most of which was still targeting the old xfree86 stuff or the old xorg monolithic tree. But when it came to crosscompile it was even less. So I tried it on my own. Here is how far I have come so far.

First, some terminology

Xserver: a summery description for an executable, providing the X11 API..writing grafics on the other hand is done by accessing vesa, vga, xgl, or what ever the flavor of the Xserver is.

Kdrive: was formely known as TinyX, programmed by Keith Packerd..was meant to be a development Xserver, but started to to receive more attention concerning embedded design, cause having X, unbloated, is just too good. The package consists of various Xservers, like Xfbdev, Xvesa etc…has nothing to do with the Xorg, the real big Xserver. Some time ago, Kdrive was merged to the now modular Xorg tree. Having the Xorg tree you have the soruces to build the Kdrive Servers too.

Xfbdev: is the Framebuffer variant of the Kdrive Xservers. This is the one we need for blackfin stuff. I got to know that it could be torn down to aprox. 800 kb, though being still far bigger as the microwindows nano-X and its derivatives, it gives you the tried and true X11 API, and remote executing at its best. Think of executing some Audio stream calculating stuff and displaying results via X11 connection locally on your own screen or vice versa….just as you like.

BEFORE YOU PROCEED:

Don’t think of this guide to be complete, it is far from that. Don’t think of me to be professional. I am far from that. It is the way I tried to compile “quick and dirty” the Xfbdev Xserver to use with my uClinux Distro, without intention of integrating it into Distro infrastructure. Its only for testing purposes. If you find a nicer and better way to circumway the CROSS COMPILING restrictions in Xorg tree or the others, please let me know. I ‘d love to know. As I still have no idea on how to exactly use autoconf or the other autotool stuff, I tried to go the way of least resistance by modifying the Makefile when there were problems, thus not changing anything with the shipped configuration generations. Please keep that in mind and don’t complain. Compiling the Xorg Xserver is considered hell per se, but cross compiling it is even worse it seems.

Check out http://xorg.freedesktop.org/wiki/CrossCompilingXorg

For some info. But think of it being really out of date. There are 3 patches on that page, which I had to apply by hand, cause they were faaaar to old, I will save you the bother. Look down to get the zip and replace accordingly, it is described in text.

So here we go, building a (half) working Kdrive Xfbdev Xserver.

PREPARATIONS:

BY THE WAY: I AM USING (FDPIC) so be aware of using right flags in your precompiled uClinux Dist..

We will be using a ready to use uClinux dist, like zou have it, maybe.. I have the checked out the svn repository for the uClinux_dist..keep it updated. I assume you have got a working toolchain installation on your build system. If not, take infos from

http://docs.blackfin.uclinux.org/doku.php?id=toolchain:installing

I am using

blackfin-toolchain

blackfin-toolchain-elf-gcc-4.1

blackfin-toolchain-uclibc-full 

in the latest release version (2008R1-RC8)

I am using the BF527 EZKIT LITE Evaliation board..I assume You will have set up your distro correctling to providing Framebuffer support.

I strongly recomend to build the Xorg tree first for the build system, to get comfortable with the build process, which takes even longer than to build our distro.(Far longer, my build server Q9450@3.2Ghz /4GB needs aprox 20 min, dstro 5 for full compile)

Try to follow the indications on the page

http://xorg.freedesktop.org/wiki/ModularDevelopersGuide

If you do so, I recommend you to take the GIT checkout version instead of the tarballs.

You can revert changes later..

I was using the suse 10.3 system, it has to have the typical development stuff installed, be carefull if the build process mourns somehow, to install needed packeges including their development versions, do it.

Check out http://xorg.freedesktop.org/wiki/ModularDevelopersGuide

For the prerequisites.. (and keep it open for the executing commands, most of them are used here too)

We don’t need mesa, the 3d openGL stuff. Many of the libs we will use in their blackfin compiled versions. They are found in the uClinux_dist/ramfs/lib stuff later, but during compile time accessable in uClinux_dist/staging/usr/lib. Will be specified with compile Flags in the build.sh. We neither need libdrm on blackfin, so forget about that, unless zou also want to compile it for your build machine.

(Check out Cross Compiling http://docs.blackfin.uclinux.org/doku.php?id=cross_compiling

And the use of some flags in http://docs.blackfin.uclinux.org/doku.php?id=simple_hello_world_application_example

)

Be sure to have the additional requirements installed as well, like the automake, autoconf, libtool, etc.. But normaly they are, just verify if the devel versions are installed as well.

In adition we have to install bison package on your build system (yacc stuff, including its devel, needed for twm and other apps) and the fontconfig library for the blackfin system.

The last prerequisite, the fontconfig, is needed on the host system, so we have to compile it first.

0.) Installing and compiling the fontconfig lib..

Get the sources at http://www.fontconfig.org/release/

you can select the latest version.

Extract it somewhere, best to uClinux_dist/lib/fontconfig, just for compatibility with source tree, later I will try to insert it in the build system..

Change to the top directory of fontconfig and run, by replacing prefix content with the directory you want your compiled stuff to be copied later.

konstantin@apollo:~> ./configure --build=`config.guess` --host=bfin-linux-uclibc --prefix=/home/konstantin/fontconfigout --with-arch=blackfin "CFLAGS=-O2 -pipe -isystem /home/konstantin/uClinux/trunk/staging/usr/include -L/home/konstantin/uClinux/trunk/staging/usr/lib"

cd to src folder and open Makefile with your favorite editor and replace the empty versions of these same variables with

LTCOMPILE = $(top_builddir)/doltcompile $(COMPILE)

LTCXXCOMPILE = $(top_builddir)/doltcompile $(CXXCOMPILE)

the directory which was specified in the prefix needs to be created.

mkdir /home/konstantin/fontconfigout

cd /home/konstantin/fontconfigout

mkdir lib

now copy from your uClinux_dist/staging/usr/lib folder all the expat, freetype and zlib related libs and symlinks to the lib folder zou just created.

Go back to top directory of fontconfig and run

make

then

make install

now you should have fontconfig build and generated stuff ready to include in zour staging stuff (and romfs)

copy content of fontconfigout/lib to your staging/usr/lib and ramfs/lib (be careful, MERGE!!!)

copy content of fontconfigout/include to your staging/usr/include

copy content of fontconfigout/bin to your ramfs/bin

by now we are prepared to start building Xfbdev

1 ) GETTING THE Xorg TREE

get the git script as described in the link above. Or here

http://xorg.freedesktop.org/wiki/ModularDevelopersGuide?action=AttachFile&do=view&target=git_xorg.sh

modify it, do download the fonts as well. See same guide above.

…

do_dir driver "${driver}"

do_dir font "${font}"        # this line added to get fonts

do_dir lib "${lib}"

…

Move it to a directory where to download the Xorg source tree,

say uClinux_dist/trunk/user/xorg_git

and make it executable

chmod a+x git_xorg.sh

run

$ ./git_xorg.sh > gitres 2>&1

And take a nap…:)

A full tree looks like

$ ls -F

app/  data/  doc/  driver/  drm/  font/  git_xorg*  lib/  pixman/ proto/  util/  xcb/  xserver/

2)    APPLY CHANGES To TREE

Cd to xorg_git top directory.

First, replace the build.sh script in util/modular

With my own. Here. There are some changes considering the case we are crosscompiling..

Replace util/modular/build.sh

Replace lib/libXt/configure.ac

Replace lib/libXt/util/Makefile.am

Replace lib/liblbxutil/configure.ac

Replace lib/liblbxutil/src/Makefile.am

Replace lib/libX11/configure.ac

Replace lib/libX11/src/util/Makefile.am

NOTE: dont forget to rename them back....

Edit the xserver/hw/kdrive/fbdev/fbdev.c somewhere around line 70

And change the mmap flags there from MAP_SHARED to

MAP_PRIVATE | MAP_FILE

Replace xserver/include/servermd.h

3) BUILD PROCESS

Unlike in the Xorg guide, we don’t need to specify the PATH var, it is already done in the build.sh. But keep the prefix output directory always the same.

keep this order from build.sh in mind. If there is any error you can correct and resume execution at the specified package point. See later how.

____

# We must install the global macros before anything else

build util macros

#build_doc

build_proto

build_lib

build data bitmaps

build_app

build_mesa

build_xserver

build_driver

build_data

build_font

build_util

Cd to the xorg_git top level directory

And run (FOR BUILD ALWAYS RUN FROM THIS DIR)

./util/modular/build.sh -c /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1 &

You can tail builders, to see where the build process is, but redirecting output will really speed up things.

Hopefully, the build process will not halt due to error before the libX11 package.

The problem is described in the CrossCompile ref, that barely the packeges supprt cross compiling. So we have to correct the use of some utils needed at buildtime, so they might build using gcc and not bfin gcc.

Cd to xorg_git/lib/libX11/src/util

Edit Makefile

And change the line with

CCLD = $(CC)

to CCLD = $(CC_FOR_BUILD)

cd to xorg_git/lib/libX11

and run

make

make install

now there are hopefully no errors.

Continue build with the next package (see in build.sh), it’s the lib/libXext

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r lib/libXext /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1 &

Again the build process will halt hopefully not before package libXt

Cd to xorg_git/lib/libXt/util

Edit Makefile in same way like before

Run make and make install from library package top dir (xorg_git/lib/libXt/)

Resume build with

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r lib/libXmu /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1 &

it will mourn in the libpciaccess..we don’t need it, so we leave it out, and resume the next package, pixman

resume with

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r pixman/ /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1 &

it still will halt in the same package, complaining that for some test routines it does not have the gtk-x11-2.0, if some one needs it or knows how to insert it relay in a fast and easy manner into the distro, then please….let me know.. this is my next stuff to do. Creating GUI APPS

cd to xorg_build/pixman

edit Makefile and change the SUBDIRS variable removing the test dir

make

make install

resume with

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r data/bitmaps /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1 &

it now will stop with one of the applications, showing that the libs necessary are not acessable. Now i don’t know why, because they are supposed to be in same directory of xorg_build/lib.. if anyone finds out why, let me now..

so far we leave apps out, they seem to have all the same problems, logically

This time we hope that execution will proceed passing the xserver package, so we need to resume and specify already some flags for the xserver package, they will be passed when its time..(note: this is not included in original build.sh)

run

konstantin@apollo:~/uClinux/trunk/lib/fontconfig> ./util/modular/build.sh -c -x "--enable-kdrive --disable-kdrive-vesa --disable-xephyr --disable-xorg --disable-xorgcfg --disable-dri --disable-dri2 --disable-glx --disable-ipv6 --disable-xgl --disable-xglx --disable-xsdl --disable-xwin --disable-xnest --disable-xvfb -disable-xquartz --disable-dmx" -r xserver/ /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1 &

Now we hope that the build process will halt in driver section, having successfully build Xserver. The build process will halt in building the drivers..no idea why.

I remember having had to copy xserver/xorg-server.m4 to my xorg_build/share/aclocal

If there is a complaint about undefined macro, try that..seems to be a bug in the build system. This is specially the case if resume with xf86-video-fbdev and get errors like

./configure: line 20048: syntax error near unexpected token `RANDR,'

> ./configure: line 20048: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'

So first copy the m4 macro to its place in aclocal and then resume building drivers, directly to the fbdev driver. We don’t need the x server flags no more, since the Xfbdev server is build.

Resume with

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r driver/xf86-video-fbdev /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1

we still get an amount of errors, concerning not encountered headers. I assume that the video drivers are only relevant to the real Xorg Xserver, the big brother.

Resuming the xf86-input-keyboard driver spits the same problem

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r driver/xf86-input-keyboard /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1

resuming to the mouse driver

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r driver/xf86-input-mouse /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1

same errors, and same with xf86-input-void, resuming

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r driver/xf86-input-void /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1

I really think that those driver stuff modules are only relevant for the big Xorg, since the Xfbdev is assumed to run on a variety of platforms on the run, specifying mouse and keyboard stuff in the command line. This is to be figured out.

ADDITION: I had experimented with the new Xfbdev, seems it needs the drivers really SO THIS IS TO BE DONE

We proceed to data/cursors

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r data/cursors /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1

It hopefully will pass to the font section, but complaining that the ucs2any cant be executed, this is due to being compiled with bfin gcc, but the build process needs it itself.

Cd to xorg_git/fonts/util and edit the Makefile, changing CC variable to simply gcc

Then,

make clean

make

and

make install

This makes it possible to compile the rest of the fonts

konstantin@apollo:~/uClinux/trunk/user/xorg_git> ./util/modular/build.sh -c -r font/encodings /home/konstantin/uClinux/trunk/user/xorg_build > buildres 2>&1

now this should compile to the end.

5) CONGRATULATIONS, you have got your new Xfbdev

6) MERGE

we need to copy over all the generated stuff to the distrib romfs (and probably staging/usr/..)

Cd to your xorg_build dir

At the beginning merge the content of lib into uClinux_dist/staging/usr/lib and uClinux_dist/romfs/lib. Be carefull with pkgconfig not to overwrite all the others, merge!!!

There is a lot of data unneeded, especially the X11/fonts, you may delete all except for encondings, misc and util..also delete the big Japanese and Korean fonts in misc..search for size Strip it like that maybe only in the romfs/lib, the staging/usr/lib does not matter.

Merge bin content to romfs/bin. You can delete Xepson.

Merge include content into staging/usr/include.

7) REBUILD DISTRO

Ok, the heviest part is past. To try the server, you probably need to strip your distro, and make clean. (Running the risk of having to repeat all the merging steps above for the sake of space).

To be able to build again, zou will have to set the block size of the genext2fs call in the

uClinux/vendors/AnalogDevices/BF527-EZKIT/Makefile

there, change the BLOCKS variable accordingly, maybe to 32768. It seems as if it is still not possible to adjust that in the Kconfig infrastructure.

Take care of not having your Comrpessed uImage bigger than those 16 MB, after which there will be an overlapping of loaded compressed section and decompressed section of kernel. See http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:tftp_loading_files&s[]=overlap

Rebuild your distro, reboot the board.

8) USING Xfbdev

After boot is done:

I havent figured out why Xfbdev is trying to acess the lib and fonts folder with the old build path of build machine

(/home/konstantin/uClinux/trunk....)..I placed a symlink lib in /home/konstantin/uClinux/trunk/user/xorg_build/ to /lib

Now Run

Root:|> .Xfbdev –ac

-ac disables access control so you can start executing remote applicatioins, since we could not build our own with the tree.

On your buildsystem you can run

xclock –display 192.168.1.88:0 –u 1

being IP address of your board and the u flag is the number one, enabling the seconds arrow

to see server in action.

For those who came along with drivers and have built them and integrated: You might run

Xfbdev –ac -mouse mouse,/dev/psaux -keybd keyboard

And if you want to query an XDMCP client to start a remote session J on your blackfin, YEAH, that’s possible..welcome to remote lonux world.

Xfbdev –ac -mouse mouse,/dev/psaux -keybd keyboard -query 192.168.1.69

beeing IP Adress of the remote client

I point out that is provided the case you have build the drivers. Neither I couldn’t.

Or you can remotely manage it all with i.e fvwm..or any other window manager..now there is the advantage

fvwm –display 192.168.1.88:0

again being IP  address of your board.

NOW, if zou really came that far, RESPECT!!!

10) CONCLUSIONS:

If there is anyone who knows how to really strip the Xfbdev, using more special flags, and which libs are not used and could be deleted, and which fonts are used and how they are configured, please post it. I still believe that we could get our Xfbdev+libs+fonts to around 2.5 MB, thus offering a real alternative to nano-X, not in terms of memory (which in my opinion is not that big deal, really, 32 MB or 64 MB, it matters 1 $ J) but in terms of the free world of X11 toolkits like GTK, QT, FLTK (which also exist for nano I think). See http://wiki.neurostechnology.com/index.php/XServer

But the real goal is the remote execution ability and the clear known API. (almost clear).

There is still a lot of fine tuning, it is complaining that much about fonts, no drivers can be compiled nether apps in the Xorg package.BUT IT WORKS, which is really astonishing. having decided on one Toolkit, one can stick to develop GUI apps really on build machine..and try it out on host. But zou know all those benefits as well.

OK, I will try to add the tslib driver to that. Enjoy it.

Xorg.zip

Xorg.zip

QuoteReplyEditDelete

2008-05-27 06:52:21     Re: Kdrive Xfbdev server instead of microwindows

Konstantin Hartwich (GERMANY)

Message: 56300   

News about trying progz runnning on Xfbdev:

I dont know if anyone tried to run any program with Xfbdev. I did..

The Xfbdev Server seems to have its problems with the Framebuffer driver offered in the distro. the typical screen of X (with the mouse X in the center) seems like alised.

Doing a -query (XDMCP) to my suse box, seems to work by protocol, but the screen (varitronix, on bf527 ezkit) looks weired, shows hardly any colors, seems like compressed or something..has to be a problem with Kdrive, since Nano-X is working fine on that. running Xfbdev with explicit -screen 320x240x24 option has no effect.

I couldnt compile any native Xorg apps like xterm for the blackfin (cant acces the libs for some reason..no idea why). so i tried the fltk progz which work fine with nano-X through the nxlib (libX11 API fake). so expecting the same behavior i started the progz on native Xfbdev X11 API.  strange look, one can recognize the elements, buttons etc..but the are not where they are supplosed to be and again a look like compressed colors..Command was like

clock -display

thus bzpassing the tcp stack uing file io i think

i tried to run those progs on the blackfin with output to another X server by specifiing i.e  

clock -display 192.168.1.69:0

it reads Cant open display 192..

I tried

clock -display 127.0.0.1:0

which should do, since is same host, but same error occurs.

Has anyone an idea or suggestion where to continue?

QuoteReplyEditDelete

2008-06-12 09:22:34     Re: Kdrive Xfbdev server instead of microwindows

Andras Szemzo (HUNGARY)

Message: 57132   

hi,

yesterday I successfully compiled Xserver to bfin. I'm using a custom bf532 based board.

I'm not using the git version, instead I started from the xorg7.3 avr32 sources:

http://www.avr32linux.org/twiki/bin/view/Main/XWindows

It took almost a day to compile, and I have a lot of (I think) unnessesary libs and fonts too.  Later  I'll try to strip it.

I did some custom build scripts, not so usefull at the moment, becouse  I had  to check every lib if it's compiled successfully.

The xserver is running OK. (After adding the mmap patch) I compiled only some example apps, like xclock, and it's running ok too.

I added tslib too, but I have to check if it's working too. (It works ok in nano-X and QT embedded)

Today I compiled Mesa GL library successfully, just for test/fun, evening I'll test if it's working or not.

Best Regards,

Andras

QuoteReplyEditDelete

2008-06-12 11:44:55     Re: Kdrive Xfbdev server instead of microwindows

Andras Szemzo (HUNGARY)

Message: 57158   

hi,

I just would like to report that glxgears running as fast as ~4FPS in 320x240 fullscreen mode... :))

Kép008.jpg

Attachments: