GUI without X (ткните в документацию)

[AND]

Здравствуйте!
Есть обычный x86 компьютер, ядро Linux, bash, минимальный набор программ, web-сервер(lighttpd)+php-cgi.
Хочу сделать примитивный интерфейс с использованием QtWebKit.
Иксов нет, только framebuffer.
Кто-нибудь сталкивался с подобными задачами. Как лучше реализовать?

[Swappp]

http://doc.trolltech.com/4.5/qt-embedded-install.html
Какие проблемы?

[tohisu]

Всем привет!
Срочно надо разобраться с разработкой на QTEmbedded под arm архитектуру.
Сейчас я пытаюсь у себя на машине собрать qtopia и запустить демо примеры.

Собираю так:
1) cd /home/ozzy/Desktop/qt
2) tar xzvf qt-embedded-linux-opensource-src-4.5.3.tar.gz
3) mkdir /home/ozzy/qtopia
4) cd /home/ozzy/qtopia
5) /home/ozzy/Desktop/qt/qt-embedded-linux-opensource-src-4.5.3/configure -qt-gfx-qvfb -no-qt3support  -developer-build -silent
6) make
ждем дофига времени (кстати можно ускорить процесс? процессор загружен очень не сильно в процессе сборки)
7) make install

Все собирается ставится, но с виртуальным фрэм буфером что-то не понимаю я...
После сборки пытаюсь выполнить:  bin/qtdemo -qws -display QVFb:0
Результат:
  QVFb: driver cannot connect
  Aborted

И теперь непосредственно как быть с ARM архитектурой? Я так понимаю надо задать при конфигурации ключик -embedded arm, но при сборке проблема с компилятором (нет грит).

ЗЫ.
Вопросы новичка, кем я собственно и являюсь в QTEmbedded, но очень горят сроки, а времени вдумчиво читать доки очень мало... ((((

[Rcus]

Для того чтобы виртуальный фреймбуффер работал он должен быть утилита qvfb входит в состав Qt/X11.

Для сборки под архитектуру arm (а arm'ов много разных, PXA27x и Cortex A8 это... хм, довольно большая разница) нужно взять исходники gcc и собрать кросс-компилятор (если только у вас случайно нет рабочего репозитория). У меня рабочая среда для кросскомпиляции построена по книге CLFS.

И да, если настолько горят сроки что кода еще нет, а документации читать уже некогда значит что-то не так...

[tohisu]

И да, если настолько горят сроки что кода еще нет, а документации читать уже некогда значит что-то не так...

Не, на самом деле все нормально, сейчас (буквально сегодня завтра) надо добиться запуска нашего демо приложения на девайсе. Это делаем с целью проверить будет ли оно вообще работать, а если будет, то как шустро. Сама разработка будет занимать достаточное время.
Кстати, может кто-нибудь уже сталкивался с разработкой под такое "несильное" железо и может ответить как qt будет работать на нем?
Собственно железо: CPU: Samsung Arm9 200MHz; RAM: 32Mb; Место под операционку с программами примерно 50 метров (может тут я и не прав).

Для того чтобы виртуальный фреймбуффер работал он должен быть утилита qvfb входит в состав Qt/X11.

Угу, вроде вот он: qt-x11-opensource-src-4.5.3/tools/qvfb
Т.е. я должен сбилдить ее, а потом куда положить чтобы запускалось? Как вообще потом запускать это?

Для сборки под архитектуру arm (а arm'ов много разных, PXA27x и Cortex A8 это... хм, довольно большая разница) нужно взять исходники gcc и собрать кросс-компилятор (если только у вас случайно нет рабочего репозитория). У меня рабочая среда для кросскомпиляции построена по книге CLFS.

К девайсу идет toolchain в котором есть какие-то компиляторы:
ozzy@ozzy-desktop:/arm-9tdmi-linux-gnu/gcc-3.3.4-glibc-2.2.5$ ls
arm-9tdmi-linux-gnu  arm-linux  bin  include  info  lib  libexec  man  tmp

ozzy@ozzy-desktop:/arm-9tdmi-linux-gnu/gcc-3.3.4-glibc-2.2.5/bin$ ls
arm-9tdmi-linux-gnu-addr2line  arm-9tdmi-linux-gnu-ld       arm-linux-c++
arm-9tdmi-linux-gnu-ar         arm-9tdmi-linux-gnu-nm       arm-linux-cpp
arm-9tdmi-linux-gnu-as         arm-9tdmi-linux-gnu-objcopy  arm-linux-g++
arm-9tdmi-linux-gnu-c++        arm-9tdmi-linux-gnu-objdump  arm-linux-gcc
arm-9tdmi-linux-gnu-c++filt    arm-9tdmi-linux-gnu-ranlib   arm-linux-ld
arm-9tdmi-linux-gnu-cpp        arm-9tdmi-linux-gnu-readelf  arm-linux-nm
arm-9tdmi-linux-gnu-g++        arm-9tdmi-linux-gnu-size     arm-linux-objcopy
arm-9tdmi-linux-gnu-gcc        arm-9tdmi-linux-gnu-strings  arm-linux-objdump
arm-9tdmi-linux-gnu-gcc-3.3.4  arm-9tdmi-linux-gnu-strip    arm-linux-ranlib
arm-9tdmi-linux-gnu-gccbug     arm-linux-addr2line          arm-linux-readelf
arm-9tdmi-linux-gnu-gcov       arm-linux-ar                 arm-linux-strip
arm-9tdmi-linux-gnu-gprof      arm-linux-as

Только как их пользовать пока не понял

[Rcus]

На "несильном" железе Qt работает прекрасно, у меня пока платформа pxa270 - все вполне летает, проблема только правильно порезать библиотеку для уменьшения времени старта.

По поводу qvfb. Да ее нужно собрать, запускать лучше скриптом с передачей параметров экрана.

Чтобы собрать Qt достаточно добавить указанный путь в $PATH.

[tohisu]

Чтобы собрать Qt достаточно добавить указанный путь в $PATH.

Указанный путь до компиляторов всмысле?
export PATH=$PATH:/arm-9tdmi-linux-gnu/gcc-3.3.4-glibc-2.2.5/bin

А потом при конфигурировании библиотек просто указывать -embedded arm?
Я так пробовал не могу найти компилятор говорит...

[Rcus]

Ну должно работать, он же должен писать какой компилятор не может найти, вот отрывок mkspecs/qws/arm-linux-g++/qmake.conf.

Код:

# modifications to g++.conf
QMAKE_CC                = arm-linux-gcc
QMAKE_CXX               = arm-linux-g++
QMAKE_LINK              = arm-linux-g++
QMAKE_LINK_SHLIB        = arm-linux-g++

# modifications to linux.conf
QMAKE_AR                = arm-linux-ar cqs
QMAKE_OBJCOPY           = arm-linux-objcopy
QMAKE_STRIP             = arm-linux-strip

Можно там конечно полные пути прописать, но лучше разобраться в проблеме.ъ
ADD: Интересно - тулчейн поставлен в корень?

[tohisu]

Так, с фрэймбуфером почти разобрался
После того как я его собрал и запустил, демо приложение смогло отобразится:

ozzy@ozzy-desktop:~/qtopia/bin$ ./qtdemo -qws -display "QVFb:0"
Connected to VFB server QVFb:0: 800 x 600 x 4 282x212mm (72x72dpi)
Cannot open keyboard: Permission denied

Но чет траблы с мышом и клавиатурой.... Поддержку клавы и мышки надо было при построении библиотек указывать да? Или ключик хитрый есть? Хотя в документации только вот это:

-width <value>   The width of the virtual framebuffer (default: 240).
-height <value>   The height of the virtual framebuffer (default: 320).
-depth <value>   The depth of the virtual framebuffer (1, 8 or 32; default: .
-nocursor   Do not display the X11 cursor in the framebuffer window.
-qwsdisplay <:id>   The Qt for Embedded Linux display ID (default: 0).
-skin <name>.skin   The preferred skin. Note that the skin must be located in Qt's /tools/qvfb/ directory.
-zoom <factor>   Scales the application view with the given factor.

ADD: Интересно - тулчейн поставлен в корень?

Да, так в его инстал гайде было написано... не стал я с ним спорить

Хорошо, теперь следующий шаг, запустить это все на устройстве. Со сборкой библиотек под arm я сейчас разбираюсь, а потом как это закидывать на устройство? Т.е. я имею ввиду я могу же закинуть все библиотеки и исполнимый файл в одну папку? Или есть скрипт который подготовит сборку для устройства?

[Rcus]

Вместо -qt-gfx-qvfb надо было указать ключ -qvfb, иначе собирается только плагин дисплея.

[Rcus]

Хорошо, теперь следующий шаг, запустить это все на устройстве. Со сборкой библиотек под arm я сейчас разбираюсь, а потом как это закидывать на устройство? Т.е. я имею ввиду я могу же закинуть все библиотеки и исполнимый файл в одну папку? Или есть скрипт который подготовит сборку для устройства?

Хороший вопрос: у меня на устройстве для отладки предусмотрена возможность подключения флешки в качестве корневой системы (ядро грузится с внутренней флеш памяти). При этом можно подлкючиться к консоли через серийный порт. В релизе старт программы заносится в /etc/inittab, корневая система упаковывается в squashfs и заливается в память через dd. Библиотеки конечно располагаются по системным путям (хотя можно поправить /etc/ld.so.conf)

[tohisu]

Похоже заливать смогу только вместе с прошивкой. Ну да ладно главное, что можно тестироваться на десктопной машине без проблем. )
Просматривал я сейчас файловую систему, которая заливается в машинку и не заметил в папке /dev файла fb0.
Это плохо? При загрузке системы он появится? Вообще у меня на Ubuntu тоже его нету. Подозреваю за ненадобностью т.к. стоит XWindows? И на машинке что-то должно стоять вроде. Только не знаю где смотреть.

ЗЫ
Никогда ни копал в этом направлении.

[Rcus]

/dev/* это просто символьные имена для обращений к драйверам (обычно общение сводится к open/close/ioctl и т.п., в частности для подсистемы fb возможные запросы описаны в /usr/include/linux/fb.h, но Qt это хорошо скроет от вас если только не понадобится использовать специфичные способности оборудования вроде аппаратного оверлея).
Создаются эти псевдофайлы ядром, так что если нет нужного драйвера то и символьного имени не будет. Так же и /proc является отображением состояния процессов из ядра в пространство пользователя.

[tohisu]

Удалось подключиться к девайсине по ssh (через usb порт). С флэшки создал символьные линки для библиотек в /usr/lib/. После чего запустил демо приложение ./textedit -qws
Ура! Работает!
Только пока не могу определить производительность qt на этом девайсе.
Есть пара вопросов:
1) Как запустится в режиме 16 оттенков серого и разрешении 600*800 и отключить курсор мышки?
2) При старте девайса запускается приложение которое рулит всеми остальными. Попытался его снести как получил проблему (девайс стал мигать экраном), но при этом текстэдитор получал пользовательский ввод. После того как приложение вернул обратно оказалось, что оно перехватывает пользовательский ввод.
В общем не могу найти где прописан запуск этого приложения? Надо его изменить на мое приложение.

[whirlwind]

1. чтобы отключить курсор мыши, можно использовать ключ -nomouse. Правда, не знаю, будет ли в таком случае тачскрин работать. Если 600*800 - разрешение вашего экрана, возможно, лучше запускать приложение фулскрином.
2. посмотрите в /etc/inittab , вдруг оттуда