Thanks to the generous help from this list, I now have a kernel SCSI sg
driver patch which provides for binary compatibility of 32 bit x86
applications on AMD64 kernels, when using struct sg_io_hdr with
write()/read() (the ioctl() method already worked).
The preliminary version is here (it still h
Dear Mr. Kuhlmann,
I do not know about your scanner, but scanners do usually not cause
performance issues on the SCSI-bus. I would expect that the effect of this is
more than neglible - you wouldn't feel it. We still use that sparc linux
system with a SCSI scanner, and I have not noticed any imp
abel deuring wrote:
Hi,
>> Good luck in getting every copyright holder (which includes every
>> patch contributor) to agree to the relicensing :)
>
> That's exactly, why I wrote that I don't want to open a discussion ;)
Yeah, I mentioned that as a reference for people wondering why SANE
isn't l
Julien BLACHE wrote:
> abel deuring wrote:
>
>>I don't want to open a discussion about licenses, but IMHO Sane's
>>exception to the GPL encourages cases like this one. I think it
>>would be more reasonable to put sane-backends under the LGPL, which
>
> Good luck in getting every copyright holder
Volker Kuhlmann wrote:
> On Tue 10 Jan 2006 06:58:20 NZDT +1300, abel deuring wrote:
>
>>http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015886.html
>
> Thanks for this link, my ISP routed that particular email to /dev/null.
>
>>No, Dieter is right indeed. Sane backends too use
On Tue 10 Jan 2006 06:58:20 NZDT +1300, abel deuring wrote:
> http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015886.html
Thanks for this link, my ISP routed that particular email to /dev/null.
> No, Dieter is right indeed. Sane backends too use sanei_scsi.c. The
> problems he h
abel deuring wrote:
> I don't want to open a discussion about licenses, but IMHO Sane's
> exception to the GPL encourages cases like this one. I think it
> would be more reasonable to put sane-backends under the LGPL, which
Good luck in getting every copyright holder (which includes every
patch
Volker Kuhlmann wrote:
> Hello Henning,
>>Just to make one thing clear: Vuescan is NOT a SANE frontend. I.e. it
>>does not use any SANE backend. It's a completely independent program
>>with independent scanner drivers.
>
>>It just happens to use a part of the internal low level SANE code
>>(sanei
Hello Henning,
thanks much for your thoughts!
> > 3) xsane is a GUI around sane,
>
> It's a frontend, not really "gui around sane".
>
> >but not a scanning application either,
>
> Come on.
Let's not argue about semantics. While I don't doubt that xsane is a
good program for pushing slider
Henning Meier-Geinitz wrote:
[snip]
>
>
>> but not a scanning application either,
>
> Come on.
In the context of scanning negatives and films using high end scanners
xsane is not scanning application but a toy.
>
>> its results are useless. Take this as a fact which we can debate
>> e
> Err... excuse me? I don't think the amount of money any of the SANE
> developers makes from SANE development justifies any effort on this
> behalf.
I am aware of that, and I wasn't asking the sane developers for any
effort, unless you count brain-picking as effort.
> No, there goes "Vuescan i
Hi Mr. Kuhlmann,
I was the one to bring up the issue with the SPARC workaround, the sane folks
helped me a lot to do the testing and find out that using the "old" interface
made everything work.
And, as a matter of fact, everything on SPARC64 is compiled 32 bit in the user
world. Only the kerne
Hi,
On 2006-01-09 09:54, Volker Kuhlmann wrote:
> 1) sane is an API for scanners which works
> 2) sane is *NOT* a scanning application, i.e. some software which gets
>some scanning work done.
sane-backends is not. Frontends like scanimage, xscanimage and xsane
are.
> 3) xsane is a GUI around
Hi,
> He doesn't want to recompile
> for 64bit because the amount of money he makes from the Linux
> version doesn't justify it.
Err... excuse me? I don't think the amount of money any of the SANE
developers makes from SANE development justifies any effort on this
behalf.
> I can understand yo
> > Most annoying that it doesn't work with SCSI scanners on 64bit machines,
> > something a recompile would fix. Hence my recent question about write()
> > encapsulation in sanei_scsi.c (which no-one replied to :( ).
> If somebody else needs such a special handling because of the
> binary-only na
15 matches
Mail list logo
