Jocelyn, Thomas, JF> I think the culprit is probably this patch: JF> https://patchwork.freedesktop.org/patch/486242/ JF> JF> before this patch, JF> mgag200_simple_display_pipe_mode_valid() always return MODE_OK JF> JF> after this patch, it checks the bandwidth limit too. I can easily test this theory, which sounds entirely reasonable - I will do so and let you know the result. TZ> I'm not quite sure how to proceed here, as the driver is correct and TZ> the problem came from a mismatching config file on your system. In so far as a user's viewpoint is relevant, I would say this: A user wants to be able to obtain any mode that actually is usable with his hardware. He starts from a position of not having any extra config files in place, and it works. He wants a different mode, so he adds a config file. If he does that deliberately, then the system should allow it, even if it goes over some theoretical limit - as if he gets no video, he will then know exactly why he got no video (and can use the tty interface after a reboot to remove his config file). (But by all means put a warning message in the logs.) What is really bad is for a mode that used to work to stop working with no explanation - and even to stop working in such a manner that the only way to get the system back is to force a reboot by removing power rather than defaulting to a different mode. (But I think that that behaviour results from userspace not expecting a late rejection of the mode.) Moreover, any decent system that uses a GUI to allow you to change screen mode offers you a preview before locking that mode in - and automatically reverses the change if the user doesn't confirm it. So I would prefer a mode chosen by a deliberate xorg config file to not be rejectable by the driver, but just give a warning in the logs. (But I do understand that you will also need to consider other points of view.) I'll confirm the result of the above test shortly. Thanks, Roger.
