Как я подключал GoPro Hero 13 к ноутбуку — а в итоге пропатчил KDE

vdudouyt22 часа назад

Как я подключал GoPro Hero 13 к ноутбуку — а в итоге пропатчил KDE

Уровень сложностиСреднийВремя на прочтение9 минОхват и читатели7.8KLinux*Графические оболочки*Компьютерное железоПериферияКейсНе столь давно супруга попросила меня перелить записи со своей GoPro на мой ноутбук. Когда-то, когда камеры были по сути обычными USB-флешками с FAT это ни у кого не вызывало проблем, а вот с MTP-устройствами бывает и так:

На этом месте можно было взять Android File Transfer for Linux и перелить через него - но я упертый, и решил разобраться в ситуации.

Читаем дескриптор устройства

Хорошей отправной точкой при изучении любого USB-устройства является его дескриптор. Поэтому узнаем пару vid/pid устройства и стягиваем его:

$ lsusb|grep -i gopro
Bus 001 Device 045: ID 2672:0059 GoPro HERO13 Black
$ lsusb -d2672:0059 -vvv >descriptor.txtПрочитанный дескриптор (поскольку текста много - убираю под спойлер):

descriptor.txtBus 001 Device 008: ID 2672:0059 GoPro HERO13 Black
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2672 GoPro
idProduct 0x0059 HERO13 Black
bcdDevice 0.01
iManufacturer 1 GoPro
iProduct 2 HERO13 Black
iSerial 3 C3534250246817
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x007c
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 Generic Config
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 13 [unknown]
bFunctionProtocol 0
iFunction 8 CDC NCM
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 13 [unknown]
bInterfaceProtocol 0
iInterface 5 CDC Network Control Model (NCM)
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 6 0457474BB944
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
CDC NCM:
bcdNcmVersion 1.00
bmNetworkCapabilities 0x11
crc mode
packet filter
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 1
iInterface 7 CDC Network Data
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 1
iInterface 7 CDC Network Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 6 Imaging
bInterfaceSubClass 1 Still Image Capture
bInterfaceProtocol 1 Picture Transfer Protocol (PIMA 15470)
iInterface 10 MTP
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x001c 1x 28 bytes
bInterval 6
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x0000010e
BESL Link Power Management (LPM) Supported
BESL value 256 us
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000f
Device can operate at Low Speed (1Mbps)
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 511 micro seconds
Device Status: 0x0001
Self PoweredКакие мы можем сделать выводы:

• Интерфейсы 0 и 1 реализуют протокол CDC Network и не представляют для нас интереса в рамках данной статьи. Причина их существования заключается в том, что камера так же предоставляет псевдосетевой интерфейс по USB.
• Интерфейс 2 реализует протокол PTP (а точнее - его MTP-надмножество) и состоит из конечных точек с адресами 0x83 (EP 3 IN / Bulk), 0x02 (EP 2 OUT / Bulk) и 0x84 (EP 4 IN / Interrupt)
• Поскольку у интерфейса есть точка с типом interrupt in, можно с высокой долей уверенности сказать что устройство реализует в рамках данного протокола некую сущность “событий”, поступающих клиенту по инициативе от устройства.Стоит отметить, что номера точек не являются некими предопределенными в спецификации PTP/MTP значениями. Вместо этого они сами обнаруживаются клиентом исходя из типа и направления трансфера - как и в большинстве основанных на USB протоколов.

Запускаем Wireshark

Самое время посмотреть, что происходит “на проводе” - в чем нам поможет небезызвестный среди хабражителей сниффер. Не забываем загрузить модуль ядра и выставить права, чтобы не работать из-под рута:

$ sudo modprobe usbmon
$ sudo chgrp wireshark /dev/usbmon*
$ sudo chmod g+r /dev/usbmon*
$ wiresharkНачинаем запись на интерфейсе usbmon0. Ну а чтобы поле зрения не засоряли другие USB-устройства - а так же коммуникация самого GoPro по безинтересному в рамках данной статьи протоколу CDC Network, отфильтруем интересующие нас URB-ы по адресу устройства и номерам конечных точек:

usb.device_address==30 && usb.endpoint_address in {0x83, 0x02, 0x84}Если все прошло успешно, то должна получиться примерно вот такая картина:

Однако, вникать в происходящее без диссектора протокола было бы не очень здорово. Поэтому самое время добавить немного AI-магии.

Генерируем диссектор

Я закинул документацию в Claude Code вместе со следующим промптом. Чтобы Клод мог самотестироваться заранее ставим tshark и заливаем наш тестовый дамп. (Наверняка кто-то уже придумал MCP-сервер для wireshark, но и предложенная схема вполне себе работает).

Examine the docs and implement an MTP over USB protocol dissector for Wireshark 4.2.2 in Lua. You’re free to use tshark for the testing purposes. I uploaded an example of MTP communication in pcapng format for your reference - but keep in mind that it also contains CDC Network class communication that should be ignored.Закидываем получившийся mtp.lua в /usr/lib/x86_64-linux-gnu/wireshark/plugins/ и открываем дамп по новой:

Как по мне - так намного лучше. Далее я решил просто просмотреть коммуникацию устройства с хостом на предмет наличия каких-то очевидных проблем для начала.

Как я обнаружил проблему

Достаточно быстро я наткнулся на довольно интересный URB. Как видно, в этом месте хост запрашивает у устройства информацию о доступных Storage - а в ответ ему прилетает пустой список:

Непродолжительное разбирательство показало, что дело в следующем: оказывается, по каким-то причинам данная модель камеры не готова предоставить доступ к стореджу непосредственно в момент подключения по USB, а приходит в состояние готовности примерно через 1-2 секунды. Хотя в мире MTP появление и пропадание стореджей у устройства “на лету” не то, что бы является какой-то прям частой ситуацией - но и не то, что бы не предусмотрено: в данной ситуации устройство должно кинуть клиенту событие PTP_EC_StoreAdded или PTP_EC_StoreRemoved, ответив на “висящий” на хост-контроллере запрос на interrupt-трансфер.

Однако, отфильтровав трафик по 0x84-й точке я понял, что kiod даже не пытается получать события с устройства: в этом случае мы должны были бы увидеть этот самый “висящий” запрос на interrupt transfer - а его нет.

Про flow control в USB и "висящие" запросыКак это работает на видимом для ОС (transfer) уровне:

• Клиент (например, драйвер HID или libusb-приложение) создает запрос на interrupt in трансфер, и через USB-стек операционной системы он протягивается в хост-контроллер
• Хост-контроллер отправляет устройству токен IN и ожидает от него немедленный ответ
• Устройство может ответить фреймом с данными, если оно готово к передаче в данный момент, либо NAK в противном случае
• Если хост-контроллер получил NAK, то он повторяет попытку через некоторое время - а наш запрос на трансфер, с точки зрения операционной системы, все это время продолжает “висеть”
• Если устройство стало готово к передаче данных (например, пользователь двинул мышкой или нажал клавишу на клавиатуре и надо передать HID-репорт) то при следующим запросе с хост-контроллера оно отвечает фреймом с данными, а клиент - наконец-то получает ответ. После чего, как правило, тотчас же создает новый запрос.Данный принцип верен для всех типов трансферов кроме isochronous. Однако, гарантированный интервал опроса есть только у interrupt и равен bInterval, указанному в дескрипторе точки.

Само собой, ни ОС, ни wireshark все эти низкоуровневые приседания на транзакционном уровне не видят. Все, что ниже трансферного уровня можно увидеть только подключив логический анализатор к сигнальным линиям USB.

Патчим KDE

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

Но сначала находим пакет, в котором находится kf5/kiod/kmtpd.so и получаем его исходники:

$ apt-file search kf5/kiod/kmtpd.so
kio-extras: /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kiod/kmtpd.so
$ apt-get source kio-extras
dpkg-source: info: unpacking kio-extras_23.08.5.orig.tar.xz
dpkg-source: info: unpacking kio-extras_23.08.5-0ubuntu5.debian.tar.xzБеглое изучение исходников kio-extras/mtp/ показало наличие паттерна, по всей видимости, используемого для оповещения внешней среды при появлении изменений в структуре девайса. Похоже на то, что здесь взводится некий dirty flag, после чего отправляется сигнал во внешнюю среду:

device->setDevicesUpdatedStatus(true);
org::kde::KDirNotify::emitFilesAdded(device->url());Мы попробуем этим воспользоваться - однако, перед этим нужно организовать опрос устройства на предмет наличия событий в отдельном треде. Что ж, Qt way - так Qt way: создаем класс MTPEventWorker который будет опрашивать устройство и кидать сигналы storageAdded и storageRemoved по мере поступления соответствующих событий.

void MTPEventWorker::run()
{
qCDebug(LOG_KIOD_KMTPD) << "MTPEventWorker: starting event loop";
while (!m_stop) {
LIBMTP_event_t event;
uint32_t storage_id = 0;
const int ret = LIBMTP_Read_Event(m_device, &event, &storage_id);
if (ret != 0) {
qCDebug(LOG_KIOD_KMTPD) << "MTPEventWorker: LIBMTP_Read_Event returned" << ret << "— stopping";
break;
}
switch (event) {
case LIBMTP_EVENT_STORE_ADDED:
qCDebug(LOG_KIOD_KMTPD) << "MTPEventWorker: storageAdded storageId=" << storage_id;
Q_EMIT storageAdded(storage_id);
break;
case LIBMTP_EVENT_STORE_REMOVED:
qCDebug(LOG_KIOD_KMTPD) << "MTPEventWorker: storageRemoved storageId=" << storage_id;
Q_EMIT storageRemoved(storage_id);
break;
default:
break;
}
}
Q_EMIT finished();
}Запускаться это все будет в конструкторе MTPDevice:

m_eventThread = new QThread(this);
m_eventWorker = new MTPEventWorker(m_mtpdevice);
m_eventWorker->moveToThread(m_eventThread);

connect(m_eventThread, &QThread::started, m_eventWorker, &MTPEventWorker::run);
connect(m_eventWorker, &MTPEventWorker::finished, m_eventThread, &QThread::quit);
connect(m_eventThread, &QThread::finished, m_eventWorker, &QObject::deleteLater);

connect(m_eventWorker, &MTPEventWorker::storageAdded, this, &MTPDevice::onStorageAdded);
connect(m_eventWorker, &MTPEventWorker::storageRemoved, this, &MTPDevice::onStorageRemoved);

m_eventThread->start();Добавляем слот MTPDevice::storageAdded() - в нем добавляем полученный сторедж в m_storages и сигнализируем системе о наличии изменений:

void MTPDevice::onStorageAdded(quint32 storageId)
{
LIBMTP_Get_Storage(m_mtpdevice, LIBMTP_STORAGE_SORTBY_NOTSORTED);

for (const MTPStorage *s : qAsConst(m_storages)) {
if (s->storageId() == storageId)
return;
}

for (LIBMTP_devicestorage_t *storage = m_mtpdevice->storage;
storage != nullptr; storage = storage->next) {
if (storage->id == storageId) {
int index = m_storages.size();
auto *s = new MTPStorage(
QStringLiteral("%1/storage%2").arg(m_dbusObjectName).arg(index),
storage, this);
m_storages.append(s);
qCDebug(LOG_KIOD_KMTPD) << "StorageAdded: registered storage" << storageId;
break;
}
}

this->setDevicesUpdatedStatus(true);
org::kde::KDirNotify::emitFilesAdded(this->url());
}MTPDevice::onStorageRemoved - по аналогии:

void MTPDevice::onStorageRemoved(quint32 storageId)
{
for (int i = 0; i < m_storages.size(); ++i) {
if (m_storages[i]->storageId() == storageId) {
qCDebug(LOG_KIOD_KMTPD) << "StorageRemoved: unregistering storage" << storageId;

QUrl storageUrl = url();
storageUrl.setPath(storageUrl.path() + QLatin1Char('/') + m_storages[i]->description());

delete m_storages.takeAt(i);

this->setDevicesUpdatedStatus(true);
org::kde::KDirNotify::emitFilesRemoved({storageUrl});
break;
}
}
}Не забываем прибираться за собой в деструкторе MTPDevice:

if (m_eventThread && m_eventThread->isRunning()) {
m_eventWorker->stop();
if (!m_eventThread->wait(2000)) {
m_eventThread->terminate();
m_eventThread->wait();
}
}С согласия читателя я опускаю всякую тривиальщину типа объявления используемых элементов класса, так как не думаю, что это представляет интерес для разбора. Если же кому-то нужен полный код патча - он есть в конце статьи.

На этом, в общем-то, все - собираем и устанавливаем пакет:

$ dch -v 4:23.08.5-0vdudouyt # меняем префикс версии на недефолтный
$ fakeroot dpkg-buildpackage -nc
$ sudo dpkg -i kio-extras_23.08.5-0vdudouyt_amd64.deb kio-extras-data_23.08.5-0vdudouyt_all.deb
$ killall -9 kiod5Теперь подключаем GoPro опять. И - ура, теперь проблема полностью исчезла:

А что с андроидами?

Стоит отметить, что GoPro не является единственным устройством, имеющим склонность возвращать пустой список в ответ на GetStorageId. К примеру, именно в этот момент Android-устройства обычно показывают диалог "Разрешить доступ к данным на телефоне". Однако вместо отправки PTP_EC_StoreAdded они просто переподключаются с новым device address дернув pull-up резистор на линии - и эту ситуацию KDE сейчас и по дефолту умеет успешно отрабатывать.

Заключение

Надеюсь, что данная статья помогла читателю лучше понять, что происходит при передаче данных через ныне повсеместно распространенные протоколы USB и MTP, а так же ознакомиться с некоторыми потенциально проблемными граничными случаями последнего. Если же кого-то интересует полный текст патча, то его можно взять вот здесь.Теги:• gopro
• kde
• patch
• usb
• mtpХабы:• Linux
• Графические оболочки
• Компьютерное железо
• Периферия