udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Помог совет с LOR:Числа для «ручных» режимов ЖК мониторов лучше вычислять с помощью программки cvt с параметром -r вычисленное с параметром -r значение: было съедено xrandr на вход, разрешение выставилось.Теперь думаю, как это автоматизировать для wayland и xorg при загрузке |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Установка в xorg-конфиге секции monitor приводит к незагрузке xorg. Проблема в том, что wayland ведет себя аналогично, пропадает разрешение WQHD. Откат ядра решает проблему. На обычном ядре все ломается при переходе 4.8 -> 4.9. Проблема явно не на уровне xorg вывод xrandr до обновления ядра:
после обновления:
Результат попытки выставить правильное разрешение:
|
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Дано: PC: Dell XPS 2720
В указанной выше конфигурации все отлично работает, проблем нет. Проблема: При обновлении на ядро linux-lts-4.9.13-1 при загрузке компьютера на этапе KMS выставляется разрешение FullHD, после загрузки xorg xrandr и конфигурация дисплея gnome отображает FullHD как максимальное доступное разрешение экрана. Попытка выставить разрешение вручную через xrandr ни к чему не приводит (разрешение появляется в списке, но переключение на него не происходит, картинка остается в FullHD). Также система ведет себе на новых не-lts ядрах, точно не выяснял с какого именно началась поломка. Пробовал выгрузить EDID и вручную загружать файл с ним при загрузке, ничего не дало, хотя файл подгружается, судя по dmesg. Ниже расшифровка EDID:
cvt:
Вопрос: Что делать, куда копать? :) Надеюсь на помощь сообщества. |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Gnome + полноэкранная tilda в качестве терминала на f2, привык намертво уже, маловероятно что скоро сменю. Нравится, что настройки практически не требует, весь необходимый десктопный функционал из коробки, развертывание требует минимума телодвижений. |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Введение в проблему: С некоторых пор, уже не помню с каких, из gnome-shell убрали поддержку xdg-menu категорий по кнопке "Показать приложения>все" (Show Applications>all). Сама по себе поддержка осталась, например можно получить автоматические категории с помощью стандартного расширения Applications Menu, которое замещает кнопку "Обзор" раскрывающимся списком, в котором приложения рассортированы по xdg-категориям, в соответствии с записями в desktop-файлах. Но в списке всех приложений по-прежнему останется свалка. Это не доставляет особых неудобств из-за удобного поиска и возможности вынести избранные приложения в отдельную панель, для быстрого доступа, но заставляет грустить по тем временам, когда программы сразу после установки автоматически аккуратно группировались по категориям. Работа над решением: Когда я первый раз столкнулся с этой ситуацией, я стал искать решение, пытался понять зачем поломали и что с этим теперь делать, так как, например, мои родственники в возрасте предпочитают пользоваться именно этим меню для поиска приложений. В процессе выяснения я установил, что можно решить проблему создав записи о категориях, и распределив вручную приложения через редактирование гномовского "реестра". Такое дружелюбие серьезно пошатнуло мою веру в человечество, но я стал искать дальше, в надежде найти удобный инструмент. На тот момент на роль удобного инструмента смог пригодиться только shell-скрипт aur/gnome-catgen. Он работает следующим образом: This will create (if it doesn't already exist) and open (with the editor set by $EDITOR, or vi if nothing is set) the .category file in ~/.local/share/applications-categories for the provided category name. In this file, you can now add one application's '.desktop' filename per line. After all the desired applications have been added, you can then run: gnome-catgen -s to apply your configuration. То-есть, приводит всю процедуру разделения по категориям к простой процедуре записи списка desktop-файлов в файл ~/.local/share/applications-categories/имя_категории.category и последующего запуска gnome-catgen -s. И все бы хорошо, но вручную набивать файл category для gnome-catgen не в ходило в мои планы, благо я изначально всего лишь хотел вернуть xdg-menu. Поэтому я написал для себя еще один скрипт, который "автоматизирует автоматизатор" и "упрощает упрощатор" gnome-catgen. Этим скриптом я и хотел бы поделиться, возможно кому-то он окажется полезен. Автоматизатор автоматизатора gnomenu.sh Скрипт требует для своей работы gnome-catgen, лежащий где-либо на пути, его можно получить, например, установив из aur; запускается от пользователя, для которого генерируются категории. Далее идет сам скрипт, я постарался сделать его более-менее читаемым, насколько позволяет мой скилл в bash и кривое знание английского, поправки приветствуются, хотелось бы набраться ума разума от сообщества:
Использование скрипта сводится к указанию опции -i с аргументом в виде языка, это влияет на то, на каком языке будут созданы категории, пример того что именно ждет скрипт можно посмотреть в desktop-файлах, можно указать в качестве аргумента "sys", тогда будет сделана попытка использовать системную переменную $LANG. В документации xdg сказано, что параметр локализации берется из LC_MESSAGES, но там содержится что-то вида "ru_RU.utf-8", а в файлах directory присутствует только общий "[ru]", поэтому в нехорошем стиле пришлось закостылить для "sys" вот такую гадость: Чтобы обойти несчастья, которые она могла породить скрипт работает таким образом, что в случае получения негодного аргумента для "-i" сработает выбор стандартного англоязычного варианта.Вернуть все в дефолтное гномовское состояние можно вызовом скрипта с аргументом gnomenu.sh -u, будте внимательны(!), если сами создавали категории в g(d)conf или category-файлы для gnome-catgen, скрипт выполняет gnome-catgen -x и удаляет всю папку с категориями. Надеюсь, что опус окажется кому-то полезным, ну и жду критики в том числе английского, если не затруднит:) |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Сделал дополнительную проверку, загрузил live-образ ubuntu 14.10, она вообще не нашла устройств HDMI, звука в XBox также нет. Загрузка в UEFI или Legacy роли не играет. Без загрузки ОС, при работе в BIOS звука нет (это важно). Если запустить XBox при загруженном Linux звука в XBox нет, но если после этого перезагрузиться в Windows, звук в XBox появляется. Как устроена эта кухня мне не ясно, вижу что оба HDMI устройства playback. В спецификациях и на корпусе устройства, ясное дело, один из портов помечен как IN, да и работает именно так как ожидается с загруженной ОС Microsoft. |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Ок, исправляюсь: default.pa client.conf daemon.conf system.pa
NatrioПодскажите как это можно выяснить? Судя по выводу aplay hdmi заведует Intel. Из мультимедийныйх карт в ПК также присутствует, работающая через optimus, карта nvidia 750, но, опятьже, по выводу aplay я предполагаю, что она HDMI не заведует. |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Дано: 1) Моноблок Dell XPS 2720 с HDMI-IN и HDMI-OUT разъемами 2) ОС Archlinux: 3) ОС MS Windows версии 7 (для проверки звука)4) MS XBox 360 Проверен и работает звук через встроенные динамики моноблока: 1) Звук в Archlinux, десктоп с Gnome 3 и Pulseaudio
Основное устройство вывода звука: pulseaudio2) Звук в Windows версии 7 3) Звук от XBox, подключенного по HDMI-IN, при условии что загружена ОС Windows 7 Не работает: Звук от XBox, подключенного по HDMI-IN, при условии что загружена ОС Archlinux (через динамики продолжает идти звук от PC). Хотелось бы разобраться в ситуации, но в плане устройства alsa, pulse и правил их настройки я крайне слаб. Пробовал запретить загрузку модулей snd...hdmi, толку никакого. В ~/.asoundrc выставлял устройство по-умолчанию, также без результата. Нужны помощь в решении и советы с какого конца взяться за проблему, заранее благодарен. |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
jim945Прошу прощения, не написал свое мнение по-этому вопросу сразу, действительно мое упущение. К сожалению в постах автора отсутствует четкое обоснование почему необходима 32-bit only ОС, в свою очередь его же комментарий: improovizatorвызывает подозрение, что нет четкого понимания по этому вопросу. Единственным реальным ограничителем в плане архитектуры является неподдержка ее процессорами десктопов и серверов. Из относительно современных CPU только с некоторыми Atom, если мне память не изменяет память, такая ситуация. 1) Если именно "атомные" рабочие места являются ограничителем и есть жесткое ограничение от руководства по единовременным тратам - вопросов нет, но даже в этом случае лучше Debian. По поводу замены icewaesel на firefox: a) Это не проблема b) В 99.9% случаев это не нужно, iceweasel поддерживаемый браузер, с фиксами безопасности от вполне себе серьезного поставщика. 2) Если рабочие места "атомные", но ограничения по бюджету не слишком жесткие имеет смысл собрать ферму VDI на KVM, при наличии тонких клиентов (бывших рабочих станций) стоимость внедрения может оказаться раза в 3 дешевле простой замены десктопов на что-то с x86_64, при этом резко упрощается обслуживание, повышается надежность. 3) Если рабочие станции поддерживают x86_64, но ограничителем являются внутренние предубеждения: a) У нас всего по 1-2 гигабайта ОЗУ, нам не нужна x86_64 - ошибка, с моей точки зрения, стоимость обслуживания арча на 100+ машинах перекроет покупку памяти, не говоря уж о том, что ее можно и не покупать, Linux великолепно заведется и на 1-2 при запросах: "браузер-офис", можете потестировать. b) На 64 ОС будут проблемы с проприетарными 32 битными приложениями - также ошибка в 99% случаев, ядро 64 не отменяет в современных ОС поддержку 32-приложений. Я бы посчитал стоимость поддержки решения, а также задумался о том, что будет делать работодатель, когда вам захочется от него уйти, проблема поиска человека с навыками работы с Арчем, и готового переварить все возможные самодельные или не очень системы автоматизации, которые вам захочется внедрить может оказаться значительно более финансово и трудозатратным делом, чем даже внедрение oVirt-VDI. Я не знаю всей ситуации, я просто предлагаю постараться учитывать все эти моменты, если они учтены, и вы обо всем подумали, то выбор сделан :) |
udarnik |
|
Темы:
3
Сообщения:
46
Участник с: 30 ноября 2012
|
Посмотрите все-таки в сторону centos, основные плюсы: 1) свежая версия (7) вышла недавно, пакетная база не успела устареть, значит пользовательский софт не придется сразу пересобирать. 2) работающая из коробки связь с интересными и удобными инфраструктурными серверами RH (IPA, Spacewalk), фронтенд с вебмордой, хорошо если придется обучать новичка. 3) действующие в России курсы и сертификации, значит проще будет искать специалистов. 4) возможность использовать одну платформу и пакетную базу для серверов и рабочих станций, что существенно упрощает обслуживание даже активно растущей инфраструктуры. Короче, если речь идет хотябы о 50+ инсталляций, я бы шел по пути унификации. Арч великолепный дистрибутив, но он хорош для домашних машин или разовых инсталляций под задачу, разворачивать и обслуживать на нем полноценную рабочую инфраструктуру может оказаться просто неудобно. RH (ну и centos как дочерний) позволяют сейчас построить решение практически под любую стандартную задачу, от простого офиса, до крупной серверной инсталляции с использованием широкого спектра ПО (включая проприетарное, на которое бизнес по какой-то роковой ошибке неровно дышит xD) Для офиса можно построить что-то в этом роде: IPA - общая аутентификация и политики доступа Кластеризованный NFS, можно на RH cluster suite Jenkins - автоматизация сборки ПО Spacewalk - деплой машин, поддержка жизненного цикла ПО, управление конфигурациями + вики для ведения документации |