ブラザーの複合機DCP7010のスキャナがLinuxで動かない

表題の件ですが、プリンタのほうはCentOS7をインストール直後に正常に利用できることは確認しました。
スキャナも試したのですが、その時点でInvalid Argumentとか言われて正常に動かないことを認識したのですが、ほかにもやるべきことが山積していたので今まで原因の調査に着手できずにいました。

なお、現時点でも解決しておりませんので、解決策をお求めになられている方には大変恐縮ですがそのまま戻るボタンを押下してこのページのことは忘れてください。申し訳ございません。

さて、スキャナをsane-backendsで共有出来て大変便利なのですが、そのパッケージに付属するscanimageでスキャナを正しく認識できません。

具体的には、lsusbを行うと
Bus 001 Device 017: ID 04f9:0182 Brother Industries, Ltd DCP-7010

と、バス番号1、デバイス番号17で接続されているにもかかわらず、

$ scanimage -L
device `brother2:bus1;dev2' is a Brother DCP-7010 USB scanner

と、バス番号1、デバイス番号2で繋がってますとか勘違いされちゃってます。

とりあえずブラザーのホームページに行くと、新しいデバイスドライバがリリースされていたのでそちらを導入してみても、結果は変わらず。
USBの接続口をあちこち変えてみても、デバイス番号がインクリメントされていくにもかかわらずscanimageするとまるで違うバス番号とデバイス番号で認識するという結果は変わりませんでした。

ここでsane-find-scannerというコマンドがあったことを思い出して、試しに実行してみると
$ sane-find-scanner
found USB scanner (vendor=0x04f9, product=0x0182) at libusb:001:017

困ったことに、こちらは正しく判定できているじゃあありませんか。
同じsane-backendsのツールなのに結果が違う。

そこで、調べてみると、sane-backendsの最新版は1.0.25なのですが、CentOS7向けのパッケージは1.0.24。しかも、公式ホームページに掲載されている変更点に
Workaround for USB3 problems in Linux kernel.            
とあるじゃありませんか。
高鳴る期待を胸に早速取り寄せて、しかしもしダメだったときに消しやすいように1.0.24のsrpmを取り寄せて1.0.25用にしてrpm化してさっそくインストールしても、1.0.24の時と全く変わらず。

rpm化せずに直接make installしても、やっぱり同じでした。。。

そこで、もうこうなったら仕方がないので、scanimageをgdbで追いかけることにしました。

追いかけていくと、dll.cの1059行目で
     status = (*(op_get_devs_t)be->op[OP_GET_DEVS]) (&be_list, local_only);
という行でデバイスドライバ側の関数 sane_brother2_get_devices()をコールして、デバイスを取得していることが分かりました。
be_list[0]がそのﾘｽﾄなのですが、この構造体のメンバnameに、誤認されたバス番号とデバイス番号(この場合はbus1;dev2)が入っていたのでした。

つまり、デバイスドライバそのものが勘違いしていたというわけでした。。。

もうここでドライバはソースも公開されていないしどうにもならないのですが、もうちょっと調べてみると、SANE_DEBUG_BROTHER2環境変数を定義してあげると、デバイスドライバからデバッグメッセージが表示されるようだったので試してみると、dll.cの615行目の

  status = (*(op_init_t)be->op[OP_INIT]) (&version, auth_callback);

という行でsane_brother2_init()をコールした段階で
[brother2] brother init
[brother2] brother version: 1000001
[brother2] starting bus scan
[brother2] scanning bus 001
[brother2] found dev 046D/C043
[brother2] found dev 04F9/0182　←これがDCP7010
(以下略)

というようにUSBにぶら下がっている機器のベンダIDと製品IDがずらずらと列挙されました。

USBポートを繋ぎ替えてつらつら観察してみると、どうもこの表示される順番が例の"bus1;dev2"という表現となっている様子。この場合は2行目だからdev2だぞと。

これじゃ連番にしかならないから17なんて数値が出てくるわけがありませんな。。。

初期化の段階で既に誤認していたわけです。

結局、sane-backendsは正常に動作しており、デバイスドライバ側の問題だったことまでは突き止められました。
ただ、プリンタ機能のほうは、brotherから提供されているデバイスドライバで問題なく印刷できるのですが、プリンタドライバはusbがらみのことは一切cupsにお任せしているのかな?

ちなみに、ダメもとで
ln -s /dev/bus/usb/001/017 /dev/bus/usb/001/002
とかかましてデバイスドライバを騙せないかやってみましたが、
$scanimage --type=tiff >tmp.tiff
scanimage: open of device brother2:bus1;dev2 failed: Invalid argument
と言われてやっぱり駄目でした。

再起動予定は当分先なので試せませんが、多分これ、BIOSでxHCIモードを無効にすればあっさり動くんじゃないかな、と思います。

盛大に回り道した挙句の大山鳴動ネズミ0匹。
恥の記録にふさわしいのでここに記録いたします。

*ご参考: sane-backends.specのdiff
39c39
< Version: 1.0.24
---
> Version: 1.0.25
81c81
< BuildRequires: %{_bindir}/latex
---
> #BuildRequires: %{_bindir}/latex
186,193c186,193
< %patch0 -p1 -b .udev
< %patch1 -p1 -b .epson-expression800
< %patch2 -p1 -b .soname
< %patch3 -p1 -b .sane-config-multilib
< %patch4 -p1 -b .hwdb
< %patch5 -p1 -b .pixma_bjnp-crash
< %patch6 -p1 -b .static-code-check
< %patch7 -p1 -b .scsi-permissions
---
> #%patch0 -p1 -b .udev
> #%patch1 -p1 -b .epson-expression800
> #%patch2 -p1 -b .soname
> #%patch3 -p1 -b .sane-config-multilib
> #%patch4 -p1 -b .hwdb
> #%patch5 -p1 -b .pixma_bjnp-crash
> #%patch6 -p1 -b .static-code-check
> #%patch7 -p1 -b .scsi-permissions
203c203
< %configure \
---
> %configure --disable-latex \
229a230,231
>
> rm -f %{buildroot}%{_bindir}/umax_pp