Frame buffer driver for X server

What are you trying to accomplish ?

Do you use QT ? AFAIK, QT does use an X server. It's normal Unix standard that X is done via TCP/IP. So you can use a remote X server (even on Windows there is a free X-Server: XMING).

Why is framebuffer necessarily involved here ? (I am quite ignorant regarding framebuffer.)

-Michael

I'm not using QT, I'm using embedded QT. ebedded QT uses directly linux fb. i have no X server on my board. probably i need to build one for my board .... i was just wondering if there is already one frame buffer already done that transmitts Display over TCPIP.

Is embedded QT unable to use an X-server ? So maybe you can use the standard version instead.

I don't think you need an X-server software in your device to have it access a remote X-server via TCP/IP. I gather you just need some configuration options to make QT aware of the IP address of the X server to be used.

IMHO it would be a bad idea to transfer the pixel the content of the frame buffer instead of the standard X protocol. Here X would be much more efficient and use much less memory at the embedded device. Moreover the memory needed would be independent of the size of the remote display.

If you really want to transfer the pixels in a frame buffer, you might take a look at VNC. I think same works in that way, and the software on the PC site is readily available for free.

-Michael

thanx a lot Michael ..... that's a good idea ;) probably it's better to use QT then, but i think that QT is based on X11 :((( embedded QT can access directly linux frame buffer, but i don't know if it can use a remote X server (such as XMING, xwin, reflectionX under win32).

Of course. I think that is exactly what you want: use a remote X11 server that your embedded device accesses to have it create the GUI.

If you do X11, no framebuffer device is necessary any more. Of course at that point you loose the local GUI. If you need both a local and a remote GUI, you in fact need a (framebuffer-based) X11 server on your device. This of course asks for a lot of memory and performance.

-Michael

There are compile time options for QT/e - one for using a standard X11 for output, one for the embedded frame buffer, one for vnc, and probably a few I haven't used...

./configure --help in your qt/e dir to see the options.

--Yan

Great ! I did suppose it can do FB and X11 but it's great to see that it can do VNC, as well. This might be a good option here.

When using X11 (other than with VNC) the program embedded device will try to connect to the remote X server when starting up. That might not be desirable, I don't know what will happen, if no X server is found. Will the program be able to run unmonitored, anyway ?

With VNC the embedded device is a server and can be accessed remotely (but it will continue to run if that does not happen).

BTW.: Is there a chance to use VNC in such an environment without QT/e ?

-Michael

The way qt/e works, it binds the display tightly with the program, so if it can't find the graphical output device, it will not start. So if you want it to run under X11, you need to have X11 running in order to start the program.

Yes.

Sure - but if you use qt/e, it outputs only as a VNC server - at lease I haven't found a way to output to both a framebuffer and a vnc server at the same time.

Microwindows, for example, has VNC capability - but if your app needs qt, you have to use qt.

--Yan

Great ! I'll take a look at Microwindows (I don't suppose it's by M$ :) )

Actually the developer has officially changed the name to Nano-X, since some weenie from Redmond complained that an efficient, small, working windowing environment might be confused with an inefficient, bloated, DRM-crippled windowing environment..... :-)

But we still call it Microwindows.

I forgot to add:

I submitted some patches to Microwindows VNC. It won't work otherwise.

If those patches haven't been folded into the main source, you may want to search the mailinglist archives from about a year ago. IIRC, it was mostly function name changes and such because the vnc API had changed.

--Yan

Great !

Thanks for letting me know.

-Michael

:):):)

-Michael

Looking at the Microwindows website I'm confused. It _seems_like_ Microwindows is an X server ()thus providing an X-interface as a server, but here we are considering an alternative to QT.

I'm not very deep into this. I suppose the stack looks something like this:

Standard: Program->QT->XServer->Screen or Program->QT->(Network)->XServer->Screen or Program->QT->XServer->VNC-server->(Network)->VNC-Client->Screen

Embedded: Program->QT/e->XServer->Screen or Program->QT/e->(Network)->XServer->Screen or Program->QT/e/VNC->(Network)->VNC-Client->Screen or Program->Microwindows/X->XServer->Screen or Program->Microwindows/X->(Network)->XServer->Screen or Program->QT/e/VNC->(Network)->VNC-Client->Screen or (maybe Microwindows can be configured to include/replace the X-Server): Program->Microwindows/?-> Framebuffer?->Screen

What am I getting wrong ?

-Michael

That one.

Microwindows has an X11 compat library that I've never used. It lacks all of the client-server functionality and implements most of the X11 graphics calls.

Microwindows also has its own drawings primitives, which is what I used. You can draw lines, circles, etc.

There are also some sample apps like a vt52 terminal emulator and a few others, including a basic WM.

You can compile Microwindows with VNC support, and it will act as a vnc server allowing you to connect to it with any vnc client.

If you have an existing qt app, you can't really use Microwindows; it lacks all of the qt fluff (also lacks the qt bloat; it builds to somewhere around 300K on my arm platform v. 8 MB for qt/e....)

--Yan

That indeed is what I am trying to accomplish.

I intend to create a program with _some_kind_of_ user interface and don't intend to use qt. I'd like to keep the overhead as small as possible.

The device does not have any graphic hardware and so I'd like to use a PC as display (via X11 or VNC or whatever).

Any more pointers ?

-Michael

When I stopped working with microwindows, there was some effort to build an fltk + nano-X solution, which should provide you with a fairly lightweight solution with all of the typical widgets.

You probably want to join the nano-X mailing list and find out more.

However, and this is a big issue, the kernel I was working with at the time (2.4) didn't have a functioning virtual frame buffer. I don't know if this was added in the later kernels.

Basically, microwindows VNC needs real graphics hardware to write to. If you have a system with no graphics hardware, then you have a problem.

There is a stub virtual frame buffer in the 2.4 kernels, but it is a black hole - you can write to it, but the kernel just throws away anything written into it. I've been told that it would be easy to fix - just create a real memory buffer in the kernel, but I am not a kernel hacker and it is just short of impossible for me. I can't figure out even the most basic framebuffer drivers in the kernel source.

OTOH, if you are a kernel hacker, and you create a patch for this,

*please* let me know; I would love to have a VNC based solution on some of my hardware....

--Yan

If you're trying to control some headless kit from a PC wouldn't it be better to implement a web server in the device. That way the PC would require no additional software. The device doesn't need to understand graphics much and the basic UI control stuff can be done in java or javascript. A basic web server will be much simpler than implementing X and everything above and below it.

What sort of things do you need to display?

Peter

That would be my solution as well.... (in fact, that is my current solution.)

Unless you are trying to display interactive, realtime graphics or something like that I would go with a webserver+browser as well.

--Yan