Bug 31642

Summary:	Extensibility of the m-p-i spec
Product:	Specifications	Reporter:	Alex Merry <dev+fdo>
Component:	desktop-entry	Assignee:	Allison Lortie (desrt) <desrt>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	medium	CC:	faure
Version:	unspecified	Keywords:	NEEDINFO
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Alex Merry 2010-11-15 16:20:58 UTC

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?

Comment 1 Martin Pitt 2010-11-18 09:03:01 UTC

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!

Comment 2 Linus Walleij 2010-11-24 07:37:49 UTC

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?

Comment 3 Martin Pitt 2010-11-24 23:41:12 UTC

Thanks Linus. Looks fine from my side.

Comment 4 Andres G. Aragoneses 2015-03-30 14:10:55 UTC

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?

Comment 5 Daniel Stone 2019-02-16 12:17:01 UTC

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.