Записки пингвиновода-любителя: Опыт установки HP Scanjet 3770 под Linux
Jan 30, 2016 07:07
Как-то не повезло сканеру HP Scanjet 3770 в плане поддержки под Linux. Причем не повезло даже по сравнению с его же собратьями, созданными на основе все того же чипа Realtek RTS8822. Тем не менее, если такой сканер вдруг попадет к вам в руки, то можно попробовать и пободаться. И даже вполне небезуспешно.
Итак, история эта началась еще в далеком 2004-м году, когда компания Hewlett-Packard впервые представила данное изделие миру. Вероятно, его создатели сочли в ту пору Linux достаточно экзотической системой для того, чтобы обеспечить эту модель сканера соответствующей поддержкой. Тем не менее, бета-версия соответствующего backend'а (драйвера) все же была написана. И попала в руки человека по имени Jean Philippe Boulanger, который и выложил ее для всеобщего доступа по ссылке: http://ftp.cyberbaladeur.fr/3770.tar.gz .
[История вопроса. Если неинтересно, то можно не открывать]В дальнейшем HP, похоже, потеряла всякий интерес к перспективе применения данного изделия под Linux'ом, сосредоточив свои усилия исключительно на обеспечении его работоспособности под управлением ОС "с дружественным графическим пользовательским интерфейсом". И преуспевала на этом поприще аж до 5 марта 2007 г., выпустив на прощанье "Базовый драйвер HP" версии 1.1 для ОС Microsoft Windows Vista (в 32- и 64-битном вариантах). На этом всякая поддержка данной модели сканера со стороны производителя завершилась окончательно и бесповоротно.
Что же касается Linux, то здесь тоже все складывалось достаточно непросто. Backend (драйвер), написанный ребятами с HP, и попавший в распоряжение Жана Филиппа Буланже (Jean Philippe Boulanger), представлял собой просто кусок проприетарного бинарного кода, скомпилированного только под архитектуру i386, и без исходного текста. По этой причине, разработчики проекта SANE не смогли включить его в состав официального дистрибутива своего продукта (обязательным условием для этого является наличие открытого исходного кода), но все же разместили ссылку на него на странице "SANE: External Backends (Drivers)"
Поначалу все шло вполне благополучно. Люди скачивали архив, действовали согласно инструкции, и при условии правильных и внимательных манипуляций, сканер поднимался и начинал нормально работать. Но где-то после 2007-го года одна за другой посыпались жалобы на то, что с новыми дистрибутивами Linux этот сканер работать отказывается. Пробовал несколько лет назад поднять его и я. Сначала под Ubuntu 10.04 LTS, потом - под Scientific Linux 6 (клон Red Hat Enterprise Linux 6). В обоих случаях безуспешно. По команде sane-find-scanner сканер обнаруживался, но backend hp3770 не работал: в ответ на команду scanimage -L выдавалось сообщение:
No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages).
В результате, после некоторого количества часов, потраченных на бесплодные усилия, вопрос со сканером был отложен, что называется, в долгий ящик. До тех пор, пока некоторое время назад я в конечном итоге не получил его в подарок. Соответственно, у меня появилось значительно бОльшее количество времени и вполне ощутимый стимул для возобновления экспериментов.
Что ж, попробуем разобраться, почему сканер отказывался работать.
1. Скачать архив 3770.tar.gz по ссылке: http://ftp.cyberbaladeur.fr/3770.tar.gz. 2. Распаковать его, и далее действовать в соответствии с инструкцией в файле README_hp3770.txt:
Фактически, внутри архива 3770.tar.gz находятся 2 архива с именами hp3770.tgz и libsane.tgz
1. Первый из них (hp3770.tgz) содержит собственно файл драйвера сканера (libsane-hp3770.so.1.0.13), 2 символическе ссылки на него под именами libsane-hp3770.so и libsane-hp3770.so.1 соответственно, а также файл Libtool-библиотеки libsane-hp3770.la. Все эти файлы надо распаковать в папку /usr/lib/sane, в дополнение к уже имеющимся там аналогичным файлам для поддержки других моделей сканеров (они появляются там в процессе установки SANE). "13" в имени файла libsane-hp3770.so.1.0.13 можно поменять на номер Вашей текущей версии SANE, но в этом случае придется заново создать символические ссылки на него под именами libsane-hp3770.so и libsane-hp3770.so.1.
2. Второй архив, libsane.tgz, содержит модифицированную библиотеку libsane.so.1.0.13, 2 символических ссылки на нее (libsane.so.1 и libsane.so), и Libtool-библиотеку libsane.la. Файл libsane.so.1.0.13 надо распаковать в папку /usr/lib, причем находившийся там файл libsane.so.1.0.хх, где xx - номер Вашей версии SANE, надо удалить, а libsane.so.1.0.13 переименовать в libsane.so.1.0.хх (например, libsane.so.1.0.21). Замена этого файла нужна потому, что исходная библиотека libsane.so собрана без модуля sanei_usb. В результате, попытка запуска драйвера libsane-hp3770.so приведет к сообщению об ошибке:
symbol lookup error: /usr/lib/sane/libsane-hp3770.so.1: undefined symbol: sanei_usb_init
Модифицированная библиотека libsane.so, входящая в состав архива, и собранная с добавлением модуля sanei_usb.lo, призвана устранить эту ошибку.
3. Для правильного назначения прав доступа к сканеру, далее надо, в случае Ubuntu, отредактировать файл /etc/udev/rules.d/45-libsane.rules, дописав в него следующие строки:
4. Далее следовало открыть файл /etc/sane.d/dll.conf, и дописать в него строку:
hp3770
Это необходимо для подключения драйвера libsane-hp3770.so при запуске SANE. Остальные строки, если соответствующие им сканеры в системе не используются, желательно закомментировать, чтобы облегчить и ускорить поиск и загрузку нужного драйвера.
Эксперименты решено было начать с дистрибутива, о котором имеется подтвержденная информация, что сканер с ним работает. Поэтому первой была установлена Ubuntu 6.06 LTS Dapper Drake (ядро 2.6.15, SANE 1.0.17). После выполнения вышеописанных действий, сканер сразу запустился. Положительные результаты были получены также с Ubuntu 6.10 Edgy Eft (ядро 2.6.17, SANE 1.0.18) и Ubuntu 7.04 Feisty Fawn (ядро 2.6.20, SANE 1.0.18).
Далее я предположил, что сканер не работает, начиная с какой-то определенной версии ядра или SANE. Для проверки этой версии была снова установлена Ubuntu 6.06 LTS Dapper Drake. И далее она последовательно обновлялась до следующего релиза, причем версии ядер и SANE при этом дополнительно варьировались в тех пределах, в которых удавалось удовлетворить зависимости и сохранить работоспособность системы.
В результате система была обновлена вплоть до версии Ubuntu 9.04 Jaunty Jackalope (ядро 2.6.28, SANE 1.0.19). При этом сканер продолжал работать. Значит, причина не в ядре, и не в версии SANE.
Дополнительную информацию решено было получить в процессе экспериментов с другим семейством дистрибутивов. Поскольку основным моим рабочим инструментом, в силу специфики нашей организации, является Scientific Linux (клон Red Hat Enterprise Linux), то в качестве объекта для дальнейших исследований был выбран его прототип - Fedora.
Для начала была установлена Fedora 11 Leonidas (ядро 2.6.29, SANE 1.0.19) - как крайний, который скомпилирован еще под архитектуру i586 (дело в том, что экспериментальный компьютер у меня был на базе процессора VIA Eden, который относится к семейству i586, а не i686, и поэтому установить на него последующие релизы без пересборки ядра не получилось бы). Сканер не работает. Что ж - возможно, это слишком "свежий" для данного драйвера дистрибутив.
Далее установил Fedora 7 Moonshine (ядро 2.6.21, SANE 1.0.18). Сканер все равно не работает. Попробовал еще ядра 2.6.18 от Fedora Core 6 Zod и 2.6.15 от Fedora Core 5 Bordeaux (последнее пришлось ставить принудительно, игнорируя зависимости при установке, и ругань на ошибку, если мне не изменяет память, запуска HAL при загрузке). Бесполезно, сканер не работает.
С горя собрал из исходников совершенно ископаемый SANE версии аж 1.0.14. При этом, в полном соответствии с напутствием месье Буланже, добавил в libsane модуль sanei_usb. Все равно не работает. То есть, SANE стартует, команда sane-find-scanner сканер находит, а scanimage -L его в упор не видит!
Миг решающего просветления настал чуть позже, когда на одном из форумов я откопал, что scanimage -L можно запускать не просто так, а в режиме отладки. Вот таким образом:
SANE_DEBUG_DLL=255 scanimage -L
На что незамедлительно последовал ответ:
[sanei_debug] Setting debug level of dll to 255.
[dll] sane_init: SANE dll backend version 1.0.12 from sane-backends 1.0.21 [dll] sane_init/read_dlld: processing /etc/sane.d/dll.d ... [dll] sane_init/read_dlld: done. [dll] sane_init/read_config: reading dll.conf [dll] add_backend: adding backend `hp3770' [dll] sane_get_devices [dll] load: searching backend `hp3770' in `/usr/lib/sane' [dll] load: trying to load `/usr/lib/sane/libsane-hp3770.so.1' [dll] load: dlopen()ing `/usr/lib/sane/libsane-hp3770.so.1' [dll] load: dlopen() failed (libstdc++.so.5: cannot open shared object file: No such file or directory) [dll] sane_get_devices: found 0 devices
No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). [dll] sane_exit: exiting [dll] sane_exit: finished
Так вот оно что! Оказывается, нашему драйверу для запуска просто не хватает библиотеки libstdc++.so.5. И libstdc++.so.6, которая имеется в системе, ей не замена. Файл драйвера скомпилирован с языка C++ компилятором GCC версии еще 3.3. А в связи с переходом на GCC 4.x, Runtime-библиотеки, обеспечивающие совместимость со старыми версиями, в более поздних дистрибутивах устанавливать по умолчанию перестали. Вот и не захотел работать сканер в более новых системах.
В дистрибутивах Fedora, RHEL, CentOS, Scientific Linux и им подобных, недостающая библиотека устанавливается командой:
# yum install compat-libstdc++-33
Для Ubuntu, Debian и им подобных дистрибутивов это будет, предположительно:
sudo apt-get install libstdc++5
За достоверность последнего я не ручаюсь (на практике не проверял), но суть операции именно такова: надо установить пакет, содержащий 32-битную библиотеку libstdc++.so.5.
Повторяем SANE_DEBUG_DLL=255 scanimage -L, и наблюдаем долгожданное чудо:
SANE_DEBUG_DLL=255 scanimage -L [sanei_debug] Setting debug level of dll to 255. [dll] sane_init: SANE dll backend version 1.0.12 from sane-backends 1.0.21 [dll] sane_init/read_dlld: processing /etc/sane.d/dll.d ... [dll] sane_init/read_dlld: done. [dll] sane_init/read_config: reading dll.conf [dll] add_backend: adding backend `hp3770' [dll] sane_get_devices [dll] load: searching backend `hp3770' in `/usr/lib/sane' [dll] load: trying to load `/usr/lib/sane/libsane-hp3770.so.1' [dll] load: dlopen()ing `/usr/lib/sane/libsane-hp3770.so.1' [dll] init: initializing backend `hp3770' [dll] init: backend `hp3770' is version 1.0.0 [dll] sane_get_devices: found 1 devices device `hp3770:libusb:001:002' is a Hewlett-Packard hp3770 flatbed scanner [dll] sane_exit: exiting [dll] sane_exit: calling backend `hp3770's exit function [dll] sane_exit: finished [scanjet@scanjet ~]$
Ура! Заработало!!!
Итак, каким же образом нам следует устанавливать и запускать злополучный сканер, с учетом всего вышеизложенного? Рассмотрим 3 случая на примере Scientific Linux 6.x (в той же степени это касается и Red Hat Enterprise Linux 6.x, CentOS 6.x, Oracle Linux 6.x и т.п.).
3. Распаковать вложенный архив hp3770.tgz. Второй архив (libsane.tgz) нам не нужен: с библиотекой libsane.so в нашей системе уже все в порядке, и заменять ее не надо.
4. Скопировать файлы libsane-hp3770.so.1.0.13, libsane-hp3770.so.1 и libsane-hp3770.so в папку /usr/lib/sane. Если вас смущает номер версии, то можете, исключительно ради визуального единообразия, переименовать libsane-hp3770.so.1.0.13 в libsane-hp3770.so.1.0.21. Но в этом случае символические ссылки на него libsane-hp3770.so.1 и libsane-hp3770.so придется создать заново. А можно и вообще ничего не переименовывать, все работает и так.
5. Открыть файл /etc/sane.d/dll.conf. Дописать в него строку:
hp3770
Остальные строки, если других сканеров в системе нет, желательно закомментировать (поставить в начале строки знак #).
6. Заходим в папку /etc/udev/rules.d, и создаем в ней файл следующего содержания:
Возможные неполадки. Возможно, xsane при запуске от обычного пользователя будет сегфолтиться (аварийно завершаться с ошибкой сегментирования). При этом от root'а xsane будет работать нормально. Если это происходит, попробуйте в файле /etc/sane.d/dll.conf раскомментировать еще какой-нибудь драйвер. Например, net или hp3900. Научного объяснения этому факту я пока что еще не придумал, но на практике помогло.
Примечание. Сканирование с этим драйвером возможно только со стекла. Слайд-модуль с верхним источником света и кнопки на крышке не работают.
2. 64-битная система.
К сожалению, драйвер данного сканера существует в природе только в виде 32-битной версии (бинарный код для архитектуры i386). Тем не менее, имеется (и проверена мною на практике) вполне реальная возможность заставить его работать и на 64-битной машине. Для этого достаточно просто заменить 64-битный SANE 32-битным:
1. Выковыриваем из системы 64-битный SANE:
# yum remove sane-backends
При этом крайне настоятельно рекомендую скопипастить куда-нибудь список удаляемых пакетов, чтобы относительно легко восстановить потери, если случайно удалится что-нибудь лишнее. Например, как-нибудь так: [Пример сохранения списка удаляемых пакетов]
================================================================================ Пакет Архитектура Версия Репозиторий Размер ================================================================================ Удаление: sane-backends x86_64 1.0.21-3.el6 @anaconda-ScientificLinux-201208021154.x86_64/6.3 4.4 M Удаление зависимостей: hpijs x86_64 1:3.12.4-6.el6 @sl 7.7 M hplip-libs x86_64 3.12.4-6.el6 @sl 335 k python-imaging-sane x86_64 1.1.6-19.el6 @sl 56 k sane-backends-devel i686 1.0.21-3.el6 @sl 33 k sane-backends-devel x86_64 1.0.21-3.el6 @sl 33 k sane-backends-libs i686 1.0.21-3.el6 @sl 7.4 M sane-backends-libs x86_64 1.0.21-3.el6 @anaconda-ScientificLinux-201208021154.x86_64/6.3 7.6 M sane-backends-libs-gphoto2 i686 1.0.21-3.el6 @sl 37 k sane-backends-libs-gphoto2 x86_64 1.0.21-3.el6 @anaconda-ScientificLinux-201208021154.x86_64/6.3 40 k sane-frontends x86_64 1.0.14-9.2.el6 @sl 132 k xsane x86_64 0.997-8.el6 @sl 1.9 M xsane-gimp x86_64 0.997-8.el6 @sl 645 k
Результат операции ================================================================================ Удалить 13 пакет(а,ов)
64-битный пакет xsane-gimp ОБЯЗАТЕЛЬНО УДАЛЯЕМ, вместе с 64-битным sane-backends-libs!
3. После этого процедура установки сканера сводится к описанной выше для 32-битной системы
Возможные неполадки:
1. 64-битный GIMP не видит 32-битного плагина xsane-gimp (в меню "Файл"-"Создать"-... отсутствует пункт "XSane: Выбор устройства..."). Для решения достаточно создать символическую ссылку на 32-битный файл /usr/lib/gimp/2.0/plug-ins/xsane из /usr/lib64/gimp/2.0/plug-ins:
2. Графическая оболочка YAGF к программе для OCR Cuneiform: сканирование через xsane происходит нормально, файл ~/.config/yagf/input.jpg сохраняется, но отсканированное изображение страницы в программу не передается.
Можно удалить целиком 64-битную версию программы YAGF, вместе с Cuneiform и словарями, и установить взамен 32-битные версии всего вышеперечисленного (руководство по установке см. здесь).
Попутно выяснился еще один неприятный нюанс: текущая версия пакета cuneiform-1.1.0-5.el6.nux.i686.rpm в репозитории nux-dextop требует в качестве зависимости при установке наличия ImageMagick - невзирая на то, что он уже установлен в системе. Можно потратить время и силы на выяснение причины, а можно просто воспользоваться предыдущей версией: cuneiform-1.1.0-4.el6.nux.i686.rpm, с которой эта проблема не возникает.
3. Сетевая установка.
Если ковырять подобным образом 64-битную систему жалко, по каким-либо причинам невозможно, или просто лень, или же если нужен доступ к сканеру с нескольких компьютеров, то имеет смысл расшарить наш сканер через сеть. Для этого нам понадобится компьютер, который можно использовать в качестве скан-сервера. Имеющие в последнее время хождение варианты с использованием в качестве скан-сервера роутера под управлением Linux в нашем случае неприемлемы, т.к. лично мне пока что неизвестны роутеры на базе архитектуры i386, а именно это является непременным условием успешной установки и работоспособности драйвера.
Итак:
1. Устанавливаем на компьютер, который будет использоваться в качестве скан-сервера, практически любой дистрибутив Linux под архитектуру i386, i586, или i686. С целью экономии ресурсов можно без графической оболочки ("иксов"). Причем этот дистрибутив совсем не обязательно должен совпадать с тем, который будет стоять на клиетских компьютерах.
Сам компьютер, выбранный в качестве скан-сервера, тоже может быть достаточно скромным по своим возможностям. Автор использовал для своих экспериментов компьютер на плате VIA EPIA ME6000 форм-фактора mini-ITX, с процессором VIA Eden 600 МГц - в силу ее компактности и экономичности. В дальнейшем эту плату можно будет поместить в компактный корпус и расположить в непосредственной близости от сканера - например, как подставку под него.
2. Устанавливаем на него xsane и драйвер нашего сканера. Для дистрибутивов Scientific Linux (Red Hat Enterprise Linux 6.x, CentOS 6.x, Oracle Linux 6.x и т.п.), а также Fedora см. раздел "32-битная система".
3. После того, как сканер успешно запустился локально на скан-сервере, устанавливаем сервер xinetd, обеспечивающий работу демона saned:
# yum install xinetd
4. Создаем файл /etc/xinetd.d/sane-port
service sane-port { disable = no port = 6566 socket_type = stream server = /usr/sbin/saned protocol = tcp user = root group = root wait = no }
5. Открываем файл /etc/sane.d/saned.conf и вписываем в него диапазон адресов локальной сети, из которого возможен доступ к сканеру, например:
8. На каждом из клиентских компьютеров в файле /etc/sane.d/net.conf указать IP адрес компьютера с подключенным сканером, например:
192.168.0.10
9. В файле /etc/sane.d/dll.conf, если не прописано, прописать или раскомментировать строчку:
net
10. Проверить доступность сканера можно выполнив команду (от root'a):
# scanimage -L
11. Чтобы дать доступ к сканеру пользователю, его необходимо внести в группу sсanner. Для этого создаем группу scanner:
# groupadd scanner
и добавляем в нее текущего пользователя:
# useradd -G scanner <имя_пользователя>
12. Чтобы изменения вступили в силу, надо пользователю выйти и войти в систему. После этого проверить доступ к сканеру, выполнив теперь уже от имени простого пользователя, в командной строке:
scanimage -L
Нюансы, баги и странности в работе через сеть.
При сканировании через сеть с сабжевым сканером наблюдается следующее явление. Сканирование с разрешением по 300 dpi включительно проходит без каких-либо особенностей. А вот уже при 600 dpi процесс сканирования наглухо зависает, если длина строки по горизонтали превышает примерно половину ширины листа. Если быть точным, то до 2729 точек включительно по X сканируются нормально, а 2730 и больше - не сканируются вообще. В этой ситуации надо либо уменьшать ширину сканируемой поверхности, либо уменьшать разрешение, либо уменьшать глубину цвета (например, вместо 24-битного цвета использовать Greyscale).
scanimage: scanning image of size 2730x5700 pixels at 24 bits/pixel
scanimage: acquiring RGB frame
(на этой стадии процесс останавливается, пока не нажмешь Ctrl-C)
^Cscanimage: received signal 2
scanimage: trying to stop scanner scanimage: min/max graylevel value = 255/0
scanimage: sane_read: Error during device I/O
Сетевой траффик при этом приобретает ярко выраженный аномальный характер:
Такое впечатление, что все переданные сервером пакеты тут же возвращаются клиентским компьютером обратно.
Данное явление: - Не зависит от дистрибутива Linux ни на сервере, ни на клиетской машине. Реально проверялись Ubuntu 6.06, 6.10, 7.04, 8.04, 9.04, Fedora 7, 11, Scientific Linux 6.7. - Не зависит от разрядности клиентского компьютера (пробовались 64- и 32-битные дистрибутивы) - Не зависит от версии SANE (пробовались различные версии в диапазоне от 1.0.14 по 1.0.21, включая собственноручно собранные из исходников) - Не зависит от типа используемой на сервере сетевой карты: в тестовых целях интегрированный адаптер VIA VT6102 заменялся на 3Com 3C905-TX, картина при этом не менялась - Не зависит от типа сетевой карты и способа подключения на клиетской машине (проверялись разные компьютеры, как с проводным, так и беспроводным подключением) - Имеет место только при сканировании по сети, на локальной машине сканер работает нормально со всеми вышеперечисленными дистрибутивами и версиями SANE.
В качестве рабочей версии допускаю, что на пути передачи данных через сеть где-то имеет место некий буфер размером 8К (или же ограничение по максимальному количеству пакетов -?), переполнение которого приводит к вышеупомянутой аномалии. В пользу этой версии говорит простой прикидочный расчет:
2729 точек * 3 канала * 8 бит/канал = 8187 байт (~ 8K вместе со служебными байтами)
Дополнительно (неизвестно, имеет ли это отношение к делу) наблюдаются некоторые странности в выполнении команды scanimage -T. Так, при локальном сканировании она дает следующий выход:
scanimage: scanning image of size 1132x1560 pixels at 24 bits/pixel
scanimage: acquiring RGB frame, 8 bits/sample scanimage: reading one scanline, 3396 bytes... PASS scanimage: reading one byte... FAIL No data scanimage: stepped read, 2 bytes... FAIL No data scanimage: stepped read, 4 bytes... FAIL No data scanimage: stepped read, 8 bytes... FAIL No data scanimage: stepped read, 16 bytes... FAIL No data scanimage: stepped read, 32 bytes... FAIL No data scanimage: stepped read, 64 bytes... FAIL No data scanimage: stepped read, 128 bytes... FAIL No data scanimage: stepped read, 256 bytes... FAIL No data scanimage: stepped read, 512 bytes... FAIL No data scanimage: stepped read, 1024 bytes... FAIL No data scanimage: stepped read, 2048 bytes... FAIL No data scanimage: stepped read, 4096 bytes... PASS scanimage: stepped read, 4095 bytes... PASS scanimage: stepped read, 2047 bytes... FAIL No data scanimage: stepped read, 1023 bytes... FAIL No data scanimage: stepped read, 511 bytes... FAIL No data scanimage: stepped read, 255 bytes... FAIL No data scanimage: stepped read, 127 bytes... FAIL No data scanimage: stepped read, 63 bytes... FAIL No data scanimage: stepped read, 31 bytes... FAIL No data scanimage: stepped read, 15 bytes... FAIL No data scanimage: stepped read, 7 bytes... FAIL No data scanimage: stepped read, 3 bytes... FAIL No data
Ошибка сегментирования
Хотя на обычном сканировании это никак не сказывается.
А если ту же команду подать через сеть, то в результате получим:
scanimage -T
scanimage: scanning image of size 1132x1560 pixels at 24 bits/pixel scanimage: acquiring RGB frame, 8 bits/sample scanimage: reading one scanline, 3396 bytes... PASS scanimage: reading one byte... PASS scanimage: stepped read, 2 bytes... PASS scanimage: stepped read, 4 bytes... PASS scanimage: stepped read, 8 bytes... PASS scanimage: stepped read, 16 bytes... PASS scanimage: stepped read, 32 bytes... PASS scanimage: stepped read, 64 bytes... PASS scanimage: stepped read, 128 bytes... PASS scanimage: stepped read, 256 bytes... PASS scanimage: stepped read, 512 bytes... PASS scanimage: stepped read, 1024 bytes... PASS scanimage: stepped read, 2048 bytes... PASS scanimage: stepped read, 4096 bytes... PASS scanimage: stepped read, 4095 bytes... PASS scanimage: stepped read, 2047 bytes... FAIL No data scanimage: stepped read, 1023 bytes... FAIL No data scanimage: stepped read, 511 bytes... FAIL No data scanimage: stepped read, 255 bytes... FAIL No data scanimage: stepped read, 127 bytes... FAIL No data scanimage: stepped read, 63 bytes... FAIL No data scanimage: stepped read, 31 bytes... FAIL No data scanimage: stepped read, 15 bytes... FAIL No data scanimage: stepped read, 7 bytes... FAIL No data
scanimage: stepped read, 3 bytes... FAIL No data
При этом имеет место аномалия, описанная выше.
Итак, в результате проведенных экспериментов получена вполне достаточная функциональность сабжевого сканера под управлением ОС Linux, причем как для 32-битных, так и для 64-битных систем. Функциональность сканера при работе через сеть имеет ограничение по разрешающей способности до 300 dpi для цветных изображений и до 600 dpi для монохромных, обусловленную аномалией в процессе передачи данных, природа которой пока не установлена. Если кто-то поможет решить этот ребус ко всеобщей пользе, я буду очень признателен.
P.S. Для линейки сканеров HP на основе чипа RTS8822 существует также драйвер (backend) с открытым исходным кодом. Он входит в стандартный состав дистрибутива SANE, и носит название sane-hp3900. Данный backend обеспечивает поддержку моделей HP ScanJet 3800, HP ScanJet 3970, HP ScanJet 4070 Photosmart, HP ScanJet 4370, HP ScanJet G3010, а также UMAX Astra 4900/4950. Но, несмотря на очевидное сходство аппаратной части, HP ScanJet 3770 в число поддерживаемых этим драйвером моделей не входит. В силу своей открытости, этот backend доступен для любой архитектуры, и теоретически может быть доработан с целью обеспечения поддержки также и модели HP ScanJet 3770. По крайней мере, если данный драйвер "обмануть", дописав в файл /etc/sane.d/hp3900.conf строки:
# HP Scanjet 3770 usb 0x03f0 0x2505
что соответствует сабжевому сканеру, и раскомментировав в файле /etc/sane.d/dll.conf строку:
hp3900
то наш сканер начинает распознаваться и управляться данным драйвером. При этом выбор из числа из доступных моделей, при определенных настройках (особенно при низком разрешении), позволяет в отдельных случаях получить хотя и искаженные и непригодные для использования, но все же вполне осмысленные изображения. Так что, в принципе, доработка упомянутого драйвера вполне возможна. Другое дело - это целесообразность подобной доработки, с учетом необходимых для ее осуществления затрат труда и времени.