opentoonz-1.8.0-alt2 Стенды (обновлённые до Sisyphus): Alt Education kde/xfce 11.2 Alt Workstation 11.2 Alt Workstation K 11.4 Шаги для воспроизведения: 1) # apt-get install opentoonz 2) $ opentoonz 3) Подключить веб-камеру к машине 4) Сканирование и очистка -> Тестирование камеры -> затем перейти в "Захват камеры" Ожидаемый результат: Камера доступна Реальный результат: Камера недоступна
Created attachment 22372 [details] видео Прикрепляю видео
Подскажите пожалуйста, а если так запустить, будет работать? Exec=env QT_QPA_PLATFORM=xcb opentoonz
Сейчас заметил что камера стала доступна, ВМ простаивала минут 30, в какой-то момент из этого промежутка пошла картинка с вебки. Запуск вида "Exec=env QT_QPA_PLATFORM=xcb opentoonz" проблему не решает.
Посмотрел исходники захвата камеры в версии 1.8 для x86_64. Перечень устройств берётся через Qt, а захват выполняется OpenCV. На Linux выбранный номер в списке передаётся OpenCV без привязки к deviceName(); эти номера не обязаны совпадать. Также обнаружены остановка захвата при повторном выборе той же камеры и выбор неподтверждённого максимального разрешения при пустом списке разрешений Qt. Это отдельные дефекты/риски в коде, но пока не доказанная причина данного отчёта, особенно самопроизвольного появления изображения после простоя. Для диагностики без доступа к вашей камере просьба собрать следующие сведения. Можно начать с одного стенда, где проблема стабильно наблюдается; для остальных достаточно отметить отличия. Проверку xcb, которая уже не помогла, повторять не нужно. 1. Окружение и подключение - Точная модель камеры, USB VID:PID (lsusb). - Название и версия гипервизора, ОС хоста; камера проброшена как USB-устройство или как виртуальная камера? Какой USB-контроллер используется в ВМ (2.0/3.0)? - Камера встроенная или внешняя; есть ли другие камеры/виртуальные видеоустройства? - Проблема есть на физической машине или только в ВМ? Если физическая машина недоступна, достаточно это указать. - Вывод в гостевой системе: cat /etc/os-release uname -a printf 'session=%s desktop=%s\n' "$XDG_SESSION_TYPE" "$XDG_CURRENT_DESKTOP" rpm -qa | grep -Ei 'opentoonz|opencv|qt5.*(multimedia|wayland)|gstreamer|gst-plugins|v4l' id 2. Какие устройства доступны именно в момент неисправности В гостевой системе от обычного пользователя, запускающего OpenToonz: lsusb ls -l /dev/video* v4l2-ctl --list-devices fuser -v /dev/video* v4l2-ctl входит в v4l-utils. Если команды отсутствуют, сообщите это либо установите соответствующие диагностические утилиты. Для каждого /dev/videoN, относящегося к этой камере (N заменить фактическим номером): v4l2-ctl -d /dev/videoN --all v4l2-ctl -d /dev/videoN --list-formats-ext udevadm info --query=property --name=/dev/videoN Часть узлов может быть для метаданных и не поддерживать захват — их ошибки тоже полезны. Если после ожидания картинка появится, повторите список устройств, ls -l и fuser: важно понять, изменились ли номера устройств или освободилась камера. 3. Точный симптом и настройки OpenToonz - Камера отсутствует в выпадающем списке или присутствует, но изображение пустое/чёрное/замершее? Какой текст ошибки виден? - Скриншот всего окна «Захват камеры»: выбранное устройство, разрешение, состояние переключателя «Use MJPG with Webcam». - Список предлагаемых разрешений. - Остаётся ли интерфейс отзывчивым во время ожидания? - Появилась ли картинка сама, без действий, или перед этим были переключение камеры/разрешения, открытие окна, переподключение USB? По возможности замерьте время от открытия окна до первого кадра. 4. Логи запуска Полностью завершить OpenToonz, затем запустить от обычного пользователя: env OPENCV_VIDEOIO_DEBUG=1 OPENCV_LOG_LEVEL=DEBUG QT_LOGGING_RULES='qt.multimedia.*=true' opentoonz > opentoonz-camera.log 2>&1 Воспроизвести проблему, записать время открытия «Захвата камеры» и, если дождались, время появления изображения. Завершить приложение и приложить лог файлом. Лог может быстро расти из-за повторяющихся ошибок; достаточно 1–2 минут неисправного состояния, ждать 30 минут с отладкой необязательно. Также нужны сообщения ядра гостя за период подключения/отказа/начала работы камеры: journalctl -k -b --since "YYYY-MM-DD HH:MM:SS" --until "YYYY-MM-DD HH:MM:SS" Подставить фактический интервал; при нехватке прав выполнить от root. Особенно важны сообщения USB, uvcvideo, video4linux, таймауты и отключения устройства. Если гипервизор сообщает ошибки USB-проброса, приложить относящийся к камере фрагмент его журнала. 5. Проверки по одной, с записью результата Перед каждым независимым опытом завершать OpenToonz и приложения, использующие камеру; не менять несколько условий одновременно: а) Подключить камеру до запуска OpenToonz, открыть сразу «Захват камеры», без «Тестирования камеры». б) Подключить после запуска, нажать обновление списка камер и выбрать устройство. в) Выбрать 640×480, если оно поддерживается по выводу v4l2-ctl, сохранив прежнее состояние MJPG. г) Отдельно проверить включённый и выключенный «Use MJPG with Webcam» на одном поддерживаемом разрешении. д) При работающем захвате повторно выбрать ту же камеру: прекращается ли изображение? Восстанавливается ли после выбора «- Select camera -» и повторного выбора камеры либо смены разрешения? е) После неудачного подключения помогают ли закрытие/открытие окна, полный перезапуск приложения или USB-переподключение? Проверить отдельно. ж) Проверить камеру в другом приложении внутри той же ВМ. Указать приложение и результат, затем полностью его закрыть перед OpenToonz. Если возможно, отдельно проверить на хосте, предварительно освободив камеру от ВМ; не использовать одновременно на хосте и в госте. 6. Независимая проверка V4L2 (если возможно) При закрытых OpenToonz и других клиентах камеры, от того же обычного пользователя, для capture-узла: timeout 20s v4l2-ctl -d /dev/videoN --stream-mmap --stream-count=30 --stream-to=/dev/null echo "exit=$?" Приложить вывод, в том числе ошибки/таймаут. Команда использует текущий формат: приложите --all перед тестом. Она не сохраняет изображение; код 124 означает, что сработало ограничение времени. Это поможет отделить неисправность захвата/проброса от выбора устройства и настроек внутри OpenToonz. Не нужны пароли, полный дамп окружения, приватные проекты или запись изображения с камеры. Перед публикацией журналов удалите серийные номера, личные пути и другие чувствительные данные, сохранив модель, VID:PID, номера /dev/videoN, форматы и временные метки. Если какой-то пункт выполнить нельзя, просто отметьте это.
Created attachment 22752 [details] архив с вложениями Кратко о стенде: ALT Workstation K 11.4 (Sisyphus), ВМ в Proxmox, камера проброшена с ноутбука по SPICE. opentoonz-1.8.0-alt3. Сессия: Wayland, KDE. ------------------------------------------------------------------ 1. Окружение и подключение ------------------------------------------------------------------ > - Точная модель камеры, USB VID:PID (lsusb). Модель: HP FHD Camera (Quanta Computer) VID:PID: 0408:546d В ВМ: Bus 002, Port 004, драйвер uvcvideo (If 0, If 1), скорость 480M. If 2 (Application Specific Interface) без драйвера. > - Название и версия гипервизора, ОС хоста; камера проброшена как > USB-устройство или как виртуальная камера? Какой USB-контроллер > используется в ВМ (2.0/3.0)? Гипервизор: Proxmox VE 9.2.5 (pve-manager 9.2.5-alt5), QEMU 10.2.2 (pve-qemu-system 1:10.2.2-alt1), ускорение KVM включено. SPICE на стороне сервера: libspice-server 0.15.2-alt3. Данные DMI из ВМ: sys_vendor = QEMU product_name = Standard PC (i440FX + PIIX, 1996) product_version = pc-i440fx-10.2 bios_version = 1.16.3-alt3 Конфигурация ВМ: SeaBIOS, дисплей VirtIO-GPU, USB-слоты usb0-usb3 (spice; usb2 и usb3 с usb3=1). ОС хоста (не уверен, какой хост имелся в виду, указываю оба): - сервер, на котором запущен Proxmox: alt-server 11.1 - ноутбук (камера физически здесь, запущен remote-viewer): ALT Workstation K 11.4, virt-viewer 11.0-alt3, libspice-gtk3 0.42-alt1, libusbredir 0.14.0-alt1. Проброс: камера проброшена как USB-устройство через SPICE, не как виртуальная камера. USB-контроллер в ВМ: QEMU xHCI (USB 3.0), камера на нём (Bus 002, порт 4), скорость 480M (USB 2.0). > - Камера встроенная или внешняя; есть ли другие камеры/виртуальные > видеоустройства? Камера встроена в ноутбук. Других камер и виртуальных видеоустройств нет, v4l2-ctl --list-devices показывает только: HP FHD Camera (usb-0000:00:1a.0-4): /dev/video0 /dev/video1 /dev/media0 > - Проблема есть на физической машине или только в ВМ? Если физическая > машина недоступна, достаточно это указать. Физическая машина недоступна. > - Вывод в гостевой системе: cat /etc/os-release, uname -a, > printf ..., rpm -qa | grep ..., id Полные выводы в приложенном файле step1/env-60885.txt. Главное: ОС: ALT Workstation K 11.4, ветка sisyphus Ядро: 6.12.112-6.12-alt1 x86_64 Сессия: session=wayland desktop=KDE OpenToonz: opentoonz-1.8.0-alt3 Qt: libqt5-multimedia 5.15.18, qt5-wayland 5.15.18 GStreamer: 1.28.8 (base, good, bad, ugly), gst-plugins-libcamera 0.7.2 OpenCV: установлены одновременно libopencv4.10, libopencv4.13, libopencv4.14 V4L: libv4l 1.32.0, v4l-utils 1.32.0 id: uid=1000(test), в группах video и camera ------------------------------------------------------------------ 2. Какие устройства доступны именно в момент неисправности ------------------------------------------------------------------ > В гостевой системе от обычного пользователя, запускающего > OpenToonz: lsusb, ls -l /dev/video*, v4l2-ctl --list-devices, > fuser -v /dev/video*, и для каждого /dev/videoN: v4l2-ctl --all, > --list-formats-ext, udevadm info Снимок сделан 2026-10-16 в 15:11:50 от пользователя test, при открытом окне "Захват камеры" в OpenToonz, когда камера была недоступна. Полный вывод в приложенном файле step2/step2.txt. lsusb: Bus 002 Device 003: ID 0408:546d Quanta Computer, Inc. HP FHD Camera ls -l /dev/video* /dev/media*: crw-rw----+ root video /dev/media0 /dev/video0 /dev/video1 (созданы 13:52, с тех пор не менялись) v4l2-ctl --list-devices: HP FHD Camera (usb-0000:00:1a.0-4): /dev/video0, /dev/video1, /dev/media0 fuser -v /dev/video*: /dev/video0 открыт процессом OpenToonz (PID 33828, пользователь test). Для процессов 32081 и 32327 fuser выдал "Отказано в доступе" [Повтор от root: пустой вывод] /dev/video0 (узел захвата, Device Caps: Video Capture, Streaming): драйвер uvcvideo, текущий формат 640x480 YUYV 30 fps. Форматы (--list-formats-ext): MJPG: 640x480, 640x360, 1280x720, 1920x1080 (30 и 15 fps) YUYV: 640x480, 640x360 (30 и 15 fps) udevadm: ID_V4L_CAPABILITIES=:capture:, TAGS=:seat:uaccess: /dev/video1 (узел метаданных, Device Caps: Metadata Capture, формат UVCH): форматов видео нет (--list-formats-ext пусто). udevadm: ID_V4L_CAPABILITIES пусто. ------------------------------------------------------------------ 3. Точный симптом и настройки OpenToonz ------------------------------------------------------------------ > - Камера отсутствует в выпадающем списке или присутствует, но > изображение пустое/чёрное/замершее? Какой текст ошибки виден? Камера в выпадающем списке есть: "HP FHD Camera: HP FHD Camera" (в окне название обрезано). Вместо изображения чёрная область с надписью "Camera is not available". Других текстов ошибок, диалогов и сообщений в окне нет. > - Скриншот (приложен файлом step3/screenshot_opentoonz.png) всего окна «Захват камеры»: выбранное устройство, разрешение, состояние переключателя «Use MJPG with Webcam». Выбрано устройство HP FHD Camera, разрешение по умолчанию 3840x2160, затем переключал на 1920x1080; при обоих разрешениях результат одинаковый. Переключатель "Use MJPG with Webcam": не нашёл > - Список предлагаемых разрешений. В выпадающем списке 14 значений: 640x360, 640x480, 800x448, 800x600, 848x480, 864x480, 960x540, 960x720, 1024x576, 1280x720, 1600x896, 1600x900, 1920x1080, 3840x2160. Для сравнения, камера по v4l2-ctl --list-formats-ext: MJPG: 640x480, 640x360, 1280x720, 1920x1080 YUYV: 640x480, 640x360 То есть в списке есть значения, которых у камеры нет (в том числе 3840x2160, выбранное по умолчанию). > - Остаётся ли интерфейс отзывчивым во время ожидания? Да, интерфейс остаётся отзывчивым. > - Появилась ли картинка сама, без действий, или перед этим были > переключение камеры/разрешения, открытие окна, переподключение USB? > По возможности замерьте время от открытия окна до первого кадра. Картинка появлялась в одном из прежних запусков, примерно через 60-90 минут после открытия окна; перед этим я переключал камеру и разрешение. Переподключение USB не выполнялось(вроде). В текущем запуске картинка не появилась. ------------------------------------------------------------------ 4. Логи запуска ------------------------------------------------------------------ Лог OpenToonz снят по инструкции. Все логи приожены (step4/kernel-step4.log и step4/opentoonz-camera-step4.log). Журнал гипервизора мне не доступен/ ------------------------------------------------------------------ 5. Проверки (при выполнении этого пункта была обнаружена ошибка мhttps://bugzilla.altlinux.org/61128) ------------------------------------------------------------------ > Проверки по одной, с записью результата > Перед каждым независимым опытом завершать OpenToonz и приложения, > использующие камеру; не менять несколько условий одновременно: Выполнены проверки а, б, в, д, е, ж; г не выполнена (см. ниже). Каждый опыт - отдельный запуск OpenToonz; перед стартом он не был запущен (строка "запущен ли OpenToonz" в файлах *-state.txt пустая). Результаты - в приложенном архиве, папка step5/. Как читать файлы. Порядок чтения во всех папках один и тот же: 1) *-state.txt - условия опыта и итог: время старта и конца, были ли /dev/video*, видна ли камера в lsusb, сколько было попыток открыть камеру. Первым, чтобы понять, что это за опыт. 2) *-short-log-kernel-uvcvideo-usb.txt - события ядра по камере: отключение, подключение, таймауты (серийный номер убран). Вторым, потому что показывает, когда камера пропадала и возвращалась: от этих моментов удобно читать лог OpenCV. Пустой файл - таких событий не было. 3) *-short-log-opencv.txt - выдержка из лога OpenCV: попытки открыть камеру и результат каждой. Число в скобках, например [ WARN:0@24.374] - секунды от запуска OpenToonz. Файлы ...-gstreamer.txt, ...-resolution.txt - дополнения к нему: те же попытки по сообщениям GStreamer и строки про разрешение. 4) *-counts.txt - сколько раз встретилась каждая ошибка: итог по логу из пункта 3. 5) *-short-log-kernel-xhci-per-minute.txt - число ошибок xhci в минуту (слева число ошибок, справа минута). Общий фон ядра, на него смотрят после остального. 6) *-devices-now.txt - какие /dev/video* были сразу после опыта. Не во всех папках есть все файлы, порядок при этом сохраняется. Время ядра - по часам ВМ (МСК). Полные логи опытов не прикладываю из-за размера (кроме exp-a.log), могу прислать по запросу. > а) Подключить камеру до запуска OpenToonz, открыть сразу «Захват > камеры», без «Тестирования камеры». Выполнено. Камера подключена до запуска, окно открыто сразу. Камера не заработала (изображения нет). Файлы, читать по порядку: 1) step5/step5-a/exp-a.txt - состояние и итог запуска; 2) step5/step5-v/step5-v1/short-log-kernel-uvcvideo-usb.txt - события ядра по камере; 3) там же not-working-short-log-opencv.txt - попытки открыть камеру в этом запуске; 4) там же not-working-short-log-gstreamer.txt - то же по сообщениям GStreamer; 5) там же short-log-kernel-xhci-per-minute.txt - ошибки xhci; 6) step5/step5-a/exp-a.log - полный лог запуска, если не хватит выдержек (читать последним, он самый большой). Почему файлы 2-5 лежат в step5-v1: сразу после а) я перешёл к в) и первым запуском (v1) ничего не менял, камера заработала на максимальном разрешении. Выдержки собраны сразу по обоим запускам: not-working-* относятся к а), working-* - к v1 (см. пункт в), файлы ядра общие для обоих. > б) Подключить после запуска, нажать обновление списка камер и > выбрать устройство. Выполнено один раз. Камеру отключил до запуска OpenToonz, запустил, затем подключил камеру, обновил список и выбрал её. Камера заработала на самом большом разрешении. Папка step5/step5-b/, файлы по порядку: 1) b-state.txt - условия (камеры в системе не было) и итог; 2) b-short-log-kernel-uvcvideo-usb.txt - когда камера отключилась и когда вернулась; 3) b-working-short-log-opencv.txt - попытка открыть камеру; 4) b-working-short-log-counts.txt - счётчики по этому логу; 5) b-short-log-kernel-xhci-per-minute.txt - ошибки xhci; 6) b-devices-now.txt - устройства после опыта. > в) Выбрать 640×480, если оно поддерживается по выводу v4l2-ctl, > сохранив прежнее состояние MJPG. Выполнено двумя запусками, папка step5/step5-v/. v1 (после опыта а): запустил, ничего не менял (камера и разрешение по умолчанию). Камера заработала на максимальном разрешении. Папка step5-v1/, файлы по порядку: short-log-kernel-uvcvideo-usb.txt (общий с а), working-short-log-opencv.txt (попытки открыть камеру), working-short-log-gstreamer.txt (то же по сообщениям GStreamer), short-log-kernel-xhci-per-minute.txt (общий с а). v2: как просили, состояние MJPG не менялось. Открыл окно, камера сначала не работала; выбрал 640x480 - появилось изображение, оно работало до закрытия. Папка step5-v2/, файлы по порядку: 1) 640x480-state.txt - условия и итог; 2) 640x480-short-log-kernel-uvcvideo-usb.txt - события ядра (файл пуст: событий не было); 3) 640x480-working-short-log-opencv.txt - попытки открыть камеру; 4) 640x480-working-short-log-gstreamer.txt - то же по сообщениям GStreamer; 5) 640x480-short-log-kernel-xhci-per-minute.txt - ошибки xhci. > г) Отдельно проверить включённый и выключенный «Use MJPG with > Webcam» на одном поддерживаемом разрешении. Не выполнено: параметр «Use MJPG with Webcam» не нашёл. > д) При работающем захвате повторно выбрать ту же камеру: > прекращается ли изображение? Восстанавливается ли после выбора > «- Select camera -» и повторного выбора камеры либо смены > разрешения? Выполнено. Выбрал 640x480 - изображение пошло; выбрал «- Select camera -» - изображение пропало; выбрал камеру снова (по умолчанию стоит наибольшее 3840x2160) - изображение пошло. Прямой повторный выбор той же камеры без «- Select camera -» отдельно не фиксировался. Папка step5/step5-d/, файлы по порядку: 1) reselect-state.txt - условия и итог; 2) reselect-short-log-kernel-uvcvideo-usb.txt - события ядра; 3) reselect-short-log-opencv.txt - попытки открыть камеру в порядке времени; 4) reselect-short-log-resolution.txt - строки лога про разрешение; 5) reselect-short-log-kernel-xhci-per-minute.txt - ошибки xhci. > е) После неудачного подключения помогают ли закрытие/открытие > окна, полный перезапуск приложения или USB-переподключение? > Проверить отдельно. Выполнено тремя запусками в step5/step5-e/ (камера была подключена с самого начала): step5-e1 - запуск без выбора 640x480: камера не заработала. Файлы по порядку: e1-state.txt, e1-short-log-kernel-uvcvideo-usb.txt, e1-not-working-short-log-opencv.txt, e1-not-working-short-log-counts.txt, e1-short-log-kernel-xhci-per-minute.txt. step5-e2 - два запуска: e2 (первый запуск) и e22 (полный перезапуск OpenToonz). В обоих камера не заработала. Ядро для них общее, поэтому порядок такой: сначала состояния обоих запусков (e2-state.txt, e22-state.txt), затем общий файл ядра e2-e22-short-log-kernel-uvcvideo-usb.txt, затем логи OpenCV (e2-short-log-opencv.txt, e22-short-log-opencv.txt), счётчики (e2-short-log-counts.txt, e22-short-log-counts.txt) и общий e2-e22-short-log-kernel-xhci-per-minute.txt. step5-e3 - USB-переподключение камеры: камера не заработала. Файлы по порядку: 1) e3-state.txt - условия и итог; 2) e3-short-log-kernel-uvcvideo-usb.txt - отключение и подключение камеры (точки отсчёта для остальных файлов); 3) e3-short-log-opencv-first40.txt - первые 40 строк попыток (начало запуска); 4) e3-short-log-first-errors.txt - первые ошибки "нет файла"; 5) e3-short-log-last-enoent.txt - последние такие ошибки; 6) e3-short-log-opencv-last10.txt - последние попытки (конец запуска); 7) e3-short-log-counts.txt - счётчики по всему логу; 8) e3-short-log-kernel-xhci-per-minute.txt - ошибки xhci; 9) e3-devices-now.txt - устройства после опыта. Пункты 3-6 идут в порядке времени внутри лога. > ж) Проверить камеру в другом приложении внутри той же ВМ. Указать > приложение и результат, затем полностью его закрыть перед > OpenToonz. Если возможно, отдельно проверить на хосте, предварительно > освободив камеру от ВМ; не использовать одновременно на хосте и в > госте. Приложение cheese, запускал на ВМ. Камера доступна сразу, проблем не было, изображение шло. На хосте отдельно не проверялось. ------------------------------------------------------------------ 6. Независимая проверка V4L2 ------------------------------------------------------------------ > При закрытых OpenToonz и других клиентах камеры, от того же > обычного пользователя, для capture-узла: timeout 20s v4l2-ctl > -d /dev/videoN --stream-mmap --stream-count=30 --stream-to=/dev/null > echo "exit=$?" Выполнено от пользователя test, 2026-10-16 17:23:18 - 17:23:25. OpenToonz не запущен. fuser от root: /dev/video1, /dev/video2, /dev/media0 никем не открыты. От test fuser видит /dev/media0 открытым процессом wireplumber (фоновая служба PipeWire). Capture-узел: /dev/video1 (Card type: HP FHD Camera, Device Caps 0x04200001, Video Capture); /dev/video2 - метаданные (Metadata Capture). /dev/video0 в системе отсутствует. Текущий формат перед тестом (v4l2-ctl --all, приложен step6/v4l2-all-before-60885.txt). Команда: timeout 20s v4l2-ctl -d /dev/video1 --stream-mmap --stream-count=30 --stream-to=/dev/null Результат: получено 30 кадров, exit=0 (таймаут не сработал), скорость 6.05 - 7.73 fps (по v4l2-ctl --list-formats-ext камера отдаёт на 640x480 30 или 15 fps). Вывод приложен: step6/v4l2-stream-60885.txt. Журнал ядра за время теста (17:23:23): 4 пары сообщений xhci_hcd 0000:00:1a.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 / Looking for event-dma ...; ошибок uvcvideo нет. Вывод: в текущем состоянии (узлы /dev/video1, /dev/video2) V4L2-захват с камеры работает, кадры идут. Тест при наличии /dev/video0 повторю и сообщу отдельно.
Если я правильно понимаю, судя по issue, проблема давно известна, и пока не решена в апстрим
Created attachment 22771 [details] Исправление выбора Linux-устройства камеры, повторного выбора и резервного разрешения Спасибо за подробную диагностику в комментарии №5. Подготовил небольшой патч для OpenToonz 1.8.0 и проверил его на Poligon с виртуальной V4L2-камерой (v4l2loopback + движущийся тестовый кадр FFmpeg), без физической веб-камеры. На исходном opentoonz-1.8.0-alt3 воспроизвелись два отдельных дефекта: 1. Если единственное устройство захвата — /dev/video1, Qt видит именно его, но OpenToonz передаёт OpenCV номер 0 из списка. В результате программа пытается открыть отсутствующий /dev/video0. 2. Повторный выбор уже работающей камеры останавливает захват: release() и остановка таймера выполняются до проверки «камера не изменилась». Патч открывает на Linux путь выбранного устройства через V4L2 и переносит проверку повторного выбора перед остановкой захвата. Дополнительно при пустом списке разрешений Qt по умолчанию выбирается 640x480 вместо неподтверждённого 3840x2160. Остальные пункты резервного списка и восстановление сохранённого разрешения оставлены. Полная сборка с существующими ALT-патчами прошла. На исправленной сборке автоматическая проверка реального окна Camera Capture подтвердила движущееся изображение с /dev/video0 и /dev/video1, повторный выбор той же камеры, закрытие/открытие окна, выбор через «- Select camera -» и запуск без камеры. Проверка выполнялась через Qt xcb в Xvfb, не в нативной Wayland-сессии. Прилагаю исходный патч: из корня исходников patch -p1 < opentoonz-1.8.0-camera-device.patch, затем пересборка. Это не патч для установленного бинарного файла. Готовый RPM пока не собран и не опубликован. Просьба проверить сборку с этим патчем на исходном стенде с HP FHD Camera через SPICE: - камера подключена до запуска, сразу открыть Camera Capture без Camera Test; - сначала проверить 640x480: ранее сохранённое 3840x2160 может восстановиться и с патчем; - при работающем изображении повторно выбрать ту же камеру, БЕЗ промежуточного выбора «- Select camera -»; - отдельно закрыть/открыть окно захвата и проверить отключение/повторное подключение камеры с обновлением списка; - если номер capture-узла изменится, проверить, что захват идёт с нового /dev/videoN. Достаточно указать результат каждого опыта, выбранное разрешение, фактический capture-узел и время до первого кадра. Полный набор сведений об окружении повторять не нужно. Если отказ сохранится, полезен короткий лог: env OPENCV_VIDEOIO_DEBUG=1 OPENCV_LOG_LEVEL=DEBUG opentoonz > opentoonz-camera-patched.log 2>&1 Достаточно 1–2 минут неисправного состояния и сообщений ядра за тот же интервал. Эмуляция не воспроизводит ошибки USB/xHCI/SPICE и согласование MJPEG с реальной HP-камерой. Поэтому эти исправления пока не доказывают устранение всех причин данного отчёта; баг оставляю открытым.
попробуйте с реальным стендом и заданием https://packages.altlinux.org/tasks/438166
(Ответ для Anton Farygin на комментарий #8) > попробуйте с реальным стендом и заданием > https://packages.altlinux.org/tasks/438166 Доброго времени суток. на моем ноутбуке в opentoonz из задания, камера заработала
opentoonz-1.8.0-alt4 -> sisyphus: Wed Oct 21 2026 Anton Farygin <rider@altlinux> 1.8.0-alt4 - fixed Linux camera device selection and capture on camera reselection (Closes: #60885) - use a conservative default when camera resolutions cannot be queried
Исправление проверено, ошибка не воспроизводится
