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

PATCH Till Kamppeter 3 participants 8 messages Aug 10, 2009 – Aug 11, 2009 Bluetooth drivers

Share & tools

Till Kamppeter

author

2009-08-10 20:19 UTC #0 lore raw

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:

<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:

cups/main.c +1 -1

@@ -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

Bastien Nocera

2009-08-11 10:33 UTC #1 lore raw

Hello Till,

Quoted 24 lines · 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.

Quoted 8 lines

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

<policy group="lp">
<allow send_destination="org.bluez"/>
</policy>

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

Quoted 5 lines

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.

Quoted 3 lines

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>

Quoted 8 lines

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

Till Kamppeter

author

2009-08-11 11:19 UTC #2 lore raw

Quoted 5 lines · Bastien Nocera

Quoted 5 lines
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:

Quoted 8 lines

Quoted 5 lines

<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.

Quoted 9 lines

Quoted 1 line
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.

Quoted 10 lines

Quoted 2 lines
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"

Quoted 3 lines

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.

Quoted 3 lines

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

Bastien Nocera

2009-08-11 11:33 UTC #3 lore raw

Quoted 13 lines · Till Kamppeter

Quoted 12 lines · Bastien Nocera
Quoted 11 lines
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:

<policy group="lp">
<allow send_destination="org.bluez"/>
</policy>

Quoted 6 lines

Quoted 2 lines
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).

Quoted 14 lines

Quoted 6 lines
Quoted 5 lines
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.
Quoted 7 lines
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.

Quoted 7 lines

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 :)

Quoted 5 lines

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.

Quoted 19 lines

Quoted 11 lines
Quoted 3 lines
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"
Quoted 3 lines
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.

Quoted 8 lines

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...

Quoted 4 lines

Quoted 2 lines
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.

Quoted 1 line

Do you have a bug/feature request tracking system?

There isn't one.

Till Kamppeter

author

2009-08-11 12:24 UTC #4 lore raw

Quoted 4 lines · Bastien Nocera

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.

Quoted 5 lines

Quoted 1 line
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.

Quoted 5 lines

Quoted 2 lines
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.

Quoted 3 lines

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

OK.

Quoted 7 lines

Quoted 3 lines
Quoted 2 lines
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.

Quoted 3 lines

Quoted 1 line
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

Bastien Nocera

2009-08-11 13:12 UTC #5 lore raw

On Tue, 2009-08-11 at 14:24 +0200, Till Kamppeter wrote:
<snip>

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
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...

Quoted 1 line

From b2d24735492e6a71f3441720940ac55c33fa0838 Mon Sep 17 00:00:00 2001

From: Till Kamppeter <[email protected]>
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(-)

src/bluetooth.conf +6 -0

index c047623..315009c 100644
@@ -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>

Signature · 1 line

1.6.2.5

Quoted 1 line

From d96004d65132a7934308ded8010c5f819013157a Mon Sep 17 00:00:00 2001

From: Till Kamppeter <[email protected]>
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(-)

cups/main.c +1 -1

index ba9864f..bb15c9c 100644
@@ -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

Signature · 1 line

1.6.2.5

Marcel Holtmann

maintainer

2009-08-11 22:09 UTC #6 lore raw

Hi Bastien,

Quoted 7 lines

Quoted 2 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
Do you have a bug/feature request tracking system?

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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

Marcel Holtmann

maintainer

2009-08-11 22:14 UTC #7 lore raw

In reply to Bastien Nocera

Hi Bastien,

Quoted 4 lines

Quoted 2 lines
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