Frame buffer driver for X server - Embedded

This is a discussion on Frame buffer driver for X server - Embedded ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: Frame buffer driver for X server

  1. Frame buffer driver for X server

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


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

  3. 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
    wrote:
    > 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




  4. Re: Frame buffer driver for X server

    walid.benyoussef@gmail.com wrote:
    > I'm not using QT, I'm using embedded QT. ebedded QT uses directly
    > linux fb.


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

    > i have no X server on my board. probably i need to build one for my
    > board ....


    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.

    > i was just wondering if there is already one frame buffer already done
    > that transmitts Display over TCPIP.


    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

  5. Re: Frame buffer driver for X server

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


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




  6. Re: Frame buffer driver for X server

    > probably it's better to use QT then, but i think that QT is based on
    > X11 ((


    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.

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


    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

  7. Re: Frame buffer driver for X server

    walid.benyoussef@gmail.com wrote:
    >> Is embedded QT unable to use an X-server ? So maybe you can use the
    >> standard version instead.

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


    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

  8. Re: Frame buffer driver for X server

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


    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

  9. Re: Frame buffer driver for X server

    Michael Schnell wrote:
    >>
    >> 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...

    >
    > 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 ?


    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.

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


    Yes.

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


    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

  10. Re: Frame buffer driver for X server

    >> BTW.: Is there a chance to use VNC in such an environment without QT/e ?
    >
    > 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.


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

  11. Re: Frame buffer driver for X server

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

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

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


  12. Re: Frame buffer driver for X server

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

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

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


    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

  13. Re: Frame buffer driver for X server

    Great !

    Thanks for letting me know.

    -Michael

  14. Re: Frame buffer driver for X server


    -Michael

  15. Re: Frame buffer driver for X server

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


    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

  16. Re: Frame buffer driver for X server

    Michael Schnell wrote:

    > Program->Microwindows/?-> Framebuffer?->Screen


    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

  17. Re: Frame buffer driver for X server

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


    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

  18. Re: Frame buffer driver for X server

    Michael Schnell wrote:
    >> 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....)

    >
    > 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 ?


    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

  19. Re: Frame buffer driver for X server

    "Michael Schnell" wrote in message
    news:esmahe$57h$1@murphy.mediascape.de...
    >> 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....)

    >
    > 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 ?


    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



  20. Re: Frame buffer driver for X server

    Peter Dickerson wrote:
    > "Michael Schnell" wrote in message


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


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

    >
    > What sort of things do you need to display?


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

    --Yan

+ Reply to Thread
Page 1 of 2 1 2 LastLast