On Mon, Jun 4, 2012 at 7:26 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote:
> On Mon, Jun 04, 2012 at 06:44:21PM +0300, Zeeshan Ali (Khattak) wrote:
>> From: "Zeeshan Ali (Khattak)" <zeeshanak@xxxxxxxxx>
>>
>> This function was adding the second list elements to new list first so
>> the order of elements in the new list was contrary to what user will
>> expect of this function (and all wrapper/using functions).
>
> This change makes sense to me, but since you looked at this code to fix a
> Boxes bug, you should explain what behaviour you were seeing without this
> patch, what this patch change, and why it's better now (or something in
> that spirit ;)
If the change makes sense anyways, I don't see the need to waste time
on justifying it.
> As I understand it, sound was not working in Windows 7 because the list of
> audio devices contained 2 elements, ich6 and ac97. Boxes arbitrarily picked
> the first element in the list which is ac97, but this one is not working.
> With your change, the list order is changed and ich6 is first. Since it's
> the more specific device (it's specified on the 'win7' node in
> windows.xml), this ordering makes sense even though it's not specified
> anywehere I could find in the documentation.
>
> However, the bigger question (if the above explanation is what you were
> seeing) is why was a non-working audio device present in the device list
> returned by libosinfo?
Good point! I don't know how to fix this in a non-intrusive and nice
way as win7 does inherit from vista and vista from NT. This actually
brings us to a more generic problem: How do we deal with device
support being dropped in a later version of the OS? Perhaps we could
introduce a new node/API for this:
<dropped-devices>
<device id="http://pciids.sourceforge.net/v2.2/pci.ids/8086/2415"/>
<!-- AC97 -->
</dropped-devices>
?
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
