 | |  |
| барбос | Дата: Четверг, 16.03.2023, 00:18 | Сообщение # 1 |
|
Сержант
- Группа:Администраторы
- Сообщений:39
- Регистрация:25.07.2011
-
5
| Предисловие
Для того, чтобы завести некоторые функции в OS X (в особенности на ноутбуках), мы вынуждены прибегать к изменению DSDT и SSDT. В этом мануале мы расскажем основополагающие понятия работы с вашими оригинальными файлами ACPI.
Вы, конечно, можете использовать чужой DSDT и прочие файлы (config.plist, какие-то кастомные кексты), но это не гарантирует полноценной работоспособности, и даже наоборот приводит к непонятным, жутким, дичайшим багам. Вы банально не можете проверить происхождение этих файлов, и разобраться в них вы тоже вряд ли сможете. Любое маленькое изменение в настройках биоса, любое маленькое отличие по железу (будь то даже жёсткий диск другой модели), приводит к трагическим последствиям, вплоть до чрезмерного накала процессора, ведущего к износу компонентов железа.
Поэтому, давайте договоримся сразу – используем только оригинальные файлы, к которым причастны только производитель и мы.
Основные принципы работы с ACPI:
Основные, и в то же время эталонные принципы работы с DSDT:
Всегда использовать только оригинальные таблицы;
Нельзя брать таблицы из программ, наподобие AIDA64 или подобных, поскольку они подхватывают DSDT, который уже отредактирован загрузчиком операционной системы, а так же нельзя использовать патченный DSDT какими-либо программами, типа DSDTPatcher. Только оригинал, правленный руками, может выступать в качестве вашей основы для корректировки.
Никогда не брать чужие DSDT в сети;
Потому что даже из-за одного несовпадения значения в биосе, дсдт может работать криво, и вы не разберетесь в синтаксисе другого человека. А бед это может принести немало.
Используйте только MaciASL;
Никаких DSDTEditor, DSDTPatcher, и прочих программ. Ничего, кроме MaciASL. Актуальная версия лежит здесь.
Процесс патчинга происходит в несколько этапов:
Извлечение оригинальных файлов;
Разбор (disassembling) нативных файлов;
Анализ и фильтрация;
Патчинг;
Компилирование, и установка файлов.
Также, в статье есть несколько лайфхаков, как можно подправить некоторые вещи. Список “Якорей”:
Извлечение оригинальных файлов:
Patchmatic;
Clover (F4);
Linux.
Сборка iASL-декомпилятора через терминал;
Исправление проблемы с просыпанием компьютера.
Начинаем.
1. Извлечение оригинальных файлов.
Любой биос сообщает ACPI-таблицы операционной системе. Следовательно, их можно извлечь из любой ОС, для дальнейшей работы по корректировке файлов.
Успешное извлечение возможно в Linux, OS X, Windows, а так же с помощью Clover’а. Нативные файлы в целом идентичны, но могут иметь различные названия (в зависимости от софта). В этой статье мы сфокусируемся на трёх методах извлечения: Используя patchmatic в OS X; Используя Clover; Используя Debian-образный Linux.
Рекомендуем ознакомиться со всеми, чтобы выбрать для себя что-то наиболее подходящее.
Извлечение с помощью Patchmatic:
Если вы уже установили OS X, но вы не использовали опции загрузчика по корректировке ACPI, вы можете извлечь нативные DSDT/SSDT через patchmatic. Скачайте Patchmatic здесь: https://github.com/RehabMan/OS-X-MaciASL-patchmatic. Для большей лёгкости использования в терминале, положите копию (необходимо разархивировать) в директорию “/usr/bin”.
После установки patchmatic’а, вызывайте терминал, и вводите следующее:
Код cd ~/Desktop
mkdir extract
cd extract
patchmatic -extract
Patchmatic извлечёт все загруженные ACPI-таблицы и поместит их в прописанную директорию. Если вы использовали какие-нибудь патчи на DSDT/SSDT, то у вас будет уже не нативные файлы, которые будут непригодны для использования нами в дальнейшем. Для примера, если вы использовали ключ DropSSDT=yes (Хамелеон), или параметр DropOem=true (Клевер), нативные SSDT будут отброшены до загрузки, и вы получите совершенно другой “выхлоп”, и, как следствие, вся дальнейшая работа пойдёт насмарку. Отключите все генерации SSDT в клевере, все фиксы на DSDT, и вообще любые проявления изменения таблиц. Даже отключите дроп Cpu0lst и CpuPM.
Именно по всем этим причинам, часто легче извлекать с помощью Linux или с помощью Clover.
Извлечение с помощью Clover:
В GUI* Clover’а мы должны нажать клавишу F4, после чего клевер сохранит все OEM таблицы по пути /EFI/Clover/ACPI/origin. А так же приложит DumpLog.txt, который поможет разобраться, какие из таблиц сохранены, какую длину они имеют, и ещё много интересных вещей. Примечание: на некоторых ноутбуках функциональные клавиши срабатывают по нажатию Fn+F1-12. Следовательно, нам необходимо нажать именно Fn+F4, если на ноутбуке инверсия фн. клавиш.
Это не сработает, если диск, на котором установлен клевер, имеет файловую систему, отличную от FAT32. Говоря простым языком – у клевера должны быть права не только на чтение, но и на запись. Для нашей цели подойдёт либо клевер, установленный на ESP (EFI System Partition), либо чистая флешка, отформатированная в FAT32 (В OS X эта файловая система называется MS-DOS FAT), на которую установлен клевер.
Время от времени, клевер грешит тем, что дублирует SSDT. Эти дубликаты могут создать проблемы для дизассемблирования. Мы просто сверяем все таблицы, и избавляемся от дубликатов. В этом плане, мне больше нравится использовать Linux, так как я никогда не видел, чтобы Linux показывал дубликаты SSDT.
Извлечение через Linux:
В Linux’е нативные файлы просто лежат на жёстком диске по путям /sys/firmware/acpi/tables и /sys/firmware/acpi/tables/dynamic. Просто идите и заберите их на флешку, скиньте себе архивом, или заберите их на OS X любыми другими способами!
Для этого даже не нужно устанавливать Linux, можно просто воспользоваться live-загрузкой: http://www.ubuntu.com/download/desktop
2. Дизассемблирование ACPI-файлов.
Хотя извлеченные родные файлы могут быть открыты непосредственно в MaciASL, это не рекомендуется. Открытие файла .aml непосредственно в MaciASL заставит MaciASL разобрать файл, и сделать его автономным. И, если .aml имеет упоминания других .aml, он неправильно его разберёт. Из-за чего вы будете мучатся, исправляя кучу ошибок. Особенно сильно это касается синтаксиса.
Как результат, лучше разобрать все файлы в виде группы с помощью iASL в Терминале. Подготовим файлы: соберите все DSDT и SSDT файлы в одной папке (не копируйте ACPI файлы, которые не начинаются с DSDT или SSDT), и измените имена, таким образом, чтобы они имели .aml расширение (если это не так). Вам понадобится последняя версия iASL, чтобы правильно их разобрать, которая лежит здесь: https://bitbucket.org/RehabMan/acpica/downloads. Вы можете положить iASL так, чтобы был быстрый доступ из терминала (Опять же, ZIP в /usr/bin).
В терминале OS X:
cd "путь к папке, куда вы положили DSDT и SSDT файлы"
iasl -da -dl *.aml
Примечание: Не пытайтесь разобрать другие ACPI файлы с помощью флага “-da“. Это банально не будет работать.
Новая версия iASL в конечном итоге будут доступна по ссылке на Bitbucket выше, но для тех, кто хочет быть на 'передовой'...
Примечание: Вы так же можете собрать последнюю версию iASL из гитхаба RehabMan’а. Для этого должен быть установлен Xcode:
cd ~/Documents
git clone https://github.com/RehabMan/Intel-iasl.git iasl.git
cd iasl.git
make
После чего, вы уже можете его установить:
sudo make install
С этого момента, вы будете работать исключительно с вытекающими *.dsl файлами при помощи MaciASL. Конечно, чтобы использовать их необходимо сохранить как “ACPI Machine Language Binary” с расширением .aml, и разместить их, где они будут загружены клевером (~/EFI/Clover/ACPI/patched). Но, мы рекомендуем иметь исправленные файлы .dsl, на случай необходимости изменить что-либо в будущем.
Позвольте мне заявить довольно понятным языком (потому что это самая частая ошибка, которая происходит из-за невнимательности, и после чего приходит много жалоб): Если вы открываете файл .aml непосредственно в MaciASL, и нажимаете “Compile”, вы делаете это НЕПРАВИЛЬНО. Пусть это сохранится в вашем сером веществе между ушами в течение минуты. (Оригинальная мысль автора сохранена).
Дизассемблирование refs.txt.
Иногда бывают дополнительные обращения к внешним названиям (названия, которые находятся в таблице, отличной от DSDT/SSDT). iASL дизассемблер будет пытаться к ним обратиться, но это далеко не всегда срабатывает. Вы можете исправить это, предоставляя компилятору информацию о них в текстовом файле. К примеру, вот некоторые внешние названия (будь то метод, или девайс): SGPO, ECRD, ECWT, и MMTB.
Для начала создайте файл refs.txt в той же папке, где лежат ваши DSDT/SSDT файлы, с следующим содержимым:
Код External(_SB_.PCI0.PEG0.PEGP.SGPO, MethodObj, 2)
External(_SB_.PCI0.LPCB.H_EC.ECWT, MethodObj, 2)
External(_SB_.PCI0.LPCB.H_EC.ECRD, MethodObj, 1)
External(_GPE.MMTB, MethodObj, 0)
После чего мы его сохраняем, и дизассемблируем, подобно тому, что мы делали во втором пункте:
В терминале OS X:
Код iasl -da -dl -fe refs.txt *.aml
iASL дизассемблер будет учитывать эти обращения к внешним таблицам для всего кода. В то же время, это не есть хорошо. Большую часть времени вам необходимо будет таскать внешние файлы за собой, вместо того, чтобы они были просто частью кода. Это станет очевидно, как только вы получите ошибку от внешнего обращения к файлу, который отсутствует в refs.txt.
3. Фильтрация ACPI файлов.
Для старых компьютеров (Sandy Bridge и старее), SSDT, связанные с CPU, могут вызвать проблемы. Если дело обстоит именно так (подразумевается, что вы уже попробовали альтернативные методы дропа таблиц), то вы не должны оставлять такие SSDT в ~/ACPI/patched.
Я бы включил все SSDT в их первоначальном виде, и патчить их надлежащим образом, если известно, что они не вызывают проблем.
Примечание: таблицы с пометкой “X” для клевера, а так же таблицы, взятые из папки динамических таблиц в Linux, являются динамичными таблицами, которые являются изменёнными в процессе загрузки (и из-за других параметров). Такие таблицы никогда не кладутся в ~/ACPI/patched!
После того как вы успешно дизассемблировали свои файлы, рассмотрим каждый из них, в попытке определить роль того или иного SSDT. Если это SSDT процессора, которые, как известно, любят вызывать проблемы, откиньте их в сторону, и не кладите их в свой окончательный набор для инжекции через загрузчик. По большей части, SSDT, которые имеют в оглавлении “_PR.CPUx”, и есть SSDT процессора.
Вот типичные SSDT, которые вы можете найти:
CPU: уже обсуждалось выше. Включить в набор, если проблем не возникает.
SATA: можете включить, а можете и не включать. На ваш выбор.
PTID: обычно этот файл бесполезен OS X, и, к тому же, содержит много ошибок. В редких случаях (например, на ноутбуках Acer и HP), это может дать информацию системе, как читать скорость вентилятора, температуру, и другие датчики.
IAOE: Если это SSDT присутствует, то он, как правило, является выходцем из DSDT (метод _WAK). Без него сон может не работать, или работать кривым образом.
GFX0: Обычно SSDT с GFX0 существует для интегрированной графики. Этот SSDT вы патчите для контроля подсветки. На старых ноутбуках, GFX0 обычно находится в DSDT. А в ноутбуках Haswell и выше, она обычно находится в SSDT (хотя она также может быть и в DSDT).
PEGP: PEGP обычно существует для дискретной карты в конфигурациях с двумя GPU. Таких SSDT может быть более одного, и обычно вы должны будете включить всю группу, чтобы достигнуть каких-либо значимых исправлений. Эти SSDT должны быть исправлены, если вы хотите отключить дискретную карту при запуске OS X.
Остальные SSDT следует рассматривать в отдельности. Если, конечно, они вам встретились.
Как мне кажется, было бы неплохо вести заметки о том, какие SSDT вам нужно дропнуть, какие SSDT вам нужно модифицировать, а какие SSDT вам нужно оставить неизменными.
4. Исправление ошибок (Патчинг).
Даже когда вы дизассемблировали все таблицы сразу (iASL с флагом -da), оригинальные файлы по-прежнему могут содержать ошибки. В дизассемблированном состоянии файлы имеют ошибки, связанные с изменениями в самом iASL (обновления), недостатками в iASL, и различии в компиляции среды между нашими компьютерами и производителем. Распространенной причиной ошибок (согласно моей теории), например, в том, что некоторые из упомянутых методов, на самом деле, существуют только внутри Windows (Например, MMTB и MDBG (их, кстати, можно смело удалять, если вы не планируете использовать эти таблицы и для Windows)). Также существуют случаи, когда были допущены ошибки в коде, или же код был написан умышленно неправильно (иногда трудно отличить).
Так что… После определения того, какие файлы вам нужны, вы должны исправить их, чтобы они скомпилировались без ошибок. Есть много общих патчей для таких ошибок, в репозиториях патчей для MaciASL.
MaciASL: https://osxpc.ru/downloads/programs/maciasl/
Репозитории: https://osxpc.ru/articles/osxpc-repo/
Примечание: Мы не проверяем патчи с помощью DSDT Editor. Он имеет слишком много ошибок, и очень старую версию iASL. Пожалуйста, не спрашивайте нас и RehabMan’а об этом.
Чтобы быть уверенным, всегда читайте README, чтобы загружать из правильного места, и для того, чтобы настройки MaciASL были правильными. Патчи для задач синтаксисических ошибок начинаются с “[syn]” в названии. Типичные примеры для старых DSDT: “Fix _PLD Buffer/Package Error”, “Fix TNOT Error”, and “Fix FPED Parse Error”. Для того чтобы определить, какие патчи вам нужны, вы можете посмотреть на сообщение об ошибке, поступающей из iASL компилятора, и кода, на какой линии была обнаружена ошибка. Вы можете также попытаться применить патч, чтобы посмотреть, вносит ли он изменения, как показано в окне предварительного просмотра в MaciASL. Если вы не знакомы с ошибками, это может занять некоторое время, полное экспериментов, проб и ошибок.
Для некоторых ошибок, вы можете просто удалить строку кода, вызвавшего ошибку. Но это зависит от того, является ли строчка необходимой для правильной работы кода, или нет. Например, ошибки, причиной которых являются “внешние” (“External”) параметры, решаются удалением строки.
Эти занятия помогают приобрести опыт в ACPI-спецификациях, и просто опыт программирования. А нынче, этот опыт очень полезен, согласитесь
Ваша цель – получить каждый файл .dsl, в котором не будет ошибок (Предупреждения/примечания/оптимизации приемлемы. Тем не менее, исправить предупреждения, всё-таки желательно.). Если у вас есть файлы, которые компилируются без ошибок, вы можете переходить к патчингу. А после патчинга, вы можете повторно установить OS X, с грамотными таблицами. И, как следствие, с грамотным NVRAM-переменными, и прочими прелестями.
Дополнительные сведения о патчинге.
Минимальные фиксы.
Как правило, DSDT патч применяется только после выявления его необходимой пользы. Но есть несколько патчей, которые необходимы по дефолту, и, обычно, не вызывают никаких проблем. Они находятся в репоизтории перечислены здесь:
Fix _WAK Arg0 v2;
HPET Fix;
SMBUS Fix;
IRQ Fix;
RTC Fix;
*Очень сильно любит делать вид, что патч необходим, хотя нет отличий между Before и After в меню патчинга. Будьте внимательны.
OS Check Fix;
*Не имеет ничего общего с версией Windows. Изучите описание, которое прилагается в MaciASL, а после решите – нужен ли вам патч.
Fix Mutex with non-zero SyncLevel;
Fix PNOT/PPNT;
*Используется только при дропе CPU SSDT.
Add IMEI.
Проблема с моментальным пробуждением.
Проблема с сном:
Патчи на USB убирают просыпания после секунды сна, если в консоли присутствует сообщение “Wake Reason: USB”, “Wake Reason: EHC1/2”, или же “Wake Reason: XHC”. Если у вас есть такая же проблема, но проблема не в USB, то попробуйте применить это:
Если вы испытываете проблемы с пробуждением компьютера или ноутбука, воспользуйтесь следующим методом:
Откройте DSDT, нажимаете cmd+f, и в поиске ищите “_PRW”;
Ищите его в устройстве, которое вызывает пробуждение. Пусть это будет XHC. Вот кусок кода:
Код Device (XHC)
{
Name (_ADR, 0x00140000) // _ADR: Address
OperationRegion (XPRT, PCI_Config, Zero, 0x0100)
Field (XPRT, AnyAcc, NoLock, Preserve)
{
DVID, 16,
Offset (0x40),
, 11,
SWAI, 1,
Offset (0x44),
, 12,
SAIP, 2,
Offset (0x48),
Offset (0x74),
D0D3, 2,
Offset (0x75),
PMEE, 1,
, 6,
PMES, 1,
Offset (0xA8),
, 13,
MW13, 1,
MW14, 1,
Offset (0xAC),
Offset (0xB0),
, 13,
MB13, 1,
MB14, 1,
Offset (0xB4),
Offset (0xD0),
PR2, 32,
PR2M, 32,
PR3, 32,
PR3M, 32
}
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x6D, 0x03))
}
Method (_DSW, 3, NotSerialized) // _DSW: Device Sleep Wake
{
Store (Arg0, PMEE)
}
И меняем это
Код Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x6D, 0x03))
}
На это:
Код Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x6D,
Zero
})
И получаем это
Код Device (XHC)
{
Name (_ADR, 0x00140000) // _ADR: Address
OperationRegion (XPRT, PCI_Config, Zero, 0x0100)
Field (XPRT, AnyAcc, NoLock, Preserve)
{
DVID, 16,
Offset (0x40),
, 11,
SWAI, 1,
Offset (0x44),
, 12,
SAIP, 2,
Offset (0x48),
Offset (0x74),
D0D3, 2,
Offset (0x75),
PMEE, 1,
, 6,
PMES, 1,
Offset (0xA8),
, 13,
MW13, 1,
MW14, 1,
Offset (0xAC),
Offset (0xB0),
, 13,
MB13, 1,
MB14, 1,
Offset (0xB4),
Offset (0xD0),
PR2, 32,
PR2M, 32,
PR3, 32,
PR3M, 32
}
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x6D,
Zero
})
Method (_DSW, 3, NotSerialized) // _DSW: Device Sleep Wake
{
Store (Arg0, PMEE)
}
И так проделать со всеми устройствами, что пробуждают компьютер.
Работа с USB.
Следующие патчи используйте только в соответствии с вашим железом:
6-series USB
7-series/8-series USB
Мультиплекс-патч на USB3 исправляет работу AppleUSBXHCI.kext, чтобы не прибегать к использованию GenericUSBXHCI.kext. Он основан на информации, опубликованной Mieze. Большинство DSDT нуждаются в этом патче. А так же, ProBook, например, использует модифицированную версию этого патча. А вот Lenovo U310/U410 может использовать его как есть. Ах, да. Имя патчу: “7-series USB3 Multiplex“.
Если вы используете GenericUSBXHCI.kext на 10.10, убедитесь, что вы используете только его. Кроме того, чтобы избежать мгновенного пробуждения, вам может понадобиться флаг ядра ‘-gux_defer_usb2′.
Чипсет.
На хасвелле существуют некоторые проблемы с подгрузкой AppleLPC.kext. Если у вас в загруженных кекстах нет AppleLPC, то примените этот патч: “Haswell LPC”
Немного о переименовании.
Переименовывание должно быть “сбалансированным”. То есть, переименование должно быть в равной степени как в DSDT, так и в SSDT. А так же это нужно, чтобы лучше соответствовать требованиям OS X (пример “Rename GFX0 to IGPU” для правильного управления питанием IGPU). В этом случае, во всех DSDT/SSDT, где есть ссылки на это имя, также должны быть переименованы.
Информация относительно идентификаторов дубликатов.
Вы должны быть уверены, что ваши патченные файлы не содержат дубликатов. Общим правилом можно считать добавление метода _DSM в один из SSDT, где производитель определил _DSM в другой SSDT. Чтобы избежать этой проблемы, можно использовать патч “Remove _DSM methods”, в качестве одного из самых первых патчей, который вы применяете для всех DSDT/SSDT.
Исправления конкретных проблем.
Скоро будет перевод статей, а пока:
Статус батареи: https://www.tonymacx86.com/threads/guide-how-to-pat...y-status.116102/
Настройка яркости: https://www.tonymacx86.com/threads/guide-patching-d...-control.152659/
Отключение nVidia/Radeon на ноутбуках: https://www.tonymacx86.com/threads/guide-disabling-...-laptops.163772/
Примите во внимание!
Многие патчи образуют синергию с config’ом и кекстами, а по одиночке не имеют никакого смысла.
Патчи для AppleHDA.
С патченным AppleHDA, есть два момента, которые необходимо соблюсти:
IRQ Fix;
Audio Layout 12.
5. Компиляция и установка файлов.
Использование файлов загрузчиком.
Для того, чтобы использовать свои патченные DSDT/SSDT файлы, необходимо сохранить в то место, откуда их подхватит загрузчик, и начнёт подгружать. Файлы должны быть сохранены в “ACPI Machine Language Binary” (MaciASL -> Сохранить как…). Сохранение файла .dsl с расширением .aml просто вызвает панику, или же очень странное поведение OS X.
Clover: сохраняем наши .dsl в .aml, и подкладываем все нужные файлы по пути ~/EFI/CLOVER/ACPI/patched. Клевер подхватит все .aml файлы, которые лежат по этому пути (начиная с версии 3062).
Для SSDT очень важен порядок в цифрах в названии. То есть, SSDT-1.aml, после всех изменений, должен быть именно SSDT-1.aml, а SSDT-5.aml – SSDT-5.aml. Это необходимо, потому что патченные файлы заменяют те, что подхватываются из биоса. Если назвать неправильно, то произойдёт дубляж одного и того же SSDT, что неминуемо приведёт к панике ядра.
В то же время, для DSDT порядок несколько иной – имя файла DSDT, который необходимо подхватывать, должен быть указан в config.plist, по пути Config.plist/ACPI/DSDT/Name, тип значения “string”. К тому же, можно положить несколько DSDT с разными именами, например DSDT.aml, DSDT-original.aml, DSDT-test.aml, и прямо из GUI выбирать, с каким DSDT нужно загрузиться. Это удобно для тестов: если что-то пошло не так, можно просто взять и поменять название на один из лежащих вариантов, или же вообще загрузить оригинальный, указав имя BIOS.aml.
Примечание: если указано неверное имя, будет грузиться оригинальный DSDT, взятый из биоса.
“Плавающие” регионы.
В ACPI есть такая вещь, как регионы-операторы (Например: MMIO-регион, SystemMemory регион, EmbeddedControl регион, и т.д.). Эти регионы имеют фиксированные адреса, которые зависят только от компьютера, модели биоса, и настроек биоса. Малейшее изменение этих регионов приводит к краху весь дсдт, и как итог мы имеем паники, или неправильно работающую OS X. Это и называется “плавающие” регионы.
Так, исправляя DSDT/SSDT, мы делаем снимок этих адресов в тот момент, когда мы снимали таблицы. Они не могут совпасть, если вы меняли параметры биоса, меняли компоненты железа, и производили подобные операции. Такие регионы останутся, но будут доступны по другому адресу. Если это так, то вы заметите, что некоторые вещи начинают работать криво, или возникают другие проблемы со стабильностью. Которые, к слову, кажутся случайностью.
Чтобы избежать этого, нам необходимо использовать фикс клевера “Fix_Regions”, который сравнивает регионы при каждой загрузке, и, при несовпадении, исправляет. Находится этот фикс рядом с остальными фиксами DSDT, а именно: Config.plist/ACPI/DSDT/Fixes.
Вот только с SSDT таких хитростей пока что не придумано. Лечения, следовательно, тоже нет. Единственное, что хочется отметить – регионы в SSDT не так сильно играют роль в поведении OS X, из-за чего сильного удара по юзабилити не предвидится. А исследования методов исправления выходит далеко за рамки этого мануала.
|
|
