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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
