Google Chrome over Linux FrameBuffer

Question

I am working on a project where I need to run Google chromium over Linux FrameBuffer, I need to run it without any windowing system dependency ( It should draw on the buffer we provide it to draw, this will make its porting to any embedded system very easy) , I do not need its multi-tab GUI, I just need its renderer window in the buffer, has any body ever tried this? Any help on what approach should I use for this?

Solution 1

If you need to have some direct control of the window functions, or want to poke around in the DOM data, then the right way to solve this problem is to probably look at embedding webkit directly. This will be much faster and cleaner than what I am about to suggest.

Now, let's suppose you don't need all that fancy control and that you are really lazy. An ancient, low tech solution to your problem could be to create a virtual frame buffer and then read its contents directly. To do this, you can set up xvfb on your server:

http://www.x.org/releases/X11R7.6/doc/man/man1/Xvfb.1.xhtml

xvfb is an old unix tool that lets you create a virtual x-server with whatever type of configuration you want. More importantly, it can be configured to write the contents of its X server's screen directly to a memory mapped file! You can also set it up to use shared memory, which is a bit faster though also more complicated.

Solution 2

I guess you will have better luck with uzbl and GTK/DirectFB. Same engine, and works with javascripts. For the facebook chat issue, I think you just have to change the user-agent string.

Solution 3

try to port webkit engine to the netsurf framebuffer-based code.

HTH

Solution 4

There is the Origyn Web Browser, which is supposed to be an embedded WebKit-based browser that looks portable and does not depend on "heavy" libraries (like GTK). Their web page is http://www.sand-labs.org/owb but it looks like their database crashed, which is a little worrying maybe.

Solution 5

You could buy one of the remaining 10 (or so) OGD1 boards. http://en.wikipedia.org/wiki/Open_Graphics_Project

Then you can talk directly to hardware using libpci.

However you will still need code that draws a picture into a memory buffer.

I realize this answer is more a shameless plug. But people who are interested in your question might want such a board. I already have a board like this and it would help a lot if it got more exposure.

View more solutions