Drm что это linux
| | Долой игры в политику, или зачем Линусу Торвальдсу DRM membrana |
Мир потрясён: Линус Торвальдс, легендарный создатель ОС Linux фактически предлагает ввести в своё детище (которое уже далеко не только его) средства защиты прав на цифровой контент — DRM. Сам Linux и такие средства считаются взаимоисключающими явлениями. Так в чём же дело?
| | |
Дело в том, что такие средства — это излюбленное детище коммерсантов. В особенности, Microsoft. За тотальное внедрение DRM ратуют также медиагиганты — звукозаписывающие компании и Голливуд.
Уже не первый год последние подвергаются показательной порке из-за угла: они не захотели вовремя воспользоваться преимуществами интернет-технологий, зато к ним поспешили прибегнуть любители дармовщинки, и теперь пираты всё время наносят медиадинозаврам некоторый ущерб .
По другую сторону баррикад от Microsoft, RIAA и иже с ними засели «бессеребренники» — сообщество разработчиков программ с открытым кодом (сообщество Open Source).
В этой среде многие не в восторге от самой идеи каких-либо ограничений на использование того или иного программного обеспечения, в каких бы то ни было целях. Хотя, конечно, всё относительно: наверняка большинство приобщённых к компьютеру людей предпочли, чтобы спаммерских программ и вирусов никто не создавал и не использовал.
Как бы там ни было, Linux — один из светлых идеалов и движения Open Source, и сторонников идеологии свободного программного обеспечения. Их не следует мешать в одну кучу, однако же общего в их устремлениях, взглядах на жизнь и будущее информационных технологий много. И DRM ни у кого из них не котируется.
И вдруг Линус Торвальдс (Linus Torvalds), отец-основатель, человек, имеющий статус, можно сказать, полубога, выдаёт вот такой сюрприз: в рассылке Linux Kernel для разработчиков ядра Linux он пишет, что «ничто в базовых правилах использования Linux не должно препятствовать использованию технологий DRM».
Приведём цитату из его письма :
«Ок, я понимаю, что покрасоваться тут не получится, так что я даже и пытаться не буду. Я просто собираюсь присесть на корточки и ждать мощного и продолжительного флейма ( от английского flame — пламя ). Мои асбестовые трусы на мне, и они, признаться, крайне неудобны.
Так вот, я хочу дать ясно понять, что DRM и Linux совершенно не противоречат друг другу!
Ну вот, я сказал это. Я вышел на свет. Давайте, вперёд. «
«Упс!» — хором подумалось благодарным фанатам Linux и лично Торвальдса.
| | |
| ||
Однако, Торвальдс считает, что ничего криминального в цифровой подписи ядра Linux для обеспечения его аутентификации нет. Главное — не прятать ключи от пользователей (это, кстати, запрещено лицензией GPL напрямую).
Торвальдс говорит о том, что он не хочет «играть в политику» с Linux. Осмелимся предположить, что это один из ключевых моментов.
Дело в том, что сообщества Linux, в частности, Open Source, в общем, уже давно вышли за узкие рамки сугубо компьютерных, превратившись в «компьютерно-политические движения», в лучшем случае, видящие себя достойной альтернативой коммерческим разработкам Microsoft и других, в худшем же — ставящим себя в непримиримую оппозицию всему коммерческому ПО — которое не в меньшей степени идеологично.
И хотя можно сказать, что пиковый накал страстей давно уже миновал, и Microsoft отказалась от прямой критики Linux на уровне выражений «это не по-американски» и определений вроде «раковая опухоль на теле интеллектуальной собственности», жёсткое противостояние Microsoft vs. Linux сохраняется — и не только на уровне рыночной конкуренции, но и на уровне борьбы за умы потребителей.
На уровне идеологии.
DRM считается идеологическим атрибутом коммерческого ПО. Соответственно, в «бунтарском» открытом ПО таким средствам не место. Вроде как.
Но всё дело в том, что разработчики коммерческого софта и создатели аппаратного обеспечения — в основном те, что стоят под знамёнами Microsoft и Intel, — активно занимаются разработками в рамках провозглашённой Биллом Гейтсом инициативы «trusted computing» («надёжный компьютинг»), основной целью которой является обеспечение безопасности компьютеров от троянов и вирусов: пользователь должен быть уверен в том ПО, которое он запускает на своей машине.
|
| |
| ||
Ну и, как явствует, например, из описания Microsoft Palladium, такие средства подразумевают внедрение в программную и аппаратную части компьютеров систем аутентификации.
Многие разработчики «железа» отнюдь не в восторге от подобных вещей, но ещё меньше в этом заинтересованы разработчики открытого ПО. Последние имеют серьёзные основания полагать, что такие средства встраиваются ещё и затем, чтобы не допустить запуска определённых программ на стандартных машинах или не допустить их взаимодействия с другими программными средствами.
Так это, или не так, знают наверняка только в Microsoft и Intel, однако есть серьёзные основания полагать, что будущее аппаратное обеспечение, равно как и программное, сможет взаимодействовать только с «аутентифицированным» ядром Linux, с ядром, у которого имеются «документы», причём не только усы, лапы и хвост, и не только «здрасьте, я ядро Linux, давайте работать вместе».
Торвальдс, как уже сказано, не хочет, чтобы Linux был политическим движением, точнее, чтобы политика мешала использованию операционной системы так, как это нужно её пользователям, кем бы те ни были.
В конечном счёте, музыку заказывают — увы — производители «железа». И с чисто практической точки зрения разработчикам открытого ПО нет смысла вставать в патетичную позу и пытаться отказываться от правил, от которых невозможно отказаться.
Источник
Графическая среда Linux без единого разрыва
TL;DR — Если ваше графическое окружение Linux во время просмотра видео, сеанса игры или прокрутки интерактивной веб страницы не успевает вовремя обновлять картинку целиком, то тогда для вас имеет смысл установить последнюю стабильную версию ядра ≥ 4.10.
Давным давно, то есть несколько лет назад каждая реализация протокола X11 предполагала смену режима видео напрямую, поперек батьки кернела. Затем появился KMS (kernel mode setting) и эта важная функция перешла к ядру. Но остались некоторые шероховатости. Атомарная смена режима является дальнейшим улучшением механизма KMS.
Для чего нужны атомарные операции KMS? Главным образом для того, чтобы избежать вот таких моментов.
Атомарная смена режима видео
DRM драйвер с поддержкой атомарной смены режима, a․ k․ a․ atomic mode setting имеет полезное свойство, которое заключается в том, что изменения видео режима проходят полную проверку прежде, чем вступят в силу. Это делается с целью обеспечить их корректное исполнение в драйверах и на дисплее с тем, чтобы избавить пользователей от мерцания, тиринга и прочих артефактов изображения. Скорость исполнения при этом также повышается. Звучит неплохо, а как это работает?
- Framebuffer — Видео память, однако в терминологии KMS это скорее пул источников памяти видео — объектов GEM, для которого заданы такие характеристики как активная зона памяти, или то, что будет изображено, а также формат данных, длина шага.
- CRTC — Аббревиатура расшифровывается как Cathode Ray Tube Controller, CRT Controller. Мало кто в нынешнее время использует мониторы на электронно-лучевых трубках, однако историческое название сохранилось с виде абстракции железа, которое считывает байты с памяти видео-карты и выдает пиксели на шину данных.
- Encoder — Интерфейс между разнородными источниками видео, читает с CRTC и передает в соединительный разъем, a․ k․ a․ Connector . Один CRTC может иметь несколько кодеров.
- Connector — Это может быть представлением для соединительного разъема монитора или же самим монитором в случае встроенных устройств с подключенных внешним экраном.
- Planes — Слой или план изображения на CRTC .
Для этого надо понять как изменяется видео режим без этого нововведения. Рассмотрим обычный сценарий, в котором пользователь смотрит видео в окне браузера или плеера, не в полный экран, используя аппаратное ускорение. Видео образует передний план, окно и декорации браузера или плеера, это второй — задний план.
- Драйверу видео передается список различных параметров: кадровый буфер, CRTC, экраны, режим.
- Пользователь перемещает окно плеера.
- Для этого нужно подгрузить новую страницу, a․ k․ a․ page flip, например.
- Если новая страница не синхронизирована между передним и задним планом, видео сместится относительно своего окна.
Механизма, обеспечивающего синхронизацию на предпоследнем шаге нет, отсутствовал ioctl() , который выполнял бы всю работу. Например, только основной план имел механизм неблокирующих обновлений критичных с точным завершением событий. А для того, чтобы обновления произошли в нескольких слоях, требовалось куча системных вызовов из пользовательского пространства в надежде на то, что они завершатся синхронно. В то же время атомарные операции KMS имеют встроенную защиту от этого. Вместо трех разных ioctl() , все изменения проходят в одном единственном ioctl() .
Вообще-то проблему отсутствия синхронизации между активной зоной и задним планом во время просмотра видео решалась компоновкой всего с помощью GL, так как последний умеет обновлять кадры синхронно с VBlank. Все бы хорошо, только вот для мобильных устройств это не приемлемо из за высоких требования к памяти и питанию со стороны GL компоновщика.
Работы над «атомным» проектом началась в 2015-м с патчей Дейва Эйрли (Dave Airlie), затрагивающих интеловские i915 и еще несколько драйверов, плюс новое атомарное API.
В настоящий момент атомарный процесс обновлений происходит следующим образом.
- Все изменения передаются ядру одним списком свойств (в середине картинки Properties ).
- Ядро генерирует состояние устройства (справа на картинке State ).
- atomic_check() проверяет валидность всех элементов списка свойств. Если есть ошибка ioctl() вернет уведомление об ошибка и отменит обновления.
- atomic_commit() также в соответствии с названием вводит изменения в действие, если на предыдущем шаге atomic_check() завершился без ошибок.
Структура атомарной KMS определена в файле /usr/include/uapi/drm/drm_mode.h .
Для открытых драйверов Nouveau от Nvidea атомарный KMS включен по умолчанию начиная с версии Linux 4.10, для драйверов Intel — начиная с 4.12. Дальше — больше!
Источник
libdrm samples
Background
DRM(Direct Rendering Manager) is the kernel part of DRI(Direct Rendering Infrastructure) originally designed for Linux X display server. In this artical, we focus on how to use libdrm.
DRM mainly has two parts:
- KMS: kernel mode setting
- GEM: Graphics Execution Manager, buffer management
DRM major concepts:
- Framebuffer: Memory infomation such as width, height, depth, bpp, pixel format, etc.
- CRTC: Mode information, resolution, depth, polarity, porch, refresh rate, etc
- Encoder: convert digital signal from CRTC to appropriate analog level, eDP, MIPI, …
- Connector: Physical connector like HDMI，DVI-D，VGA，S-Video
librdrm
DRM exports API through ioctl, libdrm is a user mode library to wrap these ioctls, please reference xf86drm.h in libdrm for detailed explanation. The general steps to use the libdrm are:
- open/drmOpen /dev/dri/cardN device node
- call drmModeGetResources, get all the drmModeRes resources. Resources include all the fb, crtc, encoder, connector, etc.
- loop through drmModeRes structure, call drmModeGetConnector, get the first connected connector(DRM_MODE_CONNECTED)
- drmModeConnector stores all the supporting mode, choose one from them.
- loop through drmModeRes，call drmModeGetEncoder. If the encoder matches with the selected mode, save the drmModeModeInfo for later use.
- create kms_driver, create buffer object，get the pitch of the BO，and map the BO to user space.
- draw on the BO using cairo or whatever graphic toolbox you like.
- get original display mode by calling drmModeGetCrtc, this will be used after program exit to restore the original mode.
- get frame buffer ID by calling drmModeAddFB, whose argument is BO handle.
- call drmModeSetCrtc with frame buffer ID, the BO attached with the FB is outputed to display.
a basic sample
The code snippet that follows these steps:
Open drm device, get drmModeRes based on fd. drmModeRes is the central point for following operations, incuding searching connectors and encoders. This picture shows some of the structures in libdrm. The arrows are data flow.
Search resource->connector array，get the first connected( DRM_MODE_CONNECTED ) connector. Get drmModeInfo by connector->modes[0].
In all encoders (resource->encoders array), search the matched encoder with connected connector.
create kms_driver, create BO(buffer object), get the pitch of the BO.
map BO to user space, map_buf stores the memory address.
get original display mode by calling drmModeGetCrtc, this is used to restore display mode after program exits.
get BO handle, call drmModeAddFB, get Frame Buffer id (fb_id). set display mode by calling drmModeSetCrtc，output the FB content(map_buf) associated with the BO.
wait for user input, restore the original display mode and quit the program.
page flip
Above sample draws on the same BO when it is displayed, thus it will probably make display flicker. Page flip use double buffer mechanisam, can be used to avoid flicker. Two frame buffers are created, each associated a BO. The BO being drawn is not the same BO being displayed. The application maintains two frame buffers. Picture is drawn on current frame buffer, and drmModePageFlip is called to send another frame buffer to crtc when vblank comes. Two frame buffers are switched in this way.
In this example, select is used to monitor multiple fds.
close line buffer of stdin in order for the program to receive any key without input enter.
The main loop of the program. stdin is put into monitor list of select. Whenever terminal has input, select return ready. ESC or ‘q’ is used to quit the program. We use drmHandleEvent to handle event on the drm device. evctx is an instance of drmEventContext structure, evctx.page_flip_handler points to the page flip handler.
page_flip_handler get current fb id, get next fb id, call drmModePageFlip. The next fb is set to crtc, frame buffer is swtiched.
cleanup, restore work after program exists. tcsetattr is used to restore original terminal setting.
Источник
