On Sat, Nov 1, 2008 at 4:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Friday, October 31, 2008 4:01 am Thomas Hellström wrote:
>> Jesse Barnes wrote:
>> > This commit adds the core mode setting routines for use by DRM drivers to
>> > manage outputs and displays.  Originally based on the X.Org Randr 1.2
>> > implementation, the code has since been heavily changed by Dave Airlie
>> > with contributions by Jesse Barnes, Jakob Bornecrantz and others.
>> >
>> > This one should probably be split up a bit; I think the TTM stuff in
>> > particular could be factored out fairly easily.
>>
>> Jesse,
>> We must split out TTM from anything that goes into DRM next for now, as
>> we're about to re-add it in a device dependant
>> form with a well defined kernel only API. (This is probably going to
>> happen within a couple of weeks).
>>
>> A minimal user-space API will be added when there are drivers supporting
>> it. I guess the first one will be a reworked via driver following up
>> with other work.
>>
>> So for now, I guess the best thing is to strip the TTM parts completely
>> and not consider the drivers that rely on it.
>>
>> I have a patch lying around that strips TTM from modesetting-gem and
>> disables the build of radeon, radeon-ms and nouvea, if that would help...
>
> Yeah that would help a bit.  I'm not in a position to push those bits anyway,
> so it would be good if my next set of patches didn't have any TTM or radeon
> bits...
>

My tree in drm-rawhide shouldn't have many TTM + modeset commits.

My plan was to take the core modesetting additions patch
75432e26f0a14a30da437018938d4c04a8faa00e
db392921b6e5d051b6651c1f8d47875da789fb44

get a tree with just those in it, copy over the latest version of the
modesetting files from
the head of the branch and make that the base patch.

Then get the multi-master bits (can go before or after modesetting in theory).

Then drop the Intel driver on top.

Nearly all the work on drm-rawhide has been on radeon mm and kms so
the core kms code
hasn't see major amount of changes.

We should ignore radeon from an upstream perspective for the moment as
the TTM interfacing needs to happen first.

Dave.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to