On 16/03/17 07:09 PM, Daniel Stone wrote:
On 16 March 2017 at 09:55, Michel Dänzer michel@daenzer.net wrote:
Otherwise this can also prevent modesets e.g. for switching VTs.
FB_MISC_USER_EVENT is set when the request originates from userspace, which is what we're interested in here according to the DRM_DEBUG output.
Bugzilla: https://bugs.freedesktop.org/99841 Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev") Signed-off-by: Michel Dänzer michel.daenzer@amd.com
I'm not entirely sure why the values can not match for a VT switch. If anybody thinks this just papers over the real issue, please speak up.
It happens for me in multi-head with different resolutions. A real compositor will set native resolutions with separate framebuffers, and then fbcon will try to set one buffer for both outputs. This works on the output with the larger resolution, but the one with the smaller resolution will fail due to [xy]res_virtual (IIRC) being different.
That's more or less the line of thinking that lead me to writing this patch, based on the assumption that the fb->* values correspond to what was set by whatever we're VT switching from. However, it occurred to me that it's an invalid assumption; fb here is always fb_helper's framebuffer for fbdev. I think Ville is right that the tests are bogus in the first place.