[sane-devel] New backend kodakaio for kodak AiO devices - adding tosane-backends
On 2012-06-21 23:07, Paul Newall wrote: kodakaio was based on magicolor. I have made the minimum changes to get it to work. That's why so many references to magicolor remain. I'm not sure what the right approach is? If I have a function that is identical to the function in magicolor, it might be good for it to have the same name? I guess if I have changed a function, it ought to have a new name. The kodakaio scanners have nothing significant in common with the magicolor scanners. When I wrote the magicolor backend, I took the epson2 backend and did a huge search-and-replace to get rid of everything epson-specific and instead use magicolor-specific names (e.g. *_mc_* etc.) Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New backend kodakaio for kodak AiO devices - adding tosane-backends
On 2012-06-21 23:19, m. allan noah wrote: Clearly the license of magicolor applies to you now, though i wonder if the magicolor license is legitimate, based on its origin? Sorry, I don't understand which concerns you have. The magicolor backend is a fork of the GPL'ed epson2 backend, adjusted to magicolor-specific functionality and scanner protocol. The magicolor backend is under the GPL, too, so I don't think there should be any concern as to the ligitimacy of the license or the backend. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Konica-Minolta Magicolor 1690MF
On 2012-03-20 00:09, Steven Santos wrote: So, my 1690MF is detected by sane-find-scanner, but not by anything else. Hm, which version of sane are you using? Are you sure, the magicolor backend is enabled in the sane configuration (ie. does /etc/sane.d/dll.conf contain a line magicolor)? Any help? OS is Centos 6.2, the output of sane-find-scanner and scanimage are below. I have been hanging out on the IRC channel all day, but no one seems to be on... I don't have enough time for IRC (not even enough time for doing any sane development atm). And I suppose I'm the only one who can really help you, as I'm the author of the magicolor backend. [steven at server1]# scanimage -L Can you set some environment variables before calling scanimage, so you get (a lot of) useful debug output: export SANE_DEBUG_MAGICOLOR=9 export SANE_DEBUG_SANEI_CONFIG=127 export SANE_DEBUG_SANEI_USB=127 and then run scanimage -L (or xsane). You might first start with only the first variable (i.e. don't set the two *SANEI* variables). If that doesn't give you any output, then the magicolor backend isn't enabled at all. If you get some output, maybe we can track down the problem. Cheers, Reinhold -- -- Reinhold Kainhofer,reinhold at kainhofer.com, http://reinhold.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Konica-Minolta Magicolor 1690MF
On 20/03/2012 16:34, Steven Santos wrote: Their is no magicolor line in /etc/sane.d/dll.conf. Not sure how to get the version of SANE, but the backend packages are: sane-backends-1.0.21-3.el6 sane-backends-libs-1.0.21-3.el6 That's the issue: The magicolor backend was included only in 1.0.22 (see the News entry on the left side of the SANE homepage: http://www.sane-project.org/ ). Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Version of net-snmp
On 2012-01-01 18:35, Paul Newall wrote: I have ubuntu 11.10 with net-snmp 5.4.3 sane-backends configure says net-snmp 5.6 is needed Can anyone explain how the dependencies are determined for sane-backends? Since cups can use net-snmp 5.4.3 to find printers, is it really necessary to have 5.6 ? Is there some very useful extra feature in 5.6 ? Do many backends need 5.6 ? Only the magicolor backend (for KONICA MINOLTA magicolor 1690MF devices) uses the snmp package to detect the scanner. The reason for the 5.6 requirement is that snmp broadcast was introduced in that version. Even if the snmp library is not found, the magicolor backend will work, but automatic network detection will not work and you'll have to enter the IP address manually into the sane config file. cups also uses its own snmp implementation, AFAIK. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Many questions: JPEG-Compressed scan; public or password login; Error messages; Scanner HDD access
I'm currently trying to write a backend for Konica minolta bizhub
copiers/scanners (via TCP/IP). I have basically decoded the protocol:
http://wiki.kainhofer.com/hardware/bizhub_scan
Now, I have several issues concerning how to implement things in the backend:
1) The device supports user login, public login or completely free access.
It's clear how I can request a user/password if that is required. However, the
device I have at hand allows public access and optional password-protected
access. How can I let the user decide whether to use public access or
password-protected access? I'm attaching a screenshot of the corresponding
part of the windows TWAIN driver.
2) The device offers JPEG compression for grayscale and color scans, while
SANE so far only supports uncompressed RGB frames (which means that at 600dpi,
it will require up to 200MB of network traffic and RAM). What is the
recommended way to decompress the JPEG data? Link to libjpeg and use that? Or
is there some built-in code (afaics, sanei_jpeg.h is about creating jpeg
files, right?).
Most backends simply seem to disallow any compression if SANE_FRAME_JPEG is
not defined, which I don't like because sending the uncompressed data is
really a waste of bandwidth and it takes quite a while.
3) How can I get some custom error message to the front end? In particular,
the device will refuse to scan from FBF if there is some paper in the ADF.
(The reverse is easy, because the is SANE_STATUS_NO_DOCS to indicate that the
scanner expects paper in the ADF) How can I tell the user that he can't scan
from FBF if the ADF is loaded? SANE_STATUS_INVAL does not give the user any
clue what's wrong...
4) The device supports Paper discoloration or Background removal, both with a
setting of either Auto or a numeric values -6...+2 (see attached
screenshot). It seems that the proper way to implement this for an option is
to use a Range {-6, 2, 1} and capabilities with SANE_CAP_AUTOMATIC. This
really adds a checkbox in xsane to use either automatic or the manually given
numeric value.
However, I don't find a way to set the default to automatic...
5) The scanners also have a HDD installed, where one can store scans on the
disk and later retrieve them via the network (again, it's the same SCL-based
protocol like real scans). It basically works by logging in as a user, then
selecting a box and then selecting an image in that box. You can then download
that image just like you would really scan it.
How can I implement this as a sane backend (in particular the box+image
selection part)? Any ideas?
Thanks,
Reinhold
--
--
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-- next part --
A non-text attachment was scrubbed...
Name: Login_Dialog_WindowsTWAIN.jpg
Type: image/jpeg
Size: 17322 bytes
Desc: not available
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20111005/72528863/attachment-0002.jpg
-- next part --
A non-text attachment was scrubbed...
Name: ExtendedSettingsDialog_AutoOrNumericValue.jpg
Type: image/jpeg
Size: 18062 bytes
Desc: not available
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20111005/72528863/attachment-0003.jpg
[sane-devel] autoconf/configure and debug
Am Dienstag, 14. Juni 2011, 22:32:25 schrieb Chris Bagwell: configure will not default to CFLAGS=-g -O2 if you specify your own value. But if your getting two -O2 then something else may be adding it as well. Yes, the culprit is the net-snmp library... To get the include path for the net-snmp library, the binary net-snmp-config is called with --cflags and the result is appended to CFLAGS. Unfortunately, reinhold at einstein:~$ net-snmp-config --cflags -g -O2 -Ulinux -Dlinux=linux -Wall -Wstrict-prototypes -Wwrite-strings -Wcast- qual -I. -I/home/reinhold/.build/include Judging from the output of net-snmp-config --help, there is no other way to get the correct include pathes / libraries to link to net-snmp without dragging in all unneeded compiler flags... Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
Am Sonntag, 30. Januar 2011, um 20:31:13 schrieb m. allan noah: I'm trying to build this now on Fedora 14 with net-snmp enabled, and I get the following error: magicolor.c: In function 'mc_network_discovery_handle': magicolor.c:1800:2: error: 'netsnmp_indexed_addr_pair' undeclared (first use in this function) [...] make[2]: *** [libmagicolor_la-magicolor.lo] Error 1 And poking around in /usr/include/net-snmp reveals no definition for netsnmp_indexed_addr_pair. This is using net-snmp 5.5, which seems like it might still be a current release? Ah, sorry. It seems like the snmp auto-detection really needs net-snmp 5.6 :( In net-snmp 5.5 the UDP broadcast option was added, but apparently the devs missed to add a public-API method of extracting the responding IP address to the broadcast package. In 5.5 the netsnmp_udp_addr_pair struct was used in snmplib/snmpUDPDomain.cc, but that structure was never made public in any header file, so there was not way to get the IP address of the responding scanner. In net-snmp 5.6, the new netsnmp_indexed_addr_pair struct provides access to that information, so I now increased the required net-snmp version to 5.6, as 5.5 does not provide the required functionality... Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Add function sanei_usb_get_endpoint
Since we now have the possibility to change the endpoint used for a particular USB communication type, we also need a way to retrieve the current endpoint, so that one can e.g. decide whether a switch to a different endpoint is needed at all, or reset the endpoint to the old value after a single usb operation on a different endpoint. Attached is a simple patch that adds this function sanei_usb_get_endpoint to sanei/, plus a range check in sanei_usb_set_endpoint. Okay to push to master or does that already violate the feature freeze? Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -- next part -- A non-text attachment was scrubbed... Name: 0001-sanei_usb-Add-function-sanei_usb_get_endpoint-add-ra.patch Type: text/x-patch Size: 3366 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110131/4aca1da8/attachment.bin
[sane-devel] Add function sanei_usb_get_endpoint
Am Montag, 31. Januar 2011, um 21:42:04 schrieb m. allan noah: I will not complain if you commit, but I don't understand the point. You are not saving any cycles when you look up the value instead of just setting it. It's the same switch(), touching the same variable. Plus, if you DO decide you need to change it, you now have to call a second function. Your code now does more operations, not less. Yes, the purpose is not so much about deciding whether one has to use a different endpoint in normal operation, but about debugging (so that you can see in your own backend if the correct endpoint is used, when things don't work). And also about being able to restore the previous value if an endpoint is used for use one USB operationr.. With that new function, you can store the old endpoint, change it, do your USB operation and restore the old endpoint. That might be useful if a scanner uses one endpoint for most operations, but another endpoint for some very particular operations. I can imagine that the code is clearer if one sets and immediately resets the endpoint for the operation(s) on the less-used endpoint. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Add function sanei_usb_get_endpoint
Am Montag, 31. Januar 2011, um 22:11:14 schrieb m. allan noah: Good enough reasoning for me. Commit ASAP. Now, when you modify the magicolor backend to use it, that might be a new feature :) No, the magicolor backend currently uses just one endpoint (0x85), so I set it once and leave it unchanged. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
Am Samstag, 22. Januar 2011, um 11:54:29 schrieb Reinhold Kainhofer: Anyway, I have a local patch that gets rid of all the byteorder.h macros and instead copies all little-endian encoded values manually byte-by-byte. I'm currently away from home, so I cant test it with my magicolor scanner. I'll commit it as soon as I'm back home (probably tomorrow). Finally, I could test that patch and fix all the problems with it. I've now pushed a fix to the problems (I no longer use the htole32a etc. macros), so I hope that the backend now properly compiles also on 64-bit systems. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
Am Donnerstag, 20. Januar 2011, um 21:26:42 schrieb m. allan noah: What if you make the pointer unsigned char instead? If I use unsigned char*, then I get no warning. However, I fail to see why using an additional variable makes a difference... This does not work (b[0] is a pointer to an unsigned char, right?): unsigned char b[4]; htole32a(b[0], value); while this does: unsigned char b[4]; unsigned char *bp=b[0]; htole32a(bp, value); Anyway, I have a local patch that gets rid of all the byteorder.h macros and instead copies all little-endian encoded values manually byte-by-byte. I'm currently away from home, so I cant test it with my magicolor scanner. I'll commit it as soon as I'm back home (probably tomorrow). Sorry for the breakage! Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
Am Donnerstag, 20. Januar 2011, um 16:24:06 schrieb Brian Shaver: I'm having some trouble compiling with these changes committed. Below is the error I'm getting. I'll admit I haven't actually looked into the source code to confirm the change comes from this set of commits, but it seemed like it would be related. I'm running Fedora 13, and I've been able to build from the latest source as recent as 2011.01.12. Yes, these warning/errors come from my new magicolor backend. FWIW, I have been developing on a 32-bit KUbuntu Linux machine. magicolor.c: In function 'dump_hex_buffer_dense': magicolor.c:400: warning: format '%04x' expects type 'unsigned int', but argument 3 has type 'size_t' magicolor.c: In function 'mc_send': magicolor.c:492: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' Oops, that's a portability problem: How shall I print size_t objects with printf in SANE? A google search showed some people advocating the use of casting to unsigned long and printf'ing that: printf(%lu\n, (unsigned long)x); Shall I use that instead in SANE code? Or is it possible to use the z modifier for size_t arguments (which is not C90, AFAICS)? i.e. printf(%zu\n, x); magicolor.c: In function 'cmd_start_scan': magicolor.c:680: warning: pointer of type 'void *' used in arithmetic magicolor.c:680: warning: dereferencing 'void *' pointer magicolor.c:680: error: invalid use of void expression That line (and the other error in line 921) is simply calling the htole32a macro that is defined in byteorder.h (I didn't touch that one). Apparently, on your system, htole32a does not like a void* pointer as its first argument. On my system, I tried using the same code as the epson2-ops.c file: unsigned char params1[4]; htole32a(params1[0], value); but that gave me the compiler warning magicolor.c: In function 'cmd_start_scan': magicolor.c:678: warning: dereferencing type-punned pointer will break strict- aliasing rules The code unsigned char params1[4]; void *tmp = params1[0]; htole32a(tmp, value); didn't give me any warnings and worked fine on my system. magicolor.c: In function 'mc_network_discovery': magicolor.c:1868: warning: unused parameter 'host' That warning is there, because HAVE_LIBSNMP is not defined, so all of the commands in mc_network_discovery are commented out by a #if HAVE_LIBSNMP. Unfortunately, the autofoo reconf seems to have missed to add the HAVE_LIBSNMP variable to configure.h.in (so SNMP was never enabled, even if you have the net-snmp development files installed). I'll commit a fix for that shortly, so that warning won't appear when you have the net-snmp library (and dev files) installed. If you don't have it, then you'll still get that warning. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
Am Donnerstag, 20. Januar 2011, um 18:13:09 schrieb Adrian Glaubitz: Hi Allan, On Jan 20, 2011, at 6:00 PM, m. allan noah wrote: Hmm- looks like *p1 should not be void ptr. Try this change: sane-backends/backend/magicolor.c line 672 void *p1; should be unsigned char * p1; perhaps? Indeed, that fixes the problem along with a second change in the same backend. I generated a patch so you can see what I actually changed. It fixes the error, but still adds a compiler warning about signedness... I'm currently really thinking of getting rid of those htole32a calls and instead simply copying over all four bytes (in little endian) manually. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
Am Freitag, 7. Januar 2011, um 02:34:20 schrieb m. allan noah: I took a quick look at the code, and only see a few minor issues at first glance. 1. MC_AutoDetectionTimeout is not configurable at runtime 2. the code only calls sanei_usb_init during sane_init. This prevents long-running programs like button press daemons from finding hotplugged scanners. This was discussed recently on the list. 3. Some of your Option Groups could get their names from saneopts.h (SANE_NAME_GEOMETRY, TITLE, DESC, etc) Other than those things, it looks fine to me. Okay, here are updated patches (amended, so the whole backend is in one patch): http://www.fam.tuwien.ac.at/~reinhold/sane/magicolor_backend_patches/ -) Patches 0001 and 0002 are the USB patches you already reviewed (with copyright notices added as you wanted), so they are ready to be applied. -) Patch 0003 fixes a compiler warning that macros like htobe16 (byteorder.h) etc. are already defined. In that case, don't overwrite the existing definitions. (Chris Bagwell okay'ed it) -) Patch 0004 is the actual backend -) Patch 0005 is an alternative to running autoreconf (No manual changes done by me!). This patch should probably not be applied to git master, but someone (Chris Bagwell already volunteered) should run autoreconf with the recommended auto(conf|make|...) versions for sane installed. Changes to patch 0003 are in detail (compared to the last version you looked at): -) All three timeouts (SNMP detection, scan data read, other scanner responses) are configurable in the magicolor.conf file -) Cleaned up the options, reused pre-defined values as much as possible -) Call sanei_usb_init also in get_devices -) get_devices does not erase the list of scanners any more, but keeps still- existing scanners untouched, just removes removed and adds new scanners. There is, however, one issue that needs to be discussed in principle: How shall network auto-detection work in a sane way, once several backends support auto-detecting network-connected scanners? AFAICS, all backends are loaded sequentially, and the network auto-detection of each backend needs to wait for a certain time before timing out (even if one response was received, you have to wait the whole timeout, as there might be another device on the network). So, if 10 backends support auto-detection, and each uses a 2 second timeout, sane would have a startup time of 20 seconds... Clearly, that's not desirable. On Windows, that's not an issue, as the user only installs drivers for the scanners he really owns. However, sane provides all backends by default and runs each backend's initialization (get_devices), so here it is a problem. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] New magicolor backend for inclusion in git
As you know, I have been developing a magicolor backend for KONICA MINOLTA magicolor 1690MF devices (possibly also for other devices, but I don't have access to any other KONICA MINOLTA device that uses the same protocol -- The bizhub devices use a different protocol). In my view, it is now in a state so that it can be included in sane-backends (I'm using it regularly with xsane). The git patches can be found at: http://www.fam.tuwien.ac.at/~reinhold/sane/magicolor_backend_patches/ -) The first two (0001 and 0002) are for the sanei_usb functionality already send yesterday, -) 0003 is the actual backend, -) 0004 fixes some compiler warnings in byteorder.h, and -) 0005 includes only the changes from running autoreconf (i.e. no manual code changes!) The backend uses libsnmp (configure check added!) to optionally auto-detect a LAN-connected magicolor device. I have set the timeout to a very low value (a little more than 1 second!), so all systems without a magicolor scanning in the network are not held up by the SNMP auto-detection of the magicolor devices. On the other hand, if the network is really slow, this might mean that we miss an SNMP response that takes longer than 1 second! What do you think of this backend? Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Fwd: sanei_usb limitations
Am Dienstag, 4. Januar 2011, um 22:19:16 schrieb m. allan noah:
I think your previous idea of adding a a new function to set the
currently 'active' endpoint would be simpler.
Actually, that was never my idea for overriding the endpoints for a single
transactions, only for setting the global defaults. For the defaults, it is
definitely cleaner/easier to use one function to set the default endpoints.
For overriding the ep of a single transaction I don't like this approach too
much. Having to call a setter function first to set a global variable, before
you do the actual function call is highly thread-unsafe, and I would prefer to
pass the ep right to the function itself.
something like:
/*endpoint types*/
#define SANEI_USB_BULK_OUT 0
#define SANEI_USB_BULK_IN 1
...
What do you have against bitmasks like (USB_DIR_IN | USB_ENDPOINT_TYPE_BULK)?
Then we don't need any new constants...
sanei_usb_set_endpoint(SANE_Int dn, SANE_Int endpoint_type, SANE_Int
endpoint_number){
switch/case setting devices[devcount].
}
Then you've only got one new function, and no other code changes?
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Fwd: sanei_usb limitations
New patch is now up at: http://codereview.appspot.com/2823041/ Am Mittwoch, 5. Januar 2011, um 02:25:24 schrieb m. allan noah: On Tue, Jan 4, 2011 at 8:01 PM, Reinhold Kainhofer reinhold at kainhofer.com wrote: Am Dienstag, 4. Januar 2011, um 22:19:16 schrieb m. allan noah: I think your previous idea of adding a a new function to set the currently 'active' endpoint would be simpler. Actually, that was never my idea for overriding the endpoints for a single transactions, only for setting the global defaults. For the defaults, it is definitely cleaner/easier to use one function to set the default endpoints. certainly easier than a callback, but really you don't need the defaults to be changed once you have the ability to override it on a per-call basis. Actually, it is more convenient to change the default once during initialization and then don't have to care about passing the correct endpoint to each and every usb call. Anyway, since changing USB endpoints is rarely needed, I'm fine with adding just one function sanei_usb_set_endpoint, which sets the endpoint for a given type. If a backend needs to set a different endpoint for each call, then we might re-evaluate it. For now, every backend that needs to use two different endpoints of the same type needs to call sanei_usb_set_endpoint before each read/write call. What do you have against bitmasks like (USB_DIR_IN | USB_ENDPOINT_TYPE_BULK)? Then we don't need any new constants... where are USB_DIR_IN and USB_ENDPOINT_TYPE_BULK defined? :) include/sane/sanei_usb.h, lines 163 and 116. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Fwd: sanei_usb limitations
Am Mittwoch, 5. Januar 2011, um 15:25:59 schrieb m. allan noah: On Tue, Jan 4, 2011 at 8:55 PM, Reinhold Kainhofer reinhold at kainhofer.com wrote: New patch is now up at: http://codereview.appspot.com/2823041/ Looks good, except you forgot your copyright notice :) [...] Add your copyright notice and I'll commit it. Patch is attached (plus one patch that adds two sanity checks to sanei_usb_clear_halt, where a check for dn within the allowed range was missing). Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -- next part -- A non-text attachment was scrubbed... Name: 0001-Add-function-to-set-USB-endpoints-to-use.patch Type: text/x-patch Size: 4155 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110105/bfb4ca5f/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: 0002-Add-some-sanity-checks.patch Type: text/x-patch Size: 1783 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110105/bfb4ca5f/attachment-0001.bin
[sane-devel] Fwd: sanei_usb limitations
Am Samstag, 27. November 2010, um 00:10:54 schrieb m. allan noah: Reinhold Kainhofer has recently worked up a patch with an alternative implementation of your idea- and there was some discussion about yet a third mechanism, which relies on a 'setting' function to be called prior to transferring the data, much as the existing timeout control code works. I think that would be the best choice, not sure if Reinhold has gotten a chance to work on it. I have now updated my patch to also include a callback function to sanei_usb_open_extended, which is called before all available endpoints are listed. Patch is here: http://codereview.appspot.com/2823041/ The callback function (if given) is called for each combination of USB_DIR_IN/USB_DIR_OUT and USB_ENDPOINT_TYPE_CONTROL/USB_ENDPOINT_TYPE_ISOCHRONOUS/USB_ENDPOINT_TYPE_BULK/USB_ENDPOINT_TYPE_INTERRUPT. If a value 0 is returned, it is used as the default endpoint of that type (instead of the first encountered endpoint of that type). The old functionality of an additional argument to each usb read/write function to explicitly override the endpoint for a single transaction is still there, so one can now override the default used for all transfers as well as the endpoint for a single transfer. Any comments? Of course, I would love to get this into the 1.0.22 release, so other backends that need different endpoints for different communication types finally have this functionality available. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] sanei_usb limitations
Am Freitag, 26. November 2010, um 23:00:56 schrieb Hugo Bonstra Grostabussiat: In its current state however, sanei_usb API does not allow us to choose what endpoint to use for bulk transfers. It will always use the first IN and OUT endpoints it finds for functions sanei_usb_read_bulk() ans sanei_usb_write_bulk() respectively. To overcome that limitation, I thought of adding a few functions to sanei_usb API to allow specifying an alternative endpoint (for instance: sanei_usb_read_bulk_ep() which would take an additional ep argument of type SANE_Byte). That's basically what my patch does (there's some more work to do, like making it possible to use a default endpoint in the auto-detection phase): http://codereview.appspot.com/2823041/ Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Fwd: sanei_usb limitations
Am Samstag, 27. November 2010, um 00:10:54 schrieb m. allan noah: Reinhold Kainhofer has recently worked up a patch with an alternative implementation of your idea- and there was some discussion about yet a third mechanism, which relies on a 'setting' function to be called prior to transferring the data, much as the existing timeout control code works. I think that would be the best choice, not sure if Reinhold has gotten a chance to work on it. Not yet, I currently have so many other things to do that I don't find the time to work on sane. It's on my list, though. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] How to handle devices with multiple USB bulk-in endpoints
Am Dienstag, 2. November 2010, um 01:24:38 schrieb m. allan noah: I've not had a chance to look at the code, but i can say that this design is preferred over a new argument to the open() function, because some scanner might someday require communication with two endpoints of the same type concurrently. Actually, I meant whether we should additionally provide a way to globally override the default endpoint. Most devices use only one endpoint, so it doesn't make so much sense to require their backends to provide the endpoint to each and every USB command. Rather, one would pass the endpoints to be used to the open function and those will be set as default. Of course, with each individual USB command, one can override that default (which is only relevant for devices that use multiple endpoints for different operations). Also, sanei is 'internal' to sane. The interface is not stable, and we don't want it installed to the system. In fact, if we wanted to, we could just use your new functions in place of the old ones, and modify all the backends to use the -1 argument, without harming external development. So, the bigger question is, why are you not installing your backend using the infrastructure that sane gives you? Well, in the end I think the backend should be included with the stock sane- backends repository. However, I don't think that each new backend development process should start inside sane-backends for several reasons: 1) One never knows if a developer will really finish the backend (or at least get it to a usable stat), so cluttering sane-backends with half-finished, broken backends in development is not an option. 2) I want to provide a repository for others to try out the backend (and only that backend) while still in development. 3) During development, I wasn't sure which additional libraries would be required or which external code would be incorporated (in particular for SNMP detection in my case). I was also investigating the code from the CUPS project, which is GPL, but owned by Apple, so I doubt that the SANE exception (which AFAIU is needed for the backends in sane-backends) would be granted. 4) In particular for new backends, there will be users (larger institutions with managed installations) that want to use the backend with older sane versions. So, in short, I think that new backends should start in their own repository and can then later be incorporated into sane-backends. However, for this, one needs to copy (and continuosly sync) sanei from sane-backends to one's one repository. After all, sanei provides utility function for all the basic functionality common to most backends. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] How to handle devices with multiple USB bulk-in endpoints
Am Montag, 1. November 2010, um 01:03:23 schrieb m. allan noah:
Yes- what we should probably do is add a new set of
sanei_usb_{read,write,etc}_extended() functions, which take the
endpoint as a argument. Then all of the existing functions could
become a wrapper around those, which call a helper function to
determine the 'automatic' endpoint to use.
Here's a first shot at this extension:
http://codereview.appspot.com/2823041/
I added sanei_usb_*_extended functions, whenever an endpoint is used in the
code. If the endpoint argument is -1, then the auto-detected endpoints are
used (first found is taken, all others are ignored, just like things worked so
far).
I'm not sure if we should add an (optional) pointer to (bulk|int|...)-(in|out)
endpoints to the sanei_usb_open function to make it possible to override the
default in/out endpoints...?
What do you think?
With this patch, the magicolor backend works fine for USB-connections (two
bulk-in endpoints, where the second needs to be used)...
Cheers,
Reinhold
PS: Why are the files in sanei/sanei* and include/sane/sanei_*.h not installed
and rather directly linked to by the backends? The problem with this approach
is that any backend outside the sane-backends tree needs to copy those files
over and keep them up to date from sane-backends.
--
--
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] magicolor backend
Am Dienstag, 5. Oktober 2010, um 01:19:47 schrieb Reinhold Kainhofer: My backend for KONICA MINOLTA devices (currently only the magicolor 1690mf multi-function scanner) is progressing nicely. Here's a status update for my magicolor backend (git repo at http://repo.or.cz/w/sane-backend-magicolor.git ) The backend is basically working (both with USB and LAN connectivity, with 150-600dpi, mode BW/Gray/Color, source ADF/FBF). What is now working: -) Network auto-detection (using snmp) -) scanning (scanimage or xsane or any other frontend) o) from FBF or ADF o) with a resolution of 150/300/600dpi (color only 150/300dpi) o) in BW/Gray/Color. That's basically everything the device supports at all. -) Multiple pages can be scanned from the FBF Of course, there is still some work to do, in particular in two areas: -) Add more status checks (sometimes the communication times out, then one has to turn off and on the device). -) USB connections: The device has two bulk-in endpoints (#4 and #5), where SANE automatically uses the first one #4, while the scanner only responds to #5. Thus, USB communication does not currently work. However, as soon as I change sanei_usb_open not to ignore the second detected bulk-in endpoint, then scanning from USB works just as fine as over the network. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] How to handle devices with multiple USB bulk-in endpoints
My KONICA MINOLTA magicolor 1690mf has one bulk-out endpoint and unfortunately two bulk-in endpoints (#4 and #5, where it only uses #5 for all communication). SANE on the other hand chooses to only use the first bulk-in endpoint (i.e. #4 in my case), which will not work. There were some discussions a while ago to make that more configurable (i.e. make it work with such devices), but no code went in and no concrete proposals/suggestions how it should be done were made. In particular, see: http://lists.alioth.debian.org/pipermail/sane-devel/2009-March/024266.html http://lists.alioth.debian.org/pipermail/sane-devel/2007-July/019608.html http://lists.alioth.debian.org/pipermail/sane-devel/2006-September/017722.html http://lists.alioth.debian.org/pipermail/sane-devel/2006-December/018173.html So, since I need this functionality to get the magicolor 1690mf working with the magicolor backend, I'll have to tackle that problem. What would you think is the best approach to letting sanei_usb_open select which of the endpoints to use? Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Rising project : Support of Konica-Minolta Magicolor 2480MF
Am Freitag, 13. August 2010, um 06:29:56 schrieb Jean-Marc CHALLIER: Just a few words to say that the USB frame grabbing is (I think) finished. Giving a rapid overview of the captured data, it seems that all frames start with ESC (0x1B) and not 0x03, so the protocol is certainly not the same as the 1690MF... too bad. Does it look like the SCL-derived protocol used by the bizhub devices? In particular: http://wiki.kainhofer.com/hardware/bizhub_scan When looking at the captured data shown there, you might have to ignore the first 12 bytes of each command, as this header data might be used for LAN communication only... All commands start with ESC (0x1b), then * (0x2a), followed by a letter (f,o,s,w,z), optionally a number, followed by a letter, again numbers followed by a letter (can be multiple numbers - letter sequences... The end of the command is always indicated by the letter being uppercase). Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Who has a KONICA MINOLTA device? (or an Epson AL-CX16)
As you might know, I'm currently working on a backend for my KONICA MINOLTA magicolor 1690mf multi-function scanner. From what I heard from Ilia Sotnikov, several KONICA MINOLTA devices use a similar scanning protocol, so if anyone has such a device (other than the magicolor 1690mf; particularly bizhub ones and the magicolor 4680/4690 series), I would be very interested in more details about the device and it's capabilities. It would be great if I could get some data sniffs of a scanning operation. If you have such a device, please contact me and we'll talk about details (i.e. which operations, device capabilities, how to obtain data sniffs, and even how to test my alpha-quality backend). Also, if the device is a network device, the snmp variables offered by the device would be interesting for auto-detection (simply send me the output of snmpwalk -c public -v 2c IP_ADDRESS 1, where IP_ADDRESS is the IP-address of the device). Thanks a lot, Reinhold PS: The Epson AL-CX16 and AL-CX16NF look exactly like my magicolor 1690mf, so maybe they are even identical devices. I you have access to such a device, I would be just as interested... -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] magicolor backend (alpha-quality)
My backend for KONICA MINOLTA devices (currently only the magicolor 1690mf multi-function scanner) is progressing nicely. My current status (I would call it a working prototype) can be found in my git repository: http://repo.or.cz/w/sane-backend-magicolor.git So far, B/W and grayscale scanning (whole scan area and parts of it) work over the network (also in xsane). Of course, there are still lots of things to be done: -) USB connections are not yet supported at all -) network connections have no auto-detection (over SNMP) yet, so you have to enter net 10.0.0.5 (or whatever the IP of the scanner is) to the etc/sane.d/magicolor.conf configuration file) -) Color scanning does not properly work, as I still have to figure out the exact data format -) The backend is missing better error checks. In particular, the status is requested not often enough to be on the safe side. -) Scanning from the ADF works only for the first page, the other pages are ignored (and xsane reports that nothing was scanned?!) If you are interested in the backend, you can clone the git repo and compile the backend. It should configure and build propertly (i.e. ./configure; make; make install), but you need to have some libraries installed, but of course ./configure should tell you about missing dependencies. You can either install the backend to the default prefix (ie. no --prefix passed to configure), or to any other prefix you like. The latter only works if you have the latest development version of sane from git installed. In that case, you can set export SANE_CONFIG_DIR=/home/reinhold/.build/etc/sane.d:/etc/sane.d: export LD_LIBRARY_PATH=/home/reinhold/.build/lib/sane/:$LD_LIBRARY_PATH to force sane to take the configuration from that directory. To debug the backend, in case you run into problems (I would be surprised if you don't!), set the environment variables export SANE_DEBUG_DLL=127 export SANE_DEBUG_MAGICOLOR=9 to get useful debug output on the console. And finally, the usual warning: This backend is in the early stages of development, so try it at your own risk. If you do try it, make sure you are near the device to turn it off in case of emergencies. For me, B/W and grayscale scanning works, but in the past I had some problems with the scanner trying to send more data. The device then hangs and needs to be turned off and on again. I hope to have fixed that problem. Cheers, Reinhold PS: I now have a much better understanding of the scanning protocol, which I have again put on the web: http://wiki.kainhofer.com/hardware/magicolor_scan -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] [PATCH] Fix handling of SANE_CONFIG_DIR environment variable
Am Mittwoch, 15. September 2010, 15:14:28 schrieben Sie: I'm sorry, I seem to be doing most of the patch reviewing lately, and I've been really busy. Sure, no problem. I just don't want it to be completely forgotten. Take your time, the patch is not urgent (and I can't imagine a situation where the wrong pointers might pose a security vulnerability). Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] SNMP detection of network scanners?
For magicolor devices, KONICA MINOLTA provides SNMP functionality to detect the scanner (existence, model, etc.) and also some of its capabilities. Is there any SNMP framework provided by sane that can/should be used, or is it completely up to me to implement the SNMP conversation? I couldn't see anything SNMP-related in the default backends, so how would you suggest to implement SNMP? libsnmp or manually implementing SNMP from scratch (as cups seems to do)? Cheers, Reinhold PS: The backend for the magicolor 1690mf (and as Ilia Sotnikov noticed probably also some bizhub devices) is progressing nicely. Currently, I'm already at a stage where the scanning is started and the data is received by the backend. Of course, there are still some things where I don't know the exact purpose of command arguments, but the most important stuff is decoded and implemented. If you are interested, the current state can be found a git repository at repo.or.cz: http://repo.or.cz/w/sane-backend-magicolor.git WARNING: This is very much work in progress, so it will probably not work for you yet, and it might even lock up your device right now! Try it entirely on your own risk! -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] question about SANE backend fill_buffer function
Am Dienstag, 7. September 2010, um 21:37:26 schrieb Nicolas Martin: Le mardi 07 septembre 2010 ? 19:47 +0900, Gernot Hassenpflug a ?crit : I now have a problem where the pixels also need to be rearranged vertically. In particular, the first half of a line corresponds to the second half of a line much further along in the data. Is there any backend that has support for such processing, that I can look at for help? Or have I misunderstood what can be done with the current mp150_fill_buffer function in pixma_mp150.c? Yes, as I answered you, the pixma_mp150 implements a vertical shift reassembling that is needed by the CCD devices, as they produce scans with vertically shifted color planes. Maybe you can just use this, or use some modified version. The epson2 backend also has vertical color shifts. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Device with two USB bulk IN endpoints? (Was: Rising project: Support of Konica-Minolta Magicolor 2480MF)
Am Sonntag, 8. August 2010, 19:21:31 schrieb Ilia Sotnikov: Several months ago almost finished implementing the backend for Konica-Minolta devices (BizHub 162/132, DiMage 1611 to name them). [...] Basic command structure is: 03 [1 byte] (could be counted as 'signature') command [1 byte] argument1 size [4 byte] argument1 [argument1 size] ... argumentN size [4 byte] argumentN [argumentN size] end-of-record [4 byte] 00 00 00 00 Of course, you were correct with that command structure. I was missing one byte somewhere in my documentation, so the size arguments didn't align properly... - device has several endpoints of same type in one interface descriptor (3 and 5 being OUT, 4 and 6 being IN, uses 5 and 6 for scanning functions). SANE USB layer ignores them all but first. This is the reason I didn't submit the backend - didn't finish the USB layer changes. As I see MagiColor devices have separate descriptors/configurations for different functions, though. Actually, I'm running into the same problem with the magicolor 1690MF. It has one USB interface for the scanner and two for the printer. The problem is that the scanner interface has 3 bulk endpoints: #3 OUT, #4 IN and #5 IN. Unfortunately, the scanner uses endpoint #5 to send data, while SANE always takes the first bulk IN endpoint, which is #4 in this case. So, we are back to your problem http://lists.alioth.debian.org/pipermail/sane-devel/2009-March/024266.html Has anything happened in this direction? Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] [PATCH] Fix handling of SANE_CONFIG_DIR environment variable
Attached is a patch for the current sane-backends git, which fixes several
problems with the handling of the SANE_CONFIG_DIR environment variable. In
particular, the problems were:
-) backends/dll.c did not use SANE_CONFIG_DIR at all when searching for
dll.d/, but always only looked at the $prefix/etc/sane.d/dll.d/ path (i.e.
PATH_SANE_CONFIG_DIR as used in the ./configure call). This made development
of third-party backends quite cumbersome, if you also needed a working global
installation without your not-yet-working backend. In particular, you could
not have your own configuration to test just one backend, as the global dll.d/
directory was used no matter what. The only solution was to install a complete
sane-backends to the same prefix as your third-party backend.
-) in sanei/sane_config.c there was code like:
static const char *dir_list;
FILE * sanei_config_open (const char *filename)
{
char result[PATH_MAX];
[...]
if (!dir_list) {
[...]
dir_list = result;
}
/* use dir_list */
[...]
}
Of course, on the next call to sanei_config_open, dir_list will still be set
to something non-NULL, but point to the invalid result local variable of the
previous call. Similar problems happened with
dir_list = getenv (SANE_CONFIG_DIR);
which was also later pointing to an invalid string... In all these cases, of
course a strdup was missing.
The attached patch fixes those and also adds a function sanei_config_get_paths
to obtain all configuration pathes (from env var SANE_CONFIG_DIR and default
paths). Since that functionality is needed in sanei/sane_config.c as well as
in backend/dll.c, I figured I could just create one public helper function to
return the same config pathes for all use cases...
Althoughsanei_config_get_paths should never return NULL (except when it
runs
out of memory), I still check the returned pointer whenever it's called.
What's the stance of the sane project on such cases? Shall one always check
the return value, or assume it is valid, because when out of memory the
application will crash anyway?
The git commit msg:
Fix SANE_CONFIG_DIR handling, use it for dll.d/; Add sanei_config_get_paths
* include/sane/sanei_config.h sanei/sanei_config.c: Add function
sanei_config_get_paths to obtain all configuration pathes (from env var
SANE_CONFIG_DIR and default paths); fix pointers to invalid/freed
strings when SANE_CONFIG_DIR is set
* backend/dll.c: When searching for the dll.d/ directory, also use
the SANE_CONFIG_DIR env variable.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Fix-SANE_CONFIG_DIR-handling-use-it-for-dll.d-Add-sa.patch
Type: text/x-patch
Size: 7096 bytes
Desc: not available
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100903/5acca3ca/attachment.bin
[sane-devel] Device info about KONICA-MINOLTA magicolor 1690MF
Attached is an HTML page for the (unsupported) magicolor 1690MF scanner to be included on the homepage. I used the template.html from the website git repo and inserted the proper data there. I couldn't find out how the list of unsupported devices on the homepage is generated exactly, so I couldn't add an entry and link there... Would be nice if you could add this info to the homepage. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100827/90ff5503/attachment.html
[sane-devel] Rising project : Support of Konica-Minolta Magicolor 2480MF
Am Sonntag, 8. August 2010, um 19:21:31 schrieb Ilia Sotnikov: Several months ago almost finished implementing the backend for Konica-Minolta devices (BizHub 162/132, DiMage 1611 to name them). Looking through the sniffs Reinhold and Jean-Marc collected I could say that the protocol is kind of similar. Hey, that's great! Commands I've found: Start scan0x08 Get last error0x09 Stop scan 0x0a Get image params 0x0b Set scan area 0x0c Get status0x0d Read 0x0e Get buttons 0x0f Set button wait 0x10 Yes, I suspected some of these already (and looking at USB traffic gives some more insight into how things work)... Basic command structure is: 03 [1 byte] (could be counted as 'signature') command [1 byte] argument1 size [4 byte] argument1 [argument1 size] Actually, I can't confirm this The third byte here does not always correspond to the size of the argument... In particular, the 03 08 04... start the scan command does not fulfill it, for example. Contents of the commands and arguments are little-endian (host order). First argument serves also as a return value (if a command has one). What do you mean by that? Now the differences: - those devices I investigated are only black-white machines, also with fixed size of scan area (scanner accepts no X/Y coordinates, just an index of a predefined area). I workarounded the fixed area issue by scanning at a suitable predefined area (implemented) and than cropping to what frontend requested (not finished). We can probably include that. - device has several endpoints of same type in one interface descriptor (3 and 5 being OUT, 4 and 6 being IN, uses 5 and 6 for scanning functions). SANE USB layer ignores them all but first. This is the reason I didn't submit the backend - didn't finish the USB layer changes. As I see MagiColor devices have separate descriptors/configurations for different functions, though. Well, my USB sniffs basically use 3 and 5 only. I could provide the backend sources, looks like it would be suitable to operate MagiColor devices with some modifications. Yes, that would be really great! Thanks, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Rising project : Support of Konica-Minolta Magicolor 2480MF
Hello Jean-Marc, On Fri, 6 Aug 2010, Jean-Marc CHALLIER wrote: I wanted to start the development of a back-end for the Konica-Minolta Magicolor 2480MF Multi-Functional Peripheral (MFP). I have several questions : * Has such a project already been started ? I searched the archives of the mailing list without success, but... Now, that's a coincidence. Just a few days ago I posted a similar question to the list about the magicolor 1690MF... Unfortunately, I did not get any response. Please note, though, that I'm not a sane developer, but I'm looking into writing a backend. * Is there anything special about the programming of an MFP back-end, or does the underlying kernel take care about the printing/scanning mutual exclusion ? To be honest, I haven't yet thought about this, but I would suspect that the other devices don't respond while one is doing some work, or an error code is returned. * Does anyone know where I can get programming information about this device (any experience discussing with Konica-Minolta anyone ?) or will I have to reverse-engineer the communications between the PC and the scanner (gonna be tough...) ? I tried sending a request to the konica minolta support, but got absolutely no response. I did some reverse-engineering, and it doesn't seem so hard. It would be interesting to see whether the 2480mf uses the same protocol (and if so, what are the differences). Here are the results of my reverse-engineering so far: http://wiki.kainhofer.com/hardware/magicolor_scan * Is there anyone who would like to give me a hand, either with programming or at least with testing ? I can't help you much with programming, since I don't know the sane codebase yet, but at least the data protocol looks like it might be decoded. Cheers, Reinhold
[sane-devel] Rising project : Support of Konica-Minolta Magicolor 2480MF
Am Freitag, 6. August 2010, 11:12:30 schrieb Jean-Marc CHALLIER: Well, I must admit that I only searched for 2480MF, not for other devices, given the fact that this seems to be is very specific, even among the Magicolor series. First of all, it is USB-only, and if you do a man foo2lava, you'll see the following : [...] ..which means that the protocol is not the same as others. If I can't find any documentation, I'll take a look, at least, to the printer driver in order to understand a bit more about this 'OPL' protocol. That difference in the printing protocol does not indicate anything. The printing protocol and the scanning protocol/chip are independent, so it might still be that the 2480mf uses the same scanning protocol. I did some reverse-engineering, and it doesn't seem so hard. It would be interesting to see whether the 2480mf uses the same protocol (and if so, what are the differences). Here are the results of my reverse-engineering so far: http://wiki.kainhofer.com/hardware/magicolor_scan Waooh ! You've really done an impressive work there. You seem to have decoded the most important parts of the protocol. I'll have to get an USB sniffer to do the job (wireshark does not seem to be able to directly capture USB traffic on Windows...) I'm running Windows in VirtualBox and use wireshark (for wlan sniffing to the MFP) in Linux (since the traffic of the virtualized Windows will be run through the Linux network/usb drivers, too, of course). Under Linux, load the usbmon kernel module and you can use wireshark to also sniff USB traffic... Alternatively, there are USB Snoopy and sniffusb for Windows. Well, you can find a tutorial in the sane-project Web pages which seems to make things pretty straightforward... Actually, now. The backend-writing.txt file mainly talks about the directory structure and the coding style. The important backend.c file is only documented as usually contains the SANE API code, but without any further mention what exactly needs to be coded and what the API is exactly, and how USB/network connections are to be detected/handled. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Rising project : Support of Konica-Minolta Magicolor 2480MF
Am Freitag, 6. August 2010, 14:40:00 schrieb m. allan noah: Well, you can find a tutorial in the sane-project Web pages which seems to make things pretty straightforward... Actually, now. The backend-writing.txt file mainly talks about the directory structure and the coding style. The important backend.c file is only documented as usually contains the SANE API code, but without any further mention what exactly needs to be coded and what the API is exactly, and how USB/network connections are to be detected/handled. Apparently you missed the SANE Standard (API) documents: Yes, I really missed them. I looked at Contributing - Writing a Backend (Driver), which only referred to backend-writing.txt, but not to the SANE API... Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org
[sane-devel] Konica Minolta magicolor 1690MF multi-function printer/scanner
00 00 00 00 00 FE1D 00 . 0285 03 12 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 FE1E 00 00 00 00 00 00 00 00 00 00 00 ... 02C5 03 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 FE29 00 . 0305 03 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 FE2A 00 . 0345 03 0f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 FE2B 00 . 0385 03 0e 04 00 00 00 00 fe 00 00 00 00 00 00 00 00 -) After that, the scanner sends again some more data. -) After all data has been sent, the communication is as follows (I have truncated the 64-byte packets sent to the scanner again to 16 bytes to make it easier to read): 0A05 03 12 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E4A 00 00 00 00 00 00 00 00 00 00 00 ... 0A45 03 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E55 00 . 0A85 03 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E56 00 . 0AC5 03 0f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E57 00 . 0B05 03 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E58 00 . 0B45 03 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E59 00 . 0B85 03 0d 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00106E5A ff 00 00 00 00 00 00 00 00 00 00 ... 0BC5 04 03 00 ... Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -- next part -- This is sane-find-scanner from sane-backends 1.0.20 # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. searching for SCSI scanners: checking /dev/scanner... failed to open (Invalid argument) checking /dev/sg0... failed to open (Invalid argument) checking /dev/sg1... failed to open (Invalid argument) checking /dev/sg2... failed to open (Invalid argument) checking /dev/sg3... failed to open (Invalid argument) checking /dev/sg4... failed to open (Invalid argument) checking /dev/sg5... failed to open (Invalid argument) checking /dev/sg6... failed to open (Invalid argument) checking /dev/sg7... failed to open (Invalid argument) checking /dev/sg8... failed to open (Invalid argument) checking /dev/sg9... failed to open (Invalid argument) checking /dev/sga... failed to open (Invalid argument) checking /dev/sgb... failed to open (Invalid argument) checking /dev/sgc... failed to open (Invalid argument) checking /dev/sgd... failed to open (Invalid argument) checking /dev/sge... failed to open (Invalid argument) checking /dev/sgf... failed to open (Invalid argument) checking /dev/sgg... failed to open (Invalid argument) checking /dev/sgh... failed to open (Invalid argument) checking /dev/sgi... failed to open (Invalid argument) checking /dev/sgj... failed to open (Invalid argument) checking /dev/sgk... failed to open (Invalid argument) checking /dev/sgl... failed to open (Invalid argument) checking /dev/sgm... failed to open (Invalid argument) checking /dev/sgn... failed to open (Invalid argument) checking /dev/sgo... failed to open (Invalid argument) checking /dev/sgp... failed to open (Invalid argument) checking /dev/sgq... failed to open (Invalid argument) checking /dev/sgr... failed to open (Invalid argument) checking /dev/sgs... failed to open (Invalid argument) checking /dev/sgt... failed to open (Invalid argument) checking /dev/sgu... failed to open (Invalid argument) checking /dev/sgv... failed to open (Invalid argument) checking /dev/sgw... failed to open (Invalid argument) checking /dev/sgx... failed to open (Invalid argument) checking /dev/sgy... failed to open (Invalid argument) checking /dev/sgz... failed to open (Invalid argument) # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid
