In message [off-list ref] you wrote:
Do you meaean that responsibility of byte order is left to application
level ?
No. The graphic drivers are responsible for it.
Linux fbdev just maps display memory to user application space and so it
cant do anything for how R,G,B bits are ordered within word. It is
then responsibility to GUI-engine ( X-server, Embedded-QT ) to
handle this ordering.
This is why it is impossible to use a simple framebuffer driver on
the Coral-P in 16 bit mode. You can run a framebuffer with 24 bpp
(and actually our first demo dreiver was doing this), but it ain't no
fun.
Also, with a framebuffer driver you miss all the options for
accelerated graphics provided by the Coral-P engine.
This is why we implemented an accelerated X11 driver for the Coral-P.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Today is the yesterday you worried about tomorrow.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
Do you meaean that responsibility of byte order is left to application
level ?
No. The graphic drivers are responsible for it.
It is how you call it. X server or Embedded QT graphics driver normally
works
in user level..
quoted
Linux fbdev just maps display memory to user application space and so it
cant do anything for how R,G,B bits are ordered within word. It is
then responsibility to GUI-engine ( X-server, Embedded-QT ) to
handle this ordering.
This is why it is impossible to use a simple framebuffer driver on
the Coral-P in 16 bit mode. You can run a framebuffer with 24 bpp
(and actually our first demo dreiver was doing this), but it ain't no
fun.
Yes, this was that i were using and in this one x-server was just
patched to fix byte order.
Also, with a framebuffer driver you miss all the options for
accelerated graphics provided by the Coral-P engine.
This is why we implemented an accelerated X11 driver for the Coral-P.
I should try this new one. With the older one i have some problems with
get all required
virtual console etc drivers to compiled to kernel to make Xfree 4.4
happy. Ok, now
there looks a like to be icecube_5200_CoralP_defconfig
It is just somehow dificult to find all new files appearing to tree ......
May be it is worth to try use QT with X11 server instead using embedded
qt direct to
fb device. In older driver it was anyhow much better to use embedded qt
direrctly.
Kate
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Fri, 2004-07-02 at 09:22, Wolfgang Denk wrote:
quoted
Linux fbdev just maps display memory to user application space and so it
cant do anything for how R,G,B bits are ordered within word. It is
then responsibility to GUI-engine ( X-server, Embedded-QT ) to
handle this ordering.
This is why it is impossible to use a simple framebuffer driver on
the Coral-P in 16 bit mode. You can run a framebuffer with 24 bpp
(and actually our first demo dreiver was doing this), but it ain't no
fun.
I now found out why my picture looked so dim...
My trusty old CRT was finally broken. ARG!
Ok, but the picture from the console (penguin, messages ...)
is still very blue-ish; however X is perfectly ok with
the accelerated driver, so with the above said by you,
it this what I have to expect?
I understand that console messages on the VGA are not
important for an embedded system when the apps (can)
work correctly.
I just want to avoid everyone asking me
"why does that screen look so blue?" :)
Btw: "fbset -depth 24" and bootargs+="video=mb86290:1024x768-24@70"
apparently have no effect at all...
--
Stefan Nickl
Kontron Modular Computers
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/