В конечном итоге мы сделали комплексное решение, позволяющее избежать проблем с путями. В зависимости от варианта использования мы использовали одно или несколько из следующего:
PATH = ...
в этом сценарии и / или запустить исходный код $ HOME / .bashrc
в зависимости от ситуации. Это использовалось для инструментов, которым требовались другие инструменты, но которые в остальном могли работать в нашем кластере. Частичный ответ:
Я предполагаю, что это Xorg.log
является результатом запуска X-сервера с существующим xorg.conf
; если это не так, удалите свой xorg.conf
и повторите попытку.
Xorg.log
вначале выглядит нормально, в частности
[ 4.129] (II) AMDGPU(0): Output DVI-D-0 using initial mode 1920x1080 +0+0.
[ 4.129] (II) AMDGPU(0): Output DVI-D-1 using initial mode 1280x1024 +1920+0
означает, что у вас есть один фреймбуфер («рабочий стол» ), и каждый выход отображает часть фреймбуфера.
Однако это не останавливается на достигнутом, после все выглядит правильно инициализированным мы получаем
[ 4.702] (II) AMDGPU(0): EDID vendor "SAM", prod id 161
...
[ 4.817] (II) AMDGPU(0): Allocate new frame buffer 1920x1080
[ 4.817] (II) AMDGPU(0): => pitch 8192 bytes
поэтому мы получаем EDID для "SAM", который находится на "DVI -D -1", второй раз, и он выделяет для него новый фреймбуфер, и у меня есть подозрение, что этот фреймбуфер отличается от общего "настольного" фреймбуфера. Это означает, что если отображается именно этот фреймбуфер, вы можете сколько угодно менять вещи в фреймбуфере «настольного компьютера», но на «DVI -D -1» он просто отобразит другой фреймбуфер. Который, вероятно, черный, и это то, что вы видите.
Я никогда не видел ничего подобного и понятия не имею, что происходит.
Я бы отправил отчет об ошибке специалистам по сопровождению AMDGPU и посмотрел, есть ли у них идеи. Включите полный Xorg.log
.