* [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes
@ 2016-10-28 8:10 Daniel Vetter
2016-10-28 8:45 ` ✗ Fi.CI.BAT: warning for " Patchwork
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Daniel Vetter @ 2016-10-28 8:10 UTC (permalink / raw)
To: Intel Graphics Development, DRI Development; +Cc: Daniel Vetter, 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
^ permalink raw reply related [flat|nested] 19+ messages in thread* ✗ Fi.CI.BAT: warning for drm: Nerf DRM_CONTROL nodes 2016-10-28 8:10 [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Daniel Vetter @ 2016-10-28 8:45 ` Patchwork 2016-11-17 7:42 ` [PATCH] [RFC] " Daniel Vetter 2017-02-19 14:54 ` Thomas Hellstrom 2 siblings, 0 replies; 19+ messages in thread From: Patchwork @ 2016-10-28 8:45 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx == 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2016-10-28 8:10 [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Daniel Vetter 2016-10-28 8:45 ` ✗ Fi.CI.BAT: warning for " Patchwork @ 2016-11-17 7:42 ` Daniel Vetter 2016-12-06 1:42 ` Mike Lothian 2017-02-19 14:54 ` Thomas Hellstrom 2 siblings, 1 reply; 19+ messages in thread From: Daniel Vetter @ 2016-11-17 7:42 UTC (permalink / raw) To: Intel Graphics Development, DRI Development; +Cc: Daniel Vetter, 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2016-11-17 7:42 ` [PATCH] [RFC] " Daniel Vetter @ 2016-12-06 1:42 ` Mike Lothian 2016-12-06 1:47 ` Michel Dänzer 0 siblings, 1 reply; 19+ messages in thread From: Mike Lothian @ 2016-12-06 1:42 UTC (permalink / raw) To: Daniel Vetter, Intel Graphics Development, DRI Development Cc: Daniel Vetter, Daniel Vetter [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2016-12-06 1:42 ` Mike Lothian @ 2016-12-06 1:47 ` Michel Dänzer 2016-12-06 1:55 ` Mike Lothian 0 siblings, 1 reply; 19+ messages in thread From: Michel Dänzer @ 2016-12-06 1:47 UTC (permalink / raw) To: Mike Lothian, Daniel Vetter, Intel Graphics Development, DRI Development Cc: Daniel Vetter, Daniel Vetter 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2016-12-06 1:47 ` Michel Dänzer @ 2016-12-06 1:55 ` Mike Lothian 0 siblings, 0 replies; 19+ messages in thread From: Mike Lothian @ 2016-12-06 1:55 UTC (permalink / raw) To: Michel Dänzer, Daniel Vetter, Intel Graphics Development, DRI Development Cc: Daniel Vetter, Daniel Vetter [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2016-10-28 8:10 [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Daniel Vetter 2016-10-28 8:45 ` ✗ Fi.CI.BAT: warning for " Patchwork 2016-11-17 7:42 ` [PATCH] [RFC] " Daniel Vetter @ 2017-02-19 14:54 ` Thomas Hellstrom 2017-02-19 15:21 ` Thomas Hellstrom 2 siblings, 1 reply; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-19 14:54 UTC (permalink / raw) To: Daniel Vetter, Intel Graphics Development, DRI Development; +Cc: Daniel Vetter 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2017-02-19 14:54 ` Thomas Hellstrom @ 2017-02-19 15:21 ` Thomas Hellstrom 0 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-19 15:21 UTC (permalink / raw) To: Daniel Vetter, Intel Graphics Development, DRI Development Cc: Daniel Vetter, Dave Airlie, linux-kernel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes @ 2017-02-19 15:21 ` Thomas Hellstrom 0 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-19 15:21 UTC (permalink / raw) To: Daniel Vetter, Intel Graphics Development, DRI Development Cc: Daniel Vetter, linux-kernel, Dave Airlie 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2017-02-19 15:21 ` Thomas Hellstrom @ 2017-02-20 22:22 ` Daniel Vetter -1 siblings, 0 replies; 19+ messages in thread From: Daniel Vetter @ 2017-02-20 22:22 UTC (permalink / raw) To: Thomas Hellstrom Cc: Intel Graphics Development, DRI Development, Daniel Vetter, Dave Airlie, linux-kernel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes @ 2017-02-20 22:22 ` Daniel Vetter 0 siblings, 0 replies; 19+ messages in thread From: Daniel Vetter @ 2017-02-20 22:22 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Intel Graphics Development, linux-kernel, DRI Development, Dave Airlie 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) 2017-02-20 22:22 ` Daniel Vetter @ 2017-02-21 5:32 ` Thomas Hellstrom -1 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-21 5:32 UTC (permalink / raw) To: Daniel Vetter Cc: Intel Graphics Development, DRI Development, Daniel Vetter, Dave Airlie, linux-kernel 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 >> > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) @ 2017-02-21 5:32 ` Thomas Hellstrom 0 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-21 5:32 UTC (permalink / raw) To: Daniel Vetter Cc: Daniel Vetter, Intel Graphics Development, linux-kernel, DRI Development, Dave 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 /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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) 2017-02-21 5:32 ` Thomas Hellstrom @ 2017-02-21 5:34 ` David Airlie -1 siblings, 0 replies; 19+ messages in thread From: David Airlie @ 2017-02-21 5:34 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Intel Graphics Development, DRI Development, Daniel Vetter, linux-kernel > > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) @ 2017-02-21 5:34 ` David Airlie 0 siblings, 0 replies; 19+ messages in thread From: David Airlie @ 2017-02-21 5:34 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Intel Graphics Development, linux-kernel, DRI Development, Daniel Vetter > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) 2017-02-21 5:34 ` David Airlie @ 2017-02-21 10:52 ` Thomas Hellstrom -1 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-21 10:52 UTC (permalink / raw) To: David Airlie Cc: Daniel Vetter, Intel Graphics Development, DRI Development, Daniel Vetter, linux-kernel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) @ 2017-02-21 10:52 ` Thomas Hellstrom 0 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-21 10:52 UTC (permalink / raw) To: David Airlie Cc: Daniel Vetter, Intel Graphics Development, linux-kernel, DRI Development, Daniel Vetter 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes 2017-02-20 22:22 ` Daniel Vetter @ 2017-02-21 11:11 ` Thomas Hellstrom -1 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-21 11:11 UTC (permalink / raw) To: Daniel Vetter Cc: Intel Graphics Development, DRI Development, Daniel Vetter, Dave Airlie, linux-kernel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes @ 2017-02-21 11:11 ` Thomas Hellstrom 0 siblings, 0 replies; 19+ messages in thread From: Thomas Hellstrom @ 2017-02-21 11:11 UTC (permalink / raw) To: Daniel Vetter Cc: Daniel Vetter, Intel Graphics Development, linux-kernel, DRI Development, Dave Airlie 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-02-21 11:12 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-28 8:10 [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Daniel Vetter 2016-10-28 8:45 ` ✗ Fi.CI.BAT: warning for " Patchwork 2016-11-17 7:42 ` [PATCH] [RFC] " Daniel Vetter 2016-12-06 1:42 ` Mike Lothian 2016-12-06 1:47 ` Michel Dänzer 2016-12-06 1:55 ` Mike Lothian 2017-02-19 14:54 ` Thomas Hellstrom 2017-02-19 15:21 ` Thomas Hellstrom 2017-02-19 15:21 ` Thomas Hellstrom 2017-02-20 22:22 ` Daniel Vetter 2017-02-20 22:22 ` Daniel Vetter 2017-02-21 5:32 ` DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) Thomas Hellstrom 2017-02-21 5:32 ` Thomas Hellstrom 2017-02-21 5:34 ` David Airlie 2017-02-21 5:34 ` David Airlie 2017-02-21 10:52 ` Thomas Hellstrom 2017-02-21 10:52 ` Thomas Hellstrom 2017-02-21 11:11 ` [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Thomas Hellstrom 2017-02-21 11:11 ` Thomas Hellstrom
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.