XRDP で「変換」キーが入力できるように対応した

※ 「XRDP で「変換」キーが入力できるように対応した — その後」へ続きます。

あきらは Xubuntu 14.04 に X11RDP-o-Matic で XRDP 導入して Windows 10 のリモートデスクトップ接続で操作しています。

Microsoft の RDCMan だと、リモートデスクトップ接続で高 DPI 環境に対応できそうだとの情報を掴んだので、Surface Pro 3 で試したところ、表示は対応出来たのですが、「変換キー」が入力できませんでした。自分は漢字入力を Mac 風のキーバインドにしているため、変換・無変換キーが使えないと不便でしかたありません。

2日ほど色々調べて、設定ファイルを修正するだけで対応できることが判明しました。
原因は xkeyboard の base ルールの pc105 で、XF86AudioMedia が Henkan を上書きしてしまう事でした。
現在では evdev ルールが主流で、そちらでは同様の問題は無いため何年も放置されているようです。

以下、X11RDP-o-Matic で XRDP を導入している場合の修正内容です。その他の方は参考にして下さい。

/etc/xrdp/xrdp_keyboard.ini

--- xrdp_keyboard.ini.orig	2016-06-24 17:51:44.169447686 +0900
+++ xrdp_keyboard.ini	2016-06-24 07:44:47.317894018 +0900
@@ -98,7 +98,6 @@ layouts_map=rdp_layouts_map_mac
 [rdp_keyboard_jp]
 keyboard_type=7
 keyboard_subtype=2
-model=jp106
 rdp_layouts=default_rdp_layouts
 layouts_map=default_layouts_map
 

/usr/share/X11/xkb/rules/base

--- base.orig	2016-06-24 02:17:08.041738858 +0900
+++ base	2016-06-24 02:02:05.621268995 +0900
@@ -954,13 +954,16 @@
   tm2030USB-106 =       +inet(media_nav_acpi_common)
   trust_slimline =      +inet(media_nav_acpi_common)
   vsonku306     =       +inet(microsoftprooem)
-  $inetkbds     =       +inet(%m)
   $maclaptop    =       +inet(apple)+level3(enter_switch)
   $applealu     =       +inet(apple)
   $macs	        =       +inet(apple)
   sun_type7_jp_usb	=	+sun_vndr/solaris(defaults_type7jp)
   $sun			=		+sun_vndr/solaris(defaults)
 
+! model		layout		=	symbols
+  $inetkbds     jp              =       +inet(jp109)
+  $inetkbds     *               =       +inet(%m)
+
 ! layout	variant		=	compat
   de		neo			=	+caps(caps_lock)+misc(assign_shift_left_action)+level5(level5_lock)
   jp        $sun_compat =   complete+japan(kana_lock)

/usr/share/X11/xkb/symbols/inet

--- inet.orig	2016-06-24 16:47:59.730480262 +0900
+++ inet	2016-06-24 07:49:02.387162449 +0900
@@ -1846,6 +1846,12 @@ xkb_symbols "pc105" {
     include "inet(media_nav_acpi_common)"
 };
 
+partial alphanumeric_keys
+xkb_symbols "jp109" {
+    include "inet(media_nav_acpi_common)"
+    key  { [ Henkan ] };
+};
+
 //Intelligent Keyboard K04
 partial alphanumeric_keys
 xkb_symbols "intelligent_keyboard_k04" {

/opt/X11rdp/share/X11/xkb/rules/base

--- base.orig	2016-06-24 02:13:19.832611586 +0900
+++ base	2016-06-24 07:50:04.619465134 +0900
@@ -1012,11 +1012,14 @@
   tm2030USB-106 =       +inet(media_nav_acpi_common)
   trust_slimline =      +inet(media_nav_acpi_common)
   vsonku306     =       +inet(microsoftprooem)
-  $inetkbds     =       +inet(%m)
   $maclaptop    =       +inet(apple)+level3(enter_switch)
   $applealu     =       +inet(apple)
   $macs	        =       +inet(apple)
 
+! model		layout		=	symbols
+  $inetkbds     jp              =       +inet(jp109)
+  $inetkbds     *               =       +inet(%m)
+
 ! layout	variant		=	compat
   de		neo			=	+caps(caps_lock)+misc(assign_shift_left_action)+level5(level5_lock)
 

/opt/X11rdp/share/X11/xkb/symbols/inet

--- inet.orig	2016-06-24 02:14:02.548823251 +0900
+++ inet	2016-06-24 00:36:19.415751019 +0900
@@ -1825,3 +1825,9 @@ partial alphanumeric_keys
 xkb_symbols "pc105" {
     include "inet(media_nav_acpi_common)"
 };
+
+partial alphanumeric_keys
+xkb_symbols "jp109" {
+    include "inet(media_nav_acpi_common)"
+    key  { [ Henkan ] };
+};

※ 「XRDP で「変換」キーが入力できるように対応した — その後」へ続きます。

Surface Pro 3 で PA-WG1400HP の 5GHz に接続すると悲劇的に遅い対策をした

以下の理由でやっと 5GHz 帯の無線LANルータへ変更することに決めました。

・仕事用のフレッツADSL と家庭用(主に子供の YouTube 用)の WiMax2+ を契約していたが、解約してフレッツ光に一本化した
・わが家も 5GHz 帯対応の機器が多くなってきた
・電子レンジの影響がうっとおしくなってきた
・現状の 2.4GHz 帯では、たまに無線 LAN が 0.1MHz にまで遅くなり、仕事にならない

PA-WG1400HP への変更はわりとすんなりと出来たのですが、Surface Pro 3 を 5GHz に接続すると速度がやっと 1MHz の状況でした。
色々ネットを調べてみたのですが、これといった情報は無く、ルーターとの相性じゃないかとの情報ばかりでした。
iPad / iPod touch / SHL22 (スマホ) / ASUS X205TA と、他の 5GHz 対応の機器は問題ないので、なんとかならないかとルータの設定を確認すること数時間、やっと回避策が見つかりました。

http://aterm.me/
トップページ > Wi-Fi(無線LAN)設定 > Wi-Fi詳細設定(5GHz)
「クワッドチャネル機能」を「使用しない」に設定

お試しください。

HWD15 で WiMax 2+を安定させる

Windows 10 にアップグレードして HWD15 で WiMax 2+ を使うと、ネットワークが切断され、ネットワークの検出も出来なくなり、再起動するしかない状態に何度も陥った。
色々調べた結果、HWD15 の設定画面をブラウザで開いて、802.11g/b/n から 802.11g/b に変更し、802.11n を使わないようにすれば良いようだった。

設定を変更した後は安定して使用できている。

実はわが家の ADSL はせいぜい 4Mbps なので、WiMax 2+ で夜中だと倍の速度で通信できてしまう。
まぁ状況によっては大きく落ち込むのが WiMax 2+ の速度なので、平均すると ADSL と同じくらいだろう。

それにしても米子市なんて片田舎でも無線が ADSL を凌駕するなんて、すごい時代となったもんだ。

X11RDP-o-Matic のご紹介

明けまして、おめでとうございます。

お年玉と言うわけではないんですが、X11RDP-o-Matic をご紹介いたします。

詳しくは上記のページをご覧になっていただくとして、アキラは Xubuntu 14.04 で正常に動作することを確認しています。
標準パッケージの XRDP の場合には、セッション終了時に RDP クライアントの画面が閉じなかったりするため、安心して使用できませんでした。
X11RDP-o-Matic を使ってインストールすると、上記の不具合もなく、レスポンスも良いと思います。

開発は GitHub を使って行われているため、変更リクエスト(Pull Request: PR)も比較的簡単にできます。
また、Google グループ で相談することもできます。

あきらは今回 GitHub を初めて知りました。
勉強がてら XRDP の日本語キーボード対応の PR を送ってみたところ、採用していただきました。
開発版(develブランチ)で、”\ _”キーと変換キーが正しく入力できるように対策しています。

上記を含めた XRDP & X11RDP のインストール手順は以下となります。

$ sudo apt-get install git
$ git clone --depth 1 -b v3.03 https://github.com/scarygliders/X11RDP-o-Matic.git
$ cd X11RDP-o-Matic
$ sudo ./X11rdp-o-matic.sh --branch devel --justdoit

“–branch devel” の部分を追加するだけです。develブランチとなりますが、十分安定しているように思います。

追記 (2015/02/24)

現時点で上記の変更は master ブランチにマージされています。
“–branch devel” は必要無くなりました。

VAIO Pro 11 を自分なりに活用するまで

以前、持ち運び用に使っていたノートパソコンのバッテリーがへばってきてしまったのですが、Ultrabook 仕様のため、簡単にバッテリーを交換する事ができませんでした。
また、ちょっといいノートパソコンを買ってもいいよと嫁さんが言ってくれたので、ヤマダ電機の店頭で触った VAIO Pro 11 を、ほぼ衝動買いしてしまいました。
実はたまたま CPU ファンが低温時に回って高温時に止まるという初期不良に当たってしまい、購入して1週間で交換してもらったのですが、その後はハードウェアの不具合は発生せず、便利に使っています。

最近、Linux Mint 17 の使い勝手が良かったので、VAIO Pro 11 に入れてデュアルブートにしたくなりました。その際に経験した問題の解決方法をメモしておきます。

■ リカバリーディスクの作成

購入時に初期設定を済ませたら、リカバリーディスクを作成しておきましょう。あきらは外付け DVD ドライブで 4 枚の DVD を作成しました。どうも長期保存に USB メモリや SD カードを使いたくないんですよね。消えてしまいそうで。

Windows 8 モデルでしたので 8.1 にアップデートしましたが、その時点で以下のようなパーティションとなっていました。

・#1 SONYSYS
・#2 回復パーティション
・#3 EFI 用パーティション
・#4 Windows 予約領域
・#5 C ドライブ
・#7 回復パーティション
・#6 リカバリー領域 14.14GB

■ ディスク容量を確保するまで

以下の手順で LinuxMint 用の領域を確保します。

・リカバリー領域の削除
・不要な回復パーティションの削除
・C ドライブのリサイズ

■ リカバリー領域の削除

まず、Windows 8.1 にアップデートするとリカバリー領域でのリカバリーはできなくなります。つまり、無駄な領域となりますので削除します。
参考URL : http://www.call-t.co.jp/blog/mt/archives/entry/015676.html

■ 不要な回復パーティションの削除

Windows 8.1 へのアップデート時に、C ドライブの後ろに勝手に作成されました。C ドライブを縮小して後ろに空き領域を作る際に邪魔となるのですが、下手にいじるとブートできなくなります。また、以前の回復パーティションは十分な容量なので、作成されるのは明らかにインストーラーのバグです。なんとかこのパーティションが削除できないかと調べました。

LinuxMint 17 の DVD で起動して、以下を行います。

・古い回復パーティション(#2)の Recovery/WindowsRE フォルダを削除
・新しい回復パーティション(#7)の Recovery/WindowsRE フォルダを、古い回復パーティション(#2)の Recovery/WindowsRE フォルダとしてコピー

Windows 8.1 で再起動して、コマンド プロンプト(管理者) で以下を実行します。

reagentc /disable
reagentc /setreimage /path \\?\GLOBALROOT\device\harddisk0\partition2\Recovery\WindowsRE\winre.wim
reagentc /enable

正しく再起動できることを確認します。

参考URL : http://answers.microsoft.com/ja-jp/windows/forum/windows8_1-windows_install/win881%E3%81%A7%E5%9B%9E%E5%BE%A9%E3%83%91/c8970d3a-2c52-41c8-9c91-b76e4516b254?page=2

■ C ドライブのリサイズ

再び LinuxMint 17 の DVD で起動して、GParted で以下を行います。

・新しい回復パーティション(#7)の削除
・C ドライブ(#5)を可能な限り拡張(後ろに 36GB を確保するための仮作業)
・C ドライブ(#5)のリサイズ(後ろに 36GB を確保しました)
・C ドライブ(#5)のリサイズに時間がかかるため、操作を適用しておく

・LinuxMint 用 / パーティション作成(32GBとしました)
・LinuxMint 用 swap パーティション作成(4GBとしました)

■ LinuxMint のインストールと rEFInd のインストール

以下のサイトで詳しく解説されています。大変参考になりました。ありがとうございます。

参考URL : http://qiita.com/rit-rit/items/5adefbd7d4876f0917c3

「Ubuntuのインストール」以降の作業で継続します。

Linux のリモートデスクトップを検討

相変わらず Web システムの開発を行っているわけですが、最近ではリモートデスクトップで VPS の開発用サーバにログインして、作業を行っています。
ファイルの転送は、開発がひと通り終わった後に実サーバへアップロードする1回のみです。
以前はローカルで修正して開発用サーバにアップロードして動作確認後、ローカルから実サーバへアップロードしていたのですが、誤って開発用サーバにアップロードしてしまって実サーバが更新されなかったり、開発用サーバを直接修正したのにローカルのファイルを実サーバへアップロードしてしまって元の状態に戻ってしまったりといった単純ミスが発生していました。

ともあれ、現状の手順だと開発用サーバで IDE(Eclipse) と FTP ソフト (Filezilla) が使いたいため、リモートデスクトップは必須です。

で、色々試した結果、XRDP を選択しました。XRDP にしたのは以下の理由です。

・NX Client がアップデートされて、FreeNX のクライアントとして使えなかったり使いづらくなったりしてしまった。旧バージョンは購入済みの顧客対象に公開されるようになってしまった。
・X2Go のクライアントが安定しない。複数のセッションを立ちあげれない。
・RDP であれば現状でクライアントは困らない。Windows では標準で準備されており、Mac だと Microsoft が無償で提供している。

設定などで注意する点です。

・ポートは標準の 3389 から変更
・レスポンスを考慮して色は 16 ビットにしておく

Skype for Windows が改良されていた

パソコンをシャットダウンする際に、「このアプリケーションがシャットダウンを妨げています」と表示されていたのですが、すんなりシャットダウン出来るようになっていました。
もしやと思って確認すると、Skype for Windows がアップデートされていました。やはりコイツが犯人だったようです。

ありがとうと思う反面、もっと早く対応してくれれば良かったのにと思ってしまうのはしょうがないですよね。

PHP5 の basename 関数のバグ対応

PHP5 の basename 関数にはバグがあり、ファイル名が日本語を含むとうまく処理できません。
ググってみると代替え関数を用意する方法が多く提案されていましたが、あきらは以下の置き換えで対処しました。

basebane( $path )

preg_replace( '/^.*\//u', '', $path )

最長一致がデフォルトなので上手く動きます。