Вероятно, у вас (или была )общесистемная -установка RVM. Это может быть связано с установкой его через систему пакетов, такую как apt -get в Ubuntu или pacman в Arch Linux (оба имеют пакеты rvm ).
Проверьте переменные среды:
> env | grep rvm_path
Если он у вас есть, то сбросьте его и попробуйте установить заново:
> unset rvm_path
> curl -sSL https://get.rvm.io | bash -s stable
ОСТОРОЖНО! Если у вас все еще установлен rvm в системе -, это может привести к непредсказуемым результатам, убедитесь, что вы удалили его, прежде чем делать это.
Если он уже удален, а путь rvm _все еще существует, возможно, вы можете выйти из системы и войти снова, чтобы удалить их из среды (или просто перезагрузите компьютер ).
Это выглядит примерно так (не соответствует масштабу)
┌───────────────────────────────────────────────┐
│ User │
│ ┌─────────────────────────────────────────┤
│ │ Application │
│ │ ┌──────────┬─────┬─────┬─────┤
│ │ │ ... │ SDL │ GTK │ QT │
│ │ ├──────────┴─────┴─────┴─────┤
│ │ │ xLib │
│ │ ├────────────────────────────┤
├─────┴───┬────────┴──┐ X11 │
│ Gnu │ Libraries │ Server │
│ Tools │ │ │
├─────────┘ │ │
├─────────────────────┤ │
│ Linux (kernel) │ │
├─────────────────────┴─────────────────────────┤
│ Hardware │
└───────────────────────────────────────────────┘
Из диаграммы видно, что X11 общается в основном с железом. Однако ему нужно общаться через ядро, чтобы изначально получить доступ к этому оборудованию.
Я немного не уверен в деталях (и думаю, что они изменились с тех пор, как я в последний раз изучал ). Существует устройство /dev/mem
, которое дает доступ ко всей памяти (Я думаю, что это физическая память ), так как большая часть графического оборудования отображается в память, этот файл (видит все, это файл )может использоваться для доступа к нему. X11 откроет файл (ядро использует права доступа к файлу, чтобы увидеть, может ли оно это сделать ), затем X11 использует mmap
для отображения файла в виртуальную память (сделать его похожим на память ), теперь память похожа на память. После mmap
ядро не участвует.
X11 необходимо знать о различном графическом оборудовании, так как он обращается к нему напрямую, через память.
(это может иметь изменения, в частности модель безопасности, может больше не давать доступ ко ВСЕЙ памяти.)
Внизу Linux (ядро ):небольшая часть системы. Он обеспечивает доступ к оборудованию и обеспечивает безопасность.
Затем Gnu (Библиотеки; удар; инструменты :лс и т. д.; Компилятор C и т. д. ). Большая часть операционной системы.
Затем X11 (Или Wayland, или... ), базовая подсистема GUI. Это выполняется в пользовательской -земле (вне ядра ):это просто еще один процесс с некоторыми привилегиями. Ядро не вмешивается, кроме предоставления доступа к оборудованию. И обеспечение связи между процессами -, чтобы другие процессы могли взаимодействовать с сервером X11.
Простая абстракция, позволяющая писать код для X11.
Следующими идут такие библиотеки, как qt, gtk, sdl — они упрощают использование X11 и работу в других системах, таких как wayland, Microsoft Windows или MacOS.
Приложения размещаются поверх библиотек.
Использование xlib — хороший способ узнать о X11. Однако сначала почитайте о X11.
SDL предоставит вам низкоуровневый доступ, прямой доступ к битовым -плоскостям, чтобы вы могли напрямую рисовать на них.
Если вы хотите опуститься ниже, то я не уверен, какие есть хорошие текущие варианты, но вот несколько идей.
https://en.wikipedia.org/wiki/X_Window_System
Написание этого вызвало у меня интерес, поэтому я взглянул на современный быстрый способ сделать это. Вот несколько ссылок:
https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/
В SunOS 5 была библиотека DGA, которая обеспечивала независимый от устройства доступ к различным графическим адаптерам cg[3,6,14], TCX или LEO, что также поддерживало DOOM на машинах SPARC.
cg6 был 8-битным, обычно использовался в X11 как визуальный псевдоцвет, но он также мог обеспечить 8-битный истинный цвет, в то время как tcx и leo — это 24-битный ускоренный буфер кадров 3D-дисплея (псевдоцвет = байт в видеораме индекс в большую таблицу, которая дает значение RGB 3x8, содержимое таблицы может быть легко изменено. )У cg3 была примерно такая же способность, но она не была ускорена (Разработчики cg6 основали впоследствии другую фирму... nVidia.)
Более поздние устройства, такие как PGX, основанный на наборе микросхем ATI Rage Pro, не могли одновременно поддерживать истинный и псевдоцвет, как это делали более ранние устройства. Это заставляло пользователя выбирать между старыми приложениями, написанными для модели псевдоцвета (, или обновлять программное обеспечение, если это возможно ), и запускать только приложения, ориентированные на истинный цвет.
Псевдоцвет существовал в основном потому, что то, что было видеорамой, было ужасно дорогим в середине 80-х до 1992 года или около того. Цветной дисплей, который поддерживал приемлемое для рабочих станций разрешение, также был довольно дорогим (. Черно-белый Sun 2 1984 года имел разрешение 1152x864, в то время как MG1 1989 года или около того имел разрешение 1600x1280, но черно-белое.)
Я пишу это, потому что хочу показать различные требования, которые должен был поддерживать X11.
Я бы настоятельно рекомендовал начать с ncurses .
В отличие от более сложных графических систем, он основан исключительно на тексте,так что нет необходимости увязнуть в деталях драйверов экрана и графических библиотек. Однако основные принципы размещения окон на экране, перемещения фокуса между окнами и т. д. остаются в силе. И вы все еще можете рисовать на уровне блоков отдельных символов и изображений ASCII.
Конечно, вы все еще строите это поверх библиотеки, но это библиотека, которую вы можете легко понять. И более того, это библиотека, исходный код которой находится в свободном доступе, довольно хорошо документирован и не слишком непонятен, если вы хотите его прочитать. Вы даже можете изменить его самостоятельно, если хотите. Или вы можете просмотреть все библиотечные функции, чтобы найти, каким должен быть API, и написать его самостоятельно с нуля на основе этого дизайна.
ctrl -alt -ответ Делора дает вам хороший обзор общей архитектуры. Для более подробного -подхода я даю вам ответ относительно «ничего, кроме ядра Linux и программирования на C».
Мне нравится время от времени записывать прямо в буфер кадра -. Драйвер буферного устройства кадра -выполнит за вас всю утомительную процедуру закрытия -к -аппаратному обеспечению -«как это в конечном итоге окажется на экране». Вы можете сделать это сразу с помощью корневой оболочки :
.echo -n -e '\x00\x00\xFF' > /dev/fb0
Он устанавливает красный цвет для самого первого (верхнего левого )пикселя в моем 32-битном фреймбуфере:
Вы можете полностью сделать это изнутри C, открыв /dev/fb0 и записав байты. Картирование памяти может стать вашим другом. Это работает только без X-сервера или в виртуальной консоли.Нажмите Ctrl+Alt+F1, чтобы получить к нему доступ.
PS :Визуализация случайных данных, таких как движения мыши, тоже может быть интересной:
cat /dev/input/mouse0 > /dev/fb0
PPS :Также обратите внимание, что практически любое настольное приложение реального -мира требует более прямого доступа к оборудованию для некоторых причудливых вещей, таких как аппаратное ускорение для рисования, 3D и рендеринга видео. Простое буферное устройство кадра -не справляется со всем этим.