Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote:
> 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..

I sure hope all users will go look at this page first. But some how I
don't think they will. When we getting _exact_ duplicates with the same
summary and almost identical comments. I don't think users will bother to
look anywhere else.

But that will add extra work on our side to keep this list in synch. On
top of the usual stuff that we already do.

Vitaliy.