[PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

[Hans de Goede]

Hi,

On 11-11-2019 15:11, Ville Syrjälä wrote:
> On Mon, Nov 11, 2019 at 10:50:42AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11-11-2019 10:25, Daniel Vetter wrote:
>>> On Sun, Nov 10, 2019 at 7:41 PM Hans de Goede <hdegoede at redhat.com> wrote:
>>>>
>>>> drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
>>>> a video= argument over calculating our own timings for the user specified
>>>> mode using CVT or GTF.
>>>>
>>>> But userspace code which is auto-configuring the mode may want to know that
>>>> the user has specified that mode on the kernel commandline so that it can
>>>> pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.
>>>>
>>>> This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
>>>> as we would do on the user-specified mode when no matching probed mode is
>>>> found.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>
>>> Will existing userspace dtrt here with this? Some links to popular
>>> ones would be good (since essentially this is uapi fine tuning we need
>>> that anyway). With that will get my ack.
>>
>> A valid question, I've gone over what I consider the major userspace kms users:
>> -Xorg xserver modesetting driver does not check for this:
>>    [hans at shalem xserver]$ ack DRM_MODE_TYPE_ hw/xfree86/drivers/modesetting/
>>    hw/xfree86/drivers/modesetting/drmmode_display.c
>>    1321:    if (kmode->type & DRM_MODE_TYPE_DRIVER)
>>    1323:    if (kmode->type & DRM_MODE_TYPE_PREFERRED)
>> -Other Xorg drivers:
>>    [hans at shalem driver]$ ls -d xf86-video-*
>>    xf86-video-amdgpu  xf86-video-intel        xf86-video-qxl
>>    xf86-video-armsoc  xf86-video-modesetting  xf86-video-sisusb
>>    xf86-video-ati     xf86-video-nouveau      xf86-video-vmware
>>    xf86-video-dummy   xf86-video-omap         xf86-video-voodoo
>>    xf86-video-geode   xf86-video-opentegra
>>    These all only do the same checks as the Xorg modesetting driver
>> -mutter:
>>    [hans at shalem mutter]$ ack DRM_MODE_TYPE_
>>    src/backends/native/meta-output-kms.c
>>    261:      if (drm_mode->type & DRM_MODE_TYPE_PREFERRED)
>>
>> So it seems nothing (that I can quickly find) in userspace is using this atm.
>>
>> The reason I wrote this patch is because about a year ago plymouth used to
>> fully rely on the kernel to setup the modes on monitors and would simply
>> inherit the modes setup by the kernel. Basically plymouth was relying on
>> fbcon to load first and setup modes.
>>
>> Deferred fbcon takeover (for flickerfree) means that this is no longer
>> happening. So now plymouth picks a mode itself. When I submitted the
>> plymouth change for plymouth to pick a mode itself the plymouth maintainer
>> (Ray Strode) was afraid that would break plymouth honoring video= arguments.
>> So currently plymouth still relies on the kernel to do the mode setup if
>> a video= argument is present on the kernel commandline.
> 
> Why can't plymouth just keep using the current mode if the crtc is
> already active and otherwise pick a mode itself?

Well for one the firmware may have setup an output with a non
native mode because it always uses e.g 1024x768, we really want to
switch to the preferred mode in that case.

We could only pick the current mode if the crtc is already active
when video= is present on the kernel cmdline in an attempt to
honor video= arguments, but that will only work if fbcon has
already setup the modes according to the video= arguments and with
flickerfree boot we defer loading fbcon until there are kernel are initrd
errors to show. So in order to honor video= in a flickerfree setup
plymouth needs to pick the requested mode itself. Actually knowing which
mode is requested makes this a lot easier.

Regards,

Hans