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年 3月 8日 03:23)

コメント一覧

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



2021年 3月 6日

気に入るマウスはどれ?

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

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

  • 2004年 12月: Logitech Optical Mouse USB M-UV96
  • 2007年 1月: Logicool Nono 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 から転記しておくことにした。マウス遍歴を追加。

編集者: すずき(更新: 2021年 3月 8日 03:58)

コメント一覧

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



2021年 3月 4日

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

その 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'
...

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

FORIFY_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 しか持っていないような方でしょうか。この手順も大概面倒くさいけどね。

編集者: すずき(更新: 2021年 3月 7日 12:36)

コメント一覧

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



2021年 3月 3日

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

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

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

編集者: すずき(更新: 2021年 3月 7日 12:36)

コメント一覧

  • コメントはありません。
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年 3月 5日 18:34)

コメント一覧

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

コメント一覧

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



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

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 4/20 02:25

カレンダー

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

最近のコメント 5件

  • link 21年04月12日
    すずき 「コメントありがとうございます。ご参考にな...」
    (更新:04/18 22:39)
  • link 21年04月12日
    たくじ 「こんにちは。\n記事読ませていただきまし...」
    (更新:04/16 17:22)
  • link 21年02月28日
    すずき 「ですね、その辺りも違います。違いを全部示...」
    (更新:03/06 00:21)
  • link 21年02月28日
    hdk 「109と109Aって、かなの記号も違うん...」
    (更新:03/05 21:43)
  • link 21年02月14日
    すずき 「そうですね、1年だけとか、出張の時だけ、...」
    (更新:02/15 11:27)

最近の記事 3件

link もっとみる
  • link 21年04月16日
    すずき 「[ドキュメントスキャナーで書類を電子化] 我が家の本棚は広い方では...」
    (更新:04/20 02:25)
  • link 21年04月12日
    すずき 「[Zenfone+ahamo にしたらハマった] ドコモがついに...」
    (更新:04/13 17:54)
  • link 21年04月06日
    すずき 「[ディスプレイアーム] 机の奥行きが 60cm のためか、ディスプ...」
    (更新:04/12 11:18)

こんてんつ

open/close wiki
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 過去日記について

その他の情報

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