> Hmm, I don't think that's possible; I haven't looked at the SANE sources
> in great detail though; they do have what appears to be some mainloop
> integration bits (sane_get_select_fd() for example) so perhaps that can
> be used. Either way, it's an implementation detail though + people are
> pro
On Tue, 2007-03-20 at 03:17 +0100, Étienne Bersac wrote:
> Hi,
>
> > e.g. it's polling. I don't suppose there's any way to avoid this, it
> > only will happen when the scanner is plugged in and powered on.
>
> How to do without polling in user space ?
Hmm, I don't think that's possible; I haven'
On Mon, 2007-03-19 at 21:58 -0400, David Zeuthen wrote:
> No, device access via libusb is exclusive (as it needs!) so this is not
> possible. One way around this, though, would be to modify libsane to
> send a D-Bus message to the HAL add-on so it releases the device (unless
> you configured libsan
Hi,
> e.g. it's polling. I don't suppose there's any way to avoid this, it
> only will happen when the scanner is plugged in and powered on.
How to do without polling in user space ?
> So here's what I would do
> [snip]
> What do you think?
That's really nice !!! Also, patching sane_get_devices
On Mon, 2007-03-19 at 10:30 -0400, Donald Straney wrote:
> > In fact, imcapd is going to be a HAL add-on, but registering dbus call
> > in order to reclaim/release device. Donald, can you confirm that ?
>
> Right, it could definitely do that as a HAL addon. Each scanner could
> have ReleaseDevice
Hi,
Does libusb allow to lock device ? Does libusb actually access a device
locked by another process ?
About usb-only. It's up to you to implement different devices and
protocols.
Étienne.
--
Verso l'Alto !
___
desktop-devel-list mailing list
deskto
> In fact, imcapd is going to be a HAL add-on, but registering dbus call
> in order to reclaim/release device. Donald, can you confirm that ?
Right, it could definitely do that as a HAL addon. Each scanner could
have ReleaseDevice and ReclaimDevice methods which would make it
temporarily close th
Hi,
In fact, imcapd is going to be a HAL add-on, but registering dbus call
in order to reclaim/release device. Donald, can you confirm that ?
Étienne.
--
Verso l'Alto !
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome
Hi,
> > scannerbuttonsd from SANE CVS use libusb for buttons handling, would
> > be nice to have it as an hal add-on.
>
> Yes, I totally agree with this. Email me if you need any help with the
> HAL bits.
This would be nice, but is this possible without owning the device ?
This is the main diff
On Sun, 2007-03-18 at 20:16 +0100, Étienne Bersac wrote:
> scannerbuttonsd from SANE CVS use libusb for buttons handling, would
> be nice to have it as an hal add-on.
Yes, I totally agree with this. Email me if you need any help with the
HAL bits.
Richard.
__
On Sun, 2007-03-18 at 20:16 +0100, Étienne Bersac wrote:
> Hi,
>
> This is a true problem i don't really know how to solve. Luckily, SANE
> people have just commited fdi generator to SANE CVS. So we should have
> proper device detection in the next release.
Right, it was actually committed today
Hi,
This is a true problem i don't really know how to solve. Luckily, SANE
people have just commited fdi generator to SANE CVS. So we should have
proper device detection in the next release. However, this does not
solve sharing and button event handling.
The problem with addon is : to bind to SAN
> People shouldn't be expected to start a service when they insert a
> scanner - this stuff should just work from a users perspective.
The idea is that it would be registered as a HAL callout, so it would
start when a scanner was plugged in and exit after 20 seconds if there
was no activity and no
On Sun, 2007-03-18 at 13:41 +0100, Étienne Bersac wrote:
> > how "important" is imcapd and at which state is it currently (would
> this
> > introduce an external dependency to imcapd if gnomescan would be
> > included into GNOME 2.20? if imcapd isn't good enough yet, could
> button
> > support just
Hi,
> which time constraints exactly do not fit, and why?
Afaik, gnome-scan was supposed to continue its development in order to
be ready (at least useful) for 2.20. However, i just restarted
gnome-scan from scratch for 3 days. So i wonder what will be available
for Gnome 2.20, and especially for
Hi,
Well, according to Roadmap, GnomeScan seems to be one of the highlight
of Gnome 2.20. GnomeScan got its repo since less than a week. Waiting
for this repos, i designed GnomeScan (see
http://live.gnome.org/GnomeScan/Spec and
http://live.gnome.org/GnomeScan/API ).
In the meantime two other rela
a draft for the gnome 2.19 schedule is available at
http://live.gnome.org/TwoPointNineteen .
comments welcome.
andre
--
mailto:[EMAIL PROTECTED] | failed!
http://www.iomc.de/ | http://blogs.gnome.org/portal/aklapper
signature.asc
Description: Dies ist ein digital signierter
17 matches
Mail list logo
