Софт для ZN5 и прочих MotoMAGX: MGX и PEP, Разработка, портирование и обсуждение нативного софта Поделиться Опции

[EXL]

Мануал: Компиляция приложений для MotoMAGX OS, создание пакетов



Для портирования и сборки приложений для нашей платформы в первую очередь нам нужны:

1. Компьютер с Linux OS. Или Windows OS с установленным Virtual BOX/VMware Player, в крайнем случае под виндой можно воспользоваться AndLinux'ом или Cygwin'ом.
2. SDK & Toolchains для MotoMagX + Исходники программ/приложений.
3. Программист/Разработчик или начинающий программист (1 шт.).

Я рассмотрю наиболее приемлемый многим начинающим разработчикам способ, с использованием популярного дистрибутива Ubuntu 11 (Linux OS) в виртуальной машине VMware Player в Windows OS. Те пользователи, у которых стоит Linux OS на компе, могут скачать SDK & Toolchains | Зеркало | Зеркало | Зеркало и сразу перескочить на пункт #4.

Итак, начнём:

1. Загрузка необходимых для разработки инструментов и файлов:

1.1. Скачиваем ISO-образ диска Ubuntu 11. Я качал себе в городской сетке, пошарьтесь в своих тоже, может найдёте. На всякий случай, ссылка: [Download | Скачать] на скачивание с официального сайта: http://www.ubuntu.com Там вы можете выбрать любую конфигурацию под свой компьютер (amd/i386) и т.д.

1.2. Скачиваем VMware Player - Скачать можно с официального сайта: [Download | Скачать] или тут: [Mirror | Зеркало]

1.3. Скачиваем SDK & Toolchains для MotoMagX. [Download | Скачать] - полная версия, включающая в себя 2 тулчейна SDL (От испанцев) + QT (От Ant-On'a) а также python, bennugd, boost и множество различных библиотек. Инструкция по установке есть внутри или ниже можно прочитать подробно.
Тем, кто хочет разрабатывать приложения на SDL, можно скачать небольшой тулчейн для сборки приложений: [Download | Скачать] [Mirror | Зеркало]

2. Мануалы по установке VMware, Ubuntu и SDK & Toolchains в картинках:*
* - картинки открывать лучше всего в новом окне, нажав колёсико мышки. После открытия воспользуйтесь масштабированием, например, в стандартном просмоторщике картинок.

2.1. Установка программы VMware для самых маленьких.
2.2. Установка Linux OS в программу VMware, на примере Ubuntu 11.
2.3. Установка дополнительных инструментов (VMware-tools) в Ubuntu 11. Необходимо для перемещения файлов между Ubuntu в виртуальной машине и виндой.

2.1.:    2.2.:    2.3.:



3. Мануалы по установке, текстом.

3.1. Установка VMware-tools для Ubuntu 11.
3.1.1. Стартуем Ubuntu 11, вверху нажимаем "Virtual Machine", затем "Install VMware Tools...
3.1.2. Ждём загрузки инструментов (нужно подключение к интернету!), затем снова вверху нажимаем "Virtual Machine" -> "Install VMware Tools...
3.1.3. С открывшегося диска копируем архив в формате *.tar.gz например в /home/user (user - ваше имя при установке Ubuntu), распаковываем его.
3.1.4. Запускаем терминал и выполняем в нём следующее:

Код

cd /home/user/vmware-tools-distrib
sudo ./vmware-install.pl

После команды sudo надо ввести пароль, который мы указывали при установке Ubuntu.
3.1.5. Умный скрипт сам предложит вам вводить нужные значения (в квадратных скобках), вводите их.
3.1.6. После успешной установки инструментов, перезагрузите компьютер.
3.1.7. Данные инструменты помогут с лёгкостью переносить файлы из Windows в Linux Ubuntu, просто копируя их или перенося из окна в окно, как вы это делали в Windows. Кроме того, появится множество разрешений для экрана системы.

3.2. Общие папки между системами для обмена файлами.
3.2.1. Стартуем Ubuntu 11, вверху нажимаем "Virtual Machine", затем "Virtual Machine Settings"
3.2.2. Переходим на вкладку "Options", выбираем "Shared Folders"
3.2.3. Переключатель "Folder sharing" ставим в положение "Always enabled", нажимаем кнопку "Add".
3.2.4. На компьютере выбираем любую папку, добавляем её, жмём ОК.
3.2.5. Теперь в Ubunte, в папке /mnt/hgfs видим добавленную нами папку из Windows.

4. Установка SDK & Toolchains.

4.1. Скачиваем архив тулчейна (*.tar.gz), перемещаем его в папку /home/user (user - ник при установке Ubuntu).
4.2. Выполняем команды, новая строка - Enter, вместо user естественно пишем своё имя, после команды sudo потребуется ввести пароль, который мы указывали при установке Ubuntu.

Код

sudo mkdir /mmc
sudo chown user -R /opt
sudo chown user -R /home
sudo chown user -R /mmc
sudo ln -s -d /opt/toolchains/motomagx/arm-eabi -t /
mkdir /opt/toolchains
mkdir /home/z6
mkdir /mmc/mmca1
tar -C /opt/toolchains -xzvf /home/user/motomagx-toolchains_12_08_2011.tar.gz
cp /opt/toolchains/motomagx/setenv-z6.sh /home/z6
cp /opt/toolchains/motomagx/setenv-z6-2.sh /home/z6

4.3. Обратите внимание на имя скаченного вами архива с тулчейном! Именно его нужно вводить в восьмой строке кода, приведённого выше!
4.4. Установленный тулчейн:


5. Запуск окружения, компиляция программ и helloworld'a.

5.1. Чтобы запустить окружение для компиляции под MotoMagx, достаточно выполнить в терминале следующее:

Код

cd /home/z6
. setenv-z6.sh

После этого, компиляторы, библиотеки и хэдеры будут браться из нашего тулчейна, а не с компьютера.

5.2. HelloWorld.
5.2.1. Создаём пустой файл с именем hello.c в папке /home/z6 (Правой клавишей по пустому месту, "Create Document" -> "Empty File")
5.2.2. Редактируем его содержимое следующим образом, сохраняем:

Код

// Hello World for Motorola Magx!

#include <stdio.h>

int main(void)
{
    printf ("Hello Moto!!!\n");
    return 0;
}

5.2.3. Компилируем:

Код

cd /home/z6
arm-linux-gnueabi-gcc hello.c -o hello

5.2.4. Полученный исполнительный файл "hello" кидаем на телефон и запускаем через телнет!

Код

Mobilinux(TM) 4.1
Welcome 2 Motorola ZN5!
[root@Symbiosis ~]
#> /mmc/mmca1/hello
Hello Moto!!!

5.3. Работа с утилитой Make* и SDL библиотекой.
* - Утилита Make позволяет компилировать достаточно сложные проекты. Подробнее тут: http://ru.wikipedia.org/wiki/Make
5.3.1. Скачиваем следующие исходники, распаковываем в папку /home/z6:

ballgame_src.tar.gz   ( 34 килобайт ) Кол-во скачиваний: 21672

5.3.2. Запускаем терминал и окружение для компиляции, переходим в папку с проектом, выполняем команду make:

Код

cd /home/z6/ballgame_src
make

После выполнения команды будет выполнена компиляция проекта и создан mgx пакет. Для очистки проекта от объектного кода и бинарников, следует выполнить make clean. Для создание mgx пакета - команду make mgx.
5.3.3. Теперь можно кинуть пакет на карту памяти и попробовать запустить. (Для SDL приложений вам потребуется установленные SDL-библиотеки!)
5.3.4. Структура простейшего Makefile для компиляции HelloWorld'a:

Код

# MakeFile for HelloWorld
# Motorola MotoMAGX

CC = arm-linux-gnueabi-gcc  
STRIP = arm-linux-gnueabi-strip
  
CFLAGS = # Необходимые флаги
LDFLAGS = # Необходимые флаги
OPTIMIZATION = -march=armv6j -mtune=arm1136jf-s -mfpu=vfp -O2 # Оптимизация под процессор

INCLUDE = $(CFLAGS) $(OPTIMIZATION) -I/dir # Путь к нужным хэдэрам.
LIBS = $(LDFLAGS) -L/dir # Путь к нужным либам

BIN = hello # Бинарник

all:
    $(CC) -c hello.c -o hello.o $(INCLUDE)
    $(CC) -o $(BIN) hello.o $(LIBS)
    $(STRIP) $(BIN)
clean:
    rm -f ./*.o $(BIN)

Если положить данный Makefile рядом с hello.c, и выполнить make, получим исполнительный файл.
5.3.5. Замена строк, для портирования SDL проектов:

Код

CC:=gcc ---> CC:=arm-linux-gnueabi-gcc
cc=gcc ---> CC=arm-linux-gnueabi-gcc
cxx=g++ ---> CXX=arm-linux-gnueabi-g++
ld=ld ---> LD=arm-linux-gnueabi-ld
ar=ar ---> AR=arm-linux-gnueabi-ar
as=as---> AS=arm-linux-gnueabi-as
oc=oc ---> OC=arm-linux-gnueabi-objcopy
ranlib=ranlib ---> RANLIB=arm-linux-gnueabi-ranlib
strip=strip ---> STRIP=arm-linux-gnueabi-strip
В INCLUDE или CFLAGS добавляем `sdl-config --cflags`
В LIBS или LDFLAGS добавляем `sdl-config --libs` -lнеобходимая_библиотека

5.4. Работа с утилитой configure* и SDL библиотекой.
* - Скрипт configure создаёт Makefile и позволяет компилировать сложные проекты, состоящие из множества файлов. Подробнее тут: http://en.wikipedia.org/wiki/Configure_script
5.4.1. Пример работы. Скачиваем исходники, распаковываем в папку /home/z6:

PTC-demos.tar.gz   ( 33.29 килобайт ) Кол-во скачиваний: 21788

5.4.2. Выполняем следующее:

Код

cd /home/z6/PTC-demos
./configure --host=arm-linux-gnueabi
make

После этих команд у нас появятся исполнительные файлы Fire и Tunnel. Копируем их в корень карточки телефона.
5.4.3. Запускаем через телнет следующим образом:

Код

export LD_LIBRARY_PATH=/mmc/mmca1/games/lib:$LD_LIBRARY_PATH
chmod +x /mmc/mmca1/Fire
/mmc/mmca1/Fire

5.4.4. Для установки файлов в нужную директорию используется prefix и команда make install:

Код

mkdir /home/z6/test
cd /home/z6/PTC-demos
./configure --host=arm-linux-gnueabi --prefix=/home/z6/test
make
make install

После этого нужные нам файлы будут в папке /home/z6/test.
5.4.5. Для чистки объектного кода и бинарников используется команда make clean, для удаления сконфигурированных Makefile'ов используется команда make distclean (полная очистка).

5.5. Деббагер "Segmentation fault"
5.5.1. Качаем gdb и распаковываем архив на карту памяти, в папку /mmc/mmca1/games
Исполнительные файлы должны быть собраны с префиксом '-g' и не должны быть пострипаные
5.5.2. Выполняем (gdb):

Код

ulimit -c unlimited
./<bin_app>
Segmentation fault (core dumped)
файл <core> будет создан
../bin/gdb ./<bin_app> <core>

5.5.3 Выполняем (strace):

Код

../bin/strace ./<bin_app>

5.6. Скрипт запуска для SDL приложений:

Код

#!/bin/sh
mypath=${0%/*}
LIBDIR1=/ezxlocal/download/mystuff/games/lib
LIBDIR2=/mmc/mmca1/games/lib
LIBDIR3=$mypath/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LIBDIR1:$LIBDIR2:$LIBDIR3
export HOME=$mypath
export SDL_QT_INVERT_ROTATION=1
cd $mypath
sleep 1

exec $mypath/<bin_app>

5.6.1. Если нужен вывод лога в файл, заменяем последнюю строку в скрипте на

Код

exec $mypath/bin_app >$mypath/stdout.txt 2>$mypath/stderr.txt

5.7. HelloWorld с использованием GUI и функций телефона.
5.7.1. Скачиваем архив, распаковываем в /home/z6:

Helloworld_GUI.tar.gz   ( 80.01 килобайт ) Кол-во скачиваний: 21975

5.7.2. Выполняем:

Код

cd /home/z6/папка с нужным проектом
make PLATFORM=EZX-ZN5

или просто make
5.7.3. Кидаем исполнительные файлы на телефон и пробуем запустить, должно получиться что-то типа этого:


5.8. Собираем MgxBox.
5.8.1. Скачиваем архив, распаковываем в /home/z6:

MgxBox.tar.gz   ( 5.23 мегабайт ) Кол-во скачиваний: 23238

5.8.2. Выполняем:

Код

cd /home/z6/MgxBox/MgxBox_GUI_ru
make PLATFORM=EZX-ZN5
cd /home/z6/MgxBox/p7zip_9.20.1
make all2
make install
cp -r /mmc/mmca1/p7zip/lib/p7zip /home/z6/MgxBox/Release/app/p7zip

5.8.3. Кидаем папку /home/z6/MgxBox/Release на телефон и пробуем запустить бинарник в папке Release/app, если всё нормально, должно получиться что-то типа этого:


6. Создание пакетов вручную.

6.1. Создание MGX пакета:
6.1.1. Создаём папку, помещаем в нее необходимые файлы (дата файлы приложения, исполнительные файлы, скрипт запуска, иконку).
6.1.2. Создаём в папке файл "Имя папки".cfg, редактируем его содержимое следующим образом:

Код

Name = Test
Exec = run.sh
Icon = icon.png
Author = Ant-ON
Version = 1.0
Comment = Port for ZN5 by EXL

Где, Name - имя программы, Exec - запускаемый файл, Icon - иконка, Author - Автор программы, Version - Версия программы, Comment - Комментарий.
6.1.3. Запаковываем папку в любой удобный вам архив (RAR, TAR, GZ, 7Z, ZIP), и переименовываем в "имя программы".mgx

6.2. Создание PEP пакета:
6.2.1. Создаём папку с именем "app", помещаем в нее необходимые файлы (дата файлы приложения, исполнительные файлы, скрипт запуска).
6.2.2. Создаём рядом с папкой файл "description.ini", редактируем его содержимое следующим образом:

Код

[Actions]
Silent=0
InstallApp = 1  
AddAppToMenu = 1

[InstallApp]
Name = Jump n Blob
Exec = run.sh
InstallPath = ../../mmc/mmca1/.Programs/jump_n_blob/
AppLockable = 1
Author = http://www.2d-retroperspectives.org | Philipp. Port by -=Strelok=-, EXL (c) MotoFan.Ru 08.01.2010
Version = 0.1
Daemon = 1
BigIcon= icon.png
AniIcon= icon.png
Icon= icon.png

[AddAppToMenu]
ParentFolder= root

Где, Name - имя программы, Exec - запускаемый файл, Icon | AniIcon | BigIcon - иконка, Author - Автор программы, Version - Версия программы, InstallPath - Путь установки.
6.2.3. Создаём иконку, рядом с папкой "app" и "description.ini".
6.2.4. Запаковываем иконку, папку "app" и "description.ini" в архив формата TAR, затем сжимаем его в GZ переименовываем в "имя программы".pep

7. Полезные ссылки, документация, наши проекты.

7.1. Исходники, сайты с исходниками. Множество интересных проектов есть на code.google.com и sf.net
7.1.1. Исходники проектов, базирующихся на SDL:
libsdl.org/games
libsdl.org/demos
http://dl.openhandhelds.org/cgi-bin/gp2x.cgi?0,0,0,0,46
http://dl.openhandhelds.org/cgi-bin/dingoo.cgi?0,0,0,0,46
7.1.2. Исходники проектов, базирующихся на QT:
http://www.elsix.org/index.php?w=browse - В основном там под Sharp Zaurus, но идеи создания приложений и сорцы найти можно.

7.2. Документация, темы для прочтения:
Пробуем портировать игры и проги сами
Разработка софта под MOTOMAGX, начну небольшой HOWTO
Компиляция нативных приложений под E6/A1200, Создание окружения для компиляции
SDL библиотека
http://plg.lrn.ru/wiki/Заглавная_Страница
http://plg.lrn.ru/doc/sdl/index.html
http://doc.qt.nokia.com

7.3. Проекты:
http://code.google.com/p/open-mgx/ - исходники программ от Ant-On'a
http://code.google.com/p/sdl-magx/ - библиотека SDL HW для MotoMAgx от Ant-On'a
http://code.google.com/p/zmessanger/ - нативная аська, автор Ant-On
http://sourceforge.net/projects/qte2console/ - qte2console от DoomChisel
http://code.google.com/p/motocakerteam/ - исходники программ от испанцев MotoCakerTeam
http://code.google.com/p/zsoft/

8. Мануалы данной темы:

Если кто не может запустить ZN5Encoder в Magic box - пост #290
Нативные заставки на основе портированных мной и Neomoto демок! - пост #291
Мануал по установке Tmake в тулчейн, и правки созданного им MakeFile - пост #484
Изучение разделяемых библиотек (so) - пост #1440
Эмуляция нажатия клавиш на Motorola ZN5 - пост #1684

© EXL for MotoFan.Ru 27.08.2011

[EXL]

Может задумка была шобы подключалося всё кроме модема?

Вряд ли, скорее всего просто по аналогии делали.

[fill.sa]

На магиксе а режиме модем эмулируется типовой модем и должен работать со стандарными драйверами модема. Никакого доп кода для этого ненужно.
Про пид я писал, их два в зависимости от режима телефона.

[EXL]

Разобрался с тем, как генерировать нажатия клавиш на клавиатуре MotoMAGX-телефонов программно, вставляя KeyEvent'ы прямо в очередь драйвера. Буду писать здесь всю информацию на всякий случай, поэтому пост получится объёмным. Если лень всё это читать, переходите сразу в последний практический раздел в самом низу поста. Итак, в MotoMAGX-телефонах в /dev/ имеется несколько типов устройств. На старой платформе LJ 6.x (Z6, V8, ZN5, U9, Z6W, AURA) используются /dev/keypad0, /dev/keypadI и /dev/keypadB, которые возможно остались ещё в наследство от EZX, а на LJ 7.x (E8, EM30, VE66, EM35, VA76r и MotoMAGX Emulator) используется одно всеобъемлющее устройство /dev/vkm через которое можно управлять огромным количеством всяких разных Event'ов, в т. ч. и сенсорным колесом Omega Wheel. Но пока нас интересует лишь отправка нажатий на кнопки телефона.

Работа с /dev/vkm и /dev/keypadX происходит через функцию ioctl(), в аргументы которой вставляется либо адрес структуры, которая содержит всю необходимую информацию, либо просто нужный keycode у KeyEvent'а, пример кода на языке программирования "C" для двух разных драйверов:

Код

static int send_event_to_vkm_driver(const int vkm_device_fd, const key_code_long_t keycode) {
    fprintf(stderr, "Keycode is: 0x%08X, dec: %u\n", keycode, keycode);

    MOTO_INPUT_EVENT_T vkm_event;
    vkm_event.type = MOTO_INPUT_EVENT_TYPE_KEY;
    vkm_event.event.key_event = (keycode | MOTO_INPUT_KEY_EVENT_PRESSED_MASK);

    return ioctl(vkm_device_fd, MOTO_INPUT_IOC_INSERT_EVENT, &vkm_event);
}

static int send_event_to_keypad_driver(const int keypad_device_fd, const key_code_short_t keycode) {
    fprintf(stderr, "Keycode is: 0x%04X, dec: %hu\n", keycode, keycode);

    return ioctl(device_fd, KEYPAD_IOC_INSERT_EVENT, (keycode | KEYDOWN));
}

Интересный момент. Посылка драйверу обычного keycode'а кнопки означает отжатие клавиши. Для того, чтобы зарегистрировать именно нажатие старший бит в keycode'е должен быть установлен в "1", что достигается конструкцией (keycode | KEYDOWN) для /dev/keypadX, где KEYDOWN это 0x8000 (16-битное целое число) или (keycode | MOTO_INPUT_KEY_EVENT_PRESSED_MASK) для /dev/vkm, где MOTO_INPUT_KEY_EVENT_PRESSED_MASK это 0x80000000 (32-битное целое число).

В итоге у меня получилась такая вот простенькая утилитка pushkey, исходный код которой опубликован здесь: https://github.com/EXL/keyd/blob/master/pushkey/pushkey.c

Использовать её можно как-то так:

Код

|pushkey| by EXL, v1.0, 14-Nov-2021

Usage:
    pushkey <keycode> <device> <mode>

Examples:
    pushkey 0x8001         # Нажать кнопку "1" на устройстве "/dev/keypadI", обычный режим
    pushkey 0x0001         # Отпустить кнопку "1" на устройстве "/dev/keypadI", обычный режим

    pushkey 0x8001 i       # Нажать кнопку "1" на устройстве "/dev/keypadI", обычный режим
    pushkey 0x0001 i       # Отпустить кнопку "1" на устройстве "/dev/keypadI", обычный режим

    pushkey 0x8001 b       # Нажать кнопку "1" на устройстве "/dev/keypadB", обычный режим
    pushkey 0x0001 b       # Отпустить кнопку "1" на устройстве "/dev/keypadB", обычный режим

    pushkey 0x31 i a       # Нажать кнопку "1" на устройстве "/dev/keypadI", режим ASCII
    pushkey 0x31 b a       # Нажать кнопку "1" на устройстве "/dev/keypadB", режим ASCII

    pushkey 0x0001 i s     # Нажать кнопку "1" на устройстве "/dev/keypadI", режим одиночного нажатия
    pushkey 0x0001 b s     # Нажать кнопку "1" на устройстве "/dev/keypadB", режим одиночного нажатия

    pushkey 0x80000004 v   # Нажать кнопку "4" на устройстве "/dev/vkm", обычный режим
    pushkey 0x00000004 v   # Отпустить кнопку "4" на устройстве "/dev/vkm", обычный режим

    pushkey 0x00000004 v s # Нажать кнопку "4" на устройстве "/dev/vkm", режим одиночного нажатия

Распишу немного подробнее. В обычном режиме, который активирован по умолчанию, происходит отправка одного Event'а с выбранным keycode'ом в аргументе утилиты. То есть за нажатием клавиши должен явно следовать вызов этой же утилиты с keycode'ом её отжатия. Подобное в теории можно использовать для эмуляции длительного нажатия клавиши таким образом:

Код

#!/bin/sh
pushkey 0x8001
sleep 2
pushkey 0x0001

Хотя это пока не тестировалось. Режим одиночного нажатия кнопки посылает за Event'ом с keycode'ом нажатия клавиши сразу же Event её отжатия, это наиболее подходящий режим для того чтобы разово эмулировать нажатие какой-либо клавиши на клавиатуре. Режим ASCII наверное действует аналогично режиму одиночного нажатия, только вместо keycode'а в качестве аргумента он принимает код символа из таблицы ASCII, например, у единички это будет 0x31, а вот какие там коды использовала Motorola для таких кнопок, как красная и зелёная трубки, мне неизвестно, поскольку реального мобильного телефона у меня нет, чтобы это проверить.

Касательно устройств, то как уже было отмечено выше, на Motorola ZN5 используется /dev/keypadI и /dev/keypadB, первое устройство реагирует на отправку нажатий цифровой клавиатуры, красной и зелёной трубок и пр. (протестировано), а вот за что отвечает второе устройство я пока не знаю. Возможно за нажатия кнопок на дополнительной Morphing Mode клавиатуре, там где корзинка удаления изображения из приложения Галереи и прочее. Либо же за кнопки на проводной или Bluetooth-гарнитурах. А может быть вообще для каких-то служебных целей, на что намекает комментарий в заголовочном файле ядра. Если кто выяснит назначение /dev/keypadB, отпишитесь пожалуйста в этой теме.

Теперь самое интересное, коды клавиш. Для устройства /dev/vkm я ничего не смог найти в заголовочных файлах, зато нашёл кучку файликов в MotoMAGX Emulator, где перечислены эти коды на различных раскладках клавиатуры, которые видимо планировалось использовать в реальных устройствах. Но похоже что они не совсем полные. Для эмулятора используется раскладка 6x6 (упоминаются ещё 5x5 и 8x8), которая выглядит вот так:

Код

# This file defines the mapping from the function key name to
# the key index used in VKM -- standard 6x6 keypad device driver.
KEYPAD_6              = 0
KEYPAD_8              = 1
KEYPAD_7              = 2
KEYPAD_2              = 3
KEYPAD_4              = 4
KEYPAD_RIGHT          = 6
KEYPAD_DOWN           = 7
KEYPAD_9              = 8
KEYPAD_UP             = 9
KEYPAD_LEFT           = 10
KEYPAD_1              = 12
KEYPAD_3              = 13
KEYPAD_5              = 14
KEYPAD_SIDE_SELECT    = 15
KEYPAD_SIDE_UP        = 16
KEYPAD_MENU           = 18
KEYPAD_SLEFT          = 19
KEYPAD_STAR           = 20
KEYPAD_SEND           = 21
KEYPAD_SRIGHT         = 22
KEYPAD_CARRIER        = 24
KEYPAD_CLEAR          = 25
KEYPAD_POUND          = 26
KEYPAD_SIDE_DOWN      = 28
KEYPAD_AF             = 30
KEYPAD_0              = 32
KEYPAD_IMAGING        = 35
KEYPAD_END            = 36

Файлики эти я тоже прикрепляю, может кому-нибудь они пригодятся. А вот для устройств /dev/keypadI и /dev/keypadB, которые используются на Motorola ZN5, определения кодов кнопок доступны в исходниках ядра, в заголовочном файле keypad.h: https://github.com/fillsa/motomagx-kernel_linux_hardhat/blob/master/linux-2.6.x/include/linux/keypad.h:125-257, их можно все протестировать и посмотреть что именно происходит при их отправке в драйвер. Только нужно не забывать конвертировать их из DEC в HEX, для этого можно использовать python:

Код

python
>>> hex(23)
'0x17'
>>> hex(36)
'0x24'
>>> hex(45)
'0x2d'

Благодаря тому, что отправка Event'ов теперь работает, можно к Web-серверу в телефоне прикрутить не только просмотр экрана, но и удалённое управление телефоном или попытаться доделать VNC Server.

Эмуляция нажатия клавиш на Motorola ZN5

1. Открываем по ссылке файлик keypad.h, находим в нём секцию в которой перечислены keycode'ы.
2. Конвертируем код клавиши из DEC в HEX, например, для клавиши Backspace KEYPAD_CLEAR 22, это будет 0x16.
3. Запускаем утилиту pushkey со слеудующими аргументами и проверяем что эта клавиша нажалась на телефоне:

Код

pushkey 0x0016 i s

4. Повторяем для следующей интересующей нас кнопки.

В итоге для использования утилиты или опубликованного мной API в своей программе можно составить необходимую таблицу заведомо рабочих keycode'ов и их ассоциаций с реальными кнопками на клавиатуре.

Прикреплённые файлы:

[VINRARUS]

EXL, класна игрушка!

Только нужно не забывать конвертировать их из DEC в HEX, для этого можно использовать python:

Ой, та ладно:

Код

printf "%x\n DEC

А вот шобы играться с шыком:

Код

while read N; do N=`printf "%x\n" $N`; ./pushkey 0x$N b s; done

Добавлено позже (14.11.2021, 23:54):
Проблемка с главной кнопой зины

Код

#запускаем камеру:
./pushkey 0x0019 b s

#фокусируемся на мгновение:
./pushkey 0x0036 b s

#фокус не происходит:
./pushkey 0x0036 b

#фоткать не выходит, хотя в режыме видео работает:
./pushkey 0x0019 b s

[EXL]

VINRARUS,
Я правильно понимаю, что KeyEvent'ы вставляются как в /dev/keypadI, так и в /dev/keypadB, разницы никакой нет? Или же они вставляются только в /dev/keypadB? Или же /dev/keypadB отвечает только за кнопки камеры? Проясни этот момент.

Проблемка с главной кнопой зины

Там кстати возможна такая ситуация, что зажатие кнопки детектируется не как обычное зажатие, а как очередь из KeyEvent'ов постоянных одиночных нажатий с каким-либо произвольным промежутком. У себя на эмуляторе попробовал верхнюю команду и удалось получить зажатие клавиши, попробуй нижнюю команду у себя:

Код

for i in $(seq 1 10); do ./pushkey_EMU 0x80000004 v; usleep 100000; done; usleep 100000; ./pushkey_EMU 0x00000004 v

for i in $(seq 1 10); do ./pushkey 0x8036 b; usleep 100000; done; usleep 100000; ./pushkey 0x0036 b

Нажатие кнопки фокуса будет как 0x8036, а вот отжатие на 0x0036, а ты просто отжимал эту кнопочку по идее. В общем экспериментируй потихоньку.

Если будет время, составь табличку вида:

Код

+-------------------------------------+----------------------------------+-------------------+-------------------+
| Название реальной кнопки в телефоне | Название кнопки в файле keypad.h | Код клавиши в HEX | Код клавиши в DEC |
+-------------------------------------+----------------------------------+-------------------+-------------------+
|                 "0"                 |            KEYPAD_0              |        0x00       |         0         |
|                 "1"                 |            KEYPAD_1              |        0x01       |         1         |
|                 "2"                 |            KEYPAD_2              |        0x02       |         2         |
|                 "3"                 |            KEYPAD_3              |        0x03       |         3         |
|                 "4"                 |            KEYPAD_4              |        0x04       |         4         |
|                 "5"                 |            KEYPAD_5              |        0x05       |         5         |
|                 "6"                 |            KEYPAD_6              |        0x06       |         6         |
|                 "7"                 |            KEYPAD_7              |        0x07       |         7         |
|                 "8"                 |            KEYPAD_8              |        0x08       |         8         |
|                 "9"                 |            KEYPAD_9              |        0x09       |         9         |
|                 "#"                 |          KEYPAD_POUND            |        0x0A       |         10        |
|                 "*"                 |          KEYPAD_START            |        0x0B       |         11        |
|                 ...                 |            ........              |        ....       |         ..        |
+-------------------------------------+----------------------------------+-------------------+-------------------+

Она поможет легче ориентироваться.

[VINRARUS]

Я правильно понимаю, что KeyEvent'ы вставляются как в /dev/keypadI, так и в /dev/keypadB, разницы никакой нет?

Я разницы не заметил пока вообще. Даже ести нажат a отжымается на b нормально.

Там кстати возможна такая ситуация, что зажатие кнопки детектируется не как обычное зажатие, а как очередь из KeyEvent'ов постоянных одиночных нажатий с каким-либо произвольным промежутком.

Та вроде нет.

Нажатие кнопки фокуса будет как 0x8036, а вот отжатие на 0x0036, а ты просто отжимал эту кнопочку по идее. В общем экспериментируй потихоньку.

Аааааааааааааааааааааааааааааааааааааааааааааааааа...
Я не заметил разницу между 0x8036 и 0x0036

Код

./pushkey 0x8036 a; sleep 1; ./pushkey 0x0019 b s; ./pushkey 0x0036 b

Так фокусируется и фоткает без проблем!

[EXL]

Я разницы не заметил пока вообще. blind.gif Даже ести нажат a отжымается на b нормально.

Хорошо, используй тогда "i", то есть /dev/keypadI по умолчанию, по крайней мере в keypad.h описание устройств следующее:

Код

/* device name from ezx */
#define DEVFS_NAME         "keypad0"
#define KEYPAD_DEVICENAME  "/dev/keypad0"

/* device name from juix, same as keypad0  */
#define DEVFS_JNAME         "keypad"
#define KEYPAD_JDEVICENAME  "/dev/keypad"

/* device name for inserting events */
#define DEVFS_INAME         "keypadI"
#define KEYPADI_DEVICENAME  "/dev/keypadI"

/* device name for getting bitmap information */
#define DEVFS_BNAME         "keypadB"
#define KEYPADB_DEVICENAME  "/dev/keypadB"

А устройства "a" там нет, только "i" /dev/keypadI, "b" /dev/keypadB и "v" /dev/vkm, это режимы третьим аргументом "a" ASCII или "s" Single идут.

Так фокусируется и фоткает без проблем! happy.gif

А вот так?

Код

./pushkey 0x8036 i; sleep 1; ./pushkey 0x0019 i s; ./pushkey 0x0036 i

[VINRARUS]

А устройства "a" там нет

Да блин. Это всё оранжевый шрифт...

А вот так?

Да, нармально фоткает.

Сообщение отредактировал VINRARUS - 16.11.2021, 19:44

[EXL]

VINRARUS,
Можешь теперь использовать эту утилитку в своём Web Server'е. Как я понял для того же снятия скриншота там бинарь qtsnap (или аналогичный) вызывается и перезаписывает скриншот-картинку, которая подцепляется потом сервером.

То есть если организовать на HTML-страничке "клавиатурку", клавиши которой будут вызывать pushkey с нужными аргументами и после перегружать "обновлять" этот скриншот, получится удалённое управление телефоном. Правда, не самое быстрое, конечно.

[VINRARUS]

Как я понял для того же снятия скриншота там бинарь qtsnap (или аналогичный) вызывается и перезаписывает скриншот-картинку, которая подцепляется потом сервером.

Токо он в png сохраняет, а это сильно нагружает ЦП. Можеш скриншотник консольный c сохранением в bmp сделать?
Думаю в bmp будет легче системе делать чем png или даже jpg.

и после перегружать "обновлять" этот скриншот

...или обновлять в фрейме постоянно, если не очень накладно по ЦП времени будет.

[EXL]

Можеш скриншотник консольный c сохранением в bmp сделать?

А исходники есть у кого этого скриншотника? С другой стороны BMP будет больше весить (всегда 230 КБ), нагрузка на сеть возрастёт. Если найду, пересоберу, посмотришь будет оно быстрее или нет.

[fill.sa]

VINRARUS,
Этож не калькулятор что бы на паре картинок заметить разницу пнг/бмп.
Поди видео вообще нельзя запускать в телефоне)

[EXL]

fill.sa,
https://github.com/EXL/ImageBenchmark
SAedition MOD для Zn5, самый быстрый мод

Да нет, там есть разница. Возможно что именно из-за этой разницы в том же iconres.ezx много каких иконок хранятся в BMP, или как там его *.g вроде называют, аналог насколько я понимаю. Место-то на флешке телефона не резиновое, если могли бы сжать, сжимали. А то эти громадные iconres.ezx'ы под 50 МБ встречаются на некоторых телефонах. Громадные из-за того, что там битмапы хранят.

[VINRARUS]

А исходники есть у кого этого скриншотника?

Есть бинарник.

[EXL]

VINRARUS, Спасибо, зареверсил бинарь и вижу что это какой-то слишком навороченный скриношотер, похоже там используется QBrush для рисования красного прямоугольниках где-то в углу экрана. Ещё работа с текстом какая-то есть и другая функциональность вроде поворота скриншота или подобное.

В итоге взял идею Ant-ON'а и получился такой простейший код, который использует чисто Qt'овские API для снятия скриншота довольно хитрым способом создания невидимого прозрачного QWidget'а на весь экран, "фоном" которого будет всё то, что лежит под ним:

Код

// zgrab.cpp
#include <qapplication.h>
#include <qpixmap.h>
#include <qwidget.h>

#include <stdio.h>

#define SCR_WIDTH  240
#define SCR_HEIGHT 320

int main(int argc, char *argv[]) {
    if (argc == 2) {
        QApplication app(argc, argv);
        QWidget fullScreenWidget(0);
        fullScreenWidget.setFocusPolicy(QWidget::NoFocus);
        fullScreenWidget.setBackgroundMode(QWidget::NoBackground);
        fullScreenWidget.setFixedSize(SCR_WIDTH, SCR_HEIGHT);
        fullScreenWidget.show();
        QPixmap fullScreenPixmap(SCR_WIDTH, SCR_HEIGHT, -1, QPixmap::BestOptim);
        bitBlt(&fullScreenPixmap, 0, 0, &fullScreenWidget, 0, 0, SCR_WIDTH, SCR_HEIGHT, Qt::CopyROP, true);
        fullScreenPixmap.save(argv[1], QStringList::split(".", argv[1])[1].upper());
    } else
        fprintf(stderr, "Usage:\n\tzgrab screenshot.<format>\n\nExample:\n\tzgrab screenshot.png\n\tzgrab screenshot.bmp\n");
    return 0;
}

Компилировать так:

Код

# Motorola ZN5
/arm-eabi/bin/arm-linux-gnueabi-g++ -pipe -DQWS -fno-exceptions -fno-rtti -Wall -W -O2 -I/arm-eabi/lib/qt-zn5/include -I/arm-eabi/lib/ezx-zn5/include -I/arm-eabi/arm-linux-gnueabi/include zgrab.cpp -o zgrab -Wl,-rpath-link,/arm-eabi/lib/ezx-zn5/lib -L/arm-eabi/lib/ezx-zn5/lib -lqte-mt
/arm-eabi/bin/arm-linux-gnueabi-strip -s zgrab

# MotoMAGX Emulator
/opt/toolchains/motomagx/emulator/bin/i686-mot-linux-gnu-g++ -pipe -DQWS -fno-exceptions -fno-rtti -Wall -W -O2 -I/opt/toolchains/motomagx/emulator/include zgrab.cpp -o zgrab -L/opt/toolchains/motomagx/emulator/lib -lqte-mt
/opt/toolchains/motomagx/emulator/bin/i686-mot-linux-gnu-strip -s zgrab

Использовать как:

Код

./zgrab screenshot.bmp
./zgrab screenshot.png
./zgrab screenshot.jpeg

Поддерживает следующие форматы в Qt: PNG, BMP, XBM, XPM, JPEG (писать расширение нужно именно как JPEG, не JPG), PBM, PGM, PPM. Форматы GIF и MNG не поддерживаются.

Заодно сделал небольшой бенчмарк по форматам в эмуляторе, хотя на реальном устройстве ситуация может сильно отличаться

Код

+----------+----------+----------+----------+----------+----------+----------+----------+
|   BMP    |   PNG    |   JPEG   |   XBM    |   XPM    |   PBM    |   PGM    |   PPM    |
+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.16s | 0m 0.08s | 0m 0.08s | 0m 0.26s | 0m 0.06s | 0m 0.07s | 0m 0.04s |
| 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.01s | 0m 0.11s | 0m 0.03s | 0m 0.01s | 0m 0.21s | 0m 0.01s | 0m 0.02s | 0m 0.01s |
+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.03s | 0m 0.18s | 0m 0.07s | 0m 0.04s | 0m 0.26s | 0m 0.07s | 0m 0.07s | 0m 0.03s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.01s |
| 0m 0.00s | 0m 0.12s | 0m 0.04s | 0m 0.01s | 0m 0.19s | 0m 0.01s | 0m 0.02s | 0m 0.01s |
+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.05s | 0m 0.15s | 0m 0.08s | 0m 0.07s | 0m 0.26s | 0m 0.07s | 0m 0.04s | 0m 0.05s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.01s | 0m 0.11s | 0m 0.01s | 0m 0.04s | 0m 0.20s | 0m 0.03s | 0m 0.01s | 0m 0.03s |
+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.07s | 0m 0.16s | 0m 0.08s | 0m 0.07s | 0m 0.27s | 0m 0.06s | 0m 0.03s | 0m 0.01s |
| 0m 0.01s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.02s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.03s | 0m 0.09s | 0m 0.02s | 0m 0.03s | 0m 0.20s | 0m 0.01s | 0m 0.00s | 0m 0.00s |
+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.15s | 0m 0.09s | 0m 0.08s | 0m 0.25s | 0m 0.06s | 0m 0.08s | 0m 0.05s |
| 0m 0.00s | 0m 0.02s | 0m 0.00s | 0m 0.00s | 0m 0.02s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.01s | 0m 0.09s | 0m 0.02s | 0m 0.02s | 0m 0.15s | 0m 0.02s | 0m 0.02s | 0m 0.01s |
+----------+----------+----------+----------+----------+----------+----------+----------+

На каждый формат по три "прогона" по пять забегов, в таблицу выбирался самый лучший результат (по среднему) у каждого формата. Подводя итоги можно увидеть, что PNG в среднем снимается в три-четыре раза медленее BMP, что примерно и ожидалось, учитывая его сильную компрессию без потерь. А вот JPEG показал себя очень неплохо, возможно для использования WebServer'а стоит расмотреть именно его, так как он обеспечивает неплохую скорость снятия скриншота и минимальный размер выводимого файла. Но это всё нужно тестировать на реальном устройстве, команды для прогона бенчмарков:

Код

for i in $(seq 1 5); do busybox time ./zgrab screenshot.bmp; sleep 1; rm screenshot.bmp; done;
for i in $(seq 1 5); do busybox time ./zgrab screenshot.png; sleep 1; rm screenshot.png; done;
for i in $(seq 1 5); do busybox time ./zgrab screenshot.jpeg; sleep 1; rm screenshot.jpeg; done;

Экзотические форматы рассматривать не имеет смысла, они наверняка не поддерживаются браузером. Самый медленный из них иксовый XPM, упаковка скриншота в остальные битмапные форматы работает примерно с одной и той же скоростью, несмотря на то что многие из них либо вообще чёрно-белые, либо используют только grayscale. Фаворитом является PPM, который примерно аналогичен BMP, но имеет ещё меньший и компактный заголовок.

Прикреплённые файлы:

[VINRARUS]

А вот JPEG показал себя очень неплохо, возможно для использования WebServer'а стоит расмотреть именно его, так как он обеспечивает неплохую скорость снятия скриншота и минимальный размер выводимого файла

...и минимальное качество.

Но это всё нужно тестировать на реальном устройстве, команды для прогона бенчмарков:

А табличку кто будет рисовать?

Код

# cd /tmp
# /home/zgrab.sh
+----------+----------+----------+
|   bmp    |   jpeg   |   png    |
+----------+----------+----------+
| 0m 0.43s | 0m 0.66s | 0m 2.10s |
| 0m 0.16s | 0m 0.36s | 0m 1.75s |
| 0m 0.06s | 0m 0.03s | 0m 0.05s |
+----------+----------+----------+
| 0m 0.48s | 0m 0.63s | 0m 2.06s |
| 0m 0.15s | 0m 0.32s | 0m 1.74s |
| 0m 0.07s | 0m 0.06s | 0m 0.08s |
+----------+----------+----------+
| 0m 0.45s | 0m 0.59s | 0m 2.07s |
| 0m 0.14s | 0m 0.31s | 0m 1.73s |
| 0m 0.05s | 0m 0.07s | 0m 0.07s |
+----------+----------+----------+
| 0m 0.47s | 0m 0.62s | 0m 2.08s |
| 0m 0.16s | 0m 0.31s | 0m 1.77s |
| 0m 0.06s | 0m 0.07s | 0m 0.04s |
+----------+----------+----------+
| 0m 0.44s | 0m 0.62s | 0m 2.06s |
| 0m 0.17s | 0m 0.34s | 0m 1.77s |
| 0m 0.06s | 0m 0.04s | 0m 0.05s |
+----------+----------+----------+

# cd /home  
# /home/zgrab.sh
+----------+----------+----------+
|   bmp    |   jpeg   |   png    |
+----------+----------+----------+
| 0m 1.89s | 0m 0.82s | 0m 2.43s |
| 0m 0.14s | 0m 0.36s | 0m 1.76s |
| 0m 0.29s | 0m 0.06s | 0m 0.08s |
+----------+----------+----------+
| 0m 1.75s | 0m 0.87s | 0m 2.55s |
| 0m 0.20s | 0m 0.36s | 0m 1.74s |
| 0m 0.23s | 0m 0.06s | 0m 0.14s |
+----------+----------+----------+
| 0m 2.09s | 0m 0.82s | 0m 2.44s |
| 0m 0.15s | 0m 0.38s | 0m 1.73s |
| 0m 0.23s | 0m 0.07s | 0m 0.11s |
+----------+----------+----------+
| 0m 1.76s | 0m 0.79s | 0m 2.53s |
| 0m 0.16s | 0m 0.32s | 0m 1.72s |
| 0m 0.24s | 0m 0.06s | 0m 0.09s |
+----------+----------+----------+
| 0m 1.39s | 0m 0.78s | 0m 2.51s |
| 0m 0.20s | 0m 0.31s | 0m 1.73s |
| 0m 0.17s | 0m 0.07s | 0m 0.09s |
+----------+----------+----------+

Для максимально жостких условий частота ЦП зафиксирована на 133 МГц.
А вот скоростя загрузки с браузера при 133 МГц:



Добавлено позже (21.11.2021, 23:25):
А вот при 740 МГц:

Код

# cd /tmp
# /home/zgrab.sh
+----------+----------+----------+
|   bmp    |   jpeg   |   png    |
+----------+----------+----------+
| 0m 0.13s | 0m 0.15s | 0m 0.45s |
| 0m 0.05s | 0m 0.08s | 0m 0.35s |
| 0m 0.01s | 0m 0.02s | 0m 0.03s |
+----------+----------+----------+
| 0m 0.13s | 0m 0.15s | 0m 0.44s |
| 0m 0.05s | 0m 0.07s | 0m 0.35s |
| 0m 0.00s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+
| 0m 0.13s | 0m 0.15s | 0m 0.44s |
| 0m 0.03s | 0m 0.06s | 0m 0.35s |
| 0m 0.02s | 0m 0.01s | 0m 0.00s |
+----------+----------+----------+
| 0m 0.13s | 0m 0.15s | 0m 0.44s |
| 0m 0.05s | 0m 0.06s | 0m 0.35s |
| 0m 0.00s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+
| 0m 0.13s | 0m 0.15s | 0m 0.45s |
| 0m 0.04s | 0m 0.06s | 0m 0.36s |
| 0m 0.01s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+

# cd /home
# /home/zgrab.sh
+----------+----------+----------+
|   bmp    |   jpeg   |   png    |
+----------+----------+----------+
| 0m 0.50s | 0m 0.17s | 0m 0.56s |
| 0m 0.02s | 0m 0.06s | 0m 0.36s |
| 0m 0.05s | 0m 0.00s | 0m 0.02s |
+----------+----------+----------+
| 0m 1.30s | 0m 0.20s | 0m 0.53s |
| 0m 0.05s | 0m 0.08s | 0m 0.36s |
| 0m 0.08s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+
| 0m 0.46s | 0m 0.20s | 0m 0.60s |
| 0m 0.02s | 0m 0.08s | 0m 0.36s |
| 0m 0.05s | 0m 0.00s | 0m 0.00s |
+----------+----------+----------+
| 0m 0.41s | 0m 0.20s | 0m 0.55s |
| 0m 0.05s | 0m 0.08s | 0m 0.36s |
| 0m 0.05s | 0m 0.00s | 0m 0.03s |
+----------+----------+----------+
| 0m 0.44s | 0m 0.20s | 0m 0.56s |
| 0m 0.03s | 0m 0.08s | 0m 0.35s |
| 0m 0.05s | 0m 0.00s | 0m 0.01s |
+----------+----------+----------+

Добавлено позже (21.11.2021, 23:28):
Для потокового слайдшоу действительно предпочтительнее jpeg, но, блин, качество...

[EXL]

Для потокового слайдшоу действительно предпочтительнее jpeg, но, блин, качество...

Может быть тогда сделать какую-нибудь опцию выбора между PNG и JPEG?

Тут вот ещё один вариант снятия скриншота сделал из одной моей программки, которая превращает CG41.smg и CG42.smg из разобранной прошивки в BMP'шки. Вот, fill.sa, получается этот код и пригодился. Используется чистый C, к сожалению в BMP нестандартный 18bpp не загонишь, а так было бы ещё быстрее:

Код

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>

#define RGB666_TO_RGB888(color) \
    ((((color) & (0x3F << 0)) <<  2) | (((color) & (0x3F <<  6)) << 4) | (((color) & (0x3F << 12)) <<  6))

typedef struct {
    int32_t width;
    int32_t height;
    uint32_t size;
    uint32_t depth;
} display_t;

/* See: https://en.wikipedia.org/wiki/BMP_file_format */
#pragma pack(push, 1)
typedef struct {
    /* Bitmap file header */
    uint16_t file_magic;
    uint32_t file_size;
    uint32_t bytes_reserved;
    uint32_t bitmap_start;
    /* DIB header (bitmap information header) */
    uint32_t dib_header_size;
    int32_t bitmap_width;
    int32_t bitmap_height;
    uint16_t color_planes;
    uint16_t bitmap_bpp;
    uint32_t compression_method;
    uint32_t bitmap_size;
    int32_t bitmap_width_ppm;
    int32_t bitmap_height_ppm;
    uint32_t num_of_colors;
    uint32_t num_of_important_colors;
} bmp_header_t;
#pragma pack(pop)

static int32_t ErrUsage(void) {
    fprintf(
        stderr,
        "Usage:\n"
        "\t./fbgrab <device> <BMP image file>\n\n"
        "Example:\n"
        "\t./fbgrab /dev/fb/0 screenshot.bmp\n"
    );
    return 1;
}

static int32_t ErrFile(const char *aFileName, const char *aMode) {
    fprintf(stderr, "Cannot open '%s' file for %s.\n", aFileName, aMode);
    return 1;
}

static uint32_t *CreateBitmapFromFile(FILE *aReadFile, const display_t *aDisplay) {
    int32_t y, x;
    uint32_t *lBitmapRgb888 = malloc(aDisplay->size * sizeof(uint32_t));
    for (y = 0; y < aDisplay->height; ++y)
        for (x = 0; x < aDisplay->width; ++x) {
            uint32_t lPixelRgb666 = 0x000000;
            fread(&lPixelRgb666, 3, 1, aReadFile); /* RGB666 in RGB888, 3 bytes, 18-bit or 24-bit for color. */
            lBitmapRgb888[x + y * aDisplay->width] = RGB666_TO_RGB888(lPixelRgb666);
        }
    return lBitmapRgb888;
}

static void WriteBmpHeader(FILE *aWriteFile, const display_t *aDisplay) {
    bmp_header_t lBmpHeader;
    memset(&lBmpHeader, 0, sizeof(bmp_header_t));
    lBmpHeader.file_magic = 0x4D42;
    lBmpHeader.file_size = aDisplay->size * 3 + 14 + 40; /* RGB888/24/3, BMP header, DIB header. */
    lBmpHeader.bitmap_start = 0x00000036;
    lBmpHeader.dib_header_size = 0x00000028;
    lBmpHeader.bitmap_width = aDisplay->width;
    lBmpHeader.bitmap_height = aDisplay->height;
    lBmpHeader.color_planes = 0x0001;
    lBmpHeader.bitmap_bpp = 0x0018;
    lBmpHeader.bitmap_size = aDisplay->size * 3; /* RGB888/24/3. */
    fwrite(&lBmpHeader, sizeof(bmp_header_t), 1, aWriteFile);
}

static void WriteBmpBitmap(FILE *aWriteFile, const display_t *aDisplay, const uint32_t *aBitmap) {
    int32_t y, x;
    for (y = aDisplay->height - 1; y >= 0; --y)
        for (x = 0; x < aDisplay->width; ++x) {
            uint32_t lPixelRgb888 = aBitmap[x + y * aDisplay->width];
            fwrite(&lPixelRgb888, 3, 1, aWriteFile);
        }
}

int main(int argc, char *argv[]) {
    if (argc != 3)
        return ErrUsage();

    display_t lScreen;
    lScreen.width = 240;
    lScreen.height = 320;
    lScreen.size = lScreen.height * lScreen.width;
    lScreen.depth = 24;

    FILE *lSmgFile = fopen(argv[1], "rb");
    if (!lSmgFile)
        return ErrFile(argv[1], "read");
    uint32_t *lBitmap = CreateBitmapFromFile(lSmgFile, &lScreen);
    fclose(lSmgFile);

    FILE *lBmpFile = fopen(argv[2], "wb");
    if (!lBmpFile)
        return ErrFile(argv[2], "write");
    WriteBmpHeader(lBmpFile, &lScreen);
    WriteBmpBitmap(lBmpFile, &lScreen, lBitmap);
    free(lBitmap);
    fclose(lBmpFile);

    return 0;
}

Компилировать так:

Код

# Motorola ZN5
/arm-eabi/bin/arm-linux-gnueabi-gcc -pipe -Wall -W -O2 fbgrab.c -o fbgrab
/arm-eabi/bin/arm-linux-gnueabi-strip -s fbgrab

# MotoMAGX Emulator
/opt/toolchains/motomagx/emulator/bin/i686-mot-linux-gnu-gcc -pipe -Wall -W -O2 fbgrab.c -o fbgrab
/opt/toolchains/motomagx/emulator/bin/i686-mot-linux-gnu-strip -s fbgrab

Запускать так:

Код

./fbgrab /dev/fb/0 screenshot.bmp
./fbgrab /dev/fb/1 screenshot.bmp

По бенчмарку похоже этот способ чуть быстрее варианта с Qt из поста выше:

Код

# for i in $(seq 1 5); do busybox time ./fbgrab /dev/fb/0 screenshot.bmp; sleep 1; rm screenshot.bmp; done;
real    0m 0.02s
user    0m 0.00s
sys     0m 0.00s

real    0m 0.02s
user    0m 0.00s
sys     0m 0.01s

real    0m 0.00s
user    0m 0.00s
sys     0m 0.00s

real    0m 0.03s
user    0m 0.00s
sys     0m 0.01s

real    0m 0.02s
user    0m 0.00s
sys     0m 0.00s

Мне ещё вот что интересно. Будет ли захват картинки, если выполнять ./fbgrab /dev/fb/1 screenshot.bmp во время работы видоискателя камеры или же во время запуска какой-нибудь игры, которая использует аппаратно ускоренную SDL-библиотеку? Или всё равно будет чёрный экран? В эмуляторе к сожалению IPU похоже что не работает. Проверьте ради интереса, так ли это. В ядре, в файле mxcfb.h устройства описываются следующим образом:

Код

#define MXCFB_MAIN_DEVICE       "/dev/fb/0"
#define MXCFB_OVERLAY_DEVICE    "/dev/fb/1"
#define MXCFB_CLI_DEVICE        "/dev/fb/2"

По идее OVERLAY и есть вот этот вот IPU-буфер, а CLI это изображение с внешнего дисплея различных раскладушек вроде U9, VA76r и др.

Прикреплённые файлы:

[VINRARUS]

Может быть тогда сделать какую-нибудь опцию выбора между PNG и JPEG?

PNG не вариант, сильно медленно. Уровень зжатия жопега не регулируется там?

Или всё равно будет чёрный экран?

Оно везде чорный картинко выводит.

[EXL]

PNG не вариант, сильно медленно. Уровень зжатия жопега не регулируется там?

Да, регулируется в диапазоне от 0-100, пробуй:

Код

// zgrab.cpp
#include <qapplication.h>
#include <qpixmap.h>
#include <qwidget.h>

#include <stdio.h>

#define SCR_WIDTH  240
#define SCR_HEIGHT 320

int main(int argc, char *argv[]) {
    if (argc >= 2 && argc <= 3) {
        QApplication app(argc, argv);
        QWidget fullScreenWidget(0);
        fullScreenWidget.setFocusPolicy(QWidget::NoFocus);
        fullScreenWidget.setBackgroundMode(QWidget::NoBackground);
        fullScreenWidget.setFixedSize(SCR_WIDTH, SCR_HEIGHT);
        fullScreenWidget.show();
        QPixmap fullScreenPixmap(SCR_WIDTH, SCR_HEIGHT, -1, QPixmap::BestOptim);
        bitBlt(&fullScreenPixmap, 0, 0, &fullScreenWidget, 0, 0, SCR_WIDTH, SCR_HEIGHT, Qt::CopyROP, true);
        if (argc == 2)
            fullScreenPixmap.save(argv[1], QStringList::split(".", argv[1])[1].upper());
        else
            fullScreenPixmap.save(argv[1], QStringList::split(".", argv[1])[1].upper(), QString(argv[2]).toInt());
    } else
        fprintf(
            stderr,
            "Usage:\n"
            "\tzgrab screenshot.<format>\n\n"
            "Example:\n"
            "\tzgrab screenshot.png\n"
            "\tzgrab screenshot.bmp\n"
            "\tzgrab screenshot.jpeg 100\n"
            "\tzgrab screenshot.jpeg 25\n"
        );
    return 0;
}

Бенчмарк на эмуляторе не показывает существенных понижений в скорости на разном качестве JPEG:

Код

+----------+----------+----------+----------+----------+
| JPEG  25 | JPEG  50 | JPEG  65 | JPEG  85 | JPEG 100 |
+----------+----------+----------+----------+----------+
| 0m 0.07s | 0m 0.06s | 0m 0.07s | 0m 0.07s | 0m 0.06s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.02s |
| 0m 0.00s | 0m 0.00s | 0m 0.03s | 0m 0.02s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.03s | 0m 0.07s | 0m 0.07s | 0m 0.06s | 0m 0.07s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.02s | 0m 0.04s |
+----------+----------+----------+----------+----------+
| 0m 0.08s | 0m 0.06s | 0m 0.06s | 0m 0.05s | 0m 0.07s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.06s | 0m 0.05s | 0m 0.06s | 0m 0.07s | 0m 0.07s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.06s | 0m 0.07s | 0m 0.07s | 0m 0.07s | 0m 0.07s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
| 0m 0.02s | 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.00s |
+----------+----------+----------+----------+----------+

При этом качество картинки на разных уровнях JPEG-компрессии следующее (от 25 к 100 слева направо, в конце PNG для сравнения):





При сравнении обратите внимание на бордовые круги ниже иконки браузера.

Оно везде чорный картинко выводит. not_i.gif

Даже при ./fbgrab /dev/fb/0 screenshot.bmp что ли? Такого быть не должно.

Прикреплённые файлы:

[VINRARUS]

Даже при ./fbgrab /dev/fb/0 screenshot.bmp что ли? Такого быть не должно.

Робочий стол:

screenshot.bmp   ( 225.05 килобайт ) Кол-во скачиваний: 12

ПС: на улице был туман.

[fill.sa]

Я так понимаю от хваленого бмп отказались.
По моей памяти перевод иконореса с бмп на пнг заметно ускорил работу. Замеров я не делал, сугобо субьективное мнение.
Да и по замеру винраруса страничка на пнг знатно быстрее грузится ибо в пнг меньше даннвх загружать нужно.

[VINRARUS]

Я так понимаю от хваленого бмп отказались.

Нет. Качество и скорость создания bmp неоспоримы!

По моей памяти перевод иконореса с бмп на пнг заметно ускорил работу.

Наоборот, по крайней мере на Z6.

Да и по замеру винраруса страничка на пнг знатно быстрее грузится ибо в пнг меньше даннвх загружать нужно.

Так всем понятно шо чем меньше файл тем быстрее его передача.
Но для начала же его сгенерировать нада, и тут PNG с треском отстаёт в сумарном времени получения скриншота.
Для кого мы тут псевдотаблички заполняли?
BMP: 0.681/0.256
JPG: 0.665/0.166
PNG: 2.131/0.484

[fill.sa]

Но для начала же его сгенерировать нада, и тут PNG с треском отстаёт в сумарном времени получения скриншота.
Для кого мы тут псевдотаблички заполняли?
BMP: 0.681/0.256
JPG: 0.665/0.166
PNG: 2.131/0.484

Так понятно что на сжатие какое-то время тратится. Но это по мне мелочи.
Ты на конечный результат смотри, особенно в действительностях магикса.
Да и по открытию веб страници ты сам видешь что на пнг ты успееш 5 картинок открыть пока 1 бмп прогрузится. Вот и вся твоя скорость.

Я могу ехать 200Км/ч и останавливаться кажные 10 км на заправку и охладится.
А кто-то будет ехать 100км/ч и в конечном счете мы одинаково приедем.

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

[VINRARUS]

Ты на конечный результат смотри, особенно в действительностях магикса.

Цыфры в цытате и есть конечный результат.
Если не можеш сам их итерпретировать — я помогу:
2.131÷0.681=в 3,13 раз скриншот BMP быстрее в браузере появится чем PNG, при Wi-FI подключении и мин. частоте ЦП (при 740 МГц разница уменьшается до 2х раз).

Я же говорю по ощущениям иконрез на пнг заметно быстрее, к сожалению проверить это никак, только по ощущениям. Ибо проверить можно только отдельные вещи в виде скорости генерации картинки, но не как не замерить весь процесс.

По моим ощущениям bmp скин шустрее, но уменя не тормозина — на тормозине экономия RAM решает.

[EXL]

VINRARUS, Очень странно, ведь на эмуляторе всё работает.
А если так сделать, будет эффект?

Код

cat /dev/fb/0 > screen.dump
./fbgrab screen.dump screen.bmp

Если нет, прицепи screen.dump для изучения.

[VINRARUS]

Если нет, прицепи screen.dump для изучения.

Изучай.

Добавлено позже (24.11.2021, 2:03):
EXL, кстати zgrab при срабатывании закрывает всплывающие менюшки и нажатия кнопок подтупливают.

[EXL]

EXL, кстати zgrab при срабатывании закрывает всплывающие менюшки и нажатия кнопок подтупливают.

Я нашёл ещё один способ захвата картинки с экрана через Qt, без хитрости в виде создания какого-либо виджета поверх. Возможно сейчас менюшки закрываться не будут, а сама скриншотилка будет отрабатывать ещё быстрее. У меня на эмуляторе работает, проверь на реальном девайсе:

Код

// dgrab.cpp
#include <qapplication.h>
#include <qpixmap.h>
#include <qwidget.h>

#include <stdio.h>

int main(int argc, char *argv[]) {
    if (argc >= 2 && argc <= 3) {
        QApplication app(argc, argv);
        QPixmap::setDefaultOptimization(QPixmap::BestOptim);
        QPixmap fullScreenPixmap = QPixmap::grabWindow(QApplication::desktop()->winId());
        if (argc == 2)
            fullScreenPixmap.save(argv[1], QStringList::split(".", argv[1])[1].upper());
        else
            fullScreenPixmap.save(argv[1], QStringList::split(".", argv[1])[1].upper(), QString(argv[2]).toInt());
    } else
        fprintf(
            stderr,
            "Usage:\n"
            "\tdgrab screenshot.<format>\n\n"
            "Example:\n"
            "\tdgrab screenshot.png\n"
            "\tdgrab screenshot.bmp\n"
            "\tdgrab screenshot.jpeg 100\n"
            "\tdgrab screenshot.jpeg 25\n"
        );
    return 0;
}

Собирать так:

Код

# Motorola ZN5
/arm-eabi/bin/arm-linux-gnueabi-g++ -pipe -DQWS -fno-exceptions -fno-rtti -Wall -W -O2 -I/arm-eabi/lib/qt-zn5/include -I/arm-eabi/lib/ezx-zn5/include -I/arm-eabi/arm-linux-gnueabi/include dgrab.cpp -o dgrab -Wl,-rpath-link,/arm-eabi/lib/ezx-zn5/lib -L/arm-eabi/lib/ezx-zn5/lib -lqte-mt
/arm-eabi/bin/arm-linux-gnueabi-strip -s dgrab

# MotoMAGX Emulator
/opt/toolchains/motomagx/emulator/bin/i686-mot-linux-gnu-g++ -pipe -DQWS -fno-exceptions -fno-rtti -Wall -W -O2 -I/opt/toolchains/motomagx/emulator/include dgrab.cpp -o dgrab -L/opt/toolchains/motomagx/emulator/lib -lqte-mt
/opt/toolchains/motomagx/emulator/bin/i686-mot-linux-gnu-strip -s dgrab

Запускать аналогично zgrab, а вот с fbgrab пока не разбирался. Вижу по размеру файла дампа, что чтение не происходит, что странно. Может быть из-за прав такое...? На root, а не ezx запускать пробовал? Нужно разбираться.

Прикреплённые файлы:

[VINRARUS]

Возможно сейчас менюшки закрываться не будут, а сама скриншотилка будет отрабатывать ещё быстрее. У меня на эмуляторе работает, проверь на реальном девайсе:

Да, так намного лучше!

На root, а не ezx запускать пробовал?

Ну я ж не убунтьоныш, шобы рута бояться. В телнете сразу рут права все.

Сообщение отредактировал VINRARUS - 25.11.2021, 4:54

[EXL]

VINRARUS,
В общем собрал все исходники утилит для снятия скриншотов на GitHub: https://github.com/EXL/MagxScreenshot/

Ну я ж не убунтьоныш, шобы рута бояться. laugh.gif В телнете сразу рут права все.

Наверное пофиксил, но так и не понял в чём там дело и почему fread() и fopen() не работают, а mmap() и open() работают нормально. Правда фиг его знает как это скажется на производительности.

Добавил ещё jgrab, которая делает JPEG-скриншоты, пробуй:

Код

./fbgrab /dev/fb/0 screenshot.bmp
./jgrab /dev/fb/0 screenshot.jpg 100

Теперь "/dev/fb/0" должен нормально сниматься, а ещё можешь на "/dev/fb/1" при врубленной камере или запущенном на SDL HW приложении проверить, есть ли там чего или всё так же чёрный экран.

Прикреплённые файлы:

[VINRARUS]

EXL, вот теперь шыкарно!
Новые fbgrab и jgrab:

Код

# cd /tmp
# echo 133 > /sys/mpm/op
# /home/zgrab.sh
+----------+----------+----------+----------+----------+
|   bmp    |  jpg10   |  jpg50   |  jpg90   |  jpg100  |
+----------+----------+----------+----------+----------+
| 0m 0.25s | 0m 0.20s | 0m 0.24s | 0m 0.22s | 0m 0.28s |
| 0m 0.19s | 0m 0.18s | 0m 0.18s | 0m 0.22s | 0m 0.23s |
| 0m 0.02s | 0m 0.02s | 0m 0.03s | 0m 0.01s | 0m 0.04s |
+----------+----------+----------+----------+----------+
| 0m 0.20s | 0m 0.22s | 0m 0.21s | 0m 0.25s | 0m 0.27s |
| 0m 0.19s | 0m 0.19s | 0m 0.19s | 0m 0.23s | 0m 0.27s |
| 0m 0.01s | 0m 0.01s | 0m 0.02s | 0m 0.01s | 0m 0.00s |
+----------+----------+----------+----------+----------+
| 0m 0.20s | 0m 0.23s | 0m 0.20s | 0m 0.28s | 0m 0.30s |
| 0m 0.18s | 0m 0.20s | 0m 0.20s | 0m 0.23s | 0m 0.26s |
| 0m 0.02s | 0m 0.01s | 0m 0.01s | 0m 0.00s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.23s | 0m 0.20s | 0m 0.23s | 0m 0.23s | 0m 0.28s |
| 0m 0.20s | 0m 0.19s | 0m 0.21s | 0m 0.21s | 0m 0.27s |
| 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.02s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.22s | 0m 0.19s | 0m 0.26s | 0m 0.25s | 0m 0.30s |
| 0m 0.19s | 0m 0.19s | 0m 0.21s | 0m 0.22s | 0m 0.27s |
| 0m 0.02s | 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+----------+----------+

# echo 740 > /sys/mpm/op
# /home/zgrab.sh
+----------+----------+----------+----------+----------+
|   bmp    |  jpg10   |  jpg50   |  jpg90   |  jpg100  |
+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.04s | 0m 0.04s | 0m 0.05s | 0m 0.05s |
| 0m 0.04s | 0m 0.05s | 0m 0.05s | 0m 0.04s | 0m 0.05s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.04s | 0m 0.04s | 0m 0.05s | 0m 0.06s |
| 0m 0.03s | 0m 0.04s | 0m 0.04s | 0m 0.05s | 0m 0.06s |
| 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.04s | 0m 0.05s | 0m 0.05s | 0m 0.06s |
| 0m 0.04s | 0m 0.03s | 0m 0.04s | 0m 0.05s | 0m 0.05s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.05s | 0m 0.04s | 0m 0.05s | 0m 0.05s |
| 0m 0.04s | 0m 0.05s | 0m 0.04s | 0m 0.05s | 0m 0.05s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s |
+----------+----------+----------+----------+----------+
| 0m 0.04s | 0m 0.04s | 0m 0.04s | 0m 0.05s | 0m 0.07s |
| 0m 0.03s | 0m 0.04s | 0m 0.04s | 0m 0.05s | 0m 0.06s |
| 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s |
+----------+----------+----------+----------+----------+

а ещё можешь на "/dev/fb/1" при врубленной камере

Работает в камере!
К стати, при закрытии камеры на /dev/fb/1 остаётся останний кадр висеть.

[EXL]

VINRARUS, Отлично, что для камеры тоже заработало. А для игр на SDL HW это тоже работает? Там наверное должен этот же буфер использоваться. Проверь ради интереса.

Немного оптимизировал код в jgrab, обнови у себя нужные исполняемые файлы. Ещё добавил утилиту pgrab по типу fbgrab и jgrab, но для снятия скриншотов в PNG, уровень компрессии регулируется в пределах 0-9:

Код

./pgrab /dev/fb/0 screenshot1.png 0
./pgrab /dev/fb/0 screenshot2.png 2
./pgrab /dev/fb/0 screenshot3.png 9

Бенчмарк на эмуляторе показал следующую картину, в самом конце размер файла в байтах:

Код

for i in $(seq 1 5); do busybox time ./pgrab /dev/fb/0 scr.png 9; sleep 1; rm scr.png; done;

+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
|  PNG 0   |  PNG 1   |  PNG 2   |  PNG 3   |  PNG 4   |  PNG 5   |  PNG 6   |  PNG 7   |  PNG 8   |  PNG 9   |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.02s | 0m 0.06s | 0m 0.05s | 0m 0.07s | 0m 0.09s | 0m 0.08s | 0m 0.12s | 0m 0.14s | 0m 0.27s | 0m 0.50s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.01s | 0m 0.02s | 0m 0.04s | 0m 0.03s | 0m 0.03s |
| 0m 0.00s | 0m 0.04s | 0m 0.02s | 0m 0.03s | 0m 0.06s | 0m 0.06s | 0m 0.09s | 0m 0.08s | 0m 0.22s | 0m 0.43s |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.07s | 0m 0.04s | 0m 0.06s | 0m 0.06s | 0m 0.07s | 0m 0.09s | 0m 0.12s | 0m 0.15s | 0m 0.31s | 0m 0.43s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.01s | 0m 0.00s | 0m 0.04s |
| 0m 0.06s | 0m 0.00s | 0m 0.05s | 0m 0.04s | 0m 0.02s | 0m 0.09s | 0m 0.09s | 0m 0.12s | 0m 0.29s | 0m 0.35s |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.05s | 0m 0.08s | 0m 0.04s | 0m 0.09s | 0m 0.10s | 0m 0.10s | 0m 0.13s | 0m 0.14s | 0m 0.34s | 0m 0.50s |
| 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.01s | 0m 0.02s | 0m 0.00s | 0m 0.02s | 0m 0.00s | 0m 0.08s |
| 0m 0.05s | 0m 0.06s | 0m 0.02s | 0m 0.06s | 0m 0.07s | 0m 0.08s | 0m 0.11s | 0m 0.11s | 0m 0.31s | 0m 0.40s |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.03s | 0m 0.07s | 0m 0.08s | 0m 0.09s | 0m 0.09s | 0m 0.09s | 0m 0.12s | 0m 0.10s | 0m 0.33s | 0m 0.52s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.02s | 0m 0.06s | 0m 0.02s |
| 0m 0.03s | 0m 0.05s | 0m 0.06s | 0m 0.07s | 0m 0.06s | 0m 0.09s | 0m 0.11s | 0m 0.07s | 0m 0.24s | 0m 0.46s |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
| 0m 0.03s | 0m 0.06s | 0m 0.08s | 0m 0.08s | 0m 0.10s | 0m 0.11s | 0m 0.12s | 0m 0.14s | 0m 0.32s | 0m 0.49s |
| 0m 0.00s | 0m 0.01s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.00s | 0m 0.07s | 0m 0.03s |
| 0m 0.02s | 0m 0.04s | 0m 0.07s | 0m 0.07s | 0m 0.09s | 0m 0.10s | 0m 0.11s | 0m 0.13s | 0m 0.22s | 0m 0.41s |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+
|  231154  |  68689   |  66579   |  63552   |  60778   |  59231   |  58129   |  57665   |  56473   |  56033   |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+----------+

Как видно, время снятия скриншота с повышением уровня компрессии возрастает, но не особо быстро. Исключения последние два уровня 8 и 9. Даже минимальный уровень сжатия 1 неплохо жмёт картинку и при этом не особо прожорлив. Возможно следует попробовать заюзать его вместо JPEG, но нужно смотреть как оно на реальном устройстве будет сжиматься, там разница может быть более драматическая.

Если будешь в Web-сервер встраивать всё это, не забудь сделать снятие скриншота именно в PNG-формате, например, по отдельной кнопке. Сделать именно lossless скриншот бывает очень полезно.

Прикреплённые файлы:

[Unreal_man]

Пнг скриншоты на телефоне это зло, у нас просмотрщик кривой по части открытия пнг. Лучше джипег.

[VINRARUS]

Unreal_man, а оно не для просмотра на телефоне в даном случае.



Добавлено позже (26.11.2021, 20:21):
... если конешно мова не про управление зиной чирез другую зину.

[EXL]

VINRARUS, Ага, это удобно для публикации постов со скриншотами на форум в первую очередь

[VINRARUS]

Ещё добавил утилиту pgrab по типу fbgrab и jgrab, но для снятия скриншотов в PNG, уровень компрессии регулируется в пределах 0-9

А шо у неё с размером случилось, шо в 10 раз больше чем другие?

[EXL]

VINRARUS,
Причина этого как всегда обрезанная Qt-библиотека у ZN5. Например её сравнение с той, что у VE66 по части PNG-функций:

Код

$ cd /arm-eabi/lib/ezx-zn5/lib/
$ readelf -s -w libqte-mt.so.2.3.8 | grep -i png_ | c++filt
readelf: libqte-mt.so.2.3.8: warning: local symbol 465 found at index >= .dynsym's sh_info value of 10
   236: 416c6870    92 func    global default   11 png_error@@version
   520: 416cadf4    16 func    global default   11 png_set_strip_16@@version
   624: 416c5d90   144 func    global default   11 png_sig_cmp@@version
   656: 416c8fd0   620 func    global default   11 png_create_read_struct@@version
  1032: 416cabb0   136 func    global default   11 png_set_read_fn@@version
  1066: 416d4f58    32 func    global default   11 png_set_packing@@version
  1155: 416c64b0     8 func    global default   11 png_get_io_ptr@@version
  1726: 416c6914    28 func    global default   11 png_get_valid@@version
  2400: 416c71e0    72 func    global default   11 png_get_plte@@version
  2631: 416c6f1c   260 func    global default   11 png_get_ihdr@@version
  3005: 416c941c  1620 func    global default   11 png_read_info@@version
  3207: 416ca840   192 func    global default   11 png_destroy_read_struct@@version
  3329: 416c9ff8   100 func    global default   11 png_read_image@@version
  3386: 416c72e4   132 func    global default   11 png_get_trns@@version
  3439: 416c5f14    56 func    global default   11 png_create_info_struct@@version
  3962: 416c68fc    16 func    global default   11 png_set_error_fn@@version
  3989: 416ca05c  1360 func    global default   11 png_read_end@@version

$ cd /arm-eabi/lib/ezx-ve66/lib/
$ readelf -s -w libqte-mt.so.2.3.8 | grep -i png_write_ | c++filt
   153: 41791a68    72 func    global default   10 png_write_gama_fixed
   585: 41792898   288 func    global default   10 png_write_iccp
   668: 41791ab0    96 func    global default   10 png_write_srgb
   989: 41792e34   252 func    global default   10 png_write_scal
  1207: 417914c8   960 func    global default   10 png_write_ihdr
  1258: 417929b8   220 func    global default   10 png_write_text
  1655: 41790f18    52 func    global default   10 png_write_chunk_end
  1660: 41791c04   920 func    global default   10 png_write_chrm
  2162: 41791f9c   496 func    global default   10 png_write_chrm_fixed
  2316: 417930a8   480 func    global default   10 png_write_start_row
  2532: 41792a94   292 func    global default   10 png_write_ztxt
  2536: 41791888   224 func    global default   10 png_write_plte
  2616: 4178fb10   292 func    global default   10 png_write_init_2
  2940: 41792298   228 func    global default   10 png_write_bkgd
  3095: 41791b10   244 func    global default   10 png_write_sbit
  3435: 417937a8   252 func    global default   10 png_write_filtered_row
  3960: 417926dc   444 func    global default   10 png_write_splt
  3999: 417938a4  3276 func    global default   10 png_write_find_filter
  4089: 4178fee8    64 func    global default   10 png_write_rows
  5437: 4178eea0   528 func    global default   10 png_write_info_before_plte
  5642: 4178fc64   540 func    global default   10 png_write_row
  5908: 4178f0b0   908 func    global default   10 png_write_info
  5991: 41791968    76 func    global default   10 png_write_idat
  6799: 41790f4c    52 func    global default   10 png_write_chunk_data
  6909: 41792fe0   200 func    global default   10 png_write_time
  6918: 41790fe0    52 func    global default   10 png_write_chunk
  7050: 41790f80    96 func    global default   10 png_write_chunk_start
  7089: 4179237c   172 func    global default   10 png_write_hist
  7120: 41793288   576 func    global default   10 png_write_finish_row
  7240: 417919b4    68 func    global default   10 png_write_iend
  7328: 4178f43c   452 func    global default   10 png_write_end
  7340: 41790538   284 func    global default   10 png_write_png
  7709: 41792c68   460 func    global default   10 png_write_pcal
  8256: 41792bb8   176 func    global default   10 png_write_offs
  8510: 417919f8   112 func    global default   10 png_write_gama
  8660: 41790014   260 func    global default   10 png_write_destroy
  9198: 4178fe80   104 func    global default   10 png_write_image
  9890: 4178ff38   220 func    global default   10 png_write_flush
  9954: 41792f30   176 func    global default   10 png_write_phys
10183: 41791014   144 func    global default   10 png_write_sig
10542: 4179218c   268 func    global default   10 png_write_trns
10910: 4178fc34    48 func    global default   10 png_write_init
10947: 4178ed38    60 func    global default   10 png_write_data

Как видно, у ZN5 библиотека Qt может только читать PNG изображения. Не знаю где там в прошивке ZN5 код сохранения PNG-изображений, возможно в самой либе Qt собственная внутренняя приватная реализация этой функциональности, поэтому приходится этот код таскать с собой и линковать его статически. Что, конечно, увеличивает размер исполняемого файла на десятки килобайт.

Поищи, есть ли libpng.so где-нибудь в /lib, например?

[VINRARUS]

Не знаю где там в прошивке ZN5 код сохранения PNG-изображений

А может его и нет, ведь сохранять в png это так не по американски...

Поищи, есть ли libpng.so где-нибудь в /lib, например?

Нету.

[EXL]

А может его и нет, ведь сохранять в png это так не по американски... no2.gif

Хех, но Qt ведь как-то сохраняет PNG через тот же dgrab и zgrab?!

А это значит что где-то всё-таки нужный код есть, но только он хорошо прикопан. Либо вообще какая-то внутренняя реализация в Qt мимо libpng. И кстати эта либа примерно так же статически вкомпилена в libqte-mt.so.2 разных телефонов. Просто в случае с ZN5 в каком-то обрезанном варианте.

[VINRARUS]

А для игр на SDL HW это тоже работает? Там наверное должен этот же буфер использоваться. Проверь ради интереса.

на /dev/fb/1 висит последний кадр камеры
А на /dev/fb/0 такие картинки:

[EXL]

VINRARUS, Понял, спасибо за тесты.

А на /dev/fb/0 такие картинки:

Примерно понял почему. Там в SDL видимо переводится видео режим с 18 bpp на 16 bpp или какой-то другой, поэтому такие вот артефакты. Может быть когда-нибудь сделаю снятие картинки в режиме 16 bpp, но пока руки до этого не доходят.

Кстати, вот отличия в качестве картинки на 16-bit'ах (RGB565) и 18-bit'ах (RGB666). Лично я эту разницу немного вижу.