On Mon, Feb 01, 2010 at 10:22:24AM EST, Oliver Gabel wrote: > Chris Jones wrote:
>> I have read some promising articles about DirectFB and experimenting >> with it on a debian squeeze system, but I am still unclear as to what I >> can do for me, leading to ask a few questions. >> >> 1. I understand DirectFB is a low resource replacement for X with a few >> caveats which might make it of interest no only in the context of >> embedded devices but also on slightly challenged desktop hardware, in >> my case, Pentium III with 386 Meg of RAM. >> >> Am I correct in assuming this? > Depends on what you mean by 'replacement'. > > X is a hardware accelerated graphics subsystem, a network protokoll > and a windowing system. It is old (1985), large, complex and bloated, > and it does not allways provide a maximum of hardware acceleration. > However, it is a de facto standard. 99% of all graphical linux/unix > applications were written for X. > > DirectFB is a modular hardware accelerated graphics subsystem. It > provides an optional windowing system. It is sleek, very fast and has > a small memory footprint Well replacement means that you can use one instead of the other. Or in other words, you are saying that DirectFB does not provide the networking capabilities that 'X' does. Apart from that, they would appear to be functionally equivalent. >> 2. I used a test debian squeeze sacrificial environment for a >> preliminary round of testing and much to my surprise the DirectFB >> lib's were already installed. I proceeded to apt-get the >> DirectFB/gtk package, assuming I would be able to use my >> environment to run DirectFB on top of my ramebuffer console -- >> that there was some command or other that I could enter at the >> bash prompt such as 'startdfb' maybe, that would pretty much do >> what 'startx' does and that I would find myself in a graphical >> environment where I might be able to start a terminal emulation >> or a web browser, but I could not find anything that looked like >> it might do this, either by grepping my system or googling for >> DirectFB howto's. Or to take another example, what I was looking >> for was something akin to the fbiterm command that lets me start >> a 256-color capable terminal emulator on top of the linux >> framebuffer. > fbterm is a native DirectFB terminal emulator. It works and it's > pretty neat. Actually, saying that DirectFB applications such as > dfbterm 'run on top of the linux framebuffer' is kind of missleading. > They are running on top of DirectFB. The linux framebuffer device > /dev/fb is only used for memmapping the graphics memory to your > applications process space on startup and for modesetting. I was, note the spelling, referring to fbiterm. It does not appear to be in any way connected to DirectFB, or at least the output of ldd fbiterm doesn't suggest it. After I log in at the getty prompt, I currently have three options: 1. Run applications on top of the terminal emulation provided by the kernel - aka the 'linux console'.. with possibly an intervening multiplexer such as GNU/screen 2. Start an enhanced terminal emulation via the fbiterm command. This mostly gives me access to 256 colors and unicode capabilities that are not provided by the linux console. The result is that I can function as if I was running on uxterm with 256 colors and therefore do not need separate configuration files for my applications. 3. start X so as to be able to run graphical applications. This is the reason I mentioned fbiterm in this context, in the sense that DirectFB would provide me with an additional opton to investigate. What I don't understand is that the DirectFB lib's are already installed on this system, so they must have been pulled when I installed something else -- will have to check to apt log files and see how it came to be. What I don't know is what executable I need to run to bring up the equivalent of an X server. >> Is this the way DirectFB works, or am I misunderstanding >> DirectFB's design? >> >> 3. Since the applications I use on a daily basis were designed to >> work in the context of an X server, does this mean that I would >> need specific versions of xterm, GNU/screen, mutt, slrn, ELinks, >> etc. to be able to function under DirectFB instead of X? > No, you're misunderstanding things. DirectFB has nothing to do with X. > Your desktop (be it KDE, Gnome, Xfce, or an X window manager) and the > applications it comes with were written and compiled for X. > Specifically, the toolkits that they are written with (e.g. qt, gtk, > etc.) are compiled for X (they are linked to Xlib) and they need an > open X display connection, otherwise they will not run. However, > there is an X server implementation that uses DirectFB for rendering, > but nevertheless provides this 'X environment'. It is called > XDirectFB. Hm.. that's exactly what I had in mind when I mentioned 'specific versions' of the applications above. > Quoting from http://en.wikipedia.org/wiki/Directfb : > "DirectFB can host XDirectFB, a rootless X server implementation that > uses DirectFB windows for X11 top-level windows. XDirectFB is an > interface that mimics the X11 interface through the DirectFB API to > simplify running applications written for X11 on DirectFB." > You can install XDirectFB, kill your normal X server and run XDirectFB > instead. This way you could run your usual Desktop, but have the > rendering be done by DirectFB underneath. > > If you have a gtk application (that has no other X dependencies), you > could compile/install directfb-gtk and then compile and link your gtk > application against the directfb-gtk libs. This way you could run your > gtk application _natively_ under DirectFB (not requiring XDirectFB). OK, this makes sense. The reason I missed that in the wiki is that I run debian lenny and I do not see any package named XDirectFB in the repositories, or anything that might implement this functionality. As far as I can tell, the closest would be libgtk-directfb but it looks more like a development tool than a runtime conversion layer that would let one run applications compiled against X toolkits under directfb. >> 4. Since I made the decision to run my applications full-screen a >> long time ago, and use mostly text-mode applications under >> GNU/screen, I only need a couple of the features that are provided by >> an X window manager, namely multiple desktops/workspaces and the >> ability to switch from one to the other via a keyboard action, and to >> accomodate my slothful nature, binding a few keyboard combos to the >> launching the applications that I run frequently. I have used Window >> Maker for a number of years and I doubt that it would happily run >> under DirectFB out of the box, so I'm wondering if such capabilities >> are provided by DirectFB, either natively or via some form of window >> management extension. > Again, Window Maker is an X window manager. It has been designed and > written for X. It will only work under XDirectFB. A full fledged window > manager such as Window Maker does not yet exist natively for DirectFB. > However, you could write one :-) Since I will need XDirectFB anyway, I guess I might as well stick with Window Maker. And come to think of it, as long as I can switch to another VT, I don't even need a window manaber. So, do I need to obtain XDirectFB from a tarball so as to proceed.. what am I supposed to do to bring up a DirectFB environment.. I remain in the dark where these aspects are concerned. Thank you for your comments. CJ _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
