danke schonmal, ich probiere das mal aus.
habe allerdings jetzt nen anderen Weg über die acer-hotkey-treiber probiert.
leider werde ich mal wieder aus der Readme-Datei nicht schlau. Da steht drinnen das man mit dem tool die wireless-karte des md40100 (also meines Notebooks) aktivieren kann. Leider verstehe ich nicht was man nach der installation (kompilieren und so hat anscheinend geklapt) machen muss, da ich wieder einmal die Dateien und die Verzeichnisse die in dieser Readme stehen nicht finden kann.
Ich poste hier mal die Readme-Datei, vielleicht kann mir ja einer erklären was zu tun ist. Hoffe das ist hier in dem Forum so erlaubt einen Dateiinhalt zu posten. Ich als newbie tippe mal das die infos zu dem was das ding zum laufen bringt unter dem Punkt "usage" steht.
Bis dahin versuche ich den Weg den Oli-Linux geschrieben hat.
Danke
Und hier ist die readme:
What is this driver good for?
*****************************
This driver will give access to the special keys on notebooks of the
Acer Travelmate series, which are not handled by the keyboard
driver.
Currently the driver is supports the following Travelmate series:
210
220
230
360
350
520
610
620
630
C110
It should also work (but is untested) on:
200
260
600
730
740
C100
Series, where it works partly (use module parameter usedritek=1), support is
very experimental:
Travelmate 290
Travelmate 650
Travelmate 660
Travelmate 800
Aspire 1300
Aspire 1310
Aspire 1350
Aspire 1400
Aspire 1450
Aspire 1700
It also has some other related functionality, currently only the ability to
switch on or off the mail led (available on 6xx models).
You also can use this driver to enable the wlan hardware in Medion MD40100
laptops. Some keys are also supported.
Usage
*****
The driver provides a device /dev/misc/acerhk where you can access all
functions through IOCTL's, look into acerhk.h for their definitions.
I use devfs and don't care about the minor number. You may want to change
ACERHK_MINOR in acerhk.h.
If you don't use devfs you need to create the device node. The device uses
major 10 (misc character devices), the minor is chosen by the kernel (if
ACERHK_MINOR equals MISC_DYNAMIC_MINOR) or by yourself (any other value).
Use something like
mknod /dev/acerhk c 10 123
to create the device node.
You can also use most functions through procfs. You will find three files in
/proc/driver/acerhk:
led - write "on" or "off" to set the led state
key - read it to get a key press
info - some information about the driver, including the number of
pending keys
wirelessled - write "on" or "off" to set the led state and enable
wlan hardware
blueled - write "on" or "off" to set the led state and enable
bluetooth hardware
Probably the best way to use the driver is to let it poll for the keys itself
and generate real key events. You can do this by loading the module with an
additional parameter:
insmod acerhk poll=1
or you can use the ioctl as specified in acerhk.h to start the polling. If
your kernel has proper input support you will get real key events when
pressing the special keys. (If not the driver shouldn't load) You can then use
whatever software you like to make use of those keys, i.e. 'hotkeys' or Linux
Easy Access Keyboard 'lineakd'. I prefer hotkeys, just in case anyone is
interested, you can find a sample configuration for this programm in doc/acertm.def.
Gnome 2.4 has built in support for multimedia keys, that's what I use now.
Module parameters
*****************
name values meaning
autowlan 0,1 disable(default)/enable automatic switching of wlan hardware
on wireless keypress
poll 0,1 disable(default)/enable kernel polling of key events
verbose 0-4 verbosity level, see below
usedritek 0,1 disable(default)/enable use of dritek hardware on newer series
this is a dangerous option, use only if don't mind rebooting
Debugging
*********
You can make the the driver be more verbose. To do this, add the following
parameter when loading the module:
verbose=<n>
n is an integer, 0 (default) means no additional information while increasing
values provide an increasing amount of information. Currently 3 is maximum,
bigger values will have the same effect as 3. The existing verbosity levels
will generate information about:
Level Information
1 state changes and variable initialization
2 model probing
3 key translation, only known keys
4 key translation, everything
If you have rather serious problems you can activate debugging functionality
in the driver. To do this, uncomment the '#define ACERDEBUG' in acerhk.c. You
will find a new file in /proc/driver/acerhk, named 'debug'. You cannot read
from this file, but you can write commands consisting of up to 4 digits. The
first one specifies the action, while the latter can give additional
parameters. Implemented are:
'd' decrement module usage counter
'i' increment module usage counter
'p' call function pbutton_fct()
't' call function get_thermal_event()
'w1x' call function wbutton_fct_1() with parameter x (0-9)
'w2x' call function wbutton_fct_2() with parameter x (0-9)
'vx' change verbosity level to x (0-9)
'mxyy' set mapping of key name x to key event yy (hex)
'sxx' send key event xx (hex) to input system
'Sxx' simulate acer key press with code xx (hex)
'e0' stop kernel polling
'e1' start kernel polling
Example:
1) echo d > /proc/driver/acerhk/debug
will decrement the usage counter, very useful if a program using the driver
segfaulted. This way you can still unload the driver.
2) echo v4 > /proc/driver/acerhk/debug
will set the verbosity level to maximum.
Keycodes
********
see doc/keycodes
Also see http://bernd-wurst.de/linux/tm800.php#mmkeys (only in german)
If you have one of the newer models with the dritek hardware, use kernel 2.6
and get (after enabling it) kernel messages of the form:
atkbd.c: Unknown key pressed (translated set 2, code 0xf4 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e074 <keycode>' to make it known.
then you should do exactly what your told. In this case you could do
setkeycodes e074 158
to map the button with scancode e074 (hex) to keycode 158 (decimal). To find
out the scancodes of the buttons either look into the kernel log or into the
file MMKEYBD.CFG of the windows launch manager package. There you should find
lines like this:
Key 1 = 1,E0,74,E0,F4,F500,P1
** ** **
The important information is marked in the example above. The numbers give the
scancode produced by the button which's name is given last.
The keycode you give as parameter to setkeycodes is one out of the header file
linux/input.h, in the example above the one for KEY_BACK.
To ease the setup of keymappings for the newer series I will try to include
setup scripts for the different notebook series. If I have enough time to
spare I will perhaps expand the driver itself do to that.
How does it work?
*****************
The driver is based on the windows Me driver and resembles its structure and
functionality.
Key presses are events, which are stored in a FIFO queue with 31
entries. You can access the event count via CMOS nvram, but the access to
the actual queue (and other functionality like switching the mail led) is
done through calling a system ROM function.
Upon loading the driver looks for this function, if it cannot find it,
loading aborts.
Credits
*******
Leif Jensen, whose driver inspired me to do the probing stuff
http://www.math.columbia.edu/~jensen/linux/acertm/
Thanks to all who tried this driver on their laptops, without them it would'nt
support anything else but my TM 613.
Contact
*******
Email: Olaf Tauber <tauber@informatik.hu-berlin.de>
The latest version can be found here:
http://www.informatik.hu-berlin.de/~tauber/acerhk
