On Wed, 2018-08-15 at 14:15 -0700, Rodrigo Vivi wrote:
On Tue, Jul 17, 2018 at 09:04:45PM +0100, Chris Wilson wrote:
Quoting Souza, Jose (2018-07-17 18:02:17)
On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote:
Quoting José Roberto de Souza (2018-07-16 23:38:36)
GPU accelerators usually don't have display block or the display driver part can be disable when building driver(for servers it save some resources) so it is important let userspace check this capability too.
We currently communicate that by having no modeset resources. What does another cap bit accomplish that we don't already know?
This is a hackish way to check if driver support modeset, drmModeGetResources()/drm_mode_getresources() can fail and return null by other reasons and just check for the errno value can be misleading too.
Do not confuse libdrm with the ioctl. You do not need to allocate anything for such a check, and it is being used directly without allocations as a has-kms check.
More to the point existing userspace determines modeset capability through the reported resources. Your changelog needs to explain why they are inadequate and how you plan to coordinate your fix with userspace. As it stands you are introducing uABI with no user...
I agree with Chris here. There is no indication on how this will affect userspace here and this so far is just a uABI without user that is a big blocker.
The user would be IGT but I would only send the patch after get this merged.
Okay, I can drop this patch without any changes in this series.
And I also got confused because that modeset capability check got introduced in a block that is for "/* Only some caps make sense with UMS/render-only drivers. */"
-Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx