[PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Daniel Vetter]

Looking at the ioctl permission checks I noticed that it's impossible
to import gem buffers into a control nodes, and fd2handle/handle2fd
also don't work, so no joy with dma-bufs.

The only way to do anything with a control node is by drawing stuff
into a dumb buffer and displaying that. I suspect control nodes are an
entirely unused thing, and a cursory check shows that there does not
seem to be any callers of drmOpenControl nor of the other drmOpen
functions using DRM_MODE_CONTROL.

Since I don't like dead uabi, let's remove it. But since this would be
a really big change I think it's better to start out small by simply
not registering anything. We can garbage-collect the dead code later
on, once we're sure it's really not used anywhere.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_drv.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6efdba4993fc..f085e28ffc6f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
 		goto err_free;
 	}
 
-	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
-		ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
-		if (ret)
-			goto err_minors;
-	}
-
 	if (drm_core_check_feature(dev, DRIVER_RENDER)) {
 		ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
 		if (ret)
-- 
2.10.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: warning for drm: Nerf DRM_CONTROL nodes

[Patchwork]

== Series Details ==

Series: drm: Nerf DRM_CONTROL nodes
URL   : https://patchwork.freedesktop.org/series/14515/
State : warning

== Summary ==

Series 14515v1 drm: Nerf DRM_CONTROL nodes
https://patchwork.freedesktop.org/api/1.0/series/14515/revisions/1/mbox/

Test gem_ringfill:
        Subgroup basic-default-hang:
                timeout    -> PASS       (fi-ivb-3770)
        Subgroup basic-default-interruptible:
                incomplete -> PASS       (fi-ivb-3770)
Test kms_pipe_crc_basic:
        Subgroup bad-pipe:
                pass       -> DMESG-WARN (fi-ilk-650)
        Subgroup bad-source:
                pass       -> DMESG-WARN (fi-ilk-650)
        Subgroup hang-read-crc-pipe-a:
                pass       -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u     total:239  pass:224  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050     total:239  pass:199  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700     total:239  pass:211  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900     total:239  pass:211  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820     total:239  pass:207  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770      total:239  pass:219  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r     total:239  pass:218  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650       total:239  pass:182  dwarn:3   dfail:0   fail:0   skip:54 
fi-ivb-3520m     total:239  pass:216  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770      total:239  pass:216  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u     total:239  pass:217  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u     total:239  pass:225  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hq    total:239  pass:218  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k     total:239  pass:217  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hq    total:239  pass:225  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m     total:239  pass:206  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600      total:239  pass:205  dwarn:0   dfail:0   fail:0   skip:34 

56cae66b9bf88f7114ae9e526106aca1605c7fd0 drm-intel-nightly: 2016y-10m-28d-07h-26m-15s UTC integration manifest
9d01daa drm: Nerf DRM_CONTROL nodes

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2844/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Daniel Vetter]

On Fri, Oct 28, 2016 at 10:10:50AM +0200, Daniel Vetter wrote:
> Looking at the ioctl permission checks I noticed that it's impossible
> to import gem buffers into a control nodes, and fd2handle/handle2fd
> also don't work, so no joy with dma-bufs.
> 
> The only way to do anything with a control node is by drawing stuff
> into a dumb buffer and displaying that. I suspect control nodes are an
> entirely unused thing, and a cursory check shows that there does not
> seem to be any callers of drmOpenControl nor of the other drmOpen
> functions using DRM_MODE_CONTROL.
> 
> Since I don't like dead uabi, let's remove it. But since this would be
> a really big change I think it's better to start out small by simply
> not registering anything. We can garbage-collect the dead code later
> on, once we're sure it's really not used anywhere.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Applied with Dave's irc-ack to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6efdba4993fc..f085e28ffc6f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>  		goto err_free;
>  	}
>  
> -	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> -		ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
> -		if (ret)
> -			goto err_minors;
> -	}
> -
>  	if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>  		ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>  		if (ret)
> -- 
> 2.10.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Mike Lothian]

[-- Attachment #1.1: Type: text/plain, Size: 2320 bytes --]

Hi

This patch (in drm-next and drm-intel-nightly) stops my system from
booting, I don't see any errors, just a black screen and a reboot after the
kernel has been selected

I have confirmed that reverting this patch gets those two branches working
again

Sorry to be the bearer of bad news - I'm guessing this is PRIME related

Mike

On Thu, 17 Nov 2016 at 07:42 Daniel Vetter <daniel@ffwll.ch> wrote:

On Fri, Oct 28, 2016 at 10:10:50AM +0200, Daniel Vetter wrote:
> Looking at the ioctl permission checks I noticed that it's impossible
> to import gem buffers into a control nodes, and fd2handle/handle2fd
> also don't work, so no joy with dma-bufs.
>
> The only way to do anything with a control node is by drawing stuff
> into a dumb buffer and displaying that. I suspect control nodes are an
> entirely unused thing, and a cursory check shows that there does not
> seem to be any callers of drmOpenControl nor of the other drmOpen
> functions using DRM_MODE_CONTROL.
>
> Since I don't like dead uabi, let's remove it. But since this would be
> a really big change I think it's better to start out small by simply
> not registering anything. We can garbage-collect the dead code later
> on, once we're sure it's really not used anywhere.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Applied with Dave's irc-ack to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6efdba4993fc..f085e28ffc6f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>               goto err_free;
>       }
>
> -     if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> -             ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
> -             if (ret)
> -                     goto err_minors;
> -     }
> -
>       if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>               ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>               if (ret)
> --
> 2.10.1
>

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[-- Attachment #1.2: Type: text/html, Size: 4904 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Michel Dänzer]

On 06/12/16 10:42 AM, Mike Lothian wrote:
> Hi
> 
> This patch (in drm-next and drm-intel-nightly) stops my system from
> booting, I don't see any errors, just a black screen and a reboot after
> the kernel has been selected 
> 
> I have confirmed that reverting this patch gets those two branches
> working again
> 
> Sorry to be the bearer of bad news - I'm guessing this is PRIME related

It's not. You can choose between

https://patchwork.freedesktop.org/patch/125754/

or

https://patchwork.freedesktop.org/patch/125644/

for the fix. :)


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Mike Lothian]

[-- Attachment #1.1: Type: text/plain, Size: 854 bytes --]

Thank you!

On Tue, 6 Dec 2016 at 01:47 Michel Dänzer <michel@daenzer.net> wrote:

> On 06/12/16 10:42 AM, Mike Lothian wrote:
> > Hi
> >
> > This patch (in drm-next and drm-intel-nightly) stops my system from
> > booting, I don't see any errors, just a black screen and a reboot after
> > the kernel has been selected
> >
> > I have confirmed that reverting this patch gets those two branches
> > working again
> >
> > Sorry to be the bearer of bad news - I'm guessing this is PRIME related
>
> It's not. You can choose between
>
> https://patchwork.freedesktop.org/patch/125754/
>
> or
>
> https://patchwork.freedesktop.org/patch/125644/
>
> for the fix. :)
>
>
> --
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
>

[-- Attachment #1.2: Type: text/html, Size: 1998 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

Hi!

This patch breaks the vmwgfx resolutionKMS daemon which opens a control
node to tell DRM about the monitor layout...

/Thomas


On 10/28/2016 10:10 AM, Daniel Vetter wrote:
> Looking at the ioctl permission checks I noticed that it's impossible
> to import gem buffers into a control nodes, and fd2handle/handle2fd
> also don't work, so no joy with dma-bufs.
>
> The only way to do anything with a control node is by drawing stuff
> into a dumb buffer and displaying that. I suspect control nodes are an
> entirely unused thing, and a cursory check shows that there does not
> seem to be any callers of drmOpenControl nor of the other drmOpen
> functions using DRM_MODE_CONTROL.
>
> Since I don't like dead uabi, let's remove it. But since this would be
> a really big change I think it's better to start out small by simply
> not registering anything. We can garbage-collect the dead code later
> on, once we're sure it's really not used anywhere.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_drv.c | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6efdba4993fc..f085e28ffc6f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>  		goto err_free;
>  	}
>  
> -	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> -		ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
> -		if (ret)
> -			goto err_minors;
> -	}
> -
>  	if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>  		ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>  		if (ret)


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

So I think we need a quick revert of this commit or a quick stable
follow-up to unbreak things on our side.

/Thomas


On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
> Hi!
>
> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
> node to tell DRM about the monitor layout...
>
> /Thomas
>
>
> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>> Looking at the ioctl permission checks I noticed that it's impossible
>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>> also don't work, so no joy with dma-bufs.
>>
>> The only way to do anything with a control node is by drawing stuff
>> into a dumb buffer and displaying that. I suspect control nodes are an
>> entirely unused thing, and a cursory check shows that there does not
>> seem to be any callers of drmOpenControl nor of the other drmOpen
>> functions using DRM_MODE_CONTROL.
>>
>> Since I don't like dead uabi, let's remove it. But since this would be
>> a really big change I think it's better to start out small by simply
>> not registering anything. We can garbage-collect the dead code later
>> on, once we're sure it's really not used anywhere.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> ---
>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 6efdba4993fc..f085e28ffc6f 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>  		goto err_free;
>>  	}
>>  
>> -	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> -		ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>> -		if (ret)
>> -			goto err_minors;
>> -	}
>> -
>>  	if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>  		ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>  		if (ret)
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

So I think we need a quick revert of this commit or a quick stable
follow-up to unbreak things on our side.

/Thomas


On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
> Hi!
>
> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
> node to tell DRM about the monitor layout...
>
> /Thomas
>
>
> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>> Looking at the ioctl permission checks I noticed that it's impossible
>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>> also don't work, so no joy with dma-bufs.
>>
>> The only way to do anything with a control node is by drawing stuff
>> into a dumb buffer and displaying that. I suspect control nodes are an
>> entirely unused thing, and a cursory check shows that there does not
>> seem to be any callers of drmOpenControl nor of the other drmOpen
>> functions using DRM_MODE_CONTROL.
>>
>> Since I don't like dead uabi, let's remove it. But since this would be
>> a really big change I think it's better to start out small by simply
>> not registering anything. We can garbage-collect the dead code later
>> on, once we're sure it's really not used anywhere.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> ---
>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 6efdba4993fc..f085e28ffc6f 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>  		goto err_free;
>>  	}
>>  
>> -	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> -		ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>> -		if (ret)
>> -			goto err_minors;
>> -	}
>> -
>>  	if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>  		ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>  		if (ret)
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Daniel Vetter]

On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.

I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your control tool is
using (i.e. which ioctl), plus links to the source code for future
references. Also not sold on the immediate revert, this stuff has been
merged since months.
-Daniel

>
> /Thomas
>
>
> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>> Hi!
>>
>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>> node to tell DRM about the monitor layout...
>>
>> /Thomas
>>
>>
>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>> Looking at the ioctl permission checks I noticed that it's impossible
>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>> also don't work, so no joy with dma-bufs.
>>>
>>> The only way to do anything with a control node is by drawing stuff
>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>> entirely unused thing, and a cursory check shows that there does not
>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>> functions using DRM_MODE_CONTROL.
>>>
>>> Since I don't like dead uabi, let's remove it. But since this would be
>>> a really big change I think it's better to start out small by simply
>>> not registering anything. We can garbage-collect the dead code later
>>> on, once we're sure it's really not used anywhere.
>>>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>>  1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 6efdba4993fc..f085e28ffc6f 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>>              goto err_free;
>>>      }
>>>
>>> -    if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>> -            ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>> -            if (ret)
>>> -                    goto err_minors;
>>> -    }
>>> -
>>>      if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>>              ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>>              if (ret)
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Daniel Vetter]

On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.

I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your control tool is
using (i.e. which ioctl), plus links to the source code for future
references. Also not sold on the immediate revert, this stuff has been
merged since months.
-Daniel

>
> /Thomas
>
>
> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>> Hi!
>>
>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>> node to tell DRM about the monitor layout...
>>
>> /Thomas
>>
>>
>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>> Looking at the ioctl permission checks I noticed that it's impossible
>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>> also don't work, so no joy with dma-bufs.
>>>
>>> The only way to do anything with a control node is by drawing stuff
>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>> entirely unused thing, and a cursory check shows that there does not
>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>> functions using DRM_MODE_CONTROL.
>>>
>>> Since I don't like dead uabi, let's remove it. But since this would be
>>> a really big change I think it's better to start out small by simply
>>> not registering anything. We can garbage-collect the dead code later
>>> on, once we're sure it's really not used anywhere.
>>>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>>  1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 6efdba4993fc..f085e28ffc6f 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>>              goto err_free;
>>>      }
>>>
>>> -    if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>> -            ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>> -            if (ret)
>>> -                    goto err_minors;
>>> -    }
>>> -
>>>      if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>>              ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>>              if (ret)
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

No.

IMO Not fixing this immediately through stable is out of the question.
The deal is that we don't break userspace.
Having said that, I'm not against a long term vmwgfx-only solution. But
let's fix this now.

Admittedly we missed testing this but you got to understand that not all
developer teams have a multitude of
developers (we have on average one for the whole linux graphics driver
stack except GL), and the bug
doesn't show up for QE on regression testing unless they run
gnome-sheel/Wayland which they currently don't, and I guess they've been
focused on the fb2 regression.

It's no secret that we've been using the control nodes for some time.
The CONTROL_ALLOW is present in the
driver private ioctls and the commit has been there since 2016.

The user-space code has been present in vmware-tools also since that
commit and due to the long release cycles of
open-vm-tools the open-vm-tools version was just about to be released.
It's necessary for non-xorg

/Thomas


On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>
>> /Thomas
>>
>>
>> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>>> Hi!
>>>
>>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>>> node to tell DRM about the monitor layout...
>>>
>>> /Thomas
>>>
>>>
>>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>>> Looking at the ioctl permission checks I noticed that it's impossible
>>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>>> also don't work, so no joy with dma-bufs.
>>>>
>>>> The only way to do anything with a control node is by drawing stuff
>>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>>> entirely unused thing, and a cursory check shows that there does not
>>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>>> functions using DRM_MODE_CONTROL.
>>>>
>>>> Since I don't like dead uabi, let's remove it. But since this would be
>>>> a really big change I think it's better to start out small by simply
>>>> not registering anything. We can garbage-collect the dead code later
>>>> on, once we're sure it's really not used anywhere.
>>>>
>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>>> ---
>>>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>>>  1 file changed, 6 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>>> index 6efdba4993fc..f085e28ffc6f 100644
>>>> --- a/drivers/gpu/drm/drm_drv.c
>>>> +++ b/drivers/gpu/drm/drm_drv.c
>>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>>>              goto err_free;
>>>>      }
>>>>
>>>> -    if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>>> -            ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>>> -            if (ret)
>>>> -                    goto err_minors;
>>>> -    }
>>>> -
>>>>      if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>>>              ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>>>              if (ret)
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>

DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

No.

IMO Not fixing this immediately through stable is out of the question.
The deal is that we don't break userspace.
Having said that, I'm not against a long term vmwgfx-only solution. But
let's fix this now.

Admittedly we missed testing this but you got to understand that not all
developer teams have a multitude of
developers (we have on average one for the whole linux graphics driver
stack except GL), and the bug
doesn't show up for QE on regression testing unless they run
gnome-sheel/Wayland which they currently don't, and I guess they've been
focused on the fb2 regression.

It's no secret that we've been using the control nodes for some time.
The CONTROL_ALLOW is present in the
driver private ioctls and the commit has been there since 2016.

The user-space code has been present in vmware-tools also since that
commit and due to the long release cycles of
open-vm-tools the open-vm-tools version was just about to be released.
It's necessary for non-xorg

/Thomas


On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>
>> /Thomas
>>
>>
>> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>>> Hi!
>>>
>>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>>> node to tell DRM about the monitor layout...
>>>
>>> /Thomas
>>>
>>>
>>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>>> Looking at the ioctl permission checks I noticed that it's impossible
>>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>>> also don't work, so no joy with dma-bufs.
>>>>
>>>> The only way to do anything with a control node is by drawing stuff
>>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>>> entirely unused thing, and a cursory check shows that there does not
>>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>>> functions using DRM_MODE_CONTROL.
>>>>
>>>> Since I don't like dead uabi, let's remove it. But since this would be
>>>> a really big change I think it's better to start out small by simply
>>>> not registering anything. We can garbage-collect the dead code later
>>>> on, once we're sure it's really not used anywhere.
>>>>
>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>>> ---
>>>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>>>  1 file changed, 6 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>>> index 6efdba4993fc..f085e28ffc6f 100644
>>>> --- a/drivers/gpu/drm/drm_drv.c
>>>> +++ b/drivers/gpu/drm/drm_drv.c
>>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>>>              goto err_free;
>>>>      }
>>>>
>>>> -    if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>>> -            ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>>> -            if (ret)
>>>> -                    goto err_minors;
>>>> -    }
>>>> -
>>>>      if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>>>              ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>>>              if (ret)
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[David Airlie]

> 
> No.
> 
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
> 
> Admittedly we missed testing this but you got to understand that not all
> developer teams have a multitude of
> developers (we have on average one for the whole linux graphics driver
> stack except GL), and the bug
> doesn't show up for QE on regression testing unless they run
> gnome-sheel/Wayland which they currently don't, and I guess they've been
> focused on the fb2 regression.
> 
> It's no secret that we've been using the control nodes for some time.
> The CONTROL_ALLOW is present in the
> driver private ioctls and the commit has been there since 2016.
> 
> The user-space code has been present in vmware-tools also since that
> commit and due to the long release cycles of
> open-vm-tools the open-vm-tools version was just about to be released.
> It's necessary for non-xorg

can you send a revert against drm-next? I'm not sure how clean it will be.

there might be an intermediate step.

Then can we port vmtools of this behaviour, not even sure what it is doing.

Dave.

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[David Airlie]

> 
> No.
> 
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
> 
> Admittedly we missed testing this but you got to understand that not all
> developer teams have a multitude of
> developers (we have on average one for the whole linux graphics driver
> stack except GL), and the bug
> doesn't show up for QE on regression testing unless they run
> gnome-sheel/Wayland which they currently don't, and I guess they've been
> focused on the fb2 regression.
> 
> It's no secret that we've been using the control nodes for some time.
> The CONTROL_ALLOW is present in the
> driver private ioctls and the commit has been there since 2016.
> 
> The user-space code has been present in vmware-tools also since that
> commit and due to the long release cycles of
> open-vm-tools the open-vm-tools version was just about to be released.
> It's necessary for non-xorg

can you send a revert against drm-next? I'm not sure how clean it will be.

there might be an intermediate step.

Then can we port vmtools of this behaviour, not even sure what it is doing.

Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed testing this but you got to understand that not all
>> developer teams have a multitude of
>> developers (we have on average one for the whole linux graphics driver
>> stack except GL), and the bug
>> doesn't show up for QE on regression testing unless they run
>> gnome-sheel/Wayland which they currently don't, and I guess they've been
>> focused on the fb2 regression.
>>
>> It's no secret that we've been using the control nodes for some time.
>> The CONTROL_ALLOW is present in the
>> driver private ioctls and the commit has been there since 2016.
>>
>> The user-space code has been present in vmware-tools also since that
>> commit and due to the long release cycles of
>> open-vm-tools the open-vm-tools version was just about to be released.
>> It's necessary for non-xorg
> can you send a revert against drm-next? I'm not sure how clean it will be.
>
> there might be an intermediate step.
>
> Then can we port vmtools of this behaviour, not even sure what it is doing.
>
> Dave.

So after a quick investigation of the impact it looks like the daemon
patch was pulled out of the Fedora open-vm-tools update in time. This
limits the impact to within VMware where we can update the daemon code
and rerun the test cycle. I've posted a patch that makes it possible for
us to use render-nodes instead of control nodes.

/Thomas

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed testing this but you got to understand that not all
>> developer teams have a multitude of
>> developers (we have on average one for the whole linux graphics driver
>> stack except GL), and the bug
>> doesn't show up for QE on regression testing unless they run
>> gnome-sheel/Wayland which they currently don't, and I guess they've been
>> focused on the fb2 regression.
>>
>> It's no secret that we've been using the control nodes for some time.
>> The CONTROL_ALLOW is present in the
>> driver private ioctls and the commit has been there since 2016.
>>
>> The user-space code has been present in vmware-tools also since that
>> commit and due to the long release cycles of
>> open-vm-tools the open-vm-tools version was just about to be released.
>> It's necessary for non-xorg
> can you send a revert against drm-next? I'm not sure how clean it will be.
>
> there might be an intermediate step.
>
> Then can we port vmtools of this behaviour, not even sure what it is doing.
>
> Dave.

So after a quick investigation of the impact it looks like the daemon
patch was pulled out of the Fedora open-vm-tools update in time. This
limits the impact to within VMware where we can update the daemon code
and rerun the test cycle. I've posted a patch that makes it possible for
us to use render-nodes instead of control nodes.

/Thomas



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>

https://cgit.freedesktop.org/~thomash/open-vm-tools/commit/?h=feature/thellstrom/resolutionKMS&id=9bf65a22d5a06d3a706bc14578619a56e06f8a24

/Thomas

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>

https://cgit.freedesktop.org/~thomash/open-vm-tools/commit/?h=feature/thellstrom/resolutionKMS&id=9bf65a22d5a06d3a706bc14578619a56e06f8a24

/Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx