[sane-devel] official ZETA port diffs

[François Revol]

> > I'm sending the diffs against sane-backends-1.0.15 for the sane 
> > port we
> > use in ZETA, which is based on the BeSANE port from intuiware, and
> > subsequent work from yellowTAB (usb support, ...).
> 
> Thanks for your work. Please also have a look on our platforms page:
> http://www.sane-project.org/sane-support.html
> Is the information about BeOS / Zeta still correct? If no, what 
> should
> be changed?

Seems so.
Note BeOS doesn't have the usb_scanner driver by default, so it must be 
installed.
Zeta has it, as well as the headers.

I also sent the diffs to the BeSANE maintainer, 
Philippe Houdoin <philippe dot houdoin at free dot fr>.

> 
> > Parts of it are of general interest, like checks for header files, 
> > and
> > the removal of libusb dependancy in the sm3600 backend.
> 
> Have you (or anyone else) tested the sm3600 backend with sanei_usb? I
> would really like to remove its dependence on libusb.

Yes, someone brought one once at a user meeting, that's why I had to do 
that because we don't have libusb.
I was able to scan, so I suppose it works, didn't test it much though, 
and I heard its PSU broke since then.

> > - we don't have a libusb port, and I had a sm3600 around, so I 
> > ported
> >   the backend over to sanei 
> > (was it some kind of foreign code not fully ported ??),
> 
> When it was included into sane, SANE did not support libusb via
> sanei_usb yet. 

I see, makes sense.

> > +++ sane/backend/sm3600-scanusb.c	Wed Apr 13 18:03:04 2005
> > +++ sane/backend/sm3600.c	Wed Apr 13 18:03:05 2005
> 
> Not applied. Let's see if anyone can test this with a real scanner
> using sanei_usb.

As I said, it worked for me, but it's better to have others test it, 
though I didn't remove the libusb code there... 
(so if you test, make sure you don't configure with libusb 
or force it off).

> > -#include "../include/sys/types.h"
> > +#include <sys/types.h>
> 
> Applied. I'm surprised that nobody noticed that and that it works at
> all.

You tell me :)

> > +++ sane/include/sane/config.h.in	Tue Feb 15 20:52:31 2005
> 
> config.h.in is autogenerated by autoheader. If you need anything that
> is not generated from configure.in (like the #ifdef), you must add it
> to configure.in manually (look for "AH_BOTTOM").

That seems like old code from BeSANE (which was quite hacky).
maybe it goes to AC_CHECK_HEADERS, but I don't know which files it's 
needed for.
Or isn't there a globaly included .h anyway...

> > +++ sane/lib/Makefile.in	Thu Feb  3 17:21:37 2005
> > +++ sane/lib/getpass.c	Thu Feb  3 17:22:28 2005
> 
> Not applied. The license of that file looks a bit strange and I don't
> want to add yet another license to SANE (GPL, SANE exception, LGPL,
> JPEG license for now).

Hmm yeah, I have a getpass in an external libmoreposix of mine anyway, 
and it should get into Zeta's libroot at some point anyway.

> Let's see if there is a LGPL file for that or if something else can 
> be
> used for getpass. At least on Linux, it's marked as "obsolete" in the
> man page.

Hmm right...
http://www.die.net/doc/linux/man/man3/getpass.3.html
but it doesn't give something to use instead.
getpassphrase() isn't much better...

I have this in libmoreposix, quite ugly but works, though it doesn't 
check for a tty on stdin, but we don't have /dev/tty in beos anyway:

/* NOT threadsafe */
static char getpass_buff[258];

char *getpass(const char *prompt)
{
	struct termios tios;
	char *ptr;

	if (prompt)
		printf("%s", prompt);
	if (ioctl(0, TCGETA, &tios) < B_OK)
		return NULL;
	tios.c_lflag &= (~ECHO);
	if (ioctl(0, TCSETA, &tios) < B_OK)
		return NULL;
	ptr = gets(getpass_buff);
	tios.c_lflag |= ECHO;
	if (ioctl(0, TCSETA, &tios) < B_OK)
		return NULL;
	return ptr;
}

char *getpassphrase(const char *prompt)
{
	return getpass(prompt);
}

> > +++ sane/sanei/sanei_scsi.c	Tue Jul  5 16:06:25 2005
> 
> Not applied because I don't like this:
> 
> > +#ifndef __BEOS__ // nuke all code, replace by BeOS code at the end 
> > of file
> >  #if USE == DOMAINOS_INTERFACE
> 
> This is easy for you but not for the next one who wants to add a new
> operating system. Therefore there is the "USE" system.

Agreed, I didn't like it either, but it's again old BeSANE code which 
should be cleaned up. I leave that to the maintainer :)


Thx for comments,
François.