Ok, where to begin... I have the listed model:EX110 USB/PS2 keyboard/mouse combo. It didn't do much except for the required keys, except in windows. It has "extra" keys that the net is full of howto's some worked for me some didn't. To cut to the chase, I have mine working now after way too much work on the subject. I am going to post a working set of setkeycodes=xxxx, and keycode=xxx for this model. I am sorry for this but I am using X 6.9 of a livecd installed to the hard disk. Serge, I did see the announcement you made for xkeyboard-config 1.0. http://lists.freedesktop.org/archives/xorg/2007-July/026318.html and I have downloaded it to compare inet files with. I see some updated keyboards in there. This EX110 is a bargain basement keyb I picked up in a pinch, but I like it more than my M$ Bluetooth garbage. It has from the left side to the top going across to the right in this order: (gray) Back, Close, then on the top: 4 Media player keys on the left side... (gray) Play/Pause toggle, Stop, Previous, Next. Then going to the middle right side 6 more keys: (gray) Audio Mute, Vol-, Vol+, Email, Home, Calculator The 12 Function Keys... Next it also has a Function Key mode button which does what a lot of other Logitech models do... gives the 12 function keys a new lease on life by sending yet new codes the kernel knows nothing about, even when plugged in to the PS2 port. (On USB, the 12 function keys were just not ever seen by the kernel.) I had to set the kernel message level to 8 before it would report in the syslog that keys were there but it didn't know what they were. Ctrl-Alt-SysReq then Ctrl-Alt-8. I put this here for the benefit of those who have a Linux put together by someone who thinks like my distro did and sets the loglevel too low for these messages to be recorded in the syslog. They have pictures on them, but they almost all map to some XFree86 symbolic name. There is no XF86Undo or XF86Redo defined in my XKeysymDB or something Close to Powerpoint, so I used XF86Pictures in mine. I defined a model in the needed files in /usr/X11/lib/X11/xkb/rules/ as logiex110. I have 12 new keys that I can assign to alot of things in KDE, but not anything like Cut Copy Paste which KDE seems to want a combo keystroke for. Possibly I can get better results using different setkeycodes commands. For now, I am just enjoying alot of new keys to assign functions to. I used the Logitech Cordless Desktop as a starting point, but it did the wrong thing for some buttons, and there were some it had no mapping for. Home and Close, I remember for sure. The F9~F12 keys are just labeled A,B,C,D so I gave them Launch labels. I know there are ways to include sections of keys Logitech definitions, but what I don't know is if I use an include directive, and then specify a new label for a key already defined, then which one will win? Is there an "overrides" directive in the compiler's building of the tables? // Logitech Cordless Desktop EX110 partial alphanumeric_keys xkb_symbols "logiex110" { key <I6A> { [ XF86Back ] }; // Back key <I2F> { [ XF86Close ] }; // Close key <I22> { [ XF86AudioPlay, XF86AudioPause ] }; key <I24> { [ XF86AudioStop ] }; key <I10> { [ XF86AudioPrev ] }; key <I19> { [ XF86AudioNext ] }; key <I20> { [ XF86AudioMute ] }; key <I2E> { [ XF86AudioLowerVolume ] }; key <I30> { [ XF86AudioRaiseVolume ] }; key <I6C> { [ XF86Mail ] }; key <I32> { [ XF86WWW ] }; key <I21> { [ XF86Calculator ] }; // Extended function keys // In the Console before starting X, in an init script preferably. // Using setkeycodes e03b 212 e03c 213 e03d 214 e03e 215 e03f 216 e040 217 // setkeycodes e041 218 e042 219 e043 220 e044 221 e057 222 e058 223 6d 206 key <I3B> { [ XF86Support ] }; // F1 key <FK13> { [ XF86Word ] }; // F2 key <FK14> { [ XF86Excel ] }; // F3 key <FK15> { [ XF86Pictures ] }; // F4 key <FK16> { [ Undo ] }; // F5 key <I65> { [ Redo ] }; // F6 key <I42> { [ Print ] }; // F7 key <I43> { [ XF86Save ] }; // F8 key <I44> { [ XF86Launch1 ] }; // F9 key <I45> { [ XF86Launch2 ] }; // F10 key <I14> { [ XF86Launch3 ] }; // F11 key <I4A> { [ XF86Launch4 ] }; // F12 };
Ok, I just looked at the new inet from xkeyboard-config 1.0. It has a nice logitech_base group that has alot of what mine needs, some incorrect but I see that a second mapping overwrites the first one. So here is one that uses the defs from the new inet. // Logitech Cordless Desktop EX110 partial alphanumeric_keys xkb_symbols "logiex110" { include "inet(logitech_base)" key <I2F> { [ XF86Close ] }; // Close key <I21> { [ XF86Calculator ] }; // Extended function keys // In the Console before starting X // Using setkeycodes e03b 212 e03c 213 e03d 214 e03e 215 e03f 216 e040 217 // setkeycodes e041 218 e042 219 e043 220 e044 221 e057 222 e058 223 6d 206 // *=keys that are there but need different symbol names. key <I3B> { [ XF86Support ] }; // F1 key <FK13> { [ XF86Word ] }; // F2 key <FK14> { [ XF86Excel ] }; // F3 key <FK15> { [ XF86Pictures ] }; // F4 key <FK16> { [ Undo ] }; // F5 key <I65> { [ Redo ] }; // F6 * key <I42> { [ Print ] }; // F7 key <I43> { [ XF86Save ] }; // F8 key <I44> { [ XF86Launch1 ] }; // F9 * key <I45> { [ XF86Launch2 ] }; // F10 key <I14> { [ XF86Launch3 ] }; // F11 key <I4A> { [ XF86Launch4 ] }; // F12 };
> key <I2F> { [ XF86Close ] }; // Close ok > key <I21> { [ XF86Calculator ] }; ok > key <I3B> { [ XF86Support ] }; // F1 Could I change it to "Help"? > key <FK13> { [ XF86Word ] }; // F2 There is no such keysym, see keysymdef.h > key <FK14> { [ XF86Excel ] }; // F3 There is no such keysym > key <FK15> { [ XF86Pictures ] }; // F4 There is no such keysym > key <FK16> { [ Undo ] }; // F5 ok > key <I65> { [ Redo ] }; // F6 * ok > key <I42> { [ Print ] }; // F7 ok > key <I43> { [ XF86Save ] }; // F8 ok > key <I44> { [ XF86Launch1 ] }; // F9 * > key <I45> { [ XF86Launch2 ] }; // F10 > key <I14> { [ XF86Launch3 ] }; // F11 > key <I4A> { [ XF86Launch4 ] }; // F12 These are ok Actually, thanks for spotting the problem - I found a couple of existing mappings with XF86Word/XF86Excel, I am going to eliminate them.
Sorry, I was wrong. The missing symbols are not in keysymdef.h but in XKeysymDB. So they are ok. The only question is - could I change XF86Suppor to just Help?
Sure. Help would be better, I agree. I just stuck to what was in the files, in case someone like KDE decides to use those labels like it surely does for Vol+, Vol-, and Mute. I have to say the new inet looked alot cleaner. Includes are nice!
(In reply to comment #2) > These are ok > > Actually, thanks for spotting the problem - I found a couple of existing > mappings with XF86Word/XF86Excel, I am going to eliminate them. > Were you referring to the line I put in" " *=keys that are there but need different symbol names. " That was a note just saying that inet(logitech_base) had those keys mapped... key <I65> { [ Redo ] }; // F6 * key <I44> { [ XF86Launch1 ] }; // F9 * but had different name/labels which needed to overwritten. But if you want to get rid of Excel, Word, etc... more power to ya. I was shocked they were there.
Ok, I committed the stuff as it is. I am not excited by Word/Excel/... - but I'll let it stay for a while.
(In reply to comment #6) > Ok, I committed the stuff as it is. I am not excited by Word/Excel/... - but > I'll let it stay for a while. > Either am I. I think XF86Editor, XF86Spreadsheet, XF86Presentation would be less offensive to my eyes. Is there an XF86Help symbol defined yet? Also, I looked over in KDE core and they seem to be using the XF86Homepage instead of XF86WWW. I think having the 2, are more confusing than beneficial. So in light of that KDE patch having already been put in, this past February, I would change XF86WWW to XF86Homepage in logitech_base. http://lists.kde.org/?l=kde-core-devel&m=117232820712374&w=2 If there is room to do so... these need some definition XF86Help XF86Undo XF86Redo XF86Print XF86Presentation Can you say... deprecate XF86Word, XF86Excel, and create more universal ones like XF86Editor, XF86Spreadsheet, XF86Presentation. I am sure OpenOffice and KDE would appreciate it. Ok, I am done here. Thanks Sergey
Now that I passed the torch on to you Sergey, I decided to check a little further... These 2 ranges were just available... so setkeycodes e03b 212 would be the command given for the left side's first item. e03b 212 e03b 227 e03c 213 e03c 228 e03d 214 e03d 229 e03e 215 e03e 230 e03f 216 e03f 231 e040 217 e040 232 e041 218 e041 233 e042 219 e042 234 e043 220 e043 235 e044 221 e044 236 e057 222 e057 237 e058 223 e058 238 This first group uses the setcodes on the left. starting with keycode 212. Here are the function keys assigned into existence by the setkeycodes command. state 0x0, keycode 187 (keysym 0xff6a, Help), same_screen YES, state 0x0, keycode 118 (keysym 0x1008ff89, XF86Word), same_screen YES, state 0x0, keycode 119 (keysym 0x1008ff5c, XF86Excel), same_screen YES, state 0x0, keycode 120 (keysym 0x1008ff91, XF86Pictures), same_screen YES, state 0x0, keycode 121 (keysym 0xff65, Undo), same_screen YES, state 0x0, keycode 229 (keysym 0xff66, Redo), same_screen YES, state 0x0, keycode 194 (keysym 0xff61, Print), same_screen YES, state 0x0, keycode 195 (keysym 0x1008ff77, XF86Save), same_screen YES, state 0x0, keycode 196 (keysym 0x1008ff58, XF86Launch1), same_screen YES, state 0x0, keycode 197 (keysym 0x1008ff57, XF86Launch2), same_screen YES, state 0x0, keycode 148 (keysym 0x1008ff6d, XF86Launch3), same_screen YES, state 0x0, keycode 202 (keysym 0x1008ff55, XF86Launch4), same_screen YES, Now after redefining the setkeycodes with the group on the right... starting with e03b 227, and not changing the codes used in the inet file... state 0x0, keycode 214 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 215 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 216 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 217 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 218 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 228 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 142 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 213 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 240 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 241 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 242 (keysym 0x0, NoSymbol), same_screen YES, state 0x0, keycode 243 (keysym 0x0, NoSymbol), same_screen YES, So........ What is the preferred way of letting someone know what setkeycodes command to give... so that a mapped keyboard's mapping will correspond to the codes used with setkeycodes? Is there a way to specify this when creating a mapping such as this one? I didn't see such a thing. Without the exact key mapping I used, nobody will get the missing keys the kernel doesn't understand, and says so, to map correctly. There really has to be a way to do this. Should I open a bug for this? Another interesting thing is the F7 Key, Labeled "Print". There is a definition in keysymdef.h for it, so X returns a positive second value using XKeysymToKeycode. KeyPress event, serial 31, synthetic NO, window 0x400001, root 0x63, subw 0x0, time 8085423, (122,587), root:(960,610), state 0x10, keycode 194 (keysym 0xff61, Print), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False
> What is the preferred way of letting someone know what setkeycodes > command to give... so that a mapped keyboard's mapping will correspond to > the codes used with setkeycodes? Other than putting comments into xkb config file - I'm afraid there is no way. > will get the missing keys the kernel doesn't understand, and says so, to map > correctly. There really has to be a way to do this. May be, this resource could be useful: http://people.freedesktop.org/~hughsient/quirk/ > Another interesting thing is the F7 Key, Labeled "Print". > There is a definition in keysymdef.h for it, so X returns a positive > second value using XKeysymToKeycode. Sorry, I do not really get it. What makes it interesting?
Created attachment 10944 [details] [review] These are the changes I made to X 7.2 I am not so hot at patching and diffing, but the orig /etc/X11/kbd was copied to /etc/X11-orig/xkb and the new files are in /etc/X11/xkb. Is that backwards? Well the plus lines are the ones that are added to the existing files.
Created attachment 10945 [details] File to use for hal to just recognize the keys... This file on the new hal, currently 0.5.10, gave me a totally working keyboard... so easy grandma could do it. I placed it in /usr/share/hal/fdi/information/10freedesktop/30-keymap-logitech.fdi Now if users who have that keyboard come to this bug, and modify this file to specify their computer in these lines... <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains="M825G"> <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" contains="ECS"> then it should work using the same codes needed by the the config I gave you. I will try and find a way to be more general... in the above lines... so it fits any computer.
Well Sergey, After some silence I come back bearing a good news of sorts. With alot of learning about stuff I really didn't need to know, I found out how right you were. Hal is part of the answer. Using 2 parts, an xkb config file set, and a hal file that is intended to be for that keyboard... it works. I did not have to issue any setkeycodes and xmodmap commands at all. Now even the keys the atkbd driver and then the kernel, would not use are just there... This was using the hal from git. 0.5.10.
I should mention that I had to dump a partition, and install Slackware 12. Then the only other thing I did was to get the current hal with the git command. But... when you compile hal you must be careful. cd to the top of hal... then override the compiler defaults by using this... again for slackware 12. ./autogen.sh --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --datadir=/usr/share make && make install when done you can check everything was okay with: john@woojo:~/Desktop $ pkg-config --modversion hal 0.5.10 Plug and play almost here...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.