[Libva] Fwd: FGLRX detection code overly restrictive

[Stephan Diestelhorst]

Eeek. this fell off the list. Sorry for that.

---------- Forwarded message ----------
From: Stephan Diestelhorst <stephan.diestelhorst at gmail.com>
Date: Sun, Oct 9, 2011 at 11:36 AM
Subject: Re: [Libva] FGLRX detection code overly restrictive
To: Gwenole Beauchesne <gb.devel at gmail.com>


Hi Gwenole,
 thanks for getting back so quickly.

On Sun, Oct 9, 2011 at 9:42 AM, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
> 2011/10/7 Stephan Diestelhorst <stephan.diestelhorst at gmail.com>:
>
>> This is the first bug: handing in a NULL pointer to strlen without checking.
>
> The check was done through the return value of va_GetDriverName().
> VA_FGLRXGetClientName() indeed has a bug that would make it return
> success even if no valid match was found.

Indeed, this reasoning sounds logical.

>> Eventually, this causes a mismatch in match_display in
>> libva/va/x11/va_fglrx.c such
>> that x11_dpy_name = ":0", test_dpy_name=":0.0" (and display_name being
>> ":0" in there)
>> which causes the comparison to fail and hence does not set the driver
>> name to fglrx,
>> but returns a success error code.
>
> That's another problem. AFAIK, in a single monitor system, we can
> assume :0 == :0.0. However, in a multi-monitor system, that won't hold
> true. Besides, an XvBA context would be screen dependent, if I
> remember correctly.

How does one detect whether this is a multi-monitor setup? According
to the X documentation :0 is equal to :0.0, since the first screen is chosen
by default. I'll try to incorporate that into a patch.

> The proper fixes would be:
> 1. Don't return success if no valid match was found.
> 2. Account for ":0" cases in a single monitor system.

Will hack sth together!

Stephan