[sane-devel] hp7400c won't work with latest sane ?
Yeah, just that X segfaulted, does not tell much. However, you could test with scanimage in a xterm (or variant) or even the console text terminal to check your basic image processing functionality ... Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name Well scanimage doesn't crashing xorg. In this moment i've compiled old sane-backends 1.0.18 and my scaner had return to previous state, it's working for now, but i think that this situation is not so fine. Is there anyway to solve this problem ? when i catch some more time i will try to investigate a bit more this issue. Regards
[sane-devel] hp7400c won't work with latest sane ?
m. allan noah pisze: On 4/3/08, Tymoteusz tymoteusz.drozd at gmail.com wrote: Yeah, just that X segfaulted, does not tell much. However, you could test with scanimage in a xterm (or variant) or even the console text terminal to check your basic image processing functionality ... Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name Well scanimage doesn't crashing xorg. In this moment i've compiled old sane-backends 1.0.18 and my scaner had return to previous state, it's working for now, but i think that this situation is not so fine. Is there anyway to solve this problem ? yes- get a debug log like i asked for previously allan when i catch some more time i will try to investigate a bit more this issue. Regards -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org oups sorry i had forgotten to add ur email adres to my previous post log is here http://atelier1.website.pl/N-A Regards
[sane-devel] hp7400c won't work with latest sane ?
Hi, On 04.04.2008, at 01:05, Tymoteusz wrote: m. allan noah pisze: On 4/3/08, Tymoteusz tymoteusz.drozd at gmail.com wrote: Yeah, just that X segfaulted, does not tell much. However, you could test with scanimage in a xterm (or variant) or even the console text terminal to check your basic image processing functionality ... Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http:// rene.rebe.name Well scanimage doesn't crashing xorg. In this moment i've compiled old sane-backends 1.0.18 and my scaner had return to previous state, it's working for now, but i think that this situation is not so fine. Is there anyway to solve this problem ? yes- get a debug log like i asked for previously allan when i catch some more time i will try to investigate a bit more this issue. Regards -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org oups sorry i had forgotten to add ur email adres to my previous post log is here http://atelier1.website.pl/N-A It is just inf. waiting for light warmup. I just yesterday found a similar problem with a newer hardware and will provide a workaround when done. Can you test if you can scan successfully if you let the scanner warm it's light before you scan with the Avision SANE backend? Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] hp7400c won't work with latest sane ?
Rene Rebe pisze: Hi, On 04.04.2008, at 01:05, Tymoteusz wrote: m. allan noah pisze: On 4/3/08, Tymoteusz tymoteusz.drozd at gmail.com wrote: Yeah, just that X segfaulted, does not tell much. However, you could test with scanimage in a xterm (or variant) or even the console text terminal to check your basic image processing functionality ... Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name Well scanimage doesn't crashing xorg. In this moment i've compiled old sane-backends 1.0.18 and my scaner had return to previous state, it's working for now, but i think that this situation is not so fine. Is there anyway to solve this problem ? yes- get a debug log like i asked for previously allan when i catch some more time i will try to investigate a bit more this issue. Regards -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org oups sorry i had forgotten to add ur email adres to my previous post log is here http://atelier1.website.pl/N-A It is just inf. waiting for light warmup. I just yesterday found a similar problem with a newer hardware and will provide a workaround when done. Can you test if you can scan successfully if you let the scanner warm it's light before you scan with the Avision SANE backend? Yours, Well i have left scanner for warmup but this didn't give any difference. Regards.
[sane-devel] In progress: TRUST Imagery 9600SP (TECO_VM6552)
Gerard Klaver wrote: On Thu, 2008-04-03 at 14:56 +0200, Ralph D. Ungermann wrote: Hello Ralph, I am the maintainer of the teco2 backend, if you have a link (or send a zip file with data to mailbox) to your backend i can have a look and add improvements to the teco2 backend. Hello Gerard, nice to meet you! I'll send you my sources ASAP. I hope, you'll like my resource management: - sane_init() doesn't open every device at startup - no device needs to allocate a 64KB scsi buffer - sane_read() doesn't wait for the whole image to be read - sane_read() polls for `cancel' While the device handling issues aren't so important on a desktop with a single scanner, the `no-wait' and `cancel' things have been major pain reliefs for me. And most surely you will like my color scans: my scanner just tells me, _which_ color it has sent; hence no more sophisticated guessing algorithms, no more huge color permutation tables, and no more restrictions to preselected resolutions. Just pick a line, and if the scanner says `red', distribute it to the red bytes. This change would save you many hundred lines of code. Unfortunately, you can't call this an `obvious bug fix'. So don't do it, unless you can test it for all supported scanners. Here is my offer: you tell me, which scanner models you have your hands on. Then I can try to include one of them into my backend. If we're lucky, it'll work, and we can build an enhanced new backend at least for the scanners we own, leaving the old drivers untouched. -- ralph
[sane-devel] In progress: TRUST Imagery 9600SP (TECO_VM6552)
Hello Frank, A month ago, I learned, that you do not maintain these drivers any more (I thought it was the headline of http://www.zago.net/sane, but I can't find it there any more). I'm highly pleased to see you here. Let me take the chance to thank you for the code and its documentation. Without that, I'd have had no chance to get my scanner working (and I really had a minute's silence before deleting your function adjust_raster()). Frank Zago wrote: m. allan noah wrote: [to Gerard Klaver] Gerard- Sorry, I thought these backends were all unmaintained. I stand corrected. Can you say how similar the protocol is on all these machines? Is it reasonable to combine the backends? No. There is 3 backends for a reason. I could take a look at Ralph's code and make sure it's indeed different than the other scanners. In that case the best solution would be to create a teco4 backend. From a diff between teco2.c and teco3.c, I cannot figure out, why you decided to separate them. Your hints are welcome. I'll send you (and Gerard) my sources when I'm back home. But let me redirect the further discussion of this topic to my response to Gerard's post, please. For now, let me recapitulate: a) I have a working driver for the VM6552. We can *add* it to S.A.N.E. as teco4, so everybody in this world will have it on his/her hard disk tomorrow. Allan obvoisly has no problem with wasting other people's disk space, but I'm afraid, that nobody out there needs it, because today only one VM6552 scanner has survived, and that lucky one is sitting on my desk at home. So I'm still hesitating. b) I didn't intentionally add anything special to the VM6552. So I presume, that my driver will still work with the VM3552, and thus may *replace* the existing teco3 backend. This would actually _save_ the world's disk space. But I have no way to prove it, and I hesitate to deliver untested software. c) My main achievements are putting the colors right, and slimming resource usage. These may be also applicable to teco2. I'll stay in contact with Gerard for that purpose, and we'll take care, that this will _not_ lead to teco5. since I don't have any scanner left I don't think it's a good idea to patch an existing backend besides fixing obvious bugs. Agreed! Unless nobody with a VM3552 helps us, this will rule out b). I'll sleep over it, and probably become the maintainer of teco4. But I'd appreciate you having a glance at my code before. -- ralph
