функция обратного вызова DXGKDDI_DSITRANSMISSION (dispmprt.h)
Функция обратного вызова DxgkddiDsiTransmission выполняет передачу последовательного интерфейса дисплея (DSI).
Синтаксис
DXGKDDI_DSITRANSMISSION DxgkddiDsitransmission;
NTSTATUS DxgkddiDsitransmission(
[in] HANDLE Context,
[in] D3DDDI_VIDEO_PRESENT_TARGET_ID TargetId,
[out] PDXGK_DSI_TRANSMISSION pArgs
)
{...}
Параметры
[in] Context
[in] TargetId
Целевой идентификатор монитора.
[out] pArgs
Указатель на структуру DXGI_DSI_TRANSMISSION .
Возвращаемое значение
DxgkddiDsiTransmission возвращает STATUS_SUCCESS в случае успешного выполнения; В противном случае возвращается один из кодов ошибок, определенных в ntstatus.h.
Комментарии
Чтобы позволить драйверу панели изготовителя оборудования взаимодействовать через частный интерфейс между графическим адаптером и аппаратным оборудованием панели, транзакции должны либо не иметь эффекта графического драйвера, кроме времени, занимающего шину, либо они должны быть полностью определены, чтобы графический драйвер был под контролем. Поскольку возможность взаимодействия с драйвером панели изготовителя оборудования заключается в предоставлении поддержки пользовательских функций панели, которые непрозрачны для графического драйвера, полностью определенные операции предназначены для транзакций, в которых драйвер панели должен выполнять стандартизованную операцию, которая не может быть выполнена без участия графического драйвера. Такие транзакции будут рассматриваться как исключения, перенаправленные явным образом, а не как передачи.
Каждый запрос на передачу DSI состоит из одного буфера, который заполняется драйвером панели OEM, передается по стеку монитора и возвращается с результатами передачи, если таковые есть. Буфер содержит общие сведения о передаче с полями ввода и вывода, за которым следует массив DXGK_DSI_PACKET структур с переменным размером. Пакеты описаны в терминах DSI, так что любой пакет DSI может быть описан, однако ОС будет анализировать пакеты и отклонять любую передачу, включающую пакеты, которые запрещены. Все пакеты, кроме последнего, являются, по определению DSI, пакетами записи, которые могут быть либо короткими(в этом случае Payload буфер не используется), либо длинными, которые помещаются в Payload буфер. Последний пакет в передаче, который может быть чтением или записью, может использовать расширенные полезные данные, выделяя и описывая больший буфер, который позволит свободное место для операций чтения или записи любого размера, вплоть до предельного размера данных длинного пакета DSI в 64 КБ-1 байт данных. Это позволяет помещать в очередь небольшие пакеты записи в драйвер в одном вызове, но требует, чтобы большие пакеты отправлялись по отдельности. Значение поля указывает, сколько дополнительных FinalPacketExtraPayload байтов было выделено, но это также должно учитываться в TotalBufferSize поле.
Драйвер панели oem отвечает за обеспечение того, чтобы запрашиваемые передачи не конфликтовли и не мешали другим передачам, которые графический драйвер использует для нормального взаимодействия с панелью из-за чрезмерных запросов или операций запроса, которые могут привести к задержкам при обработке других передач. Драйвер панели не должен изменять состояние, которое может вызвать последующие сбои в графическом драйвере, например изменение времени панели с помощью команд MCS. Аналогичным образом, если ОС запросила изменение дисплея, например с помощью графического драйвера, например при увеличении яркости, драйвер панели не должен использовать команды DSI для отмены этого изменения в ответ или в других целях.
IOCTL_MIPI_DSI_TRANSMISSION используется для запроса передачи на периферийное устройство, содержащее один или несколько пакетов DSI. Драйвер панели всегда должен инициализировать TotalBufferSizeи PacketCount первые три БАЙТа каждого пакета. Драйвер панели может переопределить поведение по умолчанию, используя ненулевые значения для TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPortи FinalCommandExtraPayloadManufacturingMode . Все неинициализированные значения должны иметь нулевое значение.
Операционная система гарантирует, что последовательность пакетов DSI имеет правильный формат, а также допустимые сведения во всех определенных полях и правильные размеры буфера. Операционная система отвечает за инициализацию FailedPacket поля для DXGK_DSI_INVALID_PACKET_INDEX таким образом, чтобы дальнейшая проверка в ОС или драйвере устанавливала поле только в том случае, если обнаружена проблема с определенным пакетом. Если DXGK_DSI_TRANSMISSION не имеет правильного формата, операционная система установит флаг DXGK_HOST_DSI_INVALID_TRANSMISSION в HostErrors поле, чтобы отличить его от других ошибок недопустимых параметров.
Чтобы считаться правильно сформированным, все должно быть верным:
- TotalBufferSize >= sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload
- FinalPacketExtraPayload <= 64K-1-DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE (0xFFF7)
- TotalBufferSize <= ROUND_TO_PAGES( sizeof(DXGK_DSI_TRANSMISSION) + (0xFE * sizeof(DXGK_DSI_PACKET)) + 0xFFF7 )
- PacketCount != 0
- Только последний пакет может быть прочитан
- Только последний длинный пакет записи может иметь
LongWriteWordCountзначение, превышающее [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE]
Проверка пакетов
Хотя ОС не будет пытаться полностью проверить содержимое всех пакетов, она отклонит передачу, содержащую все команды DSI, отличные от следующего, выполнив IOCTL без вызова графического драйвера:
| Значение типа данных | Описание |
|---|---|
| 0x03 | Общая короткая запись, без параметров |
| 0x13 | Общая короткая запись, 1 параметр |
| 0x23 | Общая короткая запись, 2 параметра |
| 0x04 | Универсальное чтение, без параметров |
| 0x14 | Универсальный параметр READ, 1 параметр |
| 0x24 | Универсальный параметр READ, 2 параметра |
| 0x05 | DCS Short WRITE, без параметров |
| 0x15 | DCS Short WRITE, 1 параметр |
| 0x06 | DCS READ, без параметров |
| 0x29 | Универсальная длинная запись |
| 0x39 | Запись и write_LUT dcs long |
Универсальные команды чтения и записи требуют понимания спецификации панели, поэтому предполагается, что эти команды могут свободно использоваться драйвером панели без проблем для графического драйвера, если шина не используется чрезмерно. Аналогичным образом команды DCS MCS явно определены для использования производителем, поэтому не должно возникать проблем с помехами между графическим драйвером и драйвером панели.
Для DCS UCS неопределенные команды не должны использоваться графическим драйвером, поэтому ОС позволит использовать их драйвером панели, хотя существует явный риск того, что будущие изменения спецификации MIPI-DCS определяют команду, поэтому предпочтительнее использовать команды MCS.
Стандартизированные команды DCS UCS будут использоваться графическим драйвером во время нормальной работы и потенциально могут использоваться драйвером панели, поэтому необходимо снизить риск того, что команды, отправленные драйвером панели изготовителя оборудования, вызывают проблемы с последующими командами графического драйвера. Для этого ОС будет анализировать команды DCS и отклонять пакеты, которые, как ожидается, вызовут конфликты, если драйвер панели OEM не установит ManufacturingMode флаг, а ОС подтвердит, что система находится в производственном режиме. Если флаг установлен, но система не находится в производственном режиме, IOCTL передачи будет завершен с флагом DXGK_HOST_DSI_INVALID_TRANSMISSION, установленным в HostErrors поле без вызова графического драйвера.
Условия, для которых требуется полностью определенная транзакция вместо использования передачи, будут в следующих случаях:
- Время простоя требуется до или после, например DCS soft_reset
- Изменение рабочей среды для вывода кадра, например dcs set_vsync_timing и enter_sleep_mode
- Использование транзакций с семантикой запуска и продолжения, где графическому драйверу также может потребоваться доступ к тем же данным, например DCS write_memory_start/write_memory_continue
Кроме того, существуют классы команд DCS, которые будут отклоняться ОС при отправке в качестве передачи:
- Любая команда, которая должна быть полностью определена, как описано выше
- Чтение данных в пикселях, которые можно использовать для очистки экрана
- Запись данных в пикселях
Команды UCS, которые ос будет передавать графическому драйверу:
| Hex | Get-Help |
|---|---|
| 00h | Nop |
| 26 ч. | set_gamma_curve |
| 2Dh | write_LUT |
| 51 ч | set_display_brightness |
| 52 ч | get_display_brightness |
| 53h | write_control_display |
| 54h | get_control_display |
| 55h | write_power_save |
| 56h | get_power_save |
| 5Eh | set_CABC_min_brightness |
| 5Fh | get_CABC_min_brightness |
| 03h | get_compression_mode |
| 05h | get_error_count_on_DSI |
| 06h | get_red_channel |
| 07h | get_green_channel |
| 08h | get_blue_channel |
| 0Ah | get_power_mode |
| 0Bh | get_address_mode |
| 0Ch | get_pixel_format |
| 0Dh | get_display_mode |
| 0Eh | get_signal_mode |
| 0Fh | get_diagnostic_result |
| 14 ч | get_image_checksum_rgb |
| 15 ч | get_image_checksum_ct |
| 3Fh | get_3D_control |
| 45 ч | get_scanline |
Команды UCS, которые ос будет отклонять:
| Hex | Get-Help |
|---|---|
| 01h | soft_reset (необходимо отправить через IOCTL_MIPI_DSI_RESET) |
| 10 ч | enter_sleep_mode |
| 11ч | exit_sleep_mode |
| 12 ч | enter_partial_mode |
| 13 ч. | enter_normal_mode |
| 20 ч | exit_invert_mode |
| 21 ч. | enter_invert_mode |
| 28 ч | set_display_off |
| 29h | set_display_on |
| 2Ah | set_column_address |
| 2Bh | set_page_address |
| 2Ch | write_memory_start |
| 2Eh | read_memory_start |
| 30 ч | set_partial_rows |
| 31h | set_partial_columns |
| 33 ч | set_scroll_area |
| 34 ч | set_tear_off |
| 35 ч | set_tear_on |
| 36h | set_address_mode |
| 37h | set_scroll_start |
| 38h | exit_idle_mode |
| 39h | enter_idle_mode |
| 3Ah | set_pixel_format |
| 3Ch | write_memory_continue |
| 3Dh | set_3D_control |
| 3Eh | read_memory_continue |
| 40 ч | set_vsync_timing |
| 44 ч | set_tear_scanline |
| A1h | read_DDB_start |
| A2h | read_PPS_start |
| A8h | read_DDB_continue |
| A9h | read_PPS_continue |
Реализация графического драйвера
Если передача проходит проверку ОС, операционная система передает буфер графическому драйверу, вызвав DxgkDsiTransmission DDI.
Добавление передач oem в интерфейс, который уже используется для отправки пиксельных и управляющих данных на основе запросов ОС и потребностей периферийного управления, неизбежно означает, что графическому драйверу потребуется улучшить внутреннюю последовательность, чтобы обеспечить правильное включение этого дополнительного потока пакетов. Графический драйвер не должен переупорядочения пакетов в рамках передачи от драйвера панели OEM и должен отправлять всю последовательность непрерывно и без чередование других пакетов. Графический драйвер не обязан поддерживать порядок собственных пакетов относительно времени поступления запроса на передачу панели OEM, поэтому может выбрать отправку пакетов для настройки следующего кадра до (или после) отправки передачи панели OEM. Если завершение запущенной передачи на панели OEM угрожает пропустить период времени для критических пакетов, драйвер должен сообщить об отмене передачи. Если передача не запущена, но драйвер ожидает, что это приведет к пропуску критических пакетов временного окна, драйвер должен отложить запуск передачи до следующего периода пробела. Если задержка передачи панели OEM приведет к тому, что она ждала запуска более двух кадров, драйвер должен сообщить о передаче как об отброшенной.
Графический драйвер не может гарантировать, что передачи, отправляемые от имени драйвера панели, не конфликтуют с передачами, которыми он управляет. Драйвер может проверить пакеты в рамках передачи и отклонить передачу, если это вызовет проблемы, но любые пакеты, которые считаются небезопасными, должны быть помечены на отторжение на уровне ОС, поэтому отклонение на уровне драйвера в идеале должно быть вызвано проблемами поставщика графики. Драйвер не должен пытаться кэшировать или оптимизировать операции чтения или записи, даже если пакеты кажутся стандартизованными командами.
Если графический драйвер отклоняет передачу из-за проблемы с пакетом, он должен обновить FailedPacket поле с индексом первого пакета, что приведет к отклонению передачи, и установить HostErrors флаг DXGK_HOST_DSI_DRIVER_REJECTED_PACKET перед возвратом. Если задано переопределение режима передачи, драйвер должен убедиться, что переопределение совместимо с аппаратными ограничениями, а если нет, установить HostErrors флаг DXGK_HOST_DSI_BAD_TRANSMISSION_MODE перед возвратом.
Если во время обмена данными происходит сбой, графический драйвер должен обновить FailedPacket поле с индексом пакета, который завершился сбоем, однако во всех случаях драйвер может не определить пакет, поэтому драйвер должен оставить значение по умолчанию, DXGK_DSI_INVALID_PACKET_INDEX для таких случаев.
Графический драйвер отвечает за обмен пакетами, поэтому должен гарантировать, что все суммы проверка вычисляются и проверяются. Любая передача, которая заканчивается чтением, будет коротким пакетом, поэтому поля Data0 и Data1 содержат любые параметры, а ответ может быть коротким или длинным пакетом. Графический драйвер может не знать, в какой форме и как долго будут находиться возвращаемые данные, но максимальный размер — это полный размер полезных данных для конечного пакета, включая FinalPacketExtraPayload. ОС проверит, что это значение не больше, чем TargetMaximumReturnPacketSize указано драйвером в его возможностях для целевого объекта, но драйвер должен убедиться, что этот буфер не переполнен периферийным устройством, сообщающим больше данных, и что данные с периферийного устройства не усечены из-за того, что они больше, чем MaximumReturnPacketSize, применяемый в настоящее время к периферийной системе. Драйвер записывает число байтов, прочитанных в буфер, в ReadWordCount поле, описывающее передачу.
В некоторых случаях графический драйвер вынужден сбрасывать либо интерфейс связи на панель, либо на всю панель из-за ошибок, которые могут не быть связаны с драйвером панели изготовителя оборудования. Чтобы устранить эту проблему, драйвер должен сообщить о DXGK_HOST_DSI_INTERFACE_RESET или DXGK_HOST_DSI_DEVICE_RESET, заданных в HostErrors поле при первой попытке передачи передачи после сброса, чтобы драйвер панели изготовителя оборудования смог обнаружить ситуацию и восстановиться. Драйвер не должен отправлять эту передачу на оборудование, но драйвер панели OEM может просто повторить ту же команду, если восстановление не требуется. В этом случае драйвер должен продолжить обработку передачи, как обычно.
Завершение передачи
После завершения IOCTL полезные FailedPacketданные , ReadWordCount, MipiErrorsHostErrors и для считываемого (окончательного) пакета могут быть обновлены в зависимости от результата. Если при обработке передачи обнаружены ошибки, драйвер панели изготовителя оборудования должен использовать выходные MipiErrors значения и HostErrors , чтобы определить способ восстановления и продолжения.
Чтобы обеспечить возврат выходных данных вызывающей объекту для предоставления сведений о любых ошибках, вызовы IOCTL и DDI должны сообщать об успешном выполнении, даже если ошибки найдены. Успех не означает, что транзакция была успешной, а указывает на то, что вызовы для обработки транзакции были выполнены должным образом, и установлены флаги ошибок, если это необходимо. Сбои по-прежнему могут сообщаться для таких условий, как неподдерживаемый вызов DDI (предположительно из-за несоответствия драйвера), сбои выделения памяти или передача полностью плохих параметров, таких как передача буфера NULL. Если при успешном вызове не сообщается об ошибках, вызывающий объект должен предположить, что транзакция была успешной.
Требования
| Требование | Значение |
|---|---|
| Минимальная версия клиента | Windows 10 версии 2004 |
| Верхняя часть | dispmprt.h |
См. также раздел
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по