* [PATCH libdrm] libdrm: Allow dynamic drm majors on linux @ 2018-08-31 11:54 Thomas Hellstrom 2018-08-31 12:15 ` Eric Engestrom 2018-08-31 12:30 ` Emil Velikov 0 siblings, 2 replies; 25+ messages in thread From: Thomas Hellstrom @ 2018-08-31 11:54 UTC (permalink / raw) To: dri-devel, linux-graphics-maintainer; +Cc: Thomas Hellstrom To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, https://cgit.freedesktop.org/mesa/vmwgfx and any future attempt to introduce dynamic device numbers for drm. So instead of checking for the device major, instead check for the presence of the /sys/dev/char/<major>:<minor>/device/drm directory. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> --- xf86drm.c | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 7807dce9..4cfc5d3e 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -2761,6 +2761,21 @@ char *drmGetDeviceNameFromFd(int fd) return strdup(name); } +static bool +drmNodeIsDRM(int maj, int min) +{ +#ifdef __linux__ + char path[64]; + struct stat sbuf; + + snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device/drm", + maj, min); + return stat(path, &sbuf) == 0; +#else + return maj == DRM_MAJOR; +#endif +} + int drmGetNodeTypeFromFd(int fd) { struct stat sbuf; @@ -2772,7 +2787,7 @@ int drmGetNodeTypeFromFd(int fd) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) { + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) { errno = EINVAL; return -1; } @@ -2837,7 +2852,7 @@ static char *drmGetMinorNameForFD(int fd, int type) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return NULL; snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min); @@ -2871,7 +2886,7 @@ static char *drmGetMinorNameForFD(int fd, int type) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return NULL; switch (type) { @@ -3731,7 +3746,7 @@ process_device(drmDevicePtr *device, const char *d_name, maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return -1; subsystem_type = drmParseSubsystemType(maj, min); @@ -3845,7 +3860,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return -EINVAL; node_type = drmGetMinorType(min); @@ -3911,7 +3926,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return -EINVAL; subsystem_type = drmParseSubsystemType(maj, min); @@ -4071,7 +4086,7 @@ char *drmGetDeviceNameFromFd2(int fd) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return NULL; snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", maj, min); @@ -4097,7 +4112,7 @@ char *drmGetDeviceNameFromFd2(int fd) maj = major(sbuf.st_rdev); min = minor(sbuf.st_rdev); - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) return NULL; node_type = drmGetMinorType(min); -- 2.18.0.rc1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-08-31 11:54 [PATCH libdrm] libdrm: Allow dynamic drm majors on linux Thomas Hellstrom @ 2018-08-31 12:15 ` Eric Engestrom 2018-08-31 12:30 ` Emil Velikov 1 sibling, 0 replies; 25+ messages in thread From: Eric Engestrom @ 2018-08-31 12:15 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: linux-graphics-maintainer, dri-devel On Friday, 2018-08-31 13:54:19 +0200, Thomas Hellstrom wrote: > To determine whether a device node is a drm device node or not, the code > currently compares the node's major number to the static drm major device > number. > > This breaks the standalone vmwgfx driver on XWayland dri clients, > https://cgit.freedesktop.org/mesa/vmwgfx > and any future attempt to introduce dynamic device numbers for drm. > > So instead of checking for the device major, instead check for the presence > of the /sys/dev/char/<major>:<minor>/device/drm directory. Just FYI, this means it now matches /dev/fb0 too. I don't think this will be an issue, but just pointing it out so people notice. > > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> > --- > xf86drm.c | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) > > diff --git a/xf86drm.c b/xf86drm.c > index 7807dce9..4cfc5d3e 100644 > --- a/xf86drm.c > +++ b/xf86drm.c > @@ -2761,6 +2761,21 @@ char *drmGetDeviceNameFromFd(int fd) > return strdup(name); > } > > +static bool > +drmNodeIsDRM(int maj, int min) > +{ > +#ifdef __linux__ > + char path[64]; > + struct stat sbuf; > + > + snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device/drm", > + maj, min); Nit: mixing tabs and space on this line. With that fixed: Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> > + return stat(path, &sbuf) == 0; > +#else > + return maj == DRM_MAJOR; > +#endif > +} > + > int drmGetNodeTypeFromFd(int fd) > { > struct stat sbuf; > @@ -2772,7 +2787,7 @@ int drmGetNodeTypeFromFd(int fd) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) { > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) { > errno = EINVAL; > return -1; > } > @@ -2837,7 +2852,7 @@ static char *drmGetMinorNameForFD(int fd, int type) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return NULL; > > snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min); > @@ -2871,7 +2886,7 @@ static char *drmGetMinorNameForFD(int fd, int type) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return NULL; > > switch (type) { > @@ -3731,7 +3746,7 @@ process_device(drmDevicePtr *device, const char *d_name, > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return -1; > > subsystem_type = drmParseSubsystemType(maj, min); > @@ -3845,7 +3860,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return -EINVAL; > > node_type = drmGetMinorType(min); > @@ -3911,7 +3926,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return -EINVAL; > > subsystem_type = drmParseSubsystemType(maj, min); > @@ -4071,7 +4086,7 @@ char *drmGetDeviceNameFromFd2(int fd) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return NULL; > > snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", maj, min); > @@ -4097,7 +4112,7 @@ char *drmGetDeviceNameFromFd2(int fd) > maj = major(sbuf.st_rdev); > min = minor(sbuf.st_rdev); > > - if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) > + if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) > return NULL; > > node_type = drmGetMinorType(min); > -- > 2.18.0.rc1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-08-31 11:54 [PATCH libdrm] libdrm: Allow dynamic drm majors on linux Thomas Hellstrom 2018-08-31 12:15 ` Eric Engestrom @ 2018-08-31 12:30 ` Emil Velikov 2018-08-31 13:05 ` Thomas Hellstrom 1 sibling, 1 reply; 25+ messages in thread From: Emil Velikov @ 2018-08-31 12:30 UTC (permalink / raw) To: Thomas Hellstrom, Dave Airlie, Daniel Vetter Cc: VMware Graphics, ML dri-devel Hi Thomas, On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> wrote: > To determine whether a device node is a drm device node or not, the code > currently compares the node's major number to the static drm major device > number. > > This breaks the standalone vmwgfx driver on XWayland dri clients, > https://cgit.freedesktop.org/mesa/vmwgfx Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. > and any future attempt to introduce dynamic device numbers for drm. > I'm not sure how well any such attempt will pan out, regardless of the libdrm checks. Namely: the static 226 has been used by a number of tools that interpose the libc' ioctl function. There could be others that also depend on it. Personally, I'd go with the kernel developers decision. Dave, Daniel, others Should we keep or drop the major == 226 checks. Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-08-31 12:30 ` Emil Velikov @ 2018-08-31 13:05 ` Thomas Hellstrom [not found] ` <bbb94b6f-c9d5-27ab-9e6d-4b4c1d85db8e-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-08-31 13:05 UTC (permalink / raw) To: Emil Velikov, Dave Airlie, Daniel Vetter; +Cc: VMware Graphics, ML dri-devel Hi, Emil On 08/31/2018 02:30 PM, Emil Velikov wrote: > Hi Thomas, > > On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> wrote: >> To determine whether a device node is a drm device node or not, the code >> currently compares the node's major number to the static drm major device >> number. >> >> This breaks the standalone vmwgfx driver on XWayland dri clients, >> > Any particular reason why the code doesn't use a fixed node there? > It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. > >> and any future attempt to introduce dynamic device numbers for drm. >> > I'm not sure how well any such attempt will pan out, regardless of the > libdrm checks. > > Namely: the static 226 has been used by a number of tools that > interpose the libc' ioctl function. > There could be others that also depend on it. True, in any case for existing drivers changing static 226 to something else is at least 10+ years away according to Linus' policy, so the main issue here is really to get rid of a big annoyance in the standalone vmwgfx case. /Thomas > > Personally, I'd go with the kernel developers decision. > > Dave, Daniel, others > Should we keep or drop the major == 226 checks. > > Thanks > Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <bbb94b6f-c9d5-27ab-9e6d-4b4c1d85db8e-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <bbb94b6f-c9d5-27ab-9e6d-4b4c1d85db8e-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> @ 2018-08-31 14:38 ` Michel Dänzer [not found] ` <33fb1ba6-cc44-f747-545b-9f877917933e-otUistvHUpPR7s880joybQ@public.gmane.org> 2018-08-31 15:27 ` Emil Velikov 0 siblings, 2 replies; 25+ messages in thread From: Michel Dänzer @ 2018-08-31 14:38 UTC (permalink / raw) To: Thomas Hellstrom, Emil Velikov, Dave Airlie, Daniel Vetter Cc: VMware Graphics, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, ML dri-devel [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: > On 08/31/2018 02:30 PM, Emil Velikov wrote: >> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >> wrote: >>> To determine whether a device node is a drm device node or not, the code >>> currently compares the node's major number to the static drm major >>> device >>> number. >>> >>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>> >> Any particular reason why the code doesn't use a fixed node there? >> It will make the diff vs the in-kernel driver a bit smaller. > Because then it won't be able to interoperate with other in-tree > drivers, like virtual drm drivers or passthrough usb drm drivers. > There is no clean way to share the minor number allocation with in-tree > drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <33fb1ba6-cc44-f747-545b-9f877917933e-otUistvHUpPR7s880joybQ@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <33fb1ba6-cc44-f747-545b-9f877917933e-otUistvHUpPR7s880joybQ@public.gmane.org> @ 2018-08-31 14:46 ` Thomas Hellstrom [not found] ` <e656d26a-be98-cc9c-7962-fd74ad226c60-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-08-31 14:46 UTC (permalink / raw) To: Michel Dänzer, Emil Velikov, Dave Airlie, Daniel Vetter Cc: VMware Graphics, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, ML dri-devel On 08/31/2018 04:38 PM, Michel Dänzer wrote: > [ Adding the amd-gfx list ] > > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>> wrote: >>>> To determine whether a device node is a drm device node or not, the code >>>> currently compares the node's major number to the static drm major >>>> device >>>> number. >>>> >>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>> >>> Any particular reason why the code doesn't use a fixed node there? >>> It will make the diff vs the in-kernel driver a bit smaller. >> Because then it won't be able to interoperate with other in-tree >> drivers, like virtual drm drivers or passthrough usb drm drivers. >> There is no clean way to share the minor number allocation with in-tree >> drm, so standalone vmwgfx is using dynamic major allocation. > I wonder why I haven't heard of any of these issues with the standalone > version of amdgpu shipped in packaged AMD releases. Does that also use a > different major number? If yes, maybe it's just that nobody has tried > Xwayland clients with that driver. If no, how does it avoid the other > issues described above? > > Is standalone AMD supposed to be able to coexist with in-tree drm drivers? /Thomas _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <e656d26a-be98-cc9c-7962-fd74ad226c60-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <e656d26a-be98-cc9c-7962-fd74ad226c60-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> @ 2018-08-31 14:49 ` Michel Dänzer [not found] ` <6d78b948-55bc-3adf-f8c0-691aa80a8bb2-otUistvHUpPR7s880joybQ@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Michel Dänzer @ 2018-08-31 14:49 UTC (permalink / raw) To: Thomas Hellstrom, Emil Velikov, Dave Airlie, Daniel Vetter Cc: VMware Graphics, ML dri-devel, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote: > On 08/31/2018 04:38 PM, Michel Dänzer wrote: >> [ Adding the amd-gfx list ] >> >> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>> wrote: >>>>> To determine whether a device node is a drm device node or not, the >>>>> code >>>>> currently compares the node's major number to the static drm major >>>>> device >>>>> number. >>>>> >>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>> >>>> Any particular reason why the code doesn't use a fixed node there? >>>> It will make the diff vs the in-kernel driver a bit smaller. >>> Because then it won't be able to interoperate with other in-tree >>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>> There is no clean way to share the minor number allocation with in-tree >>> drm, so standalone vmwgfx is using dynamic major allocation. >> I wonder why I haven't heard of any of these issues with the standalone >> version of amdgpu shipped in packaged AMD releases. Does that also use a >> different major number? If yes, maybe it's just that nobody has tried >> Xwayland clients with that driver. If no, how does it avoid the other >> issues described above? >> >> > Is standalone AMD supposed to be able to coexist with in-tree drm drivers? Yes, it does, it's working e.g. on laptops with an Intel integrated and an AMD discrete GPU. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <6d78b948-55bc-3adf-f8c0-691aa80a8bb2-otUistvHUpPR7s880joybQ@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <6d78b948-55bc-3adf-f8c0-691aa80a8bb2-otUistvHUpPR7s880joybQ@public.gmane.org> @ 2018-08-31 14:59 ` Thomas Hellstrom 0 siblings, 0 replies; 25+ messages in thread From: Thomas Hellstrom @ 2018-08-31 14:59 UTC (permalink / raw) To: Michel Dänzer, Emil Velikov, Dave Airlie, Daniel Vetter Cc: VMware Graphics, ML dri-devel, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW On 08/31/2018 04:49 PM, Michel Dänzer wrote: > On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote: >> On 08/31/2018 04:38 PM, Michel Dänzer wrote: >>> [ Adding the amd-gfx list ] >>> >>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>>> wrote: >>>>>> To determine whether a device node is a drm device node or not, the >>>>>> code >>>>>> currently compares the node's major number to the static drm major >>>>>> device >>>>>> number. >>>>>> >>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>>> >>>>> Any particular reason why the code doesn't use a fixed node there? >>>>> It will make the diff vs the in-kernel driver a bit smaller. >>>> Because then it won't be able to interoperate with other in-tree >>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>>> There is no clean way to share the minor number allocation with in-tree >>>> drm, so standalone vmwgfx is using dynamic major allocation. >>> I wonder why I haven't heard of any of these issues with the standalone >>> version of amdgpu shipped in packaged AMD releases. Does that also use a >>> different major number? If yes, maybe it's just that nobody has tried >>> Xwayland clients with that driver. If no, how does it avoid the other >>> issues described above? >>> >>> >> Is standalone AMD supposed to be able to coexist with in-tree drm drivers? > Yes, it does, it's working e.g. on laptops with an Intel integrated and > an AMD discrete GPU. > > Hmm. The symptoms with xf86-video-vmware are that when mesa initializes, we get: MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information but then vmwgfx_dri.so loads anyway. With XWayland, mesa just silently tries swrast instead of vmwgfx. Not sure this has always been the case though. It might be due to a recent XWayland change. In any case, the change to libdrm silence the warnings on Xorg and makes mesa try vmwgfx on XWayland. /Thomas _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-08-31 14:38 ` Michel Dänzer [not found] ` <33fb1ba6-cc44-f747-545b-9f877917933e-otUistvHUpPR7s880joybQ@public.gmane.org> @ 2018-08-31 15:27 ` Emil Velikov [not found] ` <CACvgo53Wd1fq8=V_v7jjuFGimUfh7xD+ccCg-jOTjLSJdWUKeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 1 reply; 25+ messages in thread From: Emil Velikov @ 2018-08-31 15:27 UTC (permalink / raw) To: Michel Dänzer Cc: Thomas Hellstrom, Daniel Vetter, ML dri-devel, VMware Graphics, amd-gfx mailing list On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: > > [ Adding the amd-gfx list ] > > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>> wrote: >>>> To determine whether a device node is a drm device node or not, the code >>>> currently compares the node's major number to the static drm major >>>> device >>>> number. >>>> >>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>> >>> Any particular reason why the code doesn't use a fixed node there? >>> It will make the diff vs the in-kernel driver a bit smaller. >> Because then it won't be able to interoperate with other in-tree >> drivers, like virtual drm drivers or passthrough usb drm drivers. >> There is no clean way to share the minor number allocation with in-tree >> drm, so standalone vmwgfx is using dynamic major allocation. > > I wonder why I haven't heard of any of these issues with the standalone > version of amdgpu shipped in packaged AMD releases. Does that also use a > different major number? If yes, maybe it's just that nobody has tried > Xwayland clients with that driver. If no, how does it avoid the other > issues described above? > AFAICT, the difference is that the standalone vmwgfx uses an internal copy of drm core. It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CACvgo53Wd1fq8=V_v7jjuFGimUfh7xD+ccCg-jOTjLSJdWUKeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <CACvgo53Wd1fq8=V_v7jjuFGimUfh7xD+ccCg-jOTjLSJdWUKeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2018-08-31 15:30 ` Thomas Hellstrom [not found] ` <c1dc7253-d505-dd16-480c-ee9a862d57ef-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> 2018-08-31 15:31 ` Christian König 1 sibling, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-08-31 15:30 UTC (permalink / raw) To: Emil Velikov, Michel Dänzer Cc: Daniel Vetter, VMware Graphics, Dave Airlie, ML dri-devel, amd-gfx mailing list On 08/31/2018 05:27 PM, Emil Velikov wrote: > On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: >> [ Adding the amd-gfx list ] >> >> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>> wrote: >>>>> To determine whether a device node is a drm device node or not, the code >>>>> currently compares the node's major number to the static drm major >>>>> device >>>>> number. >>>>> >>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>> >>>> Any particular reason why the code doesn't use a fixed node there? >>>> It will make the diff vs the in-kernel driver a bit smaller. >>> Because then it won't be able to interoperate with other in-tree >>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>> There is no clean way to share the minor number allocation with in-tree >>> drm, so standalone vmwgfx is using dynamic major allocation. >> I wonder why I haven't heard of any of these issues with the standalone >> version of amdgpu shipped in packaged AMD releases. Does that also use a >> different major number? If yes, maybe it's just that nobody has tried >> Xwayland clients with that driver. If no, how does it avoid the other >> issues described above? >> > AFAICT, the difference is that the standalone vmwgfx uses an internal > copy of drm core. > It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. > > -Emil Actually, standalone vmwgfx could perhaps also try to allocate minors from 63 and downwards. That might work, but needs some verification. /Thomas _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <c1dc7253-d505-dd16-480c-ee9a862d57ef-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <c1dc7253-d505-dd16-480c-ee9a862d57ef-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> @ 2018-09-03 9:16 ` Thomas Hellstrom 2018-09-03 16:33 ` Daniel Vetter 0 siblings, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-09-03 9:16 UTC (permalink / raw) To: Emil Velikov, Michel Dänzer Cc: Daniel Vetter, VMware Graphics, Dave Airlie, ML dri-devel, amd-gfx mailing list On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: > On 08/31/2018 05:27 PM, Emil Velikov wrote: >> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: >>> [ Adding the amd-gfx list ] >>> >>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>>> wrote: >>>>>> To determine whether a device node is a drm device node or not, >>>>>> the code >>>>>> currently compares the node's major number to the static drm major >>>>>> device >>>>>> number. >>>>>> >>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>>> >>>>> Any particular reason why the code doesn't use a fixed node there? >>>>> It will make the diff vs the in-kernel driver a bit smaller. >>>> Because then it won't be able to interoperate with other in-tree >>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>>> There is no clean way to share the minor number allocation with >>>> in-tree >>>> drm, so standalone vmwgfx is using dynamic major allocation. >>> I wonder why I haven't heard of any of these issues with the standalone >>> version of amdgpu shipped in packaged AMD releases. Does that also >>> use a >>> different major number? If yes, maybe it's just that nobody has tried >>> Xwayland clients with that driver. If no, how does it avoid the other >>> issues described above? >>> >> AFAICT, the difference is that the standalone vmwgfx uses an internal >> copy of drm core. >> It doesn't reuse the in-kernel drm, hence it cannot know which minor >> it can use. >> >> -Emil > > Actually, standalone vmwgfx could perhaps also try to allocate minors > from 63 and downwards. That might work, but needs some verification. > So unfortuntately this doesn't work since the in-tree drm's file operations are registered with the DRM_MAJOR. So I still think the patch is the way to go. If people are concerned that also fbdev file descriptors are allowed, perhaps there are other sysfs traits we can look at? /Thomas > /Thomas > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-09-03 9:16 ` Thomas Hellstrom @ 2018-09-03 16:33 ` Daniel Vetter [not found] ` <20180903163310.GJ21634-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Daniel Vetter @ 2018-09-03 16:33 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Michel Dänzer, Emil Velikov, amd-gfx mailing list, VMware Graphics, ML dri-devel On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: > On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: > > On 08/31/2018 05:27 PM, Emil Velikov wrote: > > > On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: > > > > [ Adding the amd-gfx list ] > > > > > > > > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: > > > > > On 08/31/2018 02:30 PM, Emil Velikov wrote: > > > > > > On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> > > > > > > wrote: > > > > > > > To determine whether a device node is a drm device > > > > > > > node or not, the code > > > > > > > currently compares the node's major number to the static drm major > > > > > > > device > > > > > > > number. > > > > > > > > > > > > > > This breaks the standalone vmwgfx driver on XWayland dri clients, > > > > > > > > > > > > > Any particular reason why the code doesn't use a fixed node there? > > > > > > It will make the diff vs the in-kernel driver a bit smaller. > > > > > Because then it won't be able to interoperate with other in-tree > > > > > drivers, like virtual drm drivers or passthrough usb drm drivers. > > > > > There is no clean way to share the minor number allocation > > > > > with in-tree > > > > > drm, so standalone vmwgfx is using dynamic major allocation. > > > > I wonder why I haven't heard of any of these issues with the standalone > > > > version of amdgpu shipped in packaged AMD releases. Does that > > > > also use a > > > > different major number? If yes, maybe it's just that nobody has tried > > > > Xwayland clients with that driver. If no, how does it avoid the other > > > > issues described above? > > > > > > > AFAICT, the difference is that the standalone vmwgfx uses an internal > > > copy of drm core. > > > It doesn't reuse the in-kernel drm, hence it cannot know which minor > > > it can use. > > > > > > -Emil > > > > Actually, standalone vmwgfx could perhaps also try to allocate minors > > from 63 and downwards. That might work, but needs some verification. > > > > So unfortuntately this doesn't work since the in-tree drm's file operations > are registered with the DRM_MAJOR. > So I still think the patch is the way to go. If people are concerned that > also fbdev file descriptors are allowed, perhaps there are other sysfs > traits we can look at? Somewhat out of curiosity, but why do you have to overwrite all of drm? amdgpu seems to be able to pull their stunt off without ... -Daniel -- 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <20180903163310.GJ21634-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <20180903163310.GJ21634-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> @ 2018-09-03 17:00 ` Thomas Hellstrom [not found] ` <91ad6140-4e56-afc1-2515-9ca973d0ea05-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-09-03 17:00 UTC (permalink / raw) To: Daniel Vetter Cc: Daniel Vetter, Michel Dänzer, Emil Velikov, amd-gfx mailing list, VMware Graphics, ML dri-devel On 09/03/2018 06:33 PM, Daniel Vetter wrote: > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: >>> On 08/31/2018 05:27 PM, Emil Velikov wrote: >>>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: >>>>> [ Adding the amd-gfx list ] >>>>> >>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>>>>> wrote: >>>>>>>> To determine whether a device node is a drm device >>>>>>>> node or not, the code >>>>>>>> currently compares the node's major number to the static drm major >>>>>>>> device >>>>>>>> number. >>>>>>>> >>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>>>>> >>>>>>> Any particular reason why the code doesn't use a fixed node there? >>>>>>> It will make the diff vs the in-kernel driver a bit smaller. >>>>>> Because then it won't be able to interoperate with other in-tree >>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>>>>> There is no clean way to share the minor number allocation >>>>>> with in-tree >>>>>> drm, so standalone vmwgfx is using dynamic major allocation. >>>>> I wonder why I haven't heard of any of these issues with the standalone >>>>> version of amdgpu shipped in packaged AMD releases. Does that >>>>> also use a >>>>> different major number? If yes, maybe it's just that nobody has tried >>>>> Xwayland clients with that driver. If no, how does it avoid the other >>>>> issues described above? >>>>> >>>> AFAICT, the difference is that the standalone vmwgfx uses an internal >>>> copy of drm core. >>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor >>>> it can use. >>>> >>>> -Emil >>> Actually, standalone vmwgfx could perhaps also try to allocate minors >>> from 63 and downwards. That might work, but needs some verification. >>> >> So unfortuntately this doesn't work since the in-tree drm's file operations >> are registered with the DRM_MAJOR. >> So I still think the patch is the way to go. If people are concerned that >> also fbdev file descriptors are allowed, perhaps there are other sysfs >> traits we can look at? > Somewhat out of curiosity, but why do you have to overwrite all of drm? > amdgpu seems to be able to pull their stunt off without ... > -Daniel At the time we launched the standalone vmwgfx, the DRM <-> driver interface was moving considerably more rapidly than the DRM <-> kernel interface. I think that's still the case. Hence less work for us. Also meant we can install the full driver stack with latest features on fairly old VMs without backported DRM functionality. /Thomas _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <91ad6140-4e56-afc1-2515-9ca973d0ea05-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <91ad6140-4e56-afc1-2515-9ca973d0ea05-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> @ 2018-09-04 22:33 ` Dave Airlie [not found] ` <CAPM=9tzScEQ-RWK55zKeT_yXiN6iAyx34DVX1eCgA3ZqC_SpuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Dave Airlie @ 2018-09-04 22:33 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Michel Dänzer, Emil Velikov, amd-gfx mailing list, linux-graphics-maintainer-pghWNbHTmq7QT0dZR+AlfA, dri-devel, Daniel Vetter On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom <thellstrom@vmware.com> wrote: > > On 09/03/2018 06:33 PM, Daniel Vetter wrote: > > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: > >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: > >>> On 08/31/2018 05:27 PM, Emil Velikov wrote: > >>>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: > >>>>> [ Adding the amd-gfx list ] > >>>>> > >>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: > >>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: > >>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> > >>>>>>> wrote: > >>>>>>>> To determine whether a device node is a drm device > >>>>>>>> node or not, the code > >>>>>>>> currently compares the node's major number to the static drm major > >>>>>>>> device > >>>>>>>> number. > >>>>>>>> > >>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, > >>>>>>>> > >>>>>>> Any particular reason why the code doesn't use a fixed node there? > >>>>>>> It will make the diff vs the in-kernel driver a bit smaller. > >>>>>> Because then it won't be able to interoperate with other in-tree > >>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers. > >>>>>> There is no clean way to share the minor number allocation > >>>>>> with in-tree > >>>>>> drm, so standalone vmwgfx is using dynamic major allocation. > >>>>> I wonder why I haven't heard of any of these issues with the standalone > >>>>> version of amdgpu shipped in packaged AMD releases. Does that > >>>>> also use a > >>>>> different major number? If yes, maybe it's just that nobody has tried > >>>>> Xwayland clients with that driver. If no, how does it avoid the other > >>>>> issues described above? > >>>>> > >>>> AFAICT, the difference is that the standalone vmwgfx uses an internal > >>>> copy of drm core. > >>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor > >>>> it can use. > >>>> > >>>> -Emil > >>> Actually, standalone vmwgfx could perhaps also try to allocate minors > >>> from 63 and downwards. That might work, but needs some verification. > >>> > >> So unfortuntately this doesn't work since the in-tree drm's file operations > >> are registered with the DRM_MAJOR. > >> So I still think the patch is the way to go. If people are concerned that > >> also fbdev file descriptors are allowed, perhaps there are other sysfs > >> traits we can look at? > > Somewhat out of curiosity, but why do you have to overwrite all of drm? > > amdgpu seems to be able to pull their stunt off without ... > > -Daniel > > At the time we launched the standalone vmwgfx, the DRM <-> driver > interface was moving considerably more rapidly than the DRM <-> kernel > interface. I think that's still the case. Hence less work for us. Also > meant we can install the full driver stack with latest features on > fairly old VMs without backported DRM functionality. > I think this should be fine for 99% of drm usage, there may be corner cases in wierd places, but I can't point to any that really matter (maybe strace?) Acked-by: Dave Airlie <airlied@redhat.com> Dave. _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CAPM=9tzScEQ-RWK55zKeT_yXiN6iAyx34DVX1eCgA3ZqC_SpuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <CAPM=9tzScEQ-RWK55zKeT_yXiN6iAyx34DVX1eCgA3ZqC_SpuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2018-09-05 9:33 ` Emil Velikov [not found] ` <CACvgo50cfLHWDUEjeNet4H3F4i3okdhSsXfjNiPvH-YZbQsyEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Emil Velikov @ 2018-09-05 9:33 UTC (permalink / raw) To: Dave Airlie Cc: Thomas Hellstrom, Daniel Vetter, Michel Dänzer, amd-gfx mailing list, VMware Graphics, dri-devel, Daniel Vetter On 4 September 2018 at 23:33, Dave Airlie <airlied@gmail.com> wrote: > On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom <thellstrom@vmware.com> wrote: >> >> On 09/03/2018 06:33 PM, Daniel Vetter wrote: >> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: >> >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: >> >>> On 08/31/2018 05:27 PM, Emil Velikov wrote: >> >>>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: >> >>>>> [ Adding the amd-gfx list ] >> >>>>> >> >>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >> >>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >> >>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >> >>>>>>> wrote: >> >>>>>>>> To determine whether a device node is a drm device >> >>>>>>>> node or not, the code >> >>>>>>>> currently compares the node's major number to the static drm major >> >>>>>>>> device >> >>>>>>>> number. >> >>>>>>>> >> >>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >> >>>>>>>> >> >>>>>>> Any particular reason why the code doesn't use a fixed node there? >> >>>>>>> It will make the diff vs the in-kernel driver a bit smaller. >> >>>>>> Because then it won't be able to interoperate with other in-tree >> >>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >> >>>>>> There is no clean way to share the minor number allocation >> >>>>>> with in-tree >> >>>>>> drm, so standalone vmwgfx is using dynamic major allocation. >> >>>>> I wonder why I haven't heard of any of these issues with the standalone >> >>>>> version of amdgpu shipped in packaged AMD releases. Does that >> >>>>> also use a >> >>>>> different major number? If yes, maybe it's just that nobody has tried >> >>>>> Xwayland clients with that driver. If no, how does it avoid the other >> >>>>> issues described above? >> >>>>> >> >>>> AFAICT, the difference is that the standalone vmwgfx uses an internal >> >>>> copy of drm core. >> >>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor >> >>>> it can use. >> >>>> >> >>>> -Emil >> >>> Actually, standalone vmwgfx could perhaps also try to allocate minors >> >>> from 63 and downwards. That might work, but needs some verification. >> >>> >> >> So unfortuntately this doesn't work since the in-tree drm's file operations >> >> are registered with the DRM_MAJOR. >> >> So I still think the patch is the way to go. If people are concerned that >> >> also fbdev file descriptors are allowed, perhaps there are other sysfs >> >> traits we can look at? >> > Somewhat out of curiosity, but why do you have to overwrite all of drm? >> > amdgpu seems to be able to pull their stunt off without ... >> > -Daniel >> >> At the time we launched the standalone vmwgfx, the DRM <-> driver >> interface was moving considerably more rapidly than the DRM <-> kernel >> interface. I think that's still the case. Hence less work for us. Also >> meant we can install the full driver stack with latest features on >> fairly old VMs without backported DRM functionality. >> > > I think this should be fine for 99% of drm usage, there may be corner > cases in wierd places, but I can't point to any that really matter > (maybe strace?) > Having a closer look, I think this will break the Firefox/Chrome sandboxing :-\ I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed list [1] [2]. Thomas, can you please send a patch to the respective teams or give them a heads up? Thanks Emil [1] https://hg.mozilla.org/releases/mozilla-beta/file/264fcd3206a6/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp [2] https://chromium.googlesource.com/chromium/src/+/8655d49f657d3878c937f1387b3d31fa66c8e76a/content/gpu/gpu_sandbox_hook_linux.cc _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CACvgo50cfLHWDUEjeNet4H3F4i3okdhSsXfjNiPvH-YZbQsyEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <CACvgo50cfLHWDUEjeNet4H3F4i3okdhSsXfjNiPvH-YZbQsyEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2018-09-05 10:10 ` Thomas Hellstrom 2018-09-05 13:07 ` Emil Velikov 0 siblings, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-09-05 10:10 UTC (permalink / raw) To: Emil Velikov, Dave Airlie Cc: Daniel Vetter, Michel Dänzer, dri-devel, VMware Graphics, amd-gfx mailing list, Daniel Vetter Hi, Emil, On 09/05/2018 11:33 AM, Emil Velikov wrote: > On 4 September 2018 at 23:33, Dave Airlie <airlied@gmail.com> wrote: >> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom <thellstrom@vmware.com> wrote: >>> On 09/03/2018 06:33 PM, Daniel Vetter wrote: >>>> On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: >>>>> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: >>>>>> On 08/31/2018 05:27 PM, Emil Velikov wrote: >>>>>>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: >>>>>>>> [ Adding the amd-gfx list ] >>>>>>>> >>>>>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>>>>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>>>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>>>>>>>> wrote: >>>>>>>>>>> To determine whether a device node is a drm device >>>>>>>>>>> node or not, the code >>>>>>>>>>> currently compares the node's major number to the static drm major >>>>>>>>>>> device >>>>>>>>>>> number. >>>>>>>>>>> >>>>>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>>>>>>>> >>>>>>>>>> Any particular reason why the code doesn't use a fixed node there? >>>>>>>>>> It will make the diff vs the in-kernel driver a bit smaller. >>>>>>>>> Because then it won't be able to interoperate with other in-tree >>>>>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>>>>>>>> There is no clean way to share the minor number allocation >>>>>>>>> with in-tree >>>>>>>>> drm, so standalone vmwgfx is using dynamic major allocation. >>>>>>>> I wonder why I haven't heard of any of these issues with the standalone >>>>>>>> version of amdgpu shipped in packaged AMD releases. Does that >>>>>>>> also use a >>>>>>>> different major number? If yes, maybe it's just that nobody has tried >>>>>>>> Xwayland clients with that driver. If no, how does it avoid the other >>>>>>>> issues described above? >>>>>>>> >>>>>>> AFAICT, the difference is that the standalone vmwgfx uses an internal >>>>>>> copy of drm core. >>>>>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor >>>>>>> it can use. >>>>>>> >>>>>>> -Emil >>>>>> Actually, standalone vmwgfx could perhaps also try to allocate minors >>>>>> from 63 and downwards. That might work, but needs some verification. >>>>>> >>>>> So unfortuntately this doesn't work since the in-tree drm's file operations >>>>> are registered with the DRM_MAJOR. >>>>> So I still think the patch is the way to go. If people are concerned that >>>>> also fbdev file descriptors are allowed, perhaps there are other sysfs >>>>> traits we can look at? >>>> Somewhat out of curiosity, but why do you have to overwrite all of drm? >>>> amdgpu seems to be able to pull their stunt off without ... >>>> -Daniel >>> At the time we launched the standalone vmwgfx, the DRM <-> driver >>> interface was moving considerably more rapidly than the DRM <-> kernel >>> interface. I think that's still the case. Hence less work for us. Also >>> meant we can install the full driver stack with latest features on >>> fairly old VMs without backported DRM functionality. >>> >> I think this should be fine for 99% of drm usage, there may be corner >> cases in wierd places, but I can't point to any that really matter >> (maybe strace?) >> > Having a closer look, I think this will break the Firefox/Chrome sandboxing :-\ > I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed > list [1] [2]. Thanks for pointing this out. The function drmGetMinorNameForFD() already opens this path, so any user-space using that function would not work before either. Also mozilla/firefox adds /sys/dev/char/226:* Which means that while it still won't work on standalone vmwgfx, there should at least be no regression. For Chromium it seems they allow /sys/dev/char/ for AmdGpu, but only under ChromOS, so I'll ping those to be safe. I also won't be doing an immediate release after pushing. Thanks, Thomas > Thomas, can you please send a patch to the respective teams or give > them a heads up? > > Thanks > Emil > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-09-05 10:10 ` Thomas Hellstrom @ 2018-09-05 13:07 ` Emil Velikov [not found] ` <CACvgo53t4OSsdmxdHSqrfSWKZGYg4s+uXrSV3gWcignwNxfE8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Emil Velikov @ 2018-09-05 13:07 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Michel Dänzer, amd-gfx mailing list, VMware Graphics, dri-devel On 5 September 2018 at 11:10, Thomas Hellstrom <thellstrom@vmware.com> wrote: > Hi, Emil, > > > On 09/05/2018 11:33 AM, Emil Velikov wrote: >> >> On 4 September 2018 at 23:33, Dave Airlie <airlied@gmail.com> wrote: >>> >>> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom <thellstrom@vmware.com> >>> wrote: >>>> >>>> On 09/03/2018 06:33 PM, Daniel Vetter wrote: >>>>> >>>>> On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: >>>>>> >>>>>> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: >>>>>>> >>>>>>> On 08/31/2018 05:27 PM, Emil Velikov wrote: >>>>>>>> >>>>>>>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> [ Adding the amd-gfx list ] >>>>>>>>> >>>>>>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>>>>>>>>> >>>>>>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>>>>>>>>> >>>>>>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom >>>>>>>>>>> <thellstrom@vmware.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> To determine whether a device node is a drm device >>>>>>>>>>>> node or not, the code >>>>>>>>>>>> currently compares the node's major number to the static drm >>>>>>>>>>>> major >>>>>>>>>>>> device >>>>>>>>>>>> number. >>>>>>>>>>>> >>>>>>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri >>>>>>>>>>>> clients, >>>>>>>>>>>> >>>>>>>>>>> Any particular reason why the code doesn't use a fixed node >>>>>>>>>>> there? >>>>>>>>>>> It will make the diff vs the in-kernel driver a bit smaller. >>>>>>>>>> >>>>>>>>>> Because then it won't be able to interoperate with other in-tree >>>>>>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>>>>>>>>> There is no clean way to share the minor number allocation >>>>>>>>>> with in-tree >>>>>>>>>> drm, so standalone vmwgfx is using dynamic major allocation. >>>>>>>>> >>>>>>>>> I wonder why I haven't heard of any of these issues with the >>>>>>>>> standalone >>>>>>>>> version of amdgpu shipped in packaged AMD releases. Does that >>>>>>>>> also use a >>>>>>>>> different major number? If yes, maybe it's just that nobody has >>>>>>>>> tried >>>>>>>>> Xwayland clients with that driver. If no, how does it avoid the >>>>>>>>> other >>>>>>>>> issues described above? >>>>>>>>> >>>>>>>> AFAICT, the difference is that the standalone vmwgfx uses an >>>>>>>> internal >>>>>>>> copy of drm core. >>>>>>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor >>>>>>>> it can use. >>>>>>>> >>>>>>>> -Emil >>>>>>> >>>>>>> Actually, standalone vmwgfx could perhaps also try to allocate minors >>>>>>> from 63 and downwards. That might work, but needs some verification. >>>>>>> >>>>>> So unfortuntately this doesn't work since the in-tree drm's file >>>>>> operations >>>>>> are registered with the DRM_MAJOR. >>>>>> So I still think the patch is the way to go. If people are concerned >>>>>> that >>>>>> also fbdev file descriptors are allowed, perhaps there are other sysfs >>>>>> traits we can look at? >>>>> >>>>> Somewhat out of curiosity, but why do you have to overwrite all of drm? >>>>> amdgpu seems to be able to pull their stunt off without ... >>>>> -Daniel >>>> >>>> At the time we launched the standalone vmwgfx, the DRM <-> driver >>>> interface was moving considerably more rapidly than the DRM <-> kernel >>>> interface. I think that's still the case. Hence less work for us. Also >>>> meant we can install the full driver stack with latest features on >>>> fairly old VMs without backported DRM functionality. >>>> >>> I think this should be fine for 99% of drm usage, there may be corner >>> cases in wierd places, but I can't point to any that really matter >>> (maybe strace?) >>> >> Having a closer look, I think this will break the Firefox/Chrome >> sandboxing :-\ >> I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed >> list [1] [2]. > > Thanks for pointing this out. > > The function drmGetMinorNameForFD() already opens this path, so any > user-space using that function would not work before either. > > Also mozilla/firefox adds /sys/dev/char/226:* Which means that while it > still won't work on standalone vmwgfx, there should at least be no > regression. > > For Chromium it seems they allow /sys/dev/char/ for AmdGpu, but only under > ChromOS, so I'll ping those to be safe. > > I also won't be doing an immediate release after pushing. > In that case, please give me 24h to do a libdrm release before pushing. I had to push some workarounds for the sandboxing mentioned earlier :-\ Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CACvgo53t4OSsdmxdHSqrfSWKZGYg4s+uXrSV3gWcignwNxfE8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <CACvgo53t4OSsdmxdHSqrfSWKZGYg4s+uXrSV3gWcignwNxfE8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2018-09-05 13:20 ` Thomas Hellstrom 2018-09-05 13:53 ` Emil Velikov 0 siblings, 1 reply; 25+ messages in thread From: Thomas Hellstrom @ 2018-09-05 13:20 UTC (permalink / raw) To: Emil Velikov Cc: Daniel Vetter, Michel Dänzer, amd-gfx mailing list, VMware Graphics, dri-devel, Daniel Vetter, Dave Airlie On 09/05/2018 03:07 PM, Emil Velikov wrote: > On 5 September 2018 at 11:10, Thomas Hellstrom <thellstrom@vmware.com> wrote: >> Hi, Emil, >> >> >> On 09/05/2018 11:33 AM, Emil Velikov wrote: >>> On 4 September 2018 at 23:33, Dave Airlie <airlied@gmail.com> wrote: >>>> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom <thellstrom@vmware.com> >>>> wrote: >>>>> On 09/03/2018 06:33 PM, Daniel Vetter wrote: >>>>>> On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: >>>>>>> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: >>>>>>>> On 08/31/2018 05:27 PM, Emil Velikov wrote: >>>>>>>>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> >>>>>>>>> wrote: >>>>>>>>>> [ Adding the amd-gfx list ] >>>>>>>>>> >>>>>>>>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>>>>>>>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>>>>>>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom >>>>>>>>>>>> <thellstrom@vmware.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> To determine whether a device node is a drm device >>>>>>>>>>>>> node or not, the code >>>>>>>>>>>>> currently compares the node's major number to the static drm >>>>>>>>>>>>> major >>>>>>>>>>>>> device >>>>>>>>>>>>> number. >>>>>>>>>>>>> >>>>>>>>>>>>> This breaks the standalone vmwgfx driver on XWayland dri >>>>>>>>>>>>> clients, >>>>>>>>>>>>> >>>>>>>>>>>> Any particular reason why the code doesn't use a fixed node >>>>>>>>>>>> there? >>>>>>>>>>>> It will make the diff vs the in-kernel driver a bit smaller. >>>>>>>>>>> Because then it won't be able to interoperate with other in-tree >>>>>>>>>>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>>>>>>>>>> There is no clean way to share the minor number allocation >>>>>>>>>>> with in-tree >>>>>>>>>>> drm, so standalone vmwgfx is using dynamic major allocation. >>>>>>>>>> I wonder why I haven't heard of any of these issues with the >>>>>>>>>> standalone >>>>>>>>>> version of amdgpu shipped in packaged AMD releases. Does that >>>>>>>>>> also use a >>>>>>>>>> different major number? If yes, maybe it's just that nobody has >>>>>>>>>> tried >>>>>>>>>> Xwayland clients with that driver. If no, how does it avoid the >>>>>>>>>> other >>>>>>>>>> issues described above? >>>>>>>>>> >>>>>>>>> AFAICT, the difference is that the standalone vmwgfx uses an >>>>>>>>> internal >>>>>>>>> copy of drm core. >>>>>>>>> It doesn't reuse the in-kernel drm, hence it cannot know which minor >>>>>>>>> it can use. >>>>>>>>> >>>>>>>>> -Emil >>>>>>>> Actually, standalone vmwgfx could perhaps also try to allocate minors >>>>>>>> from 63 and downwards. That might work, but needs some verification. >>>>>>>> >>>>>>> So unfortuntately this doesn't work since the in-tree drm's file >>>>>>> operations >>>>>>> are registered with the DRM_MAJOR. >>>>>>> So I still think the patch is the way to go. If people are concerned >>>>>>> that >>>>>>> also fbdev file descriptors are allowed, perhaps there are other sysfs >>>>>>> traits we can look at? >>>>>> Somewhat out of curiosity, but why do you have to overwrite all of drm? >>>>>> amdgpu seems to be able to pull their stunt off without ... >>>>>> -Daniel >>>>> At the time we launched the standalone vmwgfx, the DRM <-> driver >>>>> interface was moving considerably more rapidly than the DRM <-> kernel >>>>> interface. I think that's still the case. Hence less work for us. Also >>>>> meant we can install the full driver stack with latest features on >>>>> fairly old VMs without backported DRM functionality. >>>>> >>>> I think this should be fine for 99% of drm usage, there may be corner >>>> cases in wierd places, but I can't point to any that really matter >>>> (maybe strace?) >>>> >>> Having a closer look, I think this will break the Firefox/Chrome >>> sandboxing :-\ >>> I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed >>> list [1] [2]. >> Thanks for pointing this out. >> >> The function drmGetMinorNameForFD() already opens this path, so any >> user-space using that function would not work before either. >> >> Also mozilla/firefox adds /sys/dev/char/226:* Which means that while it >> still won't work on standalone vmwgfx, there should at least be no >> regression. >> >> For Chromium it seems they allow /sys/dev/char/ for AmdGpu, but only under >> ChromOS, so I'll ping those to be safe. >> >> I also won't be doing an immediate release after pushing. >> > In that case, please give me 24h to do a libdrm release before pushing. > I had to push some workarounds for the sandboxing mentioned earlier :-\ > > Thanks > Emil Ouch, I just pushed the patch, but feel free to cut the release just before that commit. /Thomas _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-09-05 13:20 ` Thomas Hellstrom @ 2018-09-05 13:53 ` Emil Velikov 2018-09-30 17:31 ` Thomas Hellstrom 0 siblings, 1 reply; 25+ messages in thread From: Emil Velikov @ 2018-09-05 13:53 UTC (permalink / raw) To: Thomas Hellstrom Cc: Daniel Vetter, Michel Dänzer, amd-gfx mailing list, VMware Graphics, dri-devel On 5 September 2018 at 14:20, Thomas Hellstrom <thellstrom@vmware.com> wrote: >> In that case, please give me 24h to do a libdrm release before pushing. >> I had to push some workarounds for the sandboxing mentioned earlier :-\ >> >> Thanks >> Emil > > > Ouch, I just pushed the patch, but feel free to cut the release just before > that commit. > That doesn't quite work. Barring any objections I'll: revert, release, reapply. -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-09-05 13:53 ` Emil Velikov @ 2018-09-30 17:31 ` Thomas Hellstrom 2018-10-02 19:55 ` Thomas Hellstrom [not found] ` <a3af864a-8914-3bef-ff26-02c7672a9e50-4+hqylr40dJg9hUCZPvPmw@public.gmane.org> 0 siblings, 2 replies; 25+ messages in thread From: Thomas Hellstrom @ 2018-09-30 17:31 UTC (permalink / raw) To: Emil Velikov, Thomas Hellstrom Cc: Daniel Vetter, Michel Dänzer, VMware Graphics, dri-devel, amd-gfx mailing list Hi, Emil, On 09/05/2018 03:53 PM, Emil Velikov wrote: > On 5 September 2018 at 14:20, Thomas Hellstrom <thellstrom@vmware.com> wrote: > >>> In that case, please give me 24h to do a libdrm release before pushing. >>> I had to push some workarounds for the sandboxing mentioned earlier :-\ >>> >>> Thanks >>> Emil >> >> Ouch, I just pushed the patch, but feel free to cut the release just before >> that commit. >> > That doesn't quite work. Barring any objections I'll: revert, release, reapply. > > -Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel What happened here? I can't really see my commit nor a revert nor a release in libdrm. /Thomas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux 2018-09-30 17:31 ` Thomas Hellstrom @ 2018-10-02 19:55 ` Thomas Hellstrom [not found] ` <a3af864a-8914-3bef-ff26-02c7672a9e50-4+hqylr40dJg9hUCZPvPmw@public.gmane.org> 1 sibling, 0 replies; 25+ messages in thread From: Thomas Hellstrom @ 2018-10-02 19:55 UTC (permalink / raw) To: Emil Velikov Cc: Daniel Vetter, Michel Dänzer, linux-graphics-maintainer, dri-devel, amd-gfx mailing list Ping? On 09/30/2018 07:31 PM, Thomas Hellstrom wrote: > Hi, Emil, > > On 09/05/2018 03:53 PM, Emil Velikov wrote: >> On 5 September 2018 at 14:20, Thomas Hellstrom >> <thellstrom@vmware.com> wrote: >> >>>> In that case, please give me 24h to do a libdrm release before >>>> pushing. >>>> I had to push some workarounds for the sandboxing mentioned earlier >>>> :-\ >>>> >>>> Thanks >>>> Emil >>> >>> Ouch, I just pushed the patch, but feel free to cut the release just >>> before >>> that commit. >>> >> That doesn't quite work. Barring any objections I'll: revert, >> release, reapply. >> >> -Emil >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > What happened here? I can't really see my commit nor a revert nor a > release in libdrm. > > /Thomas > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <a3af864a-8914-3bef-ff26-02c7672a9e50-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <a3af864a-8914-3bef-ff26-02c7672a9e50-4+hqylr40dJg9hUCZPvPmw@public.gmane.org> @ 2018-10-04 14:12 ` Emil Velikov [not found] ` <CACvgo5289XdFe9S4r3uSUA20QP37Zy0iiYEW_nHMho4yc0Pi8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 25+ messages in thread From: Emil Velikov @ 2018-10-04 14:12 UTC (permalink / raw) To: Thomas Hellstrom Cc: Thomas Hellstrom, Daniel Vetter, Michel Dänzer, ML dri-devel, VMware Graphics, amd-gfx mailing list On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom <thomas@shipmail.org> wrote: > > Hi, Emil, > > On 09/05/2018 03:53 PM, Emil Velikov wrote: > > On 5 September 2018 at 14:20, Thomas Hellstrom <thellstrom@vmware.com> wrote: > > > >>> In that case, please give me 24h to do a libdrm release before pushing. > >>> I had to push some workarounds for the sandboxing mentioned earlier :-\ > >>> > >>> Thanks > >>> Emil > >> > >> Ouch, I just pushed the patch, but feel free to cut the release just before > >> that commit. > >> > > That doesn't quite work. Barring any objections I'll: revert, release, reapply. > > > > -Emil > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > What happened here? I can't really see my commit nor a revert nor a > release in libdrm. > Coming back from holidays+XDC. I' m doing a release in a moment and will pick your patch just after that. Hmm you said you pushed the patch, yet it's not in master ... Not sure what happened there. Either way - it'll be there shortly. Thanks Emil _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CACvgo5289XdFe9S4r3uSUA20QP37Zy0iiYEW_nHMho4yc0Pi8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <CACvgo5289XdFe9S4r3uSUA20QP37Zy0iiYEW_nHMho4yc0Pi8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2018-10-04 16:43 ` Thomas Hellstrom 0 siblings, 0 replies; 25+ messages in thread From: Thomas Hellstrom @ 2018-10-04 16:43 UTC (permalink / raw) To: Emil Velikov, Thomas Hellstrom Cc: Daniel Vetter, Michel Dänzer, linux-graphics-maintainer, ML dri-devel, amd-gfx mailing list Hi, Emil, On 10/04/2018 04:12 PM, Emil Velikov wrote: > On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom <thomas@shipmail.org> wrote: >> Hi, Emil, >> >> On 09/05/2018 03:53 PM, Emil Velikov wrote: >>> On 5 September 2018 at 14:20, Thomas Hellstrom <thellstrom@vmware.com> wrote: >>> >>>>> In that case, please give me 24h to do a libdrm release before pushing. >>>>> I had to push some workarounds for the sandboxing mentioned earlier :-\ >>>>> >>>>> Thanks >>>>> Emil >>>> Ouch, I just pushed the patch, but feel free to cut the release just before >>>> that commit. >>>> >>> That doesn't quite work. Barring any objections I'll: revert, release, reapply. >>> >>> -Emil >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cthellstrom%40vmware.com%7C01a5434f4ae94d41e02108d62a042d8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636742594763251508&sdata=f4pVmMl%2B2GfI8HIR4GriTD1Ed2eHyEdAttMbcFoavp0%3D&reserved=0 >> What happened here? I can't really see my commit nor a revert nor a >> release in libdrm. >> > Coming back from holidays+XDC. I' m doing a release in a moment and > will pick your patch just after that. > > Hmm you said you pushed the patch, yet it's not in master ... Not sure > what happened there. > Either way - it'll be there shortly. Yes, that's strange. I'm offsite too so I can't check the system from which I pushed it. But anyway, I'll push it later today if you haven't already. Thanks, Thomas > > Thanks > Emil _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <CACvgo53Wd1fq8=V_v7jjuFGimUfh7xD+ccCg-jOTjLSJdWUKeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-08-31 15:30 ` Thomas Hellstrom @ 2018-08-31 15:31 ` Christian König [not found] ` <02acda47-d071-1c97-e151-fcb75d10c656-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 25+ messages in thread From: Christian König @ 2018-08-31 15:31 UTC (permalink / raw) To: Emil Velikov, Michel Dänzer Cc: Daniel Vetter, Thomas Hellstrom, VMware Graphics, amd-gfx mailing list, ML dri-devel Am 31.08.2018 um 17:27 schrieb Emil Velikov: > On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: >> [ Adding the amd-gfx list ] >> >> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> >>>> wrote: >>>>> To determine whether a device node is a drm device node or not, the code >>>>> currently compares the node's major number to the static drm major >>>>> device >>>>> number. >>>>> >>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>>>> >>>> Any particular reason why the code doesn't use a fixed node there? >>>> It will make the diff vs the in-kernel driver a bit smaller. >>> Because then it won't be able to interoperate with other in-tree >>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>> There is no clean way to share the minor number allocation with in-tree >>> drm, so standalone vmwgfx is using dynamic major allocation. >> I wonder why I haven't heard of any of these issues with the standalone >> version of amdgpu shipped in packaged AMD releases. Does that also use a >> different major number? If yes, maybe it's just that nobody has tried >> Xwayland clients with that driver. If no, how does it avoid the other >> issues described above? >> > AFAICT, the difference is that the standalone vmwgfx uses an internal > copy of drm core. > It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. The amdgpu pro package has it's own drm core copy as well and there it still works. Not sure how our back-porting guys handle that. Christian. > > -Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <02acda47-d071-1c97-e151-fcb75d10c656-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux [not found] ` <02acda47-d071-1c97-e151-fcb75d10c656-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2018-09-02 14:54 ` Alex Deucher 0 siblings, 0 replies; 25+ messages in thread From: Alex Deucher @ 2018-09-02 14:54 UTC (permalink / raw) To: Christian Koenig Cc: Thomas Hellstrom, Daniel Vetter, Michel Dänzer, Emil Velikov, amd-gfx list, linux-graphics-maintainer-pghWNbHTmq7QT0dZR+AlfA, Maling list - DRI developers On Fri, Aug 31, 2018 at 11:32 AM Christian König <ckoenig.leichtzumerken@gmail.com> wrote: > > Am 31.08.2018 um 17:27 schrieb Emil Velikov: > > On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote: > >> [ Adding the amd-gfx list ] > >> > >> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: > >>> On 08/31/2018 02:30 PM, Emil Velikov wrote: > >>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com> > >>>> wrote: > >>>>> To determine whether a device node is a drm device node or not, the code > >>>>> currently compares the node's major number to the static drm major > >>>>> device > >>>>> number. > >>>>> > >>>>> This breaks the standalone vmwgfx driver on XWayland dri clients, > >>>>> > >>>> Any particular reason why the code doesn't use a fixed node there? > >>>> It will make the diff vs the in-kernel driver a bit smaller. > >>> Because then it won't be able to interoperate with other in-tree > >>> drivers, like virtual drm drivers or passthrough usb drm drivers. > >>> There is no clean way to share the minor number allocation with in-tree > >>> drm, so standalone vmwgfx is using dynamic major allocation. > >> I wonder why I haven't heard of any of these issues with the standalone > >> version of amdgpu shipped in packaged AMD releases. Does that also use a > >> different major number? If yes, maybe it's just that nobody has tried > >> Xwayland clients with that driver. If no, how does it avoid the other > >> issues described above? > >> > > AFAICT, the difference is that the standalone vmwgfx uses an internal > > copy of drm core. > > It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. > > The amdgpu pro package has it's own drm core copy as well and there it > still works. We don't use our own copy of drm core in the kernel, we rely on the in kernel one. Just ttm and amdgpu are updated in the dkms packages. Alex > > Not sure how our back-porting guys handle that. > > Christian. > > > > > -Emil > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2018-10-04 16:43 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-31 11:54 [PATCH libdrm] libdrm: Allow dynamic drm majors on linux Thomas Hellstrom
2018-08-31 12:15 ` Eric Engestrom
2018-08-31 12:30 ` Emil Velikov
2018-08-31 13:05 ` Thomas Hellstrom
[not found] ` <bbb94b6f-c9d5-27ab-9e6d-4b4c1d85db8e-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2018-08-31 14:38 ` Michel Dänzer
[not found] ` <33fb1ba6-cc44-f747-545b-9f877917933e-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-08-31 14:46 ` Thomas Hellstrom
[not found] ` <e656d26a-be98-cc9c-7962-fd74ad226c60-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2018-08-31 14:49 ` Michel Dänzer
[not found] ` <6d78b948-55bc-3adf-f8c0-691aa80a8bb2-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-08-31 14:59 ` Thomas Hellstrom
2018-08-31 15:27 ` Emil Velikov
[not found] ` <CACvgo53Wd1fq8=V_v7jjuFGimUfh7xD+ccCg-jOTjLSJdWUKeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-31 15:30 ` Thomas Hellstrom
[not found] ` <c1dc7253-d505-dd16-480c-ee9a862d57ef-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2018-09-03 9:16 ` Thomas Hellstrom
2018-09-03 16:33 ` Daniel Vetter
[not found] ` <20180903163310.GJ21634-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-09-03 17:00 ` Thomas Hellstrom
[not found] ` <91ad6140-4e56-afc1-2515-9ca973d0ea05-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2018-09-04 22:33 ` Dave Airlie
[not found] ` <CAPM=9tzScEQ-RWK55zKeT_yXiN6iAyx34DVX1eCgA3ZqC_SpuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-09-05 9:33 ` Emil Velikov
[not found] ` <CACvgo50cfLHWDUEjeNet4H3F4i3okdhSsXfjNiPvH-YZbQsyEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-09-05 10:10 ` Thomas Hellstrom
2018-09-05 13:07 ` Emil Velikov
[not found] ` <CACvgo53t4OSsdmxdHSqrfSWKZGYg4s+uXrSV3gWcignwNxfE8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-09-05 13:20 ` Thomas Hellstrom
2018-09-05 13:53 ` Emil Velikov
2018-09-30 17:31 ` Thomas Hellstrom
2018-10-02 19:55 ` Thomas Hellstrom
[not found] ` <a3af864a-8914-3bef-ff26-02c7672a9e50-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
2018-10-04 14:12 ` Emil Velikov
[not found] ` <CACvgo5289XdFe9S4r3uSUA20QP37Zy0iiYEW_nHMho4yc0Pi8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-10-04 16:43 ` Thomas Hellstrom
2018-08-31 15:31 ` Christian König
[not found] ` <02acda47-d071-1c97-e151-fcb75d10c656-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-09-02 14:54 ` Alex Deucher
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.