Frame buffer driver for X server

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi Evbd,
I'm using an arm based board with embedded Linux 2.4 . I just have a
simple question :"is there a Linux Frame Buffer  driver that redirects
display over TCP IP ( X server for example )?.
this leads to redirect QT embedded applications on remote display.
Thx......


Re: 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

Re: Frame buffer driver for X server
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.



On Feb 27, 3:59 am, Michael Schnell
Quoted text here. Click to load it



Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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).




Re: Frame buffer driver for X server
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it


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.


Re: Frame buffer driver for X server
:):):)
-Michael

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Great !

Thanks for letting me know.

-Michael

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server

Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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

Re: Frame buffer driver for X server
Thanks a lot for sharing this !

-Michael

Re: Frame buffer driver for X server
Quoted text here. Click to load it

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



Site Timeline