Комментарии 17
Когда драйвер закрытый, получится ли мне обновить Ubuntu? Насколько сложно будет подцепить этот драйвер при сборке своего приложения Qt? Вот в первом посте https://forum.armbian.com/topic/1420-opengl-on-mali-gpu-bananapi-orangepi-pc-etc/ человек показывает казалось бы по шагам как он дружил открытый драйвер со своим одноплатником, но это же тихий ужас! Тем более, что пакеты обновляются, возникают новые нюансы, на это тратится время. На что тратится, чтобы ТЗ выполнить? Нет, время тратится чтобы инструментарий настроить — не хотелось бы так.
Что касается odroid, разве они ещё выпускают SBC?
Тоже смотрел в сторону OPi, система выделяется ценой. А в плане поддержки — полный ноль. Allwinner — производитель с плохой поддержкой продукции, толком ничего не найти на него. На какого клиента они рассчитывают — непонятно.
Allwinner разве ещё жив? Сейчас в основном RK3399 ставят, хотя его не купишь в розницу, так что надо в сторону STM32MP157 смотреть.
Кто знает, может доживём и до открытого GPU
QT_QPA_EGLFS_
Этот самый EGLFS вещь полезная и интересная, но с одним не достатком — информации маловато будет.
Есть документация на сайте самого Qt, легко ищется по связке «qt eglsf» или «qt embedded linux». Но при этом, возникает чувство что не все описано. Или описание не подробное.
Там же часть параметров можно внутри кода прописать, часть через переменные в самом linux. Может кто знает, где ещё можно почитать про этого зверя?
Концептуально отличается от linuxfb тем что имеется минимальное аппаратное ускорение
при блитте поверхностей.
Таким образом сначала надо сконфигруировать framebuffer, а затем через переменную окружения указать активный «qpa»
Информации на самом деле достаточно. К примеру вот здесь неплохо описано:
doc.qt.io/qt-5/embedded-linux.html
К примеру вот здесь неплохо описано:
это знаем, зачитывали, можно сказать, до дыр. Там ещё рядом есть страничка для тачскрина.
Концептуально отличается от linuxfb тем что имеется минимальное аппаратное ускорение при блитте поверхностей.
А как определить тип рендера для него?
Для примера, возьмем одноплатник с GPU совмещенного с основными ядрами. Как понять, что рендер графики идет через GPU, а не программно на ЦП. И можно ли явно указать, через что рендерить?
Нужно ли в самом проекте анализировать переменные окружения или фреймворк это делает за нас автоматически? Например, режим поддержки hiDPI.
./configure… -eglfs -opengl es2…
Во время сборки используются заголовочные файлы и .so от вендора, где включено аппратаное ускорение.
Но надо понимать что для eglfs ускорение используется очень ограниченно. Большинство графических примитивов отрисовываются в software режиме, но на EGL плоскости. И ускорение в основном касается блитта и копирования части графической поверхности.
Хорошо написали. А что мне нужно подтянуть на мой ПК для кросскомпиляции Qt в случае Orange Pi? Советы для RPI не подходят.
В rootfs должны быть не только .h файлы для соответсвующих либ, но и pkgconfig/*.pc файлы зависимостей. Плюс для configure должен быть соответсвующий файл
Вот к примеру сниппет для сборки
export SDK_DIR=/myplatform/sdk
export TOOLCHAIN_SYSROOT=$SDK_DIR/output/socplatform/host/arm-linux-gnueabihf/sysroot
export PATH=$PATH:$SDK_DIR/output/socplatform/host/bin
export PKG_CONFIG_LIBDIR=$TOOLCHAIN_SYSROOT/usr/lib/pkgconfig
export PKG_CONFIG_PATH=$(PKG_CONFIG_LIBDIR)
export PREFIX=$SDK_DIR/output/socplatform/qt-5.8.0
mkdir $SDK_DIR/output/socplatform/qt-5.8.0/ext
mkdir $SDK_DIR/output/socplatform/qt-5.8.0/host
./configure -v -extprefix $PREFIX/ext -hostprefix $PREFIX/host \
-release -opensource -confirm-license -qpa eglfs -qt-pcre -fontconfig -pkg-config -no-pch -no-xcb -no-dbus -no-iconv -no-cups -no-gtk -system-zlib >
-no-rpath -make libs -nomake tests -nomake examples -no-warnings-are-errors -no-qml-debug \
-D EGL_FBDEV -eglfs -opengl es2 -recheck-all \
-platform linux-g++-64 -device linux-arm-myplatformhf -device-option CROSS_COMPILE=arm-linux-gnueabihf- -device-option TOOLCHAIN_SYSROOT="$TOOLCHAIN_>
-skip qt3d -skip qtactiveqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtdoc -skip qtgamepa>
-skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtnetworkauth -skip qtpurchasing -skip qtquickcontrols2 -skip qtscript -skip qtscxml -s>
-skip qtserialbus -skip qtserialport -skip qtspeech -skip qtsvg -skip qttools -skip qttranslations -skip qtvirtualkeyboard -skip qtwayland -skip qt>
-skip qtquickcontrols -skip webengine -skip qtdeclarative -skip qtwebchannel -skip qtwebsockets
Qt, как очевидно из статьи, доступен в исходных кодах, так что собрать можно под что угодно. Лицензия — другой вопрос, но он возникает только если вы закрываете исходный код своего ПО. Если вы используете x86_64, можно ничего не собирать, а скачать Qt вместе с IDE Qt Creator с офсайта бесплатно хоть под Ubuntu, хоть под Windows. Однако в таком случае (без статической сборки Qt) будет проблематично создавать исполняемые файлы программ, как многие привыкли с какой-нибудь вижл студио: сделал build и получил exe, этот exe скинул другу на все компы без вижл студио. Так что статически собирать Qt (чему сей туториал посвящен) надо уметь.
Qt собрать по данному туториалу можно практически под любой SBC, потому что тут не кросскомпиляция. Обычно самое запарное — в видеодрайверах. На большистве SBC используется ARM MALI видеокарта, обычно народ с ней пытается дружить через драйвер mesa. Но дружить так, чтобы было ещё и аппаратное ускорение обычно увы не получается, в этом смысле дорогие raspberry ушли вперед, открыв свой видеодрайвер.
1) Многие раздают wifi со своего ноутбука и хотят подключиться к нему с SBC. Как это сделать:
sudo nmcli dev wifi connect myWiFiName password myWifiPassword
2) Надо узнать какой ip выдал наш ноутбук к SBC:
sudo arp | sort
3) теперь можно подключаться, например
ssh a@192.168.0.104
или
rsync -avz /home/laptop/Documents/myQtProj a@192.168.0.104:/home/a/
А вот удобный дружелюбный интерфейс для настройки раздачи wifi.
Одноплатный компьютер для embedded программиста