先日(2018年 10月 15日の日記参照)気づいたことですが、Facebook や LinkedIn の職歴では、現職として 2社以上に所属することができるようになっています。
エグゼクティブクラスなら複数の会社の取締役を兼任するだろうけど、正直言って自分には縁が無い機能だと思っていました。
しかしエグゼクティブでなくとも、この世には「出向」という 2足の草鞋を履ける制度がある訳で。自分でこの機能を使うことになるとは思いませんでした……。
メモ: 技術系の話は Facebook から転記しておくことにした。
引っ越し荷物を開梱していると、たくさんのマウスとキーボードが出てきました。いつのまにこんなに買っていたのか。
写真には 6つのマウス、6つのキーボードが映っていますが、他にもマウス 3つ(Logicool V450、Microsoft Wireless Mouse 1000 が 2つ)と、キーボード 1つ(Topre REALFORCE)がありました。
マウスの一覧です。
キーボードの一覧です。
マウスは 9個も買ったにも関わらず、一番手に合うと思ったのは、会社の PC に付属している有線タイプのマウスでした。サイズが絶妙で、とても軽くて良いです。
ワイヤレスマウスは妙に小さいか、妙に重たいので、手が疲れてしまいます。今のところ唯一気に入ったのは Logicool の M705 だけです。
キーボードは 7個も買いましたが、キーの配置がスタンダードであることだけが重要で、構造や他の要素はあまり気にならないことがわかりました。PC に付属しているキーボードはキー配置に捻りがなくて使いやすいものが多いですが、最近の PC は変なキー配置のキーボードが増えていて困ります。普通の配置が良いです。要らんことしないで欲しい。
前の会社(ソシオ)で使っていた富士通 PC に付いてたキーボード(FKB-1424 と配置が似ているやつ)はキーが若干頼りなかったですけど、キー配置が普通で良かったです。
今の会社の DELL KB216 はイマイチです。左下の Fn キーが邪魔ですし、左 Alt のところ(Z キーの一段下)に Win キーが来ていて、メチャクチャ押し間違えます。あまりに誤打するので撤去して、REALFORCE に置き換えたほどです。昔使っていた DELL マシンのキーボード(DELL SK8115?スペースキーが正方形のもの)はスタンダードな配置で良かったのにな〜。なんでノート PC もどきの配置にしたんでしょうね。
Logicool のマウスは良いものが多いんですけど、キーボードはイマイチなキー配置が多いです。K275 以外は誤打連発で手に合いません。
REALFORCE は価格は高いのを除けば、キー配置がスタンダードで非常に良いキーボードです。我が家では活躍の場がないため、会社に持って行って活躍してもらっています。
メモ: 技術系の話は Facebook から転記しておくことにした。10月13日の投稿が元だが、大幅に加筆した。
LAN ケーブルで HDMI 伝送できる世界初の "GPU搭載" HDBaseT カード - PCWatch を読んで。
面白い製品だな〜と思いつつ、今一つこの製品の価値が理解できていませんので、少し調べてみました。
私の予想するこの製品の魅力は、
のどちらかです。まず価格を見てみると、
HDMI ケーブルは確かに高いけど、実は CAT7 LAN ケーブルもかなり高いため、大きな違いがありません。
次に距離を見てみると、HDMI も 50m くらいならイコライザ付きのケーブルを使えば、引き回せるみたいです。さすがにケーブル 1本で 100m は無理そうでした。商品が見当たりません。HDMI で 100m に挑むとすると、
このような選択肢があるようです。HDMI で 50m を超えることは不可能ではないですが、一気に価格が跳ね上がります。
従って、この製品が輝くシーンは
「50m〜100m のディスプレイ配線をケーブル 1本で安く繋ぎたいとき」
だと思われます。たぶん。
メモ: 技術系の話は Facebook から転記しておくことにした。少し加筆。
先日(2018年 7月 22日の日記参照)買った Rockchip RK3328 搭載ボード ROCK64 で遊んでいます。
Rockchip の SoC で動く Linux は Rockchip がメンテナンスしている Linux(以降 Rockchip Linux)ですが、実は Linux の本流開発ツリー(以降 linux-next)も動作します。
しかし linux-next の方は全く音が出ません(speaker-test で叩くと xrun_recovery faild: -5, Input/output error が出ます)。
以前 S/PDIF も全く動かなかったのですが、原因が分かったのでパッチを送って直しました。今は出音までできているはずです。しかし I2S は原因が違うらしく、なぜ動かないのかさっぱりです。
I2S のレジスタ情報は TRM(Technical Reference Manual)に載っていたので、それを見つつ Rockchip Linux とレジスタ値を同じに揃えましたが、I2S は微塵も動きませんでした……。
I2S 以外のドライバのバグを疑い、Rockchip Linux の I2S ドライバを丸ごとコピーしたら、動いてしまいました。疑いはハズレ、つまり I2S ドライバに何らかのバグがあることは確定です。一体何が違うんでしょう。diff を見ましたが差分の意味がわかりません。
差分は多くないので、力技で Rockchip Linux から linux-next に 1つずつ差分を移植していって、動作するかどうか確かめました。原因は devm_snd_dmaengine_pcm_register() の第 2 引数(config)に NULL を渡すかどうか、でした。
私には、その違いの意味するところも、現在の linux-next のコードの何が悪いのかも、さっぱりわかりません。
動作とコードを追ってみると、現在の linux-next のコードは struct snd_dmaengine_pcm_config の prepare_slave_config を設定し忘れているため、全く DMA 転送設定がされていないことがわかりました。
要は、音声データを全く I2S ハードに送っていなかったんです。そりゃ動くわけないわ。
Rockchip Linux はどうしていたかというと devm_snd_dmaengine_pcm_register() の第 2 引数に NULL を指定していました。何も指定していないのに、どうして動くのでしょう?同じバグを踏まないのでしょうか?
実は第二引数に NULL を指定すると ALSA のフレームワーク側で prepare_slave_config に snd_dmaengine_pcm_prepare_slave_config() を指定した状態と同等に扱われます。この働きにより、無事動作していたのでした。わかるかそんなの。
知っていれば秒殺系のバグでしょうけど、私はぱっと見ではわかりませんでした。
バグの修正としてはたった 1行なんですが、理解するまで 2日掛かりました。Linux 詳しい人はもっと早く解析できると思います……。Linux を触っているとこういうの多いので、もっと Linux パワーが欲しいです。
せっかく判明したバグなので ALSA ML にパッチをぶん投げておきました。
ちなみに、これで万事解決ではなく、アナログ音声端子から音を出すには I2S1 と ACODEC というハードを叩かないといけないです(今回動いたのは I2S0)。今わかっているだけで、
これだけの問題があります。Rockchip Linux は何らかの方法で問題を解決しているはずなのですが、今のところ私にはさっぱりわかりません。
私のような門外漢が四苦八苦するより、Rockchip の中の人が linux-next に修正パッチを投げてくれる方が断然早いんですけどねえ。あまり linux-next にはご興味がないのでしょうか。
昨日(2018年 11月 10日の日記参照)の続きです。残る問題は 3つありました。
2番目の「認識しなくなる問題」の原因が判明しました。
I2S2 を有効にすると SPDIF が使えなくなる問題は、DMA の資源が枯渇していたせいでした。
RK3328 は ARM の PL330(or 互換)の DMA を持っています。SPI, UART, I2S, SPDIF, PWM, PDM など 16のハードウェアがこの DMA を使えますが、実は同時に使えるのは 8つまでという制約があります。知るかそんなこと……。
オーディオ系のハードを全て disable にしたときの DMA 資源の割り当ては、
このようになっていて、残りは 4つです。
I2S0, 1, 2 はそれぞれ DMA 資源を 2つ使い(TX, RX があるため)、SPDIF は資源を 1つ使います(TX しかないため)。
Rockchip Linux(Rockchip が独自にメンテナンスしている Linux のツリーのこと)の設定では I2S0, I2S1 のみを有効にして SPDIF を切り捨てています。ちょうど資源を 8つ使いきる設定ですね。ROCK64 はピンヘッダにしか SPDIF 信号が出せませんし、捨てるのも妥当かなとは思います。
私が前にエラーになってできないと言っていたパターンは I2S0, I2S1, I2S2, SPDIF を有効にするパターンです。この場合、
以上のように DMA 資源が足りなくなり、エラーになってしまいます。
ちなみに I2S0, I2S1, SPDIF を有効に(11/16: I2S2 → I2S1 に訂正)すると、一応動くのですが、割り当てを調べると、
このように UART が犠牲になってしまうようです。Audio が動いても、UART が死んじゃうのはダメな気がします。
(11/16 加筆)UART は DMA が無効になっても動作はしますので、死んでしまうという言い方は間違いでした。正しくは、Audio のために勝手に UART の DMA を無効にしてしまうのはダメな気がします。デバイスツリー上は有効になっているように見えるので。
せっかく鳴るようになった SPDIF を活かすか、Rockchip Linux に合わせるか、さて、どうしたもんかなあ。
メモ: 技術系の話は Facebook から転記しておくことにした。少し加筆。
目次: Kindle - まとめリンク
Kindle Fire はときおりシステムアップデートが勝手に降ってきて、気づいたら更新されています。
アップデートしてくれるのは良いですけども、バッテリー駆動の時でもお構いなしに始まるのが結構怖いです。
当然、アップデート開始前に一定の残量(例えば 50%以上、とか)があるかどうか見てから、アップデートを開始しているとは思いますが、バッテリーが弱っていて、アップデート中に一気にバッテリー残量が枯渇して電源が落ちたら、文鎮になってしまうのでは……?
メモ: 技術系の話は Facebook から転記しておくことにした。11/9 の投稿が元、一部加筆。
目次: マンガ紹介 - まとめリンク
お気に入りのマンガ紹介シリーズ。
Kindle Fire HD は大量の本を入れると動作がおかしくなる(Kindle アプリが落ちる、起動しなくなる)ので、本は読み終わったらいったん端末から削除し、読み返したくなったらまたダウンロードする運用で使っています。
そんな中、既読かつ Kindle 内に残り続けている本、いわゆる「お気に入り」をいくつかピックアップしてみます。
あまり意識していませんでしたが、異世界転生系小説のコミカライズが多いですね…。
野球漫画は球詠、メジャー 2nd、グラゼニくらいしか読んだことないですけど、どれも面白いですね。
OpenCV+OpenVX のデモンストレーション(GitHub へのリンク)を動かしてみました。
VirtualBox のディスクイメージを使えば、何もしなくても QtEditor と CMake で簡単にビルド&実行できますが、それだけでは何が何だかわかりませんので、あえて手動でビルドしてみます。
いくつかサンプルが含まれていますが、Harris Corner と呼ばれる角検出のデモである solution_tutrial1 を題材にして、ビルド方法と動かし方を書こうと思います。
サンプルコードは GitHub から clone すればよいです。その際 README にある通り、tutorial_videos ディレクトリを作成して、動画ファイル(リンク先)をダウンロードして入れておくと良いです。
もし既に VirtualBox で試しているなら、scp なりなんなりでディレクトリごとコピーしても良いです(動画ファイルも入っています)。ホームディレクトリの openvx_tutorial というディレクトリに入っています。
必要なものは OpenCV と OpenVX のライブラリです。
OpenCV のビルドはメチャクチャ面倒くさそうなので、apt-get install libopencv-dev でインストールしてしまうのが楽です。
OpenVX は Debian のパッケージになっていないようなので、自分でビルドする必要があります。
Khronos のサイトに「OpenVX 1.2 sample code (updated January 17, 2018). 」があるので、このコードを使います。(Khronos へのリンク)
$ tar xf openvx_sample_1.2.tar.bz2 $ cd openvx_sample $ make -j4
成功すると out/LINUX/x86_64/release というディレクトリの下に、libopenvx.so が生成されているはずです。install はやってもやらなくても動かせるので、今回は install せずに続行します。
次にサンプルコードをビルドします。
$ cd openvx_tutorial/tutorial_exercises/solution_exercise1 $ g++ solution_exercise1.cpp -lopencv_imgproc -lopencv_videoio -lopencv_highgui -lopencv_core -L/path/to/openvx_sample/out/LINUX/x86_64/release -lopenvx
本当は CMake を使えば依存ライブラリを勝手に調べてくれますし、オプションを手で指定する必要はありませんが、ここではあえて -l オプションで OpenCV と OpenVX のライブラリを明示的に指定しています。
ビルドがうまくいったら実行します。
$ LD_LIBRARY_PATH=/path/to/openvx_sample/out/LINUX/x86_64/release ./a.out
OpenVX のライブラリを /usr/lib などに install していない場合は、この例のように LD_LIBRARY_PATH で OpenVX ライブラリの場所を教える必要があります。
うまくいけば、ウインドウが出て、右下からたくさんの人が歩いてくる動画が出ます。また、検出された角に赤い点が打たれていて、点の動きがトラッキング(黄色い矢印)されている様子が表示されるはずです。
Windows からアクセスするファイルサーバには Samba を入れていますが、なぜか Windows 10 から接続できるマシンと、接続できないマシンがあって、ずっと理由が分からずほったらかしにしていました。
結論から言えば、Samba で無効なユーザでログインを試みた際に、ゲストにフォールバックする機能を有効にしていることが原因で、Windows 10 がサーバへの接続を拒否していました。
これは Samba の map to guest = bad user に設定されていると発生します。大抵のディストリビューションで Samba をインストールすると、この設定になっていると思います。設定の意味ですが Windows 10 側のユーザ名が AAAA だとして、Samba 側のユーザ名に AAAA が存在しない場合、Samba は不明なユーザをゲストユーザとしてログインさせようとするそうです。
この動きに対して Windows 10 は拒否反応を示して、接続を切ってしまいます。不明なユーザなら、ログイン確認画面を開いてユーザ名から確認すれば良いのに、何も出さずに「接続できませんでした」と言ってくる始末です。
問題を解決するには Samba の map to guest = never に設定すれば直りました。Windows 10 がユーザ名とパスワードを聞いてくるようになります。
なお、現象の見分け方は、イベントビューア(eventvwr.msc /s)の
[アプリケーションとサービスログ] - [Microsort] - [Windows] - [SMBClient] - [Security]
を見たときに、エラー、イベント ID 31017 が記録されていて、
安全でないゲスト ログオンを拒否しました。
ユーザー名:
サーバー名: (サーバの IP アドレス、コンピュータ名などが入る)
ガイダンス:
このイベントは、サーバーがユーザーを未認証のゲストとしてログオンさせようとした結果、
クライアントによって拒否されたことを示します。ゲスト ログオンでは、署名と暗号化などの
標準のセキュリティ機能はサポートされません。このため、ゲスト ログオンは、重要な
データをネットワーク上に漏えいさせる可能性のある man-in-the-middle 攻撃に対して脆弱
です。Windows では、ゲスト ログオンは既定で無効になっています。Microsoft では、安全
でないゲスト ログオンを有効にすることは推奨していません。
こういうエラーが記録されていたら、該当していると思われます。
オープンソース製品の「仕様」 - 赤帽エンジニアブログを読んで。
前職では Linux に限らず OSS の仕様について質問されたことは何度かありますが、今同じことを聞かれたら、この記事を紹介したいですね。仕様が〜!と質問してくる人に対して感じていた、モヤモヤ感をスッキリ説明してくれるとても良い内容です。
今は自動車関連の会社に在籍している訳ですが、自動車の考え方と、OSS の考え方は合わなさそうな気がしました。
とはいえ今の時代、ソフトウェア開発において、OSS を完全に無視することはできませんし、OSS の劣化コピーなんて素人が作っても品質悪いだけで、金と時間の無駄なので、どこかうまく折り合いをつける必要があるでしょうね。
メモ: 技術系の話は Facebook から転記しておくことにした。11/11 の投稿が元、一部加筆。
目次: Kindle - まとめリンク
Kindle Fire がおかしいのは今に始まったことではないのですが、いくつかのタイトルのマンガがダウンロードできません。困りました。
Kindle Fire で本をダウンロードする方法は、私の知る限り 4つありますが、うまくいったりいかなかったり変な挙動です。
ちなみに PC と Android にも Kindle のアプリはありますが、どちらも正常にダウンロードできます。
Kindle Fire は安さが魅力的ですが、非常にイマイチな出来です。初代 Kindle Fire HD も 100冊くらいでハング連発したり起動不能になったり挙動不審でしたし、今使っている第七世代 Kindle Fire HD もハングこそしませんが、上記のような変な挙動をします。
Kindle ストアで買った本なのに「この書籍は DRM で保護されているので表示できません」エラーが出たこともありました。はあ?何言ってるの??と思って、もう一回表示させたら何事もなかったかのように表示されます。本当に意味不明です。
DRM 掛かってる本なんて Amazon の本しかないよ!
最近は、新しく買ったマンガまでダウンロードできなくなってしまい、せっかく買ったのに読めなくて困っています。これはいよいよファクトリリセットか?マンガもアカウント設定も何もかも消えるから、再設定が面倒くさいんだよなーなどと考えていたのですが。
謎の「コンテンツ管理サービス」というアプリのデータを消去したら、ダウンロードできない病が直った気がします。
とりあえずこの状態でしばらく運用してみようと思います。
Kindle はもう嫌になったので、次は買わないと思います。しかし、困ったことに代わりになりそうなタブレットがありません。
Android タブレット市場は、Kindle が利益度外視の安値攻勢で全て焼き払ってしまいました。特にマンガを読むのに適した 10インチ級のタブレットは、新製品がほとんど発売されません。困ったね……。
メモ: 技術系の話は Facebook から転記しておくことにした。一部加筆。
ASUS、ゲーミングスマホ「ROG Phone」を 11月 23日に発売 - ケータイ Watch を読んで。
ゲーミングスマホを見ていると、割と高い(11万円)し、ゲーム画面が小さいし、これ売れるのかな?と思いますけど、スマホに吸収された機能って、何だかんだ言われつつ最後には駆逐されているし、いずれゲーム機もスマホに吸収されるんですかね?
スマホは「独自」と「最高性能」が売りで、ゲーム機は「均一」と「最低性能を保証」が売りで、設計の方向性の違いがあるので、個人的にはしばらくはゲーム機の置き換えは難しいだろうと踏んでいますけども。
Facebook でゲーミング PC の延長線ではないかというコメントを貰いました。言われてみればゲーム機というより、PC に近い設計思想だなと思いました。
スマホが当たり前の世代だと、PC を触ったことのない人も多いと聞くので、ゲーミング PC がそのうちスマホに喰われるかもしれませんね。
メモ: 技術系の話は Facebook から転記しておくことにした。一部加筆した。
山手線の新型車両の車内広告は、横並びの 3つの液晶ディスプレイを使いますが、各社で広告の見せ方が違って面白いです。
左から並べたとき、
動画、静止画の混在パターンもありました。
静止画のみのパターンもあります。
不思議なもので、3画面全て動画じゃなくても見栄えはします。しかし同じ静止画にされると、映っているものに関わらず、手抜き感を強く感じます。
メモ: 技術系の話は Facebook から転記しておくことにした。
先日(2018年 11月 11日の日記参照)の続きです。linux-next で ROCK64 の I2S1 が動きました。残る問題は 2つでした。
1番目の「I2S1 はなぜか動かない」の原因が判明しました。
I2S1 だけ死んでいた原因は、日記のコメントで T4 さんに指摘いただいていた通り、RK3328 のクロックゲートの定義がバグっていたことでした。linux の開発 ML に修正パッチをブン投げておきました。先週のどこかで取り込まれたっぽいです。良かった。
RK3328 のクロック分周器はかなり対応範囲が広いので、単純にシステムクロック=fs * 256 とすれば、44.1kHz 系を再生するときシステムクロックが 11.2896MHz になり、48kHz 系を再生するときシステムクロックが 12.288MHz になって、うまく再生されるだろうと考えました。
やってみると 48kHz 系は正常に動作しますが、44.1kHz 系を流すと EINVAL を返してきて、なぜか ACODEC までおかしくなり、リセットするまで一切音が出なくなります。イケてないです。
クロックのレジスタは GPLL * 147 / 6400 = 11.2896MHz に正しく設定されているのに、なぜかクロックドライバは 11.289599MHz だと報告してくるので、サウンドドライバが 44.1kHz の整数倍じゃないと判定して EINVAL を返しています。
良く見ると GPLL の周波数も 491.519999MHz という変な値になっています。なぜ 491.52MHz じゃないのか?491.52MHz なら先ほどの割り算は割り切れるはずなんですけどね。
あと 44.1kHz 系を再生すると ACODEC がおかしくなる仕組みも謎です。ACODEC とクロックに何か関係があるのだろうか?また今度追ってみますか。
メモ: 技術系の話は Facebook から転記しておくことにした。少し加筆。
先日(2018年 11月 28日の日記参照)の続きです。linux-next で ROCK64 のアナログオーディオ出力から音が出ました。残る問題は 1つでした。
3番目の「ACODEC は TRM に何も情報が載っていない」を回避しました。
ACODEC は I2S 信号をアナログオーディオ信号に変換するハードウェアです。仕様を秘密にするようなハードウェアではないと思いますが、TRM(Technical Reference Manual)に記載がありません。無いものは仕方ないので、rockchip-linux からドライバを移植しました。
残念ながら rockchip-linux はカーネルバージョンが 4.4 と古く、ACODEC ドライバを linux-next に持ってきてもビルドできませんので、適当に直しました。ALSA SoC のドライバを作った経験があって良かった。うん。
とりあえずアナログオーディオは動いたのですが、昨日の日記にも書いた通り、44.1kHz 系を再生すると ACODEC がおかしくなる仕組みは謎のままなので、まだ完成とは言えないです。
ROCK64 はまだまだおもちゃとして遊べそうです。
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)