- 主题:我一直觉得，输入属于键盘的内容
USB HID Keyboard的report format上报给host的是扫描码，不是文字。
没办法把汉字封进去。
【 在 cwall 的大作中提到: 】
: 但是由于中国使用方块字，常见的字也有七八千，只能通过虚拟键盘，也就是输入法来输入汉字。80年代很多人研究输入法，到今天也有很多输入法，比如搜狗，腾讯，Google等。我不明白，今天电脑的性能和尺寸已经今非昔比，为什么不在键盘里嵌入一个电脑来做输入呢？一劳永逸的解
: 稣飧鑫侍狻
: 键盘嵌入树莓派，输出HID信号给另一台主机很容易，运行一个输入法，将汉字封装为HID也很容易，接下来就是OS需要接收并处理这些信息，想问问有熟悉Linux kernel，特别是input子系统的人，这样可行吗？
: ...................
--
FROM 183.156.97.*
红通通胖死 冒号 杠杠 wiki 点 osdev 点 org 杠 USB_Human_Interface_Devices
【 在 cwall 的大作中提到: 】
: 可以扩充扫描码呀，位数不够吗
: 发自「今日水木 on iOS」
--
FROM 183.156.97.*
大哥，人家那8个字节是一个已经定义好语义、被业界用了整整30年的struct，
不是“随你怎么用都可以的8个字节”啊。
你要是重新定义消息格式，自己造出一种新的HID协议，固件和操作系统厂家
会跟着你改吗？
【 在 cwall 的大作中提到: 】
: 有8子节宽度，应该完全够用，而且目前每个子节只用了7位，也就是只有Ascii 码，扩展到Unicode难道不行?
: 发自「今日水木 on iOS」
--
FROM 183.156.97.*
另外，你把拼音（或者别的输入法）输入的代码串转成汉字编码的过程，
放在键盘的OS里完成，跟放在主机的OS里完成相比，有什么实际的优势吗？
【 在 cwall 的大作中提到: 】
: 但是由于中国使用方块字，常见的字也有七八千，只能通过虚拟键盘，也就是输入法来输入汉字。80年代很多人研究输入法，到今天也有很多输入法，比如搜狗，腾讯，Google等。我不明白，今天电脑的性能和尺寸已经今非昔比，为什么不在键盘里嵌入一个电脑来做输入呢？一劳永逸的解
: 稣飧鑫侍狻
: 键盘嵌入树莓派，输出HID信号给另一台主机很容易，运行一个输入法，将汉字封装为HID也很容易，接下来就是OS需要接收并处理这些信息，想问问有熟悉Linux kernel，特别是input子系统的人，这样可行吗？
: ...................
--
FROM 183.156.97.*
本来，凭啥是本来？就算按你的逻辑是“本来”，那凭啥“本来”了
的方法就有实际优势呢？只占了一个符合你思维的逻辑线路更短？
我问的意思是，对用户体验或者设备成本或者产业利益有什么价值？
不说后两个，就说用户体验，“本来”就是有一个免不掉的外码到内码
的转换过程，这个过程是需要用户干预的，那么外码逐码输入、被选字
的预选过程总需要一个显示的地方，放在OS里是顺理成章的，可以根据
当前UI选择合适的显示逻辑，比如光标跟随等。放到键盘上做，给键盘
多出一个显示屏，当然不是不可以……算了，不说了。
【 在 cwall 的大作中提到: 】
: 优势就是这功能本来就应该是键盘的事情啊，OS实现那不是历史局限性吗
: 这当然要改协议啊，或者说扩充，还要改OS呀，这本来就是这么个事呀。
: 问题就是怎么改，难度大不大呀
: ...................
--
FROM 183.156.97.*
USB始于1994年
【 在 cwall 的大作中提到: 】
: 30年前还没有USB呢
: 发自「今日水木 on iOS」
--
FROM 183.156.97.*
那你就去做呗。
你在首帖里关注的是一个奇怪的重点，就是做这个事在熟悉Linux kernel的
人眼里技术难度如何。感觉关注点歪掉了。因为HID class里keyboard interface
的report format是已经成熟的、固定的，没办法直接用，所以无非就是先自己做
一个自定义的interface甚至一个自定义的class，在自己的环境里把host和device
调通而已。这些通讯层面的事对于搞嵌入式的人来说是基本功。
难的是，下位机方面，这个中文键盘本身的设计和实现；上位机方面，跟host OS
里需要输入文字的所有“地方”的对接。从技术层面来说没啥好讨论的，纯粹是
工程量问题。
再比如前面有人问如何更新词库……你说OTA不是问题，那么你这个回答同样是
方法论上没问题但实际上要怼进去很多工作量的事，要做工程设计，要做权衡取舍。
如果光秃秃地拎出来一个“技术难度”讨论，真的是没啥难度。
【 在 cwall 的大作中提到: 】
: 仅仅是个技术讨论而已，为什么也要带有意义呢？
: 发自「今日水木 on iOS」
--
修改:adoal FROM 183.156.97.*
FROM 183.156.97.*
那不说意义不意义，单纯就当在网友的爱好讨论里插一句话。
我也对Linux kernel也不擅长，但以我粗浅而广博的技术见识和工程经验来看，
kernel层面的工作在这事的技术难度和工作量里绝对不是大头。
【 在 cwall 的大作中提到: 】
: 大概的意思就是每个人都有擅长的地方，也有不擅长的地方，这才有讨论吧。
: 因为我对Linux kernel不擅长，所以想问一下呀，有擅长的可以讨论一下呀。
: 至于意义什么的，这个谁都可以插嘴说，这样讨论有意义吗？我本来也没把这当回事呀，也没问值不值什么的。为什么非要把话题引到这些不着调的路子上呢？别人问的是A，你说一大堆B的东西，有什么意义呢。
: ...................
--
FROM 183.156.97.*
如果只是做实验确实不需要修改内核，用libusb在用户态读设备发来的report就可以了。
但关键的问题是下位机怎么设计，通讯协议（在不能直接复用现有HID class里的kyboard
interface的情况下）怎么设计。
【 在 cwall 的大作中提到: 】
: 我不是针对你，不好意思。我大概觉得没啥大问题，甚至不需要修改内核代码，先试一下看看吧
: 发自「今日水木 on iOS」
--
FROM 183.156.97.*
写了很长来回答你这贴，没备份，然后被审核了……
懒得再往长里写了，简单点说，HID键盘的后6个字节，是表示6个独立的键
（游戏圈里所谓的六键无冲），如果选择用HID class，就要遵循它的规范。
否则host OS就如你担心那样，肯定“那边收不住”。
如果只是为了做个原型实验来验证你的创意，那不要用HID class，可以用
app specific或者vendor specific，然后写个用户态的程序挂libusb来接收。
另：这6个字节的键值不是ASCII而是扫描码。实际上第8位也用了。
可以看看
aHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vTWlnaHR5UG9yay82ZGEyNmUzODJhN2FkOTFiNTQ5NmVl
NTVmZGM3M2RiMg==
【 在 cwall 的大作中提到: 】
: 应该可以复用目前的HID，规范里看有8个字节，其中6个可以是键值，而且标准ascii只用了一个字节的7位。汉字编码不就是扩充ascii编码吗。
: 这部分内容其实在那两篇文章里已经实现了，无非就是增加一个拼音输入法引擎的事情，目前libpinyin和sunpinyin都提供了库，独占一个显示器，不需要依赖OS，难度不大，因为几乎完全是自由发挥，整个电脑都是你的，随便折腾。
: 现在的疑虑在于OS那边，发过去问题不大，就担心那边收不住
: ...................
--
FROM 183.156.97.*