Security update carried along a broken i810 driver for Intel 830 and up

[Jim Cornette]

Alex Deucher wrote:

>On 9/20/05, Jim Cornette <jim-cornette at insight.rr.com> wrote:
>  
>
>>Kristian Høgsberg wrote:
>>
>>    
>>
>>>Jim Cornette wrote:
>>>...
>>>
>>>      
>>>
>>>>Are there any plans to seperate the driver into at least three driver
>>>>versions to allow these video cards to find a safe zone instead of
>>>>changes for the 830 breaking the 815 and such?
>>>>
>>>>Just an idea, since I have the low end and middle road Intel video
>>>>cards .
>>>>        
>>>>
>>>The issue here isn't that the different Intel chipsets are supported
>>>using one unified driver.  The problem is that we shipped a Fedora
>>>update which contained a security fix and a number of other fixes.
>>>One of these other fixes happened to introduce a regression on all
>>>Intel boards, but the problem was in the general linux pci code and
>>>would have affected all Intel chipsets even if the driver was split
>>>into three pieces.
>>>
>>>A new update should be out soon, and in the meantime I've put up i386
>>>RPMs here:
>>>
>>>    http://people.redhat.com/krh/xorg-x11
>>>
>>>for people to test.  See also:
>>>
>>>    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750
>>>    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168752
>>>
>>>Thanks,
>>>Kristian
>>>      
>>>
>>The computer with the Intel 815 worked with the PCI coding problem. The
>>security update and the fix for the Intel driver was successful with the
>>Intel 865G. Thanks for the quick resolution to the problem.
>>
>>With the security update out of the way and the pci code cleaned up a
>>bit. It still makes sense to split up the driver into 815, 830 and 915
>>to allow code to be taylored for each card that has different
>>capabilities. It also makes sense since older generations of Intel video
>>cards won't burden the advancement of next generation cards by needing
>>code carried on to maintain workability for the older chipsets.
>>
>>When the code was broken for the 810/815 portion of the driver, my 865G
>>video card started working and the random lockups ceased for the 865G.
>>Fortunately, when the code for the 810/815 was fixed, the 865G still
>>remained lockup free.
>>
>>With the latest breakage for I830 and above video cards while the Intel
>>815 worked in my tests, the thought of splitting off the driver for low,
>>medium and higher capability seperate drivers came to mind again.
>>
>>Also, when the i810 driver was broken for the Intel 815, I chanced
>>across a website that provided seperate drivers for the i810/815 and
>>another for the 830. I believe there was a seperate driver for the Intel
>>915 on the snapshotted drivers page.
>>
>>The driver on that site worked to bypass the problem. I can't remember
>>if it was the refresh or the total breakage of the driver. I believe a
>>change was made in the driver code for dual head with the 830 card at
>>the time the driver broke for the Intel 815 video my computer has as
>>builtin video.
>>
>>Just a though since I feel the scheme would be better.
>>    
>>
>
>I would actually argue that it's better to keep them all as one
>driver.  the chips are all so similar most of the code would be
>redundant between the drivers and if you found a bug you'd potentially
>have to fix it in 3 places instead of one.  Other drivers could stand
>to be merged as well, however the lack of resources has prevented it. 
>For example, s3, s3virge and savage could be merged, as could r128 and
>radeon.
>
>Alex
>  
>
The code might be redundant in many places and this code could be 
contained in a common file to prevent having to change it in many 
places. For the code that is is different for the chipsets, it can be 
contained within independent code files. Then for creating the compiled 
drivers, three different versions can be made.

I only have the Intel 815 and the Intel 865G to compare videocards with. 
The functionality and the way the video cards react to changes in the 
code to enhance or to bugfix another chipset is totally unrelated to 
each other. I have only seen one version effected by any particular bug 
at a time. Developing three different drivers sounds like a realistic 
goal to me. If the code uses 90 percent plus common but deviates 
according to the best performance fo each videocard.

I have not examined the code yet. I guess there are advantages to 
merging and into maintaining seperate drivers for cards with different 
reactions to common driver changes.

I'll examine the code, though I would probably not realize what all is 
happening within the source.

Thanks,

Jim

-- 
QOTD:
	If it's too loud, you're too old.