Tak, dowiedziałem się!
Aby aktywować wyjście VIRTUAL sterownika Intel, musisz utworzyć 20-intel.conf
plik w katalogu konfiguracyjnym Xorg (w /usr/share/X11/xorg.conf.d
sekcji Debian, dowiedz się, czytając /var/log/Xorg.0.log
)
Section "Device"
Identifier "intelgpu0"
Driver "intel"
Option "VirtualHeads" "2"
EndSection
Mój /etc/bumblebee/xorg.conf.nvidia wygląda następująco:
Section "ServerLayout"
Identifier "Layout0"
Option "AutoAddDevices" "true"
Option "AutoAddGPU" "false"
EndSection
Section "Device"
Identifier "DiscreteNvidia"
Driver "nvidia"
VendorName "NVIDIA Corporation"
Option "ProbeAllGpus" "false"
Option "NoLogo" "true"
Option "AllowEmptyInitialConfiguration"
EndSection
Section "Screen"
Identifier "Screen0"
Device "DiscreteNVidia"
EndSection
Kilka wyjaśnień: potrzebuje sekcji „Ekran”, w przeciwnym razie spróbuje użyć urządzenia Intela zadeklarowanego w 20-intel.conf (które właśnie dodaliśmy wcześniej, o mój ...). Potrzebuje także „AllowEmptyInitialConfiguration”, aby móc zacząć z optirun, gdy nie jest podłączony żaden monitor zewnętrzny.
Dzięki tej konfiguracji i uruchomieniu intel-virtual-output
mogłem uzyskać dostęp do mojego portu HDMI. Yeehaa !!!
Rozwiązywanie problemów: jeśli optirun
albo intel-virtual-output
nie działa, spójrz na /var/log/Xorg.8.log
(trzmiel tworzy serwer X z wyświetlaczem: 8 stosowany wewnętrznie).
Uwagi czytałem w kilku miejscach, które KeepUnusedXServer
powinny być ustawione true
i PMMethod
do none
w /etc/bumblebee/bumblebee.conf
, ja tego nie zrobiłem i to działa dobrze. Jeśli to zrobię, to działa, ale dyskretny procesor graficzny pozostaje włączony nawet po wyjściu z optiruneded aplikacji lub zabiciu intel-virtual-output, czego nie chciałem.
Więcej notatek Coś innego, co sprawiło, że uderzyłem głową w ścianę, to dezaktywacja Nouveau i uruchomienie serwera Intel X: należy tego dokonać za pomocą flag przekazanych do jądra, określonych w parametrach GRUB. W /etc/defaults/grub
mam następującą linię:
GRUB_CMDLINE_LINUX_DEFAULT="quiet blacklist.nouveau=1 i915.modeset=1 gfxpayload=640x480 acpi_backlight=vendor acpi_osi=! acpi_osi=\"Windows 2009\""
(strzeż się cytatów i cytatów unikanych).
Kilka wyjaśnień: unika ładowania nowego (który jest niezgodny z serwerem Nvidia X) i mówi sterownikowi Intel, aby przeszedł do trybu graficznego w momencie uruchamiania. Jeśli tego nie zrobisz, serwer Intel X nie może się uruchomić i wraca do zwykłego starego serwera VESA z renderowaniem 3D po stronie procesora. Te acpi_xxx
flagi są wymagane na tej konkretnej maszynie do pokonania BIOS błąd, który sprawia, że upaść, gdy dzieje się w trybie graficznym z dyskretnym off GPU. Należy pamiętać, że jest on specyficzny dla tego konkretnego notebooka (przenośnej stacji roboczej HP ZBook), może być niepotrzebny lub różnić się w przypadku innych laptopów.
Aktualizacja (6 grudnia 2017 r.) W najnowszej dystrybucji Debiana (Buster) „915.modeset = 1 gfxpayload = 640x480” nie jest konieczne. Aby usunąć nouveau, musiałem również utworzyć plik nouveau.conf w /etc/modprobe.d z „blacklist nouveau”, a następnie ponownie utworzyć ramdysk za pomocą „update-initramfs -u”. Uruchom ponownie i upewnij się, że „nouveau” nie jest już załadowane z „lsmod | grep nouveau”.
Aktualizacja (17 grudnia 2016 r.) W przypadku najnowszego serwera xorg (1.19) wydaje się występować problem z funkcją RandR, która zarządza gamma, gdy jest używana z intel-virtual-output
. Oto procedura łatania Xservera i uruchomienia go:
sudo apt-get build-dep xserver-xorg-core
apt-get source xorg-server
edytuj hw / xfree86 / Mode / xg86RandR12.c Wiersz 1260, wstaw „return” (aby funkcja xf86RandR12CrtcComputeGamma()
nic nie robiła )
dpkg-buildpackage -rfakeroot -us -uc
cd ..
sudo dpkg -i xserver-xorg-core_n.nn.n-n_amd64.deb
(zastąp n.nn.n-n
prawidłową wersją), uruchom ponownie i Yehaa !! działa ponownie! (ale jest to szybka i brudna poprawka)
Aktualizacja zgłosiła raport o błędzie (był już znany i został właśnie naprawiony):
https://bugs.freedesktop.org/show_bug.cgi?id=99129
Jak wymyśliłem:
Zainstalowałem xserver-xorg-core-dbg
i zrobiłem gdb /usr/lib/xorg/Xorg <xorg pid>
z innej maszyny przez ssh.
Aktualizacja (11 stycznia 17) Wygląda na to, że błąd został teraz naprawiony w najnowszych pakietach Debiana.
Aktualizacja (24 stycznia 18) Jeśli chcesz podłączyć beamer do robienia prezentacji i musisz skonfigurować wszystko tuż przed rozpoczęciem (intel-virtual-output + xrandr), może to być stresujące. Oto mały skrypt, który spełnia swoje zadanie (zrzeczenie się: dużo miejsca na ulepszenia, dotyczące stylu itp.):
# beamer.sh: sets Linux display for doing a presentation,
# for bumblebee configured on a laptop that has the HDMI
# plugged on the NVidia board.
#
# Bruno Levy, Wed Jan 24 08:45:45 CET 2018
#
# Usage:
# beamer.sh widthxheight
# (default is 1024x768)
# Note: output1 and output2 are hardcoded below,
# change according to your configuration.
output1=eDP1
output2=VIRTUAL1
# Note: I think that the following command should have done
# the job, but it does not work.
# xrandr --output eDP1 --size 1024x768 --output VIRTUAL1 --size 1024x768 --same-as eDP1
# My guess: --size is not implemented with VIRTUAL devices.
# Thus I try to find a --mode that fits my needs in the list of supported modes.
wxh=$1
if [ -z "$wxh" ]; then
wxh=1024x768
fi
# Test whether intel-virtual-output is running and start it.
ivo_process=`ps axu |grep 'intel-virtual-output' |egrep -v 'grep'`
if [ -z "$ivo_process" ]; then
intel-virtual-output
sleep 3
fi
# Mode names on the primary output are simply wxh (at least on
# my configuration...)
output1_mode=$wxh
echo Using mode for $output1: $output1_mode
# Mode names on the virtual output are like: VIRTUAL1.ID-wxh
# Try to find one in the list that matches what we want.
output2_mode=`xrandr |grep $output2\\\. |grep $wxh |awk '{print $1}'`
# There can be several modes, take the first one.
output2_mode=`echo $output2_mode |awk '{print $1}'`
echo Using mode for $output2: $output2_mode
# Showtime !
xrandr --output $output1 --mode $output1_mode --output $output2 --mode $output2_mode --same-as $output1
aktualizacja (10/07/2019)
„Poprawka” dla nowej awarii: napisz w skrypcie (wywołaj bumblebee-startx.sh
na przykład):
optirun ls # to load kernel driver
/usr/lib/xorg/Xorg :8 -config /etc/bumblebee/xorg.conf.nvidia \
-configdir /etc/bumblebee/xorg.conf.d -sharevts \
-nolisten -verbose 3 -isolateDevice PCI:01:00:0 \
-modulepath /usr/lib/nvidia/nvidia,/usr/lib/xorg/modules/
(zamień PCI: nn: nn: n adresem twojej karty NVidia, uzyskanym za pomocą lspci)
Uruchom ten skrypt z okna terminalu jako root ( sudo bumblebee-startx.sh
), utrzymanie terminala Otwórz, a następnie optirun
i intel-virtual-output
działa zgodnie z oczekiwaniami (Uwaga: czasami trzeba uruchomić xrandr
dodatkowo, aby wykryć ekran / video projektor). Teraz nie rozumiem, dlaczego to samo polecenie zaczęło się od awarii trzmiela, tyle tajemnic tutaj ... (ale przynajmniej daje tymczasową poprawkę).
Jak wymyśliłem: napisałem skrypt „otoki”, aby uruchomić Xserver, zadeklarowałem go jako XorgBinary w bumblebee.conf, zmusiłem go do zapisania wiersza poleceń ($ *) w pliku, wypróbowałem kilka rzeczy obejmujących LD_PRELOAD, wstawienie łatki do XServera, aby naprawiono awarię w osLookupColor (nie działało), ale kiedy próbowałem ręcznie uruchomić ten sam wiersz poleceń, działało i działało bez mojej łatki (ale nadal nie rozumiem dlaczego).
Aktualizacja 11/15/2019
Po aktualizacji miałem dużo migotania, przez co system był bezużyteczny. Naprawiono przez dodanie parametru jądra i915.enable_psr=0
(w /etc/defaults/grub
, wtedy sudo update-grub
). Jeśli chcesz teraz, PSR oznacza „automatyczne odświeżanie panelu”, energooszczędną funkcję procesorów graficznych Intel (która może powodować migotanie ekranu).