Qt for Embedded Linux

[Fernando Cacciola]

Hola,

Quisiera saber si alguno de uds ha tenido experiencia usando Qt for Embedded Linux.

Estamos por comenzar con un desarollo y tenemos pensado usar un Raspberry, con Raspian y Qt for Embedded Linux.

Eso funciona bien?

Muchas gracias

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

[martin ribelotta]

Nunca he usado Qt Embedded en una R-Pi pero puedo decirte que si tiene framebuffer Qt4-Embeddeed funciona sin ningun problema. Otro tema seria el hardware como touch screen o teclado y raton, pero eso no depende de Qt embedded sino de los drivers del nucleo.

En general, Qt embedded está Deprecated y se migra a Qt+Wayland (que ya anda en R-Pi segun he visto) siendo esto la solución estandar en el futuro tanto para desktop como para embedded

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Fernando Cacciola]

Hola Martín,

2014-08-01 11:42 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Nunca he usado Qt Embedded en una R-Pi pero puedo decirte que si tiene framebuffer Qt4-Embeddeed funciona sin ningun problema.

OK.

Le pusimos un Raspian al R-Pi, que tiene X11 (y por tanto framebuffer). Y un escritorio LXDE que no conocía, muy bonito.

 

Otro tema seria el hardware como touch screen o teclado y raton, pero eso no depende de Qt embedded sino de los drivers del nucleo.

OK.

Eso todavía no lo tenemos pero le vamos a poner un touch.

Un google rápido me dice que vamos a tener que recompilar el kernel para agregar los drivers (que dependerán de qué touch usemos).

Cuando lleguemos a eso ya voy a preguntar :)
 

En general, Qt embedded está Deprecated y se migra a Qt+Wayland (que ya anda en R-Pi segun he visto) siendo esto la solución estandar en el futuro tanto para desktop como para embedded

OK

Estoy viendo Wayland por primera vez y se ve bueno, aunque me parece un poco verde. O no?

Supongo que por ahora usaremos Qt4-Embedded directamente en el Raspian.

Saludos

 

[martin ribelotta]

Como opción madura, Qt4 usando framebuffer es lo mejor. X11 no tiene performance ni escala bien en este procesador, y Wayland como bien decís esta un poco verde, pero de acá a un año va a ser el estándar de facto para sistemas embebidos, igual Qt5 soporta muchos tipos de window system como para pensar en quedarse sin soporte.

De todas formas, te confirmo que si se requiere un desarrollo estable, mi opción es Qt4.8 embedded usando solo el framebuffer y alguna que otra libreria (tslib me imagino)

Por las dudas, igual pegale una mirada a esto que estan haciendo la gente de Qt:

http://blog.qt.digia.com/blog/2013/10/24/introducing-qt-enterprise-embedded-aka-boot-to-qt/

Y parece bastante estable.

--

[Fernando Cacciola]

2014-08-01 12:26 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Como opción madura, Qt4 usando framebuffer es lo mejor. X11 no tiene performance ni escala bien en este procesador,

Ok.
Una pregunta... el framebuffer que usa Qt4-Embedded es parte del X11 no? o tiene otro mecanismo? Digo por lo que decis de que X11 no escala bien.

O más bien, tengo que tener X11 instalado para usar Qt4-Embeeded, no es cierto?

Recién hoy me puse a ver esto de Qt4-Embedded y todavía no termino de entender bien qué es exáctamente, y qué cosas necesita de la distro que pongamos en el R-Pi.

 

y Wayland como bien decís esta un poco verde, pero de acá a un año va a ser el estándar de facto para sistemas embebidos, igual Qt5 soporta muchos tipos de window system como para pensar en quedarse sin soporte.

 

OK.

Decididamente tenemos que mantener presente el progreso de Wayland. Algún lugar en especial para monitoriar esto que me puedas recomendar?

De todas formas, te confirmo que si se requiere un desarrollo estable, mi opción es Qt4.8 embedded usando solo el framebuffer y alguna que otra libreria (tslib me imagino)

OK
 

Por las dudas, igual pegale una mirada a esto que estan haciendo la gente de Qt:

http://blog.qt.digia.com/blog/2013/10/24/introducing-qt-enterprise-embedded-aka-boot-to-qt/

Y parece bastante estable.

Uh, que bueno...

[martin ribelotta]

El 1 de agosto de 2014, 12:54, Fernando Cacciola <fernando...@gmail.com> escribió:

2014-08-01 12:26 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Como opción madura, Qt4 usando framebuffer es lo mejor. X11 no tiene performance ni escala bien en este procesador,

Ok.
Una pregunta... el framebuffer que usa Qt4-Embedded es parte del X11 no? o tiene otro mecanismo? Digo por lo que decis de que X11 no escala bien.

O más bien, tengo que tener X11 instalado para usar Qt4-Embeeded, no es cierto?

Recién hoy me puse a ver esto de Qt4-Embedded y todavía no termino de entender bien qué es exáctamente, y qué cosas necesita de la distro que pongamos en el R-Pi.

No, X11 y Qt-Embedded no tienen nada que ver el uno con el otro.

El framebuffer de linux es una forma facil de acceder al hardware gráfico, pensada originalmente para mostrar el splash screen, pero usada con posterioridad como sistema gráfico de bajo nivel.

X11 tambien puede acceder al framebuffer y dibujar sobre el usando el driver fbdev. Qt embedded, en vez de usar X11 para dibujar las ventanas, implementa un servidor grafico propio (QWS) para reemplazar a X11 y dibujar directamente sobre el framebuffer a pedido de las aplicaciones. Estas dibujan en buffers propios y luego el servidor QWS las compone sobre el area de memoria del framebuffer.

QWS puede correr como una tarea en background en una aplicación Qt embedded (modo por defecto) o correr como un servidor aparte y las apliaciones comunicarse con el como si fuera X11 pero con mucho menor consumo de recursos.

Hace mucho tiempo, hice una especie de desktop enviroment muy basico usando Qt embedded, tal vez te sirva para empezar:

https://github.com/mribelotta/qde

 

 

y Wayland como bien decís esta un poco verde, pero de acá a un año va a ser el estándar de facto para sistemas embebidos, igual Qt5 soporta muchos tipos de window system como para pensar en quedarse sin soporte.

 

OK.

Decididamente tenemos que mantener presente el progreso de Wayland. Algún lugar en especial para monitoriar esto que me puedas recomendar?

Basicamente los repos git de todo:

http://cgit.freedesktop.org/wayland

https://qt.gitorious.org/qt/qtwayland/source/5.3:

Y las paginas de cada proyecto. Wayland hace mucho que es un desarrollo estable, ocurre que los toolkits y los desktop enviroment deben ser portados (sin hablar de las aplicaciones que es lo que mas lleva)

 

De todas formas, te confirmo que si se requiere un desarrollo estable, mi opción es Qt4.8 embedded usando solo el framebuffer y alguna que otra libreria (tslib me imagino)

OK
 

Por las dudas, igual pegale una mirada a esto que estan haciendo la gente de Qt:

http://blog.qt.digia.com/blog/2013/10/24/introducing-qt-enterprise-embedded-aka-boot-to-qt/

Y parece bastante estable.

Uh, que bueno...

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

[Ismael Luceno]

On Fri, 1 Aug 2014 10:55:37 -0300
Fernando Cacciola <fernando...@gmail.com> wrote:
> Hola,
>
> Quisiera saber si alguno de uds ha tenido experiencia usando Qt for
> Embedded Linux.
>
> Estamos por comenzar con un desarollo y tenemos pensado usar un
> Raspberry, con Raspian y Qt for Embedded Linux.
>
> Eso funciona bien?
>
> Muchas gracias
>

Hola.

QT 4.8 y QT 5 deberían andar perfecto. Idealmente deberías aprovechar
QPA (Lighthouse), ya que en mi experiencia funciona mejor que QWS, y si
podés lidiar con QT 5, las mejoras son substanciales (he usado QT 5 en
entornos de producción desde fines del 2011 sin problemas).

[Santiago Pérez]

Quizás podes ver diferencia a la hora de buscar soporte. Qt 4.8.5 está muy difundido y hay info y experiencias por todos lados. Mi experiencia es que al querer usar lo último de lo último, a veces te termina demorando y costando mucho tiempo/dinero. Personalmente uso Qt4.8.5 y deje Qt5 para un futuro cuando la tenga más clara y haya mas soporte en la comunidad de mi micro en particular.

Saludos!

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[martin ribelotta]

El 1 de agosto de 2014, 12:05, Ismael Luceno <ismael...@gmail.com> escribió:

Adhiero al asunto, pero recomiendo que si uno no tiene experiencia empiece por donde mas facil la tenga. De todas formas, QPA da muchisima flexibilidad, desde poder usar directamente el framebuffer (bastante mas limitado de fabrica que con QWS) a usar el stack de Android o DirectFB.

Eso si, si no tenes soporte de openGL(-ES) en tu hardware (por suerte R-Pi si lo tiene) no esperes hacer andar las cosas nuevas de Qt5 como QML o QtQuick2.

[Santiago Pérez]

En algunos foros decían que Qt 4.8.X (embebido en un ARM por ejemplo) solo podía hacer uso del GPU (OpenGL) si se usa X11, porque había problemas con QWS o acceso directo al framebuffer. No se si será exclusivo de Freescale o de una gama de micros (i.MX?). Sabes algo al respecto Martín?.

Por otro lado, lo de QtQuick y todo lo nuevo que aporta Qt5 aparentemente es útil solo si las aplicaciones a desarrollar son pensadas para móviles y no tanto para escritorio (más widgets solamente aunque pueden ser con animaciones también), porque están muy pensados para el tipo de comportamiento al que nos hemos acostumbrado en los smartphones y tal cual como dice Martín, son "GPU mandatory".

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

--

[Fernando Cacciola]

2014-08-01 13:37 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

El 1 de agosto de 2014, 12:54, Fernando Cacciola <fernando...@gmail.com> escribió:

2014-08-01 12:26 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Como opción madura, Qt4 usando framebuffer es lo mejor. X11 no tiene performance ni escala bien en este procesador,

Ok.
Una pregunta... el framebuffer que usa Qt4-Embedded es parte del X11 no? o tiene otro mecanismo? Digo por lo que decis de que X11 no escala bien.

O más bien, tengo que tener X11 instalado para usar Qt4-Embeeded, no es cierto?

Recién hoy me puse a ver esto de Qt4-Embedded y todavía no termino de entender bien qué es exáctamente, y qué cosas necesita de la distro que pongamos en el R-Pi.

No, X11 y Qt-Embedded no tienen nada que ver el uno con el otro.

El framebuffer de linux es una forma facil de acceder al hardware gráfico, pensada originalmente para mostrar el splash screen, pero usada con posterioridad como sistema gráfico de bajo nivel.

X11 tambien puede acceder al framebuffer y dibujar sobre el usando el driver fbdev. Qt embedded, en vez de usar X11 para dibujar las ventanas, implementa un servidor grafico propio (QWS) para reemplazar a X11 y dibujar directamente sobre el framebuffer a pedido de las aplicaciones. Estas dibujan en buffers propios y luego el servidor QWS las compone sobre el area de memoria del framebuffer.

Ahhhhh. OK. Eso fué lo que entedí primero, pero alguien del equipo acá me dijo que no puede ser y que tiene que ser sobre X11.

 

QWS puede correr como una tarea en background en una aplicación Qt embedded (modo por defecto) o correr como un servidor aparte y las apliaciones comunicarse con el como si fuera X11 pero con mucho menor consumo de recursos.

OK

 

Hace mucho tiempo, hice una especie de desktop enviroment muy basico usando Qt embedded, tal vez te sirva para empezar:

https://github.com/mribelotta/qde

 

 

y Wayland como bien decís esta un poco verde, pero de acá a un año va a ser el estándar de facto para sistemas embebidos, igual Qt5 soporta muchos tipos de window system como para pensar en quedarse sin soporte.

 

OK.

Decididamente tenemos que mantener presente el progreso de Wayland. Algún lugar en especial para monitoriar esto que me puedas recomendar?

Basicamente los repos git de todo:

http://cgit.freedesktop.org/wayland

https://qt.gitorious.org/qt/qtwayland/source/5.3:

Y las paginas de cada proyecto. Wayland hace mucho que es un desarrollo estable, ocurre que los toolkits y los desktop enviroment deben ser portados (sin hablar de las aplicaciones que es lo que mas lleva)

OK

[Ismael Luceno]

On Fri, 1 Aug 2014 14:38:24 -0300
Santiago Pérez <pere...@gmail.com> wrote:
> En algunos foros decían que Qt 4.8.X (embebido en un ARM por ejemplo)
> solo podía hacer uso del GPU (OpenGL) si se usa X11, porque había
> problemas con QWS o acceso directo al framebuffer. No se si será
> exclusivo de Freescale o de una gama de micros (i.MX?). Sabes algo al
> respecto Martín?.

Seguramente tenga que ver con la falta de EGL.

> Por otro lado, lo de QtQuick y todo lo nuevo que aporta Qt5
> aparentemente es útil solo si las aplicaciones a desarrollar son
> pensadas para móviles y no tanto para escritorio (más widgets
> solamente aunque pueden ser con animaciones también), porque están
> muy pensados para el tipo de comportamiento al que nos hemos
> acostumbrado en los smartphones y tal cual como dice Martín, son "GPU
> mandatory".

La parte de scripting a veces viene útil...

[Ismael Luceno]

On Fri, 1 Aug 2014 14:03:10 -0300
Santiago Pérez <pere...@gmail.com> wrote:
> Quizás podes ver diferencia a la hora de buscar soporte. Qt 4.8.5
> está muy difundido y hay info y experiencias por todos lados. Mi
> experiencia es que al querer usar lo último de lo último, a veces te
> termina demorando y costando mucho tiempo/dinero. Personalmente uso
> Qt4.8.5 y deje Qt5 para un futuro cuando la tenga más clara y haya
> mas soporte en la comunidad de mi micro en particular.

Y, depende, lo mío es la infraestructura principalmente, así que si no
hay problemas que resolver como que no tengo mucho que hacer :P.

[Fernando Cacciola]

OK.

Estoy mirando QPA y parece bastante verde tambien.

[martin ribelotta]

X11 tambien puede acceder al framebuffer y dibujar sobre el usando el driver fbdev. Qt embedded, en vez de usar X11 para dibujar las ventanas, implementa un servidor grafico propio (QWS) para reemplazar a X11 y dibujar directamente sobre el framebuffer a pedido de las aplicaciones. Estas dibujan en buffers propios y luego el servidor QWS las compone sobre el area de memoria del framebuffer.

Ahhhhh. OK. Eso fué lo que entedí primero, pero alguien del equipo acá me dijo que no puede ser y que tiene que ser sobre X11.

Para nada, si usa X11, no es Qt Embedded (salvo por el simulador de QWS que corre como aplicación de X11 pero eso es como un VNC medio raro -perdón la falta de precisión pero no hay muchas formas de explicarlo sin mirar el código-

De hecho, la prueba de que eso NO es así es el link que te pase al proyecto (unipersonal y ya abandonado) de QDE que es un desktop completo sin X11.

 

QWS puede correr como una tarea en background en una aplicación Qt embedded (modo por defecto) o correr como un servidor aparte y las apliaciones comunicarse con el como si fuera X11 pero con mucho menor consumo de recursos.

OK

 

Hace mucho tiempo, hice una especie de desktop enviroment muy basico usando Qt embedded, tal vez te sirva para empezar:

https://github.com/mribelotta/qde

 

 

y Wayland como bien decís esta un poco verde, pero de acá a un año va a ser el estándar de facto para sistemas embebidos, igual Qt5 soporta muchos tipos de window system como para pensar en quedarse sin soporte.

 

OK.

Decididamente tenemos que mantener presente el progreso de Wayland. Algún lugar en especial para monitoriar esto que me puedas recomendar?

Basicamente los repos git de todo:

http://cgit.freedesktop.org/wayland

https://qt.gitorious.org/qt/qtwayland/source/5.3:

Y las paginas de cada proyecto. Wayland hace mucho que es un desarrollo estable, ocurre que los toolkits y los desktop enviroment deben ser portados (sin hablar de las aplicaciones que es lo que mas lleva)

OK

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

[martin ribelotta]

El 1 de agosto de 2014, 14:52, Ismael Luceno <ismael...@gmail.com> escribió:

On Fri, 1 Aug 2014 14:38:24 -0300
Santiago Pérez <pere...@gmail.com> wrote:
> En algunos foros decían que Qt 4.8.X (embebido en un ARM por ejemplo)
> solo podía hacer uso del GPU (OpenGL) si se usa X11, porque había
> problemas con QWS o acceso directo al framebuffer. No se si será
> exclusivo de Freescale o de una gama de micros (i.MX?). Sabes algo al
> respecto Martín?.

Seguramente tenga que ver con la falta de EGL.

De eso y de que la infraestructura de QWS no está pensada para compartir buffers de composición NUMA (non-uniformed-memory-arquitecture) que es lo que usan mayormente las GPU.

Aparte de que era un protocolo horrendo (me ha tocado hackearlo desde muy bajo nivel), sin ninguna documentación y con una pesima escalabilidad (originalmente fue pensado para sistemas empotrados sin GPU y con 32 o 64M de RAM así que no aprovecha para nada los recursos de una GPU o una APU)

 

> Por otro lado, lo de QtQuick y todo lo nuevo que aporta Qt5
> aparentemente es útil solo si las aplicaciones a desarrollar son
> pensadas para móviles y no tanto para escritorio (más widgets
> solamente aunque pueden ser con animaciones también), porque están
> muy pensados para el tipo de comportamiento al que nos hemos
> acostumbrado en los smartphones y tal cual como dice Martín, son "GPU
> mandatory".

La parte de scripting a veces viene útil...

Sin mencionar que hacer una GUI con QtQuick es muy rapido y facil.

Para Qt6 tienen ganas de dejar deprecated QtWidget pero no creo que lo puedan hacer facilmente. Cuando Qt era de nokia, esta lo quiso hacer (en algun delirio de vision de futuro) pero cuando Digia adquirió Qt, dejó claro que el mercado de embebidos era su principal target comercial y que QtWidget estaba muy enraizado ahi.

[martin ribelotta]

El 1 de agosto de 2014, 15:08, Fernando Cacciola <fernando...@gmail.com> escribió:

2014-08-01 12:05 GMT-03:00 Ismael Luceno <ismael...@gmail.com>:

On Fri, 1 Aug 2014 10:55:37 -0300
>

Hola.

QT 4.8 y QT 5 deberían andar perfecto. Idealmente deberías aprovechar
QPA (Lighthouse), ya que en mi experiencia funciona mejor que QWS, y si
podés lidiar con QT 5, las mejoras son substanciales (he usado QT 5 en
entornos de producción desde fines del 2011 sin problemas).

OK.

Estoy mirando QPA y parece bastante verde tambien.

Para nada, QPA es una tecnología probada con mas de 4 años de desarrollo.

Tal vez la confusión venga por el hecho de que QPA es una infraestructura mas que un producto acabado. Lo mismo que Wayland.

Aquí, en el mundillo de linux embebido, hablar de productos acabados o de cosas maduras es. tácitamente, hablar de servicios de terceros que se cobran.

Normalmente, todo esto, requiere de hacking bastante avanzado y no es nada parecido a un PIC que con algunas librerías salimos del paso. Hay muchos proyectos avanzando en paralelo e interaccionando entre si para crear un sistema como Linux/Android/etc. y todos ellos tienen sus pros y sus contras, así que es parte del trabajo de ingeniería entender el ecosistema y dominar las herramientas que sean  necesarias para el trabajo a realizar.

Personalmente, creo que por mucho que nos guste jugar con la parte técnica, hay una verdad incuestionable a la hora del diseño, esto es una parte de un todo y como tal, debe cumplir su cometido.

Frente a eso, muchas veces debemos refrenar nuestra tendencia teki y buscar el camino critico de la solución. Cosa que no siempre es facil ni clara ;-) y mucho menos de respuesta única.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

[Fernando Cacciola]

2014-08-01 14:03 GMT-03:00 Santiago Pérez <pere...@gmail.com>:

Quizás podes ver diferencia a la hora de buscar soporte. Qt 4.8.5 está muy difundido y hay info y experiencias por todos lados. Mi experiencia es que al querer usar lo último de lo último, a veces te termina demorando y costando mucho tiempo/dinero. Personalmente uso Qt4.8.5 y deje Qt5 para un futuro cuando la tenga más clara y haya mas soporte en la comunidad de mi micro en particular.

OK

Nosotros estamos en Qt 4.8.5 todavía

(en realidad metimos Qt5 en un Ubuntu pero no anda ni para atrás, así que lo vamos a  volar)

[Ismael Luceno]

On Fri, 1 Aug 2014 16:00:44 -0300
Fernando Cacciola <fernando...@gmail.com> wrote:
> 2014-08-01 14:03 GMT-03:00 Santiago Pérez <pere...@gmail.com>:
>
> > Quizás podes ver diferencia a la hora de buscar soporte. Qt 4.8.5
> > está muy difundido y hay info y experiencias por todos lados. Mi
> > experiencia es que al querer usar lo último de lo último, a veces
> > te termina demorando y costando mucho tiempo/dinero. Personalmente
> > uso Qt4.8.5 y deje Qt5 para un futuro cuando la tenga más clara y
> > haya mas soporte en la comunidad de mi micro en particular.
> >
>
> OK
>
> Nosotros estamos en Qt 4.8.5 todavía
> (en realidad metimos Qt5 en un Ubuntu pero no anda ni para atrás, así
> que lo vamos a volar)

Todo depende de que tan tangencial sea la infraestructura a tu
proyecto, si es parte integral te conviene ir con lo último, ahora si
la idea es explotar lo que haya disponible y funcional, nada más,
entonces obviamente tendrías que ir con una solución "empresarial".

[Fernando Cacciola]

Claro, en nuestro caso es justamente bien tangencial y es como decís, más que nada cuestión de aprovechar lo que ya está disponible.

Por otro lado, en otro equipo de trabajo--que no es embebido, ni solo Linux--pasamos a Qt5 porque en Qt 4.8.5 había en bug justo en el componente que usamos (QtWebKitBridge para hostear apps web que hacemos pero en apps nativas que necesitan acceder a scanners y plotters), así que nunca es totalmente claro qué es lo mejor.

[Fernando Cacciola]

2014-08-01 15:16 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

X11 tambien puede acceder al framebuffer y dibujar sobre el usando el driver fbdev. Qt embedded, en vez de usar X11 para dibujar las ventanas, implementa un servidor grafico propio (QWS) para reemplazar a X11 y dibujar directamente sobre el framebuffer a pedido de las aplicaciones. Estas dibujan en buffers propios y luego el servidor QWS las compone sobre el area de memoria del framebuffer.

Ahhhhh. OK. Eso fué lo que entedí primero, pero alguien del equipo acá me dijo que no puede ser y que tiene que ser sobre X11.

Para nada, si usa X11, no es Qt Embedded (salvo por el simulador de QWS que corre como aplicación de X11 pero eso es como un VNC medio raro -perdón la falta de precisión pero no hay muchas formas de explicarlo sin mirar el código-

De hecho, la prueba de que eso NO es así es el link que te pase al proyecto (unipersonal y ya abandonado) de QDE que es un desktop completo sin X11.

OK

[Fernando Cacciola]

2014-08-01 15:28 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

El 1 de agosto de 2014, 15:08, Fernando Cacciola <fernando...@gmail.com> escribió:

2014-08-01 12:05 GMT-03:00 Ismael Luceno <ismael...@gmail.com>:

On Fri, 1 Aug 2014 10:55:37 -0300
>

Hola.

QT 4.8 y QT 5 deberían andar perfecto. Idealmente deberías aprovechar
QPA (Lighthouse), ya que en mi experiencia funciona mejor que QWS, y si
podés lidiar con QT 5, las mejoras son substanciales (he usado QT 5 en
entornos de producción desde fines del 2011 sin problemas).

OK.

Estoy mirando QPA y parece bastante verde tambien.

Para nada, QPA es una tecnología probada con mas de 4 años de desarrollo.

Tal vez la confusión venga por el hecho de que QPA es una infraestructura mas que un producto acabado. Lo mismo que Wayland.

Lo que me dio esa impresión es que prácticamente no pude encontrar documentación al respecto en el sitio de Qt, salvo esto:

http://qt-project.org/doc/qt-5/qpa.html

que es muy poco convincente.

 

Aquí, en el mundillo de linux embebido, hablar de productos acabados o de cosas maduras es. tácitamente, hablar de servicios de terceros que se cobran.

Claro.
 

Normalmente, todo esto, requiere de hacking bastante avanzado y no es nada parecido a un PIC que con algunas librerías salimos del paso.

Justamente, nosotros (va, el único embedded programer que tenemos) tiene experiencia en PICs y Assembler, nada de Linux.

Y el resto, que no son embedded programmers, en Qt para Desktop.

Pero ahora queremos a intentar hacer algo con el R-Pi, aunque no es nuestro Core bussines, por eso solo estamos estudiando las opciones por ahora.

 

Hay muchos proyectos avanzando en paralelo e interaccionando entre si para crear un sistema como Linux/Android/etc. y todos ellos tienen sus pros y sus contras, así que es parte del trabajo de ingeniería entender el ecosistema y dominar las herramientas que sean  necesarias para el trabajo a realizar.

Claro
 

Personalmente, creo que por mucho que nos guste jugar con la parte técnica, hay una verdad incuestionable a la hora del diseño, esto es una parte de un todo y como tal, debe cumplir su cometido.

Frente a eso, muchas veces debemos refrenar nuestra tendencia teki y buscar el camino critico de la solución. Cosa que no siempre es facil ni clara ;-) y mucho menos de respuesta única.

Totalmente.
 

Y en ese sentido lo que estamos haciendo en este preciso momento es usar el R-Pi con un Raspian, que si tiene el X11 y ademas un LXDE, y sobre eso poner un Qt4 convencional, NO embebido. Esto porque nos pone en un ambiente de desarollo conocido (no embebido) y quizas sea más que suficiente para lo que queremos.

Lo que sí hicimos fue "configurar" el Raspian para que tenga las características de un "aparato" y que un usuario no pueda matar nuesta app y tener el sistema en sus manos. Bueno, que e sea bastante díficil al menos.

[martin ribelotta]

QPA es mayormente una API privada. Esto es, no hay documentación oficial debido a que no se comprometen a mantener un ABI estable entre version menor y version menor (4.X.Y to 4.Z.T o 5.a.b to 5.c.d)

De todas formas, lo ideal seria que poco se tenga que tocar de eso ya que hay varias infraestructuras que vienen de fabrica con QPA (plataform plugins):

* directfb (linux)

* Android (surface flinger sobre linux)

* X11 (sistemas POSIX que tengan XCB como API para ser mas preciso)

* win32 (solo en sistemas NT6+)

* cocoa (MacOS/iOS)

* QNX

* VxWorks

* fbdev (linux framebuffer) (solo una APP puede acceder al FB al mismo tiempo)

* egl-es (OpenGL-ES en linux)

* KMS (nueva infraestructura de linux framebuffer)

Toda esta información la podes sacar del codigo fuente de Qt (sory, en este mundo es leer codigo o morir jejeje):

https://qt.gitorious.org/qt/qt/source/416272fbc4a6b88433eed7f01a37dd77b02b327f:src/plugins/platforms

Y por supuesto el plugin de Wayland que ya te pase el link y es un proyecto aparte que implementa tanto plugin de aplicaciones como varios compositores que pueden hablarle al framebuffer, a opengl-es o a KMS.

--

[Fernando Cacciola]

2014-08-01 17:28 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

QPA es mayormente una API privada. Esto es, no hay documentación oficial debido a que no se comprometen a mantener un ABI estable entre version menor y version menor (4.X.Y to 4.Z.T o 5.a.b to 5.c.d)

De todas formas, lo ideal seria que poco se tenga que tocar de eso ya que hay varias infraestructuras que vienen de fabrica con QPA (plataform plugins):

* directfb (linux)

* Android (surface flinger sobre linux)

* X11 (sistemas POSIX que tengan XCB como API para ser mas preciso)

* win32 (solo en sistemas NT6+)

* cocoa (MacOS/iOS)

* QNX

* VxWorks

* fbdev (linux framebuffer) (solo una APP puede acceder al FB al mismo tiempo)

* egl-es (OpenGL-ES en linux)

* KMS (nueva infraestructura de linux framebuffer)

Toda esta información la podes sacar del codigo fuente de Qt (sory, en este mundo es leer codigo o morir jejeje):

https://qt.gitorious.org/qt/qt/source/416272fbc4a6b88433eed7f01a37dd77b02b327f:src/plugins/platforms

OK

Al menos el código no miente :)

Y por supuesto el plugin de Wayland que ya te pase el link y es un proyecto aparte que implementa tanto plugin de aplicaciones como varios compositores que pueden hablarle al framebuffer, a opengl-es o a KMS.

OK

Bueno, tengo para entretenerme un buen rato con toda esta data!

[Martin Menchon]

Hola:
Yo estuve trabajando con Qt con Raspbian y Raspberry pi. Tuve muy malas experiencias. De hecho la exposición que vamos a realizar en el SASE habla sobre eso tmb. Primero usamos librerias cross compiladas con Qt 4.8 en Windows 7. Hasta ahi todo bien, incluso andaba OpenCv, pero luego quisimos acelerar con OpenGl y las librerias para Windows no soportan OpenGl. Migramos a linux y Qt 5 que si lo soporta. Pero debido a un error de Qt, no funcionaba ninguna aplicación.
Consejo, ahorrate un problema, o usa Windows o no uses Qt
Saludos.
Martín

[martin ribelotta]

Es muy raro lo que contas, normalmente todos los que conosco, pudieron hacer andar Qt mucho mejor que otras librerias (gtk, fltk, wxWidgets, etc.)

El 5 de agosto de 2014, 21:40, Martin Menchon <martin...@gmail.com> escribió:

Hola:
Yo estuve trabajando con Qt con Raspbian y Raspberry pi. Tuve muy malas experiencias. De hecho la exposición que vamos a realizar en el SASE habla sobre eso tmb. Primero usamos librerias cross compiladas con Qt 4.8 en Windows 7. Hasta ahi todo bien, incluso andaba OpenCv, pero luego quisimos acelerar con OpenGl y las librerias para Windows no soportan OpenGl.

Windows en general es una garcha que no soporta OpenGL para nada. Qt5 soluciono ese problema en windows con las librerias Angle que transforman las primitivas OpenGL en DirectX11+

 

Migramos a linux y Qt 5 que si lo soporta. Pero debido a un error de Qt, no funcionaba ninguna aplicación.

Es muy raro, seria bueno saber cual es el error de Qt al que te referís para poder estar atentos a eso o poder decidir si usar o no Qt con algún criterio dependiente de la situación.

 

Consejo, ahorrate un problema, o usa Windows o no uses Qt

Windows en un ARM11??? Yo no lo recomiendo para nada jejejeje.

 

Eso es también muy raro porque Qt hoy es la librería con mayor soporte multiplataforma que hay. De hecho, la mayoría de aplicaciones Qt funcionan sin ningún cambio en el código entre las plataformas soportadas, incluso en cosas tan dispares como VxWorks, QNX y winCE (creo que esto ya no se soporta mas, ahora soportan WinRT)

Seria interesante que detalles un poco mas tu problema por este medio, porque sino una recomendación tan general suena a FUD cuando en realidad puede estar escondiendo un problema serio de los framework de los que hablas y ninguno de los de acá nos hemos topado con ello, por eso compartir las experiencias en este tipo de listas es importante para todos.

Saludos.

 

Saludos.
Martín

[Santiago Pérez]

Siguiendo el hilo pregunto en este post, si les parece que corresponde a otro lo mudamos.

Entonces Qt4.x.x+OpenGL solo es posible con X11 y no con framebuffer? (independientemente del fabricante de hardware). Googlee bastante y también en los foros de Qt pero nada me convenció del todo.

Saludos,

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[martin ribelotta]

Para variar: Depende.

Qt4+OpenGL está probado y andando en X11, Win32 y MacOS-X.

Qt4+OpenGL no existe en otro lado. Lo que existe es una implementación, dependiente del hardware de OpenGL-ES+EGL (EGL que es el mecanismo por el cual se piden los buffers de dibujo, es lo dependiente del fabricante) que Qt-embedded puede usar para operar EN LUGAR DEL FRAMEBUFFER (eso no le habla al framebuffer de linux sino al hardware directamente usando la libreria del fabricante egl).

Qt4+framebuffer POR DEFINICIÓN no tiene OpenGL.

[Santiago Pérez]

O sea que, si no entendí mal, no es posible tener una aplicación embebida con Qt4 que normalmente utilice el framebuffer (a través de qws) y que pueda acelerar ciertos gráficos (render 3d, charts, lo que sea) a través del GPU con OpenGL-ES (brindándome el vendor el correspondiente driver)?. Solo lo podría hacer a través de X11 en mi linux embebido?

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[martin ribelotta]

Así es, Qt4-embedded usando el framebuffer no puede acelerar el dibujado usando OpenGL.

Pero eso no quiere decir que Qt4-embedded no pueda dibujar usando OpenGL(-es) ya que QWS tiene un mecanismo plugeable de display drivers.

Para conseguir dibujar con OpenGL(-ES), se reemplaza el driver del framebuffer por uno dependiente de la implementación Open-GL(-ES) que, utilizando el API EGL (estándar definido por el Kronos Group - los mismos de OpenGL) puede pedir uno o varios "framebuffers" a la placa de vídeo (normalmente embebida) que sirvan a la aplicación para dibujar con las librerías del fabricante de la placa.

Esa era la situación en Qt4 y por eso, se re implemento todo el subsistema QWS y se lo llamó QPA (Q Plataform Abstraction) que resuelve muchas de las limitaciones de QWS en cuanto a OpenGL y otros temas (renderizado de fuentes, sincronización, portabilidad, etc.)

De hecho, Qt5 es, en todas sus versiones, la misma librería Qt usando distintos plugins de QPA, con lo que podríamos decir, que Qt5 es Qt-embedded extendida en todas sus verciones (X11, Win32, MacOS-X, framebuffer o lo que sea)

Perdón si mis respuestas no son todo lo concretas que uno desearía, es porque hay muchos mas matices que el simple hecho de "es así" o "no es así"

Un saludo!

[Fernando Lichtschein]

Han logrado que me sienta totalmente perdido....

[Santiago Pérez]

Jajajajajajajaaja, welcome to the jungle... somos varios en la jungla. Tengo que procesar aún el excelente mail de Martín para responderlo decentemente...

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[Santiago Pérez]

Martín, gracias por la respuesta y los detalles. Arrancando el lunes te contesto un poco más fresco.

El 8 de agosto de 2014, 17:59, martin ribelotta <martinr...@gmail.com> escribió:

Así es, Qt4-embedded usando el framebuffer no puede acelerar el dibujado usando OpenGL.

Ahora me cierran muchas cosas...

Pero eso no quiere decir que Qt4-embedded no pueda dibujar usando OpenGL(-es) ya que QWS tiene un mecanismo plugeable de display drivers.

Para conseguir dibujar con OpenGL(-ES), se reemplaza el driver del framebuffer por uno dependiente de la implementación Open-GL(-ES) que, utilizando el API EGL (estándar definido por el Kronos Group - los mismos de OpenGL) puede pedir uno o varios "framebuffers" a la placa de vídeo (normalmente embebida) que sirvan a la aplicación para dibujar con las librerías del fabricante de la placa.

Acá me perdí. Por ejemplo, yo tengo un micro que tiene su GPU. El vendor me provee de un driver para funcionar con OpenGLES, el cual incorporo a mi rootfs y utilizo para compilar mi versión de Qt4 embebida (en mi qmake.conf especifico este driver y el path correspondiente y agrego en el configure la opción correspondiente, la cual creo que es -opengl). Si compilo para QWS, que sería la llamada "embebida", ya puedo utilizar el framebuffer con opengl o estos plugins y drivers a los que haces referencia aún falta agregarlos?. Sería en la aplicación propiamente dicha o en la configuración de Qt4?.

Muchas preguntas, pero esta es la parte complicada me parece...

Esa era la situación en Qt4 y por eso, se re implemento todo el subsistema QWS y se lo llamó QPA (Q Plataform Abstraction) que resuelve muchas de las limitaciones de QWS en cuanto a OpenGL y otros temas (renderizado de fuentes, sincronización, portabilidad, etc.)

De hecho, Qt5 es, en todas sus versiones, la misma librería Qt usando distintos plugins de QPA, con lo que podríamos decir, que Qt5 es Qt-embedded extendida en todas sus versiones (X11, Win32, MacOS-X, framebuffer o lo que sea)

O sea que si quiero usar Qt5, solo debo especificar el plugin a utilizar según mi hardware? En que parte del proceso sería? En la configuración/compilación de Qt? Lo de los plugins es medio confuso a veces, quizás hasta que uno le agarre la mano.

Perdón si mis respuestas no son todo lo concretas que uno desearía, es porque hay muchos mas matices que el simple hecho de "es así" o "no es así"

Todo lo contrario, sino no hay forma de poder entender, aunque a veces uno se pierda más aún, ja!.

Un saludo!

 

Abrazo!

Santiago

[martin ribelotta]

Hola Santiago, colgue mal con este tema, te iba a responder apenas tuviera algun rato (e internet) en el SASE pero me fue imposible y recien ahora veo el borrador que empece a hacer ;-).

Va entre lineas:

El 11 de agosto de 2014, 9:29, Santiago Pérez <pere...@gmail.com> escribió:

Martín, gracias por la respuesta y los detalles. Arrancando el lunes te contesto un poco más fresco.

El 8 de agosto de 2014, 17:59, martin ribelotta <martinr...@gmail.com> escribió:

Así es, Qt4-embedded usando el framebuffer no puede acelerar el dibujado usando OpenGL.

Ahora me cierran muchas cosas...

Pero eso no quiere decir que Qt4-embedded no pueda dibujar usando OpenGL(-es) ya que QWS tiene un mecanismo plugeable de display drivers.

Para conseguir dibujar con OpenGL(-ES), se reemplaza el driver del framebuffer por uno dependiente de la implementación Open-GL(-ES) que, utilizando el API EGL (estándar definido por el Kronos Group - los mismos de OpenGL) puede pedir uno o varios "framebuffers" a la placa de vídeo (normalmente embebida) que sirvan a la aplicación para dibujar con las librerías del fabricante de la placa.

Acá me perdí. Por ejemplo, yo tengo un micro que tiene su GPU. El vendor me provee de un driver para funcionar con OpenGLES, el cual incorporo a mi rootfs y utilizo para compilar mi versión de Qt4 embebida (en mi qmake.conf especifico este driver y el path correspondiente y agrego en el configure la opción correspondiente, la cual creo que es -opengl). Si compilo para QWS, que sería la llamada "embebida", ya puedo utilizar el framebuffer con opengl o estos plugins y drivers a los que haces referencia aún falta agregarlos?. Sería en la aplicación propiamente dicha o en la configuración de Qt4?.

Muchas preguntas, pero esta es la parte complicada me parece...

Esta es la parte mas complicada de todas en Qt4 porque QWS nunca previó un mecanismo de integración para OpenGL así que cada fabricante hace lo que se le canta como se le canta y muchos no hacen nada... Por eso Qt5 trato de tomar el toro por las hastas con QPA.

Por desgracia, la unica implementación que conosco andando es la que viene como ejemplos en los drivers de Qt, la de PowerVR.

Lo que contiene este driver, es basicamente, la implementación del plugin de screen para QWS y la implementación de QPainter que usa OpenGL-ES debajo y se hermana con el screen de QWS comentado primero para pasar los buffers de datos. Una verdadera negrada solo aplicable a esta arquitectura y solo funcional con los drivers propietarios de PowerVR (que son una libreria, que entre otras cosas, te permite hacer graficos presindiendo del framebuffer, como plus, acelerados por hardware)

De hecho, es tan verga, que los de Texas hicieron un tutorial para poder tenerlo andando en sus SoC's
http://processors.wiki.ti.com/index.php/Building_Qt_with_OpenGL_ES_accelerated_by_SGX

 

Esa era la situación en Qt4 y por eso, se re implemento todo el subsistema QWS y se lo llamó QPA (Q Plataform Abstraction) que resuelve muchas de las limitaciones de QWS en cuanto a OpenGL y otros temas (renderizado de fuentes, sincronización, portabilidad, etc.)

De hecho, Qt5 es, en todas sus versiones, la misma librería Qt usando distintos plugins de QPA, con lo que podríamos decir, que Qt5 es Qt-embedded extendida en todas sus versiones (X11, Win32, MacOS-X, framebuffer o lo que sea)

O sea que si quiero usar Qt5, solo debo especificar el plugin a utilizar según mi hardware? En que parte del proceso sería? En la configuración/compilación de Qt? Lo de los plugins es medio confuso a veces, quizás hasta que uno le agarre la mano.

La infraestructura QPA a utilizar se puede especificar aplicación por aplicacón, usando el parametro -platform <drivername>

Tambien acepta la variable de entorno QT_QPA_PLATFORM con el mismo parametro.

Una explicación mas tecnica de como funciona QPA la podes encontrar aqui:
http://qforever.wordpress.com/2012/04/10/qt-platform-abstraction-starter-guide/
http://blog.qt.digia.com/blog/category/qpa/

O directamente en el codigo fuente... que siempre a sido mi salvación para estas cosas de magia vudí.

Por si solo, QPA provee dos plugins para trabajar con plataformas OpenGL:

* eglfs: API EGL estandar que requiere de la libreria egl del fabricante (esto en entornos open source lo provee la libreria mesa junto con el API OpenGL-ES, normalmente, los fabricantes tienen esto incluido en una sola libreria llamada libeglfs.so o libopengles2.so)

* minimalegl: Verción reducida del driver anterior sin manejo de geometrias (todo es sobre fullscreen) pero si me preguntan, no tengo ni idea de las diferencias fundamentales. Posiblemente eglfs mapee mejor el API que minimalegl pero requiera de una implementación mas completa de EGL que no todos los fabricantes proveen.

Aparte, podemos encontrar el plugin OpenWF que implementa este API (OpenWF es un protocolo y API que Kronos pensó para resolver todo el bardo al rededor de EGL y los sistemas de ventanas con composición)

No conosco a ningun fabricante que implemente OpenWF pero de tenerlo, es mucho mas comodo que EGL porque (potencialmente) podrias tener un sistema de ventanas funcional para multiples aplicaciones.

Seria bueno que Wayland se siña en algun momento a OpenWF (basicamente Wayland implementa un compositor de ventanas y OpenWF es un estandar para implementar compositores de ventanas) pero no se si está en sus objetivos a largo/corto/mediano/negativo plazo ni se si OpenWF tiene vista a futuro.

Todo esto, hablando de tener UNA SOLA aplicación que acceda a OpenGL (ES) a travez de EGL. Si ya tenemos que coordinar el acceso de varias aplicaciones y componer varias superficies (lease ventanas) en un mismo screen (ni hablar de manejar varios screens) solo tenemos la opción de Wayland o (si existe implementacion) de OpenWF.

Por desgracia, Wayland, para trabajar con los buffers de video, debe conocer el mecanismo de DMA entre el CPU y la GPU. Esto requiere proveer un API desde el driver de la placa para pasar buffers (ya sea con arquitectura UMA o NUMA).

En Linux-PC esto se resuelve con el subsistema GEM (Graphics Execution Manager, execution porque basicamente pasa programas a la GPU) y lo implementan la mayoria de los drivers como los de intel, AMD y VIA. NVidia, tiene su propio sistema de DMA el cual no conosco para nada, pero tengo entendido que piensan pasar a DMABUF (una evolución de GEM) en breve, anticipandose a Wayland.

En embebidos, esto es menos uniforme porque tambien las arquitecturas varian entre NUMA/UMA/*MA dependiendo de con que pie se levante el equipo de diseño del SoC ese dia.

Lo que todos estan mas o menos de acuerdo es en proporcionar un API openGL-ES (porque eso requiere el subsistema grafico de Android) y de llamar al mecanismo de pasaje de buffers "gralloc".

Por ejemplo, la RasberryPi usa un mecanismo de pasaje de buffers llamado BRCM usando los drivers "propietarios" (mas o menos) de Broadcom. Otros drivers de Android, pueden implementar las cosas distinto.

Como verás, esto es bastante enredado, y ni siquiera los mismos desarrolladores de drivers/graficas se ponen de acuerdo en como hacer las cosas.

Si tenes algun problema en concreto con estos temas, estaria bueno que lo compartamos ya que es algo bastante molesto el tener que resolver todo a mano y por separado. En este aspecto, embebidos32 le está ganando a stackoverflow en info!!!!!

[Ezequiel Garcia]

On Friday, August 1, 2014 11:05:09 AM UTC-3, Fernando Cacciola wrote:

Quisiera saber si alguno de uds ha tenido experiencia usando Qt for Embedded Linux.

Estamos por comenzar con un desarollo y tenemos pensado usar un Raspberry, con Raspian y Qt for Embedded Linux.

Eso funciona bien?

 
Si sirve de algo, el año pasado un proyecto de GSoC consistió en mejorar el soporte en Buildroot:

http://lists.busybox.net/pipermail/buildroot/2013-October/079906.html

Qt5 compila perfectamente en Buildroot, aunque solamente lo hemos usado para dar soporte 2D, con lo cuál el escenario es bastante más simple. Pero para pasar de usar Raspbian a usar Buildroot, hay que tener un poco de idea; Linux Embebido no es VB5.0 :-)

[Fernando Cacciola]

Gracias por el dato.

Vamos a mirar ese GSoC entonces...
 

[Santiago Pérez]

Este soporte de Buildroot es solo para las plataformas que menciona (raspberry pi, beagleboard, beaglebone, cubieboard, otras) o en general?.

Cuando hablas de 2D te referís a alguna aceleración por hard para 2D o 2D pelado digamos?

Gracias por la data,

Santiago

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

--

[Santiago Pérez]

Gracias por el tiempo y respuesta Martín, y citando a Fernando me sumo al "Han logrado que me sienta totalmente perdido....", jeje.

A modo de resumen de tu último mail, veo que el soporte de GPU cpn Qt4 es bastante complicado (o poco uniforme digamos), sobre todo con QWS (aunque también con X11???).

Por otro lado, QPA parece ser más sencillo, lo que implica utilizar Qt5 y según se dijo alguna vez, necesitas mandatoriamente GPU con su driver para poder siquiera compilar Qt5 (aunque no se use). Corríjanme si en este punto estoy equivocado.

La semana pasada intenté utilizar The Yocto Project para generar mi rootfs con Qt y aceleración por hard (sobre todo por el tema aceleración de hard), ya que todo indica que está más desarrollado y actualizada la herramienta que por ejemplo LTIB, si se utiliza Freescale. Me quedé sin espacio en el disco al 80% del proceso... consume muchísimo de espacio porque baja y compila absolutamente todo... se habla, dependiendo de las características de la imagen a crear, de entre 20-40gB por lo menos (mi caso es más el segundo). En estas semanas voy a volver a intentarlo, porque soporta varios micros conocidos y está bastante activo el tema. Aviso novedades si este modo agiliza el tema del thread.

Saludos!,

Santiago

--
Atentamente//With best Regards/Mit freundlichen Grüßen

Santiago Pérez
Ingeniero Electrónico

pere...@gmail.com
Córdoba, Argentina.

[martin ribelotta]

El 3 de septiembre de 2014, 8:50, Santiago Pérez <pere...@gmail.com> escribió:

Gracias por el tiempo y respuesta Martín, y citando a Fernando me sumo al "Han logrado que me sienta totalmente perdido....", jeje.

A modo de resumen de tu último mail, veo que el soporte de GPU cpn Qt4 es bastante complicado (o poco uniforme digamos), sobre todo con QWS (aunque también con X11???).

En X11 existe un estandar avierto llamado GLX que es una forma de implementar OpenGL sobre el protocolo X. Esta plataforma surgue junto con los trabajos de SGI (creador de opengl) y es lo mas extendido en graficos del mundo unix.

Por ende, Qt sobre X11 tiene soporte nativo de OpenGL (no ES, pero tambien podria) si el driver de X11 soporta openGL (es decir, implementa GLX). Aqui, las consideraciones no difieren de las del escritorio. 

Por otro lado, QPA parece ser más sencillo, lo que implica utilizar Qt5 y según se dijo alguna vez, necesitas mandatoriamente GPU con su driver para poder siquiera compilar Qt5 (aunque no se use). Corríjanme si en este punto estoy equivocado.

No necesariamente, si no tenes GPU podes usar mesa con el driver software (LLVMPipe o softgl) para poder emular toda la capa openGL.

Sino, podes usar el raster engine de Qt y olvidarte de compilar toda la parte de QML y QtQuick (que es la única que requiere realmente OpenGL)

 

La semana pasada intenté utilizar The Yocto Project para generar mi rootfs con Qt y aceleración por hard (sobre todo por el tema aceleración de hard), ya que todo indica que está más desarrollado y actualizada la herramienta que por ejemplo LTIB, si se utiliza Freescale. Me quedé sin espacio en el disco al 80% del proceso... consume muchísimo de espacio porque baja y compila absolutamente todo... se habla, dependiendo de las características de la imagen a crear, de entre 20-40gB por lo menos (mi caso es más el segundo). En estas semanas voy a volver a intentarlo, porque soporta varios micros conocidos y está bastante activo el tema. Aviso novedades si este modo agiliza el tema del thread.

Éxitos, esperamos a ver como te fue!