=0 ickle:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro quiet video=LVDS-1:d drm_kms_helper.poll=0 =0 ickle:~$ xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767 LVDS1 connected (normal left inverted right x axis y axis) 1024x768 60.0 + 800x600 60.3 56.2 640x480 59.9 VGA1 connected (normal left inverted right x axis y axis) 1920x1080 60.0 + 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis)
The video= kernel parameter is handled by fbmem, which is queried for fb options by drm fb helper. None of the drm fb helper functions get called by i915 when CONFIG_DRM_I915_FBDEV=n, and thus the kernel parameter is ignored altogether. With CONFIG_DRM_I915_FBDEV=n you could configure CONFIG_DRM_KMS_FB_HELPER=n and CONFIG_FB=n, AFAICT. It sounds like you have an implied expectation that video= kernel parameter should work regardless of CONFIG_DRM_I915_FBDEV when CONFIG_FB=y. (Or when both that and CONFIG_DRM_KMS_FB_HELPER=y?) Indeed, the bigger question seems to be who does the video= kernel parameter belong to, really? Should it be made independent of FB, usable in DRM also when all of the above mentioned configs are disabled? Definitely the drm fb helper uses it for more than just FB. Or should DRM have a compatible drm.video= module parameter instead? Insights welcome.
The simple rule of thumb is that you can currently configure which outputs are on and at what resolution. After the config change, you cannot. This important for devices that have ghost outputs (either due to bad VBT, fuses etc, or just as commonly broken displays) and also for specifying the resolution that X and Wayland should use for initialisation. From that perspective this is a regression. Moving the video= parsing out of video/fb would seem to be a sane plan, along with i915.video=, radeon.video= for syntatic sugar. Open for suggestions.
On Wed, Feb 12, 2014 at 1:45 PM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > BTW another funky issue I noticed about the video= option is that if you > specify a mode that's not part of the set of modes added by > drm_add_modes_noedid(), then fbcon will happily use the specified mode, > but when X starts the mode gets pruned from the mode list. It would > seem better to keep the user specified mode on the list, no matter what. Yeah, I think we need to move the cmdline parsing out of the fbdev helper into crtc helpers so that this kind of stuff Just Works. Then we could also add the cmdline mode as the first preferred one. -Daniel
Created attachment 99080 [details] [review] Perform cmdline mode parsing during connector init
Looks like this patch is live. Reopen if necessary.
(In reply to comment #5) > Looks like this patch is live. Reopen if necessary. Please don't close bugs until the patch is actually merged upstream.
commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation Please file new bugs for any gaps.
Closing resolved+fixed. No comments on two years, so assuming that cmdline parsing is now working as expected.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.