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 ;) 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? Christophe
Attachment:
pgpXFVYRsSe8D.pgp
Description: PGP signature
