API addition in Solid

[Matthias Kretz]

On Saturday 17 November 2007, John Tapsell wrote:
> Matthias,
>
>   I don't really understand the api doc comment.  If I change one
> piece of hardware, will the UDI of any _other_ hardware change?
>
>   Or do you mean that, say, 2 different usb headsets will have different
> UIDs?

Imagine your soundcard breaks and you replace it with a new one (different 
brand and type). With some luck (not) the UDI for the new card will be the 
same as for the old card. Any settings that were stored for the old card 
might not make sense for the new card anymore and you wonder why the system 
doesn't like your new hardware.

The main problem though is that you may not use the udi "globally". E.g. if 
you store udi's in KConfig files and then migrate to a new computer...

For your reading pleasure an excerpt from #hal:
[15:13] <Vir> HAL's udis are not unique enough - at least for sound devices
[15:15] <Vir> all HDA soundcards have the same udi - even if they have a 
different codec chip
[15:17] <Vir> in my case the contents 
of /sys/devices/pci0000:00/0000:00:1b.0/{subsystem_vendor,subsystem_device} 
should be in the udi
[15:18] <sjoerd> heh
[15:18] <sjoerd> Why?
[15:19] <Vir> because udi == unique device identifier?
[15:19] <sjoerd> not globally
[15:19] <sjoerd> and the curent udi contains the pci info already right
[15:19] <Vir> different chips should have a different udi, no?
[15:19] <sjoerd> different devices on the same machines should have different 
udi's
[15:20] <Vir> so can I even assume the udis will stay the same for a device if 
the user changes his hardware configuration?
[15:20] <sjoerd> You can't assume much about udi's at all
[15:20] <Vir> except that at the time I get them they're unique
[15:21] <Vir> :'(
[15:21] <sjoerd> Yeah, hal does some effort in making them reasonably unique
[15:21] <sjoerd> But no guarantees
[15:21] <sjoerd> But why do you need to know such low level hardware details 
in the first place
[15:22] <Vir> I need to store configuration for a given device
[15:22] <sjoerd> and you can get the pci.product_id and pci.vendor_id from 
other props then the udi
[15:22] <Vir> and somehow I need to identify the device
[15:22] <sjoerd> Right then the udi should be good enough.. When do you hit 
cases where it is not ?
[15:23] <Vir> well, I was trying to use it globally now
[15:23] <Vir> i.e. storing an initial preference for devices
[15:23] <sjoerd> right
[15:23] <sjoerd> In that case you might want to trigger of pci.product_id etc
[15:24] <Vir> like many soundcards have multiple devices and they need a 
reasonable initial ordering
[15:24] <sjoerd> Right
[15:24] <sjoerd> In that case indeed use the pci.product_id
[15:24] <sjoerd> UDI is the wrong thing here
[15:25] <Vir> pci.vendor_id + pci.product_id + pci.subsys_vendor_id + 
pci.subsys_product_id
[15:26] <Vir> the first two are part of the udi already
[15:26] <sjoerd> Yes but you can't rely on how the udi's are serialized
[15:26] <Vir> ok
[15:26] * Vir forgets about udis then
[15:26] <sjoerd> Well it's reasonably stable
[15:27] <sjoerd> But it's much better to indeed use those four properties to 
recognize the hardware
[15:27] <Vir> ok

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071117/f95ec3ad/attachment.sig>