| 01:39.49 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 01:54.32 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:b0cd:1369:8dd6:34e4) |
| 02:08.35 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 02:18.20 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 02:18.47 | *** join/#qi-hardware arossdotme (~zxy@79-69-206-157.dynamic.dsl.as9105.com) |
| 05:19.21 | *** join/#qi-hardware rjeffries_ (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 06:49.51 | *** join/#qi-hardware arossdotme (~zxy@79-69-193-160.dynamic.dsl.as9105.com) |
| 07:44.55 | *** join/#qi-hardware wolfspraul (~wolfsprau@77.12.146.212) |
| 07:52.51 | eintopf | wpwrak: what do you plan to do? bring atusb mainline? |
| 07:55.04 | whitequark | wpwrak: keyboard layouts |
| 07:55.11 | whitequark | oh |
| 07:55.24 | whitequark | as in, there can be more than one keyboard layout |
| 08:07.41 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 08:31.10 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:b0cd:1369:8dd6:34e4) |
| 09:07.02 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:b0cd:1369:8dd6:34e4) |
| 09:40.34 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 09:53.23 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 10:17.12 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 10:43.20 | wpwrak | eintopf: no, i'm just fixing a few things i found in anelok. anelok uses the core stack from ben-wpan |
| 10:44.24 | eintopf | ok |
| 10:44.46 | wpwrak | whitequark: yes, like pressing "Z" on a german keyboard yielding "Y" if the system uses the US keymap. USB HID is basically problem-compatible with PS/2 |
| 10:46.08 | whitequark | wpwrak: and what exactly do you suggest? the chip knowing what's on keycaps? |
| 10:47.12 | whitequark | that would mean that if something doesn't come with RU layout, there's no way to enable it, as well as added communication (complexity) between OS and kbd |
| 10:56.24 | eintopf | I use in germany the us keylayout, always funny if somebody try and try again to input his/her passwort with my account settings. |
| 10:56.54 | eintopf | it's easier to write brackets |
| 11:03.35 | wpwrak | whitequark: there are many possibilities how this could be done right, e.g., |
| 11:04.01 | wpwrak | - the keyboard could send the codes that correspond to what's on the keycaps, but your can override things in the host if you want, |
| 11:04.24 | wpwrak | - the keyboard could have a "raw" and a "translated" mode, so you can choose between both models, |
| 11:05.04 | wpwrak | - the keyboard could have a USB descriptor with the translation table and the host could then just use this as a basis. |
| 11:06.36 | wpwrak | and if the keyboard just sent the correct code, there would be no communication overhead. in any case, HID is rather complex, so adding a new setting or such wouldn't really make a difference in the overall copmlexity |
| 11:06.51 | whitequark | the keyboard still has to be informed about the layout... |
| 11:07.10 | wpwrak | that's a factory setting |
| 11:07.18 | whitequark | about the /selected/ layout |
| 11:07.40 | wpwrak | would solve 99.9% of all uses. for the 0.1%, people could just get some utility to "hack" the keyboard |
| 11:07.43 | whitequark | for, you know, everyone except 200m or so people in the anglosphere |
| 11:07.56 | whitequark | no, *your* use case is the minority one |
| 11:08.10 | wpwrak | no, the keyboard would just send the code that corresponds to what's on the keycap |
| 11:08.19 | whitequark | there are more than one symbol on the keycap |
| 11:08.21 | whitequark | sometimes more than two. |
| 11:08.43 | wpwrak | well, mix in the modifiers |
| 11:08.56 | whitequark | what? |
| 11:09.06 | wpwrak | or have that information in the translation table |
| 11:09.24 | wpwrak | in the decision of what symbol to send |
| 11:09.34 | whitequark | it's not a modifier |
| 11:09.41 | whitequark | it's a layout selected in the DE |
| 11:09.49 | wpwrak | DE ? |
| 11:09.56 | whitequark | desktop environment |
| 11:10.21 | whitequark | http://a4tech.a4-gcube.ru/img/products/full/240vbSzzvopKV0.jpg |
| 11:10.26 | wpwrak | so you have keyboard with multiple alternative layouts, all printed on the keycaps ? |
| 11:10.32 | whitequark | obviously |
| 11:11.06 | whitequark | most people (on the planet) do |
| 11:11.16 | whitequark | you switch between them by using alt+shift or such |
| 11:11.30 | wpwrak | well, it's still a modifier then |
| 11:11.44 | whitequark | it's not a fixed modifier |
| 11:11.46 | wpwrak | RU-lock or whatever :) |
| 11:13.39 | wpwrak | and i guess you have some override that switches to the respective other layout for a single keypress ? e.g., if your mode is US, Y sends Y, and AltGr-Y sends H. |
| 11:14.05 | wpwrak | btw, the QWEYTY us funny. nicely illustrates the confusion :) |
| 11:14.12 | whitequark | no, there is no override |
| 11:14.37 | wpwrak | that must suck sometimes |
| 11:14.51 | whitequark | not a problem in practice |
| 11:15.16 | whitequark | the weirdly changing layout on numeric keys is, but the fix is not to add one-off modeswitch |
| 11:15.39 | wpwrak | anyway, yet another option would be for the keyboard just to announce a layout code. in case a table is just too much work. so you'd still send key codes but at least the host would know what's printed in the keycaps and could select a suitable layout. |
| 11:16.03 | whitequark | yeah, that would make sense |
| 11:16.26 | whitequark | and would be completely trivial to add |
| 11:16.44 | wpwrak | though a table would be more flexible. and the usb folks *love* tables. the more, the merrier :) |
| 11:21.18 | wpwrak | they actually almost added such a code: there is a "country" field in the HID descriptor, but a) it only knows about a few countries, most of which having only one layout, thus not working for anything not totally mainstream, and b) setting it to something meaningful is kinda optional |
| 11:21.57 | whitequark | there is no mapping between countries and layouts |
| 11:22.16 | wpwrak | e.g., my HHKB (US layout) happily identifies itself as "Japan (Katakana)" |
| 11:22.47 | wpwrak | well, there kinda used to. at least if you consider the original IBM keyboards as the reference :) |
| 11:24.29 | wpwrak | and they have codes for variations inside the same country, e.g., switzerland has a french and a german version |
| 11:24.50 | wpwrak | page 13 (23) of http://www.usb.org/developers/hidpage/HID1_11.pdf |
| 11:26.02 | whitequark | there is no mapping between (physical location) and (what is painted on keys) |
| 11:26.05 | whitequark | is it more clear now? |
| 11:29.17 | wpwrak | you mean based on country ? i would expect that even in russia there is. maybe a few major variants, but i guess when you visit a friend you won't be faced with a completely different layout |
| 11:30.16 | whitequark | you just introduced another completely unnecessary and flawed step |
| 11:30.41 | whitequark | instead of manufacturing a keyboard with language X on keycaps, you suggest manufacturing a keyboard for some chinese dude's idea of what's used in country X |
| 11:31.08 | wpwrak | of course, with laptops and other more creative layouts, the whole concept of "standard" layouts collapses. but then you usually don't get a driver with the perfect position-to-symbol (or function) mapping, but you get a controller that makes it look like a common layout. hence my idea for a table: stop the madness :) |
| 11:32.23 | wpwrak | there's no straight mapping for "language" either :) |
| 11:32.59 | wpwrak | e.g., swiss-german != german, swiss-french != french, canadian-french != swiss-* and != french |
| 11:33.38 | wpwrak | but then spanish is probably pretty close to the "country" of "latin america" |
| 11:34.30 | wpwrak | and it's anyone's guess what language they speak in "International (ISO)" ;-) |
| 11:37.07 | wpwrak | so if you wanted a single code, you'd probably need a registry. or spread it out by making this per vendor. but that would have its own set of problems. |
| 11:37.40 | whitequark | yes, there should be a registry |
| 11:38.12 | whitequark | then you could create the xorg mappings using sed, instead of dark magic and collecting lost souls or whatever |
| 11:41.06 | wpwrak | of course, USB-IF would probably want to see some kilodollars for an entry ... |
| 11:41.50 | whitequark | making a keyboard requires injection molding |
| 11:41.55 | whitequark | a few k$ is nothing compared to it |
| 11:43.52 | wpwrak | yes, for homo economicus, there would be no question. but ... :) |
| 11:45.19 | whitequark | and if you don't make your keyboards in bulk, you probably shouldn't invent your own layout |
| 11:45.26 | whitequark | there are too many already |
| 12:09.45 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 12:31.18 | *** join/#qi-hardware rjeffries (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 16:37.41 | *** join/#qi-hardware mth_ (ngytbtqc@88.159.34.112) |
| 17:28.47 | *** join/#qi-hardware nicksydney (~quassel@148.336.dsl.syd.iprimus.net.au) |
| 17:56.03 | *** join/#qi-hardware FDCX_ (~fdcx@79.115.190.165) |
| 19:23.49 | *** join/#qi-hardware rjeffries_ (~rjeffries@ip-64-134-237-27.public.wayport.net) |
| 19:30.55 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::9) |
| 19:34.19 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::9) |
| 21:36.06 | *** join/#qi-hardware uwe_mobile__ (~uwe@static.88-198-8-117.clients.your-server.de) |
| 21:36.11 | *** join/#qi-hardware kanzure_ (~kanzure@unaffiliated/kanzure) |
| 21:41.30 | *** join/#qi-hardware roh (~roh@yamato.hyte.de) |
| 23:20.42 | *** join/#qi-hardware FDCX (~fdcx@2a02:2f0a:a02f:ffff::5679:affb) |
