|
From: <la...@no...> - 2011-01-24 08:51:17
|
Hi Linus,
After testing libmtp1.04, about the solution to check whole new mtp device which is not in libmtp player list, we find that following udev rule does not apply to our devices when they are under Ovi Mode(under this mode, devices still get recognized as cameras):
ENV{ID_MTP_DEVICE}!="1", ATTR{bDeviceClass}=="00|06|ff", PROGRAM="/lib/udev/mtp-probe" /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULt=="1",
SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1",ENV{ID_MEDIA_PLAYER}="1"
On Nokia devices, it has a OVI mode, which includes more than one interface, and mtp interface is one of them. Under this mode, its device class is '0x02' (Communications and CDC Control, according to USB.org). Since OVI mode is the default mode on Nokia devices, we hope that our devices could be recognized as MTP device under OVI mode, just like it is under Windows.
Adding '02' to the 'ATTR{bDeviceClass}' of above rule would be a direct solution to this. But if we are worried that querying an interface descriptor of a device, would affect the device bootup time, esp, when this device has multi interfaces, we can firstly resort to the information under sysfs, without operating with this device, to check if it is a mtp device. If this check failed, then invoke 'mtp-probe' to do further check. What's your opinion? Thanks.
Regards,
Lan Liu
-----Original Message-----
From: ext Linus Walleij [mailto:lin...@gm...]
Sent: Monday, January 24, 2011 5:09 AM
To: lib...@li...
Cc: Li Feng.5 (Nokia-MS/Beijing); Tarvainen Miska (Nokia-MS/Beijing); Quadros Roger (Nokia-MS/Helsinki); Wang Hongyu (Nokia-MS/Beijing)
Subject: Re: [Libmtp-discuss] udev and libmtp: detect a new mtp device based on its USB interface descriptor
2011/1/23 Marcus Meissner <ma...@je...>:
> An important thing is btw to consider this is called for more devices than
> just MTP ones.
>
> - querying the interface descriptor string should be safe even on
> cheap chinese made USB junk. (other things might crash the devices)
Sadly no, people actually have reported problems with that when I tested
it in Fedora so I added a patch that:
- Only check class 0 (per interface), communications, PTP, and
vendor spec devices.
- On per-interface devices, only check it if they have atleast one
vendor spec interface.
- If it still fails to probe the OS decriptor, clear halt on EP0
(this was probably the real problem... the rest is perhaps
a bit overcautious.)
Microsoft likely has something similar, I remember the clear halt
requirement from some document vaguely.
> - time... Querying the descriptors takes time during bootup if already plugged
> in and people love faster booting these days.
>
> But I think udev is operating stuff in parallel, so this should not be an issue.
Dunno if it does that, anyway, since I implemented it in C now it
will atleast not spawn a shell for each device :-P
So this was sort of the best I could come up with...
The only remaining alternative is to go into the kernel and add
the probe code there (under much the same conditions I believe).
Yours,
Linus Walleij
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Libmtp-discuss mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libmtp-discuss
|