Hi Brian, > >> This patch fixes the device removal order when a connection is closed, > >> which allows HAL to see the remove event and prevents a bunch of > >> duplicate devices from piling up and eventually hitting the limit for > >> the for input devices in X. > >> > >> Posting for discussion since I used a polling loop (with a sleep) to > >> wait for child devices to go away. I assume it'd be preferable to wait > >> in a more proper way. In that case, before I start, is this the right > >> place to be waiting? > >> > > > > since this is executed in a workqueue, you could easily sleep here > > without any problems. However why do you need to sleep at all. The > > device_move should sleep until the device is moved away, doesn't it? > > > > The moves do complete before the connection is removed, but it seems bad > to me to just move the child devices away rather than letting them close > down and be removed directly from the original location where they were > created. HAL thinks so, too: it still doesn't catch the input device > removal if they are moved away before they are deleted. > > > Kay, David, wouldn't be pinning of the parent device here be enough to > > get this done in a clean way? > > > > If there's a way that the connection can be pinned until the child > devices go away, that definitely sounds cleaner to me. so I pushed some patches to bluetooth-testing tree that should fix this problem. They are not fully tested by me. Please test and report back the results. Regards Marcel -- 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
