コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2021年3月8日 >>> 2021年2月27日
link もっと後

2021年3月7日

電源タップの雷ガード

在宅勤務環境を整えようと、電源タップを物色していました。電源タップを見ていると大体3つに分類できて、

  • 普通のタップ
  • スイッチ付き
  • 雷ガード(雷サージ保護)付き

前者2つはわかりやすいです。3つ目の雷ガードとは何者でしょう?前から不思議だったので、軽く調べました。

雷ガードの定義

雷ガードは雷の直撃を防ぐわけではなく(それは避雷針の仕事)、落雷したとき電線に混入する1〜20kV程度のサージ電流を防ぐ仕組みのようです。パナソニックのタップは0.8kV, 1.2kV、LED照明器具は15kV、サンワサプライは15kV, 20kVを最大電圧とした製品を見つけました。

保護の仕組みですが、サンワサプライは電源系にはバリスタ(Varistor, Variable Resistor)を使っていると書いています。パナソニックのサイトも雷サージ対策にバリスタとあるので、バリスタがポピュラーな仕組みなのでしょう。

参考: 【EMC対策】雷サージ対策部品 "バリスタ" の落とし穴 - パナソニック

バリスタはいわゆる静電気(ESD, Electric Static Discharge)対策で使われる素子です。ツェナーダイオードを2つ逆接続したようなV-I特性で、電圧の正負を気にせず、とにかく高い電圧に対し低い抵抗値を持ちます。

参考: チップバリスタ - 電子デバイス・産業用機器 - パナソニック

バリスタと本体の電子機器を並列に接続します。回路に高い電圧が掛かると、バリスタ側の抵抗値が急激に下がり、バリスタ側に電流が流れます。バリスタ側に電流が逃げることで、本体の電子機器は高い電圧を食らわずに済みサージ電流から保護される仕組みです。

ESDの場合は素子が壊れないように十分な耐圧のバリスタを選定すると思いますが、雷サージの電圧は最大何Vかわかりません。時にバリスタが耐えられない電圧が掛かり、バリスタが故障します。特にバリスタがショートモードで故障し、ユーザーが気づかずに使い続けた場合、素子が加熱し火災が発生する恐れがあります。

これは実際に起きた事故で、10年前にNOATEKの雷ガード製品がバリスタの加熱&火災を起こし150万個もリコールされました。NITEの解説を見る限り、この製品は「雷ガード=バリスタ入れればOK」という甘い設計だったため、ショートモードで故障した後、加熱を検知できず火災に至ったようです。

雷を防いだら、火事になりました、なんて製品は全く笑えません。安全な設計というのは難しいですね。

こんなことばかり調べているから、全然買い物が進みません。在宅勤務環境が整うのはまだ先のようです……。

メモ: 技術系の話はFacebookから転記しておくことにした。リンク、情報追加、加筆。

編集者:すずき(2021/03/08 03:23)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年3月6日

気に入るマウスはどれ?

手に合うワイヤレスマウスを探し続け、高級製品、小さい製品、お手ごろ製品と買いまくり、一時は家に5個くらいワイヤレスマウスがありました。

日記から遍歴を辿ってみたところ、少なくとも下記の製品を持っていたようです。

  • 2004年12月: Logitech Optical Mouse USB M-UV96
  • 2007年1月: Logicool Nano Cordless Laser Mouse V450
  • 2010年2月: Logicool Cordless Laser Mouse MX1100
  • 2011年12月: Logicool Wireless Mouse M510
  • 2012年4月: Logicool Perfomance MX M950
  • 2013年10月: Microsoft Wireless Mouse 1000
  • 2014年8月: Logicool Perfomance MX M950(2個目)
  • 2017年5月: エレコムEX-G Ultimate Laser Mouse M-XGL20DLBK
  • 2017年5月: Logicool Wireless Mouse M560
  • 2017年12月: Logicool Marathon Mouse M705
  • 2021年1月: Microsoft Basic Optical Mouse

全部で11個です。こんなに買っていたとは思いませんでした……。

最終的に辿り着いた先は

色々試して最終的に辿り着いたのは、Microsoftの1000円の有線マウス(Basic Optical Mouse)でした。このマウスは中身がほぼ空っぽでめちゃくちゃ軽いです。

はい、何ですか?ワイヤレスじゃないって?そうですね。ワイヤレスマウスはどうしても重くて、手首が疲れてしまいダメでした。

小さいワイヤレスマウスなら軽いですが、手の大きさと合わずやっぱり手が疲れてしまいます。どうもマウスの持ち方(親指と小指で挟むように持つ)が、小さいマウス、ワイヤレスマウスと合わないみたいです。

という訳でワイヤレスマウスは諦めました。有線マウスは安くて軽くて最高です!

メモ: 技術系の話はFacebookから転記しておくことにした。マウス遍歴を追加。

編集者:すずき(2022/01/21 18:42)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年3月4日

VSCodeを使ってWindowsからLinuxアプリのデバッグ その2

目次: Linux

その1その2

昨日(2021年3月3日の日記参照)の続きです。

GDBの準備

Windows側で使用するGDBを用意します。最初はMinGWのバイナリが使えるかと思ったのですが、MinGWのバイナリはWindowsの実行形式(COFF)のデバッグ用で、Linuxの実行形式(ELF)は認識せず、ダメでした。残念。

GDBはbinutilsに含まれています。ビルド方法を下記に示します。バージョンは何でも良いと思いますが、私はMinGWも使っている2.32にしました。

binutils, gdbのビルド
$ git clone git://sourceware.org/git/binutils-gdb.git
$ cd binutils-gdb
$ git checkout -b 2_32 binutils-2_32

$ mkdir build
$ cd build
$ ../configure \
    --host=x86_64-w64-mingw32 \
    --target=x86_64-unknown-linux-gnu \
    --prefix=`pwd`/_install \
    --disable-werror \
    --with-expat=no \
    --enable-sim \
    --enable-libdecnumber \
    --enable-libreadline \
    --enable-gas \
    --enable-binutils \
    --enable-ld \
    --disable-gold \
    --enable-gprof

$ make -j8
$ make install

ビルドが成功すると、build/_installディレクトリにWindows用のbinutilsのバイナリ(GDBも含む)がインストールされます。フォルダごとWindows側にコピーすれば動きます。ディレクトリの名前 _installはWindows側に持っていったあとに変更しても構いません。

比較的、新しい環境(Ubuntu 20など)だとMinGWが何か変らしく、gdb/common/common-defs.hにある _FORTIFY_SOURCEの定義を消さないと、リンクの時に __memcpy_chk() などの関数が見当たらないと言われてエラーになります。

比較的新しいMinGWでbinutilsをビルドすると遭遇するエラー
  CXXLD  gdb.exe
/usr/bin/x86_64-w64-mingw32-ld: ada-tasks.o:/usr/share/mingw-w64/include/string.h:202: undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: amd64-tdep.o:/usr/share/mingw-w64/include/string.h:202: undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: breakpoint.o:/usr/share/mingw-w64/include/string.h:228: undefined reference to `__strcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: breakpoint.o:/usr/share/mingw-w64/include/string.h:228: undefined reference to `__strcpy_chk'
...

とりあえず下記のパッチでエラーは回避できますが、おそらく正しい直し方ではありません。原因は調べていません。もしご存知の方は教えていただけると嬉しいです。

FORTIFY_SOURCEを無効化するパッチ

diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
index e574de5ed66..a9b0520b4c5 100644
--- a/gdb/common/common-defs.h
+++ b/gdb/common/common-defs.h
@@ -69,7 +69,7 @@
    then we don't do anything.  */

 #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
-#define _FORTIFY_SOURCE 2
+//#define _FORTIFY_SOURCE 2
 #endif

 #include <stdarg.h>

面倒であれば、ビルド済みのバイナリ(link binutils_x86_64-unknown-linux-gnu.zip)をどこか適当なディレクトリに展開してもらえれば動くはずです。Windows 10で動作確認しています。

Windows側の準備

Visual Studio Codeをインストールします。Microsoftのサイトからダウンロードできます(Visual Studio Code - Code Editing. Redefined)。

はじめにC/C++ Extensionをインストールします。GDBと連携するためです。


VSCode C/C++ Extensionのインストール画面

先ほどのテストプログラムが置いてあるディレクトリを開きます。メニューの [File] - [Open Folder] です。ここではZ:\projects\c\test_argvにあるとします。

左側のタブからRun and Debugを選択します。Ctrl + Shift + Dでも良いです。次に青いRun and Debugボタンを押します。するとSelect Environmentというコンボボックスが出てくるのでC++ (GDB/LLDB) を選択します。


Run and Debug


C/C++ (GDB/LLDB) を選択

ソースコードペインにlaunch.jsonのテンプレートが表示されると思うので、下記の内容に書き換えます。miDebuggerPathやmiDebuggerServerAddressは適宜、環境に合わせて書き換えてください。

launch.jsonの記述例

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "cwd": "${workspaceFolder}",
            "MIMode": "gdb",
            "miDebuggerPath": "c:\\app\\binutils\\bin\\x86_64-unknown-linux-gnu-gdb.exe",
            "miDebuggerServerAddress": "192.168.1.2:1234",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
                {
                    "description": "Relace absolute path of source code",
                    "ignoreFailures": false,
                    "text": "set substitute-path /home/katsuhiro/share/falcon z:/",
                },
            ],
        },
    ]
}

ここで大事なのはsetupCommandsのset substitute-pathです。gdbはLinux側の絶対パスでソースコードの場所を通知してくることがあります。Linux側の絶対パスを渡されてもWindows側ではファイルを探せませんから、絶対パスの一部をWindows側に存在するパスに置き換えることで、VSCodeがソースコードを見つけられるように設定してあげないと、こんなエラーで怒られます。


ソースコードの場所の設定に失敗しているとエラーが出る

今回の例では、

  • Linuxから見たテストプログラムのある場所: /home/katsuhiro/share/falcon/projects/c/test_argv
  • LinuxからSambaでWindowsに見せている場所: /home/katsuhiro/share/falcon
  • Windowsのリモートドライブレター: Z:
  • Windowsから見たテストプログラムのある場所: Z:/projects/c/test_argv

このような設定にしていますから、Windows側のネットワークドライブZ:/ が、Linux側の /home/katsuhiro/share/falconを指していることを伝えるために、上記の例のように "set substitute-path /home/katsuhiro/share/falcon z:/" にします。もし対応がわからない場合はSambaの設定を確認しましょう。

いざデバッグ

いよいよ最終目的であるLinux側のgdbserverと、Windows側のVSCode + GDBを連携させます。図示するとこのような構成です。


WindowsからLinuxアプリのデバッグ、それぞれの役割(再掲)

実際にやってみましょう。最初にLinux側でgdbserverを起動します。

Linux側の操作
$ gdbserver --multi localhost:1234 ./a.out a b c d

Process ./a.out created; pid = 15409
Listening on port 1234
Remote debugging from host ::ffff:192.168.1.112, port 64957

★mainでbreakしたあとcontinueすると下記が出力される

argc: 5
argv[1]: aa
argv[2]: bb
argv[3]: cc
argv[4]: dd
 
Child exited with status 0

その後、VSCodeでmainにブレークポイントを設定します。F5キーを押してデバッグ開始すると、main() 関数で停止し、ソースコードが表示されるはずです。


Windows側からデバッグできている状態

うまくいきました、良かった良かった。

繋がらないときは

Unable to start debugging. Unexpected GDB output from command... のように言われて、デバッグできない場合は、

  • miDebuggerPathの場所にx86_64-unknown-linux-gnu-gdb.exeはあるか?
  • miDebuggerPathに指定したファイルはコマンドプロンプトなどから実行可能か?
  • miDebuggerServerAddressは正しいか?
  • gdbserverを起動し忘れていないか?
  • Windows用のGDBからtarget remote [miDebuggerServerAddressに指定したアドレス] としたとき繋がるか?

上記を今一度チェックしてみてください。特にgdbserverはデバッグの度に毎回起動しなければなりません。割と忘れがちです。これ非常に面倒なので、改善方法が既にありそうな気がします(今はわかりません)。

Windows要らなくない?

そこに気づかれましたか、鋭いですね、おっしゃる通りです。私もbinutilsをビルドし終わった辺りで、もしやVSCodeをLinux側で動かせば何の苦労もなかったのでは?と気づきましたが、遅すぎたのでここまで突っ走りました。正直、Windowsを使うだけ面倒で、何も利点がないです。なるほど、この方法を実践している人が誰もいないわけです。

Windowsからデバッグだけする方法が向いている人、環境ですか……?うーん、ほとんど居ないと思いますが、強いていえばLinux PCのGUI環境を整備しておらず、整備も面倒と思っていて、普段遣いのWindows PCしか持っていないような方でしょうか。この手順も大概面倒くさいけどね。

編集者:すずき(2023/12/25 19:10)

コメント一覧

  • 名無しさん(2022/01/13 17:10)
    setupCommandsに"text": "shell ssh remoteHost gdbserver :1234 a.out ${args[@]}"}\nlocalなら、\n{"text": "shell gdbserver :1234 a.out ${args[@]}"}\n
  • すずきさん(2022/01/14 09:16)
    なるほど。setupCommandsでgdbserverを起動できるんですね。コメントありがとうございます。
open/close この記事にコメントする



2021年3月3日

VSCodeを使ってWindowsからLinuxアプリのデバッグ その1

目次: Linux

その1その2

同じことをしている人があまり居なさそうだったので、メモしておきます。

きっかけはGCCのコードをGDBのCUIモードで追っていて辛くなったことです。GCCのコードは超ぐちゃぐちゃの悲惨なコードで非常に追いづらく、GDBをもってしても何が起きているのか把握するのは困難です。せめてデバッガの画面くらいはGUIにして、見やすくできないか、と考えました。


WindowsからLinuxアプリのデバッグ、それぞれの役割

想定する構成は上記のとおりで、Linux側にはGUIがなく(ディスプレイを繋いでいない、など)、Windows側はデバッグのみで、Linux側でその他の全て(ビルドなど)を行う想定です。

Linux側の準備

この記事を読んでいるということは、既に何かデバッグしたいアプリケーションがあると思いますから、基本的なツールであるgccやmakeなどのインストールは省略させてもらいます。gdbserverをインストールするだけで良いはずです。

gdbserverのインストール
# apt-get install gdbserver

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  gdbserver
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/458 kB of archives.
After this operation, 1165 kB of additional disk space will be used.
Selecting previously unselected package gdbserver.
(Reading database ... 99167 files and directories currently installed.)
Preparing to unpack .../gdbserver_8.2.1-2+b3_amd64.deb ...
Unpacking gdbserver (8.2.1-2+b3) ...
Setting up gdbserver (8.2.1-2+b3) ...

デバッグするプログラムは何でも良いですが、下記を使用します。渡した引数を表示するだけのプログラムです。

デバッグ対象のプログラム、ソースコード

#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("argc: %d\n", argc);

	for (int i = 0; i < argc; i++) {
		printf("argv[%d]: %s\n", i, argv[i]);
	}

	return 0;
}
デバッグ対象のプログラム、実行結果
$ gcc -Wall -g -O0 a.c

$ ./a.out a b c

argc: 4
argv[1]: a
argv[2]: b
argv[3]: c

まずは普通にCUIからGDBで追ってみます。図示するとこのような構成です。


GDBでLinuxアプリのデバッグ

あえてやる必要もなさそうですけど、このあとの一貫性のために試します。

GDB CUIデバッグ
$ gdb a.out

...
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...

(gdb) b main

Breakpoint 1 at 0x1144: file a.c, line 5.

(gdb) r a b c d

Starting program: /home/katsuhiro/share/falcon/projects/c/test_argv/a.out a b c d

Breakpoint 1, main (argc=5, argv=0x7fffffffdca8) at a.c:5
5               printf("argc: %d\n", argc);

(gdb) c

Continuing.
argc: 5
argv[1]: a
argv[2]: b
argv[3]: c
argv[4]: d
[Inferior 1 (process 4008866) exited normally]

普通です。次はgdbserverと連携させリモートでGDBで追ってみます。図示するとこのような構成です。


gdbserver + GDBでLinuxアプリのデバッグ

実際にやってみましょう。ターミナルを2つ用意してください。

GDB CUIリモートデバッグ
★★ターミナル1つ目

$ gdbserver --multi localhost:1234 ./a.out a b c d

Process ./a.out created; pid = 4008908
Listening on port 1234
Remote debugging from host ::1, port 32918

★mainでbreakしたあとのcontinueを実行すると下記が出力される

argc: 5
argv[1]: a
argv[2]: b
argv[3]: c
argv[4]: d
 
Child exited with status 0


★★ターミナル2つ目

$ gdb

...
For help, type "help".
Type "apropos word" to search for commands related to "word".

(gdb) target remote :1234

Remote debugging using :1234
Reading test_argv/a.out from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading test_argv/a.out from remote target...
Reading symbols from target:test_argv/a.out...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/5b/e47e85c990f390b0dccb6ca9dc3e70f410dc6a.debug...
0x00007ffff7fd3090 in _start () from target:/lib64/ld-linux-x86-64.so.2

(gdb) b main

Breakpoint 1 at 0x555555555144: file a.c, line 5.

(gdb) c

Continuing.
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...

Breakpoint 1, main (argc=5, argv=0x7fffffffdd18) at a.c:5
5               printf("argc: %d\n", argc);

(gdb) l

1       #include <stdio.h>
2
3       int main(int argc, char *argv[])
4       {
5               printf("argc: %d\n", argc);
6
7               for (int i = 1; i < argc; i++) {
8                       printf("argv[%d]: %s\n", i, argv[i]);
9               }
10

(gdb) c

Continuing.
[Inferior 1 (process 4008908) exited normally]

ブレークもできますし、ソースコードも表示されます。良い感じですね。

使い勝手はGDB単体でデバッグするときとほぼ同じですが、1点だけ注意があります。デバッガとして動作するのはgdbserverであり、プログラムのprintfなどの標準出力は、gdbserverを動かしているターミナル側に出ることに注意してください。この使い方におけるGDBはgdbserverと通信するだけの役です。

Sambaのセットアップについては、ここで解説せずとも、詳しいサイトがたくさんあると思いますので、そちらをご参照ください。

思ったより長くなってきたので、続きは次回に。

編集者:すずき(2023/04/29 21:35)

コメント一覧

  • Shigeさん(2021/06/17 13:28)
    とても参考になりました。
    Good!!!
  • すずきさん(2021/06/17 17:24)
    お役に立てたようで幸いです。
open/close この記事にコメントする



2021年2月28日

JIS配列キーボードとOADG配列キーボード

今まで、いわゆる日本語配列のキー配列のことを漠然とJIS配列と呼んでいましたが、どうもこれは正確ではないようです。

技術者たるもの、規格を粗末に扱ってはいけませんよね??

JIS配列を定めているのはJIS X 6002-1980「情報処理系けん盤配列」です。この配列を見ると一目瞭然ですが、アルファベット、スペースなどは一致するものの、他のキーは全く違う位置にあったり、そもそもなかったりします。規格書は有料(1,100円)ですが、PFUのサイトでJIS配列の図をタダで拝めます。


JIS X 6002のキーボード配列(PFUのサイトより)

PFUのサイトへのリンク:
https://www.pfu.fujitsu.com/hhkeyboard/pfutechreview/section3.html

現状、主流の日本語キー配列はOADG(The PC Open Architecture Developers Group)が規格化した配列です。OADGは2004年に解散していますが、規格書はInternet Archiveで見ることができます。

Internet Archive: OADGテクニカル・リファレンス ハードウェア編1991年へのリンク:
https://archive.org/details/OADG1991/

規格の付録Aを見ると、

  • OADG 104型(英語配列)
  • OADG 109型(日本語配列)
  • OADG 109A型(109型と同じだが、- や ^ キーの刻印が違う)


OADG 104型(英語配列)


OADG 109型(日本語配列)


OADG 109A型


OADG 109型(109A型と異なる部分を示した)

の3つが書かれています。市販のキーボードは、各社ともに適当に魔改造しているため、OADG規格と全く同じキー配列のキーボードは存在しないと思います。たぶん。

実例を出すと、Logicool K295はかなり109Aに近いです。しかし、右Windowsキーが欠けています(このタイプ、俗に108キーなどと呼ばれていますね)。


Logicool K295のキー配列

FILCO Majestouchも素直な109Aに近いですが、右Appキーがなく、右WindowsキーがFnキーに置換されています。


FILCO Majestouch Convertible 2のキー配列

私の場合は、最下段は 左Ctrl, 左Win, 左Alt, スペース, 右Alt, 右Ctrlしか使わないので、K295やMajestouchのように使わないキーが欠けていても気になりませんが、使う人からすると、何てことするの!?という気分になるでしょう。

さらに言うと、無変換、変換、ひらがなキーも使わないので、使っているキーの種類だけ考えたら、いわゆる英語配列(OADG 104型)で十分に思えます。しかし日本語配列で練習したため、英語配列は記号類を間違えまくります。私物で購入したことはありません。打てて損はないので、もうちょい修行しても良いかもしれませんね……?

メモ: 技術系の話はFacebookから転記しておくことにした。写真追加、加筆。

編集者:すずき(2021/03/05 18:34)

コメント一覧

  • hdkさん(2021/03/05 21:43)
    109と109Aって、かなの記号も違うんですよ。"P"のあたりにある"『""』"なんかがなくなっていますよね。勝手な想像では、主流のWindowsで入力できないから消しちゃったんだと思いますが... ThinkPadでいうとX20とX30のところで違いが見られるようです。
    OADG誕生前のIBM JXではこのへんの記号も入力できていましたし、\と¥や〜と ̄が刻印どおりに区別されていました。(なおJXは英文モード対応の関係なのか、英語部分はUS配列だったので、位置が違いますが。)
  • すずきさん(2021/03/06 00:21)
    ですね、その辺りも違います。違いを全部示すつもりはなかった(本文と関係ないし)のですが、下手に赤丸で囲ったのが良くなかったか……。
open/close この記事にコメントする



2021年2月27日

新キーボード購入

先日の在宅勤務環境改善(2021年2月12日の日記参照)にて、デュアルディスプレイにしたところ、ノートPC本体が邪魔になってしまったので、机の上からどけました。

当然、ThinkPad本体のキーボードには手が届きませんから、ワイヤレスキーボードLogicool K295を買いました。Amazonで1,900円くらいでした。K295は変なキーも少ないし、静かで良いですが、キーの認識が渋いです。私の場合、打鍵力が足りず人差し指担当のキー(T, Uなど)の誤打が多発してイライラします。

買ってすぐ買い替えるのもどうかと悩みましたけど、あまりに誤打が多く慣れるまで辛そうだったので、さっさと諦めFILCOのMajestouch赤軸を買いました。ヨドバシで15,000円くらいでした。Majestouchはキーが戻るとき&底打ちしたとき「カーン!」と響く鐘のような音がやかましい以外は、非常に良いキーボードです。

キーボード使用歴

今まで、キーボードは標準的なキーボード(※)であれば、高くても安くても使い心地が気になることはないと思っていました。しかし今回K295がどうも合わなかったことから、実は自分とキーボードの相性って結構あるのか?と疑問に感じるようになりました。

(※)OADG 109A型の配列で、カーソルキー、ファンクションキー等の位置を移動していないキーボードのこと。

まずはキーボードの使用履歴を書き出してみます。

相性とか全く気にならなかった。

  • DELLの標準キーボード
  • Gatewayの標準キーボード
  • HPの標準キーボード
  • IBM/Lenovo ThinkPad X, Eシリーズ
  • Logicool K270
  • Majestouch赤軸
  • NEC VersaPro
  • Owltechの安いキーボード
  • RealForce 108UBK
  • サンワサプライの安いキーボード
  • SONY VAIO Type-G
  • TOSHIBA Dynabook R73

誤打しやすかった。

  • Let's Noteシリーズ(理由: キーの形が横長)
  • Logicool K295(理由: キーの認識が渋い)
  • Logicool K340(理由: カーソル、ファンクションキー配置が変)

まともに打てなかった。

  • HappyHacking(理由: キー配置が変すぎる)

以前K340やHHKで懲りて、特殊なキー配列のキーボードに触らなくなったので、コンパクト系のキーボードの利用歴はほぼゼロです。そもそもまともに打てないし、レビューできません。

ほとんどPC付属キーボード、ノートPCのキーボードばかりです。これはもしや、勝手に安物だと思いこんでいたPC付属の標準キーボード、実は質が高かったのではなかろうか?

大事な製品に標準で付属するものですし、高級ではないにせよ、あまりに変なものはつけませんよね。これが答えなのでは、という気がしてきました。

編集者:すずき(2021/02/28 03:50)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2021年3月8日 >>> 2021年2月27日
link もっと後

管理用メニュー

link 記事を新規作成

<2021>
<<<03>>>
-123456
78910111213
14151617181920
21222324252627
28293031---

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事3件

  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www2.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/20 02:52