Не столь давно супруга попросила меня перелить записи со своей 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

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

Bus 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 - а его нет.

Патчим 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, а так же ознакомиться с некоторыми потенциально проблемными граничными случаями последнего. Если же кого-то интересует полный текст патча, то его можно взять вот здесь.