Donnerstag, 21. Februar 2008
G15 Tastaturen und die Win Taste
Wie nahezu alle neuen Tastaturen hat ja auch die G15 Tastatur von Logitech eine Win Taste (unter Linux auch "Meta" Key genannt). Um aber den Spielern unter dem Spiel OS die Sicherheit zu geben, nicht versehentlich diese Taste zu drücken und damit dann das Startmenü zu öffnen, hat diese Tastatur einen kleinen Schalter.
Dieser lässt sich zwischen einem Joystick und einem Computer Symbol umschalten. Unter Linux ist diese Meta Taste nicht sehr gebräuchlich und im Anfall eines Spieltriebs hab ich die wohl irgendwann mal betätigt und versuchte nun ca 45 Minuten die Meta Taste "zu reparieren".
Hint: Wenn die Taste mal nicht funktioniert, erstmal schauen, wo dieser magische Schalter steht
Dieser lässt sich zwischen einem Joystick und einem Computer Symbol umschalten. Unter Linux ist diese Meta Taste nicht sehr gebräuchlich und im Anfall eines Spieltriebs hab ich die wohl irgendwann mal betätigt und versuchte nun ca 45 Minuten die Meta Taste "zu reparieren".
Hint: Wenn die Taste mal nicht funktioniert, erstmal schauen, wo dieser magische Schalter steht
Freitag, 16. November 2007
ACPI Battery -- und weg ist der Status
Nunja, man könnte meinen, so langsam sei das Thema ACPI mal fertig entwickelt im Linux Kernel.
Nach dem heutigen testen des 2.6.24-rc2 muss ich jedoch feststellen: mitnichten...
Mittlerweile sind viele Leute wohl der Ansicht, /proc/acpi sei auch in die Jahre gekommen und müsse nun langsam mal dem Beispiel anderer folgen und nach /sys auswandern. Schön und gut, doch wo ist nun die gewünschte Information?
Nach ein wenig Studium von bugs.kernel.org stellt sich dann heraus, dass die "neue" Variante nicht mehr mit Dateien arbeitet (hey, fopen()+fread() um den Status festzustellen wäre echt zu einfach und überall machbar), wird stattdessen die Info über den ACPI Event Kanal verteilt. Also kein schnelles Script mehr und alle Standard ACPI Monitore (die schönen Tray Icons z.B.) bekommen nix mehr mit.
Abhilfe:
[*] Deprecated /proc/acpi files
Böser Beigeschmack:
"This function has no effect on /proc/acpi files and functions which do not yet exist in /sys."
Also ein Datei -> Funktionsaufrufsübergang ohne Warnung...
EDIT um 11:54:
Hier gibts eine schöne Übersicht mit Regressions(Neue Probleme in alten Modulen):
http://kerneltrap.org/mailarchive/linux-netdev/2007/11/13/407804
Nach dem heutigen testen des 2.6.24-rc2 muss ich jedoch feststellen: mitnichten...
Mittlerweile sind viele Leute wohl der Ansicht, /proc/acpi sei auch in die Jahre gekommen und müsse nun langsam mal dem Beispiel anderer folgen und nach /sys auswandern. Schön und gut, doch wo ist nun die gewünschte Information?
Nach ein wenig Studium von bugs.kernel.org stellt sich dann heraus, dass die "neue" Variante nicht mehr mit Dateien arbeitet (hey, fopen()+fread() um den Status festzustellen wäre echt zu einfach und überall machbar), wird stattdessen die Info über den ACPI Event Kanal verteilt. Also kein schnelles Script mehr und alle Standard ACPI Monitore (die schönen Tray Icons z.B.) bekommen nix mehr mit.
Abhilfe:
[*] Deprecated /proc/acpi files
Böser Beigeschmack:
"This function has no effect on /proc/acpi files and functions which do not yet exist in /sys."
Also ein Datei -> Funktionsaufrufsübergang ohne Warnung...
EDIT um 11:54:
Hier gibts eine schöne Übersicht mit Regressions(Neue Probleme in alten Modulen):
http://kerneltrap.org/mailarchive/linux-netdev/2007/11/13/407804
Montag, 5. November 2007
Das Gentoo Distfile Experiment
So mancher Gentoo Benutzer regt sich doch gerne mal über nicht korrekte Checksummen auf, was Portage gerne mit "!!! Checksum differs" quittiert.
Um diesem Problem Herr zu werden, haben Jan und ich beschlossen, einfach mal einen groß angelegten Test zu machen. Dafür werden wir alle Pakete, die derzeit in Stable und Testing sind, herunterladen.
Da sich sowas jedoch mit der Portage API mehr schlecht als recht skripten lässt (nein, "emerge -f xxx" sind keine schöne option), verwenden wit Pkgcore.
Im ersten Durchlauf kommen wir bisher auf 26 GB Daten. Was derzeit fehlt, sind Quellen, die durch USE Flags mit einbezogen werden, der Rest sieht aber schon mal ganz gut aus
Um diesem Problem Herr zu werden, haben Jan und ich beschlossen, einfach mal einen groß angelegten Test zu machen. Dafür werden wir alle Pakete, die derzeit in Stable und Testing sind, herunterladen.
Da sich sowas jedoch mit der Portage API mehr schlecht als recht skripten lässt (nein, "emerge -f xxx" sind keine schöne option), verwenden wit Pkgcore.
Im ersten Durchlauf kommen wir bisher auf 26 GB Daten. Was derzeit fehlt, sind Quellen, die durch USE Flags mit einbezogen werden, der Rest sieht aber schon mal ganz gut aus
(Seite 1 von 1, insgesamt 3 Einträge)