IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)
Основной код: IRP_MJ_DEVICE_CONTROL
IOCTL_MIPI_DSI_TRANSMISSION отправляется для отправки последовательности пакетов MIPI DSI на периферийное устройство.
Основной код
Входной буфер
Недоступно
Длина входного буфера
Недоступно
Выходной буфер
Недоступно
Длина выходного буфера
Недоступно
Буфер входных и выходных данных
Структура DXGK_DSI_TRANSMISSION , за которой следуют DXGK_DSI_PACKET структуры, содержащие пакеты.
Длина входного/выходного буфера
По крайней мере sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload
. Дополнительные сведения см. в разделе "Примечания".
Блок состояния
Irp->IoStatus.Status имеет значение STATUS_SUCCESS, если запрос выполнен успешно. В противном случае для параметра Состояние устанавливается соответствующее условие ошибки в виде кода NTSTATUS. Дополнительные сведения см. в разделе Значения NTSTATUS.
Комментарии
Драйверы портов и минипортов мониторов, изготовителей оборудования и портов отображения должны обрабатывать ICTLs интерфейса цифрового последовательного интерфейса (DSI) для мобильных отраслевых процессоров (MIPI).
Выполнение передач
Чтобы разрешить драйверу панели взаимодействовать через этот закрытый интерфейс между графическим адаптером и аппаратным оборудованием панели, транзакции должны либо не иметь эффекта графического драйвера, кроме времени, занимающего шину, либо они должны быть полностью определены, чтобы графический драйвер был под контролем. Так как возможность взаимодействия с драйвером панели заключается в поддержке пользовательских функций панели, которые непрозрачны для графического драйвера, полностью определенные операции предназначены для транзакций, в которых драйвер панели должен выполнять стандартизованную операцию, которая не может быть выполнена без участия графического драйвера. Такие транзакции будут рассматриваться как исключения, перенаправленные явным образом, а не как передачи.
Каждый запрос на передачу состоит из одного буфера, который заполняется драйвером панели OEM, передается в стек монитора и возвращается с результатами передачи, если таковые есть. Буфер содержит общие сведения о передаче с полями ввода и вывода, за которыми следует массив DXGK_DSI_PACKET структур переменной величины. Пакеты описываются в терминах DSI, так что любой пакет DSI может быть описан, однако ОС будет анализировать пакеты и отклонять любую передачу, которая включает запрещенные пакеты. Все пакеты, кроме последнего, по определению DSI, записывают пакеты, которые могут быть либо короткими( в этом случае буфер полезных данных не используется), либо длинными, которые помещаются в буфер полезных данных . Последнему пакету в передаче, который может быть чтением или записью, разрешено использовать расширенные полезные данные, выделяя и описывая больший буфер, который позволит свободное место для операций чтения или записи любого размера, вплоть до ограничения DSI длинных пакетов данных в 64K-1 байт данных. Это позволяет помещать в очередь драйверу последовательность небольших пакетов записи в одном вызове, но требует, чтобы большие пакеты отправлялись по отдельности. Значение поля FinalPacketExtraPayload указывает, сколько дополнительных байтов было выделено, но это также необходимо учитывать в поле TotalBufferSize .
Драйвер панели OEM отвечает за обеспечение того, чтобы запрашиваемые передачи не конфликтовли и не влияли на другие передачи, которые графический драйвер использует для нормального взаимодействия с панелью из-за чрезмерных запросов или выполнения запросов, которые могут привести к задержкам при обработке других передач. Драйвер панели не должен изменять состояние, которое может привести к последующим сбоям в графическом драйвере, например изменение времени панели с помощью команд MCS. Аналогичным образом, если ОС запросила изменение дисплея через графический драйвер, например увеличение яркости, драйвер панели не должен использовать команды DSI для отмены этого изменения в ответ или в других целях.
IOCTL_MIPI_DSI_TRANSMISSION используется для запроса передачи на периферийное устройство, содержащее один или несколько пакетов DSI. Драйвер панели всегда должен инициализировать TotalBufferSize, PacketCount и первые три БАЙТа каждого пакета. Драйвер панели может переопределить поведение по умолчанию с помощью ненулевых значений для TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode и FinalCommandExtraPayload. Все неинициализированные значения должны иметь нулевое значение.
ОПЕРАЦИОННая система гарантирует, что последовательность пакетов 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 | Универсальный read, без параметров |
0x14 | Универсальный параметр READ, 1 параметр |
0x24 | Универсальный read, 2 параметра |
0x05 | DCS Short WRITE, без параметров |
0x15 | DCS Short WRITE, 1 параметр |
0x06 | DCS READ, без параметров |
0x29 | Общая длинная запись |
0x39 | Долгое запись и write_LUT DCS |
Универсальные команды чтения и записи требуют понимания спецификации панели, поэтому предполагается, что эти команды могут свободно использоваться драйвером панели, не вызывая проблем для графического драйвера, если шина не используется чрезмерно. Аналогичным образом, команды DCS MCS явно определены для использования производителем, поэтому не должно быть проблем с помехами между графическим драйвером и драйвером панели.
Для DCS UCS неопределенные команды не должны использоваться графическим драйвером, поэтому ОС позволит использовать их драйверу панели, хотя явно существует риск того, что будущие изменения спецификации MIPI-DCS определяют команду, поэтому команды MCS предпочтительнее.
Стандартизированные команды DCS UCS будут использоваться графическим драйвером во время нормальной работы и потенциально могут использоваться драйвером панели, поэтому необходимо снизить риск команд, отправленных драйвером панели OEM, которые вызывают проблемы с последующими командами графического драйвера. Для этого ОС будет анализировать команды DCS и отклонять пакеты, которые, как ожидается, вызовут конфликты, если драйвер панели изготовителя оборудования не установит 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 |
Примечание
Политики проверки ОС могут быть изменены в будущих выпусках.
Реализация графического драйвера
Если передача проходит проверку ОС, ОС передает буфер графическому драйверу с помощью DsiTransmission.
Добавление передач 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 смог обнаружить ситуацию и восстановиться. Драйвер не должен отправлять эту передачу на оборудование, но драйвер панели OEM может просто повторить ту же команду, если восстановление не требуется. В этом случае драйвер должен продолжить обработку передачи обычным образом.
Завершение передачи
После завершения FailedPacket
IOCTL полезные данные , ReadWordCount
, MipiErrors
HostErrors
и для прочитанного (окончательного) пакета могли быть обновлены в зависимости от результата. Если при обработке передачи обнаружены ошибки, драйвер панели изготовителя оборудования должен использовать выходные MipiErrors
значения и HostErrors
, чтобы определить, как восстановить и продолжить.
Чтобы обеспечить возврат выходных данных вызывающей объекту для предоставления сведений о любых ошибках, вызовы IOCTL и DDI должны сообщать об успешном выполнении, даже если ошибки обнаружены. Успешное выполнение не означает, что транзакция прошла успешно, а указывает на то, что вызовы для обработки транзакции продолжались должным образом, и при необходимости были установлены флаги ошибок. Сбои могут по-прежнему сообщаться для таких условий, как неподдерживаемый вызов DDI (предположительно из-за несоответствия драйвера), сбои выделения памяти или передача полностью недопустимых параметров, например передача буфера NULL. Если при успешном вызове не сообщается об ошибках, вызывающий объект должен предположить, что транзакция прошла успешно.
Требования
Требование | Значение |
---|---|
Минимальная версия клиента | Windows 10 версии 2004 |
Верхняя часть | ntddvdeo.h |