xvesa vs xfbdev

[uggla]

What's the difference between xvesa and xfbdev? Am I right to assume that xvesa supports more devices but xfbdev has better performance?

regards
/Uggla

[^thehatsrule^]

Actually, I think it's the opposite: xfbdev is the framebuffer one.

[SvOlli]

Thinking about performance, the both of them can't be far apart, since none of them supports any acceleration. I'd expect xvesa to be a bit faster though.

The main difference is the initialization of the graphics card: xfbdev uses the resolution of the framebuffer configuration set via the "vga="-bootparameter. If it's set to text-mode, it can't run at all. Technically it opens /dev/fb* for interaction with the graphics hardware via the kernel. xvesa accesses the hardware directly, so it can change the resolution and should be slightly faster, but it needs root privileges for running while xfbdev just needs access to /dev/fb* (and /dev/input* for mouse, keyboard, etc.).

Hope this helps.

[uggla]

Thanks!

[Marco Trapanese]

And which do you recommend to run embedded graphical applications on boards like beagle board or Atom-based?
The goal is to make a turn-on-turn-off machine, with no dekstop nor multiple applications.

I think it's better to avoid running X server and use the framebuffer, isn't it?

[tinypoodle]

Xfbdev is an X server.

[Marco Trapanese]

It seems I missed something   

In the faq I read:


In order to use framebuffer (Xfbdev) you [...]



So I understand the Xfbdev is the framebuffer.
In fact if I follow that guide I can run my GUI application at prompt, without assert start X.

I'm a bit confused....   

[SvOlli]

In order to use framebuffer (Xfbdev) you [...]

Please also read the heading above the text: "How to use framebuffer X server?"

So I understand the Xfbdev is the framebuffer.
In fact if I follow that guide I can run my GUI application at prompt, without assert start X.

No, Xfbdev is an X server drawing its contents in the framebuffer. An X server can draw on real graphics hardware, it can draw on a software interface to hardware (Xfbdev), and it can draw in a pure virtual context (Xnest, and the first vncserver). If you follow the instructions you typed in "startx" which starts the X server, on reboot the Xfbdev is started automatically, just like any other X server.

[Marco Trapanese]

I typed startx to save the configuration. Then I rebooted with text flag. When I was at prompt I launched my Qt Embedded application (with -qws) and the prompt disappeared, showing a green background with my application. I exited with ctrl-alt-backspace, returning to prompt.

Then, I typed startx and the tinycore desktop appeared.

I'm just trying to understand what I did 

[Marco Trapanese]

Anyway the question is:

do you recommend to run embedded graphical applications (on boards like beagle board or Atom-based) with the framebuffer or with an X server?
The goal is to make a turn-on-turn-off machine, with no dekstop nor multiple applications.

[tinypoodle]

What application?
Does it depend on X or not??

[Marco Trapanese]

This one:

http://doc.trolltech.com/4.2/widgets-analogclock.html

if I compile with Qt/X11 I need to start it from X server (otherwise it doesn't run).
if I compile with Qt/Embedded I need to start it from the prompt (otherwise it doesn't run).

I had to change permission on /dev/fb0 to allow my application write in the fb.

[SvOlli]

do you recommend to run embedded graphical applications (on boards like beagle board or Atom-based) with the framebuffer or with an X server?

Beagle Board is out of the question, since it's ARM based and does not run TinyCore.

On any x86-based Hardware, here's the way I go for best performance: first I try Xorg-7.5, if that does not work, I'll got for Xvesa. Xorg has support for 2D (and even 3D) acceleration on the 945 on-chip graphics of the first Atom generation (230, 330, N270). Can't tell about the current ones, since I couldn't get my hands on one until now. Xfbdev only is an option when boot time is more important that graphics performance, Xfbdev starts about 2 seconds faster than Xvesa.

[SvOlli]

if I compile with Qt/X11 I need to start it from X server (otherwise it doesn't run).
if I compile with Qt/Embedded I need to start it from the prompt (otherwise it doesn't run).

It depends on what application you want to run: if it's really just one application with low graphics output, the Qt/Embedded will also work, but you'll need to compile Qt for TinyCore yourself and can't use the libs from the AppBrowser.

I've hacked together a box running the audio player "Partyman" on a mini-itx N270 board. During this I was faced with the same question: should I use Qt/Embedded with framebuffer, or Qt/X11? My choice was going the X11 way. It saved me a lot of unnecessary work.

Qt/Embedded with framebuffer is very interesting if you've got hardware that's limited in space, both ram and/or mass-storage (usually flash in that context), but I've you're using an itx-board, you've got at least 256MB up to a range of 2GB of RAM and boot from an old HD or a CF card. These come with storage capacity where the space for Xorg really doesn't matter.

Concentrate on your project, not the platform! Get your work done, not the work that's already done.

[Marco Trapanese]

It depends on what application you want to run: if it's really just one application with low graphics output, the Qt/Embedded will also work, but you'll need to compile Qt for TinyCore yourself and can't use the libs from the AppBrowser.

Why I have to recompile Qt for Tinycore? I've just compiled the Qt Embedded for a generic linux x86 architecture.
Anyway, my applications will have a lot of graphics stuff. Something like this:

http://www.femtotech.it/images/stories/software/app1.png

Qt/Embedded with framebuffer is very interesting if you've got hardware that's limited in space, both ram and/or mass-storage (usually flash in that context), but I've you're using an itx-board, you've got at least 256MB up to a range of 2GB of RAM and boot from an old HD or a CF card. These come with storage capacity where the space for Xorg really doesn't matter.

Yeah, the hardware is not a matter.
I was concerned about the desktop environment. Perhaps I was wrong thinking how heavy is the windows desktop. For this reason I was trying to avoid the server X.

But from your answer I understand it's not a problem, so I will continue tu use Xorg or whatever else and I won't go further to Qt Embedded.