Warum braucht dieser PC Root-Rechte für clinfo?

[linuxnutzer]

Es geht um den Befehl:

clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u

$ clinfo -v
clinfo version 3.0.25.02.14

Dieser funktioniert bisher mit allen PC als User.

1 PC zeigt da aber nur unter root was an.

Vermutlich kann man die Fragestellung auf clinfo reduzieren.

~$ clinfo
Number of platforms                               0

ICD loader properties
  ICD loader Name                                 OpenCL ICD Loader
  ICD loader Vendor                               OCL Icd free software
  ICD loader Version                              2.3.4
  ICD loader Profile                              OpenCL 3.0

$ zeigt also, wird als User abgefragt.

$ sudo clinfo
Number of platforms                               1
  Platform Name                                   Intel(R) OpenCL Graphics
  Platform Vendor                                 Intel(R) Corporation
  Platform Version                                OpenCL 3.0
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_byte_addressable_store cl_khr_device_uuid cl_khr_fp16 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_icd cl_khr_icd_unloadable
...
und viel mehr

Der PC hat ein aktiviertes root-Konto, sollte aber egal sein.

Das hat auch nichts geändert:

~# apt purge clinfo
...
Entfernen von clinfo (3.0.25.02.14-1build1) ...


~# apt install clinfo
Installiere:                               
  clinfo

Zusammenfassung:
  Aktualisiere: 0, Installiere: 1, Entferne: 0, Aktualisiere nicht: 0

 

[madmax2010]

vermutlich werden dateien dazu gelesen, die dein user nicht lesen kann

schau doch nach

strace -f -e trace=%file -o /tmp/clinfo.trace \
sh -c "clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u"

Ergänzung (18. September 2026)

zum leicheren lesen vllt noch

awk -F'"' '/open(at|at2)?\(/ && / = [0-9]+/ {print $2}' /tmp/clinfo.trace |
sort -u |
while IFS= read -r file; do
if [ -e "$file" ]; then
stat -Lc '%A %a %U:%G %n' -- "$file"
fi
done

 

[linuxnutzer]

schau doch nach

Das geht über meine Kenntnisse hinaus. Ich glaube es ist einfacher, wir schränken das auf clinfo ein. Wenn die Ausgabe lang ist, passt es, sonst nicht.

Du forderst mich schon wieder mit awk, das ist mir leider zu kompliziert.

Ich musste der Datei .txt verpassen, sonst kann ich es nicht anhängen.

Ergänzung (18. September 2026)

Ich erinnere mich, dass ich mit der Grafik-Karten-Installation schon mal Merkwürdigkeiten hatte.

Ich hatte clinfo testweise gleich nach der Ubuntu-Installation installiert. Normal sollte das kein Problem sein.

Mir ist schon mehrmals passiert, dass der Grafiktreiber mit darktable nicht richtig funktioniert, wenn ich nicht davor meine "anderen" Pakete installiere. Die clinfo-Version macht aber nicht den Unterschied.

# https://dgpu-docs.intel.com/driver/client/overview.html

sudo add-apt-repository -y ppa:kobuk-team/intel-graphics
sudo apt update

sudo apt-get install -y libze-intel-gpu1 libze1 intel-metrics-discovery intel-opencl-icd clinfo intel-gsc
sudo apt-get install -y intel-media-va-driver-non-free libmfx-gen1 libvpl2 libvpl-tools libva-glx2 va-driver-all vainfo

Ergänzung (18. September 2026)

Ich habe eine Tendenz einfach nochmal neu zu installieren, ist sowieso so gut wie nichts konfiguriert und dann die Reihenfolge meiner Checklist für die Installation einzuhalten. Wenn clinfo dann noch immer ein Rechte-Problem hat, wird es spannend.

 

[madmax2010]

Du forderst mich schon wieder mit awk, das ist mir leider zu kompliziert.

einfach copy paste

 

[linuxnutzer]

@madmax2010 Mir ist aber nicht klar, ob ich da einfach ein | dazwischen geben muss und im Zweifel bin ich vorsichtig.

Mir ist folgendes aufgefallen, in meiner Checklist ist clinfo gelistet, dh wird von den Ubuntu-Quellen installiert. Das Kobuk-Repo enthält auch ein clinfo.

Dort wo es ohne root funktioniert, wird clinfo von Ubuntu verwendet. Dort wo es nicht funktioniert, kann ich nicht mehr nachschauen, weil schon die Installation formatiert wurde. Ein wenig dauert es die Crypto-Partitionen einzurichten. Ich gebe Bescheid, ob es nun funktioniert.

 

[linuxnutzer]

Also die Neuinstallation hat nichts gebracht.

https://blueprints.launchpad.net/~kobuk-team/+archive/ubuntu/intel-graphics-testing
Sollte es da ein eigenes clinfo geben? Vielleicht habe ich clinfo bei der Paketliste nur vorsichtshalber dazu geschrieben

Gleiches Verhalten wie davor. Mit root-Rechten zeigt clinfo "viel" an, als User nur ein paar Zeilen.

Was auffällt, in der Mitte des Schirms, ist die Darstellung ein wenig versetzt, ein Screenshot speichert das aber nicht. Das war am anderen PC mit der gleichen Grafikkarte genauso, ist aber mit der Installation des Intel-Treibers verschwunden. Jetzt ist es nach der Intel-Treiber-Installation nicht verschwunden.

Idealerweise sollte man als User wie beim anderen PC sehen:

$ clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u

  Device Name                                     Intel(R) Arc(TM) B580 Graphics
  Device Version                                  OpenCL 3.0 NEO
  Platform Name                                   Intel(R) OpenCL Graphics

Darktable friert immer mit der Maus ein. Die Maus ist ganz rechts in der Mitte unbeweglich. Wenn man mit Alt+F4 schließt, bewegt sich die Maus wieder normal.

Am Problem-PC mit Root-Rechten:

~# clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u
  Device Name                                     Intel(R) Arc(TM) B580 Graphics
  Device Version                                  OpenCL 3.0 NEO
  Platform Name                                   Intel(R) OpenCL Graphics

Sollte eigentlich passen, aber:

Wie prüfe ich ob der Intel-Treiber korrekt installiert ist und ein User den prop. Treiber nutzen kann. Jedenfalls ist die Maus vorher bei Darktable nicht eingefroren.

~# inxi -G
Graphics:
  Device-1: Intel Battlemage G21 [Arc B580] driver: xe v: kernel
  Device-2: Advanced Micro Devices [AMD/ATI] Granite Ridge [Radeon Graphics]
    driver: amdgpu v: kernel
  Display: unspecified server: X.org v: 1.21.1.22 with: Xwayland v: 24.1.10
    driver: X: loaded: amdgpu,modesetting unloaded: fbdev,vesa
    dri: radeonsi,iris gpu: xe,amdgpu tty: 80x24
  API: EGL v: 1.5 drivers: iris,radeonsi,swrast
    platforms: gbm,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: mesa v: 26.0.8-1ubuntu0.3
    note: console (EGL sourced) renderer: AMD Ryzen 9 9900X 12-Core Processor
    (radeonsi raphael_mendocino ACO DRM 3.64 7.0.0-31-generic), Mesa Intel
    Arc B580 Graphics (BMG G21), llvmpipe (LLVM 21.1.8 256 bits)
  API: Vulkan v: 1.4.341 drivers: radv,intel,llvmpipe surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: xfce4-display-settings wl: swaymsg x11: xdriinfo, xdpyinfo, xprop,
    xrandr

 

[Marco01_809]

Ist es denn die gleiche Distribution auf den Rechnern?

Vergleiche mal die Nutzergruppen auf einem PC wo es geht und dem wo es nicht geht mit dem Befehl id.
Und die Rechte der GPU-Devices wären auch interessant: ls -lAR /dev/dri/

EDIT: Das zeigt übrigens auch dein strace log

32349 openat(AT_FDCWD, "/dev/dri/by-path", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
32349 openat(AT_FDCWD, "/dev/dri/by-path/pci-0000:11:00.0-render", O_RDWR|O_CLOEXEC <unfinished ...>
32349 <... openat resumed>) = -1 EACCES (Keine Berechtigung)
32349 openat(AT_FDCWD, "/dev/dri/by-path/pci-0000:03:00.0-render", O_RDWR|O_CLOEXEC) = -1 EACCES (Keine Berechtigung)

Zugriff auf die GPU-Geräte ist clinfo bzw. deinem Nutzer nicht erlaubt.

Neuinstallieren von Paketen ist übrigens weitgehend Unsinn. Das würde nur dann etwas bewirken wenn man selber in /usr (außer /usr/local) rumgepfuscht hätte, was man nie tun sollte.

 

[linuxnutzer]

Ist es denn die gleiche Distribution auf den Rechnern?

Eigentlich ja

~# cat /etc/issue
Ubuntu 26.04.1 LTS \n \l

Bei den 2 PCs mit den Intel-Grafikkarten installiert mit xubuntu-26.04.1-desktop-amd64

Andere PCs (Nvidia, Onboard-Grafik) installiert mit xubuntu-26.04-desktop-amd64 und dann Updates. Vielleicht einer mit .1 dabei

Bei diesem PC funktioniert es:

Intel 1:

# ls -lAR /dev/dri/
/dev/dri/:
total 0
drwxr-xr-x 2 root root        140 Sep 19 11:59 by-path
crw-rw----+1 root video  226,   1 Sep 19 11:59 card1
crw-rw----+1 root video  226,   2 Sep 19 11:59 card2
crw-rw----+1 root render 226, 128 Sep 19 11:59 renderD128
crw-rw----+1 root render 226, 129 Sep 19 11:59 renderD129

/dev/dri/by-path:
total 0
lrwxrwxrwx+1 root root  8 Sep 19 11:59 pci-0000:03:00.0-card -> ../card1
lrwxrwxrwx 1 root root  8 Sep 19 11:59 pci-0000:03:00.0-platform-simple-framebuffer.0-card -> ../card0
lrwxrwxrwx+1 root root 13 Sep 19 11:59 pci-0000:03:00.0-render -> ../renderD128
lrwxrwxrwx+1 root root  8 Sep 19 11:59 pci-0000:11:00.0-card -> ../card2
lrwxrwxrwx+1 root root 13 Sep 19 11:59 pci-0000:11:00.0-render -> ../renderD129

Bei diesem PC darunter "Intel 2" funktioniert es nicht:

Intel 2:

# ls -lAR /dev/dri/
/dev/dri/:
total 0
drwxr-xr-x 2 root root        120 Sep 19 12:04 by-path
crw-rw----+1 root video  226,   0 Sep 19 12:04 card0
crw-rw----+1 root video  226,   1 Sep 19 12:04 card1
crw-rw----+1 root render 226, 128 Sep 19 12:04 renderD128
crw-rw----+1 root render 226, 129 Sep 19 12:04 renderD129

/dev/dri/by-path:
total 0
lrwxrwxrwx+1 root root  8 Sep 19 12:04 pci-0000:03:00.0-card -> ../card0
lrwxrwxrwx+1 root root 13 Sep 19 12:04 pci-0000:03:00.0-render -> ../renderD128
lrwxrwxrwx+1 root root  8 Sep 19 12:04 pci-0000:11:00.0-card -> ../card1
lrwxrwxrwx+1 root root 13 Sep 19 12:04 pci-0000:11:00.0-render -> ../renderD129

Und hier noch 2 mit Nvidia, die funktionieren als User:

Nvidia1:

# ls -lAR /dev/dri/
/dev/dri/:
total 0
drwxr-xr-x 2 root root         80 Sep 19 11:57 by-path
crw-rw----+1 root video  226,   1 Sep 19 11:59 card1
crw-rw----+1 root render 226, 128 Sep 19 11:59 renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx+1 root root  8 Sep 19 11:57 pci-0000:2d:00.0-card -> ../card1
lrwxrwxrwx+1 root root 13 Sep 19 11:57 pci-0000:2d:00.0-render -> ../renderD128

Nvidia2:

# ls -lAR /dev/dri/
/dev/dri/:
total 0
drwxr-xr-x 2 root root        100 Sep 19 11:58 by-path
crw-rw----+1 root video  226,   1 Sep 19 11:58 card1
crw-rw----+1 root render 226, 128 Sep 19 11:58 renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx+1 root root  8 Sep 19 11:58 pci-0000:01:00.0-card -> ../card1
lrwxrwxrwx 1 root root  8 Sep 19 11:57 pci-0000:01:00.0-platform-simple-framebuffer.0-card -> ../card0
lrwxrwxrwx+1 root root 13 Sep 19 11:58 pci-0000:01:00.0-render -> ../renderD128

Ergänzung (19. September 2026)

Neuinstallieren von Paketen ist übrigens weitgehend Unsinn.

Die Idee war, dass das clinfo ein anderes sein könnte, weil es beim Intel-Repo dabei steht.

 

[Marco01_809]

Die Dateirechte sehen so aus wie sie aussehen sollten. clinfo will auf die renderD* Geräte zugreifen, diese sind beschreibbar von root und der Gruppe render.

Wie sieht die Ausgabe von id als Nutzer auf beiden PCs aus? Ich vermute der Nutzer auf dem PC2 ist einfach nicht Mitglied in der render Gruppe.

Die Gruppe sollte der Nutzer der während der Distri-Installation angelegt wird eigentlich automatisch bekommen haben.

Die Idee war, dass das clinfo ein anderes sein könnte, weil es beim Intel-Repo dabei steht.

Ah, das ist natürlich nicht unmöglich, wenn die Version des Pakets in beiden Repos die gleiche ist.

 

[linuxnutzer]

Wie sieht die Ausgabe von id als Nutzer auf beiden PCs aus?

Ich bin mir nicht sicher, ob ich verstehe, was du meinst.

id zeigt bei beiden nichts zu render und ist ident.

 cat /etc/group | grep render
render:x:990:

bei beiden ident

 

[madmax2010]

ist aber nicht klar, ob ich da einfach ein | dazwischen geben muss und im Zweifel bin ich vorsichtig.

Du musst es kopieren wie ich es getippt habe

 

[Marco01_809]

id zeigt bei beiden nichts zu render und ist ident.

Ah bin tatsächlich nicht auf dem aktuellen Stand; (modernes) Ubuntu nutzt nicht die render Gruppe um dem Nutzer Zugriff zu gewähren. Stattdessen gibt es wohl einen Mechanismus über systemd/logind/udevd bei dem der aktuelle interaktiv eingeloggte Nutzer in die ACL der Gerätedateien hinzugefügt wird.

crw-rw----+1 root render 226, 128 Sep 19 12:04 renderD128
crw-rw----+1 root render 226, 129 Sep 19 12:04 renderD129

Das + habe ich tatsächlich übersehen. Das bedeutet die Datei hat noch erweiterte Zugriffsregeln.

Lasse dir diese mal auf beiden PCs mit getfacl /dev/dri/renderDxxx anzeigen.

 

[linuxnutzer]

Intel 1 (funktioniert)

$ getfacl /dev/dri/renderD128
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:ab:rw-
group::rw-
mask::rw-
other::---

$ getfacl /dev/dri/renderD129
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dri/renderD129
# owner: root
# group: render
user::rw-
user:ab:rw-
group::rw-
mask::rw-
other::---



Intel 2 (funktioniert nicht)

$ getfacl /dev/dri/renderD128
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:lightdm:rw-
group::rw-
mask::rw-
other::---

$ getfacl /dev/dri/renderD129
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dri/renderD129
# owner: root
# group: render
user::rw-
user:lightdm:rw-
group::rw-
mask::rw-
other::---

Da gibt es also schon entscheidende Unterschiede. User ab, ist der, der clinfo ausführt.

Ergänzung (19. September 2026)

Du musst es kopieren wie ich es getippt habe

Der Kobold ist die Erwartungshaltung, ich ging davon aus, dass das ein Einzeiler werden soll. Aber ich glaube die bessere Lesbarkeit hat sich mittlerweile erübrigt.

 

[linuxnutzer]

PC mit Nvidia 1:

$ getfacl /dev/dri/renderD128
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:lightdm:rw-
group::rw-
mask::rw-
other::---

Da ist also auch lightdm, aber hier funktioniert es.

 

[linuxnutzer]

Familien-PC mit anderer Asrock Intel Arc B580 Challenger 12GB OC funktioniert (anderer Standort, kein ssh-Zugriff
)
Diese Asrock Challenger spielt hier verrückt. Gleiche Distri installiert mit Point-Release 1.
Allerdings andere CPU

Intel 3:
$ clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u
Device Name Intel(R) Arc(TM) B580 Graphics
Device Version OpenCL 3.0 NEO
Platform Name Intel(R) OpenCL Graphics

getfacl kann ich wegen Erkrankung nicht mehr liefern, wir fürchten Corona hat zugeschlagen.

 

[foofoobar]

zum leicheren lesen vllt noch

awk -F'"' '/open(at|at2)?\(/ && / = [0-9]+/ {print $2}' /tmp/clinfo.trace |
sort -u |
while IFS= read -r file; do
   if [ -e "$file" ]; then
       stat -Lc '%A %a %U:%G %n' -- "$file"
   fi
done

Ich biete: (Not tested)

awk -F'"' '/open(at|at2)?\(/ && / = [0-9]+/ {print $2}' /tmp/clinfo.trace | sort -u | xargs ls -ld

bzw:

awk -F'"' '/open(at|at2)?\(/ && / = [0-9]+/ {print $2}' /tmp/clinfo.trace | sort -u | xargs ls -ldH

 

[linuxnutzer]

Bringt die Ausgabe von awk noch was? Ich glaube awk und ich werden in diesem Leben nicht mehr Freunde.

Familien-PC mit anderer Asrock Intel Arc B580 Challenger 12GB OC funktioniert (anderer Standort, kein ssh-Zugriff
)

Ich habe jetzt zur Challenger bekommen, wo es funktioniert:

Intel 3

$ getfacl /dev/dri/renderD128
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:ec:rw-
group::rw-
mask::rw-

Das ist also eine Variante ohne lightdm. Von 3 Intel Karte mit gleichem Chip funktioniert immer nur die Variante ohne lightdm.

 

[Marco01_809]

Grafikkarten-Hersteller, Mainboard und CPU sind hier alle irrelevant.

Intel 1 (funktioniert)

$ getfacl /dev/dri/renderD128
user:ab:rw-

Intel 2 (funktioniert nicht)

$ getfacl /dev/dri/renderD128
user:lightdm:rw-

Bist du auf Intel 1 auf dem Desktop eingeloggt und auf Intel 2 greifst du nur über SSH zu?

lightdm ist der grafische Anmeldebildschirm und daher der "Besitzer" der Grafikkarte bevor sich ein richtiger Nutzer anmeldet.

Der Mechanismus den ich hier beschrieb

Stattdessen gibt es wohl einen Mechanismus über systemd/logind/udevd bei dem der aktuelle interaktiv eingeloggte Nutzer in die ACL der Gerätedateien hinzugefügt wird.

greift ausdrücklich nur für den Nutzer, der einen interaktiven seat hat, d.h. an Tastatur und Bildschirm vor dem Gerät sitzt. Dann triggert die udev Regel, lightdm wird aus der ACL geschmissen und stattdessen dein Nutzer hinzugefügt.

Das Einloggen über SSH ist kein seat in dem Sinne, und befugt daher nicht zum Nutzen der Grafikkarte.

Dieser Mechanismus ist insofern hässlich dass er nicht nur eben diese grafische Sitzung zum Zugriff befugt, sondern wenn du eine grafische Sitzung hast, dann wird gleich dein ganzer Nutzer befugt, so dass DANN auch der Zugriff über eine SSH-Sitzung funktioniert.

Der Workaround ist einfach die traditionelle render Gruppe zu benutzen. Mitglieder dieser Gruppe haben bedingungslos Zugriff auf die Grafikkarten: sudo adduser ab render, neu einloggen und es wird laufen.

 

[linuxnutzer]

Bist du auf Intel 1 auf dem Desktop eingeloggt und auf Intel 2 greifst du nur über SSH zu?

Intel1: als User angemeldet, funktioniert
Intel2: via ssh, funktioniert nicht
Intel3; als User angemeldet, funktioniert

Nvidia1: via ssh, funktioniert!
Nvidia2: via ssh, funktioniert!

Das Einloggen über SSH ist kein seat in dem Sinne, und befugt daher nicht zum Nutzen der Grafikkarte.

Wie geschrieben, mit 2 Nvidia-PCs kein Problem.

wenn du eine grafische Sitzung hast, dann wird gleich dein ganzer Nutzer befugt, so dass DANN auch der Zugriff über eine SSH-Sitzung funktioniert.

Das ist insofern blöd, weil dann mein Script via ssh nicht funktioniert. Aber letztlich ist das Problem, dass bei Darktable die Maus einfriert. Das kann natürlich eine ganz andere Ursache haben. Darktable funktioniert aber mit Intel 1 und 3, immer die gleiche Version. Bei Darktable muss man immer aufpassen, dass opencl funktioniert, das kann eine Herausforderung sein.

Der Workaround ist einfach die traditionelle render Gruppe zu benutzen. Mitglieder dieser Gruppe haben bedingungslos Zugriff auf die Grafikkarten: sudo adduser ab render, neu einloggen und es wird laufen.

Probiere ich aus, muss dazu den PC mit Intel2 grundsätzlich einschalten und dorthin gehen. Das kann etwas dauern. Ich gebe Feedback ASAP.

Das brennendste Problem ist aber das Einfrieren der Maus mit Darktable, wollte das vorher mit clinfo geklärt haben. Bei darktable ist der User angemeldet.

Rechts in der Mitte ist die Maus eingeforeren. Über Tastatur-Kürzel Darktable geschlossen und die Maus funktioniert wieder. Die Maus friert immer an der selben Stelle ein und ist beim Starten eher auf der linken Seite.

Ergänzung (20. September 2026)

Funktioniert jetzt mit Intel 2:

clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u

# Intel 2:

$ clinfo | grep -E 'Platform Name|Device Name|Device Version|OpenCL Version' | sort -u
  Device Name                                     Intel(R) Arc(TM) B580 Graphics
  Device Version                                  OpenCL 3.0 NEO
  Platform Name                                   Intel(R) OpenCL Graphics

Soweit ich das jetzt verstehe hat das nichts mit dem Einfrieren der Maus zu tun, da ja mit Darktable ein User angmeldet war.

Soll ich für das Mausproblem einen eigenen Thread machen?

Ergänzung (20. September 2026)

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0db0:cd0e Micro Star International USB Audio
Bus 001 Device 004: ID 0db0:0076 Micro Star International MYSTIC LIGHT
Bus 001 Device 005: ID 0489:e10a Foxconn / Hon Hai
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 05e3:0620 Genesys Logic, Inc. GL3523 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 007 Device 003: ID 046a:c099 CHERRY Stream Keyboard TKL
Bus 007 Device 004: ID 046d:c050 Logitech, Inc. RX 250 Optical Mouse

Ist also eine stinknormale alte Logitech RX 250 Maus. Macht es Sinn eine andere Maus zu besorgen?

 

[linuxnutzer]

Ich glaube das Einfrieren der Maus, braucht man nicht analysieren. Es funktioniert mit einer anderen Maus.