Hi Pier, I don't know if you are interested in this but i have successfully managed to compile XDirectFB (based on xorg-server-1.5.3) for ARM920T. It was quite lengthy and painful process but i also managed to automatize everything (compilation) with shell scripts so now its a one command thing :).
Let me know if you are interested. P.S.: If you don't want xdirectfb you may want to check you the KDrive Tiny X Server... Regards, Gabriel Zabusek On Fri, Aug 21, 2009 at 4:33 PM, Pier Castonguay < [email protected]> wrote: > Hi Niels, > > Thx for the answer, even if late. > You are right, my device don't use any hardware gfx acceleration. > About my TSLIB problem, it was because I had PS/2 inputs configured too and > it was giving two different inputs at once at every click. > > I've made a long way since then. Managed to use crosstool-ng to create a > fpu > patched, up-to-date gcc/glibc crosscompiler, using the EABI interface. This > gives a massive speed boost. I then compiled over 20 libs with it, creating > a basic rootfs. Then compiled DFB, with cairo and gtk+ using it's backend. > > It's faster, but because of EABI, not directfb. > > I'm now trying (with difficulties, their script seems bugged) to > cross-compile Xorg instead of DFB for many reasons: > -GTK+ refreshing handle differently. On call .show() DFB show to window > (with old content), then repaint. With X it repaint, then show. Some things > simply never repaint with DFB. > -TSLIB sometime don't send the button_release event. > -Most importantly, pango with DFB is a MASSIVE bottleneck. Refreshing a > single label (a clock) every second with Xorg-OABI takes 10% cpu, with > DFB-EABI it takes 50%!. > > More info about my findings are there: > http://tech.groups.yahoo.com/group/ts-7000/message/15711 > > -Pier Castonguay > > -----Message d'origine----- > De : Niels Roest [mailto:[email protected]] > Envoyé : 21 août 2009 10:04 > À : Pier Castonguay > Cc : [email protected] > Objet : Re: [directfb-users] GTK-Direct FB not much faster than GTK-Xorg > > Hi Pier. > > late answer but maybe still interesting. > > DirectFB has two main reasons for giving a speed boost: > - simpler architecture - this is more or less swallowed by the other > packages build on top > - hardware acceleration - this is probably your problem - you need a > graphics driver for your TS, which I am guessing you don't. > > Fusion is not your problem, this line: > > (*) DirectFB/Core: Single Application Core. (2009-06-23 13:00) > > states that it is running in "single" mode (instead of "multi") so > without fusion interfering. > > I cannot comment on the touch screen, don't know where the location > problem is coming from. > You might wanna configure directfb with "--enable-debug" and use a > directfbrc with "debug=Core/Input/Evt" or "debug=Core/Input" for more > debug messages about event handling. > > Greets > Niels > > Pier Castonguay wrote: > > > > Hello all. > > > > After a while, I finally managed to port my GTK+ application to use > > DirectFB instead of Xorg. Unfortunately, it did not give the speed > > boost I was expecting. > > > > My device is a TS-TPC-7390 running a Cirrus EP9302 processor (ARM920T) > > so the architecture is armv4tl. Here is what I did, and fortunately > > someone can point me to something I did wrong/forgot. > > > > I have Debian-etch from TS website, and found out most libs were too > > old to enable DirectFB support in GTk+, so I started rebuilding them > > all from source. I realized afterward that I should have simply > > upgraded my distribution, but anyway. Here a list of what I recompiled > > (versions which are a few years more recent than what I had): > > > > autoconf / automake / libtool / gettext / glib / glibmm / atk / cairo > > / cairomm / fontconfig / freetype / gtk+ / gtkmm / jasper / libglade / > > libglademm / pango / pangomm / pixman / tiff / tslib > > > > So as you can see, this is quite a bunch. I first compiled them with > > “-g” flag, and afterward used “strip –strip-unneeded” to remove debug > > information, which got a small speed gain, but not that much. > > > > I didn’t have to specify any special settings to DirectFB, seems like > > it detected my framebuffer with no problems. Application ran with no > > problems, simply some minor gfx glitch (not big problem). I also have > > some warning messages. Here is the DFB log when starting the application: > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.3.1 |~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > (c) 2001-2008 The world wide DirectFB Open Source Community > > > > (c) 2000-2004 Convergence (integrated media) GmbH > > > > ---------------------------------------------------------------- > > > > (*) DirectFB/Core: Single Application Core. (2009-06-23 13:00) > > > > (*) Direct/Memcpy: Using armasm_memcpy() > > > > (*) Direct/Thread: Started 'VT Switcher' (1463) [CRITICAL OTHER/OTHER > > 0/0] <2093056>... > > > > (*) Direct/Thread: Started 'tslib Input' (1464) [INPUT OTHER/OTHER > > 0/0] <2093056>... > > > > (*) DirectFB/Input: tslib touchscreen 0 0.1 (tslib) > > > > (*) Direct/Thread: Started 'PS/2 Input' (1465) [INPUT OTHER/OTHER 0/0] > > <2093056>... > > > > (*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org) > > > > (*) Direct/Thread: Started 'Linux Input' (1466) [INPUT OTHER/OTHER > > 0/0] <2093056>... > > > > (*) DirectFB/Input: CHICONY USB Keyboard 0.1 (directfb.org) > > > > (*) Direct/Thread: Started 'Keyboard Input' (1467) [INPUT OTHER/OTHER > > 0/0] <2093056>... > > > > (*) DirectFB/Input: Keyboard 0.9 (directfb.org) > > > > (*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (directfb.org) > > > > (*) DirectFB/Core/WM: Default 0.3 (directfb.org) > > > > (*) FBDev/Mode: Setting 800x480 RGB16 > > > > (*) FBDev/Mode: Switched to 800x480 (virtual 800x480) at 16 bit > > (RGB16), pitch 1600 > > > > (*) FBDev/Surface: Allocated 800x480 16 bit RGB16 buffer (index 0) at > > offset 0 and pitch 1600. > > > > (tmg-arm:1434): Gdk-CRITICAL **: gdk_drawable_set_colormap: assertion > > `cmap == NULL || gdk_drawable_get_depth (drawable) == > > cmap->visual->depth' failed > > > > (*) Direct/Thread: Started 'EventBufferFeed' (1468) [MESSAGING > > OTHER/OTHER 0/0] <2093056>... > > > > (tmg-arm:1434): Gdk-DirectFB-WARNING **: gdk_window_set_keep_above() > > not implemented. > > > > (tmg-arm:1434): Gdk-DirectFB-WARNING **: gdk_window_set_keep_below() > > not implemented. > > > > Also, when I kill the application: > > > > (!!!) *** WARNING [still objects in 'Window Pool'] *** [object.c:241 > > in fusion_object_pool_destroy()] > > > > (!) [ 1434: 0.073] --> Caught signal 2 (sent by the kernel) <-- > > > > (!!!) *** WARNING [still objects in 'Layer Region Pool'] *** > > [object.c:241 in fusion_object_pool_destroy()] > > > > (!!!) *** WARNING [still objects in 'Layer Context Pool'] *** > > [object.c:241 in fusion_object_pool_destroy()] > > > > (!!!) *** WARNING [still objects in 'Surface Pool'] *** [object.c:241 > > in fusion_object_pool_destroy()] > > > > I don’t think it’s anything problematic. > > > > Since my application is alone, could I bypass Fusion? Would it improve > > performances? Any other things I should look for performance? > > > > Another big problem is the input of the touchscreen. When I was using > > directly the kernel module and Xorg, it was behaving a lot better than > > it is now using TSLIB. I have calibrated it with ts_calibrate, set up > > the ts.conf file and the env variables, and dfb use it. When I press, > > the cursor is set about 200 pixels from where I clicked, and then > > moves very quickly to the correct position. Holding the cursor and it > > eventually get to the correct place, but quickly clicking don’t. Also, > > some clicks don’t get handled, and most importantly, it sometimes > > randomly click to places far away from where I pressed (the > > ~200pixels). Judging from my start log above, it loads the PS/2 mouse > > (don’t have any) and it loads the keyboard twice. Could they interfere > > with the touch screen input? > > > > Anything else I should know?? > > > > Thx for any help. > > > > -Pier Castonguay > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > directfb-users mailing list > > [email protected] > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users > > > > > -- > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > > > _______________________________________________ > directfb-users mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users > -- .............................................................................................................................................. "...the finding of new proofs for known truths is often at least as important as the discovery itself..."
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
