Hi y'all, On Xfree there used to be that utility xkb to manipulate some keys. I am using xorg on a slackware 10 box and I can't find that neither as a normal user nor as root. Now I have used a frontend (gnome-keyboard-properties) to change some of the settings, but I'd still prefer doing it the oldschool way. Does anyone know an equivalent console based application ?
Then, I tried adding some shortcuts, but unfortunately found out on gnome 2.6, their functions are predefined, so I can't really assign a shortcut to run my own script. Any ideas ?
Final question: there's the fn button on my asus lappie which I'd like to make use of. The system doesn't recognize it. What do I do in order to map it ?
Thanks
I believe "xkbcomp" is the al
I believe "xkbcomp" is the alternate command you are looking for.
Yes acme is gone and now every program can define certain functions to be bound to shortcut keys. The ideal solution is to find out the way the schemas these programs install do it, and create custom ones. Take metacity's schemas for example.
The old fashioned way is to write a proper keymap for your keyboard and use xmodmap to load it.
An easier way would be used an external daemon to bind to certain keys and do functions. beep media player has such a plugin that works fine with the multimedia keys. A simple search comes up with many programs created soley for this purpose, for example:
About the fn button combinations try to follow this howto:
ask again if something is still unclear.
Thanks for all that info ! I
Thanks for all that info ! I guess I need to take a crash course in googling. Now, what I still do not quite understand is the whole keymap idea. What are all these codenumbers and how do I find out which key is which number ?
As far as I have gathered fro
As far as I have gathered from reading, The keyboard sends key presses as coded events and the kernel (newer ones) passes these code numbers to userspace through /dev/input/event(x) where x is an arbitary integer, assigned for input devices.
The X server listens at that device and decodes the codes into symbols as defined in the keymap. This works fine for standard keyboards and keyboards with known layout and know extra buttons. You just have to load the appropriate keymap using "xmodmap" ( which is what the gnome-keyboard settings thing does for you , also using "xmodmap" ).
To be precise I think the xserver compiles your keymap using "xkbcomp" and uses the compiled version.
Now what if you have a keyboard with an unkown layout? You will have buttons ( dead keys I think ) that send coded keypresses which don't get translated to symbols, and normal userspace won't understand these keypresses.
To fix this, use the program "xev" to view keypresses/scancodes, copy them to your keymap and give them the proper symbol. That way userspace can catch these keypresses.
for example, I have a multimedia keyboard. "xev" gave me the following when I pressed the "search" button :
KeyPress event, serial 29, synthetic NO, window 0x3200001, root 0x9f, subw 0x0, time 1149220, (167,-7), root:(177,86), state 0x10, keycode 122 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: Falseas you can see the keypress has keycode 122 and no symbol assigend. Using this information I can bind it to the appropriate symbol by adding the following line to ~/.Xmodmap ( which should get picked up by the Xserver when it starts ):
keycode 122 = XF86SearchThe appropriate symbols are in "/usr/lib/X11/XKeysymDB"
The program "esekeyd" I pointed you to bypasses the X server and listens directly to the input device.
refrences:
It's never over till it's over.
The keys do not return much
Thanks a lot for all the info, it helped a lot, even if not for this case in particular. Now I started xev, but it doesn't return anything on those keys. I also tried 'cat'ing /dev/input/event(x) which doesn't give any output either when I press them.
As far as I understood, is that /dev/input/event doesn't really have to do with X, hence, it does the same as esekeyd ?
Now does that mean my kernel doesn't have support for these keys at all ? I am using a 2.6 kernel.
The only way I can think of,
The only way I can think of, that your extra keys don't emit signals, is that your keyboard is USB, and the kernel has been compiled with USB HID boot protocol instead of the full USB HID support. Is this the case?
It's never over till it's over.
some laptops keys
emit acpi signals and are catched as acpi events and not keyboard events, and some keys like the fn key are not sent to the OS at all.
Alaa
"i`m feeling for the 2nd time like alice in wonderland reading el wafd"
True, that's why I gave a sep
True, that's why I gave a separate page of instructions for the fn keys. maybe I didn't make it clear, that getting the fn keys to work is separate from the rest of the instructions.
I have this problem with my M
I have this problem with my Microsoft Wireless Keyboard "Comfort Edition." Some keys don't generate *scancodes* to begin with! I'll understand if "Sleep" sends an ACPI suspend event, but what I'd love to know is how the zoom, calender, mail and other keys work on Windows when they don't generate any kind of input (Tried showkey -s, xev, dmesg.. with/without X running.. u name it). Could it be it uses non-standard scancodes which the kernel keyboard driver ignores? How do I go about finding out?
BTW the receiver is connected to the system via PS/2.
here's some output I found, d
here's some output I found, don't know if that makes any difference. What do u mean the keystroke interrupts don't even pass by the OS ?
mohammed@mind:~$ cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7nope this has nothing to do w
nope this has nothing to do with what we are discussing.
Can you summarize what parts of the instructions you followed, what happened and what can't you get to work?
It's never over till it's over.
All instructions followed
I installed and ran eseykeyd and they keyboard would spit out codes with all keystrokes but those special keys. Then I tried "cat"ing /dev/input/event0 and pressing some keys. Again this gave some output on all of them but the special ones. I guess this means, those certain keys are not even read by the OS ? Is there something to do about it ?
So both of you are facing the
So both of you are facing the same problem. dead keys.
I will search for the instructions on loading keymaps into the kernel itself, ( if that is actually the correct solution ), meanwhile can you try again after doing:
modprobe evbug
and then checking output in demsg
It's never over till it's over.
I didn't find a evbug module,
I didn't find a evbug module, hence modprobe gives me an error. I tried evdev instead but this attaches to nothing and I get absolutely no dmesg's at all.
Then your kernel doesn't have
Then your kernel doesn't have the event debugging module.
I have it and I get lots of the following in dmesg after I modprobe it:
The idea is that I want to know if it's really the kernel's fault. I am currently busy playing with some dvb hardware, I'll lookup this problem soon.
It's never over till it's over.
Same problem
I have the same problem. Some of my multimedia keys did not show in xev either, so I've done some research. The keyboard is a Logitech Ultrax cordless, with an usb-reciever.
Now the question is how to get around this, (that is, probably remapping the keys, but still, how.)
I tried the evbug module, which printed along the lines of:
evbug.c: Event. Dev: usb-0000:00:10.0-1/input1, Type: 1, Code: 171, Value: 0 evbug.c: Event. Dev: usb-0000:00:10.0-1/input1, Type: 0, Code: 0, Value: 0 evbug.c: Event. Dev: usb-0000:00:10.0-1/input1, Type: 1, Code: 294, Value: 1 evbug.c: Event. Dev: usb-0000:00:10.0-1/input1, Type: 0, Code: 0, Value: 0The difference being that the key with code 171 i can use (and it turns up in evtest), while the key 294 does not.
Two interesting things is that 2-3 of the keys has a bit random behaviour, e.q. Fn-F6 sometimes pasted copied text. Also, the showkey returns were a bit weird, varying depending on press-release speed. For Fn-F6 it was
"keycode 258 press/n keycode 0 press/n keycode 258 release".A less valuable note is that i also tried the keyboard in knoppix (v.3.4) which i had lying around, but i did not get any response whatsoever.
Valuable reading:
I think this clears up some o
I think this clears up some of the mess. I don't have keys above scancode 256 , so I might not be running into the same problem. I have a usb keyboard , so the multimedia keys are shown as a separate input device. I use 2.6.12-rc6-mm1 which has a big load of patches for all sorts of things, that could be fixing any problems
Anyway, bottom line is if evbug is skippin keys then the problem is at the kernel input layer. If not then it's at the X input layer.
Myabe there should be a scripted testcase for this kind of thing, to diagnose and fix it.
I just might do it one day. It's never over till it's over.
Can you please post compariti
Can you please post comparitive output from evbug and evtest ?
Maybe there's some clue there?
It's never over till it's over.
setxkbmap
It set the keyboard using the X Keyboard Extension
-I used to be indecisive .. but now I'm not so sure
as mentioned in the man page,
as mentioned in the man page, that command needs the proper files to be available. Correct layout, model, keymap etc.
If there was a correct layout, it would be available in gnome's keyboard settings, easily picked from there.
It's never over till it's over.
Another Problem
Another problem I am facing are the hardware controlled keys. I have certain keys (FN and a function key; FN-F1 eg) that control screen brightness, screen state (on/off). These work fine on Windows. On Linux they work too, but they take an extreme long time to do the action, for example, when I press the increase brightness button, it takes the system around 30 seconds to do so, same with switching off and on the screen. I suppose I should tell the kernel to somehow stay away from these interrupts. Unfortunately I do not know how. Any ideas ?
It is too difficult to diagno
It is too difficult to diagnose this problem without more info. Some notebook brands like the Sony vaio for example need special kernel module and userspace daemon to get the fn keys to work. Maybe yours need something extra to fix this "delay" issue.
Some laptops also need a fixed acpi table to be loaded instead of the broken bios one.
I think it's best to separate the issues at hand so we don't mix them up.
As I said I will try to dig up as much information as possible and put it in a wiki page so you people can help me in building it.
Mindspark, please start a new thread about the FN keys, as this seems to be a different issue. Post full details about your hardware and software.
It's never over till it's over.
Ok it's a big mess. We'll hav
Ok it's a big mess. We'll have to wait for things to settle down a little.
It's never over till it's over.