On 20 May 2017 at 13:14, LM <[email protected]> wrote: > I checked into DirectFB a few years ago. Was trying to get the FLTK > DirectFB port working with the latest version of DirectFB. The > DirectFB project was active at the time, but could not get much help > in the way of useful responses via the mailing lists. There are > several versions of DirectFB. I think the latest version they were > working on was supposed to work in conjunction with Wayland. > Different versions were geared to different things. I ended up using > an older version of the DirectFB library with patches from Debian ( > https://packages.debian.org/jessie/libdirectfb-dev ). Couldn't even > get DirectFB to build from source without the Debian patches. > > I use DirectFB to run SDL and SDL2 in framebuffer mode. You can run > SDL and SDL2 without DirectFB, but some applications built that way > crash when run. So, it's easier (more stable) for me to run SDL using > the DirectFB backend. > > I thought links used SDL as a backend. I remember building it at one > point and using SDL with the build. Don't remember if it was the > standard version or a modified version. Rogue Class Linux uses links > with a SDL backend ( http://rogueclass.org/ ) and I believe I may have > used the source code from there. Unfortunately, the Rogue Class Linux > source repository is no longer available. The developer of the > distribution is taking a break from programming for a while. You > could probably still contact him and ask about it though. > > Searching links with SDL brings up this link: > https://devel.dob.sk/links-sdl/ > I'm sure some of the handheld devices use links with the SDL backend. > So does Syllable desktop ( > https://sites.google.com/site/syllablesoftware/internet-network/links > ). > > I'd say running links with SDL is a good way to get it to work without > requiring Xorg. You can use DirectFB or nano-x as backends for SDL or > just run SDL directly via framebuffer. The nano-x project (formerly > microwindows) is active and I correspond with the developer who took > it over ( https://github.com/georgp24/microwindows-android-bin ). It > works on a variety of platforms including Linux, ELKs, android (and > I've even had some minor luck with a Windows port). However, the > developer hasn't been very interested in the state of SDL support for > nano-x. He's been more interested in FLTK, wxWidgets and earlier > versions of GTK+. > > I've been porting several SDL 1.2.15 applications to SDL 2.x. So, if > you have a version of links you like that's working with SDL 1.2.x, it > isn't too hard to add support for SDL 2.x if you no longer want the > older version of SDL on your system. > > You should definitely be able to get links running in framebuffer mode > with SDL. I'd use SDL over SVGAlib. It's more actively > supported/developed. I remember having issues with SVGAlib at some > point, but don't remember the details. SDL was easier to get working. > Whether you want to use DirectFB, nano-x or the framebuffer directly > with SDL is up to you, but at least there are several options. >
Thanks for a really detailed response. I've had a look at all your links and the upshot appears to be that the Links browser would need to be patched to work with SDL. There is a patch that you linked to, but it is quite old and I would be surprised if it still worked. It may do, or it might require updating. I haven't yet had time to try it. The last time I built Links, DirectFB was still a viable backend, and it worked well. I'm looking for something fairly simple to build (I have limited time available) and it would need to be fairly recent software, preferably that's well supported. Although, as I've said, the latest SVGAlib version is pretty old, it still appears to be the best bet for me, particularly as it's still in the Slackware repo. Richard
-- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
