[sane-devel] Epson Perfection V500 Photo
Ronald F. Guilmette rfg at tristatelogic.com writes: In message 87fwi43zbq.fsf at avasys.jp, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: WRT FreeBSD support, may I suggest you submit a support request[2] so we get concrete info on how badly people want this. I'm not sure that I understand your request. Could you elaborate? Submit a support request saying you want to use your V500 scanner with FreeBSD but that the current iscan packages + interpreter package don't work. The decision makers don't read the mailing list. They do get an overview of the support requests we get. *You* have to put your issue on *their* radar. I mean I want it. I want it bad. How bad? On a scale from one to ten? Well, you know, I suppose that there are many things in this life that I want more... youth, good looks, lots of money... ;-) If you are thinking that many other people will suddenly arise from out of the woodwork to clamor for a FreeBSD port of your driver, once I have formally done so, well I seriously don't think that's realistic. It's clear that FreeBSD doesn't have nearly the market penetration of Linux at this point, so there is never going to be a numerically huge demand. But those of us who use FreeBSD sure would think kindly of your company if you helped us on on this. No, that's not what I'm thinking but if you don't get your issue on the radar of those who decide what get's done and what doesn't, it won't even be considered. [...snip...] P.S. If you guys already have the code to make this work, then why not just do a FreeBSD port and release it as unsupported? I cannot imagine that doing that would take much work on your part. I mean it isn't as if Linux and FreeBSD are such radically different environments. In fact they are virtually identially in most respects. And also, as I understand it, access to this typr of scanner on FreeBSD is now performed exclusively through a low-level thing called libusb which is presenting some sort of nice clean API to higher level code that wants to access USB devices. So if your code already knows how to interface to libusb on Linux... well... I mean seriously, how hard would it be to just recompile the stuff for FreeBSD and then just stick the result on your FTP server under unsupported/ or something like that? Of course, if you are willing to do this I'll be more than happy to volunteer to be the guinea pig and test the thing out for you and see if it even works. You might want to include this in your support request. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] Thread code review and testers
Chris Bagwell wrote: I'm looking for a reviewer of attached patch and I'm also hoping someone has a scanner who's driver uses threads can test this patch to verify no regressions occurred (be sure and use --enable-pthread on configure). Current code assumes/requires that SANE_Pid is represented as an integer on all platforms because we do pid == -1 checks everywhere. Pthreads says that it can not be assumed pthread_t is an integer and on windows platform it in fact is not an integer. Attached is my solution to abstract out checks for valid PID's so that it will work with windows and any other pthread implementation that is similar. For each backend that gets ported to mingw and uses threads, it will need to switch to use sanei_thread_is_invalid(pid) instead of (pid == -1). That was not done as a part of this test patch. Good job! I cringed at the code when I saw it mangling pthread_t, but now I can cringe less. I unofficially say that your patch looks good. I'll try the latest git checkout plus this patch and see if it works any better for me.
[sane-devel] Thread code review and testers
Michael Cronenworth wrote: I'll try the latest git checkout plus this patch and see if it works any better for me. The latest git + only your patch now compiles on the first try. However, the resulting DLL doesn't find the scanner. sane-find-scanner.exe finds the USB device, but scanimage.exe and my program that uses libsane.dll do not find the scanner. I had a feeling it is looking for the config file to reference the USB vendor ID and product ID, but it cannot find it. I moved the *.conf files into the same directory as the runtime DLL and EXE files and now the scanner is found. Scanning works, too. I would guess that between .21 and .22 that the config file handling changed? It would be nice to have the Windows binaries look for the config files in a few sub-directories besides the current directory. (./etc, ../etc ./) Unfortunately this trick doesn't make the 64-bit DLL work. Something else is wrong.
[sane-devel] 64-bit compile (was:Thread code review and testers)
Michael Cronenworth wrote: Unfortunately this trick doesn't make the 64-bit DLL work. Something else is wrong. My previous message was when I compiled for 32-bit only. The 64-bit DLL I was using was the 1.0.21 version. The 64-bit compile against the latest git code doesn't complete. The backend make doesn't include sanei_magic.lo so the fujitsu object has some undefined function calls. It seems this is a byproduct of using PRELOADABLE_BACKENDS. I've attached a patch for it. The resulting 1.0.23 DLL doesn't even find the USB device so maybe something is up with libusb. I'll keep looking. -- next part -- A non-text attachment was scrubbed... Name: sane-win32-preload.patch Type: text/x-patch Size: 6247 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/2007/6fb90c35/attachment.bin
[sane-devel] Epson scaner/epkowa, SANE and 16 bit scaning
Hi, I am using Epson v500 scaner with epkowa driver. iscan 2.27.1-4 iscan-data 1.11.0-1iscan-plugin-gt-x770 2.1.1-1 Driver is working. I am able to scan with XSane/Sane, iscan or Vuescan. Vuescan scans images with 8 and 16 bit depth. But whenever I choose 16 bit depth on epkowa config panel in XSane/iscan program is crashing. I try check logs - but can't find nothing interesting. I've found some old posts at:http://lists.alioth.debian.org/pipermail/sane-devel/2008-June/04.htmlwhich describing some problems with 16 bit depth on some Epson scaner. Can somebody confirm that it still doesn't work? Or maybe somebody using it without problems. I need feedback. I'd like to use Negfix script:https://sites.google.com/site/negfix/so I don't need most features of Vuescan and its Pro license (for raw scaning). -- michalus
[sane-devel] 64-bit compile
Michael Cronenworth wrote: The resulting 1.0.23 DLL doesn't even find the USB device so maybe something is up with libusb. I'll keep looking. It helps if I have libusb in my 64-bit MinGW environment. Rebuilding SANE 1.0.23 results in a working, scanning 64-bit DLL! Woo hoo.
[sane-devel] 64-bit compile (was:Thread code review and testers)
On Mon, Nov 7, 2011 at 11:27 AM, Michael Cronenworth mike at cchtml.com wrote: Michael Cronenworth wrote: The 64-bit compile against the latest git code doesn't complete. The backend make doesn't include sanei_magic.lo so the fujitsu object has some undefined function calls. It seems this is a byproduct of using PRELOADABLE_BACKENDS. I've attached a patch for it. Thanks for patch. I'll commit it soon.
[sane-devel] Thread code review and testers
On Mon, Nov 7, 2011 at 10:55 AM, Michael Cronenworth mike at cchtml.com wrote: Michael Cronenworth wrote: I'll try the latest git checkout plus this patch and see if it works any better for me. The latest git + only your patch now compiles on the first try. However, the resulting DLL doesn't find the scanner. sane-find-scanner.exe finds the USB device, but scanimage.exe and my program that uses libsane.dll do not find the scanner. I had a feeling it is looking for the config file to reference the USB vendor ID and product ID, but it cannot find it. I moved the *.conf files into the same directory as the runtime DLL and EXE files and now the scanner is found. Scanning works, too. Glad to hear its working! Your doing better then me so far... but I'm almost there. So far, I can't get the preloaded backends to kick in from libsane-1.dll. Did you do anything special to get it working? I just committed a fix to libtool that lets us now correctly build each individual backend as its own DLL. I'm not sure I'll get the urge to fix this soon but it wouldn't be hard to get the dll backend to load these DLL's now that we are correctly building them. After that DLL build fix, I can copy libsane-epson2-1.dll to same directory as scanimage.exe but name it libsane-1.dll and now the epson2 backend is working with scanimage.exe. It correctly detects my network epson scanner but then fails to open the socket correctly. Hopefully, it will be a simple fix. I would guess that between .21 and .22 that the config file handling changed? It would be nice to have the Windows binaries look for the config files in a few sub-directories besides the current directory. (./etc, ../etc ./) The logic was modified but don't see exactly any difference in behaviour. The best solution right now is to set SANE_CONFIG_DIR to where ever you store them. Maybe in future we can modify to use standard Windows DLL search logic and look inside same directory as .exe. I've never done that before but I guess it wouldn't be hard. Unfortunately this trick doesn't make the 64-bit DLL work. Something else is wrong. I'm glad to hear in your other post that 64-bit is now working for you as well! I'm sure there are tons of people that would like to run a native Windows executable (non-cygwin) from command line/background task to do some scanning. Chris
[sane-devel] Thread code review and testers
On Mon, Nov 7, 2011 at 7:44 PM, Chris Bagwell chris at cnpbagwell.com wrote: After that DLL build fix, I can copy libsane-epson2-1.dll to same directory as scanimage.exe but name it libsane-1.dll and now the epson2 backend is working with scanimage.exe. It correctly detects my network epson scanner but then fails to open the socket correctly. ?Hopefully, it will be a simple fix. I got it working. It was minor changes to enable winsock2 correctly and how to set up non-blocking. Now I can do network scans from my epson scanner using the epson2 backend. On top of that, I'm able to compile the scanimage.exe from my Fedora box and I'm running the scanimage.exe using wine from same box. Now thats the way to develop windows applications. :-) Chris
[sane-devel] Thread code review and testers
On 11/07/2011 09:56 PM, Chris Bagwell wrote: I got it working. It was minor changes to enable winsock2 correctly and how to set up non-blocking. Ah, glad to hear it. Now thats the way to develop windows applications. Yes it is. If you ever need any assistance feel free to pop questions on the Fedora mingw list or #fedora-mingw IRC channel. The last hurdle is to be able to build libusb with MinGW. Then I can package SANE as a MinGW package in Fedora.
