Created attachment 16722 [details] [review] Keyboard definition The attached patch enables support for this keyboard. Some buttons are missing because they are not supported by the kbd driver and I can't get evdev to work. These are: zoom in and out, Spell (above F10), and the launcher buttons 1 to 5.
Unfortunately this patch does not follow the rules. You're patching the buildable files (base, base.lst, base.xml, symbols.dir, ...), not the source files. Could you please have a look at http://freedesktop.org/wiki/Software/XKeyboardConfig/Rules and CVS. Thanks
Created attachment 16723 [details] [review] Keyboard definition Added keypad =, (, and ) keys (I never thought they'd use a different scancode than the regular ones) and fixed Open key. Now everything works as documented.
Again, this patch is not good. You're patching wrong files - the buildable ones. Please look at CVS, use base.xml.in, base.*.part files
Created attachment 16724 [details] [review] Keyboard layout definition You sure know how to alienate casual contributors. While it's trivial for a developer to add once they have a patch like mine, what you are asking for is a PITA for someone who is not already developing for X.org/freedesktop.org and just wants to contribute the layout for his or her keyboard. It's even worst for someone who is not a developer and is not familiar with CVS at all. Here is the updated patch. It's also probably the last one I'm contributing in a while (save for necessary corrections to this one). Next time, please take the minute or so it should take to integrate the changes in my patch into the codebase. Thank you.
Thank you very much! That's much better:) > You sure know how to alienate casual contributors. I just love rules. > Here is the updated patch. It's also probably the last one I'm contributing in > a while (save for necessary corrections to this one). Next time, please take > the minute or so it should take to integrate the changes in my patch into the > codebase. Thank you. Sure I will. The only thing, now we are in the code freeze (before the coming release which is going to happen next week, hopefully). I'll commit your contribution immediately after release. I apologize (if you felt personally offended) - but you're really the first person having issues with that matter. Taking that I usually have several bug reports/contributions per week (for several years) this is some statistics, isn't it?
I am looking at http://www.everythingusb.com/images/list/ms-wireless-keyboard-7000-full.jpg Is this the right model? It is not clear to me how you mapped various keys. For example, parenleft, parenright and KP_Equal - which extended keys will they be put on? If you have a better picture - I'd appreciate if you attach it with some comments. Or just comments... What I am trying to avoid is the situation when some mapping are not related to the "icons" on the keyboard - the mappings created just because the author found them handy. Thanks.
No, you're not looking at the right keyboard... Really, you don't know me, but you can start by giving me some credit. The first GIS result for the name given in this bug report actually shows the referenced keyboard: http://www.mshardwareguide.com/livefiles/Products/49/header-ergo-ned7k.jpg And a slightly larger picture: http://www.thg.ru/technews/images/microsoft_natural_ergonomic_desktop_7000-250607.jpg In case it's not obvious from the pictures, I defined these keys *exactly* as they are laid on the keyboard.
It seems I found the good picture: http://www.ecost.ro/images/MSB2M000061.jpg It kind of explains your mapping (if it is the right one). The only thing I do not understand is whether Functional keys have 2 keycodes - one keycode as normal F-key, another - extended function (Help, Undo, Redo,...). Is it controlled by some modifier key on hardware level?
Yes, the keyboard sends one scancode or the other according to the F Lock state. However, in contrast to num-lock or caps-lock, this toggle is handled by the keyboard internally (it even survives reboots IIRC).
> Yes, the keyboard sends one scancode or the other according to the F Lock > state. However, in contrast to num-lock or caps-lock, this toggle is handled > by the keyboard internally (it even survives reboots IIRC). Yes, that's what I expected. So, it seemse you explained everything I wanted to know. Thanks. I am ready to apply the patch.
Thank you very much! Committed. The only thing I could wish is having the geometry file for that powerful keyboard. Of course, if you have any interest...
I'm on the road now. I'll check out the geometry definition language when I'm back home.
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.