Eigenbau-Kern 6.1 und X (gelöst)

[fischig]

Im Zusammenhang mit dem bookworm-upgrade habe ich den Kern 6.1 aus den Quellen von kernel.org auf der Basis eines laufenden 5.10er Eigenbau-Kerns kompiliert. Der Kern bootet einschließlich X. Aber er zeigt unter X keine Tastaturreaktion. Ohne X funktioniert die Tastatur, mit dem 5.10er auch unter X. Wo könnte man ansetzen, um den Fehler zu finden?

[KP97]

Hm, bei mir läuft der 6.1.33 problemlos, aber Du könntest mal schauen, was in der menuconfig bei Input Device Drivers unter keyboard alles aktiv ist.
Sonst wüßte ich im Kernel keine weitere Stelle, die die Tastatur steuert.
Dann evtl. noch im Repo schauen, ob eins von den Paketen xserver-xorg-input-evdev xserver-xorg-input-kbd oder xserver-xorg-input-libinput installiert ist.
Es gibt auch noch xserver-xorg-legacy, aber ich denke nicht, daß das notwendig ist.
Sonst auch mal eine xorg.conf verwenden, auch wenn man die nicht unbedingt braucht. Schaden tuts aber auch nicht.

[fischig]

Ich bin noch dran, aber bisher habe ich den Fehler nicht gefunden. An fehlenden Paketen kann's doch eigentlich nicht liegen, wenn ein 5.10er funktioniert - oder? Ich hatte 6.1.32. Den habe ich jetzt ersetzt durch 33 und kompiliere neu. Unter keyboards ist in menuconfig nur AT-keyboard aktiviert. Unter den übrigen nicht aktivierten Optionen erkenne ich aber nichts, was außerdem nötig sein könnte. Eine xorg.conf existierte und ist auch aktiv.

[letzter3]

die oldconfig mit deiner neuen config vergleichen?

[KP97]

Hier ein Ausschnitt aus meiner config:

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y

Zum Test könntest Du auch mal ganz ohne xorg.conf starten, ob sich dann was ändert.
Steht was in journalctl oder in xorg.0.log?

Nachtrag:
Eh Du weitermachst, es gibt den 6.1.34

[baeuchlein]

Ich hab' jetzt auch mal einen Kernel 6.1.32 mit gleicher Konfiguration wie ein 5.15.27er gebaut und unter Debian 11.7 genutzt. Tatsächlich ändert sich da was an den Meldungen in Xorg.0.log, und zwar bezüglich der Tastatur.

Ich habe eine Tastatur mit USB-Anschluss, die unter X.Org mit dem "evdev"-Treiber genutzt wird. Dafür wird mit Kernel 6.1.32 ein alter Eintrag, der eigentlich für eine PS/2-Tastatur auf einem anderen Rechner da war und aus Versehen noch in die xorg.conf-Datei 'rein kam, genutzt. Der Eintrag gibt als Device-Namen /dev/input/event3 an. Mit Kernel 6.1.32 landet dort auch meine Tastatur und wird von diesem Treiber-Eintrag aktiviert. Ein zweiter Eintrag speziell für diese eine USB-Tastatur, der den "evdev"-Treiber, aber mit dem Device-Namen /dev/input/by-id/usb-LIZHI_Flash_IC_Trust_Keyboard-event-kbd, benutzt, wird mit "device file is duplicate. Ignoring." verworfen.

Mit Kernel 5.15.27 findet sich die Tastatur aber bei /dev/input/event4, so dass der erste Eintrag sie nicht mehr findet. Nun greift aber der zweite Eintrag und aktiviert die Tastatur. Offenbar wurde im 6er-Kernel etwas geändert, so dass die Tastatur bei jenen "/dev/input/eventX"-Bezeichnungen nun eine andere Nummer kriegt. Hätte ich diesen zweiten Eintrag nicht, würde wohl unter X die Tastatur ausfallen. Ist mir Schnarchnase aber all die Monate bis Jahre nicht aufgefallen...

Ein Blick in die Xorg.0.log-Dateien bei verschiedenen Kernels sowie einen eventuellen Blick in xorg.conf (v.a. bezüglich der Tastatur-Konfiguration und insbesondere einer etwaigen Device-Angabe) wäre hier wohl anzuraten. In den Kernel-Meldungen von 5.15.27 und 6.1.32 habe ich hingegen keinen Unterschied bei den tastaturbezogenen Meldungen gesehen.

[fischig]

Vielen Dank für dein Interesse!

Mit Kernel 5.15.27 findet sich die Tastatur aber bei /dev/input/event4

So auch hier (5.10)
Ich hatte alle „events“ mit 6.1 durchprobiert. Keine Besserung. Den Rest deines Beitrag versteh' ich leider nicht. Aber ich vermute, du hast jetzt eine auch unter X funktionierende Tastatur. Mit welcher Konfiguration in xorg.conf ist mir aber nicht klar, weil ich den Rest deines Beitrag leider nicht verstehe.

Machst du was mit „by-id“? Das klingt für mich nach udev. Das wäre mein nächster Versuch. Ohne xorg.conf läuft X auf dieser alten Maschine (TP x31, radeon) überhaupt nicht.

[baeuchlein]

Ja, ich habe eine funktionierende Tastatur unter X. Tatsächlich wird dieser Text auf ihr getippt.

Auch ich komme ohne xorg.conf nicht aus, daher habe ich eine ziemlich ausführliche. Ich hab' jetzt mal die für dieses Thema nicht relevanten Dinge 'rausgeschmissen, und dann bleibt Folgendes von dieser xorg.conf übrig:

Code: Alles auswählen

# PS/2 Keyboard
Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "evdev"
        Option          "Device"        "/dev/input/event3"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "de"
        Option          "XkbVariant"    "nodeadkeys"
EndSection


# Trust USB Keyboard
Section "InputDevice"
        Identifier      "Trust USB Keyboard"
        Driver          "evdev"
        Option          "Device"        "/dev/input/by-id/usb-LIZHI_Flash_IC_Trust_Keyboard-event-kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "de"
        Option          "XkbVariant"    "nodeadkeys"
EndSection


# ServerLayout for a framebuffer (driver: "fbdev") with monitor capable of
# 1024x768 @ 60 Hz.
Section "ServerLayout"
        Identifier      "1024x768_framebuffer"
        Screen          "1024x768@60Hz and framebuffer"
        InputDevice     "Generic Keyboard"
        InputDevice     "Trust USB Keyboard"
        InputDevice     "Serial Mouse"
EndSection

Der mit "# PS/2 Keyboard" beginnende erste Abschnitt wurde ursprünglich für eine Tastatur am PS/2-Anschluss eines anderen Mainboards geschrieben und nicht entfernt, obwohl er im jetzt benutzten Rechner mangels PS/2-Tastatur zunächst mal unnötig ist. Der Eintrag für das "Device" ist

Code: Alles auswählen

        Option          "Device"        "/dev/input/event3"

d.h. es wird nachgesehen, ob als dieses "Device" eine Tastatur zu finden ist. Ist das so, dann wird sie über diesen ersten Abschnitt für X.Org genutzt. Früher war an /dev/input/event3 mal jene ursprüngliche PS/2-Tastatur im anderen Rechner zu finden. Jetzt ist je nach Kernel-Version dort die USB-Tastatur zu finden, oder aber der PC-Lautsprecher. (Warum der bei "input" auftaucht, weiß ich aber auch nicht.) Letzterer wird von X im späteren Verlauf ignoriert, weil er dann als "keine Tastatur" erkannt wird.


Der zweite, mit "# Trust USB Keyboard" beginnende Abschnitt wurde speziell für die jetzt benutzte USB-Tastatur der Firma "Trust" von mir geschrieben. Das Gedönse mit den je nach Kernel wechselnden Geräten an /dev/input/event3 (u.ä.) war mir zu doof, und als ich zufällig mal 'rausfand, dass diese USB-Tastatur stets mit demselben "Device-File" (nämlich "usb-LIZHI_Flash_IC_Trust_Keyboard-event-kbd") in /dev/input/by-id erscheint, schrieb ich eben diesen Abschnitt. Sonst hätte ich für neue Kernel-Versionen immer wieder neue Einträge schreiben müssen. Mit

Code: Alles auswählen

        Option          "Device"        "/dev/input/by-id/usb-LIZHI_Flash_IC_Trust_Keyboard-event-kbd"

war das nicht nötig.

Ich vergaß allerdings, den Eintrag für "/dev/input/event3" aus dem ersten Abschnitt dann 'rauszuschmeißen.


Der dritte, mit '# ServerLayout for a framebuffer (driver: "fbdev") ...' beginnende Abschnitt enthält u.a. zwei Zeilen, die Tastatur-Einträge betreffen:

Code: Alles auswählen

        InputDevice     "Generic Keyboard"
        InputDevice     "Trust USB Keyboard"

Damit wird versucht, jede Tastatur, die durch die beiden anderen Abschnitte gefunden wird, auch unter X.Org zu benutzen. An jenem Rechner, der eine Tastatur am PS/2-Anschluss hatte, wurde dann als "Generic Keyboard" diese PS/2-Tastatur "gefunden", sowie durch den zweiten Abschnitt die USB-Tastatur. Ich konnte beide zugleich anschließen und benutzen.

Am aktuellen Rechner wird vom ersten Abschnitt als "Generic Keyboard" die USB-Tastatur gefunden, wenn sie (durch den Kernel) über /dev/input/event3 ansprechbar ist. Der zweite Abschnitt findet dieselbe Tastatur nochmal. X merkt aber, dass es sich um dieselbe Tastatur handelt, und wirft den im zweiten Abschnitt geladenen Treiber wieder 'raus. Der für "Generic Keyboard" hingegen bleibt.

Ist dagegen auf dem aktuellen Rechner die USB-Tastatur woanders als bei /dev/input/event3 zu finden, dann entdeckt der erste Abschnitt als "Generic Keyboard" keine Tastatur. Der zweite Abschnitt findet die USB-Tastatur, und da sie diesmal nicht bereits als "Generic Keyboard" gefunden wurde, benutzt X.Org nun den zweiten Abschnitt.

Wodurch das "Device-File" namens /dev/input/by-id/usb-LIZHI_Flash_IC_Trust_Keyboard-event-kbd entsteht, weiß ich nicht. Vielleicht macht udev das, vielleicht auch der Kernel - keine Ahnung. Ich weiß nur, dass es normalerweise eben da ist und eindeutig jene USB-Tastatur von Trust findet, oder eben gar keine. An udev habe ich nie 'rumgefummelt, es müsste also irgendwelche Default-Einstellungen haben. Ob die relevant sind, weiß ich auch nicht, und was ich bisher über udev in Internet & man-pages nachgelesen habe, raff' ich auch nicht. Alles nur böhmische Dörfer.


Im dritten Abschnitt werden alle Tastaturen, die über einen Eintrag für ein "Input Device", das im dritten Abschnitt steht und vorher auch in einem eigenen Abschnitt gefunden wurde, für den X-Server genutzt. Dasselbe würde auch für mehrere Maus-Einträge u.ä. gelten.


Dass der erste Abschnitt je nach Kernel-Version mal 'ne Tastatur findet und mal nicht, liegt daran, dass er als "Device File" fest auf /dev/input/event3 eingestellt ist. Lässt der Kernel die USB-Tastatur bei diesem "Device File" erscheinen, dann findet der erste Abschnitt die als "Generic Keyboard", sonst nicht. Das ist das, was die verschiedenen Kernels bei mir unterschiedlich machen.

Über den zweiten Abschnitt findet X die USB-Tastatur immer, doch wenn X sie über den ersten Abschnitt schon vorher findet, wird der zweite Abschnitt ignoriert.


Wenn du also Einträge hast, die auf /dev/input/event3 o.ä. verweisen, kann das je nach Kernel funktionieren oder nicht. Findest du dagegen einen passenden Eintrag für deine Tastatur im Verzeichnis /dev/input/by-id, dann müsste der weitgehend kernel-unabhängig sein.

Warum dein X mal die Tastatur findet und mal nicht, kannst du vermutlich durch Vergleich der Dateien Xorg.0.log für a) X mit Kernel 5.10 und b) X mit Kernel 6.1.x herauskriegen. Dann kannst du hoffentlich sehen, ob ein geänderter Eintrag für das "Device File" (/dev/input/...) dein Problem löst.


Ich hoffe, es ist nun etwas klarer geworden, was ich meine.

[KP97]

Nachdem @bäuchlein seine Konfiguration ausführlich geschildert hat, habe ich mal eine Übersicht meiner Geräte und Einstellungen angehängt.
Ich bevorzuge schon lange die Treiber "kbd" und "mouse", da diese sehr zuverlässig funktionieren und auch das Xorg.0.log übersichtlich halten.
Ich habe die wesentlichen Einträge kopiert, aber viel mehr steht auch nicht in der config, also hier:
41920
Vielleicht kannst Du damit ja was anfangen, die Parameter für den Kernel hast Du ja schon gesehen.

[baeuchlein]

Der Tastaturtreiber "kbd" von X funktionierte bei mir auch lange Zeit über gut, bis er 2018 mal so richtig Probleme machte. Die gingen los, weil ich eine alte serielle Maus verwendete, und dafür muss in der xorg.conf die automatosche Hardwareerkennung abgeschaltet sein. Ansonsten findet X diese alten Nager bei mir nicht.

Nach dem Abschalten war die Maus dann da, aber X fand dafür dann die Tastatur nicht mehr. Aus Meldungen in Xorg.0.log entnahm ich damals, dass sie unter /dev/input/event3 von udev hinzugefügt wurde. Also teilte ich dem kbd-Treiber ebendieses "Device file" in der X-Konfiguration mit - und er wählte stattdessen die Maus als "Tastatur" aus. Entsprechend kam als "Tastendrücke" nur Unsinn 'raus. "evdev" hingegen lief mit dieser Einstellung. Seitdem gab es keinen Grund für mich, zu "kbd" zurück zu wechseln.

Vermutlich ist "kbd" zumindest auf jenem Rechner damals auf die automatische Hardwareerkennung angewiesen gewesen, die ich abstellen musste.

"mouse" funktioniert hingegen bei mir mit diversen Mäusen (seriell, USB, PS/2) bislang ohne Probleme, und solange sich das nicht ändert, benutz' ich ihn auch schön weiter.

[fischig]

Ich denke, die Ursache habe ich gefunden, wie schon (wegen /dev/input/by-id) vermutet: debian-udev.
Ich versuche dieses System ohne systemd und udev zu betreiben. Für udev hatte ich mir unter bullseye einen equivs-dummy gebaut. Nachdem ich jetzt das originale bookworm-udev installiert habe, wird die Tastatur auch mit Kern 6.1 erkannt - ohne xorg.conf. Ich werde mal schauen, ob ich durch den Bau eines neuen udev-dummies auch mit dem Kern 6.1 unter bookworm wieder auf udev verzichten kann.

Meine Kern-config unterschied und unterscheidet sich an der von KP97 zitierten Stelle nicht von ihrer.
Original-udev schreibt hier aber kein Verzeichnis by-id unter /dev/input, sondern by-path (wegen fehlendem systemd?). Mal schauen, was der neue dummy macht. Der alte hatte nichts in /dev/input geschrieben.

[baeuchlein]

Bei mir (unter Debian 11 mit systemd und udev) sind unter /dev/input sowohl by-id als auch by-path vorhanden. Für by-path ist also nicht (oder nicht allein) das fehlende systemd verantwortlich, sonst müsste by-path bei mir ja fehlen.

[fischig]

Für by-path ist also nicht (oder nicht allein) das fehlende systemd verantwortlich

Bleibt halt die Frage, warum udev (nicht der dummy) bei mir kein by-id generiert. Ist aber nicht so wichtig, ich hätt's sowieso gern ohne udev. Ob mein Wissen dafür ausreicht, oder ob ich's herausfinde, wird sich zeigen. Jedenfalls danke für den (indirekten) Hinweis auf udev.

[fischig]

Mit neuem equivs-dummy für udev unter bookworm bin ich gescheitert. Ich sehe z.Z. keine Möglichkeit mit Linux-Kernel 6.1 unter X auf udev zu verzichten. Andererseits bookworm-X funktioniert unter bookworm mit selbstgebautem 5.10 und equivs-dummy für udev.

[fischig]

Die Fehlfunktion dürfte vielleicht eher bei X als beim Eigenbau-Kern zu suchen sein.
Momentan stellt sich für mich die Frage so: Warum findet X in bookworm mit xorg.conf und ohne udev mit Eigenbau-Kern 6.1 keine Tastatur, mit Eigenbau- Kern 5.10 (auf dessen Basis 6.1 gebaut wurde) aber wohl, während die Maus unter X mit beiden Kernen funktioniert?

installiert sind diese X-Pakete: xserver-xorg, xserver-xorg-core, xserver-xorg-input-all, xserver-xorg-input-evdev, xserver-xorg-input-libinput, xserver-xorg-video-radeon

Xorg.0.log

[fischig]

Kann es sein, dass hier ein Bug vorliegt?

Nochmal: Im Prinzip funktionert das System mit dem Eigenbaukern 6.1, /etc/X11/xorg.conf und udev-dummy. Unter X gibt's Maus-Funktion, aber keine Tastatur. Auf der Konsole geht Maus und Tastatur.

installierte x-Pakete:

Code: Alles auswählen

$ dpkg -l | grep xserver-xorg
ii  xserver-xorg                     1:7.7+23                                i386         X.Org X server
ii  xserver-xorg-core                2:21.1.7-3                              i386         Xorg X server - core server
ii  xserver-xorg-input-all           1:7.7+23                                i386         X.Org X server -- input driver metapackage
ii  xserver-xorg-input-evdev         1:2.10.6-2+b1                           i386         X.Org X server -- evdev input driver
ii  xserver-xorg-input-libinput      1.2.1-1+b1                              i386         X.Org X server -- libinput input driver
ii  xserver-xorg-legacy              2:21.1.7-3                              i386         setuid root Xorg server wrapper
ii  xserver-xorg-video-radeon        1:19.1.0-3                              i386         X.Org X server -- AMD/ATI Radeon display driver

[fischig]

push

Im Grunde gilt immer noch der Eingangsbeitrag.

[h1ght]

ich hatte das problem bei meinem desktop das die maus nachn starten nicht erkannt wurde, musste die ein und austöpseln. mittlerweile geht es ohne mein zutun.

kann man eigentlich dein os noch als debian bezeichnen? ohne systemd/udev und mit eigens kompilierten kernel? ab wann kann man da eigentlich ne grenze ziehen?

[Livingston]

kann man eigentlich dein os noch als debian bezeichnen? ohne systemd/udev und mit eigens kompilierten kernel? ab wann kann man da eigentlich ne grenze ziehen?

Das sind alles Möglichkeiten, die Debian ausdrücklich vorsieht. systemd und udev sind nicht als essential eingestuft. Und einen Kernel neuzubauen wird ebenfalls unterstützt, Debian bietet immerhin hierfür die entsprechenden Pakete an.
Natürlich kann man es auch zu weit treiben, sodass einige Sachen nicht mehr funktionieren. Aber fischig macht das nun lange genug, dass er sicherlich beurteilen kann, was er sich da antut.

Nachtrag: Ich betreue gerade ein paar Server, wo ich auch am Kernel rumfummeln muss. Die Vorgabe lautet, den USB-Support komplett loszuwerden und nur eine Handvoll Module zu ermöglichen (udev läuft dabei trotzdem). Das gehört zum Sicherheitskonzept der jeweiligen Firmen und läuft prima, wenn man es sauber plant und gut durchtestet.

[h1ght]

kann man eigentlich dein os noch als debian bezeichnen? ohne systemd/udev und mit eigens kompilierten kernel? ab wann kann man da eigentlich ne grenze ziehen?

Das sind alles Möglichkeiten, die Debian ausdrücklich vorsieht. systemd und udev sind nicht als essential eingestuft. Und einen Kernel neuzubauen wird ebenfalls unterstützt, Debian bietet immerhin hierfür die entsprechenden Pakete an.
Natürlich kann man es auch zu weit treiben, sodass einige Sachen nicht mehr funktionieren. Aber fischig macht das nun lange genug, dass er sicherlich beurteilen kann, was er sich da antut.

Nachtrag: Ich betreue gerade ein paar Server, wo ich auch am Kernel rumfummeln muss. Die Vorgabe lautet, den USB-Support komplett loszuwerden und nur eine Handvoll Module zu ermöglichen (udev läuft dabei trotzdem). Das gehört zum Sicherheitskonzept der jeweiligen Firmen und läuft prima, wenn man es sauber plant und gut durchtestet.

und wenn man ahnung hat. ich habe gerade auch mal nachgeschaut. gibt ja im repo linux-image-6.5.0-0.deb12.1-amd64 z.b. aber is debian nich schon bei 12.2 gelandet? meine irgendwann mal was gelesen zu haben beim upgrade das das debian repo ne neue nr hat. überlege ob ich mir es antue auch mal ein bisschen rumzufummeln, so c10-package states wären schön. war bei 0 mit dem alten kernel und nun schon bei c3 immerhin.

[fischig]

Wie schon vermutet: udev ist verantwortlich. Wahrscheinlich gefällt der via equivs gebaute alte udev-dummy dem X in bookworm nicht mehr.