libelf-devel ist installiert.
Mir ist auch schon aufgefallen, dass auf der Nvidia-Seite die Version 384.98 für Linux angeboten wird, jedoch gibt es im Bumblebee-Nvidia-Repo nur die 384.59-er Version. Und den Treiber aus dem Standard-Nvidia-Repo kann ich ja nicht nehmen :-/
Guten Tag allerseits,
ich hatte vor einiger Zeit dank eurer Hilfe auf meinem Lenovo E470 20H2-S007 Bumblebee zum Laufen gebracht: Schlechte Performance mit Nvidia-GPU trotz Bumblebee
Nachdem ein neuerliches Software-Update aufgespielt wurde, bricht das Kompilieren des Grafiktreibers mittels dkms beim Starten ab (ich weiß nicht mehr genau, welches). In der Datei /var/lib/dkms/nvidia/384.59-64.1/build/make.log finde ich folgende Fehlermeldungen:
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm8_ats_numa.c: In function ‘bad_idea_read_string_from_file’:
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm8_ats_numa.c:134:5: warning: passing argument 3 of ‘kernel_read’ makes integer from pointer without a cast [enabled by default]
read_count = kernel_read(filp, 0, read_buffer, read_buffer_size - 1);
^
In file included from /usr/src/linux-4.14.2-1.gb0610fc/include/linux/huge_mm.h:7:0,
from /usr/src/linux-4.14.2-1.gb0610fc/include/linux/mm.h:452,
from /var/lib/dkms/nvidia/384.59-64.1/build/common/inc/nv-pgprot.h:17,
from /var/lib/dkms/nvidia/384.59-64.1/build/common/inc/nv-linux.h:20,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm_linux.h:39,
from /var/lib/dkms/nvidia/384.59-64.1/build/common/inc/nv_uvm_interface.h:30,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm8_ats_numa.c:24:
/usr/src/linux-4.14.2-1.gb0610fc/include/linux/fs.h:2844:16: note: expected ‘size_t’ but argument is of type ‘char *’
extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm8_ats_numa.c:134:5: warning: passing argument 4 of ‘kernel_read’ makes pointer from integer without a cast [enabled by default]
read_count = kernel_read(filp, 0, read_buffer, read_buffer_size - 1);
^
In file included from /usr/src/linux-4.14.2-1.gb0610fc/include/linux/huge_mm.h:7:0,
from /usr/src/linux-4.14.2-1.gb0610fc/include/linux/mm.h:452,
from /var/lib/dkms/nvidia/384.59-64.1/build/common/inc/nv-pgprot.h:17,
from /var/lib/dkms/nvidia/384.59-64.1/build/common/inc/nv-linux.h:20,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm_linux.h:39,
from /var/lib/dkms/nvidia/384.59-64.1/build/common/inc/nv_uvm_interface.h:30,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-uvm/uvm8_ats_numa.c:24:
/usr/src/linux-4.14.2-1.gb0610fc/include/linux/fs.h:2844:16: note: expected ‘loff_t *’ but argument is of type ‘size_t’
extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^
...
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:173:5: error: unknown field ‘enable’ specified in initializer
.enable = nvidia_crtc_enable,
^
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:173:5: warning: initialization from incompatible pointer type [enabled by default]
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:173:5: warning: (near initialization for ‘nv_crtc_helper_funcs.mode_valid’) [enabled by default]
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c: In function ‘nvidia_plane_create’:
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:230:9: error: incompatible type for argument 7 of ‘drm_universal_plane_init’
);
^
In file included from /usr/src/linux-4.14.2-1.gb0610fc/include/drm/drm_crtc.h:45:0,
from /usr/src/linux-4.14.2-1.gb0610fc/include/drm/drmP.h:69,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-priv.h:30,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:27:
/usr/src/linux-4.14.2-1.gb0610fc/include/drm/drm_plane.h:548:5: note: expected ‘const uint64_t *’ but argument is of type ‘enum drm_plane_type’
int drm_universal_plane_init(struct drm_device *dev,
^
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:230:9: error: too few arguments to function ‘drm_universal_plane_init’
);
^
In file included from /usr/src/linux-4.14.2-1.gb0610fc/include/drm/drm_crtc.h:45:0,
from /usr/src/linux-4.14.2-1.gb0610fc/include/drm/drmP.h:69,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-priv.h:30,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:27:
/usr/src/linux-4.14.2-1.gb0610fc/include/drm/drm_plane.h:548:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c: In function ‘nvidia_drm_add_crtc’:
/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:360:37: error: too few arguments to function ‘drm_crtc_init_with_planes’
);
^
In file included from /usr/src/linux-4.14.2-1.gb0610fc/include/drm/drmP.h:69:0,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-priv.h:30,
from /var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.c:27:
/usr/src/linux-4.14.2-1.gb0610fc/include/drm/drm_crtc.h:899:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
/usr/src/linux-4.14.2-1.gb0610fc/scripts/Makefile.build:315: recipe for target '/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.o' failed
make[3]: *** [/var/lib/dkms/nvidia/384.59-64.1/build/nvidia-drm/nvidia-drm-crtc.o] Error 1
/usr/src/linux-4.14.2-1.gb0610fc/Makefile:1508: recipe for target '_module_/var/lib/dkms/nvidia/384.59-64.1/build' failed
make[2]: *** [_module_/var/lib/dkms/nvidia/384.59-64.1/build] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14.2-1.gb0610fc-obj/x86_64/default'
Makefile:146: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14.2-1.gb0610fc'
Makefile:81: recipe for target 'modules' failed
make: *** [modules] Error 2
Ein paar Kenndaten zu meinem System, damit ihr nicht alles im alten Thread suchen müsst: Eingebaut sind ein i7 7500U mit integrierter Intel HD Graphics 620 sowie einer separaten GTX 940MX. Es läuft Leap 42.3 mit Plasma. Der Kernel ist aus Kernel:/stable, momentan 4.14.2-1.gb0610fc-default. Eingebunden sind die folgenden Repos, ich habe auch überprüft, dass alle relevanten Pakete aus den korrekten Repos installiert sind:
Index of /repositories/X11:/Bumblebee/Kernel_stable_standard
Index of /repositories/home:/Bumblebee-Project:/nVidia:/latest/openSUSE_Leap_42.3
Index of /repositories/Kernel:/stable/standard
Optirun spuckt dann folgerichtig auch eine Fehlermeldung aus:
optirun --status
[ 3051.237136] [ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[ 3051.237194] [ERROR]Could not connect to bumblebee daemon - is it running?Ist das ein Fehler, den ich bei mir beheben kann (wenn ja, wie?), oder muss ich warten und darauf hoffen, dass ein zukünftiger Patch das behebt?
Grüße, Eldrad
Ich habe eine Vermutung, wieso der besagte Patch bei mir nicht funktioniert. Ursprünglich sendete psmouse ein "failed to get extended button data", was vom Patch abgefangen und in "button_info = 0x33" umgewandelt wurde. Jetzt steht im dmesg aber weder "failed" noch "0x33", sondern:
psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 0/0
D.h. er sendet fälschlicherweise, dass es überhaupt keine TrackPoint Buttons gibt; hiergegen hilft der besagte Patch nicht. Warum dennoch die linke und rechte TrackPoint Buttons funktionieren, ist mir schleierhaft.
Ich hab das jedenfalls auch im Kernel-Bugreport geschrieben: 196253 – Middle button on trackpoint is not detected on ThinkPad E470
Die mittlere Maustaste, die physikalisch auf dem Laptop vorhanden ist, produziert kein Signal, sie ist sozusagen tot. Ich möchte, dass das Drücken dieser Taste das Signal "mittlere Maustaste" auslöst (und z.B. den Inhalt der Zwischenablage an der Mauszeigerposition einfügt). Wie schon im Eingangspost geschrieben, zeigt xev keinen Output beim Drücken dieser Taste.
Das Signal "mittlere Maustaste" kann ich im Moment ausschließlich durch das Berühren des Touchpads mit drei Fingern gleichzeitig erreichen.
Link zum Arch Wiki gelesen?
Irgendwelche Anmerkungen dazu?
Denn die psmouse bezogenen Vorschläge stehen nur bei "Troubleshooting".......
Der Inhalt des wiki-Artikels grenzt bzw. übersteigt teilweise mein Verständnis, aber ich versuche mein bestes.
xf86-input-evdev sowie -libinput sind beide installiert. Das "Middle button scroll" brauche ich nicht unbedingt (d.h. werden die mittlere Maustaste gedrückt und der TrackPoint bewegt, wird der Bildschirm gescrollt?), aber diese Funktion sollte ohnehin "enabled by default" sein, ist es aber nicht.
Die Datei xinitrc existiert in meinem home nicht, nur ~/.xinitrc.template.
xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=13 [slave keyboard (3)]Der Absatz "Xorg configuration" befasst sich mit einer "Trackpoint Wheel Emulation", die ich nicht brauche. Ebenfalls möchte ich das tap-to-click nicht aktivieren (vermute ich richtig, dass hierdurch ein kurzes Anstupsen des roten Knubbels als Klick mit der linken Maustaste interpretiert wird?).
Auf der Grundlage meines (sehr beschränkten) Verständnisses scheint es mir, als ginge der Artikel ein wenig an meinem Problem vorbei.
Sofern es hilft, hier ein Auszug von <tt>grep "evdev" /var/log/Xorg.0.log</tt>:
[ 62.787] (II) Using input driver 'evdev' for 'TPPS/2 IBM TrackPoint'
[ 62.787] (**) evdev: TPPS/2 IBM TrackPoint: Device: "/dev/input/mouse1"
[ 62.787] (EE) evdev: TPPS/2 IBM TrackPoint: Unable to query fd: Inappropriate ioctl for device
Um eine mögliche Fehlerquelle auszuschließen, habe ich außerdem heute das BIOS nach Lenovo-Anleitung aktualisiert (von Verkaufsversion 1.4 auf aktuell 1.88), aber leider ohne spürbaren Effekt.
Der TrackPoint selbst (also der rote Knubbel) funktioniert einwandfrei, es ist die mittlere Maustaste (die manchmal wohl auch als "TrackPoint button" bezeichnet wird), die den Dienst versagt. Es gibt zahlreiche Treffer zu genau diesem Problem bei Google (für Ubuntu, Arch, Debian etc.), die alle darauf hinweisen, dass unter Windows die Taste funktioniert, aber unter Linux nicht. Sie alle enden damit, dass es einen Kernel-Patch gibt, der diesen Fehler behebt.
Die psmouse-bezogenen Vorschläge haben alle den Nachteil, dass sie die Funktionalität des Touchpads einschränken: Zoomen oder 2-Finger-Klicks gehen nicht mehr. Da ich ausschließlich das Touchpad und nie den TrackPoint verwende, ist das für mich keine Lösung.
Nachträglich noch ein Auszug aus Xorg.0.log:
egrep "WW|EE" /var/log/Xorg.0.log
[ 59.637] Current Operating System: Linux linux-maxim.suse 4.14.0-2.g1d02750-default #1 SMP PREEMPT Mon Nov 20 15:48:48 UTC 2017 (1d02750) x86_64
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 59.652] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist.
[ 59.737] (WW) Falling back to old probe method for modesetting
[ 59.779] (WW) Falling back to old probe method for fbdev
[ 59.780] (WW) Falling back to old probe method for vesa
[ 60.867] (EE) evdev: TPPS/2 IBM TrackPoint: Unable to query fd: Inappropriate ioctl for device
[ 60.896] (EE) PreInit returned 2 for "TPPS/2 IBM TrackPoint"Leider hab ich keine zielführenden Ergebnisse von google zu diesen Fehlermeldungen erhalten…
Guten Tag,
auf meinem Lenovo Thinkpad E470 mit Leap 42.3 und KDE Plasma wird die physisch vorhandene mittlere Maustaste nicht erkannt und produziert kein Signal in xev. Die 3-Finger-Berührung des Touchpads wird hingegen korrekt verarbeitet. Angeblich wurde dieser Fehler in Kernel 4.11.7 behoben ([SOLVED] ThinkPad E470: Trackpoint middle button not detected / Kernel & Hardware / Arch Linux Forums), jedoch besteht das Problem bei mir immer noch.
uname -a
Linux linux-maxim.suse 4.14.0-2.g1d02750-default #1 SMP PREEMPT Mon Nov 20 15:48:48 UTC 2017 (1d02750) x86_64 x86_64 x86_64 GNU/LinuxDen Output von dmesg hänge ich an. Hat einer eine Idee, woran das liegen könnte? Für jegliche Hilfe bei der Lösung wäre ich sehr dankbar. Zusätzliche Infos gebe ich gerne an.
Grüße, Eldrad
Falsche Prios in der Repo-Liste.
Würde ich wetten.
Teilweise richtig: Bei dkms hat tatsächlich die höhere Prio von packman reingegrätscht. Die Bumblebee-Repos hatte ich bei 99 belassen, jedoch hat Yast nicht erkannt, dass bei z.B. primus die Version 0+git2015… (Bumblebee/Kernel) neuer ist als 20131226… (Standard) – trotz erlaubtem Herstellerwechsel.
Was ich noch vergessen hatte: Sucht bumblebee im XorgModulePath auch alle Unterverzeichnisse durch? Der vollständige Pfad zu nvidia_drv.so ist nämlich /usr/lib64/nvidia/xorg/modules/updates/drivers/, was ich erst nachträglich in bumblebee.conf dazugeschrieben hatte.
Ich hatte auch gesehen, dass die meisten google-Treffer zum "fallen off the bus" auf einen Hardwarefehler hinwiesen. Da jedoch der Fehler nicht unter 42.2, sondern erst 42.3 auftrat, schloss ich das aus: Die GPU wird ja wohl kaum durch eine Installation eines OS beschädigt werden.
Lustigerweise funktioniert nun optirun. Folgendes ist passiert: Ich hatte vor ein paar Tagen in /var/lib/dkms/nvidia/kernel-4.12.11-1.gbf7fb08-default-x86_64/log/make.log folgenden Eintrag gelesen: /usr/src/linux-4.12.11-1.gbf7fb08/Makefile:946: "Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel"
Dies hatte ich installiert, aber nicht daran gedacht, dkms nochmal alle Module bauen zu lassen. Gerade eben wurde das Update auf Kernel 4.13.1 verfügbar, außerdem habe ich nochmal penibel überprüft, dass alle bumblebee-Pakete aus dem korrekten Repository installiert sind. Tatsächlich gab es einige (z.B. primus), bei denen Yast die falsche Version aus den Standard-Repos ausgewählt hatte. Nach diesem Update baute dkms alle Module neu, und siehe da: Inklusive aller unserer bisherigen Änderungsversuche funktioniert optirun glxspheres und zeichnet ein weiches Bild.
Was mich etwas wundert ist folgendes: Wenn die "VGL Compression: proxy" gesetzt ist, kriege ich nur 87 frames/s: wenn ich das in bumblebee.conf auf jpeg ändere, erhalte ich 109 fps. Eingebaut ist eine GTX 9040MX. Im Vergleich dazu hat KosstAmojan einst seinen Output gepostet (siehe Post #9), wo er mit einer älteren GTX 840M auf knapp 170fps gekommen ist:
optirun -vv glxspheres
[ 1871.910843] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[ 1871.911560] [INFO]Configured driver: nvidia
[ 1871.911894] [DEBUG]optirun version 3.2.1 starting...
[ 1871.911926] [DEBUG]Active configuration:
[ 1871.911956] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[ 1871.911994] [DEBUG] X display: :8
[ 1871.912076] [DEBUG] LD_LIBRARY_PATH: /usr/lib64/nvidia:/usr/lib/nvidia
[ 1871.912109] [DEBUG] Socket path: /var/run/bumblebee.socket
[ 1871.912128] [DEBUG] Accel/display bridge: auto
[ 1871.912143] [DEBUG] VGL Compression: jpeg
[ 1871.912175] [DEBUG] VGLrun extra options:
[ 1871.912192] [DEBUG] Primus LD Path: /usr/lib64/primus:/usr/lib/primus
[ 1871.912281] [DEBUG]Using auto-detected bridge virtualgl
[ 1872.702741] [INFO]Response: Yes. X is active.
[ 1872.702761] [INFO]Running application using virtualgl.
[ 1872.702877] [DEBUG]Process vglclient started, PID 17652.
[ 1872.702959] [DEBUG]Hiding stderr for execution of vglclient
[ 1872.706031] [DEBUG]SIGCHILD received, but wait failed with No child processes
[ 1872.706149] [DEBUG]Process vglrun started, PID 17654.
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x21
Context is Direct
OpenGL Renderer: GeForce 940MX/PCIe/SSE2
109.279828 frames/sec - 121.956288 Mpixels/sec
[ 1876.429563] [DEBUG]SIGCHILD received, but wait failed with No child processes
[ 1876.429585] [DEBUG]Socket closed.
[ 1876.429598] [DEBUG]Killing all remaining processes.Neues dmesg siehe Anhang.
Einerseits bin ich erleichtert, dass es funktioniert, andererseits kann ich nicht sagen, warum…