From: Jeff M. <kd...@em...> - 2007-04-26 19:24:08
|
Hey there-- There are some misconceptions here that I'll try to clear up. Additionally, I got my hands on an iPod to do some testing with so I can show you some concrete examples. It's a long email, sit down with some coffee :-) > I think the concern over using hal if you have more than one ipod is > unfounded. This would be a udev problem that udev's rules would take care > of. > All devices are identified uniquely in hal, usually based off the device's serial number. There are no issues with multiple devices with hal. I'll admit I haven't really looked into how udev handles multiple matching devices, but I would imagine it handles it somewhat smartly. By the way -- I was throwing in the udev part for free. For my purposes (a unified way to determine which library to use to access a device) only a hal fdi file is necessary. So if you guys are concerned over multiple device support in udev, or simply don't want to muck with udev yet, then I'll focus only on hal for now. But if you'd like udev rules to go along with the hal fdi ones, I'm willing to do that as well. Also, I'll be able to test out multiple devices of the same type plugged in and see how udev reacts with a rules file, if you want to see its behavior. > The virtue of hal though (and I am sure that Jeff can correct me) is that > user's of gtkpod etc... would never need to know about the mountpoints or > device names of connected ipods as all that would be done through hal and > libgpod. > Yes, if used properly. I checked on this with one of the Solid guys on this and he said the following: "For an ipod, basically we'll get two devices: one having the interface portablemediaplayer and one having the interface volume (allowing to mount/unmount and know the mountpoint). The volume is child of the portablemediaplayer, so that's really easy to get all the info you need, both the "low level" mountpoint and the type of the media player to know to give it to libgpod." So theoretically, if gtkpod is watching hal itself or through some gnome daemon, when an iPod is plugged in, gtkpod could get the mountpoint information from hal. In fact, you could do this already, since hal kind of has a default rule for iPods :-) It's a bit different problem from the one I'm trying to solve. Just to clarify: what I'm trying to do is get information in hal about what libraries can handle what devices. iPods are a bit of a special case in that they're already somewhat handled cause somebody put a default rule in hal for them...in fact, for libgpod there's only two extra keys I'd add, at least initially. But in a general sense, my goal is that when a device is plugged into hal, and is identified as a portablemediaplayer device, the necessary information is exported through hal to allow applications and daemons watching hal to determine what library needs to be used to handle what device. I think this will be more clear later on when I show you my examples. > >From reading a little more, I believe the idea is thus: > - plug in ipod(s) > - udev detects them and gives them sensible device paths > Sure, if you'd like me to make you udev rules too -- as I said, they're not necessary for my goals, but I'm throwing them in for free (it's just busy work is all). > - hal picks up on udev's detection and identifies these new devices (based > on the .fdi files and info gleaned from device itself) before placing them > in its own database. > So far so good. > - gtkpod / amarok etc... are started and ask libgpod for details of all > available ipods connected to the system. > - libgpod interrogates the hal database using hal's api and determines the > number of ipods connected and where the mountpoints etc.. reside. This > info is passed back to gtkpod / amarok and these display the contents of > every ipod plugged in. > This is one possible scenario but not the one I envisioned. The reason is that users of KDE or Gnome generally already have daemons watching hardware that's plugged in. The way you described it, gtkpod/amarok/etc. would have to constantly be loaded and queried to determined if new iPods are connected. This information is going to come in via Solid/the_Gnome_equivalent anyways -- so why not use that information that's coming in already to figure out if the device is an iPod and if so load libgpod? The way you describe it above requires code to be added/modified in libgpod...the way I want to do it requires absolutely no change in libgpod (or any other library) other than providing the rules files. By the way, note that the two approaches are in no way mutually exclusive :-) > Pros sticking hal linking in libgpod > - linking low level hardware library with low level ipod handling library > (just seems sensible but might not be) > - avoid code duplication across different projects who use libgpod > You might avoid code duplication to some degree, but they'll still have to query libgpod for information. Alternately, they'll be getting fed information from some higher level daemon, which, although it's duplicated code more or less, they're going to be supporting anyways...so I don't think there's much reason to put it in libgpod unless, of course, you'd like to :-) There are still some good reasons for doing so. > Pros using hal at all > - track repositories in gtkpod would appear / disappear depending on what > devices were plugged in. For example, I tend to load gtkpod to add tracks > to my local repository even though my ipod is not plugged in. As such I > still see the ipod repository entry even though it is blank, ie. not > plugged in. This kind of thing would be avoided. > True. In fact, the hal key usb.serial could be used to uniquely identify the device. I may even export that value in some other standard way if usb.serial isn't portable across device types, since it's such a useful value to have. > - Users would not need to worry about setting up mount points or mounting > their ipods as this can be done automatically. > Yes, it could be, if you wanted to code it into libgpod; remember that distributions differ on where they want things to be mounted. I think sane device nodes are nice, but I'm not going to get into a mount point argument, and at the moment have no plans to put desired mount points into the fdi rules (they're often ignored anyways). > Cons > - Do all distros have udev/hal installed by default these days? > Yep. All desktop-oriented modern ones (and probably business ones like RHEL too). > - I think Jorg's question regarding linking gtkpod to hal is a fair one > and should be considered rather than using libgpod but is this the right > way to do it? > I don't see a reason why both are not good ideas. :-) But many people use libgpod that aren't using gtkpod. > - The model presented by hal from the ipod is only the model id of the usb > bus and not the ipod hence the need for libipoddevice to do some stuff > with scsi and xml in order to determine the model type (is this important > enough to worry about?) > I don't think it is, and honestly I don't know too much about libipoddevice. Although some models share IDs, they're generally just different capacities. Certainly for the purposes of identifying libgpod as the device handler it's good enough, and libgpod can then use libipoddevice or whatever (am I off the mark here?) to determine for sure. Before I get to the example, someone asked about portability. AFAIK currently udev and hal are not portable to Windows and Mac, no. But it still makes sense to have the fdi (and if you like udev rules) on Linux, where they can do good...so this could just be a check in the Makefile or such, so that it only installs the rules on Linux. Oh, or FreeBSD. Hal works on FreeBSD :-) (Note on the below example: Originally, I was going to use actual, real output. Unfortunately, I seem to have found one or two hal bugs while doing this that the developers have never seen before. They've confirmed that the fdi I wrote is correct, so they're looking into why it's not working...but it will be fixed. Hal works the vast majority of the time, I promise :-) In the meantime, I've fudged some of the second snippet as to what it will look like once hal is fixed). Now my example. Following is a snippet of output from lshal -lt using hal's current defaults (which include some detection of iPods): udi = '/org/freedesktop/Hal/devices/storage_serial_Apple_iPod_000A2700111D84F4' info.addons = {'hald-addon-storage'} (string list) portable_audio_player.output_formats = {'audio/mpeg', 'audio/aac'} (string list) portable_audio_player.storage_device = '/org/freedesktop/Hal/devices/storage_serial_Apple_iPod_000A2700111D84F4' (string) portable_audio_player.type = 'ipod' (string) portable_audio_player.access_method = 'storage' (string) I made a fdi file that has the following entry. A few things to note: the "libgpod.name" key is there to demonstrate that arbitrary key-value pairs can be added. So if you provide a fdi file you can add context information that your library can use. You might even be able to get rid of libipoddevice by doing some processing in the fdi file and adding appropriate keys :-) <match key="info.category" string="storage"> <match key="storage.vendor" contains="Apple"> <match key="storage.model" contains="iPod"> <match key="@storage.physical_device:usb.vendor_id" int="0x05ac"> <match key="@storage.physical_device:usb.product_id" int="0x1301"> <merge key="portable_audio_player.access_method" type="string">libgpod</merge> <append key="libgpod.name" type="string">iPod Shuffle (2G)</append> </match> </match> </match> </match> </match> Now when I reinserted the iPod, here's the same snippet as before (with a little helping hand until hal is fixed): udi = '/org/freedesktop/Hal/devices/storage_serial_Apple_iPod_000A2700111D84F4' info.addons = {'hald-addon-storage'} (string list) portable_audio_player.output_formats = {'audio/mpeg', 'audio/aac'} (string list) portable_audio_player.storage_device = '/org/freedesktop/Hal/devices/storage_serial_Apple_iPod_000A2700111D84F4' (string) portable_audio_player.type = 'ipod' (string) portable_audio_player.access_method = 'libgpod' (string) libgpod.name = 'iPod Shuffle (2G)' (string) Hope that makes things more clear. This way hal observers that see it's a portable media player will be able to identify which library should be used to open it, and any additional keys you guys want to assign to any particular device can be added arbitrarily. Thanks, Jeff > Think I have rambled enough. Let me know if I am way off the mark. > > Regards > > PGR > |