Hello,
On Feb 24 20:06 Oliver Rauch wrote (shortened):
May be we need an additional flag to the existing ADVANCED flag, may be
a CONFIGURE flag. This way the backend would define what the user can
select and we already would have a configuration tool: the frontend.
The backend could save the
Hello,
On Feb 24 17:25 Julien BLACHE wrote (shortened):
Johannes Meixner jsm...@suse.de wrote:
For the remaining backends which still need config files
it would be good to have a common config file syntax which
supports to change them in a safe way by software tools.
Sure, but let's
m. allan noah an...@pfeiffer.edu wrote:
In this case, the product ID will differ between the 2 hardwares (if
they're totally different, at least), or we can hope so. (talking of
USB here, as for everything else there's really no means to guess)
no, you hope for too much. there are cases
Johannes Meixner jsm...@suse.de wrote:
As far as I understand you:
On the one hand
you said that users don't want to bother with config tools
and then I assume you even more want that users should't need
to bother with reading man pages and editing config files manually.
On the other hand
the problem with this is that doing the config as non-root would mean the
backend would need elevated permissions in order to write its config out
into /etc/...
if the user is willing to run the front-end the first time as root, and
then the backend saves the config changes, that might be ok.
Hello,
On Feb 25 09:16 m. allan noah wrote (shortened):
the problem with this is that doing the config as non-root would mean the
backend would need elevated permissions in order to write its config out into
/etc/...
if the user is willing to run the front-end the first time as root, and
On Fri, 25 Feb 2005, Johannes Meixner wrote:
Hello,
On Feb 25 09:16 m. allan noah wrote (shortened):
the problem with this is that doing the config as non-root would mean the
backend would need elevated permissions in order to write its config out into
/etc/...
if the user is willing to
Hello,
On Feb 25 09:52 m. allan noah wrote (shortened):
i think we want to hide the config file concept from the user
if possible, rather than require someone to change the perms.
It is not required to change any permission.
The default that only root can write to backend.conf is
perfectly
On Fri, 25 Feb 2005, Johannes Meixner wrote:
Hello,
On Feb 25 09:52 m. allan noah wrote (shortened):
i think we want to hide the config file concept from the user
if possible, rather than require someone to change the perms.
It is not required to change any permission.
The default that
Am Fre, 2005-02-25 um 18.12 schrieb m. allan noah:
the only problem i see with this is that some backends can do scsi and
usb, and need that set in the config file, before the backend will find
the scanner and present it to the front-end for configuration. so you have
a chicken and egg
On Wednesday 23 February 2005 22:37, Oliver Rauch wrote:
=20
but you give no reasons why! you just repeatedly say we are doing wrong=
=2E=20
that is not constructive.
=20
yes, what the vendors do is odd and divergent from the normal sane=20
installation (suse's insistence on resmgr comes
Gerhard Jaeger gerh...@gjaeger.de wrote:
In the end, we need an easy to use AND handle way to unify the scanner
descriptions and to give the distri guys the possibility to create
tools for configuration:
Ok, so, as a distri guy, I disagree with this.
I agree with Oliver, in that there's no
Hello,
On Feb 24 08:49 Gerhard Jaeger wrote (shortened):
the intention was, that sane should work out of the box, BUT in fact it
doesn't anymore. We really have too much different config-entries, which
need to be tweaked.
I am sure it will become worse.
The more popular Linux becomes the more
Hello,
On Feb 24 12:17 Julien BLACHE wrote (shortened):
there's no need for config files tweaking by the user
If this is true, why are there so many config files?
for some backends, it's not possible to get rid of the
config file
How should such a scanner be set up when you neither want
a
Hello,
On Feb 24 16:17 Julien BLACHE wrote (shortened):
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Of course!
I fully agree to get rid of stuff which is in fact not needed.
Nevertheless:
For the
Johannes Meixner jsm...@suse.de wrote:
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Of course!
I fully agree to get rid of stuff which is in fact not needed.
Nevertheless:
For the remaining backends
On Thu, 24 Feb 2005, Julien BLACHE wrote:
Johannes Meixner jsm...@suse.de wrote:
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Of course!
I fully agree to get rid of stuff which is in fact not needed.
On Thu, 24 Feb 2005, Julien BLACHE wrote:
m. allan noah an...@pfeiffer.edu wrote:
let me ask this: how many of the config files that must be kept are
kept because they have scanner-specific information in them, as
opposed to backend-specific information?
ie: how many times does a conf file
Hello.
I think there will be a possibility that the backend finds out what
scanner model talks to in almost all cases. Of course it is hard work to
find out what registers behave different to identify the models. But I
am pretty sure that in most cases it is possible for the backend to
identify
On Thu, 24 Feb 2005, Oliver Rauch wrote:
Hello.
I think there will be a possibility that the backend finds out what
scanner model talks to in almost all cases. Of course it is hard work to
find out what registers behave different to identify the models. But I
am pretty sure that in most
m. allan noah an...@pfeiffer.edu wrote:
Don't you think that at least item 1 and 2 can be detected by the
backend ?
yes for #1, no for #2 and #3. since some times the same 'model' is
actually 2 different pieces of hardware. but, i am not familiar with
every single backend, so i dont know
On Thu, 24 Feb 2005, Julien BLACHE wrote:
m. allan noah an...@pfeiffer.edu wrote:
Don't you think that at least item 1 and 2 can be detected by the
backend ?
yes for #1, no for #2 and #3. since some times the same 'model' is
actually 2 different pieces of hardware. but, i am not familiar
Johannes Meixner jsm...@suse.de writes:
On Feb 22 17:23 Gerhard Jaeger wrote (shortened):
On Tuesday 22 February 2005 16:21, Johannes Meixner wrote:
Perhaps it is possible to misuse the PPD file syntax for scanner
setup as well.
You are right, but I don't like the idea to misuse
Hello,
On Feb 23 10:34 Olaf Meeuwissen wrote (shortened):
What you are suggesting here sounds quite a bit to the way foomatic
handles printers.
- an XML database
- a few utilities to crank out PPD files
- one utility to glue the PPDs, the spooler and the printer drivers
together
Hello all,
hello Till,
I don't know if you followed the Infrared channel thread.
Now I include you explicitely because I think we have come
to a point where I would like to have you informed.
I don't know who is the scanner-stuff maintainer at Red Hat.
The Infrared channel thread has changed to
On Wed, 23 Feb 2005, Till Kamppeter wrote:
I think, the best is if the backend can spit out this data. Then there can
never happen that the database and the actually installed backends differ
from each other.
unfortunately, scanners often work in a fashion similar to printers, the
model
Hello,
On Feb 23 15:14 Till Kamppeter wrote (shortened):
I think, the best is if the backend can spit out this data. Then there can
never happen that the database and the actually installed backends differ from
each other.
Yes, this would be best.
In SANE one has at least only one driver
Hello,
On Feb 23 10:05 m. allan noah wrote (shortened):
On Wed, 23 Feb 2005, Till Kamppeter wrote:
I think, the best is if the backend can spit out this data. Then there can
never happen that the database and the actually installed backends differ
from each other.
unfortunately,
Hello.
I do not understand the discussion about the sane config file format.
In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to
Hello.
I do not understand the discussion about the sane config file format.
In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to
Hello.
I do not understand the discussion about the sane config file format.
In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to
most respectfully oliver, i disagree. perhaps your points about scanner
damage, etc are true in your backend because of models of scanners that
you support, but for my backend, it is far more likely that there is an
odd variation on the scanner that the backend does not know about, but
works
Am Mit, 2005-02-23 um 20.59 schrieb m. allan noah:
most respectfully oliver, i disagree. perhaps your points about scanner
damage, etc are true in your backend because of models of scanners that
you support, but for my backend, it is far more likely that there is an
odd variation on the
On Wed, 23 Feb 2005, Oliver Rauch wrote:
Am Mit, 2005-02-23 um 20.59 schrieb m. allan noah:
most respectfully oliver, i disagree. perhaps your points about scanner
damage, etc are true in your backend because of models of scanners that
you support, but for my backend, it is far more likely
but you give no reasons why! you just repeatedly say we are doing wrong.
that is not constructive.
yes, what the vendors do is odd and divergent from the normal sane
installation (suse's insistence on resmgr comes to mind) but if you admit
that there is a 'bad situation', the how about
--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 23, 2005 at 08:36:44PM +0100, Oliver Rauch wrote:
It is dangerous when a setup program or an unexperienced user is
changing the config file. For
Hi,
On Monday 21 February 2005 00:09, Michal Jaegermann wrote:
Yes, I have seen a rather short Sane does not support the dust
removal with the Perfection 4870 here:
http://lists.alioth.debian.org/pipermail/sane-devel/2004-September/012111.html
But does somebody at least have some idea
Hi,
Gerhard Jaeger wrote:
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a
On Tuesday 22 February 2005 09:26, Rene Rebe wrote:
Hi,
Gerhard Jaeger wrote:
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a
- starting SANE 2 with, let's say 2 or three backends (in the end your Avision
stuff, my Plustek backends (plustek, plustek_pp and u12, maybe some other
VOLUNTEERS - hell lot of work to do ;)
I've been suggesting that for months. As soon as a simple SANE2
front-end (scanimage) is
Hi,
Major A wrote:
- starting SANE 2 with, let's say 2 or three backends (in the end your Avision
stuff, my Plustek backends (plustek, plustek_pp and u12, maybe some other
VOLUNTEERS - hell lot of work to do ;)
I've been suggesting that for months. As soon as a simple SANE2
On Tue, 2005-02-22 at 09:26 +0100, Rene Rebe wrote:
Hi,
=20
Gerhard Jaeger wrote:
=20
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend=
.
=20
The solution (whenever we can start) is SANE 2 where we
On Tuesday 22 February 2005 11:54, gerard klaver wrote:
On Tue, 2005-02-22 at 09:26 +0100, Rene Rebe wrote:
Hi,
Gerhard Jaeger wrote:
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more
flexible
approach for transmitting image data to a frontend.
It might also be
Hello,
On Feb 22 09:16 m. allan noah wrote (shortened):
i would like to see a few things done in the sane2 standard:
...
3. more consistent config file interface for all backends
I would appreciate this very much.
At the moment all what the Suse scanner config tool does is:
a) show a list of
On Tuesday 22 February 2005 16:21, Johannes Meixner wrote:
[SNIPSNAP]
Therefore it is normally not possible to determine the matching
backend from the autodetected model string.
I think we should discuss about an enhanced *.desc file format
to specify autodetected model strings and model
On Feb 22 09:16 m. allan noah wrote (shortened):
i would like to see a few things done in the sane2 standard:
...
3. more consistent config file interface for all backends
I would appreciate this very much.
At the moment all what the Suse scanner config tool does is:
a) show a list of
Hello,
On Feb 22 17:23 Gerhard Jaeger wrote (shortened):
On Tuesday 22 February 2005 16:21, Johannes Meixner wrote:
Perhaps it is possible to misuse the PPD file syntax for scanner
setup as well.
You are right, but I don't like the idea to misuse something,
especially it has a spec
i would like to see a few things done in the sane2 standard:
3. more consistent config file interface for all backends
I would appreciate this very much.
At the moment all what the Suse scanner config tool does is:
a) show a list of model names made from the *.desc files
b) let the user
Hello,
On Feb 22 11:29 m. allan noah wrote (shortened):
At the moment it is simply ignored when particular models require
special settings in backend.conf
unfortunately, this can be difficult to deal with, since what
each model needs can vary drastically. cheaper models that require
On Tue, Feb 22, 2005 at 08:28:18AM +0100, Gerhard Jaeger wrote:
On Monday 21 February 2005 00:09, Michal Jaegermann wrote:
But does somebody at least have some idea how to read an infrared
channel?
the problem is our SANE 1 standard, which defines the image format.
We have currently
Yes, I have seen a rather short Sane does not support the dust
removal with the Perfection 4870 here:
http://lists.alioth.debian.org/pipermail/sane-devel/2004-September/012111.html
But does somebody at least have some idea how to read an infrared
channel? It looks that quite a number of
52 matches
Mail list logo
