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. 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
