Windows10 で EP-802A


Windows10 に更新したら普段使いの EP-802A プリンタの問題に出遭いました。
ドライバ等を更新してみても、印刷はできるもののインク残量が見えないという症状で苦戦させられました。これらはネットワーク使用でつかっています。
SymantecやWindows Firewall などの無効化を試してみても問題は解決しませんでした。

機種としてはずいぶん前のものなので正しく Windows10 対応できていなくても仕方なく、これは買い換えも覚悟していたのですが、なんとか対処することができたので一安心です。

検索してみると同じように悩んでいる人もいそうだったので、自分の解決法を公開しておきたいと思います。

やったこと

ドライバをメーカーのページからダウンロードしてインストール

  • プリンタドライバ
  • スキャナドライバ
  • EPSON プリンターウィンドウ3 (ネットワークモジュール)

これらを最新版で試したのですが、前述の通りインク残量が確認できませんでした。
ファイアウォールの設定を無効化してみても改善しなかったのであきらめかけていました。

このとき、プリンタの接続ポートの情報が、 WSDポート に接続されたものでした。
EPSON のネットワークプリンタ設定だと、 EpsonNet Print Port に設定されるという情報を元に、こちらを使うように変更を試みたところうまくいきました。

そのようにする手順は簡単で、メーカーのドライバ類のダウンロードのページで、
「EpsonNet Print」という別の印刷ユーティリティソフトをダウンロードしてインストールを行います。

これをインストールした後で、プリンタのプロパティでポートの追加を選んで、
この EpsonNet Print を選択して切り替えてあげれば、無事にインク残量を確認できるようになりました。

まとめ

最近の EP シリーズは小型になったようですし、ぼちぼちと買い直ししたほうが、トラブル少なくて済むのかなと思いました。
意外と同症状で困っている人が多いみたいなので、この記事で解決できるようでしたら幸いです。


Ubuntu で DirectFB が試せないかテストしてみました。


DirectFB なるものの存在を今更知ったので動くか確認してみました。(ほんとに今更・・・)

必要なもののインストール

設定

.directfbrc という設定ファイルに以下の内容を記述します. こうしないとエラーが起こってしまいました。
こうしておくと X11 の上で動作させることが出来ました。

サンプルコード

StackOverflow かどこかで公開されていたコードを試してみました。 続きを読む



Git LFS を使ってみる


Git はソースコードの管理ツールのため、巨大なバイナリファイルの扱いが苦手でした。これに対応すべく開発されたのが LFS: Large file storage という機能です。
今回はこれをインストール&触ってみたいと思います。なお環境はすでに git for windows がインストールされた環境で行っています。

ちなみにこの記事の内容は Git for windows 2.7.2, git-lfs 1.1.1 を用いての内容となってます。バージョンが異なる場合、以下の内容とは変更になっている可能性があるのでご注意ください。

GIT LFSについて

扱いとしては git のエクステンションという形になってます。
提供する機能は、指定されたファイルタイプの場合に特殊な処理を行うようになります。
この処理というのが、バイナリファイルを指し示すリンクをソースコードの場合と同じように保持するようにして、バイナリファイル自体はそのリポジトリとは別の場所に管理させる、というようなものです。

このLFSですが、前身になるようなものとして、git-media, git-fat などがありました。これらを使用していた人は同じようなものだと考えてもらってよいと思います。
LFSのメリットはすでにGitHub や、ほかのホスティングサービスも対応を始めているため、バイナリファイルの扱いに対して準標準を得られるのでは、というところもあるかと思います。

git lfs のインストール

https://git-lfs.github.com/ からインストーラーをダウンロードします。
この記事を書いているときには、 git-lfs-windows-1.1.1.exe でした。
このインストーラーをダブルクリックで起動してインストールを行っていきます。

インストールする場所ですが、 Git for windows をインストールしたフォルダで、
mingw64/bin 以下になるようにします。以下の図では標準の場所を指していますが、Git for Windows を別の場所にインストールしている場合ではここを修正する必要があります。
(現時点ではすでにインストールされているgit のインストールパスは探索されない模様)

インストールが終わって Git Bash を開き、以下のコマンドを実行します。

このように表示されればOKです。 git lfs init というコマンドもあったようですが、廃止扱いになっており、今は git lfs install が正しいようです。

動作を確認してみる

まずは適当な git リポジトリを用意して、動作を確認していきたいと思います。

Git lfs では LFS として管理させるファイルタイプを選択、設定します。
ここでは、よく使う画像ファイルを登録したいと思います。
この登録は以下のようなコマンドによって行います。

これらの情報は .gitattributes に格納されます。上記の実行結果で以下のようになっていました。

この .gitattributes ファイルを開かずとも、 git lfs track コマンドで確認することもできます。

さて登録したタイプにあうような適当なファイルをコミットしてみます。
ここでは png のファイルを追加・コミットしてみます。
以下のように行いましたが、これは通常の git のファイル追加・コミットと変わらないです。

これが LFS の管理になっているかどうかを確認するのに以下のコマンドを実行します。

正常に機能していれば上記のように、ファイル名とその何らかのハッシュ値が表示されます。

リモートリポジトリとのアクセス

ローカルでの機能確認ができたら、リモートとのアクセスを試してみたいと思います。
現時点では GitHub は、 1GB までは無料でLFSが使えるようなのでこちらを利用したいと思います。

GitHub で新規のリポジトリを作成し、そのリポジトリをリモートするように今回のリポジトリを設定しておきます。

そして普通に git push origin master を実行してみます。

というように普通に成功しました。
(ほかの設定も必要なのではと思っていましたので意外でした)

さて、正常にあがったところでこのリポジトリを別の場所で clone してみたいと思います。新規に取得してみることが目的なので、別PCでやってもかまいません。

内部的には追加したバイナリファイルは単なるテキストファイルに変わっています。
しかし、clone,pull などのコマンド実行の際には、LFSがうまく実行され、バイナリファイルが復元されます。

などと表示されている行がまさにバイナリファイルを取得している状態を示しています。

まとめ・感想など

準公式での巨大バイナリデータに対する対策が入ったことは大きいと思います。
最低限の LFS の動作を確認してきましたが、Git をコマンドで扱っている人にとってはすでに実用になるかなと思います。

tortoisegitとの組み合わせについて

1.8.16.0 のバージョンを使っている場合での話になりますが、ちょっとまずい点がありそうです。
「 TortoiseGit commit with git-lfs files, show me a error: “.git/index.lock” file exist」
というエラーがあるようで、これが 1.8.16.4 かそれ以降のバージョンで修正されるようです。

バイナリ状態がちょっと怪しい挙動

バイナリファイルを含むリポジトリを clone した際にバイナリファイルが復元されないケースがありました。このときファイルを試しにテキストエディタで開いたら以下のようになっていました。

このときバイナリデータの復元はどうするかというと、以下のコマンドによって復元(再取得)が行えます。

これによりデータが元のバイナリデータとして復元されます。

このような状態に陥っているときには、バイナリファイル復元した状態がすでに変更状態と見なされてしまうようで、最低限のデータ取り出しを行ったら、新規にリポジトリを作成・取得し直しといったことを行った方がよさそうでした。

対応プロトコルについて

Git LFSは大容量ファイルに対するサブのリポジトリを作ってそこにデータを放り込みます。このときの通信は http となるようで、前身の git-media のほうが対応種類が多くて状況によって適切に使い分けができた気がします。LFSもまた対応が広がってくれるとうれしいのですが。

LFSによる前提の崩壊?

従来からの使用者の感覚としては、ソースコードと大容量ファイル、それぞれ別管理という印象が強いですが、この機能が標準になってさえしまえば、これらをまとめた単位がリモートのリポジトリという1つのまとまりという認識に変わりそうです。
1つ気になった点としては、LFSリポジトリ(別の置き場を今はこう呼んでおきます)ができて、ここから必要なデータだけを復元するやり方によって、
開発者全員が全てのリポジトリデータのクローンを持つわけではなくなったと考えられます。
そのため、少々強引な表現ではありましたが「分散リポジトリだから開発者全員が同じリポジトリデータを持つ」は崩れてしまった前提になるのではないかなと感じます。
(そもそも公開されていないブランチもあるでしょうから、全員が同じリポジトリデータを持つわけではなく、単に公開されているものにおいては同じ、くらいなのですが)

LFSリポジトリデータ自体のクローンは行われないわけなので、ここにたまっているデータをきちんとバックアップしてあげる仕組みがないとトラブル時にバイナリを失ってしまうということになるのではと心配が残ります。

試しに適当な場所にリポジトリをcloneした後で、リモートリポジトリを削除し、ブランチの移動やら任意コミットへのcheckout を実行したところ、バイナリファイルの復元に失敗してしまうようでした。


X-Window なしで OpenGL ES2 を使う その3


Ubuntu で NVIDIA のボード&ドライバを使って試してみました。

NVIDIA のプロプライエタリドライバをインストール

今回使用したのが NVIDIA の Geforce 750 Ti だったのですが、
Ubuntu 15.10 の標準インストールで使える nouveau ドライバでは通常の描画からして異常で使い物になりませんでした。
そこでプロプライエタリドライバをインストールするに至りました。

ドライバのインストールは以下のようにして行いました。

このドライバをインストールしてもうまく動かないようならば、
最初の描画不正の点も相まってボード故障も疑うところでした。
実際のところ、ドライバのインストール後の再起動したあとからは正常に描画できるようになりました。

コマンドでインストールしましたが、GUIからもインストールは可能だと思います。
(Additinal Drivers 関連かSoftwareセンターからできるかと思われます)

プログラムの実行

X-WindowなしでのOpenGLなプログラムを実行してみました。
そもそもこのドライバ使用でも /dev/dri/card0 が出現していたので、
KMS有効であると考えて、先日のプログラムは動くのではないかと思った次第です。

しかし結果は drmOpen で失敗してしまうようで、動作確認に至りませんでした。
NVIDIA のプロプライエタリドライバでも/dev/dri/card0 へのアクセス可能なようでしたが、 drmModeGetResources で失敗してしまうようでした。もう一歩でうまくいきそうな感じがするだけに、残念です。

追記

どうやら KMS サポートしているという見え方がダミーだったようです。
/dev/dri/card0 あたりがすでにダミーデバイスノードとの情報を見つけました。
そのせいもあって、 weston も動作しないという情報もあるようです。

http://wayland-bugs.freedesktop.narkive.com/4zE7PwYd/bug-90323-weston-launch-drmmodegetresources-failed


TortoiseGit で git add -p 相当できた


git には部分コミットを行う機能があります。これがコマンドでは git add -p ですが、 TortoiseGit からもこれと同じことが実現できることがわかったので記録しておきます。

まずは以下のように題材となるデータを用意してみました。
ある要求に対応するコードを実装したものの、途中で発見したバグを同時に直してしまったというケースです。このような場合にはバグ修正と機能追加といったように2つのコミットに分割するのが正しいです。

git-add-1

続きを読む


Ubuntu で Vulkan を試す (成功編)


ようやく Ubuntu で Vulkan のアプリケーション動作をさせてみることができたので、そこまでの方法をまとめておきます。若干強引な作業をしていたり、そもそもベータドライバだったりするので、試す際には自己責任でお願いします。

ubuntu-vulkan-sample-particle

以降の作業は Ubuntu 14.04.4 AMD64 版で、Geforce GTX 750 Ti が刺さっている環境の話でとなります。
また、Ubuntu はクリーンインストールした直後から始めている想定です。

この状態で nouveau ドライバがロードされているため、まずはこれを無効化します。
続きを読む


ようやくUbuntu で Vulkan 確認できた


Ubuntu で NVIDIA の Vulkan ドライバを入れて動作させようとがんばっていたわけですが、ようやく動作させることに成功しました。
ドライバのインストールを強行してなんとかなっているだけなので、綱渡り状態での動作です。サンプルのビルドにもちょっと手間がかかりましたが、以下のように動作させることには成功しました。

結局 Ubuntu 14.04, NVIDIA Geforce GTX 750 Ti という状態でここまでこれたので、正しく導入する方法をこれから探っていきたいと思います。

ubuntu-vulkan-sample-particle


Ubuntu で Vulkan を試す(失敗編)


NVIDIA Geforce GTX 750 Ti が刺さっている Ubuntu環境があったので、
これを Vulkan のドライバを入れてみることにしました。
その作業をここに記録しておきます。

ドライバをダウンロード

Nvidia Vulkan Driver: https://developer.nvidia.com/vulkan-driver
からドライバをダウンロードします。
ここでは、 Linux 64-bit を選択して、 NVIDIA-Linux-x86_64-355.00.27.run というファイルをダウンロードしました。

このファイルを後ほど実行するため、以下のコマンドで実行属性をつけておきます。

ドライバのインストール

既存のドライバを削除して、ダウンロードしたドライバをインストールします。
この過程でウィンドウシステム(X-Window)が一度シャットダウンされるので注意が必要です。

まずはドライバを削除します。

CTRL+ALT+F2 でコンソール画面に切り替えてから、ドライバをインストールします。

これでインストールが始まります。あとはインストーラーの指示に従ってください。
途中で”The distribution-provided pre-install script failed!” と表示されてしまう場合があるかもしれません。これの解決法は不明です。

自分の場合には、まさにこれでしたがインストールを強行することにしました。
その後インストーラーはエラーを出さなかったのですが、再起動したらグラフィカル画面が全く出なくなってしまいました。

追記

インストール&動作に成功できた記事を別途用意しました。こちらを参照ください


xperia z1 compact の電池換装


Z1fでも同じような症状が起こっており、わりと XPERIA 界隈では有名な話っぽいですが、いきなり端末のシャットダウンが発生するようになってしまいました。

原因は電池周りの不具合のせいらしいですが、原因の根幹には電池の劣化があるようです。

電池残量を正しく報告しない&瞬間的な電圧降下により残量ゼロとみなしてOSがシステムをシャットダウンしているとのことです。
そのため、90% くらい残量があると表示されていても、ブラウザでページを開こうとしていきなりシャットダウンとかザラにあります。あまりにもこれらがひどくなり、連続稼働10分を切ってしまったこともあって、何とかしようと乗り出しました。

交換パーツ

すでにやられている人がそこそこいるのか情報は検索すれば手に入りました。
また amazon でも電池パックだけが購入できたりするのでそちらを購入しました。

”Sony Xperia Z1 Compact 交換用 バッテリー 内蔵電池 ソニー 純正品 PSE”

というものです。約2000円程度だったのでダメ元でトライするにちょうどいいです。

ほかにもケースオープナーとかのヘラがあれば問題なく開くことができました。

z1compact-battery

交換過程

裏蓋を熱して、吸盤ではがしてスキマにヘラを突っ込んでこじ開ける!という定番の方法です。これも参考サイトを元に作業しました。
思いの外接着力が強かったので、はがすのに時間がかかりましたけど・・・。

また NFC のアンテナは、旧バッテリから白い包装ごと切り取って移植しました。
最初ははがそうと努力していたのですが、きれいにはがすことができず、
ちぎれそうな気配を感じたため仕方なくです。
z1compact-nfc

参考

こちらのサイトの情報が役立ちました&助かりました。

http://hatahuri.blogspot.jp/2015/10/xperia-z1-comapct.html

検証

交換前後でのバッテリの状態を確認してみます。
以前は以下のように充電状態であっても充放電を繰り返していることがわかります。
z1compact-graph-1
交換後は以下のようになりました。きれいに充電できていることがわかります。
z1compact-graph-2

この後使用を続けていますが、以前のような急なシャットダウンは発生しておらず、
交換した甲斐はあったと思っています。失ったのは防水性能ですが、使えないよりはマシということで。

充電状態が先のグラフのようになってきたら、電池交換しか復帰する方法はないという感じでしょうか。電池の状態を視覚化しておくって状態把握に大事だなと感じました。

使ったものなど

Amazon で購入したものについて紹介しておきます。

電池パックはこちらを購入しました。他にもあったのですがコネクタの位置問題があるようだったのでこちらを選択しました。

ケースオープナーは消耗品なので、念のため2種類ほど買ってみました。

ケースオープナーセット