[Bug 93885] radeon: allow the user to set a maximum HDMI pixel clock (in MHz) by a kernel parameter

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93885

--- Comment #13 from Elmar Stellnberger <estellnb at elstel.org> ---
Dear radeon developers;
  Today I have tried to give the radeon kernel module a hack: By changing
radeon_dvi_mode_valid to return MODE_OK as soon as the clock is below what I
state in a new kernel parameter called radeon.hdmimhz it was possible to make
new graphics modes appear when hdmimhz is high enough. Besides this the new
parameter has no effect; i.e. My monitor still stays black on higher modes
while it boots with any hdmimhz setting. This is contrary to the behaviour of
nouveau.hdmimhz where it blackscreens on boot when the setting is wrong.
  At next I tried to override max_tmds_clock and mode_clock in
radeon_get_monitor_bpc; without success. Finally I have tried to extend
radeon_best_single_encoder to look through all available encoders and pick the
one with the highest radeon-pixel_clock. Unfortunately there was only one such
decoder to decide from.
  When I look at the output of journalctl after enabling drm.debug=1 it seems
to honor the settings at first but then always goes down to a dotclock of
165MHz or sth. very similar. I have no idea on what to do; further guesses may
be of little success either. 
  Does anyone here have an idea on what should/could be done or on how to
resolve the issue? It needs to be possible in some way to set TMDS timing for
the card in deed and not just simulate higher TMDS for graphics mode detection.
thx.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20160203/f42486ff/attachment.html>