keyboard
keyboard
たまたま、NHKのプラスを見ていたんだ。そしたら、リアルタイムに生字幕を出す舞台裏をやってた。
聴覚障害者にもTVを楽しんでいただけるように生字幕を出すサービスだ。裏では、アナウンサーの声を聞いて、それを文字おこしして表示するって仕掛け。パソコン版の速記だな。速記協会が絶賛後援して番組はできていた。
いかに、正確に、速く、表情豊かに表現するか、普通のニュース、経済の専門用語が混るニュース、後はお楽しみで漫才を、字幕に落とす。
何組かの腕自慢と言うか指自慢のプロが集っての競技大会。みなさん、マイ・キーボードを持参されてましたねぇ。と、言っても別段特殊な改造を施してあるわけでもない(37,000円って言ってたから、高級品だ)。しっかり自分の指に馴染んだやつが良いって事だな。 中には、裁判所で使われる、特殊な速記用のタイプライターで参戦してるグループもあった。
それから、変換は普通の変換と、自分用の辞書を使う組もあった。経済ニュースの部門では、あらかじめトピックが紹介され、１５分の自由時間で、その分野を勉強する事が許されていた。 その時間を使って、出てきそうな単語を登録してた。上手くヒットすると、１秒ぐらいは変換が速くなるな。
なお、音声と字幕の遅れは３秒以内が望ましいそうだ。それ以上になると、見る人が違和感を覚えるそうだ。大変な世界だな。
でも、いつまで続くんでしょうかね？ AIで、音声認識が爆発的に進んでますからねぇ。だんだん、それに置き換わっていく予感がするぞ。
xev
以前、ひょんな事からキーボードの挙動に疑問をもった。そこで少し調べてみる。挙動で思い出すのは、X環境で、キーが押された/離されたを検出して報告するアプリだ。
sakae@deb:/tmp$ xev
:
KeyPress event, serial 38, synthetic NO, window 0x800001,
root 0x118, subw 0x0, time 7816624, (-351,329), root:(388,353),
state 0x1, keycode 24 (keysym 0x51, Q), same_screen YES,
XLookupString gives 1 bytes: (51) "Q"
XmbLookupString gives 1 bytes: (51) "Q"
XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x800001,
root 0x118, subw 0x0, time 7816786, (-351,329), root:(388,353),
state 0x1, keycode 24 (keysym 0x51, Q), same_screen YES,
XLookupString gives 1 bytes: (51) "Q"
XFilterEvent returns: False
on/off時で返答が異るぞ。一体どゆ事？ SHIFT/CTL/ALTキーも同様にイベントを発出してる。
showkey / dumpkeys
リナだとxevの他にコンソール用にshowkeyなんてコマンドが用意されてる。
sakae@deb:/tmp/z$ showkey -k kb mode was UNICODE [ if you are trying this under X, it might not work since the X server is also reading /dev/console ] press any key (program terminates 10s after last keypress)... keycode 28 release keycode 30 press keycode 30 release keycode 1 press keycode 1 release keycode 100 press keycode 100 release
この他に -a -s なんていうオプションが用意されてる。
それから、dumpkeysですよ。-lで詳しく説明モード
keycode range supported by kernel: 1 - 255 max number of actions bindable to a key: 256 number of keymaps in actual use: 128 of which 121 dynamically allocated ranges of action codes supported by kernel: number of function keys supported by kernel: 256 max nr of compose definitions: 256 nr of compose definitions in actual use: 68 Symbols recognized by dumpkeys: (numeric value, symbol) 0x0000 nul 0x0001 Control_a 0x0002 Control_b 0x0003 Control_c : Recognized modifier names and their column numbers: shift 1 altgr 2 control 4 alt 8 shiftl 16 shiftr 32 ctrll 64 ctrlr 128 capsshift 256
余り嬉しい事はないな。
dmesg
そもそもキーボードをどう検出してる？ そんな場合はFreeBSDです。１０年前のパソコンThinkPad/SL510に入れたもので確認。
[sakae@fb ~]$ dmesg | grep kbd kbd1 at kbdmux0 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0
i8042って言う石が使われているのね。それを頼りに調べてみると、 キーボード コントローラ(KBC) こんなのがヒットしたぞ。
/sys/dev/atkbdc に、それ用が鎮座してる事は承知したけど、いきなり実物を見るんじゃ辛い。もっと、おもちゃみたいなのなきかな。昔を思い出せ。
keyboard(4)
scan cntrl alt alt cntrl code base shift cntrl shift alt shift cntrl shift map[n] 0 1 2 3 4 5 6 7 ---- ------------------------------------------------------ 0x1E 'a' 'A' 0x01 0x01 'a' 'A' 0x01 0x01
xv6-public
で、MITのシュミレータですよ。 uart.c って、シリアル制御。昔風に言うとRS232C になるかな。ドライバーだな。
// Intel 8250 serial port (UART).
#define COM1 0x3f8
uartinit(void) {
:
// Announce that we're here.
for(p="xv6...\n"; *p; p++)
uartputc(*p);
}
uartgetc(void) {
:
return inb(COM1+0);
}
kbd.c これは、キーボードドライバーだな。
kbdgetc(void) {
:
st = inb(KBSTATP);
if((st & KBS_DIB) == 0)
return -1;
data = inb(KBDATAP);
:
shift |= shiftcode[data];
shift ^= togglecode[data];
c = charcode[shift & (CTL | SHIFT)][data];
if(shift & CAPSLOCK){
if('a' <= c && c <= 'z')
c += 'A' - 'a';
else if('A' <= c && c <= 'Z')
c += 'a' - 'A';
}
return c;
kbd.h そして、その定義情報
// PC keyboard interface constants #define KBSTATP 0x64 // kbd controller status port(I) #define KBS_DIB 0x01 // kbd data in buffer #define KBDATAP 0x60 // kbd data port(I) #define SHIFT (1<<0) #define CTL (1<<1) #define ALT (1<<2) #define CAPSLOCK (1<<3) #define NUMLOCK (1<<4) #define SCROLLLOCK (1<<5) #define E0ESC (1<<6)
シフトだとかの修飾キーと、それらがロックされてるかの情報定義。
これらを使っているユーザーサイドのコードが、console.c にあるって理解でいいかな。 console.cの冒頭に
// Console input and output. // Input is from the keyboard or serial port. // Output is written to the screen and serial port.
こんなコメントが入っていた。
ああ、こういうOSを作るための資料サイトが見付かったぞ。 Welcome to OSDev.org
minix1
もう一つ、易しいOSって事で、リナス君も勉強したminixを調べてみる。何を隠そう、家には、1990年製の本があるのさ。久し振りに開いてみたよ。(MINIXオペレーティングシステム第１版) 前半が解説で、後半は付録って事でソースリストがついている。昔の電話帳みたいに厚いやつ。
解説を見ながら、4120行目から始まるコードでは … って感じになってるんだけど、ランダムアクセスみたいに参照先があちこちに飛ぶ。トレースが辛い。
そこでDXですよ。アナログな本からデジタル形式に移行しなさい。政府もディジタル庁を作って、さかんに宣伝してるからね。この話に乘ってみるか。
ソースが電子的にないものかと探してみたら、見付かったぞ。これで、本と首っ引きにならなくてもいいな。tagジャンプなりcscopeを使うなり、好きにしてください。これが現代風な読書習慣。やったねDX。
なお、検索してた時に見付た、ちょっと一服てか脇道です。
kernnels/tty.c
#define KEYBD 0x60 /* I/O port for keyboard data */
#define PORT_B 0x61 /* I/O port for 8255 port B */
PUBLIC keyboard()
{
/* A keyboard interrupt has occurred. Process it. */
int val, code, k, raw_bit;
char stopc;
/* Fetch the character from the keyboard hardware and acknowledge it. */
port_in(KEYBD, &code); /* get the scan code for the key struck */
port_in(PORT_B, &val); /* strobe the keyboard to ack the char */
port_out(PORT_B, val | KBIT); /* strobe the bit high */
port_out(PORT_B, val); /* now strobe it low */
/* The IBM keyboard interrupts twice per key, once when depressed, once when
* released. Filter out the latter, ignoring all but the shift-type keys.
* The shift-type keys, 29, 42, 54, 56, and 69 must be processed normally.
*/
8255と言う石を使ってるようだ。頭にインテル印のiをつけて検索すると Intel 8255 こんなのがヒットする。インテルはCPUの石だけじゃなくて、周辺も石もガッツリと固めていたんだね。ダイナミックメモリーなんかでも、i1103なんてのを作ってた。パソコンの事なら、何でもインテルにお任せくださいってデパートだったんだな。
それにひきかえ、モトローラは、VAXの血をわけた、MC68000 なんてのをやってたけど、周辺の石と言ったら、CRTのコントローラMC6845ぐらいしかないのか。戦略の間違いが、インテルを増長させる引き金になった。おかげで、世間のプログラマーは大迷惑ですよ。電卓に毛が生えたような石でプログラミングせざるを得なかったですから。
kernels/klib88.asm
; port_out(port, value) writes 'value' on the I/O port 'port'.
port_out:
push bx ; save bx
mov bx,sp ; index off bx
push ax ; save ax
push dx ; save dx
mov dx,4[bx] ; dx = port
mov ax,6[bx] ; ax = value
out dx,al ; output 1 byte
pop dx ; restore dx
pop ax ; restore ax
pop bx ; restore bx
ret ; return to caller
不自由な石。
qemu
サード・オピニオンでqemu
sakae@deb:~/src/qemu/hw/input$ ls adb.c Kconfig ps2.c tsc210x.c adb-internal.h lasips2.c pxa2xx_keypad.c vhost-user-input.c adb-kbd.c lm832x.c stellaris_input.c virtio-input.c adb-mouse.c meson.build trace-events virtio-input-hid.c ads7846.c pckbd.c trace.h virtio-input-host.c hid.c pl050.c tsc2005.c
pckbd.cを見ると、I8024なんていう単語がちらほらと出てくるので、間違いなさそう。これって石のシュミレーターコードだよな。1000行たらずで記述出来るのか。
displayなんていうセクションもあるなあ。ここでモトローラの石6845を探してみたけど見付からず。しょうがないので、らしいのって事で、vga.cを見る。
/* * Video Graphics Array (VGA) * * Chipset docs for original IBM VGA: * http://www.mcamafia.de/pdf/ibm_vgaxga_trm2.pdf * * FreeVGA site: * http://www.osdever.net/FreeVGA/home.htm * * Standard VGA features and Bochs VBE extensions are implemented. */
へぇー、VGAの意味を初めて知りたましたよ。ソースの記載されてるソースが重要なんですね。
trans by AI
今回のテーマキーボードを自分は過去にやってなかったか、調べてみたんだ。そしたら、Mgでやってた。 そこにteo語録が記載されてた。
Linux is fucking POO, not just bad, bad REALLY REALLY BAD Linuxはうんちをクソされ、ちょうど悪くない、悪い本当に悪いです
これ、2016年当時のぐぐる翻訳の実力。
今だと、ぐるるの検索で、transってやると、翻訳出来る窓が出て来る。
Linux は糞だ、悪いだけじゃない、本当に悪い Rinakkusu wa kusoda, warui dake janai, hontōni warui
凄く翻訳精度が向上してるね。それに、日本語の発音まで出て来る。POOを糞ってちゃんと漢字で表記してるのには驚かされますよ。
Linuxはクソ不良。 Linuxはクソ不良で、ただ悪いのではなく、本当に本当に悪い。
こちらは、DeepLでも翻訳。上の段は原文のままでの結果。下のやつは、POOの後ろのカンマを削除した時の結果。
とある本によると、もう翻訳はAIに任せていいよ。どこかの会社みたいに英語が出来る事を必須とするなんて時代遅れ。それより、本業の専門分野でいかにちからを発揮出来るかが重要との事。時代は進歩してる。
最後にTeo語録を一つ。
the kernel is a harsh mistress カーネルは厳しい愛人です
AI for picture
画像生成AI「Midjourney」の描いた絵が美術品評会で1位を取ってしまい人間のアーティストが激怒
Stable DiffusionをローカルのGPU無しのWindows PC(Intel CPU)で動かす方法
sakae@deb:~/stable_diffusion.openvino$ pip3 install --user -r requirements.txt
マーフィーの法則が成立した。だからパイソンは嫌いなんです。 まて、ひょっとして32Bit環境でやってないか。こんな環境はとっくの昔に見捨てられているぞ。と言う事で、64Bitな環境でやってみたら、無事にインストール出来た。
インストール画面を眺めていたら、opencv-pythonなんてのがDLされた。400Mを越る大物。何者かと思って調べてみたよ。そしたら、INTELのCPUを有効に使って頂くためのツールセットですってさ。CPUと言うよりGPUね。エッジコンピューティング。
誰かがAIで色々なモデルを構築。新しく脳味噌を鍛える訳だな。で、その脳味噌を下々のみなに 使えるようにしてあげましょう。下々はりっぱな環境を持っていないから、せめてINTEL Loveな皆さんにも分け前をめぐんであげましょってINTELは考えた。それで、脳味噌を移植して動くようにしましょって作戦。その為の培養器だな。
実際に動かしてみると、4G近い脳味噌が転送されてくる。オイラーはそこで恐れをなして、中止しちゃったけどね。文献によると、その脳味噌は、
self._text_encoder = self.core.read_model(
hf_hub_download(repo_id=model, filename="text_encoder.xml"),
hf_hub_download(repo_id=model, filename="text_encoder.bin")
)
コンピュータが解析しやすい形式のXMLファイルと、密度が高いBIN形式のセットになってるらしい。テキスト分析が得意な脳、ネットとやり取りが得意な脳、図形な得意な脳とかに分れている。
実際に使う時は、生成したい図形ってか絵画のヒントをテキストで与える事になる。
python demo.py --prompt "Street-art painting of Emilia Clarke in style of Banksy, photorealism"
バンスキン似の絵画を宜しくってわけだ。多分これをヒントにネットを画像検索、それに手を加えているんだろうね。
オイラーなら、Big wave by Hokusai ってヒントを出してみたいぞ。 そしたら、 Ukiyoe 似の絵画が出て来るはずですから。 丁度、HTMLのALTタグの逆を行くわけだな。
同じ仕組みかどうかは知らないけど、 Midjourney が流行っているみたいだな。