On 3/21/06, Robert Reif <reif@earthlink.net> wrote:
Tom Spear (Dustin Booker, Dustin Navea) wrote:
> Jesse Allen wrote:
>
>> On 3/20/06, Mike McCormack <mike@codeweavers.com> wrote:
>>
>>
>>> Dimi Paun wrote:
>>>
>>>
>>>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin
>>>> Navea) wrote:
>>>>
>>>>
>>>>
>>>>> clicking on the audio tab to check out bug 4051 first? Please!
>>>>>
>>>>
>>>> How about we fix the problem instead? :)
>>>>
>>>
>>> The best way to fix it is probably to rearrange the code so that the
>>> Audio tab shows, then there's a [Detect] button that the user can click
>>> to run the autodetect code that might crash. At least then the user
>>> can
>>> set their Wine Audio settings manually.
>>>
>>> Mike
>>>
>>>
>>>
>>
>>
>>
>> This is not enough, as when I click the audio tab, it will lock up in
>> the kernel. I already identified where it happens and patch the
>> kernel myself. I told the ALSA devs, but they haven't looked at why
>> certain register usage causes a lockup. So it remains in the stable
>> kernel who knows who else hits it.
>>
>> Jesse
>>
>>
>
> Which is why I agree with the ideas from Mike and Dimi AND Segin..
> Why not put an autodetect button, have the exception handler catch the
> crash if arts decides to die, and then still have a popup dialog for
> when arts is manually selected that tells users it is buggy and not
> recommended to use? That doesn't fix your specific problem Jesse, I
> know, but at least it keeps winecfg open when you click on the audio tab.
>
> Tom
>
>
>
The reason I added the probe of all drivers in winecfg was so that the
broken and marginal drivers would get used and hopefully fixed. Moving
the problem will just create different bugs: [BUG xxx] winecfg crashes
when autodetect button pressed or [BUG yyy] winecfg crashes when driver
xyz selected.
Yes, and I agree that that is a good idea, which is why I asked about putting a known issues page somewhere where a lot of users will see it. It wouldnt just have to be used for the issue mentioned above. It could be done for anything that is frequently reported. I'm going to go ahead and get started on putting it in tonight. Since it will be in the wiki, as the issues are fixed, they can be removed, and as other issues become more frequently reported, they can be added. I think it will be a good supplement to bugzilla and the appdb, as more people check out wiki's (as well as README's) than do the appdb, and so therefore they will see that the issue is already reported, and can find out what bug # it is instead of filing a duplicate bug. It also helps cut down on the number of bug submissions in the comments of the appdb..
Tom