| Summary: | [!DRM_I915_FBDEV regression] video= ignored | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Chris Wilson <chris> | ||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | normal | ||||||
| Priority: | highest | CC: | intel-gfx-bugs | ||||
| Version: | XOrg git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Chris Wilson
2013-12-30 13:34:33 UTC
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.