Beiträge von benniD

Hallo,

ein kurzes Update: Mit der Umstellung auf evdev muss das hwdb-file wie folgt angepasst werden:

evdev:input:b0003v04B3p301B*
 KEYBOARD_KEY_90001=prog1 # ThinkVantage
 KEYBOARD_KEY_90002=screenlock
 KEYBOARD_KEY_90003=file
 KEYBOARD_KEY_90004=prog2
 KEYBOARD_KEY_90005=prog3
 KEYBOARD_KEY_90006=calc
 KEYBOARD_KEY_90007=mail
 KEYBOARD_KEY_90008=www

Die hexadezimalen Buchstaben in der USB-PID bzw. VID müssen unbedingt GROSS GESCHRIEBEN werden, damit das file funktioniert.

Hallo,

Zitat von Martin85

Also an alle, die ein WLAN oder Bluetooth Problem haben und es derzeit nicht mit Treibern oder Einstellungen lösen können: Kauft externe WLAN und/oder Bluetooth Geräte

alternativ ließe sich - gerade bei älteren Notebooks - das Problem auch elegant in Hardware lösen - s. Post #3 in https://thinkpad-forum.de/thre…9a48164d93ae51ffaf64c7c95

Das hat bei meinem 10,5 Jahre alten Travelmate 292 Lmi hervorragend funktioniert

Hallo in die Runde,

nachdem ich nun einige Jahre mit dem unter Kurzanleitung: Hotkeys auf Multimedia-Tastaturen benutzen beschriebenen Vorgehen die Programmstart-Tasten meines [daten]"USB Productivity Option Keyboard( has the hub in # 1 )"[/daten] genutzt habe, ist dieses Vorgehen anscheinend seit einem jüngst eingespielten Update auf systemd-210-40.1 und das gleich versionierte udev nicht mehr möglich. Somit musste eine neue Lösung her

Meine Aussagen beziehen sich auf die openSuSE 13.1 mit allen aktuellen Patches.

Die 8 Sondertasten generieren nun keine Mausbutton-, sondern normale Tastatur-Keyevents. Zwei dieser Events sind standardmäßig jedoch Keycodes > 255 zugeordnet, welche somit nicht an den X-Server weitergeleitet werden. Die Aufgabe besteht nun also "nur noch" darin, die betreffenden Keycodes umzumappen. Hierzu kann man folgendes tun:

1) Identifikation der Tastatur hinsichtlich PID und VID, z.B. mittels

hwinfo --keyboard

liefert u.a.:
[daten]
Vendor: usb 0x04b3 "IBM Corp."
Device: usb 0x301b "USB Productivity Option Keyboard( has the hub in # 1 )"
Device File: /dev/input/event4
[/daten]

2) Identifikation der (problematischen) Tastendrücke mittels

evtest /dev/input/event5

(warum ich hier event5 statt event4 wie oben ausgegeben nehmen muss weiß der Kuckuck)

[daten]Event: time 1454848917.625413, type 4 (Misc), code 4 (ScanCode), value 90004
Event: time 1454848917.625413, type 1 (Key), code 421 (?), value 1
Event: time 1454848917.625413, -------------- Report Sync ------------
Event: time 1454848917.753419, type 4 (Misc), code 4 (ScanCode), value 90004
Event: time 1454848917.753419, type 1 (Key), code 421 (?), value 0
Event: time 1454848917.753419, -------------- Report Sync ------------
Event: time 1454848920.953422, type 4 (Misc), code 4 (ScanCode), value 90005
Event: time 1454848920.953422, type 1 (Key), code 423 (?), value 1
Event: time 1454848920.953422, -------------- Report Sync ------------
Event: time 1454848921.209424, type 4 (Misc), code 4 (ScanCode), value 90005
Event: time 1454848921.209424, type 1 (Key), code 423 (?), value 0
[/daten]
Meine beiden Problemtasten generieren also die Scancodes 90004 und 90005; udev macht daraus die Keycodes 421 und 423, mit welchen der X-Server nichts anfangen kann - dieser kennt nur die aus

xmodmap -pke

ersichtlichen Werte bis maximal 255.
Aus dieser Liste sucht man sich nun nicht benötigte Werte heraus, z.B. "XF86Launch2" und "XF86Launch3".

3) Anpassung von udev's Hardwaredatenbank
Hierzu legt man eine Datei unter /etc/udev/hwdb.d an, z.B. /etc/udev/hwdb.d/90-mykeyboard.hwdb. Die Ablage der Datei unter /etc/udev/hwdb.d bewirkt, dass ggfs. abweichende Standardvorgaben aus /usr/lib/udev/hwdb.d übergangen werden. Meine *.hwdb-Datei sieht so aus:

keyboard:usb:v04B3p301B*
 KEYBOARD_KEY_90001=prog1 
 KEYBOARD_KEY_90002=screenlock
 KEYBOARD_KEY_90003=file
 KEYBOARD_KEY_90004=prog2
 KEYBOARD_KEY_90005=prog3
 KEYBOARD_KEY_90006=calc
 KEYBOARD_KEY_90007=mail
 KEYBOARD_KEY_90008=www

Somit ordnet man dem Scancode 90004 die Taste prog2 und 90005 die Taste prog3 - genauer: den jeweiligen keycode - zu. Wichtig ist, hierbei die Codebezeichnungen aus

/usr/include/linux/input.h

zu verwenden.
In der ersten Zeile stehen außerdem die Werte aus Schritt 1), d.h. die Änderungen beziehen sich NUR auf genau dieses Tastaturmodell.

4) Aktivierung der Änderungen
Dies erfolgt über

udevadm hwdb --update && udevadm trigger

Hierdurch baut udev seine Hardwaredatenbank gemäß der zuvor vorgenommenen Einstellungen neu auf und bindet anschließend die betreffenden Geräte neu ein, sodass die neuen Einstellungen sofort wirksam sind. Ein Startscript o.Ä. ist NICHT mehr notwendig

Mittels

udevadm info /dev/input/event5 |grep KEY

kann man sodann die Übernahme der Änderungen verifizieren:

[daten]E: ID_INPUT_KEY=1
E: KEYBOARD_KEY_90001=prog1
E: KEYBOARD_KEY_90002=screenlock
E: KEYBOARD_KEY_90003=file
E: KEYBOARD_KEY_90004=prog2
E: KEYBOARD_KEY_90005=prog3
E: KEYBOARD_KEY_90006=calc
E: KEYBOARD_KEY_90007=mail
E: KEYBOARD_KEY_90008=www[/daten]

5) Test unter X
Als nächstes ist es sinnvoll, auch die Weitergabe an den X-Server noch kurz zu testen.

xev

liefert nun bei Druck der entsprechenden Tasten:

[daten]
KeyRelease event, serial 41, synthetic NO, window 0x4c00001,
root 0x7e, subw 0x0, time 4319170, (-715,702), root:(727,725),
state 0x10, keycode 157 (keysym 0x1008ff42, XF86Launch2), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x4c00001,
root 0x7e, subw 0x0, time 4322882, (-564,83), root:(878,106),
state 0x10, keycode 210 (keysym 0x1008ff43, XF86Launch3), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
[/daten]

6) Finale Einrichtung
Nachdem das Mapping erfolgt ist und alle Tastendrücke korrekt erkannt werden, stehen die Tasten nun in beliebigen Anwendungen zur Verfügung. Die Einrichtung von Programmstarts, D-Bus-Aufrufen etc. kann nun z.B. über K->Systemeinstellungen->Kurzbefehle und Gestensteuerung erfolgen.

• das könnt ihr gern machen

noch ein kurzer Hinweis zu fsck: Bitte vorher die Root-Partition aushängen (ummount /). Falls das nicht geht, kein fsck ausführen. Bei eingehängten Dateisystemen kann es andernfalls zu Problemen kommen (das gibt das Programm auch so aus).

Hallo,

Zitat

Jedoch bei jedem Start bleibt das system jetzt beim startbildschirm
hängen. Man kann mit ESC unterbrechen. Dann verlangt er root passwort.

So wie sich Deine Beschreibung anhört bootet er offenbar in Runlevel 1. Melde Dich mal an und gib

runlevel

ein, um das zu überprüfen. Mir zumindest ist es in 10 Jahren linux noch nie passiert, dass GRUB ein Root-Passwort abgefragt hätte...
Was meinst Du mit "default-Liste"? Geben die Fehlermeldungen irgendwelche verwertbaren Hinweise (tun sie unter lInux meistens ;-)?
Außerdem könnte evtl. ein beschädigtes Dateisystem vorliegen. Melde Dich doch mal als root an und mache ein

fsck -f /dev/$deine-root-partition

Schaden wird das auf jeden Fall nicht.
Hast Du außerdem schon einmal versucht, mit "Failsafe"-Einstellungen zu booten?

Zitat

Ich habe den verdacht das ich bei den Repos eine falsche bzw falsch konfigurierte Auswahl getroffen habe?

Was hast Du denn für Repos - außer der DVD - im System? Wie hast Du diese angelegt? Poste ggfs. mal die Ausgabe von zypper -lr.

Zitat

Ich würde ungern den Rechner komplett plattmachen, d.h. HDD neu formatieren.

2. Kann man "Installieren" wählen und trotzdem nur das BS neu aufsetzen, d.h. die Partition /home mit allen Daten behalten ?

Wenn Du eine separate /home-Partition eingerichtet hast sollte das so sein.
Bei früheren openSuSE-Versionen gab es darüber hinaus eine Reparaturfunktion auf der DVD. Ich weiß allerdings nicht, wie es diesbezüglich heute aussieht.

Hallo zusammen,

ich habe seit kurzem einen "neuen" Gebraucht-PC (mit openSuSE 12.2) mit einer Art Multimedia-Tastatur. Diese verfügt neben den üblichen Tasten über einige Zusatzfunktionen (Browser: vor/zurück, lauter, leiser, nächster/vorheriger Titel usw.) sowie 8 Hotkey-Tasten. Letztgenannte 8 Hotkeys funktionierten nicht out-of-the-box. Im folgenden möchte ich kurz beschreiben, wie ich diese in Gang gebracht habe.

Zunächst zur Hardware:

hwinfo --keyboard

sagt u.a.:
[daten]Device Files: /dev/input/event3, /dev/input/by-id/usb-Lite-On_Technology_USB_Productivity_Option_Keyboard__has_the_hub_in_#_1__-event-kbd, /dev/input/by-path/pci-0000:00:1d.1-usb-0:2.1:1.0-event-kbd[/daten]

Auf der Tastatur steht eigentlich "lenovo", aber was heißt das schon

hwinfo --mouse

sagt u.a.:
[daten]Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event2, /dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse, /dev/input/by-path/pci-0000:00:1d.1-usb-0:1:1.0-event-mouse, /dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-mouse, /dev/input/by-path/pci-0000:00:1d.1-usb-0:1:1.0-mouse[/daten]

Hierbei handelt es sich um eine stinknormale optische Maus mit zwei Tasten und einem Rad ohne weiteren Schnickschnack.

Die grundlegenden Funktionen von Tastatur (inkl. Multimediatasten) und Maus (inkl. Rad) wurden bei der Installation von openSuSE 12.2 korrekt erkannt bzw. eingerichtet. Im folgenden geht es also nur um besagte 8 Hotkeys:

1) Mittels

xev

habe ich nachgeschaut, welche Ereignisse durch die jeweiligen Tastendrücke vom System generiert werden. Dabei fiel mir auf, dass die Multimedia-Tasten ordinäre Key-Events auslösen, die Hotkeys jedoch als (Maus-)Buttons interpretiert werden.

2) Dummerweise lieferte der erste Hotkey das Signal "Button 1" und wurde damit als Drücken der linken Maustaste interpretiert. Andersherum gesagt wären somit die Hotkeys 1-5 nicht nutzbar, da die Buttons 1-5 bereits der Maus zugeordnet sind (2 Tasten + Rad drücken + Rad rauf/runter). Die Aufgabe besteht also zunächst einmal darin, die Button-Nummern der Tastatur-Hotkeys "umzumappen"

3) Werfen wir nun einen Blick auf die für X verfügbaren Eingabegeräte:

xinput

liefert:
[daten]⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB-PS/2 Optical Mouse id=8 [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)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ) id=9 [slave keyboard (3)]
↳ Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ) id=10 [slave keyboard (3)][/daten]

In meinem Fall war der letzte Eintrag (id=10, s.u.) für die Hotkeys zuständig, der vorletzte für die (bereits funktionierenden) "normalen" Tasten der Tastatur.

4) der Befehl

xinput

ermöglicht es ferner u.a., Maustasten umzumappen. Für mich sorgt somit

xinput set-button-map 10 6 7 8 9 10 11 12 13

für das gewünschte Ergebnis. Der erste Wert (10) steht dabei für das Eingabegerät, welches die Button-Events generiert (also die id-Nummer des "Hotkey-Teils" der Tastatur, s.o.), die weiteren Zahlen geben die gewünschten Button-Nummern an, die beim Drücken der insgesamt 8 Hotkeys generiert werden sollen. Eine neuerliche Kontrolle mit

xev

zeigte nun bereits, dass das Ummappen der Hotkeys prinzipiell funktioniert: Ein Druck des ersten Hotkeys generiert "Button 6", des zweiten "Button 7" usw.

5) Nun müssen nur noch den 8 neuen "Maus-Buttons" die jeweils gewünschten Funktionen zugewiesen werden. Dafür eignet sich

xbindkeys

, welches mit einer Konfigurationsdatei der folgenden Syntax diesen Job tut:
[daten]
"$Befehl"
b:$Buttonnummer
[/daten]

In meinem Fall sieht das config-File ~/.xbindkeysrc so aus:
[daten]"firefox"
b:12

"evolution"
b:11

"kcalc"
b:10

"soffice --calc"
b:9

"soffice --writer"
b:13

"dolphin ~"
b:8

"mplayer /usr/share/sounds/KDE-Sys-App-Negative.ogg & dbus-send --session --dest=org.freedesktop.ScreenSaver --type=method_call --print-reply /ScreenSaver org.freedesktop.ScreenSaver.Lock"
b:7

"konsole"
b:6
[/daten]

Anmerkung: Hier werden einfach nur ein paar Programme gestartet - bis auf den Fall bei Button 7: Hier wird mittels dbus-Aufruf der Bildschirmschoner gestartet und die Arbeitsfläche gesperrt.

6) Zuletzt den Befehl

xbindkeys -f ~/.xbindkeysrc

ausführen, damit die config auch angewendet wird. Dies muss - genauso wie auch der o.g. xinput-Aufruf - nach jeder Neuanmeldung neu durchgeführt werden. Daher bietet es sich an, das ganze zu skripten (vgl. Anhang xinput-lenovokeyboard.sh) und dieses Skript dann zum Autostart seiner Desktop-Umgebung hinzuzufügen.

Ich hoffe, hiermit dem ein oder anderen weiterhelfen zu können - ich selbst wäre nie auf den Gedanken gekommen, dass eine Tastatur Maus-Button-Events erzeugt, und habe daher lange für diese relativ einfache Lösung gebraucht

Viele Grüße,

benniD

scheint so - gleicher Autor, gleiches Repo. Klick mal auf "Show 4 Sub packages" unter http://software.opensuse.org/s…seproject=openSUSE%3A12.2. Oder versuch' einfach ein One-Click-Install

Zitat von tomfa-ng

Wahrscheinlich weil es durch acer-wmi ersetzt wurde. Ist dieses geladen? Mal die Ausgabe von lsmod zeigen.

Die TM290-Serie ist auf http://code.google.com/p/aceracpi/wiki/SupportedHardware (diese Liste soll auch für acer-wmi gültig sein) als unsupported gelistet.
"The models listed here are the ones known to absolutely not work with this driver - if you have one of these: it is not, cannot and will not be supported by acer_acpi"

Wir haben also wohl Pech...

EDIT: ...Glück! Eine Paketsuche bei software.opensuse.org bringt jetzt Treffer für acerhk auch in der 12.1 sowie in der Factory!