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

Не столь давно супруга попросила меня перелить записи со своей GoPro на мой ноутбук. Когда-то, когда камеры были по сути обычными USB-флешками с FAT это ни у кого не вызывало проблем, а вот с MTP-устройствами бывает и так:

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

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

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

$ lsusb|grep -i goproBus 001 Device 045: ID 2672:0059 GoPro HERO13 Black$ lsusb -d2672:0059 -vvv >descriptor.txt

Прочитанный дескриптор (поскольку текста много — убираю под спойлер):

Bus 001 Device 008: ID 2672:0059 GoPro HERO13 BlackDevice 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               6Binary 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 secondsDevice 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 — а его нет.

Патчим KDE

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

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

$ apt-file search kf5/kiod/kmtpd.sokio-extras: /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kiod/kmtpd.so$ apt-get source kio-extrasdpkg-source: info: unpacking kio-extras_23.08.5.orig.tar.xzdpkg-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, а так же ознакомиться с некоторыми потенциально проблемными граничными случаями последнего. Если же кого-то интересует полный текст патча, то его можно взять вот здесь.