* [PATCH libdrm] tests/util: Add support for meson module @ 2017-01-18 13:59 Neil Armstrong 2017-01-19 9:19 ` Thierry Reding 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2017-01-18 13:59 UTC (permalink / raw) To: dri-devel; +Cc: treding, emil.l.velikov, Neil Armstrong Add support for Amlogic Meson DRM driver merged for Linux 4.10. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> --- tests/util/kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/util/kms.c b/tests/util/kms.c index 4d89ac8..959b688 100644 --- a/tests/util/kms.c +++ b/tests/util/kms.c @@ -144,6 +144,7 @@ static const char * const modules[] = { "vc4", "virtio_gpu", "mediatek", + "meson", }; int util_open(const char *device, const char *module) -- 1.9.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-18 13:59 [PATCH libdrm] tests/util: Add support for meson module Neil Armstrong @ 2017-01-19 9:19 ` Thierry Reding 2017-01-20 14:13 ` Emil Velikov 0 siblings, 1 reply; 9+ messages in thread From: Thierry Reding @ 2017-01-19 9:19 UTC (permalink / raw) To: Neil Armstrong; +Cc: emil.l.velikov, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 295 bytes --] On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: > Add support for Amlogic Meson DRM driver merged for Linux 4.10. > > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > --- > tests/util/kms.c | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 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] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-19 9:19 ` Thierry Reding @ 2017-01-20 14:13 ` Emil Velikov 2017-01-20 16:17 ` Thierry Reding 0 siblings, 1 reply; 9+ messages in thread From: Emil Velikov @ 2017-01-20 14:13 UTC (permalink / raw) To: Thierry Reding; +Cc: ML dri-devel, Neil Armstrong On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >> --- >> tests/util/kms.c | 1 + >> 1 file changed, 1 insertion(+) > > Applied, thanks. > Was going to say "NACK use Thierry's helpers" but you've beat me to it. As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-20 14:13 ` Emil Velikov @ 2017-01-20 16:17 ` Thierry Reding 2017-01-20 18:28 ` Emil Velikov 0 siblings, 1 reply; 9+ messages in thread From: Thierry Reding @ 2017-01-20 16:17 UTC (permalink / raw) To: Emil Velikov; +Cc: ML dri-devel, Neil Armstrong [-- Attachment #1.1: Type: text/plain, Size: 1473 bytes --] On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote: > On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: > > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: > >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. > >> > >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > >> --- > >> tests/util/kms.c | 1 + > >> 1 file changed, 1 insertion(+) > > > > Applied, thanks. > > > Was going to say "NACK use Thierry's helpers" but you've beat me to it. > As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. I think it's still useful to have this helper to iterate over all supported driver because it enables easy testing with just a simple modetest. That said, for (almost) as long as I remember I've been using the -M option to prevent modetest from iterating over the list, which can take fairly long if you've got DRM_DEBUG messages enabled. I'm not sure I understand exactly what you're suggesting by "use Thierry's helpers". modetest and other tests use util_open() internally now. That in turn uses drmOpen(), though we're of course open to change that. Are you suggesting we somehow use drmDevice to locate existing devices? We could implement some heuristic that finds the first device with a primary node, but what if we want to support the -M option? There is currently no way of getting the driver from drmDevice. Maybe that's something we should add anyway. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 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] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-20 16:17 ` Thierry Reding @ 2017-01-20 18:28 ` Emil Velikov 2017-01-26 15:49 ` Thierry Reding 0 siblings, 1 reply; 9+ messages in thread From: Emil Velikov @ 2017-01-20 18:28 UTC (permalink / raw) To: Thierry Reding; +Cc: ML dri-devel, Neil Armstrong On 20 January 2017 at 16:17, Thierry Reding <treding@nvidia.com> wrote: > On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote: >> On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: >> >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. >> >> >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >> >> --- >> >> tests/util/kms.c | 1 + >> >> 1 file changed, 1 insertion(+) >> > >> > Applied, thanks. >> > >> Was going to say "NACK use Thierry's helpers" but you've beat me to it. >> As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. > > I think it's still useful to have this helper to iterate over all > supported driver because it enables easy testing with just a simple > modetest. > > That said, for (almost) as long as I remember I've been using the -M > option to prevent modetest from iterating over the list, which can take > fairly long if you've got DRM_DEBUG messages enabled. > > I'm not sure I understand exactly what you're suggesting by "use > Thierry's helpers". modetest and other tests use util_open() internally > now. That in turn uses drmOpen(), though we're of course open to change > that. Are you suggesting we somehow use drmDevice to locate existing > devices? > Yes using drmDevice is what I had in mind. The only thing that was stopping me from doing that is the lack of platform devices support. With that in we can start purging _everything_ that uses drmOpen*. > We could implement some heuristic that finds the first device with a > primary node, but what if we want to support the -M option? There is > currently no way of getting the driver from drmDevice. Maybe that's > something we should add anyway. > The -M (kernel module name as given by drmGetVersion) is another interesting topic. Feel free to skip to the Tl;Dr below. If doing the ioctl implicitly via drmOpen or drmDevice wakes up the device, keeping in mind that: - it can take some time, and - you don't always need the info A couple of elaborate workarounds include: - use only on demand - add DRM_DEVICE_GET_MODULE_NAME or alike to the drmDevice2 API Needs a big "this can be VERY slow" warning in the documentation/man pages... first we need actual man pages for libdrm ;-) - deprecate the whole thing and use the compat strings - how do we handle the PCI devices ? - use the kernel module name (foo.ko) - kind of making it an ABI, but iirc we've already have users which depend on it Neither PCI devices nor platform ones are consistent in their naming - foo.ko vs the value returned by the IOCTL. We might be able to combine the latter two ... need to double-check. Tl;Dr: For the moment I'd leave it to the user to call drmGetVersion. Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-20 18:28 ` Emil Velikov @ 2017-01-26 15:49 ` Thierry Reding 2017-01-26 16:14 ` Emil Velikov 0 siblings, 1 reply; 9+ messages in thread From: Thierry Reding @ 2017-01-26 15:49 UTC (permalink / raw) To: Emil Velikov; +Cc: ML dri-devel, Neil Armstrong [-- Attachment #1.1: Type: text/plain, Size: 3332 bytes --] On Fri, Jan 20, 2017 at 06:28:39PM +0000, Emil Velikov wrote: > On 20 January 2017 at 16:17, Thierry Reding <treding@nvidia.com> wrote: > > On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote: > >> On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: > >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: > >> >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. > >> >> > >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > >> >> --- > >> >> tests/util/kms.c | 1 + > >> >> 1 file changed, 1 insertion(+) > >> > > >> > Applied, thanks. > >> > > >> Was going to say "NACK use Thierry's helpers" but you've beat me to it. > >> As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. > > > > I think it's still useful to have this helper to iterate over all > > supported driver because it enables easy testing with just a simple > > modetest. > > > > That said, for (almost) as long as I remember I've been using the -M > > option to prevent modetest from iterating over the list, which can take > > fairly long if you've got DRM_DEBUG messages enabled. > > > > I'm not sure I understand exactly what you're suggesting by "use > > Thierry's helpers". modetest and other tests use util_open() internally > > now. That in turn uses drmOpen(), though we're of course open to change > > that. Are you suggesting we somehow use drmDevice to locate existing > > devices? > > > Yes using drmDevice is what I had in mind. The only thing that was > stopping me from doing that is the lack of platform devices support. > With that in we can start purging _everything_ that uses drmOpen*. > > > We could implement some heuristic that finds the first device with a > > primary node, but what if we want to support the -M option? There is > > currently no way of getting the driver from drmDevice. Maybe that's > > something we should add anyway. > > > The -M (kernel module name as given by drmGetVersion) is another > interesting topic. Feel free to skip to the Tl;Dr below. > > If doing the ioctl implicitly via drmOpen or drmDevice wakes up the > device, keeping in mind that: > - it can take some time, and > - you don't always need the info > > A couple of elaborate workarounds include: > - use only on demand - add DRM_DEVICE_GET_MODULE_NAME or alike to the > drmDevice2 API > Needs a big "this can be VERY slow" warning in the documentation/man > pages... first we need actual man pages for libdrm ;-) > - deprecate the whole thing and use the compat strings - how do we > handle the PCI devices ? > - use the kernel module name (foo.ko) - kind of making it an ABI, but > iirc we've already have users which depend on it > Neither PCI devices nor platform ones are consistent in their naming - > foo.ko vs the value returned by the IOCTL. > > We might be able to combine the latter two ... need to double-check. > > Tl;Dr: For the moment I'd leave it to the user to call drmGetVersion. Okay, sounds like a plan. The good thing is we can keep adding new module names to the util_open() helper irrespective of when we change the implementation to use drmDevice instead of drmOpen() since it is conveniently encapsulated in a single function across libdrm. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 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] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-26 15:49 ` Thierry Reding @ 2017-01-26 16:14 ` Emil Velikov 2017-01-27 7:47 ` Thierry Reding 0 siblings, 1 reply; 9+ messages in thread From: Emil Velikov @ 2017-01-26 16:14 UTC (permalink / raw) To: Thierry Reding; +Cc: ML dri-devel, Neil Armstrong On 26 January 2017 at 15:49, Thierry Reding <treding@nvidia.com> wrote: > On Fri, Jan 20, 2017 at 06:28:39PM +0000, Emil Velikov wrote: >> On 20 January 2017 at 16:17, Thierry Reding <treding@nvidia.com> wrote: >> > On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote: >> >> On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: >> >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: >> >> >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. >> >> >> >> >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >> >> >> --- >> >> >> tests/util/kms.c | 1 + >> >> >> 1 file changed, 1 insertion(+) >> >> > >> >> > Applied, thanks. >> >> > >> >> Was going to say "NACK use Thierry's helpers" but you've beat me to it. >> >> As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. >> > >> > I think it's still useful to have this helper to iterate over all >> > supported driver because it enables easy testing with just a simple >> > modetest. >> > >> > That said, for (almost) as long as I remember I've been using the -M >> > option to prevent modetest from iterating over the list, which can take >> > fairly long if you've got DRM_DEBUG messages enabled. >> > >> > I'm not sure I understand exactly what you're suggesting by "use >> > Thierry's helpers". modetest and other tests use util_open() internally >> > now. That in turn uses drmOpen(), though we're of course open to change >> > that. Are you suggesting we somehow use drmDevice to locate existing >> > devices? >> > >> Yes using drmDevice is what I had in mind. The only thing that was >> stopping me from doing that is the lack of platform devices support. >> With that in we can start purging _everything_ that uses drmOpen*. >> >> > We could implement some heuristic that finds the first device with a >> > primary node, but what if we want to support the -M option? There is >> > currently no way of getting the driver from drmDevice. Maybe that's >> > something we should add anyway. >> > >> The -M (kernel module name as given by drmGetVersion) is another >> interesting topic. Feel free to skip to the Tl;Dr below. >> >> If doing the ioctl implicitly via drmOpen or drmDevice wakes up the >> device, keeping in mind that: >> - it can take some time, and >> - you don't always need the info >> >> A couple of elaborate workarounds include: >> - use only on demand - add DRM_DEVICE_GET_MODULE_NAME or alike to the >> drmDevice2 API >> Needs a big "this can be VERY slow" warning in the documentation/man >> pages... first we need actual man pages for libdrm ;-) >> - deprecate the whole thing and use the compat strings - how do we >> handle the PCI devices ? >> - use the kernel module name (foo.ko) - kind of making it an ABI, but >> iirc we've already have users which depend on it >> Neither PCI devices nor platform ones are consistent in their naming - >> foo.ko vs the value returned by the IOCTL. >> >> We might be able to combine the latter two ... need to double-check. >> >> Tl;Dr: For the moment I'd leave it to the user to call drmGetVersion. > > Okay, sounds like a plan. The good thing is we can keep adding new > module names to the util_open() helper The key point is that you do _not_ need any list. Any new and existing drivers should just work. If they don't then they're [highly likely] broken and should be fixed ;-) -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-26 16:14 ` Emil Velikov @ 2017-01-27 7:47 ` Thierry Reding 2017-01-27 15:42 ` Emil Velikov 0 siblings, 1 reply; 9+ messages in thread From: Thierry Reding @ 2017-01-27 7:47 UTC (permalink / raw) To: Emil Velikov; +Cc: ML dri-devel, Neil Armstrong [-- Attachment #1.1: Type: text/plain, Size: 4107 bytes --] On Thu, Jan 26, 2017 at 04:14:56PM +0000, Emil Velikov wrote: > On 26 January 2017 at 15:49, Thierry Reding <treding@nvidia.com> wrote: > > On Fri, Jan 20, 2017 at 06:28:39PM +0000, Emil Velikov wrote: > >> On 20 January 2017 at 16:17, Thierry Reding <treding@nvidia.com> wrote: > >> > On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote: > >> >> On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: > >> >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: > >> >> >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. > >> >> >> > >> >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > >> >> >> --- > >> >> >> tests/util/kms.c | 1 + > >> >> >> 1 file changed, 1 insertion(+) > >> >> > > >> >> > Applied, thanks. > >> >> > > >> >> Was going to say "NACK use Thierry's helpers" but you've beat me to it. > >> >> As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. > >> > > >> > I think it's still useful to have this helper to iterate over all > >> > supported driver because it enables easy testing with just a simple > >> > modetest. > >> > > >> > That said, for (almost) as long as I remember I've been using the -M > >> > option to prevent modetest from iterating over the list, which can take > >> > fairly long if you've got DRM_DEBUG messages enabled. > >> > > >> > I'm not sure I understand exactly what you're suggesting by "use > >> > Thierry's helpers". modetest and other tests use util_open() internally > >> > now. That in turn uses drmOpen(), though we're of course open to change > >> > that. Are you suggesting we somehow use drmDevice to locate existing > >> > devices? > >> > > >> Yes using drmDevice is what I had in mind. The only thing that was > >> stopping me from doing that is the lack of platform devices support. > >> With that in we can start purging _everything_ that uses drmOpen*. > >> > >> > We could implement some heuristic that finds the first device with a > >> > primary node, but what if we want to support the -M option? There is > >> > currently no way of getting the driver from drmDevice. Maybe that's > >> > something we should add anyway. > >> > > >> The -M (kernel module name as given by drmGetVersion) is another > >> interesting topic. Feel free to skip to the Tl;Dr below. > >> > >> If doing the ioctl implicitly via drmOpen or drmDevice wakes up the > >> device, keeping in mind that: > >> - it can take some time, and > >> - you don't always need the info > >> > >> A couple of elaborate workarounds include: > >> - use only on demand - add DRM_DEVICE_GET_MODULE_NAME or alike to the > >> drmDevice2 API > >> Needs a big "this can be VERY slow" warning in the documentation/man > >> pages... first we need actual man pages for libdrm ;-) > >> - deprecate the whole thing and use the compat strings - how do we > >> handle the PCI devices ? > >> - use the kernel module name (foo.ko) - kind of making it an ABI, but > >> iirc we've already have users which depend on it > >> Neither PCI devices nor platform ones are consistent in their naming - > >> foo.ko vs the value returned by the IOCTL. > >> > >> We might be able to combine the latter two ... need to double-check. > >> > >> Tl;Dr: For the moment I'd leave it to the user to call drmGetVersion. > > > > Okay, sounds like a plan. The good thing is we can keep adding new > > module names to the util_open() helper > The key point is that you do _not_ need any list. Any new and existing > drivers should just work. If they don't then they're [highly likely] > broken and should be fixed ;-) Yeah, what I was trying to say is that the implementation is now centralized, so adding module names until we replace the implementation isn't going to hurt much, while at the same time getting people the support that they want. Once we transition the implementation to using drmDevice, the list will simply disappear and everyone will be using the new code automatically. That said, I have a couple of things on my plate for today, but I'll go reimplement util_open() when I'm done with those. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 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] 9+ messages in thread
* Re: [PATCH libdrm] tests/util: Add support for meson module 2017-01-27 7:47 ` Thierry Reding @ 2017-01-27 15:42 ` Emil Velikov 0 siblings, 0 replies; 9+ messages in thread From: Emil Velikov @ 2017-01-27 15:42 UTC (permalink / raw) To: Thierry Reding; +Cc: ML dri-devel, Neil Armstrong On 27 January 2017 at 07:47, Thierry Reding <treding@nvidia.com> wrote: > On Thu, Jan 26, 2017 at 04:14:56PM +0000, Emil Velikov wrote: >> On 26 January 2017 at 15:49, Thierry Reding <treding@nvidia.com> wrote: >> > On Fri, Jan 20, 2017 at 06:28:39PM +0000, Emil Velikov wrote: >> >> On 20 January 2017 at 16:17, Thierry Reding <treding@nvidia.com> wrote: >> >> > On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote: >> >> >> On 19 January 2017 at 09:19, Thierry Reding <treding@nvidia.com> wrote: >> >> >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: >> >> >> >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. >> >> >> >> >> >> >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >> >> >> >> --- >> >> >> >> tests/util/kms.c | 1 + >> >> >> >> 1 file changed, 1 insertion(+) >> >> >> > >> >> >> > Applied, thanks. >> >> >> > >> >> >> Was going to say "NACK use Thierry's helpers" but you've beat me to it. >> >> >> As a Tl;DR: we _really_ want to stop using drmOpen* for anything that's KMS. >> >> > >> >> > I think it's still useful to have this helper to iterate over all >> >> > supported driver because it enables easy testing with just a simple >> >> > modetest. >> >> > >> >> > That said, for (almost) as long as I remember I've been using the -M >> >> > option to prevent modetest from iterating over the list, which can take >> >> > fairly long if you've got DRM_DEBUG messages enabled. >> >> > >> >> > I'm not sure I understand exactly what you're suggesting by "use >> >> > Thierry's helpers". modetest and other tests use util_open() internally >> >> > now. That in turn uses drmOpen(), though we're of course open to change >> >> > that. Are you suggesting we somehow use drmDevice to locate existing >> >> > devices? >> >> > >> >> Yes using drmDevice is what I had in mind. The only thing that was >> >> stopping me from doing that is the lack of platform devices support. >> >> With that in we can start purging _everything_ that uses drmOpen*. >> >> >> >> > We could implement some heuristic that finds the first device with a >> >> > primary node, but what if we want to support the -M option? There is >> >> > currently no way of getting the driver from drmDevice. Maybe that's >> >> > something we should add anyway. >> >> > >> >> The -M (kernel module name as given by drmGetVersion) is another >> >> interesting topic. Feel free to skip to the Tl;Dr below. >> >> >> >> If doing the ioctl implicitly via drmOpen or drmDevice wakes up the >> >> device, keeping in mind that: >> >> - it can take some time, and >> >> - you don't always need the info >> >> >> >> A couple of elaborate workarounds include: >> >> - use only on demand - add DRM_DEVICE_GET_MODULE_NAME or alike to the >> >> drmDevice2 API >> >> Needs a big "this can be VERY slow" warning in the documentation/man >> >> pages... first we need actual man pages for libdrm ;-) >> >> - deprecate the whole thing and use the compat strings - how do we >> >> handle the PCI devices ? >> >> - use the kernel module name (foo.ko) - kind of making it an ABI, but >> >> iirc we've already have users which depend on it >> >> Neither PCI devices nor platform ones are consistent in their naming - >> >> foo.ko vs the value returned by the IOCTL. >> >> >> >> We might be able to combine the latter two ... need to double-check. >> >> >> >> Tl;Dr: For the moment I'd leave it to the user to call drmGetVersion. >> > >> > Okay, sounds like a plan. The good thing is we can keep adding new >> > module names to the util_open() helper >> The key point is that you do _not_ need any list. Any new and existing >> drivers should just work. If they don't then they're [highly likely] >> broken and should be fixed ;-) > > Yeah, what I was trying to say is that the implementation is now > centralized, so adding module names until we replace the implementation > isn't going to hurt much, while at the same time getting people the > support that they want. > > Once we transition the implementation to using drmDevice, the list will > simply disappear and everyone will be using the new code automatically. > > That said, I have a couple of things on my plate for today, but I'll go > reimplement util_open() when I'm done with those. > Seems like I completely misunderstood you there :-\ Pardon if I came too picky 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] 9+ messages in thread
end of thread, other threads:[~2017-01-27 15:42 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-18 13:59 [PATCH libdrm] tests/util: Add support for meson module Neil Armstrong 2017-01-19 9:19 ` Thierry Reding 2017-01-20 14:13 ` Emil Velikov 2017-01-20 16:17 ` Thierry Reding 2017-01-20 18:28 ` Emil Velikov 2017-01-26 15:49 ` Thierry Reding 2017-01-26 16:14 ` Emil Velikov 2017-01-27 7:47 ` Thierry Reding 2017-01-27 15:42 ` Emil Velikov
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.