Hi, First I would like to know if splitting the current code of gudev into udev-glib and udev-gobject would be a good idea to begin with. By looking at connmand code it seems quite simple to integrate glib mainloop with udev so if we were not adding any API to udev-glib it seems like an unnecessary step, I heard that udev has some race conditions so perhaps we could add some very basic watch registration like we have done to libgdus. That way udev-object API doesn't have to change much just depend on udev-glib. On bluetoothd side, I would like to make udev code generic enough to detect any bluetooth device not only sixaxis so we can do different plugins to handle any device doing this cable association/cable pairing thing. -- Luiz Augusto von Dentz Engenheiro de Computação -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
