4 ms·

DirectFB

52 points by jasonhansel 9y ago

yjftsjthsd-h 9y ago
Okay, I'll bite: last post says it got moved to new, cheaper hosting to it wouldn't go offline. This submission is on archive.org. What happened? Neat project, though :)
- icantdrive55 9y ago
  There's a need for cheap/free(unobtrusive ads ok.), trustworthy Server. Simple server. I know about the free Google, and Heroku freeplans, but just want something simpler for my vanity sites. I don't need it to Scale. For small websites that aren't going to blow up. It does need to be located in the USA though. It needs to be free. 000webhost used to offer free servers, but now want the customer to pay unless you feel fine with premiumname.com.000wehost.noway Yes--I'm cheap. I just feel if done correctly, a company might be able to make some money? Server site requirements: Not flashy, USA located, Free for a few years. (Build a reputation before begging for debt/cc? Many people just want a trustworthy site to put the cat website, or their delusional dream site.) I know about the low cost ones, but don't trust them with my numbers. Hot Server, "But how do I pay for my electrons? Who's going to repair me?" I don't know, but figure it out? I'm too stupid. (Only for small websites--fine!)
kickitover 9y ago
Ah memories. DirectFB was an awesome project, unfortunately, if I am not mistaken, it was only targeted at Linux at the time. Another project, that now X.org+Linux are re-implementing extremely poorly, was the Kernel Graphics Interface (http://kgi-project.org http://kgi-project.org). KGI was an incredibly well engineered API, portable GPU interface, and reference implementation for FreeBSD-8.x and Linux-2.x, providing modern features and GPU programming paradigms to Linux and Unix systems; monolithic or micro-kernel designs. KGI required the General Graphics Interface for a complete user experience, as in, a replacement X server called XGGI, however, it also functioned very well without X or any other heavy graphical windowing system analogous to The X Window System, it was engineered for embedded systems too. GGI was an amazing project too, with it's platform agnostic way to draw graphics via it's multiple display targets or surfaces; DirectFB; SDL; DirectX; KGI; X11; VGL; foo. I suspect both were well over engineered, and at the time, the patches for KGI were rather large, and I believe the Linux crowd did not want GPU mode-setting in the kernel, a shame, because KGI's mode-setting was next level at the time and it could be tightly integrated with the rest of KGI, or remain a mini driver in the kernel. KGI did have some odd constructs that sometimes made for some mental acrobatics; focuses; displays; devices; odd client-server model between all the devices, it almost became a complex beast on first glance. It actually made way for a true GPU multi-headed and multi-user system, that provided fine grained security between devices or users to the GPU, managed by a brilliant low-level, or kernel level multiplexer of the low-level or kernel console, virtual terminals and other applications (or clients) to the devices (focuses/or inputs and the display). Some of their code was stuck in the late 90s and the interface was rigid regarding what a GPU was at the time, however, that could have been changed, as there were updated specifications for next generation ideas for KGI based on where GPU development was going at the time. If I recall correctly, there were GPU vendor developers volunteering at KGI, and, I could be mistaken, but when AMD bought ATi, one of the last GGI developers/volunteers worked at AMD, and they worked with other AMD engineers to convince AMD to eventually release hardware data-sheets and specifications on ATi GPU hardware, and it happened. A shame neither took off, and we are now left with X.org's insistence on Linuxisms for GPU development. Sorry for hijacking the thread, but thanks so much for the trip down memory lane :-)
ashleyn 9y ago
DirectFB was great for small embedded systems projects where you didn't want the full weight of X. Unfortuntaely I don't think there's any alternative to X any longer for these kinds of projects, probably because the cost of a SoC capable of running X has fallen to the point where it doesn't make sense to economise anymore.
- craftyguy 9y ago
  This was primarily the reason why I chose to write the disk decryption keyboard/unlocker for postmarketOS to use directFB (by way of SDL2). Putting X into an initramfs is absurd. It's very unfortunate that DirectFB seems to be abandoned now.
thisacctforreal 9y ago
See also http://tekui.neoscientists.org http://tekui.neoscientists.org
- walterbell 9y ago
  Is that currently maintained?
  - thisacctforreal 9y ago
    http://hg.neoscientists.org/tekui/ http://hg.neoscientists.org/tekui/ Last release was early 2015. Last change to the repo was 15 months ago.
    - squarefoot 9y ago
      Last time I checked it still compiles and runs fine on modern Debian systems. The only caveat is to edit its configuration file to look for (if necessary) the actually installed version of Lua. edit: minor correction
- squarefoot 9y ago
  Tekui is a great project, I wish there was something with comparable integration to other small languages such as Nim et al. Years ago I tried it with DirectFB output on an old A10 board (Hackberry IIRC). I was never able to sort out why the screen was shifted left (or right) by several dozen pixels, probably a bug somewhere, but performance on that limited processor was fairly acceptable.
noobermin 9y ago
Is there any similar library that is still under development?
buserror 9y ago
To be fair, even a while back it became pretty easy to use fbdev (memory mapped), and Cairo to draw on it. For event handling eventfd (and now libinput) also became quite a bit easier to use as well so many many years ago I decided to cut out the middleman (direcfb) and do it with these instead.

52 points by jasonhansel 9y ago

Okay, I'll bite: last post says it got moved to new, cheaper hosting to it wouldn't go offline. This submission is on archive.org. What happened? Neat project, though :)

icantdrive55 9y ago
There's a need for cheap/free(unobtrusive ads ok.), trustworthy Server. Simple server. I know about the free Google, and Heroku freeplans, but just want something simpler for my vanity sites. I don't need it to Scale. For small websites that aren't going to blow up. It does need to be located in the USA though. It needs to be free. 000webhost used to offer free servers, but now want the customer to pay unless you feel fine with premiumname.com.000wehost.noway Yes--I'm cheap. I just feel if done correctly, a company might be able to make some money? Server site requirements: Not flashy, USA located, Free for a few years. (Build a reputation before begging for debt/cc? Many people just want a trustworthy site to put the cat website, or their delusional dream site.) I know about the low cost ones, but don't trust them with my numbers. Hot Server, "But how do I pay for my electrons? Who's going to repair me?" I don't know, but figure it out? I'm too stupid. (Only for small websites--fine!)

kickitover 9y ago

Ah memories. DirectFB was an awesome project, unfortunately, if I am not mistaken, it was only targeted at Linux at the time. Another project, that now X.org+Linux are re-implementing extremely poorly, was the Kernel Graphics Interface (http://kgi-project.org http://kgi-project.org). KGI was an incredibly well engineered API, portable GPU interface, and reference implementation for FreeBSD-8.x and Linux-2.x, providing modern features and GPU programming paradigms to Linux and Unix systems; monolithic or micro-kernel designs. KGI required the General Graphics Interface for a complete user experience, as in, a replacement X server called XGGI, however, it also functioned very well without X or any other heavy graphical windowing system analogous to The X Window System, it was engineered for embedded systems too. GGI was an amazing project too, with it's platform agnostic way to draw graphics via it's multiple display targets or surfaces; DirectFB; SDL; DirectX; KGI; X11; VGL; foo. I suspect both were well over engineered, and at the time, the patches for KGI were rather large, and I believe the Linux crowd did not want GPU mode-setting in the kernel, a shame, because KGI's mode-setting was next level at the time and it could be tightly integrated with the rest of KGI, or remain a mini driver in the kernel. KGI did have some odd constructs that sometimes made for some mental acrobatics; focuses; displays; devices; odd client-server model between all the devices, it almost became a complex beast on first glance. It actually made way for a true GPU multi-headed and multi-user system, that provided fine grained security between devices or users to the GPU, managed by a brilliant low-level, or kernel level multiplexer of the low-level or kernel console, virtual terminals and other applications (or clients) to the devices (focuses/or inputs and the display). Some of their code was stuck in the late 90s and the interface was rigid regarding what a GPU was at the time, however, that could have been changed, as there were updated specifications for next generation ideas for KGI based on where GPU development was going at the time. If I recall correctly, there were GPU vendor developers volunteering at KGI, and, I could be mistaken, but when AMD bought ATi, one of the last GGI developers/volunteers worked at AMD, and they worked with other AMD engineers to convince AMD to eventually release hardware data-sheets and specifications on ATi GPU hardware, and it happened. A shame neither took off, and we are now left with X.org's insistence on Linuxisms for GPU development. Sorry for hijacking the thread, but thanks so much for the trip down memory lane :-)

ashleyn 9y ago

DirectFB was great for small embedded systems projects where you didn't want the full weight of X. Unfortuntaely I don't think there's any alternative to X any longer for these kinds of projects, probably because the cost of a SoC capable of running X has fallen to the point where it doesn't make sense to economise anymore.

craftyguy 9y ago
This was primarily the reason why I chose to write the disk decryption keyboard/unlocker for postmarketOS to use directFB (by way of SDL2). Putting X into an initramfs is absurd. It's very unfortunate that DirectFB seems to be abandoned now.

thisacctforreal 9y ago

See also http://tekui.neoscientists.org http://tekui.neoscientists.org

walterbell 9y ago
Is that currently maintained?
- thisacctforreal 9y ago
  http://hg.neoscientists.org/tekui/ http://hg.neoscientists.org/tekui/ Last release was early 2015. Last change to the repo was 15 months ago.
  - squarefoot 9y ago
    Last time I checked it still compiles and runs fine on modern Debian systems. The only caveat is to edit its configuration file to look for (if necessary) the actually installed version of Lua. edit: minor correction
squarefoot 9y ago
Tekui is a great project, I wish there was something with comparable integration to other small languages such as Nim et al. Years ago I tried it with DirectFB output on an old A10 board (Hackberry IIRC). I was never able to sort out why the screen was shifted left (or right) by several dozen pixels, probably a bug somewhere, but performance on that limited processor was fairly acceptable.

noobermin 9y ago

Is there any similar library that is still under development?

buserror 9y ago

To be fair, even a while back it became pretty easy to use fbdev (memory mapped), and Cairo to draw on it. For event handling eventfd (and now libinput) also became quite a bit easier to use as well so many many years ago I decided to cut out the middleman (direcfb) and do it with these instead.