PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Till Kamppeter]

Hi,

I am using Bluez 4.47, and I can set up a Bluetooth printer only 
manually by running the "bluetooth" CUPS backend from the command line with

/usr/lib/cups/backend/bluetooth

and then pasting the URI into the field for individual URI input in 
system-config-printer ("Others" in the device list). Then I also need to 
choose manufacturer and model manually. My expectation is that I only 
need to click the printer's make model name in the devices list and 
choose "Bluetooth" under the connection types and then the driver gets 
selected automatically as it is the case for the same printer on USB or 
WLAN.

I have found out why it does not work.

First, the CUPS Bluetooth backend asks the bluez D-Bus service whether 
there are printers available and which device ID they have. The access 
permissions for the bluez D-Bus service do not permit the CUPS system 
user "lp" to access, and exactly as this user the Bluetooth backend is 
running. Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf 
to grant this permission.

I have added the following lines into the <busconfig> section:


   <!-- allow users of lp group (printing subsystem) to communicate with 
hcid -->
   <policy group="lp">
     <allow send_destination="org.bluez"/>
   </policy>


Second, the output of the CUPS Bluetooth backend was not very good for 
the printer setup tools doing the right thing. I have patched the 
backend to let the device class of the Bluetooth printers to be "direct" 
and not "network", as users expect a Bluetooth printer rather under the 
local printers than under the network printers. I have also filled the 
make-and-model field instead of putting a hard-coded "Unknown" there. 
The change is here:


--- bluez-4.47/cups/main.c	2009-07-03 00:43:14.000000000 +0200
+++ bluez-4.47.new/cups/main.c	2009-08-10 20:09:32.000000000 +0200
@@ -226,7 +226,7 @@
  		 bdaddr[9], bdaddr[10],
  		 bdaddr[12], bdaddr[13],
  		 bdaddr[15], bdaddr[16]);
-	printf("network %s \"Unknown\" \"%s (Bluetooth)\"", uri, escaped);
+	printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
  	if (id != NULL)
  		printf(" \"%s\"\n", id);
  	else


See also my Ubuntu bug report:

https://bugs.launchpad.net/bugs/411610

I am very grateful if you could apply these changes to Bluez upstream, 
as this makes the bluetooth CUPS backend just work.

Thank you very much in advance.

    Till


http://www.openprinting.org/

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Bastien Nocera]

Hello Till,

On Mon, 2009-08-10 at 22:19 +0200, Till Kamppeter wrote:
> Hi,
> 
> I am using Bluez 4.47, and I can set up a Bluetooth printer only 
> manually by running the "bluetooth" CUPS backend from the command line with
> 
> /usr/lib/cups/backend/bluetooth
> 
> and then pasting the URI into the field for individual URI input in 
> system-config-printer ("Others" in the device list). Then I also need to 
> choose manufacturer and model manually. My expectation is that I only 
> need to click the printer's make model name in the devices list and 
> choose "Bluetooth" under the connection types and then the driver gets 
> selected automatically as it is the case for the same printer on USB or 
> WLAN.
> 
> I have found out why it does not work.
> 
> First, the CUPS Bluetooth backend asks the bluez D-Bus service whether 
> there are printers available and which device ID they have. The access 
> permissions for the bluez D-Bus service do not permit the CUPS system 
> user "lp" to access, and exactly as this user the Bluetooth backend is 
> running. Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf 
> to grant this permission.
> 
> I have added the following lines into the <busconfig> section:
> 
> 
>    <!-- allow users of lp group (printing subsystem) to communicate with 
> hcid -->
>    <policy group="lp">
>      <allow send_destination="org.bluez"/>
>    </policy>

Looks good. What about patching the upstream config file instead?

> Second, the output of the CUPS Bluetooth backend was not very good for 
> the printer setup tools doing the right thing. I have patched the 
> backend to let the device class of the Bluetooth printers to be "direct" 
> and not "network", as users expect a Bluetooth printer rather under the 
> local printers than under the network printers.

That seems like a good idea, but I don't know enough about the internals
of CUPS to know whether it changes anything but the classification of
the printer.

If it doesn't change the behaviour wrt. errors and retries, then I'm
fine with it.

>  I have also filled the 
> make-and-model field instead of putting a hard-coded "Unknown" there. 
> The change is here:

This part is broken. The backend man page says those are possible types
of output:
device-class scheme "Unknown" "device-info"
device-class device-uri "device-make-and-model" "device-info"
device-class device-uri "device-make-and-model" "device-info" "device-id"
device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"

So if you have the device-id, you must have a device-info. Your patch
removes the device-info even if we have a device-id.

<snip>
> See also my Ubuntu bug report:
> 
> https://bugs.launchpad.net/bugs/411610
> 
> I am very grateful if you could apply these changes to Bluez upstream, 
> as this makes the bluetooth CUPS backend just work.
> 
> Thank you very much in advance.

In the future, please attach the patches to your mail, and make sure
they apply to the upstream sources.

Cheers

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Till Kamppeter]

Bastien Nocera wrote:
>> Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf 
>> to grant this permission.
>>
>> I have added the following lines into the <busconfig> section:
>>
>>
>>    <!-- allow users of lp group (printing subsystem) to communicate with 
>> hcid -->
>>    <policy group="lp">
>>      <allow send_destination="org.bluez"/>
>>    </policy>
> 
> Looks good. What about patching the upstream config file instead?
> 

This is my intention, is it another file than 
/etc/dbus-1/system.d/bluetooth.conf? I simply want nothing more than 
that the access permission for "lp" is there out-of-the-box.

>> Second, the output of the CUPS Bluetooth backend was not very good for 
>> the printer setup tools doing the right thing. I have patched the 
>> backend to let the device class of the Bluetooth printers to be "direct" 
>> and not "network", as users expect a Bluetooth printer rather under the 
>> local printers than under the network printers.
> 
> That seems like a good idea, but I don't know enough about the internals
> of CUPS to know whether it changes anything but the classification of
> the printer.
> 
> If it doesn't change the behaviour wrt. errors and retries, then I'm
> fine with it.
>

The device class only appears in the output of the backends in discovery 
mode. It does not enter anywhere into the configuration of the print 
queue. So it seems only to server for separating local and network 
printers in the listing of detected printers in a printer setup tool.

A Bluetooth printer has to get paired with a computer before the 
Bluetooth CUPS backend can find it. This makes it getting assigned to 
one single computer, whereas a network printer (Ethernet or WLAN) gets 
discovered by all computers in the network and all computers can have a 
working queue accessing to the same network printer. Therefore a 
Bluetooth printer has more the characteristics of a local printer.


>>  I have also filled the 
>> make-and-model field instead of putting a hard-coded "Unknown" there. 
>> The change is here:
> 
> This part is broken. The backend man page says those are possible types
> of output:
> device-class scheme "Unknown" "device-info"
> device-class device-uri "device-make-and-model" "device-info"
> device-class device-uri "device-make-and-model" "device-info" "device-id"
> device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
> 
> So if you have the device-id, you must have a device-info. Your patch
> removes the device-info even if we have a device-id.
> 

Really? What I did is replacing the "Unknown" by "%s" and adding a 
second "expanded" for the additional "%s". I have tested it and it works 
as expected.

This is the output with my patch:

direct bluetooth://001A0E1769AA "Officejet H470" "Officejet H470 
(Bluetooth)" "MFG:HP;MDL:Officejet 
H470_BT;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CB028A;"

It has exactly the 5 items as the second last line of the output schemes 
which you show above shows.

> 
> In the future, please attach the patches to your mail, and make sure
> they apply to the upstream sources.

Sorry, was my first patch submission to this project.

Do you have a bug/feature request tracking system?

    Till

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Bastien Nocera]

On Tue, 2009-08-11 at 13:19 +0200, Till Kamppeter wrote:
> Bastien Nocera wrote:
> >> Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf 
> >> to grant this permission.
> >>
> >> I have added the following lines into the <busconfig> section:
> >>
> >>
> >>    <!-- allow users of lp group (printing subsystem) to communicate with 
> >> hcid -->
> >>    <policy group="lp">
> >>      <allow send_destination="org.bluez"/>
> >>    </policy>
> > 
> > Looks good. What about patching the upstream config file instead?
> > 
> 
> This is my intention, is it another file than 
> /etc/dbus-1/system.d/bluetooth.conf? I simply want nothing more than 
> that the access permission for "lp" is there out-of-the-box.

You're modifying a file in the Ubuntu package (it's in the debian/
sub-directory), not the one from bluez (src/bluetooth.conf in the
sources).

> >> Second, the output of the CUPS Bluetooth backend was not very good for 
> >> the printer setup tools doing the right thing. I have patched the 
> >> backend to let the device class of the Bluetooth printers to be "direct" 
> >> and not "network", as users expect a Bluetooth printer rather under the 
> >> local printers than under the network printers.
> > 
> > That seems like a good idea, but I don't know enough about the internals
> > of CUPS to know whether it changes anything but the classification of
> > the printer.
> > 
> > If it doesn't change the behaviour wrt. errors and retries, then I'm
> > fine with it.
> >
> 
> The device class only appears in the output of the backends in discovery 
> mode. It does not enter anywhere into the configuration of the print 
> queue. So it seems only to server for separating local and network 
> printers in the listing of detected printers in a printer setup tool.
> 
> A Bluetooth printer has to get paired with a computer before the 
> Bluetooth CUPS backend can find it.

I know that, seeing as I wrote the discovery code in the bluetooth
backend :)

>  This makes it getting assigned to 
> one single computer, whereas a network printer (Ethernet or WLAN) gets 
> discovered by all computers in the network and all computers can have a 
> working queue accessing to the same network printer. Therefore a 
> Bluetooth printer has more the characteristics of a local printer.

Seems fair.

> >>  I have also filled the 
> >> make-and-model field instead of putting a hard-coded "Unknown" there. 
> >> The change is here:
> > 
> > This part is broken. The backend man page says those are possible types
> > of output:
> > device-class scheme "Unknown" "device-info"
> > device-class device-uri "device-make-and-model" "device-info"
> > device-class device-uri "device-make-and-model" "device-info" "device-id"
> > device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
> > 
> > So if you have the device-id, you must have a device-info. Your patch
> > removes the device-info even if we have a device-id.
> > 
> 
> Really? What I did is replacing the "Unknown" by "%s" and adding a 
> second "expanded" for the additional "%s". I have tested it and it works 
> as expected.
> 
> This is the output with my patch:
> 
> direct bluetooth://001A0E1769AA "Officejet H470" "Officejet H470 
> (Bluetooth)" "MFG:HP;MDL:Officejet 
> H470_BT;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CB028A;"
> 
> It has exactly the 5 items as the second last line of the output schemes 
> which you show above shows.

You're right, read the patch in reverse...

> > In the future, please attach the patches to your mail, and make sure
> > they apply to the upstream sources.
> 
> Sorry, was my first patch submission to this project.

Could you rebase your fixes into patches ready for inclusion in the git
tree? If you don't know git, I'll make those changes myself.

> Do you have a bug/feature request tracking system?

There isn't one.

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Till Kamppeter]

Bastien Nocera wrote:
> You're modifying a file in the Ubuntu package (it's in the debian/
> sub-directory), not the one from bluez (src/bluetooth.conf in the
> sources).
>

For the Ubuntu packaging I did the change in the Ubuntu-provided version 
of the file as the Ubuntu (Debian?) package maintainer did other changes 
there. Putting my change in the original file then would have resulted 
in them being overwritten. In the upstream fix I naturally expect the 
change to be applied to src/bluetooth.conf.

>> A Bluetooth printer has to get paired with a computer before the 
>> Bluetooth CUPS backend can find it.
> 
> I know that, seeing as I wrote the discovery code in the bluetooth
> backend :)
>

OK, I mentioned that only to tell why the Bluetooth printers should be 
considered local.

>>  This makes it getting assigned to 
>> one single computer, whereas a network printer (Ethernet or WLAN) gets 
>> discovered by all computers in the network and all computers can have a 
>> working queue accessing to the same network printer. Therefore a 
>> Bluetooth printer has more the characteristics of a local printer.
> 
> Seems fair.
> 

OK.

> 
> You're right, read the patch in reverse...
>

OK.

>>> In the future, please attach the patches to your mail, and make sure
>>> they apply to the upstream sources.
>> Sorry, was my first patch submission to this project.
> 
> Could you rebase your fixes into patches ready for inclusion in the git
> tree? If you don't know git, I'll make those changes myself.
> 

Could you put them in? Then I do not need to download the git only to 
format two simple one-point-only-changed patches. Thanks.

>> Do you have a bug/feature request tracking system?
> 
> There isn't one.

As vluez seems to be a part of the kernel project, does the kernel even 
not have a bug tracking system?

    Till

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Bastien Nocera]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

On Tue, 2009-08-11 at 14:24 +0200, Till Kamppeter wrote:
<snip>
> Could you put them in? Then I do not need to download the git only to 
> format two simple one-point-only-changed patches. Thanks.

Patches attached.

> >> Do you have a bug/feature request tracking system?
> > 
> > There isn't one.
> 
> As vluez seems to be a part of the kernel project, does the kernel even 
> not have a bug tracking system?

BlueZ's kernel bits probably use the kernel bug tracker. For the
user-space bits, send mails here[1].

Cheers

[1]: Note that I've been barking up that tree for a while...

[-- Attachment #2: 0001-Allow-lp-CUPS-to-talk-to-bluetoothd.patch --]
[-- Type: text/x-patch, Size: 910 bytes --]

>From b2d24735492e6a71f3441720940ac55c33fa0838 Mon Sep 17 00:00:00 2001
From: Till Kamppeter <till.kamppeter@gmail.com>
Date: Tue, 11 Aug 2009 14:04:05 +0100
Subject: [PATCH 1/2] Allow lp (CUPS) to talk to bluetoothd

CUPS runs its backend helpers as the "lp" user, so we should
allow CUPS to talk to bluetoothd to enumerate printers.
---
 src/bluetooth.conf |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/bluetooth.conf b/src/bluetooth.conf
index c047623..315009c 100644
--- a/src/bluetooth.conf
+++ b/src/bluetooth.conf
@@ -17,6 +17,12 @@
     <allow send_destination="org.bluez"/>
   </policy>
 
+  <!-- allow users of lp group (printing subsystem) to 
+       communicate with bluetoothd -->
+  <policy group="lp">
+    <allow send_destination="org.bluez"/>
+  </policy>
+
   <policy context="default">
     <deny send_destination="org.bluez"/>
   </policy>
-- 
1.6.2.5


[-- Attachment #3: 0002-Mark-Bluetooth-printers-as-being-local.patch --]
[-- Type: text/x-patch, Size: 906 bytes --]

>From d96004d65132a7934308ded8010c5f819013157a Mon Sep 17 00:00:00 2001
From: Till Kamppeter <till.kamppeter@gmail.com>
Date: Tue, 11 Aug 2009 14:06:59 +0100
Subject: [PATCH 2/2] Mark Bluetooth printers as being local

For discovery purposes. Also add a better label for the printer,
and append "(Bluetooth") to the "unique" name.
---
 cups/main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cups/main.c b/cups/main.c
index ba9864f..bb15c9c 100644
--- a/cups/main.c
+++ b/cups/main.c
@@ -226,7 +226,7 @@ static void print_printer_details(const char *name, const char *bdaddr, const ch
 		 bdaddr[9], bdaddr[10],
 		 bdaddr[12], bdaddr[13],
 		 bdaddr[15], bdaddr[16]);
-	printf("network %s \"Unknown\" \"%s (Bluetooth)\"", uri, escaped);
+	printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
 	if (id != NULL)
 		printf(" \"%s\"\n", id);
 	else
-- 
1.6.2.5

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Marcel Holtmann]

Hi Bastien,

> > Could you put them in? Then I do not need to download the git only to 
> > format two simple one-point-only-changed patches. Thanks.
> 
> Patches attached.
> 
> > >> Do you have a bug/feature request tracking system?
> > > 
> > > There isn't one.
> > 
> > As vluez seems to be a part of the kernel project, does the kernel even 
> > not have a bug tracking system?
> 
> BlueZ's kernel bits probably use the kernel bug tracker. For the
> user-space bits, send mails here[1].

kernel patches and userspace patches should be send to this mailing
list.

Regards

Marcel

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Marcel Holtmann]

Hi Bastien,

> > Could you put them in? Then I do not need to download the git only to 
> > format two simple one-point-only-changed patches. Thanks.
> 
> Patches attached.

patch have been applied. Thanks.

Regards

Marcel

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Marcel Holtmann]

Hi Till,

please stop top posting. This is a proper open source mailing list and
we do proper inline quoting.

> Thank you for the quick answer.
> 
> Patch in GIT format attached.

So you have time to write a lengthy email with an explanation what is
going on, but the commit message is empty. Please fix the commit message
since that is where it should be. Especially since you wrote it already
anyway.

Regards

Marcel

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Till Kamppeter]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

Thank you for the quick answer.

Patch in GIT format attached.

    Till


Marcel Holtmann wrote:
> Hi Till,
> 
>> I am using Bluez 4.48 in Ubuntu Karmic. First thank you for applying my 
>> patches. The bluetooth backend works perfectly now with CUPS 1.3.x and 
>> older. On the new CUPS 1.4.x a new problem appeared: The new CUPS does 
>> device discovery only for a given time frame requested by the client 
>> (printer setup tool, "lpinfo" command). CUPS's default for 
>> CUPS-1.3.x-ish requests without timeout specification seems to be 10 
>> seconds. CUPS startys all backends at once in the beginning (in 
>> parallel) and kills every backend which remains running at the end of 
>> the timeout. It accepts output from the backends whenever it occurs not 
>> only when the backend finishes, so a backend can search for printers 
>> infinitely long if it outputs every found device immediately. Then all 
>> printers found during CUPS' timeout are taken into account.
>>
>> The bluetooth backend o 4.48 asks the Bluetooth daemon for printers and 
>> collects results for 10 seconds and after that it output them. This 
>> takes a total of 10.5 sec and so CUPS kills the backend right before it 
>> answers (at least with the 10-second default timeout), resulting in 
>> Bluetooth printers never being discovered by CUPS.
>>
>> I have fixed this now with the attached patch, by making each new 
>> printer added to the list being output immediately. Note that the list 
>> structure cannot be removed from cups/main.c as otherwise we would get 
>> duplicate listings.
>>
>> Can you please apply this patch to Bluez so that Bluez gets ready for 
>> the new CUPS 1.4.x generation? Thanks.
> 
> send a patch created with git format-patch so we can apply them properly
> without me having to modify the commit message manually.
> 
> Regards
> 
> Marcel
> 
> 
> 


[-- Attachment #2: 0001-Make-discovery-mode-of-bluetooth-CUPS-backend-work-w.patch --]
[-- Type: text/x-patch, Size: 3603 bytes --]

>From e9f4b0053ca32a17dfff7d19adb521952c45cf61 Mon Sep 17 00:00:00 2001
From: Till Kamppeter <till.kamppeter@gmail.com>
Date: Wed, 26 Aug 2009 21:05:43 +0200
Subject: [PATCH] Make discovery mode of bluetooth CUPS backend work with CUPS 1.4.0.

---
 ChangeLog   |    2 +
 cups/main.c |   63 +++++++++++++++++++++++-----------------------------------
 2 files changed, 27 insertions(+), 38 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d06f494..6c170f6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,5 @@
+ver 4.51:
+	Make discovery mode of bluetooth CUPS backend work with CUPS 1.4.0.
 ver 4.50:
 	Fix issue with missing manual pages in distribution.
 	Fix issue with the configuration and state directories.
diff --git a/cups/main.c b/cups/main.c
index da757b0..1bbc78c 100644
--- a/cups/main.c
+++ b/cups/main.c
@@ -185,6 +185,27 @@ static char *device_get_ieee1284_id(const char *adapter, const char *device)
 	return id;
 }
 
+static void print_printer_details(const char *name, const char *bdaddr, const char *id)
+{
+	char *uri, *escaped;
+
+	escaped = g_strdelimit(g_strdup(name), "\"", '\'');
+	uri = g_strdup_printf("bluetooth://%c%c%c%c%c%c%c%c%c%c%c%c",
+		 bdaddr[0], bdaddr[1],
+		 bdaddr[3], bdaddr[4],
+		 bdaddr[6], bdaddr[7],
+		 bdaddr[9], bdaddr[10],
+		 bdaddr[12], bdaddr[13],
+		 bdaddr[15], bdaddr[16]);
+	printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
+	if (id != NULL)
+		printf(" \"%s\"\n", id);
+	else
+		printf("\n");
+	g_free(escaped);
+	g_free(uri);
+}
+
 static void add_device_to_list(const char *name, const char *bdaddr, const char *id)
 {
 	struct cups_device *device;
@@ -212,27 +233,7 @@ static void add_device_to_list(const char *name, const char *bdaddr, const char
 	device->id = g_strdup(id);
 
 	device_list = g_slist_prepend(device_list, device);
-}
-
-static void print_printer_details(const char *name, const char *bdaddr, const char *id)
-{
-	char *uri, *escaped;
-
-	escaped = g_strdelimit(g_strdup(name), "\"", '\'');
-	uri = g_strdup_printf("bluetooth://%c%c%c%c%c%c%c%c%c%c%c%c",
-		 bdaddr[0], bdaddr[1],
-		 bdaddr[3], bdaddr[4],
-		 bdaddr[6], bdaddr[7],
-		 bdaddr[9], bdaddr[10],
-		 bdaddr[12], bdaddr[13],
-		 bdaddr[15], bdaddr[16]);
-	printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
-	if (id != NULL)
-		printf(" \"%s\"\n", id);
-	else
-		printf("\n");
-	g_free(escaped);
-	g_free(uri);
+	print_printer_details(device->name, device->bdaddr, device->id);
 }
 
 static gboolean parse_device_properties(DBusMessageIter *reply_iter, char **name, char **bdaddr)
@@ -384,23 +385,6 @@ static void remote_device_found(const char *adapter, const char *bdaddr, const c
 
 static void discovery_completed(void)
 {
-	GSList *l;
-
-	for (l = device_list; l != NULL; l = l->next) {
-		struct cups_device *device = (struct cups_device *) l->data;
-
-		if (device->name == NULL)
-			device->name = g_strdelimit(g_strdup(device->bdaddr), ":", '-');
-		/* Give another try to getting an ID for the device */
-		if (device->id == NULL)
-			remote_device_found(NULL, device->bdaddr, device->name);
-		print_printer_details(device->name, device->bdaddr, device->id);
-		g_free(device->name);
-		g_free(device->bdaddr);
-		g_free(device->id);
-		g_free(device);
-	}
-
 	g_slist_free(device_list);
 	device_list = NULL;
 
@@ -638,6 +622,9 @@ int main(int argc, char *argv[])
 	/* Make sure status messages are not buffered */
 	setbuf(stderr, NULL);
 
+	/* Make sure output is not buffered */
+	setbuf(stdout, NULL);
+
 	/* Ignore SIGPIPE signals */
 #ifdef HAVE_SIGSET
 	sigset(SIGPIPE, SIG_IGN);
-- 
1.6.3.3

Re: PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Marcel Holtmann]

Hi Till,

> I am using Bluez 4.48 in Ubuntu Karmic. First thank you for applying my 
> patches. The bluetooth backend works perfectly now with CUPS 1.3.x and 
> older. On the new CUPS 1.4.x a new problem appeared: The new CUPS does 
> device discovery only for a given time frame requested by the client 
> (printer setup tool, "lpinfo" command). CUPS's default for 
> CUPS-1.3.x-ish requests without timeout specification seems to be 10 
> seconds. CUPS startys all backends at once in the beginning (in 
> parallel) and kills every backend which remains running at the end of 
> the timeout. It accepts output from the backends whenever it occurs not 
> only when the backend finishes, so a backend can search for printers 
> infinitely long if it outputs every found device immediately. Then all 
> printers found during CUPS' timeout are taken into account.
> 
> The bluetooth backend o 4.48 asks the Bluetooth daemon for printers and 
> collects results for 10 seconds and after that it output them. This 
> takes a total of 10.5 sec and so CUPS kills the backend right before it 
> answers (at least with the 10-second default timeout), resulting in 
> Bluetooth printers never being discovered by CUPS.
> 
> I have fixed this now with the attached patch, by making each new 
> printer added to the list being output immediately. Note that the list 
> structure cannot be removed from cups/main.c as otherwise we would get 
> duplicate listings.
> 
> Can you please apply this patch to Bluez so that Bluez gets ready for 
> the new CUPS 1.4.x generation? Thanks.

send a patch created with git format-patch so we can apply them properly
without me having to modify the commit message manually.

Regards

Marcel

PATCHES: Device discovery of the "bluetooth" CUPS backend does not work

[Till Kamppeter]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

Hi,

I am using Bluez 4.48 in Ubuntu Karmic. First thank you for applying my 
patches. The bluetooth backend works perfectly now with CUPS 1.3.x and 
older. On the new CUPS 1.4.x a new problem appeared: The new CUPS does 
device discovery only for a given time frame requested by the client 
(printer setup tool, "lpinfo" command). CUPS's default for 
CUPS-1.3.x-ish requests without timeout specification seems to be 10 
seconds. CUPS startys all backends at once in the beginning (in 
parallel) and kills every backend which remains running at the end of 
the timeout. It accepts output from the backends whenever it occurs not 
only when the backend finishes, so a backend can search for printers 
infinitely long if it outputs every found device immediately. Then all 
printers found during CUPS' timeout are taken into account.

The bluetooth backend o 4.48 asks the Bluetooth daemon for printers and 
collects results for 10 seconds and after that it output them. This 
takes a total of 10.5 sec and so CUPS kills the backend right before it 
answers (at least with the 10-second default timeout), resulting in 
Bluetooth printers never being discovered by CUPS.

I have fixed this now with the attached patch, by making each new 
printer added to the list being output immediately. Note that the list 
structure cannot be removed from cups/main.c as otherwise we would get 
duplicate listings.

Can you please apply this patch to Bluez so that Bluez gets ready for 
the new CUPS 1.4.x generation? Thanks.

    Till

http://www.openprinting.org/



[-- Attachment #2: 10_bluetooth-cups-backend-report-printers-immediately.patch --]
[-- Type: text/x-patch, Size: 2704 bytes --]

diff -Nur -x '*.orig' -x '*~' bluez-4.48/cups/main.c bluez-4.48.new/cups/main.c
--- bluez-4.48/cups/main.c	2009-08-16 20:43:34.000000000 +0200
+++ bluez-4.48.new/cups/main.c	2009-08-26 19:05:31.000000000 +0200
@@ -185,6 +185,27 @@
 	return id;
 }
 
+static void print_printer_details(const char *name, const char *bdaddr, const char *id)
+{
+	char *uri, *escaped;
+
+	escaped = g_strdelimit(g_strdup(name), "\"", '\'');
+	uri = g_strdup_printf("bluetooth://%c%c%c%c%c%c%c%c%c%c%c%c",
+		 bdaddr[0], bdaddr[1],
+		 bdaddr[3], bdaddr[4],
+		 bdaddr[6], bdaddr[7],
+		 bdaddr[9], bdaddr[10],
+		 bdaddr[12], bdaddr[13],
+		 bdaddr[15], bdaddr[16]);
+	printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
+	if (id != NULL)
+		printf(" \"%s\"\n", id);
+	else
+		printf("\n");
+	g_free(escaped);
+	g_free(uri);
+}
+
 static void add_device_to_list(const char *name, const char *bdaddr, const char *id)
 {
 	struct cups_device *device;
@@ -212,27 +233,7 @@
 	device->id = g_strdup(id);
 
 	device_list = g_slist_prepend(device_list, device);
-}
-
-static void print_printer_details(const char *name, const char *bdaddr, const char *id)
-{
-	char *uri, *escaped;
-
-	escaped = g_strdelimit(g_strdup(name), "\"", '\'');
-	uri = g_strdup_printf("bluetooth://%c%c%c%c%c%c%c%c%c%c%c%c",
-		 bdaddr[0], bdaddr[1],
-		 bdaddr[3], bdaddr[4],
-		 bdaddr[6], bdaddr[7],
-		 bdaddr[9], bdaddr[10],
-		 bdaddr[12], bdaddr[13],
-		 bdaddr[15], bdaddr[16]);
-	printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
-	if (id != NULL)
-		printf(" \"%s\"\n", id);
-	else
-		printf("\n");
-	g_free(escaped);
-	g_free(uri);
+	print_printer_details(device->name, device->bdaddr, device->id);
 }
 
 static gboolean parse_device_properties(DBusMessageIter *reply_iter, char **name, char **bdaddr)
@@ -384,23 +385,6 @@
 
 static void discovery_completed(void)
 {
-	GSList *l;
-
-	for (l = device_list; l != NULL; l = l->next) {
-		struct cups_device *device = (struct cups_device *) l->data;
-
-		if (device->name == NULL)
-			device->name = g_strdelimit(g_strdup(device->bdaddr), ":", '-');
-		/* Give another try to getting an ID for the device */
-		if (device->id == NULL)
-			remote_device_found(NULL, device->bdaddr, device->name);
-		print_printer_details(device->name, device->bdaddr, device->id);
-		g_free(device->name);
-		g_free(device->bdaddr);
-		g_free(device->id);
-		g_free(device);
-	}
-
 	g_slist_free(device_list);
 	device_list = NULL;
 
@@ -638,6 +622,9 @@
 	/* Make sure status messages are not buffered */
 	setbuf(stderr, NULL);
 
+	/* Make sure output is not buffered */
+	setbuf(stdout, NULL);
+
 	/* Ignore SIGPIPE signals */
 #ifdef HAVE_SIGSET
 	sigset(SIGPIPE, SIG_IGN);