On Mon, 2010-03-22 at 18:14 +0200, Luiz Augusto von Dentz wrote: > Hi Bastien, > > On Mon, Mar 22, 2010 at 2:13 PM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > Hey, > > > > On Thu, 2010-03-18 at 22:50 -0300, Vinicius Gomes wrote: > >> Hi, > >> > >> BlueZ just got accepted as an organization for this year's Google > >> Summer of Code. > >> > >> There is a small list of project ideas here[1], for the next days we > >> need to polish it and add more content. Any help is appreciated. > >> > >> We are also looking for mentors, if this idea interests you, please > >> contact me off-list or go to #bluez-gsoc at freenode, this is also > >> where most of the discussion regarding GSoC will take place, in case > >> you just want to follow it. > >> > >> As always, patches and suggestions are welcome ;-) > > > > A couple of comments: > > - Is AVRCP 1.4 support really a full Summer's work? Could be with > > PulseAudio or application integration? > > Some avrcp 1.4 needs some integration so I guess it is ok. > > > - The "any" adapter work is a waste of resources, as I've mentioned in > > the past on the list. > > Well if it eliminates one round trip for most application I guess it > is worth adding, and we might add other tricks as storage and API > simplifications on top of it. One round-trip at the cost of more code on your side. I'm really not sure it's worth it. > > - The VDP support probably needs kernel-level hacking as well, to avoid > > being constrained to one of the supported frameworks, and create a > > user-space driver for the device (using CUSE?) > > It could be considerate, but if that is a good idea to vdp it would > also be for a2dp, there is also the problem that avdtp is currently > implemented in bluetoothd so I wonder if we should start changing > things or just implement vdp on top of the existing avdtp code. Right, except that for sound we have a "broker" application in PulseAudio. There's no such thing for V4L devices. In any case, it should probably be a separate application that would take the data from bluetoothd and make it available as a video device through v4l. The VDP-using webcam I have uses MPEG-4 as the video codec, and you probably don't want to have to reimplement that, so the broker app could probably use GStreamer to make the video available. > > I'd be happy to do testing and some integration work for both the VDP > > and DUN works. > > > > I could also add: > > - Port gnome-user-share to obexd, instead of obex-data-server (easy) > > - Port osso-gwobex test suite and extend it (medium) > > (Those 2 could be combined into one project) > > - Printer (initial) setup integration in gnome-bluetooth (medium) > > I guess those are too gnome related for being in BlueZ, expect maybe > gwobex, of course we could help/co/mentor projects under gnome > organization. Or vice-versa :) Given that porting gnome-user-share to obexd shouldn't be a long winded task, porting the osso-gwobex test suite would nicely complete it. The printer integration work could probably be re-used by other bluetoothd-setup front-ends like KDE. > > - Extended hostname support (using xdg-hostname) (medium) > > - Kernel driver and user-space changes for Sixaxis joypad (including > > rumble). The bdaddr assignment would be done in the kernel, with a > > helper in bluetoothd, extra functionality would be added in the kernel > > for the other features (medium) > > Great ideas and those fits perfectly as bluez organization projects. Cheers -- 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
