Radeon support state in libkms

Radeon support state in libkms

[Alexandre Demers]

Hi,

I was looking at the radeon support state in libkms and I found out the
following patch was proposed back in September, but never commented nor
merged. The patch was submitted by nobled.

http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html

I applied it on the latest drm git version without any problem and
compilation looks fine. Is there a reason preventing it from being merged?

If it needs testing, make your suggestion, I'll gladly make my best to
test it.

-- 
Alexandre Demers

Re: Radeon support state in libkms

[James Simmons]

> I was looking at the radeon support state in libkms and I found out the
> following patch was proposed back in September, but never commented nor
> merged. The patch was submitted by nobled.
> 
> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
> 
> I applied it on the latest drm git version without any problem and
> compilation looks fine. Is there a reason preventing it from being merged?
> 
> If it needs testing, make your suggestion, I'll gladly make my best to
> test it.

Good point. Is KMS dead? Anyone?

Re: Radeon support state in libkms

[Corbin Simpson]

On Wed, Feb 9, 2011 at 6:49 AM, James Simmons <jsimmons@infradead.org> wrote:
>
>> I was looking at the radeon support state in libkms and I found out the
>> following patch was proposed back in September, but never commented nor
>> merged. The patch was submitted by nobled.
>>
>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
>>
>> I applied it on the latest drm git version without any problem and
>> compilation looks fine. Is there a reason preventing it from being merged?
>>
>> If it needs testing, make your suggestion, I'll gladly make my best to
>> test it.
>
> Good point. Is KMS dead? Anyone?

I was seriously hoping that Dave's dumb buffer API would go upstream
and that libkms would be able to use that generic path for all KMS
drivers, rather than needing shim code for every driver it supports.

That said, yeah, the libkms maintainer probably should pull that code
in. Who is that, anyway?

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude@gmail.com>

Re: Radeon support state in libkms

[Jakob Bornecrantz]

On Wed, Feb 9, 2011 at 7:35 PM, Corbin Simpson
<mostawesomedude@gmail.com> wrote:
> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons <jsimmons@infradead.org> wrote:
>>
>>> I was looking at the radeon support state in libkms and I found out the
>>> following patch was proposed back in September, but never commented nor
>>> merged. The patch was submitted by nobled.
>>>
>>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
>>>
>>> I applied it on the latest drm git version without any problem and
>>> compilation looks fine. Is there a reason preventing it from being merged?
>>>
>>> If it needs testing, make your suggestion, I'll gladly make my best to
>>> test it.
>>
>> Good point. Is KMS dead? Anyone?
>
> I was seriously hoping that Dave's dumb buffer API would go upstream
> and that libkms would be able to use that generic path for all KMS
> drivers, rather than needing shim code for every driver it supports.
>
> That said, yeah, the libkms maintainer probably should pull that code
> in. Who is that, anyway?
>
> ~ C.

That would probably be me.

The "core" libkms changes are rb/acked and the radeon changes looks
good so just go ahead and commit them anyways. Nobled do you have
commit access to the drm repo?

Cheers Jakob.

Re: Radeon support state in libkms

[Alexandre Demers]

On 11-02-11 06:21 AM, Jakob Bornecrantz wrote:
> On Wed, Feb 9, 2011 at 7:35 PM, Corbin Simpson
> <mostawesomedude@gmail.com> wrote:
>> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons <jsimmons@infradead.org> wrote:
>>>> I was looking at the radeon support state in libkms and I found out the
>>>> following patch was proposed back in September, but never commented nor
>>>> merged. The patch was submitted by nobled.
>>>>
>>>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
>>>>
>>>> I applied it on the latest drm git version without any problem and
>>>> compilation looks fine. Is there a reason preventing it from being merged?
>>>>
>>>> If it needs testing, make your suggestion, I'll gladly make my best to
>>>> test it.
>>> Good point. Is KMS dead? Anyone?
>> I was seriously hoping that Dave's dumb buffer API would go upstream
>> and that libkms would be able to use that generic path for all KMS
>> drivers, rather than needing shim code for every driver it supports.
>>
>> That said, yeah, the libkms maintainer probably should pull that code
>> in. Who is that, anyway?
>>
>> ~ C.
> That would probably be me.
>
> The "core" libkms changes are rb/acked and the radeon changes looks
> good so just go ahead and commit them anyways. Nobled do you have
> commit access to the drm repo?
>
> Cheers Jakob.

I don't think Nobled has commit access. But to be sure, I'm adding it to
the conversation. ;)

-- 
Alexandre Demers

Re: Radeon support state in libkms

[nobled]

On Tue, Feb 15, 2011 at 9:17 AM, Alexandre Demers
<alexandre.f.demers@gmail.com> wrote:
> On 11-02-11 06:21 AM, Jakob Bornecrantz wrote:
>> On Wed, Feb 9, 2011 at 7:35 PM, Corbin Simpson
>> <mostawesomedude@gmail.com> wrote:
>>> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons <jsimmons@infradead.org> wrote:
>>>>> I was looking at the radeon support state in libkms and I found out the
>>>>> following patch was proposed back in September, but never commented nor
>>>>> merged. The patch was submitted by nobled.
>>>>>
>>>>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
>>>>>
>>>>> I applied it on the latest drm git version without any problem and
>>>>> compilation looks fine. Is there a reason preventing it from being merged?
>>>>>
>>>>> If it needs testing, make your suggestion, I'll gladly make my best to
>>>>> test it.
>>>> Good point. Is KMS dead? Anyone?
>>> I was seriously hoping that Dave's dumb buffer API would go upstream
>>> and that libkms would be able to use that generic path for all KMS
>>> drivers, rather than needing shim code for every driver it supports.
>>>
>>> That said, yeah, the libkms maintainer probably should pull that code
>>> in. Who is that, anyway?
>>>
>>> ~ C.
>> That would probably be me.
>>
>> The "core" libkms changes are rb/acked and the radeon changes looks
>> good so just go ahead and commit them anyways. Nobled do you have
>> commit access to the drm repo?
>>
>> Cheers Jakob.
>
> I don't think Nobled has commit access. But to be sure, I'm adding it to
> the conversation. ;)
>
> --
> Alexandre Demers
>
>
>
>

Haha, no, no commit access. (not subscribed on dri-devel, either, so
thanks for the CC)

But while I'm here, is there any advice anywhere for getting patches
noticed a little... sooner? 'Cause I have a whole bunch of *other*
months-old mesa-dev patches nobody's committed yet.

Re: Radeon support state in libkms

[Jakob Bornecrantz]

On Wed, Feb 16, 2011 at 7:40 PM, nobled <nobled@dreamwidth.org> wrote:
> On Tue, Feb 15, 2011 at 9:17 AM, Alexandre Demers
> <alexandre.f.demers@gmail.com> wrote:
>> On 11-02-11 06:21 AM, Jakob Bornecrantz wrote:
>>> On Wed, Feb 9, 2011 at 7:35 PM, Corbin Simpson
>>> <mostawesomedude@gmail.com> wrote:
>>>> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons <jsimmons@infradead.org> wrote:
>>>>>> I was looking at the radeon support state in libkms and I found out the
>>>>>> following patch was proposed back in September, but never commented nor
>>>>>> merged. The patch was submitted by nobled.
>>>>>>
>>>>>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
>>>>>>
>>>>>> I applied it on the latest drm git version without any problem and
>>>>>> compilation looks fine. Is there a reason preventing it from being merged?
>>>>>>
>>>>>> If it needs testing, make your suggestion, I'll gladly make my best to
>>>>>> test it.
>>>>> Good point. Is KMS dead? Anyone?
>>>> I was seriously hoping that Dave's dumb buffer API would go upstream
>>>> and that libkms would be able to use that generic path for all KMS
>>>> drivers, rather than needing shim code for every driver it supports.
>>>>
>>>> That said, yeah, the libkms maintainer probably should pull that code
>>>> in. Who is that, anyway?
>>>>
>>>> ~ C.
>>> That would probably be me.
>>>
>>> The "core" libkms changes are rb/acked and the radeon changes looks
>>> good so just go ahead and commit them anyways. Nobled do you have
>>> commit access to the drm repo?
>>>
>>> Cheers Jakob.
>>
>> I don't think Nobled has commit access. But to be sure, I'm adding it to
>> the conversation. ;)
>>
>> --
>> Alexandre Demers
>>
>>
>>
>>
>
> Haha, no, no commit access. (not subscribed on dri-devel, either, so
> thanks for the CC)

Do I have your sob, for the patch?

>
> But while I'm here, is there any advice anywhere for getting patches
> noticed a little... sooner? 'Cause I have a whole bunch of *other*
> months-old mesa-dev patches nobody's committed yet.

Poke us more, sorry sometimes we are just bussy with work...

Cheers Jakob.

Re: Radeon support state in libkms

[James Simmons]

> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons <jsimmons@infradead.org> wrote:
> >
> >> I was looking at the radeon support state in libkms and I found out the
> >> following patch was proposed back in September, but never commented nor
> >> merged. The patch was submitted by nobled.
> >>
> >> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
> >>
> >> I applied it on the latest drm git version without any problem and
> >> compilation looks fine. Is there a reason preventing it from being merged?
> >>
> >> If it needs testing, make your suggestion, I'll gladly make my best to
> >> test it.
> >
> > Good point. Is KMS dead? Anyone?
> 
> I was seriously hoping that Dave's dumb buffer API would go upstream
> and that libkms would be able to use that generic path for all KMS
> drivers, rather than needing shim code for every driver it supports.

The email suggest it is highly discouraged to use that api for anything 
accelerated. Also the one thing missing is the ablity to target which pool 
the memory comes from. I like to be able to pick VRAM or pci DMA etc.
 
> That said, yeah, the libkms maintainer probably should pull that code
> in. Who is that, anyway?

I see in the following email he lives.

Re: Radeon support state in libkms

[James Simmons]

> > But while I'm here, is there any advice anywhere for getting patches
> > noticed a little... sooner? 'Cause I have a whole bunch of *other*
> > months-old mesa-dev patches nobody's committed yet.
> 
> Poke us more, sorry sometimes we are just bussy with work...

Awesome. Now I know who to send patches to.