[sane-devel] Proposal: Change of the backend and model status strings

2003-06-07 Thread Henning Meier-Geinitz
Hi,

On Fri, Jun 06, 2003 at 08:18:54PM +0200, Henning Meier-Geinitz wrote:
> There has been some criticism of the current handling of the :status
> keywords in the .desc files. These filse are used to create our lists
> of scanners and the output of the scanner search engine.

Ok. I wrote some more code and this is the result:

http://www.meier-geinitz.de/sane/tmp/sane-mfgs.html
http://www.meier-geinitz.de/sane/tmp/sane-backends.html

I've changed the mustek backend settings for demondtsrion, so you may
want to have a look at those.

Tha status of the backend isn't used anymore. If a backend is no
longer maintained, we just set the version to "UNMAINTAINED". See the
mustek backend for an example.

The status of the devices is set by the :status keyword. The menauings
are explained in the legend.

The code of sane-desc.c translates the old alpha, beta and stable
codes like this:

alpha:  basic
beta:   good
stable: good

I think that reflects the current usage best. When sane-desc.c is in
CVS, the backends should be moved to the new system. But until this
has been done, the list can be generated using the old status vaules
(with warnings). The backend status is still used if there is no
device status.

Please check (also for spelling).

The only problem I see is that the scanner search engine code must be
rewritten. The ascii output of sane-desc doesn't print the backend
status anymore. The device status uses the new values. If a devic
estatus is not available, the backend status is used.

Bye,
  Henning


[sane-devel] error in linux/videodev.h

2003-06-07 Thread Henning Meier-Geinitz
Hi,

On Sat, Jun 07, 2003 at 05:43:45PM +0200, Thomas Soumarmon wrote:
> I have a problem compiling v4l because of the linux/videodev.h.
> Has anybody already had this problem with this file ?

No, but I haven't installed Video for Linux version 2 (the header is
from version 2).

> Follows the errors :
> 
> In file included from /usr/include/linux/videodev.h:14,
>  from v4l.c:76:
> /usr/include/linux/videodev2.h:432: parse error before "v4l2_std_id"
> /usr/include/linux/videodev2.h:432: ISO C forbids data definition with no 
> type 
> or storage class

Maybe that's the result over our pedantic warning settings. Try with
"--disable-warnings". Looks like the header file is not ISO
C-conforming (for whatever version of ISO-C).

Where did you get videodev2.h from? Is it from your version of libc
(which one)? Or is /usr/include/linux a link to
/usr/src/linux/include/linux and you have installed a 2.5 kernel?

We'll have to think about supporting v4l version 2 anyway. There is an
old v4l2 backend, but nobody yet responded to the question if v4l2 is
the same as the new version 2 kernel interface.

Bye,
  Henning


[sane-devel] error in linux/videodev.h

2003-06-07 Thread Thomas Soumarmon
Hi, 

I have a problem compiling v4l because of the linux/videodev.h.
Has anybody already had this problem with this file ?

Follows the errors :

In file included from /usr/include/linux/videodev.h:14,
 from v4l.c:76:
/usr/include/linux/videodev2.h:432: parse error before "v4l2_std_id"
/usr/include/linux/videodev2.h:432: ISO C forbids data definition with no type 
or storage class
/usr/include/linux/videodev2.h:500: parse error before "v4l2_std_id"
/usr/include/linux/videodev2.h:505: parse error before '}' token
/usr/include/linux/videodev2.h:518: parse error before "v4l2_std_id"
/usr/include/linux/videodev2.h:521: parse error before '}' token
/usr/include/linux/videodev2.h:555: parse error before "v4l2_std_id"
/usr/include/linux/videodev2.h:557: parse error before '}' token
v4l.c: In function `sane_v4l_exit':


Thank you for any help,


Thomas.


[sane-devel] Please test: changed handling of list of backends

2003-06-07 Thread Thomas Soumarmon
Hi,

I tested it with BACKENDS="hp5400" and it works great. It is nice to be able 
to compile only one backend without changing Makefile.in.

I still have a problem compiling linux/videodev.h that prevents me from 
compiling v4l. I send another mail to talk about it.




[sane-devel] Proposal: Change of the backend and model status strings

2003-06-07 Thread Henning Meier-Geinitz
Hi,

On Sat, Jun 07, 2003 at 01:46:55AM +0100, david stevenson wrote:

[backend status]
> Many backends support several scanners, and may be "supported" for most and 
> under "development" for some. 
> Is unmaintained and supported enough without the 3rd option?

I think so, yes. So a boolean flag ":maintained" would be enough.

[model status]
> I do not like the word "perfect" it implies totally bug free and not 
> improvable, would "complete" be more suitable.

Ok.

Bye,
  Henning


[sane-devel] Timeouts with UHCI and gt68xx based scanners in sane-backends 1.0.12

2003-06-07 Thread Michael Fleming
On Fri, Jun 06, 2003 at 01:46:56PM +0200, Henning Meier-Geinitz waffled thusly:
> Hi,
> 
> On Fri, Jun 06, 2003 at 09:16:05PM +1000, Michael Fleming wrote:
> > I can confirm it now works with my Genius ColorPage Vivid 3XE (USB)
> > using libusb 0.1.6 and sane-backends 1.0.12 (on Redhat 9, hand-rolled
> > RPM, current RH errata kernel)
> 
> Thanks for the report. Any problems in color mode? There is a comment
> "Mostly works. Color problems?" on my list for this scanner, but I
> don't know if it's still valid.

Thanks Henning,

I've only run a few samples so far but I've not noted any issues with
the scan result's colours.

I'll run a few more over the course of the weekend and followup if I
note anything interesting or unusual.

My test scan is at
http://www.michaelfleming.webcentral.com.au/carla2.tif (~130K)  if you
want a look. ( It's a cover shot my girlfriend's sister did for a local
magazine)

If I can, I'll have one of my artist friends give me a better idea re:
colour precision - I'm a *little* red/green colourblind which might skew
my judgement a little.

> Bye,
>   Henning

Cheers,
Michael.

-- 
Michael Fleming 
"Bother" said the Borg, "We've assimilated Pooh!"


[sane-devel] Proposal: Change of the backend and model status strings

2003-06-07 Thread david stevenson
Here are 2 personal opinions

On Friday 06 June 2003 7:18 pm, Henning Meier-Geinitz wrote:>
> There has been some criticism of the current handling of the :status
> keywords in the .desc files. These filse are used to create our lists
> of scanners and the output of the scanner search engine.
>
> We currently have two sorts of status indicators:
>
> 1) The backend status: alpha, beta or stable
> 2) The model status: unsupported, untested, alpha, beta or stable
>
>
> Concerning the backends status I think we don't really have the need
> to talk about stability. Crashing backends are rather seldom. So I'm
> not sure if we need this overall status at all anymore. If we want to
> keep it, what about a measurement on how active the backend is
> maintained, e.g.:
>
> unmaintained: There is no maintainer. Only security and other
>   grave bugs will be fixed
> supported:There is a maintainer for the backend. Bugs will be fixed and
>   patches will be accepted.
> development:  The backend is under active development. New features
>   and/or new models may be added.

Many backends support several scanners, and may be "supported" for most and 
under "development" for some. 
Is unmaintained and supported enough without the 3rd option?

> Model status: As proposed by others, I'd like to have a measurement on
> how good a scanner works compared to its capabilities. E.g.:
>
> unsupported:This device is not working at all.
> untested:   The device may work, but nobody has tested it yet.
> minimal:The device is detected and does something but is not
> really usable. E.g. It scans in one mode but colors
>   are off.
> basic:  The device is usable, but some modes are not supported
> or quality is not perfect yet.
> good:   Usable for day-to-day work. Some unusual modes or
> seldomly-used features aren't supported.
> perfect:Everything the scanner can do is supported.
>

I do not like the word "perfect" it implies totally bug free and not 
improvable, would "complete" be more suitable.

>
> Here is an example on how the HTML lists could look like:
>
> http://www.meier-geinitz.de/sane/tmp/sane-mfgs.html#MUSTEK
>
> Only the model status is implemented. And only Mustek SCSi scanners
> have set the values.
>
> Comments?
>
> Bye,
>   Henning
> ___
> Sane-devel mailing list
> sane-de...@www.mostang.com
> http://www.mostang.com/mailman/listinfo/sane-devel