On 16/03/17 07:09 PM, Daniel Stone wrote: > On 16 March 2017 at 09:55, Michel Dänzer <michel@xxxxxxxxxxx> 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@xxxxxxx> >> --- >> >> 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
