_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Luiz,
> > Btw, The printer wizard as it is now wont work with periodic
> > discovery, signals DiscoveryStarted and
> > DiscoveryCompleted are not emitted while in
> periodic discovery.
>
> The cups backend isn't supposed to run forever, so it can't do
> periodic
> discovery.
>
> Well that is not the case of being running forever but you could
> probably
> test if the periodic scan is active before you start a blocking
> discovery.
> My main concern is about multiple process doing this, the probability
> of
> having collisions while doing sdp searches could be very high as it is
> very
> common to have more than one functionality in a device, this leaves
> wizard
> processes very complicated and may force them to reschedule on each
> collision .
it is fine to start an inquiry while you are in periodic inquiry. With
the exception that some chips don't allow that.
It is also fine to create an ACL link while in periodic inquiry since
the device then will stop its inquiry train automatically and switch to
page for the ACL link. After it it will continue with the periodic
inquiry as before.
The kernel now takes care of serializing the ACL link creation. This
works perfectly fine. There is one small glitch with remote name resolve
that doesn't trigger the ACL queue. However real name request have been
always a problem. However over D-Bus you only get cached names or an
error anyway. The only exception is if you in inquiry or periodic
inquiry. While the inquiry is no problem, we have to check with the
periodic inquiry if we create a deadlock.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Comments in line:
On 5/29/07, Bastien Nocera <[email protected]> wrote:
>
> On Tue, 2007-05-29 at 00:58 -0300, Luiz Augusto von Dentz wrote:
> > I consider this as a wizard for printers, like in NetwokManager the
> > network wizard also
> > does start a discovery and it work like a charm but in my opinion it
> > doesnt belong to bluez utils.
>
> It's a standard feature of cups backends. If they support it, they
> should list the accessible/known printers in the vicinity.
>
> > Having each wizard to rely in its own discovery is probably a bad
> > design, we can probably integrate
> > all wizard together and then having services configuring them in the
> > background. This way we
> > could leave to the user to use periodic scan and popup specific device
> > wizard dependent on
> > each service when active. Also in my opinion it should exist a printer
> > service for those that want to
> > configure its devices that are not in discoverable mode.
>
> True, it would be much better. But in the meanwhile, this patch simply
> implements a CUPS feature and allows us to have some basic integration
> in the distribution-provided printer tools.
So we may mark this as subject to change.
Being able to configure the printer via a bluetooth configuration wizard
> requires a bit more work, but it's also on my plans. There should be a
> CUPS service that would allow hcid to add/remove bluetooth printers from
> cups with minimum user interaction.
My idea is to have printer service more generic, the bluetooth wizard could
do
CUPS integration as it would integrate with any other system wide
integration.
> Btw, The printer wizard as it is now wont work with periodic
> > discovery, signals DiscoveryStarted and
> > DiscoveryCompleted are not emitted while in periodic discovery.
>
> The cups backend isn't supposed to run forever, so it can't do periodic
> discovery.
Well that is not the case of being running forever but you could probably
test if the periodic scan is active before you start a blocking discovery.
My main concern is about multiple process doing this, the probability of
having collisions while doing sdp searches could be very high as it is very
common to have more than one functionality in a device, this leaves wizard
processes very complicated and may force them to reschedule on each
collision .
--
> Bastien Nocera <[email protected]>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Luiz Augusto von Dentz
Engenheiro de Computa??o
On Tue, 2007-05-29 at 00:58 -0300, Luiz Augusto von Dentz wrote:
> I consider this as a wizard for printers, like in NetwokManager the
> network wizard also
> does start a discovery and it work like a charm but in my opinion it
> doesnt belong to bluez utils.
It's a standard feature of cups backends. If they support it, they
should list the accessible/known printers in the vicinity.
> Having each wizard to rely in its own discovery is probably a bad
> design, we can probably integrate
> all wizard together and then having services configuring them in the
> background. This way we
> could leave to the user to use periodic scan and popup specific device
> wizard dependent on
> each service when active. Also in my opinion it should exist a printer
> service for those that want to
> configure its devices that are not in discoverable mode.
True, it would be much better. But in the meanwhile, this patch simply
implements a CUPS feature and allows us to have some basic integration
in the distribution-provided printer tools.
Being able to configure the printer via a bluetooth configuration wizard
requires a bit more work, but it's also on my plans. There should be a
CUPS service that would allow hcid to add/remove bluetooth printers from
cups with minimum user interaction.
> Btw, The printer wizard as it is now wont work with periodic
> discovery, signals DiscoveryStarted and
> DiscoveryCompleted are not emitted while in periodic discovery.
The cups backend isn't supposed to run forever, so it can't do periodic
discovery.
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
I consider this as a wizard for printers, like in NetwokManager the network
wizard also
does start a discovery and it work like a charm but in my opinion it doesnt
belong to bluez utils.
Having each wizard to rely in its own discovery is probably a bad design, we
can probably integrate
all wizard together and then having services configuring them in the
background. This way we
could leave to the user to use periodic scan and popup specific device
wizard dependent on
each service when active. Also in my opinion it should exist a printer
service for those that want to
configure its devices that are not in discoverable mode.
Btw, The printer wizard as it is now wont work with periodic discovery,
signals DiscoveryStarted and
DiscoveryCompleted are not emitted while in periodic discovery.
On 5/25/07, Bastien Nocera <[email protected]> wrote:
>
> On Fri, 2007-05-25 at 13:58 +0100, Bastien Nocera wrote:
> > On Fri, 2007-05-25 at 13:30 +0100, Bastien Nocera wrote:
> > > On Thu, 2007-05-24 at 19:50 +0100, Bastien Nocera wrote:
> > > <snip>
> > > > This is most ugly. There should really be a helper function for
> that, or
> > > > hcid should pass a decoded argument.
> > > >
> > > > Anyway, it's implemented now, along with a port to pure D-Bus, and
> can
> > > > use the builtin eglib instead of the system one.
> > >
> > > And an updated version which pulls the IEEE1284 ID from the attributes
> > > of the SDP record. This means that it takes 2 clicks in most config
> > > tools to add the printer (add printer, and select the bluetooth
> > > printer).
> > >
> > > If you're using the system hcid instead of the patched in bluez-utils,
> > > you'll need to replace the line:
> > > const char *svc_id = "hcrp"; /* aka 0x1126 */
> > > with:
> > > const char *svc_id = "00001126-0000-1000-8000-00805F9B34FB";
> > > in cups/main.c device_get_ieee1284_id()
> > >
> > > Patch attached.
> >
> > With some indentation changes, at Marcel's request.
>
> - Don't typedef BluezCupsDevice
> - Fix includes from common/
> - Simplify Makefile.am slightly
> - Remove already committed eglib changes
>
> --
> Bastien Nocera <[email protected]>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
--
Luiz Augusto von Dentz
Engenheiro de Computa??o
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
On May 24, 2007, at 15:39, Bastien Nocera wrote:
> On Wed, 2007-05-23 at 18:56 +0200, Johan Hedberg wrote:
>> Hi Bastien,
>>
>> On May 23, 2007, at 18:26, Bastien Nocera wrote:
>>> Updated patch attached.
>>
>> A little about optimizing the device discovery.
>
> Fixed in this version, and also added recent devices (through
> ListRemoteDevices and ListBondings).
I see you're now using the manual name resolving discovery and
deciding from the device class whether to get the name or not. Great!
However, you are causing an unecessary roundtrip back to hcid by
calling GetRemoteMinorClass because you in fact already have the
necessary information encoded in the class parameter of the
RemoteDeviceFound signal. It's not as convenient as a string to do a
strcmp on, but you can just take example from hcid code how it
converts the 3 byte value to the string.
Johan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > > Here's a patch against CVS bluez-utils to add discovery to the CUPS
> > > backend. With this, it means that most CUPS front-end will be able to
> > > list visible printers when adding a new one, be it through the web
> > > interface or other front-ends (like Fedora' system-config-printer).
> > >
> > > It adds D-Bus and glib as dependencies for the backend (not that it
> > > matters that much...).
> >
> > it actually does. We provide an eGlib for embedded systems and so when
> > compiled with GLib, we only use that function subset.
> >
> > And second you use the GLib D-Bus bindings. I am not willing to create
> > these dependencies for a "daemon" package.
>
> The dependency is already optional (and if not, I can make it so).
>
> I've looked at what using dbus directly would entail, and I'm not sure
> that's a good use of my (or anyone's) time. The code would be much more
> complicated than it would need to be, and certainly not any more
> readable.
you can use a lot of helpers from common/libhelper.a to make the
integration with D-Bus really simple. Of course low-level code might is
a little bit more complex, but for me it is not less readable actually.
> In the worst case, how about moving the cups plugin to another module?
I am not maintaining another package.
> > Actually that is the reason why we wanna go
> > for a printing service in the future.
>
> I still haven't heard the benefits, or features that service would have.
>
> Unless you want to pass data from a client, over dbus to this printing
> service, which I don't think is a good idea given the potential size of
> the data being passed over.
>
> If anyone is involved with that, a draft API would be appreciated.
We are not at that point. It was an idea that came of at the last BlueZ
developer meeting. However it might be bogus and we don't do it. I can
tell you more once we actually do start working on it. So no real
details on it so far.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2007-05-23 at 18:56 +0200, Johan Hedberg wrote:
> Hi Bastien,
>
> On May 23, 2007, at 18:26, Bastien Nocera wrote:
> > Updated patch attached.
>
> A little about optimizing the device discovery.
<snip>
> This way time
> will not go wasted to requesting names for devices we will not do
> anything with anyway.
Good call. I'll fix it up tomorrow.
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
On May 23, 2007, at 18:26, Bastien Nocera wrote:
> Updated patch attached.
A little about optimizing the device discovery. It seems you are
filtering out all non-printer devices by checking the minor device
class but still requesting names for all found devices (actually hcid
is doing the requesting because you use the normal DiscoverDevices
method).
The name requests are the most time wasting operations of the device
discovery process (if a device happens to go out of range you'll have
to wait usually between 10 and 20 seconds for a page timeout to
occur, and even if it is within range we're talking about several
seconds usually for the name request to succeed). To allow overcoming
this issue have the DiscoverDevicesWithoutNameResolving method which
can be used when you can deduce from the device class information
whether you want to ignore the device or get further information
about it (e.g. its name, provided services through SDP, etc).
So, for the CUPS case, the optimal solution would be to use this
alternate discovery method and for each RemoteDeviceFound signal
check the class of device value and if it matches request the name
for the device (as you were doing in your first patch). This way time
will not go wasted to requesting names for devices we will not do
anything with anyway.
Johan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2007-05-23 at 17:51 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > Here's a patch against CVS bluez-utils to add discovery to the CUPS
> > backend. With this, it means that most CUPS front-end will be able to
> > list visible printers when adding a new one, be it through the web
> > interface or other front-ends (like Fedora' system-config-printer).
> >
> > It adds D-Bus and glib as dependencies for the backend (not that it
> > matters that much...).
>
> it actually does. We provide an eGlib for embedded systems and so when
> compiled with GLib, we only use that function subset.
>
> And second you use the GLib D-Bus bindings. I am not willing to create
> these dependencies for a "daemon" package.
It's not a "daemon", as in, it won't be running all the time. It's only
a small short-lived program. Should I make it compile-time dependency?
> Another small thing is that DisocverDevices() will automatically take
> care of the name resolving for you. So no need to call GetRemoteName().
> You will get the RemoteNameUpdated() signal.
Cool, I'll clean up the code.
> The thing that worries me is when you start CUPS it will list through
> all backends and make them list. So on every boot the system will scan
> for devices in range and that can slow down the system boot. So this
> might not be a good idea. Actually that is the reason why we wanna go
> for a printing service in the future.
As Tim mentioned, CUPS won't do the requests on startup, but on demand.
As for the printing service, what would it actually buy us, ie. which
feature would you have in it that aren't possible in the backend?
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2007-05-23 at 17:51 +0200, Marcel Holtmann wrote:
> The thing that worries me is when you start CUPS it will list through
> all backends and make them list. So on every boot the system will scan
> for devices in range and that can slow down the system boot. So this
> might not be a good idea. Actually that is the reason why we wanna go
> for a printing service in the future.
This hasn't been true since CUPS 1.1.x. In CUPS 1.2.x device discovery
is performed on demand.
Tim.
*/
Hi Bastien,
> Here's a patch against CVS bluez-utils to add discovery to the CUPS
> backend. With this, it means that most CUPS front-end will be able to
> list visible printers when adding a new one, be it through the web
> interface or other front-ends (like Fedora' system-config-printer).
>
> It adds D-Bus and glib as dependencies for the backend (not that it
> matters that much...).
it actually does. We provide an eGlib for embedded systems and so when
compiled with GLib, we only use that function subset.
And second you use the GLib D-Bus bindings. I am not willing to create
these dependencies for a "daemon" package.
Another small thing is that DisocverDevices() will automatically take
care of the name resolving for you. So no need to call GetRemoteName().
You will get the RemoteNameUpdated() signal.
The thing that worries me is when you start CUPS it will list through
all backends and make them list. So on every boot the system will scan
for devices in range and that can slow down the system boot. So this
might not be a good idea. Actually that is the reason why we wanna go
for a printing service in the future.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2007-06-07 at 12:21 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > > With some indentation changes, at Marcel's request.
> >
> > - Don't typedef BluezCupsDevice
> > - Fix includes from common/
> > - Simplify Makefile.am slightly
> > - Remove already committed eglib changes
>
> with some fixes and cleanups, the has now been committed to the CVS.
Great stuff, thanks!
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > With some indentation changes, at Marcel's request.
>
> - Don't typedef BluezCupsDevice
> - Fix includes from common/
> - Simplify Makefile.am slightly
> - Remove already committed eglib changes
with some fixes and cleanups, the has now been committed to the CVS.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel