[sane-devel] [patch] umax_pp: fixes for x86_64
On Sat, Nov 13, 2004 at 01:50:50PM -0600, Frank Zago wrote:
> This patch makes umax_pp recognize the amd64 cpus.
> --- backend/umax_pp_low.c 8 Oct 2004 05:16:43 - 1.61
> +++ backend/umax_pp_low.c 13 Nov 2004 19:34:18 -
> @@ -208,7 +208,7 @@ sanei_outsl (unsigned int port, const un
>
>
> /* linux GCC on i386 */
> -#if ( ! defined SANE_INB ) && ( defined HAVE_SYS_IO_H ) && ( defined
> __GNUC__ ) && ( defined __i386__ )
> +#if ( ! defined SANE_INB ) && ( defined HAVE_SYS_IO_H ) && ( defined
> __GNUC__ ) && ( defined __i386__ || defined __x86_64__)
> #define SANE_INB 3
>
> static int
> @@ -305,6 +305,8 @@ sanei_insb (unsigned int port, unsigned
> static void
> sanei_insl (unsigned int port, unsigned char *addr, unsigned long count)
> {
> + int i;
> +
>for (i = 0; i < count * 4; i++)
> addr[i] = sanei_inb (port);
> }
Thanks,
will be shortly in CVS with other umax_pp fixes.
Regards,
Stef
[sane-devel] [genesy backend] some patches and a few questions
--qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's the OpenOffice spreadshhet I use to find correct values. Slope0 is the slope table found in log, and Slope1 the computed one. I usually tune strat speed then g. In the graph on the '2500' slide, you can see that both curves matches really well. Regards, Stef --qMm9M+Fa2AknHoGS Content-Type: application/vnd.sun.xml.calc Content-Disposition: attachment; filename="slopes.sxc" Content-Transfer-Encoding: base64 UEsDBBQAANShjzFFvBOUHBwIbWltZXR5cGVhcHBsaWNhdGlvbi92bmQu c3VuLnhtbC5jYWxjUEsDBBQACAAIANShjzELY29udGVudC54bWzc vWuzXcdxJfh9fgWH4+iQezY281WVVbLkjraldnvabTta6uiZmJgPEAFKmCYJBgDqMb9+Mvcl qcp9iUedk1tGFJ84WBfn5j21dlXmqnz87D/88asvP/n981evX7z8+uef4g6ffvL8689fPnvx 9W9//ul///V/etI+/Q9/+7/87H/9xb/8/a//r3/95Scvv/jixefPf/rs5efffvX86zdPPn/5 9Rv7/yf/+t//7p/+8e8/+fTJZ5/9yzfPv/6X48v2l69++9lnv/j1Lz55eP2L7/7UJ/Z9Pvvs l//86SefPrzf/uzNs0//9mdve3Oz8evXP31Af/7p7968+eann3320r7Nyz9/GwKAzx5ef/rd H3j95k9fvvvrj6/4/svfPP/jm3d+tX/BD1/89Dfvee/jK77/8mevnv7hnV/tX2Cf+fdf/8XL H776D3/4w/4HPr4Se++f/Z+/+qfP/tPLV189/cGWP3754uv/+davP9Dvv/Trb7/6zfNX77bk 6Zun4XN5/fvf/tibP3yAv//B5M9/9/TVuz+/4yv+/Inws/d8Ivzs+y+2H/Z3b/kB22f/1cDj P//1n/788b366p1v7l/ww8/3+asX37zb8ocv+fR79n/+5dPXr3/+6etvXj1/+uz1754//zMU HqUfGP3w5z/74fUXRuwnz55//uXrv/3Z8Vn/+Xc+eXj99dOvjF7/9O3nL549/eRXT79+/cl/ //qFPZe2Kl+8fPjqL55+9eLLP/3803/39JuXr//mR770Afj0k+E7fPPizef2Sf7+6asXBz0/ e/f3//XT37386unjb/n979/+zv/RvuzLx2/83W8Pf/IBefLb518/f/Xic/vQ//Di9ev3fefP fuRz/u63nn77xkx/8+LzJ8db/LAAx3+DiZ+/xB++z3fmHc+0bUtffvvV159+/ye/eWWUefXm xfPX/uP8xjjxP5/85rkxzN7Dv9v3b/Lwx5784cUzJzPtVPXzrw5rBwvebs6rt5nz6uUffsyW h98w8Mnvnr/47e+M4LAL+bd8t5nfvn7+5OU3b1589fTLJ+OffvPq2+cfbu2bpz9u7fe/+ZXt Mc9fPfnm6W+fP3n4E794/sXTb79882M/yvEnf/rsxetvvnz6p1lLPn/+tmV8/uUPVPvm6Ss/ cI4X77fHPj8/C548/fLFb7/272DH1Kvv3+rPyJPXL7995SfWFy/+eHzoXz199dsXXz/58vkX vhrfrcTB0T989yH/5uWXz2Z+NLrrR/vuK3zHD/g/I7Q/P8A/9n35qu/bx8f38bP6HfCbl8/+ 9Lc/e6DF8d/vKPLwNr5lf/rd74xv75wMf+q7J/lHvvR49r97z+PI/O5LXz959fyb50/fPLez i77/imcPP9bx0//oz/vZ/Hd963v6mt/wfm//KQrf+nPY7vAj39T3qZN99n4/Zt3z4wvtcfnp N3/7qy/t6YKfffbdy599dn6DG98SU9/y718+/+KLjHc8r+AHfO9ff/VN7sfz61/+669S3/Ef Ut/tl3807+XbV89T3/Tvnr7OfcNfvTGfNvUdf/HNi4z3e+9zL+XYak8P9N1P+O+ffvnt8ydv /vSNn3tfvvQoZQC+25x/+GH91S0/rfvv33759Oef/vz/3v/ql39F/8+//4n94v+wX/zvP8En 3/3yr/+9/eLv7f+ffqBtHi/t9m9vmRb+67/8j1/+t5/85L/9y//4yXf2PKG//sx//Z/MyCf4 139jv/yHv5qwc/gAYYPjrykTP3T3+eFk+PMP84///OufuOn/2T9z+/9/cbs/s1/848wPwCMH 7MU2/zO82+D3srCUYYlL+YsbALsRq4zr6K//khZwDYtQ/y1WQcJeIP8GJtS9Pvz1Zzvq5q/1 L/k5nLbE2z+Fj267R+H+55/NX1283fPEdm/W7K1hbVorjDuCI1trqfs+J+z7O1OXhlyIEYnG 7eMByeWMhQb/JpzhMjyO/upizsgEZ8yanav5CCQNkKKdG9+0bbyVM5LCGW3G7qZdqv83kMah mz7dj5A0gONiwE3PwgRpygxpAPdWegf7tAU02rm1O/l9Ik3JII0gVIXKtZQmrCNpDmiRnYbq cPL6q4tJUydIY9bsArbVMJLUFu20VUglTU0hDRcoosDUwB2OkTQOlUVIQ+PxZK8uJo3OkIbq XsybQSxYT2ZuJfd00hTOFOkVsRpnuPXImQNagzPYx13fXl3MmTbBGbNm19qrYGMViXZumkua lkIaxQ5AILbZdGyBNAe0CGl09C/t1cWk6TOkUdrNndTOYtuNRju3cmeYdyJNTyFNM7eFwXZH 22riRnMgi3CmjB4N3iYpTXAGYYY0BXbkSsKMNQR5hmwoqaRxyxJYY6Ee9lagN3PE4lbjUeAq Ww0H2vDltMEZ2lDfG6lQb3ZGjWGeIVu76cl9O20wgzYFsdlGYydoV64jax6QRViDYTHw6pgb Zy5z7K+dzINsrXbBEg3d6KZg5O2sybjW2QuRdqN5wcK9Bn3vAVqDNtBHJxNu+7FmaDMjCps5 OwLVYxXGDd+RLTfqxhRRuFjs1KABVCWIqvABLRJCgYbF0Dvl+fezZkYWNnN2LN3WAS0CiXZu mCvwYYosXISoNPurSukcSOPITQ78R0iayuNi1Dt9hfeTZkYWNnPshKpM0Mie02ho+gmVoguX gsBYFBSklOAOH9BNIepHSBsZby3t1dW0mRGGzZyd6BBUbbdp0dCN7lQJzrRJUYZL6a4Jt1J7 LaPE5LRxaBHajK6+v7qaNjPSMHDZu/ZeOtgvNRhatp57240p4nCpvtFUUCpaSgyjHFrFs6Fw SNHlh9SMOmzm7EJSbCHU3Mlo6CbJu02KPFxUpFSsyuYOc7jxfoAWoU2IvuH66HtGHzZzdmlY KksthaOhmyTvNikCcWl2mqJQY8ZGGGhzQIvQZsw2w79AAu6MQmzm7NBUsXcminZukHurQCkC scVQ2Li6OkyVYyDl0BqaTW/DNmovrubMhDxs1uzYOpEWcxUkmLlhMmVyxOEu/k9Vc4g13nkf 0Bp5En3MNbMXV1NmYgm6tl0F7CjqXavU0c62ae49FKVIwxVAxZVrVWnhbHpA1qBMHSlTL6fM hC7cq1HGJdbSWeuYa2jIlpsjQSmycIVq1K6lllakR8YYcpPJHx9jysiYe9MO3s+YCU3YrNmB 7YO22JWEg5kbJO8xKZJwRTLXVxpQ97A7UOaAFqEMjGtxufs7oQh36buiMvfGGhRhQ7Z783/O nEkRhCtqQ2YqFtZhlcgZh9bgjIwb/r25t+/nzIQc3AWMM9Vooyx9zBgzJJ0zKWpwJfZ7MWi1 ciyCO5CbtIGPjzKjVtZvuxiZocyEFGzW7P64grKFruMNgiHbvZUTZ8qkKMGV/IpMSwVS7BQ5 Y9Aa15WdxvCVrs6LoAkduBPvHqz2JhTEMQO2kivnUYoKXF3Ga2I7Y1du4aryAVqDMjhGr/dm GryfMhMacMeyC9ih1EtxVWO0s2zJDnCKAlxZe1cL8FB7pegAO7QIZWDc8W87bmcqcif0X4s7 ds8np94tRKUxtgPdbotZ316Rm6L/mpm1KnhNKIUaROPMAS3CmTFouvzOgCf039YtaCoElTui jtuhIZvmZtFwigBcRQmM54Jc68mbcWgNAbiNP5m9uJozE0tg1uwkaudlBa3Qg53ZmVecIwAX rOa01CatYMy8OqA1PODWBjfBXlzNmQkF2HzJ3UJ/rAL23PaRM022e5OYz5zJkYBLMYr30qhB uIR3zhi0xtnUxsTgdnleME9owE11b7bVd2C2sIlHO3VrueIM54jAFdDI0tydCfUdxhmH1kie aWOSdrstkWyGMxMicFPYm5ZS1DyB6M8opHelyRGBzZOxQELsr9Za3GccWuPioI3ytr24mjMT IrBZs0OvrReyqAk12JlctMI5GnBtqI26hUyEopEyDq1BmdFRa/fKZO+nzIQI3IqF2lr8ss9d gdFVL5qdoMc5IrBviAyFiar2eNd0QItwZjyayuVH04QIbNbsAEK1o9Q25pDfbeeZMDkSsHrH q+ZtrgpK9GUMWqTsoI2tduzF1YSZkIDNJbBFkNab1Krh/BTZbtPG3s6ZHA1Y+6E/KjIVigeT Q4tsMmNafLu8K6NMaMCN2y7NvMlO3faacZPhln0wSY4G3Jg8zb3YLiMYDyaHFomzx+xme3E1 Z2Y0YKZd0CKmZmFIG/s3G5JdpCI5GnCrXmwgAlhPYfaBrEGZ8PjS1V2vZEYCpmr+L
[sane-devel] genesys backend status update
Hello, here's the status of the genesy backend after last commit: - MD6471 is fully supported in color, gray and linart modes, at 50, 100, 150, 200, 250, 300, 400, 500, 600, 800 and 1200 dpi - code have been split up so that the genesys_low.c file is now unused, and replaced by genesys_gl646.c and genesys_gl841.c files. These hold functions specific to their related ASIC. - common code to both AISCs have been moved to genesys.c. "higher" level functions calls code from genesys_gl646.c or genesys_gl841.c based on the asic_type field which is initialized in genesys_devices.c Bugs left: - scanner init fails if the previous scan got certain amount of data. ie it doesn't fail allways. I'm trying to track it down, but that's not easy. Unplugging/replugging the scanner solves it. Once xsane has done a scan, the whole following session is OK. Todo: - for the MD6471, at dpi higher than 600, pixels are staggered. It is how the scanner sends them. So after doing 'line distance' calibration, this effect has then to be corrected (by shifting columns). Features to add: - true hardware lineart will be added when we find a scanner doing it. - add 16 bit scanning, which involves cancelling gamma calibration in this case. Some tests I did show that images aren't of good quality without hardware gamma correction. I'd like the current backend been reviewed so that we know what would be done to make it leave the experimental staging, and include it in the regular CVS. I think it is almost ready, and is only lacking a man page. Currently the gl841 file is a copy of the gl646, and needs quite some work before having GL841 based scanners work. In the process, we may have to add or move functions between genesys.c and low level files. My plan is that genesys.c will keep all common functions, functions that differs only by a few lines and so test the asic_field. Registers will have to be read or set by using the genesys_read_reg_from_set() and genesys_set_reg_from_set(). The speficic files will contain all functions that heavily use registers, or register of different meaning. Registers can be accessed directly by using the anonymous enum defined at the top of these files (841 one needs updating...). Some of the existing functions that are in the low level files could be split into a part that deals with registers, and another part of higher level which could be moved to genesys.c . However, I think it's a bit early to do it and that we'll handle such cases when enough gl841 code will have been written. Regards, Stef
[sane-devel] Re: GL841 genesys.h
On Fri, May 06, 2005 at 01:06:59PM +0200, Philipp Schmid wrote:
> Hi Stef,
>
> as the regs of the gl841 are different I propose to define two macros in
> genesys.h to the bits if it is necessary. One for the gl841 and one for
> the gl646 context of this bits. e.g.
>
> #define REG01_COMPENB0x08//gl646
> #define REG01_M16DRAM0x08//gl841
>
> Bye,
>Philipp
>
>
Hello,
what I recommend is to move *ALL* registers defines out of
genesys_low.h to
their corresponding low level files since they are different. Only use them in
genesys_gl841.c or genesys_gl646.c . If a functions in genesys.c need some
of them, we should use a helper function that calls one specialized function.
For instance I'll turn code like:
if (genesys_read_reg_from_set (reg, 0x04) & REG04_FILTER)
into:
reg04 = genesys_read_reg_from_set (reg, 0x04);
if (genesys_filter_bit(dev, reg04))
with
int genesys_filter_bit(Genesys_Device *dev, SANE_Byte)
{
switch(dev->model->asic_type)
{
case GENESYS_GL646:
return gl646_filter_bit(dev,reg);
case GENESYS_GL841:
return gl841_filter_bit(dev,reg);
}
}
right define would be used in gl646_filter_bit/gl841_filter_bit .
Or be even better (register address could be different):
into:
if (genesys_filter_bit (dev, reg, 0x04))
with:
SANE_Byte genesys_filter_bit(Genesys_Device *dev,
Genesys_Register_Set *reg,
SANE_Byte addr)
{
switch(dev->model->asic_type)
{
case GENESYS_GL646:
return gl646_filter_bit(dev,reg);
case GENESYS_GL841:
return gl841_filter_bit(dev,reg);
}
}
glXXX_filter_bit will do the register search and test bit in a specific
way.
There are quite a few functions like that to add.
Regards,
Stef
[sane-devel] Re: GL841 genesys.h
Hello, I've done the modifications I suggested. Defines are now part of genesys_glXXX files. And a couple of functions close to hardware moved away from genesys.c . Needed register bits are used through helper functions. I'm sorry but I think you'll have to merge your changes to genesys_gl841.c by hand first before check-in your changes. Regards, Stef
[sane-devel] Backend for HP2400
On Sun, May 08, 2005 at 12:57:38PM +0100, Everard Brown wrote: > Hi all, > > I am given to understand that this scanner should work vis the genesys > backend. > > Can I get an update of the status of the backend for this scanner and where I > could most usfully help out? > > I am a software engineer with lots of C/C++ experience. > > All comments welcome ;-) > > Everard > > -- > sane-devel mailing list: sane-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-requ...@lists.alioth.debian.org > Hello, the 2400C will be supported by the genesys backend since it is a gl646 based scanner. However, there is only some inital code for it. I'm going to borrow a 2300C the next 2 weeks to finished support for it. Since the 2400C differs by its max resolution (1200 instead of 600dpi), it wouldn't be that hard to add it. One first step is to have your 2400C running under windows and get usbsnoopy work to log scans. Logs to have are: - launch (to see how detection/initialization work) - preview - small color scan at each available dpi - small gray scan at each available dpi - smal lineart scan at each available dpi This is quite an hundreds MB of logs to go through, which may be done via a slew of awk scripts to decode that in a usable way. Regards, Stef
[sane-devel] Re: GL841 genesys.h
On Tue, May 10, 2005 at 02:18:22PM -0600, Luke Q Campagnola wrote: > I started doing some work with the GL841 a while back and got as far as > updating all of the register #defines and grabbing some usb dumps from > windows. Now that there's a little more activity going on with this chip, > I'd like to help out again. Is there anything I can do that won't > interfere with the work already being done? > > Thanks, > Luke > > > -- > sane-devel mailing list: sane-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-requ...@lists.alioth.debian.org > Hello, Philipp Schmid , has started working on it. I think you should discuss how you can organize this work. Meanwhile, you can send patches on the list. Regards, Stef
[sane-devel] genesys backend status update
Hello, I've started to address the points you raised (and I sohouldn't have forgotten ...). I'll signal when I'll feel the backend is up to the requirements. Regards, Stef
[sane-devel] genesys backend status update
Hello, I don't think we can have gl641 and gl841 in the same file. First some registers of same index have different bits. Second the enum we use to access registers are different. This overlap make it much harder to have both in one file than to have 2 cleanly separated objects. For instance since register sets are packed differently (not the same amount of registers used), you wouldn't be able to access them simply. You'll have to use the helper function, instead of directly using indexes. Also you'll have defines of the same name which would have to be of different values, and some values would need 2 different defines. genesys_low.c is no more needed. There are currently a lot of redefinition, but it is because the work on gl841 is at the beginning. Thing will really differ in the future. Furthermor, I expect we will have problem with the Genesys_Gpo struct because gl841 has more GPIOs, and I'm afraid that registers and bits to set the frontend are different, and we then have troubles with Genesys_Sensor. For the function pointer method, it seems clean. But we have to be sure to the parameters will be allways the same (still thinking of Genesys_Gpo and Genesys_Sensor). Which seems likely with the current state of the backend. It would also decrease limit the number of exported functions. In fact we would only need a gl646_init_funcs() and a gl841_init_funcs(). sanei_genesys_* would still be needed but not sanei_glXXX_* . I've look a little at genesys-new, and I don't feel the genesys_mid.c is really needed. If I understood, it holds functions "between" low and high level, do we really want these in an other file (which is included) ? I haven't the feeling that genesys.C has grown too big. Maybe I am missing something ? Currently, I'd be rather inclined to only add the function pointers to the gensys backend and keep separated objects for low level. Regards, Stef
[sane-devel] genesys backend status update
On Sat, May 14, 2005 at 11:35:43AM +0200, Gerhard Jaeger wrote: > Hi, > > sorry for the late response. > Hello, seems I'm not also that fast on mail. I was busy getting 2300c to work ... > On Wednesday 11 May 2005 19:00, stef wrote: > > Hello, > > > > I don't think we can have gl641 and gl841 in the same file. First some > > registers of same index have different bits. Second the enum we use to > > access registers are different. This overlap make it much harder to have > > both in one file than to have 2 cleanly separated objects. For instance > > since register sets are packed differently (not the same amount of > > registers used), you wouldn't be able to access them simply. You'll have to > > use the helper function, instead of directly using indexes. Also you'll > > have defines of the same name which would have to be of different values, > > and some values would need 2 different defines. > > Probably you're right here, but when having "locally" exported functions, > don't name it sanei_..., > > > genesys_low.c is no more needed. There are currently a lot of > > redefinition, but it is because the work on gl841 is at the beginning. > > Thing will really differ in the future. Furthermor, I expect we will have > > problem with the Genesys_Gpo struct because gl841 has more GPIOs, and I'm > > afraid that registers and bits to set the frontend are different, and we > > then have troubles with Genesys_Sensor. > > These issues, I think have been solved in genesys_new. Anyway as I told > you I don't insist on continuing with genesys_new, I simply did this > work to demonstrate how it could be done with the function pointers > (which - as far as I can see - you have now implemented...) > > > For the function pointer method, it seems clean. But we have to be sure > > to the parameters will be allways the same (still thinking of Genesys_Gpo > > and Genesys_Sensor). Which seems likely with the current state of the > > backend. > > Guess this is not really a problem. > > > It would also decrease limit the number of exported functions. In > > fact we would only need a gl646_init_funcs() and a gl841_init_funcs(). > > sanei_genesys_* would still be needed but not sanei_glXXX_* . > > > > I've look a little at genesys-new, and I don't feel the genesys_mid.c is > > really needed. If I understood, it holds functions "between" low and high > > level, do we really want these in an other file (which is included) ? I > > haven't the feeling that genesys.C has grown too big. Maybe I am missing > > something ? > > Hmmm, I do really think, that having more than 4000 lines of code is pretty > too much for one file. One other thing are the gamma settings for the I'm not personnaly keen on splitting files and then including them. However, personal taste is not a sensible argument. Including source files would involve adding an option to makedepend in the makefile (we want 'makedepend -o.lo *.c') so that dependencies are correctly handled. That raise one question, is there a build environnment where sane objects are built with .o suffixes ? I couldn't find out it from the makefiles or config files. > various models, couldn't these values be generated by a function? > I did some tests and something like: > > for( i = 0, c = 0; i > val = ( gamma_max * pow((double)i / (double)( gamma_len-1.0), > 1.0 / gamma )); > > if( val > gamma_max ) > val = gamma_max; > > for( j=0; j<4; j++ ) > gamma_table[c++] = val; > } > > generates the table: gamma = 2.2, gamma_len = 4096, gamma_max = 16380; > > > Currently, I'd be rather inclined to only add the function pointers to > > the > > gensys backend and keep separated objects for low level. > Gamma tables are currently a nobrainer cut'n past from usb logs. I've started to see if they can be replace by an init functions. However, the MD6471 case seems a little more complicated than a pow() formula. > Okay... > > > > > Regards, > > Stef > > Anyway, keep up the good work, I currently check the ST12 and ST24 stuff. > > Ciao, > Gerhard After latest check-ins, the HP 2300c is now well supported, and isn't experimental anymore, like MD5345/MD6228/MD6471. What I am looking into now, is to see if we can get rid of the 'static' gamma tables, adding true lineart scanning and 16 bits scanning. I feel like addng a 16bit option and a 'channel filter' select option. Regards, Stef
[sane-devel] The Genesys backend and the HP 2300C
On Sat, May 21, 2005 at 02:13:09PM -0500, Jason Anderson wrote: > In the previous messages, someone said that the HP 2300C is now well > supported. However, I've taken the Genesys backend, the latest CVS version > for Sane, and compiled them together, and found that I couldn't even make my > HP 2300C scanner move. I'm not a very picky person, but am I missing > something here? > > Best regards. > Hello, how did you build the experimental backend ? Did you edit the Makefile of CVS sane backends to add it ? Do you have a libsane-genesys.so.1.0.14 file in sane-backends/backend/.libs directory ? If you think everything is compiled and installed as it should do in an terminal (frst as root to avoid permission problems). export SANE_DEBUG_GENESYS=255 export SANE_DEBUG_GENESYS_GL646=255 scanimage -L When the backend is installed, but have no scanner attached you get: [sanei_debug] Setting debug level of genesys to 255. [genesys] SANE Genesys backend version 1.0 build 3 from sane-backends 1.0.14-cvs [genesys] sane_init: authorize != null [genesys] sane_init: little endian machine [genesys] sane_init: reading config file `genesys.conf' [genesys] sane_init: config file line 1: ignoring comment line [genesys] sane_init: config file line 2: ignoring empty line [genesys] sane_init: config file line 3: ignoring comment line [genesys] sane_init: config file line 4: trying to attach `usb 0x0638 0x0a10' [genesys] sane_init: config file line 5: ignoring empty line [genesys] sane_init: config file line 6: ignoring comment line [genesys] sane_init: config file line 7: trying to attach `usb 0x04a9 0x2213' [genesys] sane_init: config file line 8: ignoring empty line [genesys] sane_init: config file line 9: ignoring comment line [genesys] sane_init: config file line 10: trying to attach `usb 0x03f0 0x0901' [genesys] sane_init: config file line 11: ignoring empty line [genesys] sane_init: config file line 12: ignoring comment line [genesys] sane_init: config file line 13: trying to attach `usb 0x03f0 0x0a01' [genesys] sane_init: config file line 14: ignoring empty line [genesys] sane_init: config file line 15: ignoring comment line [genesys] sane_init: config file line 16: trying to attach `usb 0x03f0 0x1405' [genesys] sane_init: config file line 17: ignoring empty line [genesys] sane_init: config file line 18: ignoring comment line [genesys] sane_init: config file line 19: trying to attach `usb 0x07b3 0x0601' [genesys] sane_init: config file line 20: ignoring empty line [genesys] sane_init: config file line 21: ignoring comment line [genesys] sane_init: config file line 22: trying to attach `usb 0x0461 0x0377' [genesys] sane_init: exit [genesys] sane_get_devices: start: local_only = false [genesys] sane_get_devices: exit 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). [genesys] sane_exit: start [genesys] sane_exit: exit Regards, Stef
[sane-devel] libusb - problems with open/close of device in backend?
On Mon, May 23, 2005 at 02:52:27PM -0400, m. allan noah wrote: > steven, i see this exact problem with certain fujitsu scanners. the > difficulty is that USB uses a 0/1 toggling bit during the data transmit > phase. when libusb closes the device, the device should reset the toggle > back to 0, the kernel does. subsequent transmissions should start with > toggle set to 0, but if device thinks it should be 1, then device ignores > packets. windows never closes the device (the driver loads at bootup) so > the fujitsu engineers had no idea what i was talking about (though i note > that later usb2.0 fujitsu scanners do not have this problem) > > you have three options that i see: > > 1. count the number of data packets you > are sending to scanner, and always send an even number. remember that just > cause you sent or read 16 k of data, does not matter, it was busted up by > lower layers. you need this larger number of smaller packets. > > 2. get kernel/libusb to keep current toggle instead of trashing it. > > 3. call usb_reset(device) as the very last step before you exit. this will > cause the device to re-enumerate, and reset all of its internal data. > while ugly, this works for me everytime. there are other functions like > usb_clearhalt and usb_resetep, but those dont seem to fix my problem. > > my advice? write a little prog that uses libusb directly, and try to do > simple things outside the confines of sane. > > allan > Hello, this is really interesting. I had an intermittent hangup with the genesys backend, depending of tha amount of scan data. I just couldn't figured out why. Now, with your explanation, it does make sense. Dependending on the number of bulk reads, the toggle wasn't set like it should. So I did like you suggest: call usb_reset(device) before closing the device in sane_close(). That got rid of the hang (at least on HP2300C, need to double check for MD6471). Now my question is : would it be OK to do it in a backend ? Is there any drawback ? Regards, Stef
[sane-devel] libusb - problems with open/close of device in backend?
On Tue, May 24, 2005 at 01:18:59PM +0200, stef wrote: > On Mon, May 23, 2005 at 02:52:27PM -0400, m. allan noah wrote: > > steven, i see this exact problem with certain fujitsu scanners. the > > difficulty is that USB uses a 0/1 toggling bit during the data transmit > > phase. when libusb closes the device, the device should reset the toggle > > back to 0, the kernel does. subsequent transmissions should start with > > toggle set to 0, but if device thinks it should be 1, then device ignores > > packets. windows never closes the device (the driver loads at bootup) so > > the fujitsu engineers had no idea what i was talking about (though i note > > that later usb2.0 fujitsu scanners do not have this problem) > > > > you have three options that i see: > > > > 1. count the number of data packets you > > are sending to scanner, and always send an even number. remember that just > > cause you sent or read 16 k of data, does not matter, it was busted up by > > lower layers. you need this larger number of smaller packets. > > > > 2. get kernel/libusb to keep current toggle instead of trashing it. > > > > 3. call usb_reset(device) as the very last step before you exit. this will > > cause the device to re-enumerate, and reset all of its internal data. > > while ugly, this works for me everytime. there are other functions like > > usb_clearhalt and usb_resetep, but those dont seem to fix my problem. > > > > my advice? write a little prog that uses libusb directly, and try to do > > simple things outside the confines of sane. > > > > allan > > > > Hello, > > this is really interesting. I had an intermittent hangup with the > genesys backend, depending of tha amount of scan data. I just couldn't > figured out why. Now, with your explanation, it does make sense. > Dependending on the number of bulk reads, the toggle wasn't set like it > should. So I did like you suggest: call usb_reset(device) before closing the > device in sane_close(). That got rid of the hang (at least on HP2300C, need > to double check for MD6471). > Now my question is : would it be OK to do it in a backend ? Is there > any drawback ? > > Regards, > Stef > > -- OK, after some tests I can confirm that genesys hangs are related to the 'toggle' and that usb_reset() fix this. But unfortunately, resetting affects all devices plugged in the usb ports: if I plug 2 scanners on the same pair of USB ports, launch 2 xsane, then leave on -> bus is reset, and the left xsane can't work since it's device has also been reset. Well, I guess it's time to count data packets Regards, Stef
[sane-devel] experimental hp scanjet 2400 genesys backend support?
On Sun, May 29, 2005 at 01:06:25PM +0300, Ivan Kalvachev wrote: > I would like to know if scanjet 2400 (using GL_646_HP) is supposed to > work with experimental genesys or genesys-new. > > I had compiled them both (using sane-cvs) but none of them seems to > work. I wonder is there sense of sending detailed bugreport if they > are not supposed to work at all (genesys-new succeed of moving the > motor). > > Wish You Best >Ivan Kalvachev > iive > > p.s. > The scanner is second hand and expreamly cheap. I have very limited > time to accept or decline the offer. > > -- > sane-devel mailing list: sane-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-requ...@lists.alioth.debian.org > > Hello, the HP2400C is not yet supported. It may be within a time frame of one or two months. Regards, Stef
[sane-devel] usb-IO-error with genesys
On Mon, Apr 18, 2005 at 10:08:55PM +0200, Philipp Schmid wrote: > Hi Stef, > > Thank you for answering my question. I cannot imagine that endpoint 0x82 > isn't a bulk write endpoint on GL841. There is a successful bulk write > in my trace using endpoint 0x82. It is after genesys_create_slope_table: > > [genesys] genesys_bulk_write_register (size = 162) > [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 130, > index = 0, len = 8 > [sanei_usb] : 01 11 00 00 A2 00 00 00 > > [sanei_usb] sanei_usb_write_bulk: trying to write 162 bytes > [sanei_usb] : 01 20 02 30 03 1F 04 13 05 40 06 18 07 00 08 01 . > .0.@.. > [sanei_usb] 0010: 09 03 0A 05 0B 07 10 00 11 00 12 00 13 00 14 00 > > [sanei_usb] 0020: 15 00 16 33 17 05 18 31 19 2A 1A 00 1B 00 1C 00 > ...3...1.*.. > [sanei_usb] 0030: 1D 02 1E F0 1F 01 20 10 21 08 22 10 23 10 24 08 .. > .!.".#.$. > [sanei_usb] 0040: 25 00 26 00 27 D4 28 01 29 FF 2C 02 2D 58 2E 6E > %.&.'.(.).,.-X.n > [sanei_usb] 0050: 2F 6E 30 00 31 40 32 2A 33 F8 34 40 35 01 36 00 > /n0.1@2*3.4@5.6. > [sanei_usb] 0060: 37 00 38 2A 39 F8 3D 00 3E 00 3F 01 52 13 53 17 > 7.8*9.=.>.?.R.S. > [sanei_usb] 0070: 54 03 55 07 56 0B 57 0F 58 23 59 00 5A C1 5B 00 > T.U.V.W.X#Y.Z.[. > [sanei_usb] 0080: 5C 00 5D 00 5E 00 60 00 61 00 62 00 63 00 64 00 > \.].^.`.a.b.c.d. > [sanei_usb] 0090: 65 00 66 11 67 00 68 51 69 20 6A 40 6B FF 6C 00 > e.f.g.hQi j@k.l. > [sanei_usb] 00A0: 6D 01 > m... > [sanei_usb] sanei_usb_write_bulk: wanted 162 bytes, wrote 162 bytes > > I've another question about genesys_low.h. Are the /* USB control > message values */ the endpoints in the USB device or is this something > different? > > Thanks for helping > >Philipp > Hello, you are right, this a succeeding bulk write on endpoint 0x82. After checking, it is used for reading/writing one register at a time (from the log posted on the list). However, bulk writes are made on 0x8e in the log. But in the current case, could occurs because of inconsistent registers content. I sometime hit such problems when sending bogus values with my gl646 based scanner. It is unlikely that current backend sends values that fit for a gl841. It haven't fully read the datasheet, but I spotted some registers that a few different bits from gl646. Regards, Stef
[sane-devel] Unable to run scanimage
On Wed, Jun 01, 2005 at 08:21:59PM +0200, Stefan Urbanek wrote: > Hi, > > I have a problem running scanimage. When I try it: > > scanimage -d genesys > > I get: > > scanimage: open of device libgenesys failed: Invalid argument > > I have fresh CVS installation with make clean and removal of all > previously installed files. The libgenesys is present where it should > be, that is in the lib/sane. > > What should be wrong and how I can fix it? > > Thanks for any hints, > > Stefan > Hello, if you have no other scanner atached than a 'genesys' one, do 'scanimage' without any argument. However, if you want to specify the device, from memory it should be 'libusb:002:004', where numbers vary. You can find it by executing 'scanimage -L'. Regards, Stef
[sane-devel] Parallel port ASIC problem?
On Mon, Oct 06, 2003 at 01:32:54PM -0300, John Coppens wrote: > Hello people. > > This is not strictly a scanner problem, but I believe scanner hardware is > relatively similar to the webcams - at least the bus interface. > > I'm playing with a parallel port webcam (weeCam), and hope to get it > working for an experiment with a microprocessor (at the university). > > Once in a while, the communication completely hangs - even libieee1284 > cannot seem to get out of it. Only solution is to abort the program, > remove ppdev and lp, and power cycle the camera. > > I suspect the ASIC in the camera get into a weird state and some special > code sequence is necessary to get it out of it. > > Has anyone had a similar experience? I'm guessing that such states can > appear with most ASICs, and (guessing again) that it might take a special > combination of the control lines to get it out of that state. > > Thanks in advance, > > John > Hello, such reset sequence vary a lot from ASIC to ASIC. For instance, the UMAX 1220P scanner uses an EPAT C7 based ASIC, however, none of the reset sequences found in parport-scsi for EPAT worked. But who knows ? Maybe it could work. Regards, SteF range
[sane-devel] umax_pp works well with "port 0x378" bot not with "/dev/parport0"
On Mon, Oct 13, 2003 at 03:46:11PM +0200, Sven Hergenhahn wrote: > Hi List, > > when trying to setup SANE for my Unax Astra 2000p, I experience the following > strange behaviour: > > when setting > > port 0x378 > > in umax_pp.conf, the scanner is properly detected and works fine (at least as > root), but setting it to > > port /dev/parport0 (as suggested for Linux) > > results in the following error: > > gimli:~# scanimage -L > [umax_pp_low] Found 0x18 expected 0x00 (umax_pp_low.c:5267) > [umax_pp_low] Unexpected value for for register 0x0D, expected 0x00 or 0x40, > got 0x18 ! (umax_pp_low.c:5338) > [umax_pp_low] RegisterRead, found 0xFF expected 0x00 (umax_pp_low.c:5429) > [umax_pp_low] *** It appears that EPP data transfer doesn't work*** > [umax_pp_low] *** Please read SETTING EPP section in sane-umax_pp.5 *** > ... > > BIOS is set to EPP, all umax_pp tests work fine, only detecting doesn't work. > > Permissions to /dev/parport0: > > gimli:~# ls -la /dev/parport0 > crw-rw-rw-1 root lp99, 0 Oct 13 12:18 /dev/parport0 > > Any ideas? > > Thanks, > Sven > Hello, which kind of hardware is it ? Also what does 'dmesg|grep parport' reports ? It seems there is -to my opinion- some issue with ppdev on recent hardware. Also, it maybe worth to rebuild your kernel accordingly to : http://umax1220p.sourceforge.net/trouble.html Regards, Stef
[sane-devel] Re: umax_pp works well with "port 0x378" bot not with "/dev/parport0"
Hello, from the dmesg messages, I see that no IRQ is assigned to your parallel port. It might be worth passing parameter to the parallel port module in /etc/modules.conf to have it used: options parport_pc io=0x378 irq=7 dma=none Also, running the umax_pp tool with a trace level of 32 (-t 32) will give some hints on what modes are detected. Regards, Stef
[sane-devel] Re: umax_pp works well with "port 0x378" bot not with "/dev/parport0"
On Fri, Oct 17, 2003 at 04:52:05PM +0200, Sven Hergenhahn wrote: > Hi Stef, > > > It might be worth passing parameter to the parallel port module in > > /etc/modules.conf to have it used: > > options parport_pc io=0x378 irq=7 dma=none > > OK, done. It works now as root with port /dev/parport0, but still as normal > user, I get the following: > > sven@gimli:/dev$ /usr/src/sane-backends-1.0.12/tools/umax_pp -p -t 32 There's a small typo, you have to specify '-n /dev/parport0' to use ppdev. So the tool tries irect hardware access. > [sanei_debug] Setting debug level of umax_pp_low to 32. > [umax_pp_low] SANE_INB level 3 > [umax_pp_low] sanei_umax_pp_InitPort(0x378,(null)) > [umax_pp_low] sanei_ioperm() could not gain access to 0x378 > failed to gain direct acces to port 0x378! > > permissions are: > sven@gimli:/dev$ ls -l parp* > crw-rw-rw-1 root lp99, 0 2003-10-13 12:18 parport0 > crw-rw-rw-1 root lp99, 1 2003-10-13 12:18 parport1 > crw-rw-rw-1 root lp99, 2 2003-10-13 12:18 parport2 > > PPDIAG (as root) is still: > sven@gimli:/dev$ sudo /home/sven/bin/ppdiag > S01: parport built as module > > S02: parport0: > S02:modes:PCSPP,TRISTATE,EPP > S02:ADDR :0x378 > S02:IRQ :7 > S02:DMA :no DMA used > > S03: no parport parameters > > S10: couldn't find if ppdev is built in or a module > S10: It is likely that your kernel configuration has no ppdev support > S10: exiting ... > > > Did I miss anything? > > Thanks, > Sven > > > The rest looks fine. But I'm afraid that the successful test as 'root' was done with direct hardware access. Regards, Stef > > > > Also, running the umax_pp tool with a trace level of 32 (-t 32) will > > give > > some hints on what modes are detected. > > > > Regards, > > Stef > > > > ___ > > sane-devel mailing list > > sane-devel@lists.alioth.debian.org > > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > > > ___ > sane-devel mailing list > sane-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel
[sane-devel] Re: umax_pp works well with "port 0x378" bot not with "/dev/parport0"
Hello,
after reading the spec 686a datasheet, I've seen something that I think
worth trying. Could apply the following patch to
linux-2.4.21/drivers/parport/parport_pc.c, rebuild and install modules, then
reboot.
I'd like to know what the message 'Parallel port printer control=xx' reports.
You
should get it with 'dmesg | grep "Parallel"'.
The patch:
--- parport_pc.c-stock 2003-10-18 14:12:55.0 +
+++ parport_pc.c2003-10-18 14:14:40.0 +
@@ -2577,8 +2577,9 @@
/* 0xF0_5: EPP+ECP enable */
outb (0xF0, 0x3F0);
- printk (KERN_INFO "parport_pc: ing\n",
- have_eppecp = (inb (0x3F1) & (1 << 5));
+ tmp=inb (0x3F1);
+ printk (KERN_INFO "Parallel port printer control=%02X\n",tmp);
+ have_eppecp = (tmp & (1 << 5));
/*
* lock super i/o configuration, clear 0x85_1
Regards,
Stef
[sane-devel] Re: umax_pp works well with "port 0x378" bot not with "/dev/parport0"
On Wed, Oct 22, 2003 at 06:54:46PM +0200, Sven Hergenhahn wrote: > Hi Stef, > > sorry, some of the recent mails from this list didn't make it into my mailbox. > > > Could apply the following patch to > >linux-2.4.21/drivers/parport/parport_pc.c, rebuild and install modules, then > >reboot. > >I'd like to know what the message 'Parallel port printer control=xx' > >reports. > >You > >should get it with 'dmesg | grep "Parallel"'. > > Can you please give me a short introduction how to do this? > I have compiled my Kernel, but so far didn't apply any patches, sorry. > > Thanks, > Sven > Hello, well, I don't think I can explain better than the man page of the 'patch' command. But here's how to patch the parport_pc.c file. This file is in the drivers/parport subdirectory of the kernel sources. In a command shell, cd to this directory. There edit new file 'patch_file'. Cut and paste the folling lines in it: --- parport_pc.c-stock 2003-10-22 21:26:55.0 +0200 +++ parport_pc.c2003-10-22 21:28:35.0 +0200 @@ -2577,7 +2577,9 @@ /* 0xF0_5: EPP+ECP enable */ outb (0xF0, 0x3F0); - have_eppecp = (inb (0x3F1) & (1 << 5)); + tmp=inb (0x3F1); + printk (KERN_INFO "Parallel port printer control=%02X\n",tmp); + have_eppecp = (tmp & (1 << 5)); /* * lock super i/o configuration, clear 0x85_1 I know it exists a way to put patch in a file so they apply regardless their context (in a middle of mail for instance...), but don't know to achieve this. Now we have a 'patch_file'. Do 'patch
[sane-devel] HP 3200c
On Tue, Oct 28, 2003 at 03:02:41PM -0200, CARLOS EDUARDO DANTAS DE MENEZES wrote: > Julien, > > I read in some documentation that the correct seting of parport is EPP. I > tested it with others options but also my scanner wasn't recognized (none > error messages were appeared too). > How could I isolate the problem? > > Thanks, > > Menezes > Hello, have you tried the few things I replied to your mails ? http://lists.alioth.debian.org/pipermail/sane-devel/2003-October/009172.html http://lists.alioth.debian.org/pipermail/sane-devel/2003-October/009175.html Regards, Stef
[sane-devel] HP3200C doesn't work
On Sat, Nov 15, 2003 at 06:07:47PM +0100, Henning Meier-Geinitz wrote: > Hi, >=20 > On Thu, Nov 06, 2003 at 10:32:40AM -0200, CARLOS EDUARDO DANTAS DE MENE= ZES wrote: > > Could someone help me? My HP3200c scanner doesn't work. How can I deb= ug the problem? >=20 > If you haven't gotten a personal response until now, you could try to > write to the maintainer of the umax_pp backend directly: St=E9phane > VOLTZ . >=20 > Bye, > Henning >=20 > ___ > sane-devel mailing list > sane-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel I've allready answered a couple of time. It looks like his mail settings are such that he doesn't get it: http://lists.alioth.debian.org/pipermail/sane-devel/2003-October/009172.= html http://lists.alioth.debian.org/pipermail/sane-devel/2003-October/009175.= html I've also answered a personnal mail from him yesterday. It looks like it didn't get either. Infortunate. Regards, Stef
[sane-devel] Announcing Scanner-HOWTO at tldp.org
On Mon, Jun 02, 2003 at 10:18:39AM -0500, Howard Shane wrote: > I would like to announce the completion of the initial draft of the > Scanner-HOWTO for the linux documentation project, and invite > participants on the SANE-devel mailing list to comment on it. > > The goal of this document is to bridge point A (scanner) to point B > (scanner running successfully in linux) for the relative newbie as > efficiently as possible. As such it should not be too technical, it > should cover the most common hardware interface types, the required > steps to reach a working result, likely pitfalls and how to recover from > them, and places to go for help. It is not designed to be an exaustive > list of harware in/compatibilities. > > Any help you can suggest to clarify or otherwise improve the draft will > be greatly appreciated and may even result in you being mentioned in the > credits if you so desire. > > The document can be found at: > > http://ibiblio.org/gferg/ldp/Scanner-HOWTO.html > > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel Hello, I've parsed it a bit, and I must say that you're painting the picture darker than it really is for parallel port scanners. Parallel port scanners listed in SANE do work. No need to frighten people. I'm a bit skeptic about favouring ECP mode. It may be wise for printers, but I think it is useless for scanners, unless you use some patch that bring DMA reads. From a quick grep in SANE docs, EPP or ECP/EPP seems to be the recommended setting. By the way, an EPP scan is way faster than PS/2 or bidirectional mode. Also, I don't think unidirectional mode is suitable for scanning. Regards, Stef
[sane-devel] problem with UMAX 2000P printer
On Fri, Jun 13, 2003 at 02:59:38PM +0530, aneesh m raj wrote: > Hi , > Im using a UMAX 2000P parallel port printer and I have downloaded SANE and > the patch for UMAX, when I run the umax_pp tool I receive a message "No > scanner found Status 134 not expected" .Im using debian linux kernel 2.2.20. > Any help is appreciated. > Regards > Aneesh Hello, could you please send the output of 'umax_pp -p -t 255' ? Also, check that the linux kernel detects your parallel port correctly. Especially, check that EPP mode is detected. Regards, Stef
[sane-devel] problem with UMAX 2000P scanner
On Mon, Jun 16, 2003 at 10:59:05AM +0530, aneesh m raj wrote: > Hi, > I have tried scanimage -L but it also says "No scanner detected" . when I > use umax_pp -p -t 1 the scanner is detected. umax_pp is not commented in > dll.conf. > Regards > Aneesh > - Original Message - > From: "Henning Meier-Geinitz" > To: > Sent: Friday, June 13, 2003 6:25 PM > Subject: Re: [sane-devel] problem with UMAX 2000P scanner > Hello, maybe there are several instances of dll.conf on your system, and the one used by scanimage may have umax_pp commented out. Also, 'umax_pp -p -t 1' does direct hardware access, while the backend is configured by default to use ppdev character device. You can change this by editing umax_pp.conf and change the 'port' option to 'port 0x378', if 0x378 is really your parport address. Regards, Stef > > > Hi, > > > > On Fri, Jun 13, 2003 at 05:16:18PM +0530, aneesh m raj wrote: > > > Thank u it worked the mode was in ECP+EPP . Im using a program to > > > detect scanner devices but I cant retrieve the device by calling > > > sane_get_devices() function .The SANE_Device structure is NULL. > > > > Try "scanimage -L" to make sure it's not a bug in your program. > > First guess: "umax_pp" is commented out in dll.conf. > > > > Bye, > > Henning > > ___ > > Sane-devel mailing list > > sane-de...@www.mostang.com > > http://www.mostang.com/mailman/listinfo/sane-devel > > > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel
[sane-devel] HP ScanJet 2400c not supported?
Le mardi 13 avril 2010 15:27:01 Giovanni Toraldo, vous avez ?crit : > Hi, > > I have the HP ScanJet 2400c and it's not working with sane 1.0.20 > (from Debian Unstable). > Someone has any news for the current status of the backend support of > this flatbed scanner? > > Thanks. > > Hello, the HP2400 (and its G2410 twin) has experimental support for 50, 100, 300 and 600 dpi uncalibrated modes in latest source version. You are welcomed to test it by getting it at http://www.sane-project.org/source.html . You'll need to compile it. In case a scan mode doesn't work, I need an USB log of the same scan done under windows so that I can fix it. The USB snooping software can be found at http://www.pcausa.com/Utilities/UsbSnoop/ . Regards, Stef
[sane-devel] CanoScan LiDE 100 / Genesys gl843 driver status?
Le mardi 25 mai 2010 15:28:47 m. allan noah, vous avez ?crit : > The machine is actually GL847, a custom version of GL846/8, used only > by Canon. It is significantly different from the GL841/2/3, and no > public docs are available. > > However, you (and alot of others) are in luck, because stef is > currently writing drivers for this exact machine. Current > sane-backends git repo contains his work. I was able to get scans with > it a few days ago. Perhaps he will comment further. > > allan > Hello, I am working hard on it to have it finished support for LiDE 100 for mid- june. Shortly after I'll add support for LiDE 200 (Jack Mc Gill donated me such a model). You can checkout and compile latest git version and test against your scanner. Full width scans are working. What is left is data reordering, you'll see 2 pictures side by side, one for odd pixel, the other one for even ones. Regards, Stef
[sane-devel] HP Scanjet 2400c (partial) success, 100 and 300 dpi work both in grayscale and colour (some small changes needed)
Le vendredi 28 mai 2010 16:07:50 Piotr Mis, vous avez ?crit :
> Very sorry, sent to soon.
>
> Hello,
>
> I was delighted that there is some progress with Scanjet 2400c.
>
> I ran it through some tests, and fixed what I could. Results:
>
> git version of genesys backend works partially:
>
> grayscale:
> * 50 dpi: hangs
> * 100 dpi: works partially, motor step too big, need to switch off
> the scanner to prevent damage
> * 300 dpi: works nicely
> * 600 dpi: picture distorted
> colour:
> as grayscale, but colour channels seem to be switched and slightly
> offset vertically.
>
> I tried to fix it myself and managed to fix the colour channels and the
> motor step in 100dpi.
>
>
> My changes below, comments/advice very welcome:
>
> 1. The scanner (at least mine) is RBG not BGR, this fixes the vertical
> offset as well:
>
>
> diff --git a/backend/genesys_devices.c b/backend/genesys_devices.c
> index a8da85d..3459090 100644
> --- a/backend/genesys_devices.c
> +++ b/backend/genesys_devices.c
> @@ -1173,7 +1173,7 @@ Genesys_Model hp2400c_model = {
>
>0, 24, 48, /* RGB CCD Line-distance correction in
> pixel */
>
> - COLOR_ORDER_BGR, /* Order of the CCD/CIS colors */
> + COLOR_ORDER_RGB, /* Order of the CCD/CIS colors */
>
>SANE_FALSE, /* Is this a CIS scanner? */
>SANE_FALSE, /* Is this a sheetfed scanner? */
>
>
> 2. The motor definition for 100 dpi from FULL_STEP to HALF_STEP:
>
> diff --git a/backend/genesys_gl646.h b/backend/genesys_gl646.h
> index 5dc3725..695d55f 100644
> --- a/backend/genesys_gl646.h
> +++ b/backend/genesys_gl646.h
> @@ -555,11 +555,11 @@ static Motor_Master motor_master[] = {
>
>/* HP2400/G2410 motor settings base motor dpi = 600 */
>{MOTOR_HP2400, 50, SANE_TRUE , 50, HALF_STEP, SANE_FALSE,
> SANE_FALSE, 63,
> - {MOTOR_HP2400, 100, SANE_TRUE , 100, FULL_STEP, SANE_FALSE,
> SANE_TRUE, 63, 1
> + {MOTOR_HP2400, 100, SANE_TRUE , 100, HALF_STEP, SANE_FALSE,
> SANE_TRUE, 63, 1
>{MOTOR_HP2400, 300, SANE_TRUE , 300, HALF_STEP, SANE_FALSE,
> SANE_TRUE , 63, 3
>{MOTOR_HP2400, 600, SANE_TRUE , 600, FULL_STEP, SANE_FALSE,
> SANE_TRUE , 63,
>{MOTOR_HP2400, 50, SANE_FALSE, 50, HALF_STEP, SANE_FALSE,
> SANE_FALSE, 63,
> - {MOTOR_HP2400, 100, SANE_FALSE, 100, FULL_STEP, SANE_FALSE,
> SANE_TRUE, 63, 1
> + {MOTOR_HP2400, 100, SANE_FALSE, 100, HALF_STEP, SANE_FALSE,
> SANE_TRUE, 63, 1
>{MOTOR_HP2400, 300, SANE_FALSE, 300, HALF_STEP, SANE_FALSE,
> SANE_TRUE , 63, 3
>{MOTOR_HP2400, 600, SANE_FALSE, 600, FULL_STEP, SANE_FALSE,
> SANE_TRUE , 63,
>
> What I'm still really missing is the preview in xsane, has probably
> something to do with not working 50dpi mode.
>
> Regards,
>
> Piotr
>
Hello,
so with these changes 100 dpi is working ? If you wish I can send you
my
log decoding scripts. By recording scanner activity under windows with
usbsnoop, then processing it through them, you'll have the values to put in
HP2400 motor and sensor tables for the modes that aren't working yet.
Regards,
Stef
[sane-devel] HP Scanjet 2400c (partial) success, 100 and 300 dpi work both in grayscale and colour (some small changes needed)
Le dimanche 30 mai 2010 22:22:02 Piotr Mis, vous avez ?crit :
> Dnia 2010-05-30, nie o godzinie 11:14 +0200, stef pisze:
> > Le vendredi 28 mai 2010 16:07:50 Piotr Mis, vous avez ?crit :
> > > Very sorry, sent to soon.
> > >
> > > Hello,
> > >
> > > I was delighted that there is some progress with Scanjet 2400c.
> > >
> > > I ran it through some tests, and fixed what I could. Results:
> > >
> > > git version of genesys backend works partially:
> > >
> > > grayscale:
> > > * 50 dpi: hangs
> > > * 100 dpi: works partially, motor step too big, need to switch
> > > off
> > >
> > > the scanner to prevent damage
> > >
> > > * 300 dpi: works nicely
> > > * 600 dpi: picture distorted
> > >
> > > colour:
> > > as grayscale, but colour channels seem to be switched and slightly
> > > offset vertically.
> > >
> > > I tried to fix it myself and managed to fix the colour channels and the
> > > motor step in 100dpi.
> > >
> > >
> > > My changes below, comments/advice very welcome:
> > >
> > > 1. The scanner (at least mine) is RBG not BGR, this fixes the vertical
> > > offset as well:
> > >
> > >
> > > diff --git a/backend/genesys_devices.c b/backend/genesys_devices.c
> > > index a8da85d..3459090 100644
> > > --- a/backend/genesys_devices.c
> > > +++ b/backend/genesys_devices.c
> > > @@ -1173,7 +1173,7 @@ Genesys_Model hp2400c_model = {
> > >
> > >0, 24, 48, /* RGB CCD Line-distance correction in
> > >
> > > pixel */
> > >
> > > - COLOR_ORDER_BGR, /* Order of the CCD/CIS colors */
> > > + COLOR_ORDER_RGB, /* Order of the CCD/CIS colors */
> > >
> > >SANE_FALSE, /* Is this a CIS scanner? */
> > >SANE_FALSE, /* Is this a sheetfed scanner? */
> > >
> > > 2. The motor definition for 100 dpi from FULL_STEP to HALF_STEP:
> > >
> > > diff --git a/backend/genesys_gl646.h b/backend/genesys_gl646.h
> > > index 5dc3725..695d55f 100644
> > > --- a/backend/genesys_gl646.h
> > > +++ b/backend/genesys_gl646.h
> > > @@ -555,11 +555,11 @@ static Motor_Master motor_master[] = {
> > >
> > >/* HP2400/G2410 motor settings base motor dpi = 600 */
> > >{MOTOR_HP2400, 50, SANE_TRUE , 50, HALF_STEP, SANE_FALSE,
> > >
> > > SANE_FALSE, 63,
> > > - {MOTOR_HP2400, 100, SANE_TRUE , 100, FULL_STEP, SANE_FALSE,
> > > SANE_TRUE, 63, 1
> > > + {MOTOR_HP2400, 100, SANE_TRUE , 100, HALF_STEP, SANE_FALSE,
> > > SANE_TRUE, 63, 1
> > >
> > >{MOTOR_HP2400, 300, SANE_TRUE , 300, HALF_STEP, SANE_FALSE,
> > >
> > > SANE_TRUE , 63, 3
> > >
> > >{MOTOR_HP2400, 600, SANE_TRUE , 600, FULL_STEP, SANE_FALSE,
> > >
> > > SANE_TRUE , 63,
> > >
> > >{MOTOR_HP2400, 50, SANE_FALSE, 50, HALF_STEP, SANE_FALSE,
> > >
> > > SANE_FALSE, 63,
> > > - {MOTOR_HP2400, 100, SANE_FALSE, 100, FULL_STEP, SANE_FALSE,
> > > SANE_TRUE, 63, 1
> > > + {MOTOR_HP2400, 100, SANE_FALSE, 100, HALF_STEP, SANE_FALSE,
> > > SANE_TRUE, 63, 1
> > >
> > >{MOTOR_HP2400, 300, SANE_FALSE, 300, HALF_STEP, SANE_FALSE,
> > >
> > > SANE_TRUE , 63, 3
> > >
> > >{MOTOR_HP2400, 600, SANE_FALSE, 600, FULL_STEP, SANE_FALSE,
> > >
> > > SANE_TRUE , 63,
> > >
> > > What I'm still really missing is the preview in xsane, has probably
> > > something to do with not working 50dpi mode.
> > >
> > > Regards,
> > >
> > > Piotr
> >
> > Hello,
> >
> > so with these changes 100 dpi is working ? If you wish I can send you my
> >
> > log decoding scripts. By recording scanner activity under windows with
> > usbsnoop, then processing it through them, you'll have the values to put
> > in HP2400 motor and sensor tables for the modes that aren't working
> > yet.
> >
> > Regards,
> >
> > Stef
>
> Yes, 100 and 300 dpi both produce quite good scans with these settings.
> And yes, please do send me the scripts, I'll try to get the rest
> working.
>BTW. What would be nice to have is the scanner running smoothly
[sane-devel] genesys backend update / Canon LiDE 100 and 200
Hello,
with the latest git version of the genesys backend Canon LiDE 100 is
now
completely supported, and also the LiDE 200 which is only missing 2400 dpi
resolution. I'm currently working on 2400 dpi support and it should be
available in a couple of weeks.
Bug and success reports are welcomed.
Regards,
Stef
[sane-devel] Canon Lide 100/200
Le mardi 13 juillet 2010 14:11:30 Alf Gaida, vous avez ?crit : > Hi, i've builded debian-packages form the snapshot at weekend. The Canon > Lide 100 and 200 work fine. The only issue i see is that the default > calibration isn't well yet. Where (in which module) can I change the > gamma settings in the code? Hello, there is a custom gamma calibration option if you need. A frontend like xscanimage would let you change gamma settings to your likings. Regards, Stef
[sane-devel] Scanjet G2410 Scanner tested. Here's some results.
Le dimanche 4 juillet 2010 04:18:06 Rudy Matela, vous avez ?crit : > NOTE: Please keep me cc'ed, I'm not in the sane development list. > > Hi, > > Today I bought a Scanjet G2410 Scanner. While scanimage'ing I > received the following message: > > $ scanimage | pnmtopng > file.png > [genesys] WARNING: Your scanner is not fully supported or at least > [genesys] had only limited testing. Please be careful and > [genesys] report any failure/success to > [genesys] sane-devel at lists.alioth.debian.org. Please provide as > many [genesys] details as possible, e.g. the exact name of your > [genesys] scanner and what does (not) work. > > So, I'm doing what scanimage told me to do... > > Fortunately, scanimage worked and I managed to scan a monochromatic > image file with a very large resolution (dpi). So the driver worked > for that. But there are lots of things I cannot do: > > With this, I get a blurred image, with the colors kinda separated: > kinda like when you print in a poorly calibrated inkjet printer: > $ scanimage --mode Color > > With this I get the following message and nothing is scanned: > $ scanimage -vvv --resolution 150 > scanimage: value for --resolution is: 150 > scanimage: sane_start: Invalid argument > Closing device > Calling sane_exit > scanimage: finished > > $ lsusb > Bus 003 Device 002: ID 03f0:0a01 Hewlett-Packard ScanJet 2400c > > It says I have a 2400c, but mine is G2410. :D > > > I did not test, but I saw on some links that a proprietary driver for > the 2400 works with this scanner also: > http://old.nabble.com/to-configure-HP-ScanJet-2400-also-applies-to-the-HP-G > 2410-td21353706.html I don't know if the result would be just the same (no > dpi adjusting and no color scanning), but it could still be of help to > someone > working on it. > > Some info about my system: > Arch Linux > Linux oblivion 2.6.34-ARCH #1 SMP PREEMPT Sat Jun 19 13:06:16 CEST > 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux > sane 1.0.21 > > The status of scanner G2410 is untested, you can change that to > Minimal/Basic http://www.sane-project.org/sane-mfgs.html#Z-HEWLETT-PACKARD > > If you want any other info feel free to contact me. > > Regards, > Rudy Matela > > PS: The scanner is fully functional on Windows (strangely the scanner > light is always on, even there..., better keep it off to save energy!) > > -- > 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 Hello, the G2410 is a re-badged HP2400 (same product and vendor usb id). To find the real model, the backend would have to read an EEPROM using GPIO which isn't implemented. Piotr Mis is currently working on adding modes beside the 300 dpi one which is already working. Regards, Stef
[sane-devel] Xerox Travel Scanner 100 under Red Hat
Le samedi 17 juillet 2010 12:35:38 ??? ???, vous avez ?crit : > Hello. > > I am trying to make Xerox Travel Scanner 100 portable scanner under Red Hat > Linux (core - 2.4). Sane-backends-git20100716 driver is installed. > > When I use: > > $ scanimage ?d genesys > picture1.pnm > > it shows: > > $ scanimage: sane_start: Invalid argument > > To get a log, I used: > > $ export SANE_DEBUG_GENESYS=255 > $ export SANE_DEBUG_GENESYS_GL841=255 > $ scanimage ?d genesys > picture1.pnm 2 > xeroxTS100.log > > The log is attached to the email. > > Jane. Hello, there's a failure while trying to check the paper sensor. Could you run again with SANE's USB debug activated by 'export SANE_DEBUG_SANEI_USB=255' ? There may be some USB issue. Checking system logs with 'dmesg' could be interesting. Regards, Stef
[sane-devel] gt68xx backend with Plustek OpticSlim 1200 fails with error "power control failure"
Le jeudi 15 juillet 2010 04:37:06 Jens Herrmann, vous avez ?crit : > Hi, > I tried to get my Plustek OpticSlim 1200 working under Ubuntu Lucid > today following the instructions on > http://www.meier-geinitz.de/sane/gt68xx-backend/adding.html. > The scanner is recognized correctly, but on "scanimage >/dev/null" I get > > [gt68xx] sane_open: power control failure: check power plug! > scanimage: open of device gt68xx:libusb:003:004 failed: Error during > device I/O > > With SANE_DEBUG_GT68XX=255 and starting xsane I got the following output: > > -- > jens at big-white:~$ export SANE_DEBUG_GT68XX=255 > jens at big-white:~$ xsane > [sanei_debug] Setting debug level of gt68xx to 255. > [gt68xx] SANE GT68xx backend version 1.0 build 84 from sane-backends 1.0.20 > [gt68xx] sane_init: authorize != null > [gt68xx] sane_init: debug options are enabled, handle with care > [gt68xx] >> 3f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > [gt68xx] << 00 3f 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > [gt68xx] sane_open: power control failure: check power plug! > [gt68xx] sane_exit: start > [gt68xx] gt68xx_device_free: enter: dev=0x12d9e50 > [gt68xx] gt68xx_device_close: enter: dev=0x12d9e50 > [gt68xx] gt68xx_device_close: leave: ok > [gt68xx] gt68xx_device_free: freeing dev > [gt68xx] gt68xx_device_free: leave: ok > [gt68xx] sane_exit: exit > jens at big-white:~$ > --- > > The scanner does work under WindowsXP on the same system without any > problems. > Does anyone have an idea what I could do about this? > > Any advice appreciated. > Jens > > > -- > 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 Hello, the reported version : SANE GT68xx backend version 1.0 build 84 from sane-backends 1.0.20 seems quite old to me. You might try SANE 1.0.21. You may also look into overriding flags to avoid power check: ie set the GT68XX_FLAG_NO_POWER_STATUS flag. Regards, Stef
[sane-devel] problem with canoscan 5600F
Le vendredi 23 juillet 2010 15:25:02 m. allan noah, vous avez ?crit : > This scanner is not currently supported by sane. However, in March > there was a discussion about this scanner, which implied that it uses > a Genesys Logic GL847 chipset. Stef has recently added support for > this chipset to the sane-genesys backend. So, it may be possible to > make the modifications required to support this machine, if you use a > current git snapshot of sane-backends. Perhaps you and Catalin David > can work together, with some advice from stef? > > allan > Hello, we can check if it can be a gl847 with the 'lsusb' command under Ubuntu. First run it with no argument to have the list of devices: lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 04f2:b024 Chicony Electronics Co., Ltd USB 2.0 Webcam Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 04a9:1904 Canon, Inc. Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 1bcf:0007 Sunplus Innovation Technology Inc. Optical Mouse Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Then run it to get the detail of the Canon device. Here it is a LiDE 100 with vendor and product id 04a9:1904 (change to match your device id). If the reported information matches (specially the bcdDevice value), it will be worth trying to add it to gl847 devices: lsusb -d 04a9:1904 -v Bus 002 Device 003: ID 04a9:1904 Canon, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x04a9 Canon, Inc. idProduct 0x1904 bcdDevice6.03 iManufacturer 1 Canon iProduct2 CanoScan iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 8 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) Regards, Stef
[sane-devel] problem with canoscan 5600F
Le vendredi 30 juillet 2010 02:11:37 Jeff, vous avez ?crit : > How about as root so that last error doesn't happen! Sorry ... > > x at x:~# lsusb -d 04a9:1906 -v > > Bus 001 Device 005: ID 04a9:1906 Canon, Inc. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize064 > idVendor 0x04a9 Canon, Inc. > idProduct 0x1906 > bcdDevice6.03 > iManufacturer 1 Canon > iProduct2 CanoScan > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 39 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 10mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass255 Vendor Specific Subclass > bInterfaceProtocol255 Vendor Specific Protocol > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0001 1x 1 bytes > bInterval 8 > Device Qualifier (for other device speed): > bLength10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize064 > bNumConfigurations 1 > Device Status: 0x0001 > Self Powered > Hello, this look like a gl847 scanner. I'll will clone the LiDE 200 entry in the genesys backend using 5600F usb id this week-end, so you can compile and try to use your scanner. Regards, Stef
[sane-devel] Vertical bands with Lexmark X1150
Le samedi 4 septembre 2010 19:50:48 Andrew Ziem, vous avez ?crit : > I use Fedora 13 (32-bit) with SANE 1.0.21-2 with a Lexmark X1150 (Dell > A920), but I see horizontal bands when scanning with SANE, Xsane, and > GIMP. When scanning in Windows, it looks fine. > > Example image (300dpi) > http://a.imageshack.us/img829/943/lexmarkx1150verticalban.png > > Andrew > > -- > 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 Hello, the artifacts you see are due to incorrect shading calibration. Does these vertical lines change if you do several scans ? May be the lamp isn't warm enough during first scans. Regards, Stef
[sane-devel] Vertical bands with Lexmark X1150
Le mardi 7 septembre 2010 00:28:07 Andrew Ziem, vous avez ?crit : > On Sun, Sep 5, 2010 at 10:29 PM, stef wrote: > > Le samedi 4 septembre 2010 19:50:48 Andrew Ziem, vous avez ?crit : > >> I use Fedora 13 (32-bit) with SANE 1.0.21-2 with a Lexmark X1150 (Dell > >> A920), but I see horizontal bands when scanning with SANE, Xsane, and > >> GIMP. When scanning in Windows, it looks fine. > >> > >> Example image (300dpi) > >> http://a.imageshack.us/img829/943/lexmarkx1150verticalban.png > > > >the artifacts you see are due to incorrect shading calibration. > > Does these vertical lines change if you do several scans ? May be the > > lamp isn't warm enough during first scans. > > Hi Stef, > > I just tried the same scan 5 times in Linux, and it happened every > time. In Windows, it works fine the first time. > > > Andrew Hello, in order to debug, you need to compile a debug version of SANE. You must get the sources and compile them _without_ installing them. ie doing 'make' but not 'make install'. Before compiling you must edit lexmark.h and change the '#undef DEEP_DEBUG' in it to '#define DEEP_DEBUG 1'. Once compiled, it can be run locally from the 'backend' sub-directory with the appended run-lexmark shell which has to be copied in 'backend'. It will generate a lexmark-scan.log and various *.pnm files. Please send them all to me so that I can find exactly what is going on. Regards, Stef -- next part -- A non-text attachment was scrubbed... Name: run-lexmark Type: application/x-shellscript Size: 235 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100909/556a0916/attachment.bin>
[sane-devel] Scanner HP Scanjet G2410
Le mercredi 8 septembre 2010 13:11:05 Vladislav, vous avez ?crit : > sane version 1.0.14 > > Starts not every time. > In gray mode scanner works fine. In color mode scans, but a) every ~5-6 > cm returns back to 1-2 cm and rescan this place b) In picture yellow, > cyan and magenta colors are separated by few pixels. > > > -- > 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 Hello, the G2410 is a clone of the HP 2400. Support for this scanner isn't complete in the genesys backend. I'm not currently working on it, but Piotr Mis who owns such a device has undertaken this. Regards, Stef
[sane-devel] scanner HP 3690
Le Sunday 12 September 2010 23:18:22 Hiisi, vous avez ?crit :
> Hi!
> I'm running sane [1] on fedora-linux machine [2]. My scanner didn't
> work until some updates to sane-backends. Now it works like a sharm
> with xsane GUI. However the list of supported devices at sane-project
> page [3] clearly stays it doesn't work. Should it be corrected or is
> it just a miracle?
> Respectfully,
> Hiisi
>
> REFERENCES:
> 1. $ rpm -qa | grep sane
> sane-backends-1.0.21-2.fc12.i686
> libsane-hpaio-3.10.5-1.fc12.i686
> xsane-0.997-10.fc12.i686
> sane-backends-libs-1.0.21-2.fc12.i686
> xsane-common-0.997-10.fc12.i686
> xsane-gimp-0.997-10.fc12.i686
> sane-frontends-1.0.14-9.fc12.i686
> sane-backends-devel-1.0.21-2.fc12.i686
> sane-backends-libs-gphoto2-1.0.21-2.fc12.i686
>
> 2. $ uname -a
> Linux kello.ru 2.6.32.21-166.fc12.i686 #1 SMP Fri Aug 27 06:55:23 UTC
> 2010 i686 i686 i386 GNU/Linux
>
> 3.
Hello,
the HP3690 has the same USB id than the HP3670 which is fully supported
by the genesys backend. Does the UTA works well also ?
I'll update descriptions for this scanner.
Thank for the success report,
Stef
[sane-devel] scanner HP 3690
Le Monday 13 September 2010 08:06:32, vous avez ?crit : > 2010/9/13 stef : > > Le Sunday 12 September 2010 23:18:22 Hiisi, vous avez ?crit : > >> Hi! > > <--SNIP--> > > >Hello, > > > >the HP3690 has the same USB id than the HP3670 which is fully > > supported by the genesys backend. Does the UTA works well also ? > > I don't know what does UTA mean. How can I test it? Fast google didn't > find anything. > > >I'll update descriptions for this scanner. > > > > Thank for the success report, > >Stef > > Yes, thank you. That was the purpose of my writing. Somebody see that > his scanner is unsupported by Linux and would stay on windoze side. > For example, I used VirtualBox virtual machine with WinXP for the > purpose. > Appreciate your work! Hello, the UTA is the Universal Transparency Adaptor, which is the adaptor for scanning photographic negatives. I'm happy my work is useful to you. Regards, Stef
[sane-devel] problem with canoscan 5600F
Le Wednesday 15 September 2010 13:40:38 Denis Jallat, vous avez ?crit : > I have a canoscan 5600 too and the same problem as Catelin (probalely > the same problem or an identical problem); I contacted stef and I gave > him data so he can identify the problem. > > Denis Jallat > (excuse my english) Hello, the usbsnoop you sent gave lots of useful information. First the analog frontend used is different form the LiDE 100 and 200. Then the 5600f is using a CCD sensor while only CIS sensor are currently supported for gl847. I'll come up with a test patch, but real development can only be done when having the device to test. Maybe you or David may have a try at it and I would assist you. Since motor seems to work alright, what is left is some modification for CCD and analog frontend. There is already existing code for the gl841/gl843 parts which can be a good basis. In fact the most tedious is testing. Regards, Stef
[sane-devel] scanner HP 3690
Le Thursday 16 September 2010 08:54:31 Hiisi, vous avez ?crit : > > Regards, > >Stef > > It doesn't work. Actually I was able to make a few copies of negatives > but sane works only the first time I start it after reboot and only if > the scanner also was switched off/turned on again. And I was only able > to scan in 150 pixels. > Should I provide some tests for it? Hello, maybe the HP3690 UTA geometry is slightly different from the 3670 one. Could you scan it (150 dpi would be enough) by removing any doc and doing a regular color scan ? Then could you run xsane with the appended script and scan using the UTA? This will create a genesys.log file in the working directory where the script is ran. Please send it to me so that I can have an idea of what is going wrong. Regards, Stef
[sane-devel] scanner HP 3690
Hum,
here's the script
Regards,
Stef
-- next part --
A non-text attachment was scrubbed...
Name: run-genesys
Type: application/x-shellscript
Size: 244 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100917/76fc25bc/attachment.bin>
[sane-devel] Vertical bands with Lexmark X1150
Le Wednesday 15 September 2010 15:21:06 Andrew Ziem, vous avez ?crit : ... > > Hi Stef, > > Sorry! I had to do two things to make the shading file > > 1. I forgot to define DEEP_DEBUG :( > 2. I ran the commented-out parts of your shell script. (Apparently the > first time I was running the code that was installed with Fedora and > not the code I compiled myself.) > > I am attaching a .zip with the log and all the PNMs. Also there is a > PNG from Windows XP for comparison. > > (The large, solid white area in the Disneyworld PNG I posted on the > mailing list is where I removed a person for privacy reasons.) > > > Andrew Hello, to compute shading correction to be apllied on scans, the backend first scan a white area before the glass. It seems that usable white lines are lesser than other similar models. A short term fix is to try o shorten the numner of lines used. In lexmark_low.c around line 4940 change if (yoffset + (8 * 4) / regs[0x7a] < lines) lines = yoffset + (8 * 4) / regs[0x7a]; to if (yoffset + (8 * 2) / regs[0x7a] < lines) lines = yoffset + (8 * 2) / regs[0x7a]; so we use only 2 lines (you could alos try with 3 lines). If it isn't enough we'll have to change calibration to scan backward to find a better white area. Regards, Stef
[sane-devel] Canon LiDE 110, with GL848+
Le Wednesday 22 September 2010 23:37:14 Gareth McMullin, vous avez ?crit : > Hi > > I have acquired a Canon LiDE 110 scanner (vid:pid = 04a9:1909) which I > would like to use with SANE. > The 'sane-find-scanner' reports the device with chip detected as 'GL848+'. > The output of 'sane-find-scanner -v -v' is attached. > > Is anyone working on support for this device? If not, I'm interested in > contributing. > > The Genesys Logic website has no information on this chip, but I've found a > datasheet from alldatasheet.com. This document doesn't say anything about > USB transactions. > > Does anyone know where I can get more information? Otherwise I'll capture > some logs from Windows and look at the other chips supported by the Genesys > backend for comparison. > > Thanks and regards, > Gareth Hello, sane-find-scanner uses a guess method for the genesys chip used. To get usre it is a gl848 you would need to open your scanner. Another source of information is to use usbsnoop under windows to record usb activity for a low resolution scan and send me the log I'll processed it and compare it with Canon Lide 100/200 logs. This way we will have an idea of our close they are. One quick test you could make is to clone the LIDE100 entry in genesys_devices.c, and link it to 04a9:1909 and add this usb id in genesys.conf . Regards, Stef
[sane-devel] genesys and hp G2410: the size of geometry is incorrect
Le Wednesday 22 September 2010 05:11:31 Andrey Afletdinov, vous avez ?crit : > I tested a sane-backends-git20100921. > > Device HP ScanGet G2410 > lspci: > Bus 006 Device 021: ID 03f0:0a01 Hewlett-Packard ScanJet 2400c > > For A4-size paper, I had to use the options: > scanimage -y 145 > > Thus the device scans as the full size ?4. > If I set parameter -y more than 145, then a scan is attempted with a > height that exceeds the > height of the scan surface. > > As a result: I receive the image compressed on a vertical approximately > twice. > > How it to correct? I can send a debug logs. > > -- > 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 Hello, the HP2400 is not yet fully supported. So the issues you are facing are expected. Regards, Stef
[sane-devel] Driver USB scanner hp scanjet 4670 ?
Le Sunday 26 September 2010 09:21:47 damien1984 at riseup.net, vous avez ?crit : > Hello, > > My USB scanner hp scanjet 4670 is "unsupported" by XSane. I don't really > understand these indications : "Especially the output of sane-find-scanner > -v -v and/or cat /proc/scsi/scsi (for SCSI scanners) or cat > /proc/bus/usb/devices (for USB scanners) can help." I am not so kind on > computing. Can you help me ? Is it possible to find a driver for this > scanner with Ubuntu ? > > It exists for Mac and Windows : > http://h2.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?prodNam > eId=303642&lang=fr&cc=fr&prodTypeId=15179&prodSeriesId=303640&taskId=135 > > Thanks a lot, > > Damien. > > > -- > 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 Hello, the 'unsupported scanner' list hint looking for the HP4600 (same USB Id) where you can get a pointer to a basic driver at http://www.chmil.org/hp4600linux/ . It seems worth to explore this. Regards, Stef
[sane-devel] Programming a backend for the HP4010 Scanner
Le Sunday 26 September 2010 09:54:35 Eneko Zubia, vous avez ?crit : > Hi Roland, > > I just found your message about programming a backend for the HP G4010 > scanner and I am wondering if you have made any progress in all this time. > > I would like to cooperate a somehow but I warn you I don have much time for > it. You know, babies and that. > > Do you mind sharing those specs for the GL841, GL842 and GL843 chip? > > Regards > Eneko Hello, these PDF are freely available from the genesys corporate site or from various datasheet providers. Have you tried to check the exact chip used by the G4010 ? The G4050 I am currently working on is using a gl843. I am going to commit code to bring 200 and 300 dpi scans for it. It will be interesting to see how it behaves with the G4010. BTW, when the scanning head of the G4050 is away from its parking position, I can clearly see the GL843 printing on the PCB inside the scanner. May be you could try to look at it to check it is also GL843 based. Regards, Stef
[sane-devel] Colored vertical stripes with Visioneer Xerox DocuMate 510
Le Saturday 25 September 2010 22:58:03 chris guirl, vous avez ?crit : > Hi, I recently got this model scanner and tried it out. It works fine > in grayscale but when I scan color images, there are wide, repeating > vertical bars overlaying the image. > > It is not dissimilar to the problem in the picture from the thread > "[sane-devel] Vertical bands with Lexmark X1150". However in this case > there is a much more pronounced effect with brightly colored stripes > blended with much of the image. > > I'll get a sample uploaded soon, the scanner is currently in use (it > works fine with the manufacturer's drivers in Windows). > > I am using Ubuntu 10.04 x86-64 (kernel 2.6.32-25), with sane and xsane > installed via .deb packages: libsane 1.0.21-0ubuntu1, sane-utils > 1.0.21-0ubuntu1, xsane and xsane common 0.996-2ubuntu3. > > I'm a programmer and happy to hack on the driver, if necessary, since > I have the equipment and can easily test it...but I'm not quite sure > where to start as this is my first time working with sane or any > scanning on Linux for that matter. > > Thanks > > Chris Guirl > Hello, pixels on the CCD sensor aren't exactly the same on a CCD sensor. To adjust for this differences the lexmark backend scans a pure white area. The scanned value for each pixel is used to compute a correction coefficient. The targetted area is the white area between a black round spot (used to locate home position) and the glass off the effective scan area. It is located 'under the roof' of the scanner and can only be seen by disassembling the scanner. I seems that this isn't enough to get good white data. To my opinion, the best solution is to scan backward (ie move the head to the top of scanner and away from the glass). I hope the area there is better, but I can't know for sure. The problem is that these scanners don't have a mechanical system to prevent the moving sensor going to far, and it may hit the top of the casing. It happened to me quite a few times, and I had no damage since I always kept a hand free to unplug the power cable. But think of it before doing the following code change: Currently, shading calibration is done in 'forward' direction, then a scan is done backward to put back the sensor to start position. The code is in lexmark_low.c, in the sanei_lexmark_low_shading_calibration() function. The direction of the scan is driven by bit 3 of register 0xc6. To go backward we do line 4987: regs[0xc6] &= 0xF7; Move it before the first low_simple_scan() line 4881, and put regs[0xc6] |= 0x08; where it was to get to back to 'forward' direction. You might rename the debug file names as well to reflect this direction change. They are written when DEEP_DEBUG is defined in lexmark.h . Currently 8 lines are scanned, maybe there is room to scan more lines when scanning backward. You might try to increase this value. Adding a define for this line number would be handy and would improve the current code. Don't hesitate to ask me for more information and advice. Regards, Stef
[sane-devel] Colored vertical stripes with Visioneer Xerox DocuMate 510
Le Monday 27 September 2010 18:12:06 stef, vous avez ?crit : > Le Saturday 25 September 2010 22:58:03 chris guirl, vous avez ?crit : > > Hi, I recently got this model scanner and tried it out. It works fine > > in grayscale but when I scan color images, there are wide, repeating > > vertical bars overlaying the image. > > > > It is not dissimilar to the problem in the picture from the thread > > "[sane-devel] Vertical bands with Lexmark X1150". However in this case > > there is a much more pronounced effect with brightly colored stripes > > blended with much of the image. > > > > I'll get a sample uploaded soon, the scanner is currently in use (it > > works fine with the manufacturer's drivers in Windows). > > > > I am using Ubuntu 10.04 x86-64 (kernel 2.6.32-25), with sane and xsane > > installed via .deb packages: libsane 1.0.21-0ubuntu1, sane-utils > > 1.0.21-0ubuntu1, xsane and xsane common 0.996-2ubuntu3. > > > > I'm a programmer and happy to hack on the driver, if necessary, since > > I have the equipment and can easily test it...but I'm not quite sure > > where to start as this is my first time working with sane or any > > scanning on Linux for that matter. > > > > Thanks > > > > Chris Guirl > > Hello, > > pixels on the CCD sensor aren't exactly the same on a CCD sensor. To > adjust for this differences the lexmark backend scans a pure white area. > The scanned value for each pixel is used to compute a correction > coefficient. The targetted area is the white area between a black round > spot (used to locate home position) and the glass off the effective scan > area. It is located 'under the roof' of the scanner and can only be seen > by disassembling the scanner. I seems that this isn't enough to get good > white data. To my opinion, the best solution is to scan backward (ie move > the head to the top of scanner and away from the glass). I hope the area > there is better, but I can't know for sure. The problem is that these > scanners don't have a mechanical system to prevent the moving sensor going > to far, and it may hit the top of the casing. It happened to me quite a > few times, and I had no damage since I always kept a hand free to unplug > the power cable. But think of it before doing the following code change: > Currently, shading calibration is done in 'forward' direction, then a > scan is done backward to put back the sensor to start position. The code is > in lexmark_low.c, in the sanei_lexmark_low_shading_calibration() function. > The direction of the scan is driven by bit 3 of register 0xc6. > To go backward we do line 4987: > regs[0xc6] &= 0xF7; > Move it before the first low_simple_scan() line 4881, > and put > regs[0xc6] |= 0x08; > where it was to get to back to 'forward' direction. You might rename the > debug file names as well to reflect this direction change. They are written > when DEEP_DEBUG is defined in lexmark.h . Currently 8 lines are scanned, > maybe there is room to scan more lines when scanning backward. You might > try to increase this value. Adding a define for this line number would be > handy and would improve the current code. > > Don't hesitate to ask me for more information and advice. > > Regards, > Stef > > > -- > 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 Oops, forgot to check that your scanner was supported by the lexmark backend. Is it the case ? Sometimes scanners are merely relabeled models. Shading correction is varying from backend to backend with the capabilities of the underlying hardware. Regards, Stef
[sane-devel] Vertical bands with Lexmark X1150
Le Tuesday 28 September 2010 06:49:32 Andrew Ziem, vous avez ?crit : > On Sun, Sep 19, 2010 at 10:09 PM, stef wrote: > > Le Wednesday 15 September 2010 15:21:06 Andrew Ziem, vous avez ?crit : > > ... > > > >> Hi Stef, > >> > >> Sorry! I had to do two things to make the shading file > >> > >> 1. I forgot to define DEEP_DEBUG :( > >> 2. I ran the commented-out parts of your shell script. (Apparently the > >> first time I was running the code that was installed with Fedora and > >> not the code I compiled myself.) > >> > >> I am attaching a .zip with the log and all the PNMs. Also there is a > >> PNG from Windows XP for comparison. > >> > >> (The large, solid white area in the Disneyworld PNG I posted on the > >> mailing list is where I removed a person for privacy reasons.) > >> > >> > >> Andrew > > > >Hello, > > > >to compute shading correction to be apllied on scans, the backend > > first scan a white area before the glass. It seems that usable white > > lines are lesser than other similar models. A short term fix is to try > > o shorten the numner of lines used. In lexmark_low.c around line 4940 > > change > > if (yoffset + (8 * 4) / regs[0x7a] < lines) > >lines = yoffset + (8 * 4) / regs[0x7a]; > > > > to > > if (yoffset + (8 * 2) / regs[0x7a] < lines) > >lines = yoffset + (8 * 2) / regs[0x7a]; > > > >so we use only 2 lines (you could alos try with 3 lines). If it > > isn't enough we'll have to change calibration to scan backward to find a > > better white area. > > I'm still seeing the bands with 2 and 3. Should I send the logs again? > > Andrew Hello, I think you should try what I explained in 'Re: [sane-devel] Colored vertical stripes with Visioneer Xerox DocuMate 510'. Using another white area to improve shading calibration seems the best solution. Regards, Stef
[sane-devel] Programming a backend for the HP4010 Scanner
Le Monday 27 September 2010 23:25:11, vous avez ?crit : > On Monday 27 September 2010 13:31:23 you wrote: > > BTW, when the scanning head of the G4050 is away from its parking > > > > position, I can clearly see the GL843 printing on the PCB inside the > > scanner. May be you could try to look at it to check it is also GL843 > > based. > > > > Regards, > > > > Stef > > Yes, my G4010 wears a GL843 too. Where can I find your work so I can start > testing it? > > Regards, > > Eneko Hello, I have pushed my work in progress to add support for the G4050 in SANE's git repository. It now can do 200 and 300 dpi scans. I have also added a device entry for the G4010. It would be interesting if you could test it. If everything goes right, you should be able to do 200/300 dpi scans as well. Regards, Stef
[sane-devel] HP Scanjet G4010
Le Saturday 02 October 2010 11:25:07 Brian Shaver, vous avez ?crit : > Hello, > I've got an HP Scanjet G4010. > > I'd like to offer to assist with developing a backend for this model. If > I'm not mistaken, it looks like this is being actively worked on > currently. Does someone know the status of this effort? > > I'd be willing to help with testing, tweaks or whatever. > > Thanks, > Brian .. Hello, I have committed code for G4010 support in the genesys backend at the same time for limited support for G4050. It should be able to scan at 200 and 300 dpi. It would be nice if you could test latest SANE's git source code. The next step is to add higher resolution (up to 4800 dpi), but it needs another way of setting up the sensor. Up to now the genesys backend assumed that hardware sensor's dpi wouldn't change. This has to be modified since a low dpi scan is slower when the sensor is set to 4800 than another lower resolution. Regards, Stef
[sane-devel] Colored vertical stripes with Visioneer Xerox DocuMate 510
Le Saturday 02 October 2010 19:33:18 chris guirl, vous avez ?crit :
> On Mon, Sep 27, 2010 at 12:31 PM, stef wrote:
> >forgot to check that your scanner was supported by the lexmark
> > backend. Is it the case ? Sometimes scanners are merely relabeled
> > models.
>
> I don't know. On sane-project.org the model is listed as unsupported.
> I have noticed the other Xerox DocuMate scanners are supported by the
> avision backend. I'm unsure how to find out which backend is being
> used when I run xsane.
>
> >Shading correction is varying from backend to backend with the
> > capabilities of the underlying hardware.
>
> I have thought that it could be the problem you described above - the
> white-calibration area is dirty. However I can't imagine what kind of
> dirt would make this pattern...I uploaded a sample here:
>
> http://sqrville.org/software/colored_bands.png
>
>
> Recently, I was able to make a few successful scans. I can't reproduce
> this now or figure out what made it work and what made it stop working
> later.
>
>
> Doing some more testing, I noticed that the scanner has thinner bands
> of discoloration (about half the width of before) at a resolution
> setting of 600dpi.
>
>
> It is also worth noting that, to get the scanner working at all, I had
> to add this line to /lib/udev/rules.d/40-libsane.rules:
>
> # Xerox DocuMate510
> ATTRS{idVendor}=="04a7", ATTRS{idProduct}=="0446",
> ENV{libsane_matched}="yes"
>
> Chris
Hello,
this scanner appears to be supported by the avision backend. I think
your
scans may be affected 'warming up'. When the lamp isn't warm enough, light is
varying, so scanned data is different other time. This fools shading
calibration. When the lamp is stable, shading works better.
Regards,
Stef
[sane-devel] HP Scanjet G4010
Le Tuesday 05 October 2010 15:28:28 Brian Shaver, vous avez ?crit : > Stef, > Obtained the latest git source code. The G4010 is detected. scanimage > --test passes. However, trying both Color and Gray modes all I get back > scanimage is a solid black image. > > I'll keep looking around for more information / tests to run, or let me > know if there is specific output which would be helpful. > > Thanks, > Brian .. > Hello, there is a bug in setting up some registers values. To check it is the cause of blacks images, in gl843_cold_boot(), change the strcmp around line 3679 to if(1) in genesys_gl843.c Meanwhile I am progressing. I have added 100 and 150 dpi modes, and 600, 1200 and 2400 dpi modes are about to work. Regards, Stef
[sane-devel] HP Scanjet G4010
Le Friday 08 October 2010 13:11:22 Brian Shaver, vous avez ?crit : > Stef, > You are correct, changing the following line now produces results: > > /* set up clock once for all */ > if (1) /*if (strcmp (dev->model->name, "hewlett-packard-scanjet-g4050") > == 0) */ > > Trying Gray, Color and Lineart modes. The result for Gray was pretty good. > With the Color mode I'm seeing some ghosted image effects. The Lineart mode > produced an image which was nearly all black. > > Thanks, > Brian .. > > On Thu, Oct 7, 2010 at 12:15 AM, stef wrote: > > Le Tuesday 05 October 2010 15:28:28 Brian Shaver, vous avez ?crit : > > > Stef, > > > Obtained the latest git source code. The G4010 is detected. scanimage > > > --test passes. However, trying both Color and Gray modes all I get back > > > scanimage is a solid black image. > > > > > > I'll keep looking around for more information / tests to run, or let > > > me know if there is specific output which would be helpful. > > > > > > Thanks, > > > Brian .. > > > > > Hello, > > > >there is a bug in setting up some registers values. To check it is > > > > the > > cause of blacks images, in gl843_cold_boot(), change the strcmp around > > line 3679 to if(1) in genesys_gl843.c > > > >Meanwhile I am progressing. I have added 100 and 150 dpi modes, > >and > > > > 600, > > 1200 and 2400 dpi modes are about to work. > > > > Regards, > > > > Stef Hello, thanks for the tests. I'll commit a patch by Wednesday that will handle correctly the G4010, and will add at least 100 and 150 dpi color. The 'CCD line distance' (giving the color ghosting effect) problem will also be fixed. Regards, Stef
[sane-devel] HP Scanjet G4010
Le Friday 08 October 2010 13:11:22 Brian Shaver, vous avez ?crit : > Stef, > You are correct, changing the following line now produces results: > > /* set up clock once for all */ > if (1) /*if (strcmp (dev->model->name, "hewlett-packard-scanjet-g4050") > == 0) */ > > Trying Gray, Color and Lineart modes. The result for Gray was pretty good. > With the Color mode I'm seeing some ghosted image effects. The Lineart mode > produced an image which was nearly all black. > > Thanks, > Brian .. > Hello, I have updated the genesys backend and added 100, 150, 400 and 600 dpi modes for the G4010/G4050. If have also took care of the problem you had. By checking out the current SANE's git source tree you should have improved support for your scanner. Regards, Stef
[sane-devel] Lexmark X74
Le Thursday 21 October 2010 12:31:01 Torsten Houwaart, vous avez ?crit : > Hello there, > > I'm currently trying to write a driver for my old Lexmark X74 Scanner. Is > somebody already working on that? Or can somebody tell me a good reason > why I shouldn't (legal issues etc.)? I also have a few questions about > that, don't worry they won't be like 'what is a sniffer?'. I have never > written a driver before, but by now I have a good understanding of how > Lexmark scanner drivers work and I have made some good progress with tying > in some of my own commands in the backend. Should I contact Stephane Voltz > or Fred Odendaal directly (their names are in the lexmark man page)? > > Cheers, > Torsten Houwaart Hello, do you mean you are disassembling the windows driver ? I think this should be avoided for legal reasons. Sniffing means using a program that records USB activity during scans done under windows so one can look at them and figure out the protocol. If you double checked the X74 is rts8852 based, you can send patches to the mailing list for the lexmark backend. Regards, Stef
[sane-devel] Not correctly scans the scanner HP G2410
Le Tuesday 26 October 2010 11:46:51 Andrey Afletdinov, vous avez ?crit : > I need to scan quickly and I use a command: > scanimage --resolution 100 Hello, the G2410 which is a clone of the HP2400 isn't supported. IT is only in early stages. In your case the motor resolution doesn't fit the horizontal one. What is left to do is to record USB activity of a scan done under windows with usbsniff, then process these logs to extract the data and fill the structures for it in the genesys_gl646.h file. This can only be done by someone having the scanner to test. If you wish I may provide you the scripts needed to proecess USB logs, and advice to tune the genesys backend for your scanner. Regards, Stef
[sane-devel] Canon lide 80
Le Wednesday 27 October 2010 06:15:07 Ludovic Andrivon, vous avez ?crit : > Hi, > > I have a Canon Lide 80, I switch to linux in 2007 and subscribe to this > list in 2008... > So when I need to scan i have to start a virtual machine with windows XP > because this scanner is listed as unsupported. > Since 2008 I learn a few things and may be I can help making this > scanner as supported even is my background as programmer is more Cobol > oriented... > > From what I read on the list I completed the following steps: > On my computer running Ubuntu 10.04 x86_64 2.6.32-25-generic #45 > - star Virtual Box with windows XP > - install USBsnoop > - log the calibration phase > - log a small black and white scan at 75 dpi > - log a small color scan at 75 dpi > > - get a fresh copy of sane fron git and compile it > - change some genesys_device files so my scanner can be recognized and > use canon lide 60 as model > - run /usr/local/bin/sane-find-scanner > found USB scanner (vendor=0x04a9 [Canon], product=0x2214 [CanoScan], > chip=GL842) at libusb:001:006 > - run /usr/local/bin/scanimage > test.png > the scanner moved and start scanning for 5 seconds then stop and get > stuck as I 'm rigth now ;-) > > You can find all files and logs at the following web site: > https://sites.google.com/site/cialsane/ > > What can be the next steps ? > > Thanks > > Ludovic > andrivon at cial.ca > Hello, if you wish I can send you the scripts I use to decode gl841/842 logs. Then you will be able to compare what is done under windows and by the backend. It may be the analog frontend or the GPIO settings which are different from the model you choose to clone. Regards, Stef
[sane-devel] Not correctly scans the scanner HP G2410
Le Wednesday 27 October 2010 16:11:27, vous avez ?crit : > Yes, I have this model of scanner and I can make any tests. > > 2010/10/27 stef : > > Le Tuesday 26 October 2010 11:46:51 Andrey Afletdinov, vous avez ?crit : > >> I need to scan quickly and I use a command: > >> scanimage --resolution 100 > > > >Hello, > > > >the G2410 which is a clone of the HP2400 isn't supported. IT is > > only in early stages. In your case the motor resolution doesn't fit the > > horizontal one. > >What is left to do is to record USB activity of a scan done under > > windows with usbsniff, then process these logs to extract the data and > > fill the structures for it in the genesys_gl646.h file. This can only be > > done by someone having the scanner to test. > >If you wish I may provide you the scripts needed to proecess USB > > logs, and advice to tune the genesys backend for your scanner. > > > > Regards, > >Stef Hello, to decode a USB log run decode.sh. Then use genere.awk to process it to get data usable for genesys_gl646.h structs: awk -f genere.awk some.log.decode >result Regards, Stef -- next part -- A non-text attachment was scrubbed... Name: scripts.tar.gz Type: application/x-compressed-tar Size: 14589 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101027/0e54b38a/attachment-0001.bin>
[sane-devel] Canon CanoScan LiDE 100
reshold 0..100% (in steps of 1) [50] > Select minimum-brightness to get a white point > --threshold-curve 0..127 (in steps of 1) [50] > Dynamic threshold curve, from light to dark, normally 50-65 > --disable-interpolation[=(yes|no)] [no] > When using high resolutions where the horizontal resolution is > smaller > than the vertical resolution this disables horizontal > interpolation. > --color-filter Red|Green|Blue [Green] > When using gray or lineart this option selects the used color. > Sensors: > --scan[=(yes|no)] [no] [hardware] > Scan button > --file[=(yes|no)] [no] [hardware] > File button > --email[=(yes|no)] [no] [hardware] > Email button > --copy[=(yes|no)] [no] [hardware] > Copy button > Buttons: > --clear-calibration [] > Clear calibration cache > > Type ``scanimage --help -d DEVICE'' to get list of all options for > DEVICE. > > List of available devices: > genesys:libusb:001:002 > > As you can see, near the end there's a section "Sensors" which > enumerates the four physical buttons available on the scanner. > Executing `scanimage --scan` throws an error. > I wonder how these options are to be used, if I could write a script to > detect when the buttons are pressed, if I should use scanbuttond (which > I haven't managed to get working) or if I should simply give up as the > buttons won't work. > > Thank you very much. > > Regards, > Mauro Torrez. > > > > -- > 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 Hello, regarding the darkness problem you have, I'm rather inclined to look why calibration work as good as it works with my LiDE 100. There is a persistent cache for calibration. You may clear it with the --clear-calibration option, which is available in the advanced panel option in Xsane. Does clearing it and scanning again changes something ? Regarding buttons, these options are read-only and thus cannot be set as a command line option. If you want to check the button status, you should avoid using scripts, it would initialize the scanner each time, which may be so long you'll miss button events. You'd rather use scanbuttond. Regards, Stef
[sane-devel] Canon lide 80
Le Thursday 28 October 2010 03:20:37 Ludovic Andrivon, vous avez ?crit : ... > > Hi Stef, > > Of course you can send me your scripts. > I will try to get something out of those logs then. > > > Regards, > > Ludovic Hello, here are the scripts. I have tested and modified them on the log you posted. When working on a log, get sure it has everything from scanner powering on, since important things (such as GPIO settings) happen then. Happy hacking, Stef -- next part -- A non-text attachment was scrubbed... Name: scripts.tar.gz Type: application/x-compressed-tar Size: 10213 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101030/eb9647c6/attachment.bin>
[sane-devel] Canon CanoScan LiDE 100
Hello, I have just pushed a new revision of the genesys backend (build 41) that raises the default gamma of LiDE 100/200 to 1.7 instead of 1.0. It would be nice if you could test this version (now available in the git source tree) to see how it improves the image darkness issue you had. Regards, Stef
[sane-devel] Lexmark 74 - first results
Le Monday 01 November 2010 00:49:58 Torsten Houwaart, vous avez ?crit : > Hello, > > > If you double checked the X74 is rts8852 based, you can send patches to > > the mailing list for the lexmark backend. > How can i make sure ? > I've had some very promising results. I was able to get scans at 75dpi > greyscale and colour. So I guess that means it is rts8852 based. Right? > > I had to adjust just a few registers which -I think- regard the scanner. > But I had to change quite a lot of registers for the motor. The registers > 0xe0 - 0xef are described in lexmark_low.c as "motor curve stuff". When I > used register settings that all the other Lexmark models use the scanner > head wouldn't start moving. So I used register settings for 0xe0-0xef I > found by a whole page scan sniff in Windows. Could somebody explain to me > how these registers work ? > Especially: How universal are they. Can I just sniff the windows driver for > all the different resolutions (75, 150, 300, 600) dpi for the two modes > (gray, colour)? There is also a scanner mode where just the scanner head > is moving with no light, must this have different motor curve settings ? > > best regards, > Torsten Hello, unfortunately, there is no datasheet for rts8852 ASIC. So the meaning of each register has to be guessed from its usage in USB logs. Comparing values for scans at different resolutions is the right thing to do. Sometimes we can't have enough different values to figure out precisely the meaning of registers. For different models supported in the lexmark backend, there are different sensors and motors. So usually settings are shared if 2 models have the same motor. Light on/off shouldn't influence motor settings. However maybe when doing head parking, the light is turned off and the motor set for an higher cruising speed since there is no need to gather data from sensor. Regards, Stef
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de
Le Monday 01 November 2010 12:47:27 m. allan noah, vous avez ?crit :
> I disagree with this commit. Perhaps we need to change what is
> printed, but I don't think we should hide them.
>
> allan
>
> On Mon, Nov 1, 2010 at 2:34 AM, St?phane Voltz wrote:
> > The following commit has been merged in the master branch:
> > commit 27c7eae2b59385fec7228f6bec65fbcc649637a3
> > Author: St?phane Voltz
> > Date: Sat Oct 30 16:23:17 2010 +0200
> >
> >don't print readonly controls as valid command line options
> >
> > diff --git a/frontend/scanimage.c b/frontend/scanimage.c
> > index 8657a72..7a24ea1 100644
> > --- a/frontend/scanimage.c
> > +++ b/frontend/scanimage.c
> > @@ -2141,7 +2141,8 @@ Parameters are separated by a blank from
> > single-character options (e.g.\n\ if (!opt)
> >opt = sane_get_option_descriptor (device, i);
> >
> > - print_option (device, i, opt);
> > + if (SANE_OPTION_IS_SETTABLE
> > (opt->cap)||opt->type==SANE_TYPE_GROUP) + print_option
> > (device, i, opt);
> >}
> > if (num_dev_options)
> >fputc ('\n', stdout);
> >
> > --
> > SANE backends - scanner drivers
> >
> > ___
> > sane-commit mailing list
> > sane-commit at lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/sane-commit
Hello,
I can change it if you want. What I don't see is what would be the
purpose of printing these 'read-only' options with the --help argument, if we
cannot use them on command line. The fetch_options() functions skip them, so
scanimage can't make use of it.
Maybe a -Q/--query argument could print out everything the backend
exposes for diagnostics purpose, which is different from what can be used by
scanimage in a script.
Regards,
Stef
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de
Le Monday 01 November 2010 14:51:59 m. allan noah, vous avez ?crit : > We need a way for authors of button handling programs to figure out > what sensors a scanner exposes. Yes, they can use libsane to query the > options, but then a third user would have to install the button > daemon, just to find out if there are any sensors. I'd rather that > scanimage could tell us. > > We have several options- improve the 'read only' text, change > fetch_options() to print an improved warning if the user tries to set > those options, or your suggestion of hiding them unless an arg is > given. I would pick something other than '--query', but any of these > choices is fine with me. > > Opinions? > > allan Hello, I think there are different points to answer. First there is a bug to fix: the --help argument (which is geared to scanimage command line usage) shouldn't print command line options that cannot be used. Second listing all the options a backend provides including buttons is useful. It will better served with a specific argument (--list-options / -- list-buttons / --show-options ?). I'll submit a patch that brings such an argument for everyone to review. Regards, Stef
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de
Le Monday 01 November 2010 15:48:28 m. allan noah, vous avez ?crit : ... > >> allan > > > >Hello, > > > >I think there are different points to answer. First there is a bug > > to fix: the --help argument (which is geared to scanimage command line > > usage) shouldn't print command line options that cannot be used. > >Second listing all the options a backend provides including > > buttons is useful. It will better served with a specific argument > > (--list-options / -- list-buttons / --show-options ?). I'll submit a > > patch that brings such an argument for everyone to review. > > how about --all-options? > > allan Hello, here is a try at adding --all-options to scanimage . I'm looking forward to comment or suggestion. Regards, Stef -- next part -- A non-text attachment was scrubbed... Name: proposal.patch Type: text/x-patch Size: 3787 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101101/f3eeabac/attachment.bin>
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de
Le Tuesday 02 November 2010 03:57:40 Olaf Meeuwissen, vous avez ?crit : > On 2010?11?02? 09:58, m. allan noah wrote: > > On Mon, Nov 1, 2010 at 8:53 PM, Olaf Meeuwissen wrote: > >> On 2010?11?01? 23:45, stef wrote: > >>> Le Monday 01 November 2010 14:51:59 m. allan noah, vous avez ?crit : > >>>> We need a way for authors of button handling programs to figure out > >>>> what sensors a scanner exposes. Yes, they can use libsane to query the > >>>> options, but then a third user would have to install the button > >>>> daemon, just to find out if there are any sensors. I'd rather that > >>>> scanimage could tell us. > >> > >> Not sure I understand the scenario you have in mind. Care to explain? > >> > >> Within that scenario: > >> - How would one use scanimage to figure out what sensors a scanner > >> exposes? > > > > In this case- scanimage --all-options > > This produces output similar to --help. You said "we need a way for > authors of button handling programs to figure out what sensor a scanner > exposes". Apart from the fact that one doesn't know what to look for, > parsing the --all-options output is not exactly my idea of a stable API. > > >> - How would one use libsane to do that for that matter? > > > > get options and check the CAP bits. > > The problem here is that there is no combination of CAP bits that > unambiguously identifies all sensors (and only all sensors). > > >> - Why would a button handling program need a button daemon to find out > >> > >> if there are any sensors when using libsane if scanimage can do the same > >> thing using libsane without that button daemon? > > > > It does not- but as I said above- the third party end user might like > > to know if his scanner exposes sensors BEFORE he installs the button > > daemon. We have no other program installed as part of sane-backends > > which can do this. > > # I saw your follow-up on this. > > You could make it a separate utility, similar to sane-find-scanner or > gamma4scanimage. My point is that maybe this sensor listing stuff just > isn't a task for a program that was meant to "scan an image". By your > reasoning, everything one might want to do with a scanner should be > added to scanimage. Not saying that is wrong, just that it's debatable. > > Back to my original question though, what "sixth sense" does scanimage > have that would require the help of a button daemon for a button > handling program that uses libsane to query the options in order to > determine the sensors a scanner exposes? I can't think of one. > > BTW, if a backend exposes sensors, it would be natural to provide a > button daemon (and handler?) together with that backend and install both. > > >> - How does this relate to button handling for non-button sensors such > >> > >> as, for example, a paper tray empty sensor? > > > > A sensor is a sensor, regardless of type- look at the fujitsu, > > canon_dr, genesys backends. > > I had a quick look at part of the code of the backends you mentioned as > well as some other sensor/button related bits. I realized that part of > my confusion stems from the fact that I mixed up the SANE_TYPE_BUTTON > with the device's buttons. Thinking of the latter as push sensors made > things clearer (if you also call button daemons sensor monitors and > button handling programs event handlers). > > Hope this helps, Hello, I agree that things would be cleaner with a separate utility so that scanimage focus would only be scanning. Currently scanimage already extends beyond that role with the -T/--test option. The proposed patch is a short term solution while separating test and probe functions to a separate program is a longer term goal. Regards, Stef
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de
Le Thursday 04 November 2010 15:06:15 m. allan noah, vous avez ?crit : > This patch looks fine to me- Though I would say 'All options' instead > of 'All SANE options'. > > allan > Hello, ok, I'll change that. I think I'll commit this by next monday with the according man page change. Regards, Stef
[sane-devel] Possible bug in canon backend or scanimage
Le Thursday 04 November 2010 14:57:05 Myroslav Kavatsyuk, vous avez ?crit : > Hello, > > Just recently I bought CanoScan 2700F film scanner (SCSI, canon ackend). > It works fine with the xsane/xscanimage frontends. However, I have troubles > to make it working with the scanimage frontend. Namely, I can not path > some scanner-specific options (--af, --afonce, --highlight). > > According to the manual this options are there: > >scanimage -d canon:/dev/sg2 -h > > >--highlight 0..255 [255] > Selects what radiance level should be considered "white". > Focus: > --af[=(yes|no)] [yes] > Enable/disable auto focus > --afonce[=(yes|no)] [yes] > Do auto focus only once between ejects > > When I execute > > >scanimage -d canon:/dev/sg2 --resolution 2720 --film-type Slides > >--highlight 150 > out.pnm > > I get the error message: > > scanimage: unrecognised option --highlight > > I have checked the source code of the canon backend and I can not see gross > mistakes. Moreover I can control these options with the xsane GUI. > > Please give me a hint where should I look to find a solution of the > problem. > > Thank you in advance, > Best regards, > Myroslav Hello, I am quite puzzled since I can't see this error message in scanimage source code. Doing a " grep -r recognised * " on all SANE sources show no such message. What am I missing ? Regards, Stef
[sane-devel] Possible bug in canon backend or scanimage
Le Thursday 04 November 2010 22:01:48 m. allan noah, vous avez ?crit : > try American English- unrecognized > > allan > > On Thu, Nov 4, 2010 at 4:53 PM, stef wrote: > > Le Thursday 04 November 2010 14:57:05 Myroslav Kavatsyuk, vous avez ?crit : Indeed, it is much better that way. This message is printed by getopt_long in scanimage. I see no other option than debugging scanimage. Especially look at the fetch_options() () which builds the list of usable options in the all_options global var. The SANE_OPTION_IS_SETTABLE test is a good place for a breakpoint. This global var is used later by getopt_long() to check command lines arguments. Regards, Stef
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de
Le Thursday 04 November 2010 20:05:00 stef, vous avez ?crit : > Le Thursday 04 November 2010 15:06:15 m. allan noah, vous avez ?crit : > > This patch looks fine to me- Though I would say 'All options' instead > > of 'All SANE options'. > > > > allan > > Hello, > > ok, I'll change that. I think I'll commit this by next monday with the > according man page change. > > Regards, > Stef > Hello, in fact I have just pushed it. I will modify it if further changes are needed. Regards, Stef
[sane-devel] Possible bug in canon backend or > scanimage
Le Monday 08 November 2010 12:54:11 Myroslav Kavatsyuk, vous avez ?crit : > Dear colleagues, > > Thank you for your replies. I find that addition of the --all-options > is a nice idea to improve the user interface. Unfortunately it > does not solve my problem. This weekend I tried to debug sane > to find the source of the error. Just to remind you the problem: > > scanner canoscan 2700F is supposed to have extra options (reported > when using --all-options flag, works with xsane) but this options > are not accessible with a scanimage (reported error > scanimage: unrecognized option '--af=yes') > > As was pointed earlier, the message is coming from the getopt_long > function (frontend/scanimage.c:2094). With my compilation, the glibc > implementation of the getopt_long is used, therefore I could not > debug it. However, I have modified the scanimage.c in a way, to > printout all command-line parameters and the content of > full_optstring and all_options -- parameters of getopt_long > function (frontend/scanimage.c:2094). The output you can see in the > attachment (scanimage.out.highlight and scanimage.out.af). What I do > not like in the output is some (null) option-names in the printed > all_options (see line 29 of scanimage.out.af). This (null) string > is following after the "ae" option, which is still working. > All options below that (null) line do not work. Option group don't have a name, so it's normal you get null for them. I see nothing obvious from the appended files. You can force the build and use of the internal getopt_long by undef'ing HAVE_GETOPT_LONG in include/sane/config.h, so you can really step in it with a debugger. > > Here, just in case, few lines which I added to scanimage.c just before > while loop at the line 2094 to print parameters: > > fprintf(stderr,"Full_options: %s\n",full_optstring); > for(i=0;i fprintf(stderr,"ap: %s\n",all_options[i].name); > > Please let me know your opinion on this "investigation". > > I just noticed that there is active development of the genesys > backend. I have a canoscan 8400F scanner which is build with > the GL843 chip. I would like to help to make backend for this > scanner. Please let me know how can I help you. To check how much it is different, we need a usbsnoop log of a preview done under windows. By processing it with scripts, I can extract the information needed to add it to the gl843 scanners. > I also have a canoscan 3200F scanner, which I would like to > rebuild to a "film" scanner. But before taking it completely > apart I can try to see if we can make it ruining with sane. > In older CVS there was an experimental backend for this scanner. Maybe you could look at it. > Please find attached the output of the sane-find-scanner > utility. > > Best regards, > Myroslav > Regards, Stef
[sane-devel] Canoscan LiDE 700F
te_gl847_register (0x3b, 0x9d) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x01, 0x0091) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x01) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x91) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x02, 0x0032) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x02) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x32) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x03, 0x0004) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x03) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x04) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x04, 0x) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x04) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x00) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x05, 0x) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x05) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x00) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x06, 0x003f) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x06) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x3f) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys] sanei_genesys_fe_write_data (0x07, 0x) > > [genesys] sanei_genesys_write_gl847_register (0x51, 0x07) completed > > [genesys] sanei_genesys_write_gl847_register (0x3a, 0x00) completed > > [genesys] sanei_genesys_write_gl847_register (0x3b, 0x00) completed > > [genesys_gl847] gl847_bulk_write_register: wrote 3 registers > > [genesys] sanei_genesys_fe_write_data: completed > > [genesys_gl847] gl847_set_ad_fe(): end > > [genesys] sanei_genesys_create_gamma_table: size = 256, maximum = > > 65535, gamma_max = 65535, gamma = 1.7 > > [genesys] sanei_genesys_create_gamma_table: completed > > [genesys] sanei_genesys_create_gamma_table: size = 256, maximum = > > 65535, gamma_max = 65535, gamma = 1.7 > > [genesys] sanei_genesys_create_gamma_table: completed > > [genesys] sanei_genesys_create_gamma_table: size = 256, maximum = > > 65535, gamma_max = 65535, gamma = 1.7 > > [genesys] sanei_genesys_create_gamma_table: completed > > [genesys_gl847] gl847_slow_back_home (wait_until_home = 1) > > [genesys] sanei_genesys_read_gl847_register(0x6c)=0xe3 > > [genesys] sanei_genesys_write_gl847_register (0x6c, 0xfb) completed > > [genesys] sanei_genesys_read_gl847_register(0x41)=0xfc > > [genesys_gl847] status=PWRBIT BUFEMPTY FEEDFSH SCANFSH HOMESNR LAMPSTS > > *[genesys] sanei_genesys_read_gl847_register (0x41): failed while > > setting register: Invalid argument* > > [genesys_gl847] gl847_slow_back_home: failed to read home sensor: > > Invalid argument > > scanimage: open of device genesys:libusb:002:008 failed: Invalid argument > > [genesys] sane_exit: start > > [genesys] sane_exit: exit > > So it seems that I've got an issue with the register (0x41 ?). BTW I > cannot find the 0x41 registry in the genesys files. > > So how can I go on ? Do you have any idea ? Do you know where I could > find any technical documentation that I could use to understand what is > going wrong ? > Perhaps would I need to create a specific CIS_CANONLIDE700 but I really > don't know how to handle it... > > Thank you for your answers ! Hello, this is a good start. The 700F may not be a clone of the LiDE 100/200, so some values must be tweaked. To get an idea of the extent of the changes to do, I need an usbsnoop log of a preview done under windows. Regard, Stef
[sane-devel] Possible bug in canon backend or > scanimage
Le Wednesday 10 November 2010 09:55:10, vous avez ?crit : > Dear Stef, > > I did not manage to compile SANE with the internal getopt_long. At > least with my distribution (Ubuntu 10.10) SANE was always built with > the glibc getopt_long and disregarding the definitions in the config.h. > However I modified the fetch_options function (scanimage.c:859) by > adding a line > if(opt->name == NULL) continue; > at 895. After this modification scanimage works as expected, namely > it recognizes all options! May be this is a bug in the glibc > implementation of getopt_long (it stops once it reaches NULL option). > But I would suggest to modify the scanimage.c. Nice debugging. It looks to me it may be a canon backend bug. From reading the code it appears that all options including groups options are set up to SANE_CAP_SOFT_SELECT and SANE_CAP_SOFT_DETECT. While some groups have their cap value correctly set to 0 later, this is not the case for OPT_CALIBRATION_GROUP. The cap should be set to 0 before testing if it is inactive (this is done for other group options). Without that the group is 'settable' with a null name, which causes your problem. OPT_EJECT_GROUP has the same issue. > > Please find attached the usb log file of the canoscan 8400F. > I am not sure if it is complete (the log was recorded while scanner > reset and preview, but during the preview I notice that number > of recorded packets was not changing). Please let me know if you > need more information/tests. My scripts are tuned for this usb snoop program http://www.pcausa.com/Utilities/UsbSnoop/ , so I cannot parse the log you sent. > > The canoscan 3200F I will try during the Christmas holidays. > > Best regards, > Myroslav > Regards, Stef
[sane-devel] X74 a few more questions
Le Thursday 11 November 2010 15:54:33 Torsten Houwaart, vous avez ?crit : > Hi, > > My Lexmark X74 is working nicely now. I can scan at 75, 150, 300 and 600 > dpi, gray or color. > > So now I have a few questions: > > 1. Different home dot. > My X74 has a home dot that is double as wide as for the models that are > already in the lexmark backend. For the other models the home dot is > around 23 bytes at 300 dpi, for my model the width is 100 bytes at 300 dpi > or 1/3''. In the lexmark_low.c there is already this comment: > /* > * all these defines may be move in device specific constant in per model > * struct if we need it > */ > Where should i put this information? Maybe in the Lexmark_Sensor or > Lexmark_Motor class? Or just a struct in lexmark_low.c ? > > 2. Different start line. > From the home dot of the X74 there is a distance of ca. 1/3'' to the actual > scanning area. Quite frankly I find it a bit weird that the other Lexmark > models seem to not have this. So I will put a X74 specific move_fwd before > the actual scan. I will also put this distance in the rewind command. Is > that ok? > > 3. How to commit. > Where should I send my code to? Just attach to an email to this mailing > list? What should I send? The different files or a diff file? > > best regards, > Torsten Houwaart 1. You can add a field in Lexmark_Model for these specific information, or you may create a new struct like you propose. 2. You could add this distance to the new struct/fields so you don't have to duplicate the function. Such differences in the internals of similar scanners is the most common case. 3. About the commit, you can send a patch to the list. Generating it with 'git format-patch' would be perfect. Since you have a lexmark scanner (I don't have one anymore) and are working on the lexmark backend, it would be great if you could step as it's maintainer. It would require to get a login on alioth and be granting access rights to the git tree. Regards, Stef
[sane-devel] Possible bug in canon backend or > scanimage
Le Saturday 13 November 2010 14:12:19 Myroslav Kavatsyuk, vous avez ?crit : > Dear Stef, > > Please find attached log of initialization and preview done > wit the Canoscan 8400F, using correct program. > > What shell we do with the bug in canon backend? Are you > going to fix it, or shell I change the code and send you > corrected version? > > Best regards, > Myroslav > Hello, thanks for the data. I'll have a look at it soon. Since you have to device to test, I think it would be better if you could create a patch for the canon backend. The fix in canon.c to try is to add a line: s->opt[OPT_CALIBRATION_GROUP].cap=SANE_CAP_ADVANCED; and: s->opt[OPT_EJECT_GROUP].cap=SANE_CAP_ADVANCED; before the test for SANE_CAP_INACTIVE. Once you have it working, send the patch to the list so we can apply it. Regards, Stef
[sane-devel] Genesys: raw debug log activated in git & 1.0.21
Le Wednesday 17 November 2010 17:57:26 Julien BLACHE, vous avez ?crit : > Hi, > > Commit ea76aef8a23e3500dd43cb577dc617cb7dce2d0a added > #define SANE_DEBUG_LOG_RAW_DATA 1 > in genesys.c; it looks like this was an oversight when committing the > changes. > > With this activated, genesys leaves a raw.pnm file behind in the current > working directory. It's messy in a production, but more importantly, it > leaves potentially sensitive user data in this file behind the user's > back. > > Can you disable it again in git? I haven't done it myself to avoid a > conflict at your next pull/push. > > For everyone maintaining SANE in a distro or similar environment, check > your builds and disable the raw debug in genesys if your users are using > this backend. > > JB. Hello, thanks for the report. I have changed the logging code to test for debugging level. So the raw.pnm file will be created only when it is needed. Unless SANE_DEBUG_GENESYS envronment var is higher than 7, there will be no log anymore. Regards, Stef
[sane-devel] Anybody working on support for CanoScan LiDE 210 ?
Le Wednesday 17 November 2010 16:28:06 mb9000, vous avez ?crit : > Hello everybody, > > I'm new to this list. > I've got a new CanoScan LiDE 210 and would like to use it with my linux > box. > Unfortunately this model it is currently not supported. Is anybody > working on support for it already? > I don't want to invent the wheel twice... > > Best regards, > Markus B. > > -- > 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 Hello, the LiDE 210 is based on the same ASIC than the Lide 110. I am currently working on LiDE 110 support. It is planned to be finished by mid-december. Adding support for the LiDE 210 will then be quite easy from usb logs I have. Regards, Stef
[sane-devel] hp scanjet 2300c
Le Thursday 18 November 2010 16:21:51 alain lacombe, vous avez ?crit : > le scanner hp scanjet 2300c ne fonctionne plus sous ubuntu 10.10 > > merci de me r?pondre Hello, more information is needed to have an idea of the problem you have. What program are you using to scan ? What are the error messages you have? Does 'sudo scanimage -L' detects your scanner ? Regards, Stef
[sane-devel] patch
Le Tuesday 23 November 2010 02:35:25 ToHo at gmx.de, vous avez ?crit : > Sorry for my mails from toho at gmx.net I sometimes forget to change the > outgoing address. > > I send to you this patch i created with git. > > What works for my X74 with this: > 75 dpi colour, grey (here shading must be done manually) > 150 dpi colour, grey > 300 dpi colour, grey > 600 dpi grey > > > There is a possibility that I made some logical mistake for the other > scanners, although I tried to put a if(scanner==X74) where necessary and > double checked that the switch() instructions I applied didn't change any > registers for the other scanners. > > I will take my files with me. But I won't have my scanner around for the > next few weeks, so I can't test any corrections. > > Best regards, > Torsten Houwaart Hello, I have went through all the deltas. It is a very interesting patch. I think there are a couple of things to polish before committing it. First when compiling I have the following errors: In file included from lexmark_low.c:52: lexmark_models.c:55: warning: missing initializer lexmark_models.c:55: warning: (near initialization for 'model_list[0].HomeEdgePoint2') lexmark_low.c: In function 'sanei_lexmark_low_calibration': lexmark_low.c:5946: warning: ISO C90 forbids mixed declarations and code You should also add your name to the copyright notice for X74 support addition. And last, to fix some indenting deltas, you should run 'indent' on the modified file since this backend is formatted that way. It would a perfect patch if you could find the time to update the man page and lexmark.desc file. Are you considering getting a login on alioth ? Regards, Stef
[sane-devel] Backend for plustek Opticbook 3600
Le Thursday 25 November 2010 19:57:19 Chris Berry, vous avez ?crit : > Hey all, > > Sorry for my absence any of those who were waiting on the support for > this scanner, I had a massive internet problem then started a new job so > things got held back. A quick update to the project: I managed to get > most of the basic functionality together in my test bed, which still > works, unfortunately I've tried a couple of times to add my code into a > current git repository and everytime I do I am not seeing the same results. > > One big part of why I didnt merge straight off the original was that I > was using an IDE to code and it went and screwed all the whitespace up, > so now I have a diff on every line :(. If anyone has any suggestions > about how I should proceed for including this in the git repository i'd > be grateful for advice, as I understand there are a few people around > the world wanting to use this hardware. > > Thanks > > Chris Hello, you might consider running 'indent' on the genesys files before modifications, and on the updated ones. Once formatted the same, you'll only have your work in the 'diff'. Regard, Stef
[sane-devel] CanoScan LiDE 110
Le Thursday 02 December 2010 19:25:44 Thomas De Contes, vous avez ?crit : > Hi :-) > > > I just buy a CanoScan LiDE 110 > http://www.canon.fr/For%5FHome/Product%5FFinder/Scanners/Flatbed/canoscan%5 > Flide%5F110/ > > And it is not listed here : > http://www.sane-project.org/lists/sane-mfgs-cvs.html > > > Can I try the CanoScan LiDE 100 driver instead ? > > > How can I help you to add it to the list of Supported Devices ? > > Does it help you if I send you the content of the CD ROM (for mac os x & > windows) ? Hello, the LiDE 100 and 110 don't use the same ASIC, so the backend needs to be modified. I am currently working on LiDE 110 support. That will be finished this month. Regards, Stef
[sane-devel] SANE2 standard completion
Le Sunday 06 April 2008 21:16:44 m. allan noah, vous avez ?crit?: > On 3/28/08, Rene Rebe wrote: > > > > But before starting, there are some things I'd like to see in > > > > the > > > > new standard: > > > > - the current code flow is > > > > sane_init > > > > sane_open > > > > sane_start > > > > sane_read > > > > sane_cancel > > > > sane_close > > > > sane_exit > > > > > > > > rather than calling sane_cancel at the end of scan, I'd > > > > like to have a sane_end function. Leaving the use of sane_cancel for > > canceling the scan like it allready does. This new function would do > > about > > > > the same, but code flow would be cleaner and easier to understand: > > > > sane_init > > > > sane_open > > > > sane_start > > > > sane_read > > > > sane_end > > > > sane_close > > > > sane_exit > > > > > > this is a simple, single scan case. can you draw up what you think an > > > ADF or duplex scan would look like? right now, it does sane_start, > > > sane_read, sane_start, sane_read, sane_start, sane_read, > > > > I do not see a problem in this call graph. Sure, we could leave the > > cancel (or rename it to _end :-), however existing codebase like > > frontends (applications) have deal with the current API and > > backends (drivers) anyway. This is what I mean when I declare > > unnecessary work. The gain is just a little nicer callgraph on > > the paper. > > actually, i have some code in my private version of fujitsu backend > now, to try and make sane_cancel work properly. and i can say that > stef is right that separating the 'cancel' from 'dont want more > images' would be very nice for ADF programming. without it, i have to > replicate some measure of the 'EOF' sending code into the cancelling > code, so that it can tell if it needs to actually stop the scanner, or > just not start again. > Another case where having a different function for regular end of scan and error path is for the lexmark backend. The X11xx/X12xx devices don't have a sensor to detect home position. Parking position must be find by scanning a white area with a black dot in it. Currently, when sane_cancel is called, the backend doesn't know if scan is finished regularly or aborted, so it parks head slowly, scanning to find the dot because it don't 'know' where the scanning head is. If there were a difference between 'abort' and 'scans are finished', in case of normal end, the backend could just go back by the amount of scanned lines, going back faster. > gentlement (and ladies if there are any), i am in favor of starting a > new sane2 draft, with soversion bump. > > allan > > -- > "The truth is an offense, but not a sin"s, Regards, Stef
[sane-devel] SANE2 standard completion
Le Wednesday 09 April 2008 12:48:22 Ren? Rebe, vous avez ?crit?: > > As the backend controls the device and reads the image data somehow, > it should have knowledge about the actual head position and should be > able to perform the required actions even with the current interface. > > Where exactly should there be the problem? > > Yours, You are right that a backend can count how many times sane_cancel has been called after last sane_start() and that also by knowing if all data planned to be scan has been effectively read, it could sort things. But this a workaround more prone to bugs than to have a function for regular end of scan, and another for error code path. It would also have to be coded again and again into backends needing it. It is cheap to add, is about a one liner for frontends and help us to write better backends. For most backends, adding such a function would simply resolve in renaming sane_cancel to internal_cancel, and have it called by sane_cancel and the new function. Actively maintained backends will be able to take advantage of it. Regards, Stef
[sane-devel] SANE2 standard completion
Le Wednesday 09 April 2008 21:38:26, vous avez ?crit?: > > You are still just arguing around the dancing cow here. > > With a potentially new sane_end whatever function you still would have > to > keep track where the head is. A frontend may still read less data and in > any case you would need to know where the head is to move it that > specific way backwards in such a "CPU-less" "doing every step by > the host" device. > > I can still do not see where another function call to signal a scan_end > would help you. A frontend that reads less data than it required would call sane_cancel(). While I imagine some cases where it may need to do such, frontends will usually get what they asked for, and call sane_end(). It should also be noted that a frontend that don't call it would still work. Regards, Stef
[sane-devel] a wish list for SANE improvements
Hello, since the general mood is improving SANE without breaking everything, here's my wishlist: - more well known-options, with their well-known groups and their capability. Currently similar options show up in slightly different groups, and worse in 'standard' or 'advanced' options, depending on the backend. It gives an inconsistent look and feel to frontends. - two new return code: SANE_STATUS_HARD_LOCK to tell the frontend that the scanner is hard locked, and SANE_STATUS_WARMING_UP to tell that the backend is warming up. These would be optional and wouldn't break any backend. - more SANE_Format. - adding a channels field to SANE_Parameters, it would avoid frontends to test against each SANE_FRAME_* constants to calculate it, as new formats are going to be added. - adding a field to SANE_Device for capability flags. It will default to 0 if not used and would allow backends to signal things such has being to handle buttons, infra-red, ... - a different function from sane_cancel() to call at regular end of scan, which would help backend how to behave at end of scan. - a SANE_TYPE_HARD_BUTTON for scanners' buttons. The constraint field would allow to distinguish between push buttons (0 or 1 )and 'wheel buttons' (0 to N). Some improvements or recommend practices that would help backend maintainer or would be developper to code without having to wonder what should be done: - common debugging levels. currently, each backend keeps on defining debugging levels. And since debugging levels are different from backends to backends, they have to be documented on a backend basis. Having a common way to do it would allow for less coding in backends, document it for once in the general man page. - a common configuration reading function, so we don't have to code the same thing. For a start it would be offered in sanei_* functions so that new or maintained backends can benefit from it. - a recommended (not compulsory) way of naming variables and private functions would be nice. All of this can be done without breaking everything. Regards, Stef ?
[sane-devel] a wish list for SANE improvements
Le Friday 11 April 2008 08:35:35 Alessandro Zummo, vous avez ?crit?: > On Thu, 10 Apr 2008 21:33:50 +0200 > > stef wrote: > > Hello, > > > > since the general mood is improving SANE without breaking everything, > > here's my wishlist: > > While I DO agree on the matter, I haven't noticed the general > mood was that one, otherwise I wouldn't ever started SANE Evolution > > :-) > > Am I wrong? > > -- > > Best regards, > > Alessandro Zummo, > Tower Technologies - Torino, Italy > > http://www.towertech.it Hello, I get this impression from the few persons that expressed their opinions recently. However, some will only tolerate a SANE_FRAME_RGBI and SANE_FRAME_JPEG, others will accept more things. This is why I sent this wishlist. I suppose some items will be rejected, some will be accepted and that other usefull propositions will pop up. But you are right that only a few opinions were expressed, that nothing changed in years, and that things often get discussed endlessly. I'll be on vacation next week, but when I return, I intend providing some patches to help things moving on. Regards, Stef
[sane-devel] About the GL646(_HP) and future release of SANE
Le Sunday 03 February 2008 16:20:50 Tourneur Henry-Nicolas, vous avez ?crit?: > Hello, > > I'm a debian user of SANE and I'v got a hp 3690 scanjet. I saw it uses a > GL646_HP chipset which is included in the genesys backend as an > experimental driver. I would like to know if there is any planed release of > sane which will include some support for this chipset. > > Kind regards. Hello, there is currently no plan to update the genesys backend for the GL646 part. Someone with the hardware has to modify it. In case you feel like trying to do such, there are some informations about doing this at http://stef.dev.free.fr/sane/genesys/index.html You can also aks question to the mailing list. Regards, Stef
[sane-devel] Plustek ST24 - genesys...
Le Monday 25 February 2008 07:58:49 Gerhard Jaeger, vous avez ?crit?: > Hi list, hi Pierre, > > I revived my Plustek ST24 device and tried to make it work > with the genesys backend. I managed to get out some picture, BUT: > > - any resolution != 150dpi results in a picture, that has double > the height of the original > - the "focus" is not given, which means that it seems there's a > slight shift between the color planes > > my question is: could you simply give me some pointers where to > look? Which are the parameters in the set to tweek, for fixing > these issues? > > TIA > Gerhard Hello, for the double height, you may have to play with REG02_HALFSTEP in register index 0x02 (genesys_gl646.c) . for the color issue, I think you may have to tweak the 0, 8, 16 triplet that gives CCD Line-distance correction in pixel in the the plustek_st24_model entry in genesys_devices.c . I started some doc about the backend and some hint on how to improve it at http://stef.dev.free.fr/sane/genesys/index.html Regards, Stef
[sane-devel] Plustek ST24 - genesys...
Le Monday 25 February 2008 16:02:27 Gernot Hassenpflug, vous avez ?crit?: > Hi! Is your code the one in he CVS sane-backends? Or is that someone > else's code (genesys_gl646.c)? I am trying to work with GL843 device > and wonder if I can use your code as a starting point... > > Regards, Gernot Yes, current CVS code. I think you may be interested in the several messages between Guillaume Gastebois and Pierre Willenbrock, all related to the Canon LiDE 90 which is GL842 based. Regards, Stef
[sane-devel] More on Lexmark X1155
Le Wednesday 27 February 2008 05:22:08 cosme maldonado, vous avez ?crit?: > Result on running sane-find-scanner > > # 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. > > # No SCSI scanners found. If you expected something different, make sure > that > # you have loaded a kernel SCSI driver for your SCSI adapter. > > found USB scanner (vendor=0x043d, product=0x007c) at libusb:003:004 > # Your USB scanner was (probably) detected. It may or may not be > supported by > # SANE. Try scanimage -L and read the backend's manpage. > > # Not checking for parallel port scanners. > > # Most Scanners connected to the parallel port or other proprietary ports > # can't be detected by this program. > > # You may want to run this program as root to find all devices. Once you > # found the scanner devices, be sure to adjust access permissions as > # necessary. > > > > Result on running scanimage -L > device `lexmark:libusb:003:004' is a Lexmark X1100 flatbed scanner > > 2008/2/26, cosme maldonado : > > Report in using XSane 0.991 in a Dell Inspiron 6000, Ubuntu Gutsy, and > > The Lexmark X1155. > > > > > > The multifunctional It's detected as Lexmark X1100 By XSane, but the > > Scanner does not work the preview, neither the Scan, the scanning head > > makes the reverse movement for starting the scan and then gets stopped > > making a strong noise. Seems that the scanner is tryng to reverse more > > the scanning head. > > Hello, what is the SANE version you are running on your system ? If it is not SANE 1.0.19, you should try it since it brings many improvement to the lexmark backend. For instance it now handles slightly different model in the X1100 series. Regards, Stef
[sane-devel] SANE 1.1.0 Release discussion
Hello, I think this is a reasonable plan, and I feel like working on it. Regards, Stef
[sane-devel] HP Scanjet 3670
Le Monday 05 May 2008 16:50:36 Markus Kummer, vous avez ?crit?: > It seems that this scanner is still unsupported in sane. > The last entry about this scanner is from 2003. That's why I'm worried > that nobody works on it. > ?I have shortly begun with Programming in C. I have really no good > skills but want to help. Is still somebody working on the > genesys-backend for this scanner? Can I help in some form? > > > Markus Kummer Hello, you may search the archive about mails for HP 2400 support. The answer is the same. Basically, the process is to record USB logs of the scanner working under windows, then process them to extract commands and register settings, then modify the genesys_gl646.c code to handle it the same. There is some documentation at http://stef.dev.free.fr/sane/genesys/index.html . The C code involved is not high, all you'll have to do some modification of existing code. There is allready an device description of the 3670c in genesys_devices.c . To do a quick test, you can uncomment (remove the '#' at the start of the line) the usb id of your scanner in genesys.conf (which is usually located at /etc/sane.d), then try to use it from scanimage. It should be detected and I expect it to fail during warm-up. Regards, Stef
[sane-devel] problems with genesys and MD6228
Le Monday 19 May 2008 18:00:16 Werner Holtfreter, vous avez ?crit?: > Suse10.3 sane-backends1.0.19-0-pm.2 genesys Tevion-scanner MD6228 > > Hello, > > it works, but not perfectly: > > 1. The starting point at the top of page is not constant. It varies >between 0...8 mm. This results in the scanner head to crashing >into the bottom of the scanner. > > 2. If I scan on *medium* resolution, then the scanner head moves in >regular fashion. > >If I scan on *high* resolution, then the scanner head starts to >move forwards normally, then slightly backwards and then forwards >normally again and so on. The result is OK. Is the USB or the PC >too slow? > >If I scan on *low* resolution and black/white for low data rate, >then the scanner head starts to shake and does not move properly! > > All things are independent from the front-end and I have done tests > with Kooka, Xsane and Xscanimage. > > Any ideas? > -- > Viele Gr??e > Werner Holtfreter Hello, could you try to run scanimage with debug logs enabled with the following commands in a shell: export SANE_DEBUG_GENESYS=255 export SANE_DEBUG_GENESYS_GL646=255 scanimage -d genesys >scan.pnm 2>scan.log Then send me the scan.log and also the few other pnm debug files that will be created in the directory where you'll run scanimage. With these I will be able to have an idea of what is going on. BTW, is your model really a MD6228 ? MD5345, MD6228 and MD6471 have the same UBS id, but may be they are slightly different. The model I have is a MD6471. Regards, Stef
[sane-devel] HP Scanjet 3670
Le Monday 19 May 2008 11:18:37 Markus Kummer, vous avez ?crit?: > Am Montag, den 05.05.2008, 21:29 +0200 schrieb stef: ... > Hello > > Thanks for the reply! > I made some USB-logs with USB Snoopy and tried to decode them with the > decode.sh script, but the resulting file is always empty. Is there > something I should do before with the file cause its an windows-file? I > don't believe that I'm using it the wrong way. > > ./decode.sh USBlog.usblog > > The file output is USBlog.usblog.decode but its empty. > > Thanks MK Hello, could place the logs somewhere I can reach ? I'd like to look at them to see if the scripts need some tuning (or fix). Regards, Stef
