Компания Nvidia без лишнего шума и анонсов добавила в драйверах версии 435.17 для Linux поддержку работы с Vulkan и OpenGL + GLX в динамическом (on-demand) режиме рендеринга PRIME. Поддержки EGL пока нет.


Вся масштабность анонса в одном скриншоте

PRIME — это Linux-реализация системы распределения рендеринга приложений по нескольким графическим процессорам известной как Nvidia Optimus, что актуально для ноутбуков, оснащенных, например, связкой из встроенного видео Intel HD Graphics и дискретным чипом Nvidia.

Представители компании NVIDIA заявили, что в октябре 2021 года с поддержки компании будут сняты пользовательские ОС Windows 7 и Windows 8.1. Это означает, что для этих операционных систем более не будут выпускаться драйвера для графических ускорителей GeForce.

«Подавляющее большинство наших пользователей GeForce перешли на операционную систему Windows 10. Чтобы обеспечить владельцам карт максимально возможную безопасность, поддержку и функциональность, компания NVIDIA сосредоточит свои силы на операционной системе Windows 10», — говорится в сообщении.

Была без проблем и заморочек установлена сборка 7000.
Тестировалась на AMD Athlon 64 3500+, ASUS A8N-SLI-Deluxe, 2Gb DDR и видео ATI 2900HD.

Все драйвера подхватились с первого раза кроме встроенного контроллера гигабитной сети, который в свою очередь установлен из windows update.

Было много обзоров и статей по поводу — какая она красивая и все такое. Но я хотел бы затронуть вопросы некоторой кустомизации и совместимости.

Сборка на данный момент распространяется только в 32битном режиме на английском языке. Вобщем не так что бы гипернеприятность, но все таки фактор, когда вопрос стоит о машине о домашней рабочей операционке.

Недавно прочитал по поводу того, что мол — «таскбар огромный!». Ребят, это все враки! :)

В некоторых моделях обнаружена неисправность, вызванная сочетанием старых версий BIOS и драйверов аудио, которая может привести к выходу из строя динамиков (вплоть до оплавления самих динамиков и корпуса над ними), чипа аудио и иногда матрицы LCD.

Ноутбуки, к которым применима данная информация:
— T410, T410i, T410s, T410si, T510, T510i
— W510, W701, W701ds
— X201, X201i, X201s, X201 Tablet

Нужные драйвера и BIOS можно найти по следующим ссылкам:

Conexant Audio Software for Windows 7, Vista and XP — ThinkPad T410, T410i, T410s, T410si, T510, T510i, W510, W701, W701ds, X201, X201i, X201s, X201 Tablet
www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-74380

Drivers and software — ThinkPad T410, T410i, T410s, T410si, T510, T510i and W510
www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-74582#bios
Drivers and software — ThinkPad X201, X201i, X201s, X201si and X201 Tablet
www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-70656#bios
Drivers and software — ThinkPad W700, W700ds, W701 and W701ds
www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-70498#bios

Решился опубликовать результаты моего исследования программы GMABooster, которая была представлена хабражителям буквально вчера. Сразу скажу, анализ не был бы проведен столь быстро, если бы не совершенно незнакомый хабраюзер Werat, который удаленно тестировал из под админа мой код на своем Acer Aspire One a150 (отважился же человек).

Своим топиком мне хотелось бы подчеркнуть важность открытых продуктов, свободы обмена информации между людьми [а еще напомнить всем жалующимся и плачущим, что Хабр — торт!].

Disclaimer: Анализ приведен исключительно в обучающих и мирных целях, меньше всего мне хотелось бы снизить размер пожертвований в сторону автора программы. В любом случае им проведена работа, которая заслуживает уважения. Также, я вынужден рассмотреть «альтернативное» решение для некоторых платформ, в силу того, что GMABooster не удобен по ряду критериев, особенно для пользователей Linux и Mac.

Предисловие

Однажды мне понадобилось написать драйвер под Windows XP SP2. Сразу встал вопрос отладки. Уж очень не хотелось использовать мудреный SoftIce, ребутиться при кадждой ошибке или делать откаты. Поэтому было решено использовать виртуалку VirtualBox, которой я частенько пользуюсь и характеристиками которой вполне доволен, и отладчиком Windows Debugger от Microsoft. Через несколько часов в окошке WinDbg радостно замаячили строчки на Си, и было решено сделать «напоминалку», которая получилась неплохим «HowTo». Итак, начнем…

Недавно, просматривая руководство пользователя CodeIgniter, случайно обнаружил новые для себя пункты о драйверах и их создании. Поскольку написано в них немного, я решил рассмотреть эту тему подробней.

Итак драйвер — это особый тип библиотеки, которая состоит из одного родительского класса и нескольких дочерних. Дочерние классы получают доступ только к родительскому классу, но не имеют доступа к свои собратьям. Термин «дочерний» на самом деле не наследует поля родителя, а лишь получает к ним доступ.

Драйверы служат для разбиения ваших библиотек на отдельные классы и в CodeIgniter представляют собой реализацию структурного шаблона проектирования Декоратор.

Существует разные техники отладки: кто-то зарывается в отладчик, кто-то медитирует, ожидая просветления, кто-то судорожно меняет код в надежде на удачу, но почти ни кто не откажется от файла в котором будет сохранены последние мгновения жизни процесса, что происходило, в каких нитях, на каких ядрах, в какое время. Заботливо и педантично сохраненная отладочная информация может сохранить многие рабочие часы, особенно если речь идет о отладке драйвера и аппаратного обеспечения с которым он работает. Ну, а в случае когда ошибка случайная и воспроизводиться на 1 системе из 20 в течении недели, то без отладочной информации медитация может затянуться.
В данной статье пойдет речь об утилитах, помогающих в перехвате отладочных сообщений драйверов, работающих на нескольких машинах одновременно и передаче сообщений на сервер для сохранения и анализа.

Многие помнят как Линус Торвальдс показал неприличный жест в адрес NVIDIA после того, как оказалось, что компания спустя рукава относится к поддержке своих видеокарт в Linux.

Как бы то ни было, но в сегодняшнем официальном пресс-релизе NVIDIA неожиданно выяснилось, что новые драйверы для видеокарты GeForce R310 "удваивают производительность и значительно сокращают время загрузки игр на компьютерах с операционной системой Linux."

Даг Ломбарди (Doug Lombardi), вице-президент по маркетингу в Valve:

«В новой версии драйверов NVIDIA смогла повысить общую игровую производительность в ОС Linux. NVIDIA, бесспорно, заняла ведущую позицию, разработав драйверы R310 вместе с нами и другими студиями, чтобы предоставить лучшее решение под Linux для геймеров».

После апгрейда на Windows 8 мною была замечена странная проблема: после спящего режима, а иногда и при холодном старте, я не мог войти в систему потому, что ни мышка ни клавиатура не функционировали! Спешу разочаровать тех кто сталкивается с этой проблемой, внятного решения пока нет.

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

• У меня SSD, а он всё-таки подороже будет, чем обычные HDD (объём моего текущего SSD — 120 гигов)
• Ноутбук рабочий, соответственно данные на нём тоже, должны быть шифрованы, всё такое, поэтому самопальный и не утверждённое работодателем носитель втыкать не стоит
• Я жадный :)

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

Критикуешь – предлагай

Нас нередко ругают на Хабрахабре за то, что статьи недостаточно технические, а описание работы программы плохо детализировано. Но на самом деле каждый читатель понимает, что описать в одном посте абсолютно все – просто невозможно, потому что несколько лет развитие DRP шло во множестве направлений.

Часть из них связана непосредственно с исполняемым файлом, пресловутым .exe'шником; другая – с созданием архива и, что немаловажно, индекса драйверов; третья – с тестированием приложения и отдельных версий драйверов для различного оборудования как на разных версиях ОС Windows, так и на железных стойках. Часть из этих решений мы отдаем в тестирование пользователям, проявившим особенный интерес.

道 — путь. В этой заключительной статье о формате NSNJSON я хочу рассказать о моем пути, который привел меня к изобретению этого формата.

В комментариях к моим прошлым статьям («Усложнённый упрощённый JSON» и «JSON для любителей скобочек») неоднократно прозвучали вопросы о смысле, сложности, удобности и применимости этого формата. Итак, спешу поздравить всех неравнодушных — Вы дождались!

В прошлой заметке мы обсудили самую известную пару из лагеря инструментов синхронизации тредов — mutex и cond. Сегодня встретимся с sema — примитивом, который умеет заменять предыдущие два в одиночку.

Но сначала — пара слов о случайных пробуждениях. (Спасибо xaizek, который мне об этом напомнил.) В принципе, строго реализованные механизмы синхронизации этим не страдают, но, тем не менее, опытный программист на это никогда не полагается.

Напомню фрагмент кода:

while(total_free_mem <= 0)
    {
    wait_cond(&got_free_mem, &allocator_mutex);
    }

Здесь цикл вокруг wait_cond гарантирует нам, что даже если мы вернёмся из ожидания события случайно или по ошибке, ничего страшного не случится — проверка в while обеспечит нам уверенность, что нужное состояние проверяемого объекта достигнуто. Если нет — поспим ещё в ожидании.

Отметим ещё раз, что проверяем мы состояние объекта (total_free_mem <= 0) при запертом мьютексе, то есть никто не может его менять в то же самое время.

Мало кто знает, что в ядре Linux есть необычные и весьма полезные инструменты для отладки и тестирования. В этой небольшой статье я хочу поделиться описанием трассировщика ввода-вывода.

Здравствуйте, дорогие хабрачитатели.

Цель данной статьи — показать принцип реализации драйверов устройств в системе Linux, на примере простого символьного драйвера.

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

Это моя первая статья, пожалуйста не судите строго!

P.S

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

Часть 1 — Введение, инициализация и очистка модуля ядра.
Часть 2 — Функции open, read, write и trim.
Часть 3 — Пишем Makefile и тестируем устройство.

Перед вступлением, хочу сказать, что здесь будут изложены базовые вещи, более подробная информация будет изложена во второй и последней части данной статьи.

Итак, начнем.

Привет хаброчитателям!

В предыдущей части мы рассмотрели базовые структуры, а также написали инициализацию и удаление устройства.

В данной статье мы добавим в наш драйвер функции открытия scull_open, чтения/записи scull_read/scull_write и получим первый рабочий драйвер устройства.



Хочу выразить благодарность всем пользователям, которые прочитали, лайкнули и прокомментировали мою предыдущую статью. Отдельное спасибо за уточнения Kolyuchkin и dlinyj.



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

Сразу к делу!

Добрый вечер, хаброчитатели!

В предыдущих статьях (один, два) мы определили понятие символьного устройства и написали простейший пример символьного драйвера. Последняя часть посвещена проверки его работоспособности. На Хабре уже есть примеры как можно протестировать драйвер, например: тык.

Я попытаюсь рассмотреть данный вопрос чуть подробнее, надеюсь, вам понравится.

В данной статье я рассматриваю процесс написания простого драйвера PCI устройства под OC Linux. Будет кратко изучено устройство программной модели PCI, написание собственно драйвера, тестовой пользовательской программы и запуск всей этой системы.

В качестве подопытного выступит интерфейс датчиков перемещения ЛИР940/941. Это устройство, отечественного производства, обеспечивает подключение до 4 энкодеров с помощью последовательного протокола SSI поверх физического интерфейса RS-422.

Здравствуйте, хаброчитатели!

Введение

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



Процесс переноса может занять от нескольких минут до более продолжительного промежутка времени. Зависит это не только от сложности драйвера, но и от того, с какой и на какую версию ядра вы собираетесь перейти (API имеет свойство меняться — отсюда лезут все проблемы), а также от качества реализации кода, бывает, что проще переписать, чем перенести, но об этом не будем.

К сожалению, я не могу прикрепить исходный код драйвера, но мы рассмотрим все проблемы, с которыми я и вы можете столкнуться в процессе переноса. Далее будет рассмотрен пример переноса простого драйвера c версии ядра 2.6.25 на 4.12.5, который расположен в drivers/serial/name_uart.c. Также нам очень поможет следующий ресурс 2.6.25 и 4.12.5, где можно посмотреть структуру ядра, а также исходные коды.