2016年 12月 06日

daemontoolsのsetuidgidが補助グループ (supplementary groups) 権限をつけてくれない問題 (python)

tech

いままでハマったことがなかったのだけど、ついにハマってしまった。
補助グループ権限もつけてくれるsetuidgidのようなもの - (ひ)メモ を読んで、どうするかな〜と思いつつsetusergroupsを試してみたが、Unix::Groups がデフォルトで入っておらずちょっと困ったので python で以下のようにした。

#!/usr/bin/python

import os
import sys
import pwd

if len(sys.argv) < 3:
    print >> sys.stderr, 'Usage: setusergroups user program'
    sys.exit(1)


pw = pwd.getpwnam(sys.argv[1])
pw_name = pw[0]
pw_uid = pw[2]
pw_gid = pw[3]
pw_home = pw[5]

os.environ['HOME'] = pw_home
os.initgroups(pw_name, pw_gid)
os.setgid(pw_gid)
os.setuid(pw_uid)
os.execvp(sys.argv[2], sys.argv[2:])

エラると例外で落ちてトレースバックがでて十分なので特にエラー処理してな

備考

ハマったのは Raspberry Pi の pi ユーザで i2c を触るようなデーモンを作るケースで、この場合 pi ユーザに i2c グループ権限がついてないとダメなのでこういうのが必要になる。

依存なしでどうにかしたかったのは、cpanm が ansible の Core Modules に入ってなくてめんどかったから

関連エントリー

2016年 12月 03日

builderscon tokyo 2016 で「 Bluetooth キーボードの作りかた」を喋りました

tech

ありがとうございました。

聞いたトークで印象に残ったもの

OSS は Windows で動いてこそ楽しい - builderscon tokyo 2016

mattn さんが思ったより全くオッサン感なくてビビった。。。挨拶しようと思ったけどできなかったので、いつか(いつ？)挨拶したい。発表もおもしろかった。

動け！Golang 〜圧倒的IoTツール開発へようこそ〜 - builderscon tokyo 2016

IoTツール開発は生産管理ツールについてで、ものすごく貴重な話だと思った。懇親会でももうちょっと聞いたりした。

The Open Beer Server - theory and the implementation - builderscon tokyo 2016

今回のゲラゲラ枠っぽいが、ものすごい金かかっててやばかった……

C 言語で行う Web フロントエンドプログラミング - builderscon tokyo 2016

Emscripten の話とか。ブラウザって VR もサポートする予定なのか！と思った。あと Emscripten が頑張って OpenCL を WebGL に変換するとか知らなかった。

「片手間JavaScripter」にも知ってほしい、Vue.jsで実現するMVVMパターン、Fluxアーキテクチャとの距離 - builderscon tokyo 2016

Flux 触ったことなかったのでわかりやすかった。

そろそろプログラマーもFPGAを触ってみよう！ - builderscon tokyo 2016

FPGA の話とても聞きやすくて解りやすくてよかった。

一から始めるJavaScriptユニットテスト - builderscon tokyo 2016

JS のテスト、闇雲にググっても萎えるだけなので、こういうまとまった資料ってほんとまじで大事

関連エントリー

2016年 12月 02日

builderscon tokyo 2016 でしゃべります

tech

16:40〜 自作キーボードの話を1時間ぐらいする予定です。なんか1日の最後なのでゆるめでやりたいという気持ちはあります。

おおむね、事前のトーク概要と変わらない内容で話せそうです。

資料つくってます…… 話がまとまらない……

ref. builderscon - Discover Something New

関連エントリー

2016年 11月 29日

vim8 というか github の master HEAD をいれた

tech

いろんな都合により最新のvimにした。

http://www.vim.org/git.php に従い git の master HEAD を入れる

git clone https://github.com/vim/vim.git
cd vim
cd src
./configure --prefix=$HOME/app/vim --enable-multibyte --enable-gpm --enable-cscope --with-features=huge --enable-fontset --disable-gui --without-x --disable-xim --disable-perlinterp
make
make install

vim-go がうまく動かなくて入れたんだけど、結局 gocode がなんか変になってたみたいで以下をした。

go get -u github.com/nsf/gocode
gocode close


これで動いてくれた。mattn さんに教えてもらいました。

関連エントリー

2016年 11月 16日

「スマホの爆発を防止できるか? GoogleによるUSB-Cの新規格」っていう記事がひどくて爆発する

tech

スマホの爆発を防止できるか? GoogleによるUSB-Cの新規格 | ギズモード・ジャパン この記事

まずタイトルおかしいよね。。USB-C の新規格の話なんてどこにもない。Android の互換性定義の話。

それはともかく

Type-Cデバイスは、Type-Cレジスター基準に則って1.5Aと3.0Aのチャージャーを識別し、電流アドバタイズメントの違いを検知しなければなりません。

つまり、どれだけの電流が流れ込んでいるかをUSB-Cデバイスは検知しなければならないということです。

http://www.gizmodo.jp/2016/11/google-usb-c-recommend.html

って書いてあってげんなりする。

デバイスが検知しなければならないのは、充電器の供給容量(最大電流)であって、流れ込んでくる電流量ではない (バッテリ充電回路で電流制御はしているだろうが、それは USB Type-C の抵抗設定とは関係ない)。

「流れ込んでくる電流量」って言い方がなんか変。デバイスにとって自分に流れる電流量は自分のことなので、こんな他人事みたいな言い方だと違和感がある。充電器はデバイスが消費するだけの電流を供給するだけで、別に無理矢理デバイスに電流を押しこんだりしない。

ここの「チャージャーを識別する」ってのがどういうことを意図しているかというと、充電器が供給容量を超えた電流をデバイスが使おうとすると、充電器にとっては過負荷になり最悪発火するからちゃんとしてくれってこと。あくまで充電器の過負荷に対する問題であって、これはデバイスの発火の話ではない。

Android 7.0 CDD の原文

ところで CDD の原文か以下のようになっている。

Type-C devices MUST detect 1.5A and 3.0A chargers per the Type-C resistor standard and it must detect changes in the advertisement.

Android 7.0 CDD

訳がまず明らかにおかしい。。「Type-C デバイスは、Type-C 抵抗標準によって 1.5A と 3.0A の充電器を識別し、またその通知の変更を検知できなければならない」ぐらいかな?


そういえばと思い Google Translate で試したけどこっちのほうが優秀だ。

タイプCのデバイスは、タイプCの抵抗規格ごとに1.5Aと3.0Aのチャージャを検出しなければならず、広告の変化を検出する必要があります。

備考：USB Type-C のスペック

ちゃんと調べたことがなかったので改めて調べてみた。USB Type-C Specification Release 1.2.pdf の 4.6.2.1 USB Type-C Current あたりかな。

Source はチャージャ側のこと。Sink は基本的にデバイス側のこと。

  • Type-C では CC pin を使って、電源の供給量を通知する
  • 電流量には3種類定義されている
    • Default (500mA for USB 2.0 / 900mA for USB 3.1)
    • 1.5A
    • 3.0A
  • 1.5A や 3.0A を使うデバイスは CC ピンをモニタして消費電流を調整しなければならない (ただし USB PD の接続が確立されている場合はモニタする必要はない)
  • 充電側はデバイス側が過剰に電流消費している場合に自身を保護すること (保護回路をつけろってこと)

CC ピンの回路

Source 側は Rp でプルアップ、Sink 側の Rd でプルダウンしている。それぞれ必要な値は表になっている。

でもって、Sink 側はどのようにして供給電流量を判別するかといえば、Rp と Rd で分圧された部分の電圧を見ろと書いてあり、表になっている。

ためしに Rp=56kΩ Rd=5.1kΩ で計算してみると vRd は 0.42V で、vRd-USB の範囲に入る。同じように Rp=22kΩ Rd=5.1kΩだと0.94V で v-Rd-1.5、Rp=10kΩ Rd=5.1kΩ で 1.56V で vRd-3.0。

変換ケーブルについて

変換ケーブルでは CC ピンは常に 56kΩ でプルアップされなければならない。つまり Default にしとけってこと。

Default は 500mA for USB 2.0 / 900mA for USB 3.1 ってことになっているが、今まで使われてきた USB-BC も有効なため D+/D- を 200Ω でショートするアレとかで 1.5A まで流せる。

ref

Type-C の規格。zip で全部落とさないと見れない。面倒ですね。

関連エントリー

2016年 11月 15日

チップ部品のススメ

tech

最近はできるだけチップ部品を買うようにしている。特に抵抗やキャパシタではチップ部品のメリットが極めて多いように思うからだ。

  • 小さいので保管に困らない
    • 抵抗+キャパシタをリード品で一通り保有すると結構な体積になるけど、チップ部品ならそうでもない
  • リードが必要ならつければいい
    • チップ部品にリードをはんだ付けしたらリード付きにできる。そう考えるとリード品を保有する必要が全くない。
  • 実装面積が小さい
    • 小さいは正義
  • 単価が安い
    • 一通り50個ぐらいずつ買ってもたいした金額にはならない

かつて買ったリード抵抗とかはまだいっぱいあって、もったいなくて捨てれているわけではない。日本の家は狭いので保有コストを考えると「小さい」ことはとにかく正義。

抵抗もキャパシタも基本的に 1608 サイズで買っている。このサイズが手はんだがストレスなく行える限界かなという気がしているからだ。

チップ部品は慣れるとリード品よりも楽。なぜかというといちいちリードをフォーミングする必要がないのと、コテ先をあてやすいのと、はんだ付けしたあとにいちいちリードをカットする必要もないから。

買ってるもの

抵抗: E24系 0〜1M + 2M ±1%

1Ω〜910kΩまで E24 系で全て買っている。これで144種類。これに加え、0Ω、1M、2M を買ってる。あとは必要に応じて買ってる。

現実的には E24 系でもほぼ使わない値はあるけど、いざ必要なときにないのが一番ムカつくのでとにかくこの系列は全部買うというようにした。E24 は誤差5%が目安ってことになってるけど、1%品を使いたいケースが割とあるので1%で統一してる。

  • 1R0 (1Ω) 24
  • 100 (10Ω) 24
  • 101 (100Ω) 24
  • 102 (1kΩ) 24
  • 103 (10kΩ) 24
  • 104 (100kΩ) 24

キャパシタ: E12系 1pF〜10μF ±10% MLCC X5R X7R 特性

積層セラミック(無極性)のもの。耐圧は最低でも 6.3V あるものを買ってる。ただし耐圧必要なところはチップコン使わないつもり。耐圧はあとから調べようがないので、できるだけ 50V のものを買いたいが、容量によっては難しい。

  • 1pF 12
  • 10pF 12
  • 100pF 12
  • 1000pF 12
  • 10000pF (0.01uF) 12
  • 0.1uF 12
  • 1uF 12
  • 10uF 12

整理方法

AideTek BOX-ALL パーツケース チップ抵抗 チップコンデンサ 144値を確実に整理収納 専用ラベルシール付 - AideTek

AideTek

★ 4.0 / 5.0

このボックスにできるだけ入れるようにしてみた。横12縦が上下6ずつ、合計144区切りで蓋がついてる。

12の倍数ってのがキモで、E12 や E24 で収めると綺麗に揃えることができる。便利。

関連エントリー

2016年 11月 09日

LED電球の発光効率/エネルギー変換効率と発熱

tech

LED電球のエネルギー変換効率(電力→光出力)は疑似白色LED(2波長)だと現在は最大で22%前後。残りは熱や不可視光などに変換される。10W 入れても 7.8W は熱などになる。またLEDに関しては電源回路 (電圧変換) が必要不可欠で、ここの効率も装置全体の効率にかかわってくる。ただ、電源の効率は最低でも80%ぐらいはあって、最高で98%ぐらいの効率。市場製品の電源回路がどの程度かはよくわからないが、ルーメン表記を見れば装置全体の効率は計算できる。

例えば以下の商品は、7.8W 810lm (電球色) / 7.3W 810lm (昼光色) となっている。電球色の場合の全体の効率は 103.8lm/W (15%)。昼光色の場合 110.9lm/W (16%)。

-

★ 3.0 / 5.0

なお白熱電球の場合のエネルギー効率は最大で3%程度。10W入れても 9.7W は熱などになる。LED はあまり赤外線(熱線)を含まないが、白熱電球は大部分が赤外線になる。

いずれにせよ発熱はある。「LED は電球部が発熱するんじゃない、電源が発熱するんだ!」とか言ってる人を見かけたけど間違いで、発熱で支配的なのはLEDそのもの。たぶん光に手をかざしても暖かくない (赤外線がすくない) ことを勘違いしている。LED は発熱しないイメージみたいなのを持ってる人もいて謎だけど、実際はかなり発熱するし、熱で劣化するのでどんな製品でも放熱には気をつかわれてる。



最も人間の眼で感度のある555nm単波長光(緑) で 683.002lm/W が理論上最大値。白色にするためには複数の波長を混ぜる必要があるので、実際の電球では遥かに効率は落ちる。

関連エントリー

2016年 11月 04日

Raspberry Pi 3 で、シリアル経由でシェルを使うには

tech

基本

Raspberry Pi 3 からはデフォルトで UART にシェル割当されなくなったので設定する必要がある。

sudo raspi-config

して、Advanced Options → A8 Serial → YES する。


または、enable_uart=1 を /boot/config.txt に書く。実際 raspi-config がやってることはこれだけ。

接続

接続は

  • GND / GND
  • #14 (TXD0) / RXD
  • #15 (RXD0) / TXD

と繋ぐ (左が Raspi、右がシリアルアダプタなど)

115200 baud

接続後

シリアル経由だと自動的にターミナルサイズが伝わらないので、

stty rows 60 cols 300

とかすると良い。

TERM も適当に設定する

export TERM=xterm

これでとりあえず使える環境になる。ただ、115200 baud なので結構表示が遅い。

関連エントリー

2016年 10月 30日

中華製 HDMI -> USB 3.0 UVC キャプチャデバイス

tech

ちょっと思うところあって、HDMI を USB Video Class (UVC) に変換するキャプチャデバイスを買ってみました。簡単にいうと HDMI 出力をウェブカメラとして扱うことができるというものです。

この手のものは基本的に結構高価なのですが、この製品は AliExpress で $108 とかなり安い (というか 1080p USB 3.0 対応だと市場最安ぐらい？) です。

軽く使ってみる

PS3

とりあえず PS3 の HDMI 出力をこのデバイス経由で MacBook に入力して QuickTime Player で見てみました。

QuickTimer Player 側で画質を「最高」に設定すると 1080p で綺麗な画像が出てきます。また、音声もちゃんとキャプチャできていました。

この状態でゲームを起動したりしてみましたが、繋いだ状態でプレイできる感じではありません。後述しますが遅延があります。まぁその手の用途には使えないと思います。

デジカメの HDMI 出力

こんな感じです。カメラ側で 1080p 出力ができないのでしょぼいです。ビデオカメラならできると思うんですが、持ってないので……

実装

中をちょっと見てみましたが、数個の IC と FPGA っぽいものがありました。FPGA っぽいものにヒートシンクがついてました。大きいところの型番を検索してみました。

  • Analog Devices ADV7611 (HDMI レシーバ)
  • Micron D9LHT (64MB DDR2らしい/商品説明より)
  • Cypress CYUSB3014-BZXI (USB3.0 コントローラ)

ヒートシンクで FPGA の型番がわかりませんが、個人で普通に作ってケース込みで$100に収めるのは不可能に近いので、割とお得な気はします。

ところで4本のビスを外せば開けられるのですが、止めているビスがおそろしく柔らかい素材で、サイズぴったりのドライバで回しても1本は折れて、もう1本はネジ山がなめてしまいました。

発熱

結構発熱します。ケースはアルミなので、全体的に暖かくなります。15分ぐらい使うと40度ぐらいかな。だいたいこれぐらいの温度で安定してます。

遅延

ちょっとややこしいですが、キャプチャしている Mac 自身のディスプレイの1つとしてこのデバイスに出力して計測してみます。UVC 経由で Mac デスクトップが拡張されている状態です。Mac 側からの出力解像度は 1080p にしています。

requestAnimationFrame(function me(){document.body.textContent=new Date().getTime();requestAnimationFrame(me)});

するウィンドウを2つ作って、1つは DisplayPort から表示 (リファレンス)、もう1つはこのデバイスを経由して HDMI -> USB 3.0 -> QuickTime Player とした状態です。この2つのウィンドウを近付けてスクリーンショットを記録したのは以下の画像です。

左が通常 (DisplayPort)、右が UVC を QuickTime Player で見ているものです。

これで確かめてみたところ、約100msの遅延がありました。QuickTime Player や USB での処理遅延も含まれるので純粋に製品の遅延とは言えませんが、だいたいこんなもんなようです。これはマウスポインタとかでも結構気になるレベルです。

関連エントリー

2016年 10月 28日

ZenFone 3 上の Chrome for Android でサイトが中華フォントになる

tech

ZenFone3 (Android M) にしてからブラウザのフォントが Source Hans Sans になったのですが、このサイトの漢字がどうも中華フォントになってておかしいので調べていました。

で、結局どうやら

text-rendering: optimizeLegibility;

をつけると字形が中華フォントになってしまうようでした。

修正方法

text-rendering: optimizeLegibility をやめる

どういう理由かわかりませんが指定をやめれば日本語字形になります。

optimizeLegibility

このオプションはUAがフォントレンダリングを読みやすさに最適化せよという指定なのですが、このような弊害があるようです。

lang="ja" 指定する

これでも直ります。optimizeLegibility すると OS のロケールを無視してしまうんでしょうか?

しかし lang="ja" を指定すると、なぜかアルファベットに Source Hans Sans じゃないフォントが使われるようになって死にます。

とりあえずの解決方法

lang="ja" にするのがいいかと思ったんですが、アルファベットがおかしいので text-rendering: optimizeLegibility をやめるだけにしました。

関連エントリー