[PATCH xf86-video-ati 5/6] Make all active CRTCs scan out an all-black framebuffer in LeaveVT
Michel Dänzer
michel at daenzer.net
Thu Aug 31 02:35:13 UTC 2017
On 30/08/17 07:27 PM, Emil Velikov wrote:
> On 30 August 2017 at 09:04, Michel Dänzer <michel at daenzer.net> wrote:
>> On 29/08/17 07:56 PM, Emil Velikov wrote:
>>
>>> IIRC the vmwgfx's kernel driver, which has extra locking [1] in order
>>> to address that.
>>> Would a similar approach like that be applicable for radeon/amdgpu?
>>
>> I don't see how that's related.
>>
>> The issue is that if the caller of DRM_IOCTL_MODE_GETFB is DRM master
>> (or root, or using a DRM control device node), the ioctl returns a valid
>> GEM handle for the framebuffer, so the caller can use the underlying
>> buffer arbitrarily. This is handled by core DRM code, there's nothing
>> kernel drivers can do about it.
>>
> Disclaimer: I'm might be a mile off.
>
> vmgfx's vmw_master_check() which does the usual DRM master/control or
> root checking.
> There is a "Check if we were previously master, but now dropped" which
> seems, perhaps too vaguely, related to what's happening here.
>
> Admittedly I've not looked too closely at the locked_master and
> associated ttm code (ttm_read_lock, etc).
> But was under the impression that it is used to restrict access to the
> [contents behind the] GEM handle, when DRM master is dropped.
I'm not familiar with that code either, so I may be wrong, but AFAICT
it's kind of the opposite, allowing userspace which was previously DRM
master to do some things it otherwise wouldn't be allowed to do.
Whereas this change is about something userspace can do while it's DRM
master, and which cannot be disallowed per se without breaking userspace
(e.g. smooth bootsplash -> login screen -> user session transitions).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the amd-gfx
mailing list