LINUX.ORG.RU

NVIDIA Graphics Driver 555.58 для Linux, FreeBSD и Solaris

 


1

2

NVIDIA выпустила стабильную версию графического драйвера NVIDIA Graphics Driver 555.58 для платформ Linux, FreeBSD и Solaris с новыми функциями и множеством улучшений.

Главной новой особенностью графического драйвера NVIDIA 555.58 является поддержка явной синхронизации GPU для Wayland через протокол linux-drm-syncobj-v1, который недавно был реализован в окружениях GNOME 46.1 и KDE Plasma 6.1, а также в графическом стеке Mesa 24.1. Явная синхронизация в графическом драйвере NVIDIA – это большое достижение для пользователей GPU NVIDIA, желающих использовать Wayland: ожидается, что она положит конец графическим сбоям и различным неприятностям, мешающим полноценному использованию Wayland.

Драйвер NVIDIA 555.58 также включает поддержку прошивки GSP по умолчанию на всех поддерживаемых GPU NVIDIA, поддержку режима немедленного представления для Vulkan Wayland WSI и интерактивный запрос для nvidia-installer, позволяющий пользователям выбирать между проприетарными и открытыми модулями ядра.

Кроме того, в этом выпуске добавлена поддержка использования EGL вместо GLX в качестве OpenGL ICD для NvFBC, включена поддержка HDMI с 10 битами на компонент по умолчанию, а минимальная требуемая версия ядра Linux изменена с 3.10 на 4.15.

Среди других изменений в выпуске графического драйвера NVIDIA 555.58 удалена поддержка Base Mosaic на видеокартах GeForce, которая ранее была доступна только на некоторых GPU с определёнными материнскими платами и ограничивалась пятью дисплейными устройствами, а также исправлено несколько ошибок из предыдущих выпусков.

В этом выпуске также присутствует множество исправлений ошибок, таких как ошибка сегментации при запуске многопоточных приложений NvFBC или ошибка, которая могла вызывать искажение изображения при использовании расширения GLX_EXT_buffer_age на X.org с отгрузкой рендеринга PRIME.

Исправлена ошибка, которая могла вызвать сбой сервера X при запросе графическими приложениями однобуферных рисуемых объектов при включённых определённых функциях, таких как резкость в Vulkan, ошибка, которая могла привести к «панике ядра» из-за сбоя при освобождении спинлока в некоторых условиях, и «состояние гонки», которое могло привести к сбоям при возникновении ошибок Xid одновременно на нескольких GPU.

Кроме того, NVIDIA 555.58 устраняет ошибку, из-за которой отображались неправильные цвета при загрузке nvidia-drm с параметром модуля fbdev=1 на некоторых ядрах, регрессию, которая приводила к ошибкам Xid при загрузке драйвера NVIDIA на некоторых ноутбуках с GPU серии NVIDIA RTX 4xxx, и ошибку, которая вызывала сбой сборки драйвера при использовании отдельных каталогов исходного кода и вывода ядра на Linux 6.6 LTS и новее.

Устранена ошибка, которая неправильно позволяла nvidia-smi -r сбрасывать основной GPU при использовании открытых модулей ядра, ошибка, из-за которой vkGetPhysicalDeviceSurfaceSupportKHR неправильно сообщала о поддержке поверхностей Wayland при загрузке nvidia-drm без modeset=1, а также ошибка, которая могла привести к зависанию системы и сообщениям «Idling display engine timed out» при переключении виртуальных терминалов на дисплее HDMI Fixed Rate Link (FRL).

Наконец, NVIDIA 555.58 исправляет ошибку, которая могла вызвать блокировку дисплея при приостановке на ядре с включённым CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER и загруженным nvidia-drm с modeset=1 и fbdev=1, а также ошибку, которая приводила к появлению сообщений «Failed to apply atomic modeset» и «Flip event timeout» в системном журнале при потере разрешений «master» DRM клиентом (например, ddcutil) во время инициализации фреймбуфера консоли.

>>> Подробности

★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от redeyedanonymous

Подозреваю, что XFCE до поддержки вяленого допилят раньше, чем вяленый заматереет.

Тут либо KDE пофиксят к тому времени, либо вяленый заматереет. Это еще несколько лет.

pekmop1024 ★★★★★
()
Ответ на: комментарий от ac130kz

И как я прочел, там нету гарантированной частоты, и в Safari есть с ней проблемы, то есть о плавной прокрутке при чтении страницы можно забыть.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

VRR уж давно нормально работает, это именно Сафари - браузер ходячий прикол.

ac130kz ★★
()
Ответ на: комментарий от pekmop1024

При отсутствии плавности - глазам требуется больше времени на ресинхронизацию, куда прокрутилось. Так что делать анимацию прокрутку медленнее этого времени на ресинхронизацию смысла нет. А вот если сделать её быстрее - то есть шанс что благодаря плавности синхронищация не потеряется.

GPFault ★★
()
Ответ на: комментарий от pekmop1024

Как правило, эта задержка настолько незаметна, что на работу никак не влияет.
Тем более, какая разница в скроллинге, где что так, что этак страница движется? Ты б ещё на телефоне жаловался на плавный скроллинг.

whbex ★★
()
Ответ на: комментарий от whbex

Как правило, эта задержка настолько незаметна, что на работу никак не влияет.

Ну вот мне не нравится ждать по полсекунды.

Тем более, какая разница в скроллинге, где что так, что этак страница движется?

У тебя настолько говеный дисплей, что на нем при отключенной анимации что-то «движется»?

Ты б ещё на телефоне жаловался на плавный скроллинг.

Бесит, да.

pekmop1024 ★★★★★
()
Ответ на: комментарий от GPFault

При отсутствии плавности - глазам требуется больше времени на ресинхронизацию, куда прокрутилось

Мозгу. Глаза - это просто датчик. Но видимо у нас мозг работает по-разному…

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Плавность к скорости отношение не имеет, просто ты прокручиваешь и видишь два кадра, начальный и конечный, а я в это время вижу еще 4 дополнительных.

MOPKOBKA ★★★★★
()

Докладываю: вопхнул свежий драйвер в опенсусю с последними кедами. Фирменного вяленого дрыгалова поубавилось, но полностью оно не исчезло.

thesis ★★★★★
()

А где 560? Вроде же 18-го должен был быть.

thegoldone ★☆
()

Моя ничего не понимает. 560 должен был выйти 18 июня. А в итоге вышел 555, который уже был. Может не .58, но сути не меняет. Причём кто-то где-то затирал, что 555 – это бета.

thegoldone ★☆
()
Ответ на: комментарий от MOPKOBKA

Внезапно, но нет. Любая анимация добавляет латентность. Её даже регулировать иногда можно.

pekmop1024 ★★★★★
()
Ответ на: комментарий от MOPKOBKA

зачем работать с ноутбука

потому что хочется поработать в парке, в поезде, на крыше дома вечером (от детей, внуков сбежать), полноразмерной удобной клавиатуры до слёз не хватает, скажу страшную ересь-вещь сам не верил: работать можно с телефона в термух.

s-warus ★★★
()
Ответ на: комментарий от anonshmanon

Контекстное меню (в основном плазмы) «отрывается» и показывается как обычное окно, если десктоп не в фокусе

У меня так себя ведут всплывающие подсказки в окне настроек Double Commander (Qt6), в других местах не встречал. Это и на 550х дровах было.

При клике по всплывающему сообщению Телеграма вместе с ним открывается Вроде нет такого.

Зато фрикад (официальный appimage) перестал дрыгаться, steam стал дрыгаться гораздо меньше, yast (Qt5) получше стал.

Это на opensuse.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от firkax

Очень печально что в современном бизнесе принято иметь должность штатного разводилы партнёров на деньги.

Ну это главное лицо компании же. Этим успешно занимался Стив Джобс, а теперь вот у нас Тим Кук, св. ИлонЪ МаскЪ Марсианский и прочие имя им легион.

Бизнес просто теперь работает не так как он работал.

Когда мы читалим Маркса Энгельса Ленина - там писалось что буржуй выпустил продукт, продал продукт, заплатил за сырье за труд за аренду и пр пр пр - и вот разница между тем что он потратил и чем он отдал и есть его прибыль.

Теперь все не так. Теперь есть акции и биржевая торговля. И основной рост компании просиходит не от того что ты произвел что продал и сколько потратил - а от того как биржа среагировала на твои действия ростом или падением твоих акций. Акции того же ябока взлетали в космос даже от того что Стив там что-то многозначительно намекнул.

Так что бизнес это уже давно не про то чтобы сделать и продать качественный продукт, бизнес сейчас - это про то как выгодно продать свои акции на бирже, то есть по сути налюбить на деньги инвесторов. Да - продукт или проект продукта это часть аферы, но одним продуктом бизнес не сделаешь.

Qui-Gon ★★★★★
()
Ответ на: комментарий от s-warus

В парке комары, в поезде просто неудобно, а уж работать еще там! Для меня это одни из самых худших условий которые можно только представить. Сбежать куда то и работать в тишине, такое мне понятно, но в идеале хорошо бы иметь просто отдельную рабочую комнату.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от R_He_Po6oT

для хайку иван пилит в группе в тгк. Для геншина…. Стартует, собирается. В общем крутяк

FarParticul
()
Ответ на: комментарий от MOPKOBKA

Парк не упоминал, тяжело найти место без солнца и без коморов, но можно под дубами в парке победы скамейки нет, но сухо чистые корни.
Поезд самое лучшее место для работы: все не знают чем занять себя, изнывают от скуки в карты рубятся (сейчас нет) и жрут, ты полностью погружаешься в работу если собеседницу не нашёл, я за 2 дня от Москвы до Сочи и от Сочи до Москвы делал столько сколько за месяц не сделаешь, на курорте (сочи абхазии) строчки не выдавишь. Всякие кворкинги библиотеки не так у них расписание (на ночь могут закрыватся), пожрать кудато ходить, отвлекаешься на людей, они интересны в отличие от поезда, ты из кворкинга сбежать можешь, а поезде всё сидишь до конца работаешь.

s-warus ★★★
()
Ответ на: комментарий от thesis

С этим очень грусно таскать с собой не вариант, внезапно куда то очередь, в метро далеко, в кафе кого то ждёшь и таскать с собой клаву.
У меня такой вариант из костылей: терминус у этого клиента ssh клава очень удобная клава жесты все клавиши на месте, только нужно все его предложения облака и оплаты игнорировать, подключаешься к себе на локалхост в термух, можно конечно ключи в терминусе ключи и остальную хрень задействовать, но у меня скрипты ключами заведуют поэтому термух, да всё python, php, постгре, гит, имаджемеджик на самом телефоне запускаются можно ни куда не подключатся только готовые результаты сбрасывать.

s-warus ★★★
()
Ответ на: комментарий от yu-boot

Вяленый, и всякая экзотика типа нескольких мониторов с разными частотами. Под иксами с одним монитором как не было проблем, так и нет.

alegz ★★★★
()
Ответ на: комментарий от hobbit

Надо на реддите или в каком-нибудь другом публичном месте выставить рабочий десктоп с Haiku и амдшной видеокартой и написать «Haiku и AMD – созданы друг для друга»! Вот тогда NVIDIA не то, чтобы почешется, но хотя бы задумается о том, чтобы почесаться. @X512, как тебе идея? Впрочем, понятно, что для этого надо openGL в целом довести до ума сначала…

На дпнный момент я делаю порт открытого ядерного драйвера Nvidia и он уже успешно стартует и инициализирует железо. Сам открытый код от Nvidia очень портабельный и для сборки под Haiku требуется лишь пара правок вроде добавки объявлений что Haiku – это UNIX платформа. Остаётся сделать реализацию ОС-специфичных функций.

Код OpenGL/Vulkan драйвера закрытый, так что я планирую использовать драйвер NVK и обёртку над ядерным драйвером от Nvidia.

Потом если заработает, то можно попросить Nvidia собрать проприетырные драйвера OpenGL/Vulkan под Haiku. Там по идее ничего сложного портировать не надо, просто исправить возникшие ошибки сборки. Всю поддержку Haiku GUI можно сделать в отделтных модулях разработчиками Haiku.

При благоприятном исходе это может заработать уже через несколько месяцев и быть пригодно для обычного испольдования на широком диапазоне видеокарт Nvidia начиная с Turing. С AMD перспективы намного печальнее из-за отсутствия документации ядерных драйверов и сильной прибитости ядерных драйверов к Линуксу.

Так что Haiku ❤️ Nvidia

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от R_He_Po6oT

См. предыдущее сообщение.

Лог ядра от 7/4:

KERN: devfs: reload driver "nvidia_gsp" (3, 10553207)
KERN: nvidia_gsp: init_hardware
KERN: nvidia_gsp: init_driver
KERN: rm_init_rm()
KERN: Scan PCI:
KERN:   01.00.00: 10de.1ff2
KERN: +NvHaikuBaseDevice()
KERN: +NvHaikuDevice()
KERN:     BAR[0]: 0xfb000000, 0x1000000
KERN:     BAR[1]: 0xd0000000, 0x10000000
KERN:     BAR[3]: 0xe0000000, 0x2000000
KERN:     BAR[5]: 0xf000, 0x80
KERN: rm_init_private_state()
KERN: +NvHaikuBaseDevice()
KERN: MinDriver: publish_devices
KERN: MinDriver: find_device("nvidia0")
KERN: MinDriver: find_device("nvidiactl")
KERN: NvHaikuControlDevice()::Open(0x42)
KERN: +NvHaikuBaseDeviceHandle
KERN: NvHaikuDevice()::Open(0x42)
KERN: +NvHaikuBaseDeviceHandle
KERN: +NvHaikuDeviceHandle
KERN: allocate_io_interrupt_vectors: allocated 1 vectors starting from 63
KERN: msi_allocate_vectors: allocated 1 vectors starting from 63
KERN: msi enabled: 0x0081
KERN: rm_init_adapter()
KERN: NVRM: GPU 0000:01:00.0: RmInitAdapter
KERN: NVRM: GPU 0000:01:00.0: RmSetupRegisters for 0x10de:0x1ff2
KERN: NVRM: GPU 0000:01:00.0: pci config info:
KERN: NVRM: GPU 0000:01:00.0:    registers look  like: 0x00000000fb000000 0x0000000001000000
KERN: NVRM: GPU 0000:01:00.0:    fb        looks like: 0x00000000d0000000 0x0000000010000000
KERN: NVRM: GPU 0000:01:00.0: Successfully mapped framebuffer and registers
KERN: NVRM: GPU 0000:01:00.0: final mappings:
KERN: NVRM: GPU 0000:01:00.0:     regs: 0x00000000fb000000 0x0000000001000000 0x0xffffffffc0a51000
KERN: NVRM: RmFetchGspRmImages: Failed to load gsp_log_*.bin, no GSP-RM logs will be printed (non-fatal)
KERN: os_disable_console_access()
KERN: os_enable_console_access()
KERN: rm_isr(0)
KERN: rm_isr(1)
KERN: NvHaikuDevice::DeferredInterruptHandler()
KERN: NVRM: tlsIsrInit: TLS: Unnecessary tlsIsrInit() call at FFFFFFFFC0363710. Will stop reporting further violations.
KERN: NVRM: PBI is not supported for GPU 0000:01:00.0
KERN: NVRM: GPU 0000:01:00.0: RmInitAdapter succeeded!
KERN: nv->rmapi.hClient: 0xc1d00009
KERN: nv->rmapi.hDevice: 0xcaf00000
KERN: nv->rmapi.hSubDevice: 0xcaf00001
KERN: nv->rmapi.hI2C: 0xcaf00002
KERN: nv->rmapi.hDisp: 0xcaf00003
KERN: NvHaikuBaseDeviceHandle::Control(0xc020462b)
KERN:   cmd: 43, len: 32
KERN: NvHaikuBaseDeviceHandle::Control(0xc020462b)
KERN:   cmd: 43, len: 32
KERN: NvHaikuBaseDeviceHandle::Control(0xc020462b)
KERN:   cmd: 43, len: 32
KERN: NvHaikuBaseDeviceHandle::Control(0xc020462b)
KERN:   cmd: 43, len: 32
KERN: NvHaikuDevice()::Open(0x42)
KERN: +NvHaikuBaseDeviceHandle
KERN: +NvHaikuDeviceHandle
KERN: NvHaikuBaseDeviceHandle::Control(0xc038464e)
KERN:   cmd: 78, len: 56
KERN: nv_add_mapping_context_to_file(pAllocPriv: 0x0000000000000000, pageIndex: #0, fd: 6)
KERN:   nvuap:
KERN:     addr: 0xfbbb0000
KERN:     size: 0x1000
KERN:     offset: 0x0
KERN:     page_array: 0x0000000000000000
KERN:     num_pages: 0x0
KERN:     mmap_start: 0xfbbb0000
KERN:     mmap_size: 0x1000
KERN:     access_start: 0xfbbb0000
KERN:     access_size: 0x1000
KERN:     remap_prot_extra: 0x0
KERN:     contig: 1
KERN:     caching: 0x6
KERN: 1411: DEBUGGER: abort() called
KERN: debug_server: Thread 1411 entered the debugger: Debugger call: `abort() called'
KERN: stack trace, current PC 0x17218b8b7b9  </boot/system/lib/libroot.so> _kern_debugger + 0x9:
KERN:   (0x7fcbf9f31100)  0x5764ad8dd2  </boot/home/Tests/GL/NvidiaTest/build.x86_64/NvidiaTest> _ZN7NvrmApi9MapMemoryEjjmmj + 0x12c
KERN:   (0x7fcbf9f31190)  0x5764ad83b7  </boot/home/Tests/GL/NvidiaTest/build.x86_64/NvidiaTest> _ZN8NvDeviceC1EPKcj + 0x2b3
KERN:   (0x7fcbf9f31210)  0x5764ad84df  </boot/home/Tests/GL/NvidiaTest/build.x86_64/NvidiaTest> main + 0x24
KERN:   (0x7fcbf9f31270)  0x5764ad7bbe  </boot/home/Tests/GL/NvidiaTest/build.x86_64/NvidiaTest> _start + 0x3e
KERN:   (0x7fcbf9f312a0)  0x172e0438ce5  </boot/system/runtime_loader> runtime_loader + 0x115
KERN: debug_server: Killing team 1411 (./NvidiaTest)
KERN: NvHaikuDeviceHandle::Close()
KERN: NvHaikuBaseDeviceHandle::Close()
KERN: -NvHaikuDeviceHandle
KERN: -NvHaikuBaseDeviceHandle
KERN: NvHaikuBaseDeviceHandle::Close()
KERN: -NvHaikuBaseDeviceHandle
KERN: NvHaikuDeviceHandle::Close()
KERN: rm_shutdown_adapter()
KERN: os_disable_console_access()
KERN: os_enable_console_access()
KERN: NVRM: GPU 0000:01:00.0: Tearing down registers
KERN: msi_free_vectors: freeing 1 vectors starting from 63
KERN: free_io_interrupt_vectors: freeing 1 vectors starting from 63
KERN: NvHaikuBaseDeviceHandle::Close()
KERN: -NvHaikuDeviceHandle
KERN: -NvHaikuBaseDeviceHandle
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 1411: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 1411: Operation on invalid team
KERN: debug_server: Killing team 1411 ()

X512 ★★★★★
()
Ответ на: комментарий от X512

Жаль, что так всё с АМД, ты же с них начал как с открытых дров.

И теперь придётся искать компы только с энвидией под Гайку, потому что оптимус всё равно не взлетит и там, я так понимаю, работы непаханное поле.

R_He_Po6oT ★★★★★
()
Ответ на: комментарий от R_He_Po6oT

Жаль, что так всё с АМД, ты же с них начал как с открытых дров.

Ну ядерные драйвера Nvidia как бы тоже открытые: https://github.com/NVIDIA/open-gpu-kernel-modules. Но огромное отличие от AMD в том, что они не привязаны к Линуксу и без проблем собираются в Haiku. Портирование ядерных драйверов Линукса под Haiku – сложная и нудная задача за которую я не готов браться. А с документацией на железо всё плохо. Доступная документация в основном касается написания OpenGL/Vulkan драйверов, а по ядерной части почти ничего нет.

потому что оптимус всё равно не взлетит

Это про несколько видеокарт? Nvidia для рендеринга должна работать вне зависимости к какой видеокарте подключён монитор.

X512 ★★★★★
()
Ответ на: комментарий от X512

Портирование ядерных драйверов Линукса под Haiku – сложная и нудная задача за которую я не готов браться.

А кстати из-за чего? Всякие завязки на epoll’ы и прочие Linux-специфичные вещи?

EXL ★★★★★
()
Ответ на: комментарий от EXL

Ядерный код Линукса не использует обычный Си, там почти всё своё. Свои заголовки, свои типы, завязка на расширения GNU и т.д.. Портировпть всё это – кошмар. И в придачу «stable API nonsense», то есть в любой момент могут всё поломать. Кодовая база ядра Линукс – это вещь в себе которая трудно применима в других проектах, а также там враждебно относятся к ядерным модулям вне дерева кода ядра.

Портировать код пользовательского режима вроде Mesa несложно, а вот ядерный – катастрофа.

У *BSD с этим дела обстоят получше потому что они используют стандартные заголовки Си в ядре.

В придачу у Haiku есть своя специфика, например нет mknod и major/minor. Файлы устройств создаются через специальный API ядра и dev_t присваивается динамически.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 2)
Ответ на: комментарий от X512

завязка на расширения GNU

Всегда было интересно как Google собирает ядра для Android с помощью Clang/LLVM. Они там эти гнутые расширения вырезают или же Clang сегодня почти всё поддерживает?

EXL ★★★★★
()
Ответ на: комментарий от EXL

или же Clang сегодня почти всё поддерживает

This. Clang изначально разрабатывался как drop-in replacement GCC.

X512 ★★★★★
()
Ответ на: комментарий от X512

Ну, боюсь, тебе в энвидии не ответят и тогда и от открытой чпсти тоже толку не будет.

Это про несколько видеокарт? Nvidia для рендеринга должна работать вне зависимости к какой видеокарте подключён монитор.

Это аро конкретно про лаптопы, про рендеринг через энвидию, а вывод через интел/амд. В линуксе это была целая эпопея с появлением bumblebee, которые изначально променяли наработки virtualgl, а потом ответвились и что-то своё запилил, потому что nvidia не поддерживала технологию на линуксе, сначала из-за патента с майками, а потом потому что в линуксе чего-то не хватало, а потом потому что руки не доходили. Теперь в линуксе есть нативная поддежрка. А в Haiku всё было бы проще? Там же даже интеловсктй опенжиель не работает, всё через проц гоняется, или я не прав?

R_He_Po6oT ★★★★★
()
Ответ на: комментарий от R_He_Po6oT

Ну, боюсь, тебе в энвидии не ответят и тогда и от открытой чпсти тоже толку не будет.

Я выше писал, что с ядерным драйвером Nvidia можно использовать открытый Vulkan драйвер из состава Mesa NVK, если сделать враппер. Враппер сделать несложно.

Это аро конкретно про лаптопы, про рендеринг через энвидию, а вывод через интел/амд.

В худшем случае это всегда будет работать через GPU -> CPU -> GPU копирование. Это будет медленнее, чем поддержка в драйвере, но несущественно. Так чтобы вторая видеокарта вообще не работала, это какая-то особая криворукость. Чего там за проблемы возникли в Линуксе, я не знаю.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 2)
Ответ на: комментарий от X512

Я выше писал, что с ядерным драйвером Nvidia можно использовать открытый Vulkan драйвер из состава Mesa NVK, если сделать враппер. Враппер сделать несложно.

А так можно? Ого, не знал. Но работать то оно будет медленнее?

Чего там за проблемы возникли в Линуксе, я не знаю.

Ну там не только в ядре были проблемы. Тогда и меса и иусы и никто и ничто не умело так. Поэтому и был самый простой способ через virtualgl.

R_He_Po6oT ★★★★★
()
Ответ на: комментарий от ox55ff

В ядре есть стабильное API и внутреннее нестабильное API для чисто внутреннего использования, а также пока нестабилизированного функционала. В Haiku считается нормальным распространять бинарные модули ядра от сторонних разработчиков через менеджер пакетов.

В Haiku также отстутствует какая либо DRM система проверки лицензий для ядерных модулей.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.