Hi,
First of all, i have to apologize for being away from computer since few
days. This was easter days. Happy easter days :D
About proprietary backends. They have to support SANE, but SANE has not
to support those backends. Actually, as Allan said, nothing will be
break. And it's up to the
On Mon, Mar 24, 2008 at 10:13 AM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
First of all, i have to apologize for being away from computer since few
days. This was easter days. Happy easter days :D
About proprietary backends. They have to support SANE, but SANE has not
to support
On Thu, 20 Mar 2008 17:56:35 -0400
m. allan noah kitno455 at gmail.com wrote:
we dont need to contact them to know that. if they cannot handle the
default device name, they will return an error message to the hal
callout, which will not show the device. hence, those users will have
to run a
abel deuring adeuring at gmx.net wrote:
Hi,
That is one step too far -- we should get an agreement about the basic
stuff first ;) But the HAL callout could also mess with dll.conf and
I hope you're not suggesting modifying a config file, because that's a
big no-no. It's not really clear what
?tienne Bersac bersace03 at gmail.com wrote:
Hi,
Right. Considering that HAL currently support usb, scsi and ieee1394, it
makes sens to have a common scanner naming policy :
* USB = backend:libusb:busnum:devnum
* SCSI = backend:devfile
* IEEE1394 = backend:?
Sorry to
On Thu, 20 Mar 2008 20:21:39 +0100
Julien BLACHE jb at jblache.org wrote:
Why? Simply because it's what common sense dictates, and because when
it comes to proprietary backends, you'll find a lot of desktop users
have no other choice than running the Samsung driver or the Brother
driver, to
Alessandro Zummo azummo-lists at towertech.it wrote:
Hi,
btw, do we have a list of proprietary backends and frontends?
Frontends, we don't care, and backends, no, not really. Every other
day we run into some new proprietary shit. Sometimes we find that a
manufacturer developed a GPL backend,
in one mail you say that we cannot use this solution because of
external backends, in this mail, you call them proprietary shit.
what we are talking about will not break those backends, they just
wont work immediately with HAL, just like all the weird PP scanners.
allan
On 3/20/08, Julien
m. allan noah kitno455 at gmail.com wrote:
Hi,
in one mail you say that we cannot use this solution because of
external backends, in this mail, you call them proprietary shit.
Two unrelated things. Proprietary backends are crap, all of them with
no exception.
But fact is, quite a lot of
On Thu, 20 Mar 2008 22:21:30 +0100
Julien BLACHE jb at jblache.org wrote:
what we are talking about will not break those backends, they just
wont work immediately with HAL, just like all the weird PP scanners.
... this point. If the people proposing the HAL integration and stuff
today
On 3/20/08, Alessandro Zummo azummo-lists at towertech.it wrote:
On Thu, 20 Mar 2008 22:21:30 +0100
Julien BLACHE jb at jblache.org wrote:
what we are talking about will not break those backends, they just
wont work immediately with HAL, just like all the weird PP scanners.
Alessandro Zummo azummo-lists at towertech.it wrote:
so we should maybe first list the proprietary backends and
then try to find a contact point for each one of them.
so we can at least check that we are not breaking anything.
Unfortunately there are some backends that aren't maintained
Hi,
i think the best you can do is to require that the backend accept
alternate names for the scanner if it is going to use something other
than the list you gave above.
Sorry, i didn't mean to impose one unique device name, but as you said,
simply require one common naming for supporting HAL
Hello,
a bit off-topic but related: Automated backend activation
On Mar 18 17:48 abel deuring wrote (shortened):
... But the HAL callout could also mess with dll.conf and
enable those backends that fit to a newly detected scanner.
No HAL is needed for automated backend activation.
Only udev
Hi,
Very interesting, thanks goes to SUSE for working for long time on
scanner integration with udev and HAL.
The HAL callout goal would be simply to compute the SANE device name put
it to HAL device property scanner.sane.device_name . This does not need
any SANE call as long as all backends
On Wed, Mar 19, 2008 at 9:38 AM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
Very interesting, thanks goes to SUSE for working for long time on
scanner integration with udev and HAL.
The HAL callout goal would be simply to compute the SANE device name put
it to HAL device property
Hello,
On Mar 19 10:18 m. allan noah wrote (shortened):
... small concerns about this plan: replication of naming code
makes that convention a de facto API, and what about external
backends?
Isn't the worst case when the udev/HAL/whatever magic fails
that there is no nice just works
Hi,
1. a small callout, distributed with hal, which replicates the
sanei_{usb,scsi} device naming logic, and saves this device_name
string back into the hal data structure
2. a bigger callout, distributed with ??, which links to the dll
backend, and takes that device_name string, and does
On 19.03.2008 14:24, Johannes Meixner wrote:
Though this might also be a bit dangerous: The callout should
not touch any backends for devices that are for example
accessible via ethernet.
Could you explain what you mean?
What I mean is that dll.conf entires for backends for network
Hi,
unfortunately, no /dev/sgX name for the device in hal, but we can use
the host/chan/id/lun to get it.
HAL provide itself the /dev/sgX for SCSI in e.g. linux.device_file.
Regards,
?tienne.
Hi,
In january 2007, happened a very good discussion this list about SANE
and HAL wich led to shipping a basic fdi.
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018343.html.
Currently, sane-desc generate a very basic fdi which only badge device
as scanner and add a property
On Tue, Mar 18, 2008 at 10:24 AM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
In january 2007, happened a very good discussion this list about SANE
and HAL wich led to shipping a basic fdi.
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018343.html.
Currently,
Hi,
?
We should encapsulate all HAL/DBus call inside hal backend.
the hal backend will load 'backend', and ask
it for a list of scanners it can find, and somehow pick the one that
goes with the 'udi'.
But how can hal backend filter the device list ? Can we avoid the actual
backend to search
On Tue, Mar 18, 2008 at 11:27 AM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
?
We should encapsulate all HAL/DBus call inside hal backend.
the hal backend will load 'backend', and ask
it for a list of scanners it can find, and somehow pick the one that
goes with the 'udi'.
Hi all,
On 18.03.2008 16:03, m. allan noah wrote:
On Tue, Mar 18, 2008 at 10:24 AM, ?tienne Bersac bersace03 at gmail.com
wrote:
Hi,
In january 2007, happened a very good discussion this list about SANE
and HAL wich led to shipping a basic fdi.
Hi,
I answer both allan and abel in this mail.
we can also add a function like sane_get_device_information to the
Sane API that would return data like USB bus and devices numbers [?]
A HAL callout can then call sane_get_devices, call
sane_get_device_information for each Sane device and can
Hi all,
On 18.03.2008 17:15, ?tienne Bersac wrote:
Hi,
I answer both allan and abel in this mail.
we can also add a function like sane_get_device_information to the
Sane API that would return data like USB bus and devices numbers [?]
A HAL callout can then call sane_get_devices, call
On Tue, Mar 18, 2008 at 12:48 PM, abel deuring adeuring at gmx.net wrote:
Hi all,
On 18.03.2008 17:15, ?tienne Bersac wrote:
Hi,
I answer both allan and abel in this mail.
we can also add a function like sane_get_device_information to the
Sane API that would return data like
Hi,
extending sane_open just a bit to always
support 'libusb:xxx:yyy' or '/dev/sgX' is not an API change, so could
be implemented much sooner, and really only requires changes to the
backends that dont already use those names, which is few.
Right. Considering that HAL currently support usb,
On Tue, Mar 18, 2008 at 2:07 PM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
extending sane_open just a bit to always
support 'libusb:xxx:yyy' or '/dev/sgX' is not an API change, so could
be implemented much sooner, and really only requires changes to the
backends that dont
Hi,
In order to have hotplug, quicker probe, more information about device
and better integration with the desktop, i want to use HAL to detect
scanner.
Quick HAL intro. HAL means hardware abstraction layer. It's a piece of
code running on Linux and *BSD providing high level features over device
On Mon, Mar 17, 2008 at 9:58 AM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
In order to have hotplug, quicker probe, more information about device
and better integration with the desktop, i want to use HAL to detect
scanner.
Quick HAL intro. HAL means hardware abstraction layer.
Hi,
The fdi just need to tell this is a scanner, at least. We may add
extra info like device type, backend, etc. See Abel Deuring fdi
generator.
what does a UDI look like?
This is the one of a QScan scanner :
/org/freedesktop/Hal/devices/usb_device_a53_1000_noserial_if0
* HAL device
* HAL device has a scanner.sane.name string property
each backend does its own thing regarding device naming, so this would
require hal to call out to the backend to get the name.
So this need to provide a function sane_hal_get_device_name(backend,
halctx, udi) ?
Hi,
you may have a chain of backend names. the udi is only useful if each
backend can use it to get enough info from hal to indentify the
scanner. i dont know what hal can provide in that case.
Here is an example of HAL device properties (stripped), you will notify
the scanner namespace added
On Mon, Mar 17, 2008 at 2:36 PM, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
you may have a chain of backend names. the udi is only useful if each
backend can use it to get enough info from hal to indentify the
scanner. i dont know what hal can provide in that case.
Here is an
Hi,
unless you add 'backend' as an argument to the function.
Reread carefully, i talked about adding backend argument along UDI. ;)
most backends could implement the function as returning a
concatenation of 'libusb:', the vendor and device ids.
I guess you talk about bus number and device
On 3/17/08, ?tienne Bersac bersace03 at gmail.com wrote:
Hi,
most backends could implement the function as returning a
concatenation of 'libusb:', the vendor and device ids.
I guess you talk about bus number and device number.
yes- i misspoke, good catch.
the backends that return
38 matches
Mail list logo
