|(16 intermediate revisions by 7 users not shown)|
|−|Changaco, I appreciate the work you've done here by merging and categorizing the Hotkeys article. However, articles within the wiki should follow a standard format for the sake of consistency--and heavy revisions such as this one are perfect opportunities for such changes. That includes things like: |+|
|−|* Table of Contents should appear the top, above all text | |
|−|* Articles should open with an '''Introduction''' and close with an '''Additional Resources''' (where applicable | |
|−|* Headings (H1, H2, H3, H4, etc.) should be used logically, beginning at H1 (= SAMPLE= ) | |
|−|For more general guidelines, see [[ArchWiki Tutorial (English)]]<br/> | |
|−|~[[User:Thayer| Thayer]] 2008-10-19 09:23PST | |
| || |
|−|: I wasn't aware of these rules sorry. Tough I have to add that level 1 titles '''should not be used''' because <nowiki><h1></ nowiki> HTML markup should be reserved to the page title. Trust me on that I know web development quite well. |+|
| || |
|−|: [[User:Changaco|Changaco]] 12:49, 19 October 2008 (EDT) |+|
| || |
|−|:: No worries, I 'm a standards-based web designer myself. Multiple H1 titles is frowned upon in terms of SEO, but we're not as concerned about SEO optimization as we are about proper semantic organization of internal documentation--the Arch wiki is already one of the best indexed resources on Google. Thanks again for taking care of Hotkeys, it was growing into quite the behemoth! |+|
I a , the wikithe .
| || |
:I understand the motivation. Note though that Wikipedia articles all use titles from level 2 and it's not a damn mess. |+|
My pleasure for the articles, it helped me get a picture of the whole linux key management system. Took my quite some time to reorganize/rewrite all this tough so I hope people will appreciate these pages. |+|
|−|:::[[User: Changaco| Changaco]] 14: 49, 19 October 2008 ( EDT) |+|
for the , itof the . I . :[[User :|]]:, ()
getscancodes is very useful tool for grabbing scancodes.
Quick howto for newbie
- install getscancodes from aur #yaourt -Sya getscancodes
- connect your device and recognize it #dmesg|tail -30
- find the event id of the device (use grep) #cat /proc/bus/input/devices
- run getscancodes #sudo getscancodes /dev/input/event18
I find that it easy just to use setkeycodes for a quick test # setkeycodes scancode keycode
I recommend on mapping the scancodes to a keycode with udev, just link to the wiki or merge the pages.
Dhead (talk) 05:54, 21 October 2013 (UTC)
- There's already a link to official instructions in Extra_Keyboard_Keys#See_also, so I'd say it's not necessary to add these to our wiki.
- setkeycodes and mapping with udev are described in Map_scancodes_to_keycodes, which is just fine - I don't know what you mean...
- Map_scancodes_to_keycodes and Extra_Keyboard_Keys are properly interlinked, and I'm against the merging at the moment because that would imply other pages should be merged too and the resulting page would be too long and hard to read.
- -- Lahwaacz (talk) 13:00, 21 October 2013 (UTC)
Regarding the discussion about the out of date section (2.6 kernels): I use a 3.2 kernel (although not archlinux) and have a non functioning key for which "showkey -s" reports nothing, but the kernel log is full of with logs that that key is unkown, and reports it's scancode. And with the scancode reported in the log I can make it known (although this breaks another behaviour of the keyboard, so for me it is useless). So I think that section is not out of date. Kovacssanya (talk) 21:10, 14 December 2013 (UTC)