Relevant libmtp bug: https://sourceforge.net/tracker/?func=detail&aid=3109858&group_id=158745&atid=809061 In the HAL glory days, libmtp provided an FDI file that augmented 10-usb-music-player.fdi with both new devices and new information about existing devices - specifically that they could be accessed using the mtp protocol, and that libmtp was an available driver for them. What is the mechanism that should be used now? Some sort of extensibility of the m-p-i system seems sensible, but there is no information about how that should be done, so I'm guessing it hasn't really been considered. Adding new devices is obviously quite straightforward, but how should augmenting the information about devices already in m-p-i be handled?
I followed up to the libmtp bug with two possible suggestions. There is no reason why the libmtp udev rules couldn't set the ID_MEDIA_PLAYER attribute. However, we do not want nor need to track MTP devices in m-p-i itself, since the MTP protocol includes queries about the device name and capabilities. I keep this open in case you want us to change anything in README about this topic, but let's discuss it in the other bug first. Thanks!
I have added: ENV{ID_MEDIA_PLAYER}="1" To the default udev rules generated by examples/hotplug.c, do you think this will be enough?
Thanks Linus. Looks fine from my side.
Shouldn't an ideal thing be that m-p-i can be queried on-the-fly via HTTP/REST against some sort of online database? If you install a stable Linux system (let's say an Ubuntu LTS), you don't want to be upgrading to some new unstable distro version just because the new version of some library adds your new smartphone model in its internal whitelist. Can we walk towards this goal somehow?
udev is usually the way we deal with hardware quirks, so this seems fine now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.