[Pm-utils] Video quirks without HAL or dbus

[Victor Lowther]

On Nov 4, 2008, at 7:55 AM, Richard Hughes <hughsient at gmail.com> wrote:

> On Tue, 2008-11-04 at 07:39 -0600, Victor Lowther wrote:
>> On Nov 4, 2008, at 7:22 AM, Richard Hughes <hughsient at gmail.com>  
>> wrote:
>>
>>> On Mon, 2008-11-03 at 03:55 -0600, Victor Lowther wrote:
>>>> This is a minimal prototype implementation of a tool that can be
>>>> used to
>>>> query the quirk database when HAL and dbus are not running.  I will
>>>> also
>>>> use it to test some ideas I ahve w.r.t how to best handle video
>>>> driver
>>>> and kernel revisions in the video quirks without having to patch  
>>>> HAL.
>>>
>>> I really don't think you should be parsing XML in shell script...  
>>> Keep
>>> pm-utils lean and simple. Also bear in mind that as drivers are  
>>> being
>>> converted to KMS (kernel mode setting) we'll need to rip out loads  
>>> of
>>> quirks long term anyway.
>>
>> This script is not going to be part of pm-utils. It might be part  
>> of a
>> seperate project at some point, and if that happens it will not try  
>> to
>> parse XML.
>
> Right, I don't think it's a pm-utils "core" function.

It is not a pm-utils function at all.

>
>> Ripping out quirks is definitly the wrong way to work with kernel  
>> mode
>> setting. It is better to add new --quirk-none quirks once we know and
>> have tested kernel and driver combinations on hardware that currently
>> requires quirks. I needed something easier to work with than hal  
>> rules
>> to test things with, and this is the yestbed I came up with.
>
> If the video hardware is working correctly with KMS, then you don't  
> need
> any quirks -- although I admit the number of drivers that do KMS 100%
> perfect I can count on the fingers of my third hand.

More to the point, the only even half working prototypes are for Intel  
and ATI graphics. nVidia and others seem to be absent so far.

>
>>> Quirks are still very needed to get things to work right now, but I
>>> don't think we need such an infrastructure around something that
>>> doesn't
>>> have a long term future on most video hardware.
>>
>> Well, I think that is an overly optimistic view right now, but I will
>> be happy to be proven wrong :)
>
> Here's trying. :-)
>
> Richard.
>
>