Jiri Kosina wrote: > Hi Li, > > we have been discussing this with Marcel previously, and the decission was > to let the hidp code where it is right now, due to it being very closely > connected to the bluetooth network stack. > That's OK. > >> 1. HID/Bluetooth support, ONLY FOR HIGHLY EXPERIMENT. I have no >> any such device to test yet. >> > > I didn't have time yet to review the patch you sent previously, but I > don't still quite understand why does the transport layer matter here? The > generic HID layer, as it is in kernel now, makes an abstraction in a way > that the HID-specific drivers should not care about the underlying > transport layer. > > Here is my reason for supply such hid_transport data structure:
As before, we only have one driver for each transport layer, IOW, the common driver. In this case, we really need not such transport data structure. However, there are many driver in one transport layer after HID bus come, these drivers at the same transport layer implementation would like share some something each other, these live in common driver before. If we did not add such transport data structure, we must find one related driver, and clone it, I think that is not good idea. In fact, even now, the HID processing logic still do not take care of which transport layer works under it, the cost just is increasing some pointer reference operations. >> I am sorry for it is not in patch form. >> > > That's quite unfortunate. I'll try to review it nevertheless, but it'd be > much more convenient if you manage to send a patch. > > OK, I will post the patch for 2.6.21-rc6-mm1 later. You are recommended to wait to review that. My friend yanghong buy a new bluetooth mouse, so I can test bluetooth nowadays, Thanks him here. :D Good luck. - Li Yu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
