Hi! Thanks for the reply. In fact, I had only tried df_fire and df_matrix before. I had the same problem with DATADIR for the others. I'm still a beginner in linux so I did a "make install" directly on the device for the examples, and they all worked afterwards.
Now, surprisingly, most of the examples who use images from files (df_andi, df_neo, df_window) works in full color perfectly. Touchscreen input don't, but that's not the priority right now. Others examples who draw things to the screen (df_fire, df_matrix, df_palette) looks awfully wrong. Also, the non-working samples are the only ones who freeze on exit, the others don't. Exception is df_dok who seems to draw directly, and look great. Also, the non-working samples are the only ones who freeze on exit, the others don't. Judging from http://embedded-graphics.com/screenshots/df_matrix.png , mine just display the left half of the screen. Console messages are exactly the same as the correct examples (setting/switched/allocated 800x480x16 is printed 3 times, nothing about a fallback to another res). I checked loaded kernel modules, nothing about fusion. Thoses who might have something to do with the frame buffer are "ts7kvfb.ko, ts7370fb.ko and fbcon.ko). I found another thread about a guy who use the exact same device and had color depth problems, but on Qt. There's some important information on the pixel format (RRRRRGGGGGTBBBBB), if you are interested : http://lists.trolltech.com/pipermail/qt-embedded-interest/2009-January/00010 9.html . Right now I don't have time to re-compile the project with --enable-multi because it takes a long time and I don't know what it's used for. I can run dfbdump -dl neverless, here is the output (who don't gives much info): ts7000:~# dfbdump -dl ~~~~~~~~~~~~~~~~~~~~~~~~~~| 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-01 20:10) (*) Direct/Memcpy: Using armasm_memcpy() (*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER 0/0] <2093056>... (*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0] <2093056>... (*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <2093056>... (*) DirectFB/Input: TS-LCD (1) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <2093056>... (*) DirectFB/Input: CHICONY USB Keyboard (2) 0.1 (directfb.org) (*) Direct/Thread: Started 'Keyboard Input' (-1) [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. DirectFB uptime: 00:00:00 -----------------------------[ Surfaces ]------------------------------------- Reference FID . Refs Width Height Format Video System Capabilities ---------------------------------------------------------------------------- -- N/A : 2 800 x 480 RGB16 750k* 750k* video only double ------ ------ 750k 750k -> 1500k total ----------------------------------[ Contexts of Layer 0 ]---------------------------------------- Reference FID . Refs Width Height Format Location on screen Regions Active Info Level ---------------------------------------------------------------------------- --------------------- N/A : 3 800 x 480 RGB16 0.0, 0.0 -> 1.0, 1.0 1 (*) SHARED N/A (!!!) *** WARNING [still objects in 'Layer Region Pool'] *** [object.c:241 in fusion_object_pool_destroy()] So my real question is, what is the difference between working and non-working examples? Thx -----Message d'origine----- De : Niels Roest [mailto:[email protected]] Envoyé : 3 juin 2009 13:27 À : Pier Castonguay Cc : [email protected] Objet : Re: [directfb-users] Using DirectFB on TS7370 arm device, bad color depth Hi Pier, not sure what the problem is but can give some hints. first, RGB16 is RGB 5/6/5 where you seem to have RGB 5/5/5, but that should in fact make your screen look slightly pinkish. If you say 'to the right side of the screen' it sounds as if directfb switches resolution at startup; you should run fbset -i in the same terminal as your app, but that is quite impossible to do, so I would advise to run dfbdump simultaneously instead, which also gives some data on the currently selected format in the "layer" section. You need to have configured with --enable-multi though, and a working fusion.ko. dfbdump -dl can be interesting as well, this will dump the layer content as DirectFB sees it, so you can load it gimp or so to check. for the system-not-found issue, The DirectFB Makefile has a variable called MODULEDIR; Your systems are then searched in $(MODULEDIR)/systems. MODULEDIR can be overridden runtime by e.g. --dfb:module-dir=<your location>. hth Niels Pier Castonguay wrote: > > Hello! > > > First sorry if this is a duplicate, seems like I had problem posting > the first time around. > > > I'm trying to port a xorg/gtk application to use directfb instead for > faster speed. I got DirectFB-1.3.1 from the git source (to fix the > armasm_memcpy error). I first tried to cross-compile and copy the libs > but when running an example application I had the "no system found" > error. So I compiled directly on the arm device. It took a few hours > but it finally worked and exemples (cross-compiled) now execute. > > So I run df_matrix. Problem is, resolution and color depth it try to > use seems bad. Everything is gray/yellow and to the right side of the > screen. > > fbset gives me this: > > ts7000:~# fbset -i > > mode "800x480-61" > # D: 31.500 MHz, H: 31.754 kHz, V: 61.066 Hz > geometry 800 480 800 480 16 > timings 31746 128 24 28 9 40 3 > rgba 5/11,5/5,5/0,0/0 > endmode > > Frame buffer device information: > Name : TS7370 > Address : 0x60100000 > Size : 768000 > Type : PACKED PIXELS > Visual : MONO01 > XPanStep : 0 > YPanStep : 0 > YWrapStep : 0 > LineLength : 1600 > MMIO Address: 0x600ff030 > MMIO Size : 10 > Accelerator : No > > I then checked /etc/fb.modes but there was a list of un-related > resolution (imposible for this device). So I took the mode from fbset > and wrote it as the first one in this file. Unfortunately, no change > on df_matrix look. Startup messages looks a bit better (instead of > failing setting 2-3 modes, it say it accepted 800x480x16 directly, but > don't seems like it use it). > > I also tried to run with arguments like dfb :pixelformat=RGB16, but > no changes. > > My framebuffer seems correct, because catting a fullscreen color > picture directly to /dev/fb0 works. > > Also, if I start xorg, then open a console and start "df_matrix > --dfb:system=x11", it opens a new window and the colors are correct. > Still, the goal is to prevent the use of xorg. > > Finally, when starting the application in the console (with bad > colors), and exiting with "esc", it completly freeze my display until > I either reboot, or connect to the device with telnet and execute > startx. This isn't normal isn't it? > > Is there anything else I could check? > > Thx > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
