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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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@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@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@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@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@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?

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel