- 主题:我一直觉得,输入属于键盘的内容
仅仅是个技术讨论而已,为什么也要带有意义呢?
【 在 chunhui 的大作中提到: 】
: 如果你不带目的性的折腾。那尽管去做就好了。没必要讨论挣得别人的支持和同意。如果你想和别人讨论一个合理性,那本身就是目的性。
:
: 另外,其实我上一个帖子就想说,技术本身必然就带目的性的。不带目的性的那叫艺术。单纯折腾的人多的是。这东西也上升不到什么中国外国的层面。就是中国外国有这个差别,那
: ..................
发自「今日水木 on iOS」
--
FROM 101.30.17.*
500块甚至1000块,这样的键盘你自己愿意买吗?
【 在 cwall 的大作中提到: 】
: 仅仅是个技术讨论而已,为什么也要带有意义呢?
:
: 发自「今日水木 on iOS」
发自「快看水母 于 把时光,都炖香」
--
FROM 223.74.154.*
本来,凭啥是本来?就算按你的逻辑是“本来”,那凭啥“本来”了
的方法就有实际优势呢?只占了一个符合你思维的逻辑线路更短?
我问的意思是,对用户体验或者设备成本或者产业利益有什么价值?
不说后两个,就说用户体验,“本来”就是有一个免不掉的外码到内码
的转换过程,这个过程是需要用户干预的,那么外码逐码输入、被选字
的预选过程总需要一个显示的地方,放在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不擅长,所以想问一下呀,有擅长的可以讨论一下呀。
至于意义什么的,这个谁都可以插嘴说,这样讨论有意义吗?我本来也没把这当回事呀,也没问值不值什么的。为什么非要把话题引到这些不着调的路子上呢?别人问的是A,你说一大堆B的东西,有什么意义呢。
【 在 adoal 的大作中提到: 】
: 那你就去做呗。
:
: 你在首帖里关注的是一个奇怪的重点,就是做这个事在熟悉Linux kernel的
: 人眼里技术难度如何。感觉关注点歪掉了。因为HID class里keyboard interface
: 的report format是已经成熟的、固定的,没办法直接用,所以无非
: ..................
发自「今日水木 on iOS」
--
FROM 101.30.17.*
我不是针对你,不好意思。我大概觉得没啥大问题,甚至不需要修改内核代码,先试一下看看吧
【 在 cwall 的大作中提到: 】
: 大概的意思就是每个人都有擅长的地方,也有不擅长的地方,这才有讨论吧。
:
: 因为我对Linux kernel不擅长,所以想问一下呀,有擅长的可以讨论一下呀。
:
: 至于意义什么的,这个谁都可以插嘴说,这样讨论有意义吗?我本来也没把这当回事呀,也没问值不值什么的。为什么非要把话题引
: ..................
发自「今日水木 on iOS」
--
FROM 101.30.17.*
那不说意义不意义,单纯就当在网友的爱好讨论里插一句话。
我也对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,规范里看有8个字节,其中6个可以是键值,而且标准ascii只用了一个字节的7位。汉字编码不就是扩充ascii编码吗。
这部分内容其实在那两篇文章里已经实现了,无非就是增加一个拼音输入法引擎的事情,目前libpinyin和sunpinyin都提供了库,独占一个显示器,不需要依赖OS,难度不大,因为几乎完全是自由发挥,整个电脑都是你的,随便折腾。
现在的疑虑在于OS那边,发过去问题不大,就担心那边收不住
【 在 adoal 的大作中提到: 】
: 如果只是做实验确实不需要修改内核,用libusb在用户态读设备发来的report就可以了。
: 但关键的问题是下位机怎么设计,通讯协议(在不能直接复用现有HID class里的kyboard
: interface的情况下)怎么设计。
: --
发自「今日水木 on iOS」
--
FROM 101.30.17.*