A few questions about Open-Source ATI driver developement
Hi, if anyone knows the answers to these questions I'd be really grateful:
-are there any plans to fix TV-out support (only one res seems to work now)
-will we ever see some sort of a control center for open ATI driver?
-maybe it's just my hardware, but the open source driver seems to detect only half of the modes detected by the ATI closed driver (i.e. resolutions are detected fine, refresh rates not) and actually the situation was better in the past... is there any work being done in this area?
Forgive me if the questions are silly or asked at a wrong place.
grep EDID /var/log/Xorg.0.log
If there is no output you should specify 3 things in your monitor section:
1) HorizSync horizsync-range
2) VertRefresh vertrefresh-range
3) DisplaySize width height
This optional entry gives the width and height, in millimetres,
of the picture area of the monitor. If given this is used to
calculate the horizontal and vertical pitch (DPI) of the screen.
Alex did some work on TV-out for newer chips based on the programming information we have been able to dig up so far, but it's not working properly yet. The hardware changed quite a bit over the last few generations so some chips are working better than others... right now I think 5xx is the worst IIRC. There will be more work done on this after we get the first round of 6xx/7xx 3D code working better.
Originally Posted by borsook
I don't think there are any plans to write a control panel specifically for our GPUs; the idea is that these functions are being written as part of the desktop suites and hooked into the drivers through RandR or other configuration mechanisms, giving a solution that works for all hardware not just ours.
I wasn't aware of a different mode set being loaded; AFAIK all the drivers start with modes based on EDID info from your display, then optionally patch in additional modes. The open drivers running with user modesetting patch in a standard mode list from the X server, open drivers running KMS don't patch in anything today IIRC, and I guess the fglrx driver may patch in a different set of modes we accumulated over the years in the common modesetting code, although I had actually been under the impression that fglrx patched in the list from the x server just like the open drivers. I'll add this to the list of things to investigate as time permits.
You can add custom modelines manually at run time with xrandr --newmode/--addmode or via your xorg.conf. See this page for more info:
xrandr --newmode "1152x864" 81.75 1152 1216 1336 1520 864 867 871 897 -hsync +vsync
xrandr --addmode VGA-0 "1152x864"
It is possible that the lack of refresh rates is a problem related to my monitor not the driver, although both under Windows and fglrx all the modes appear fine, so...
Originally Posted by bridgman
The open source monitor adds the modes from the edid, and in the case of CRT monitors, it adds the the default server modes that are applicable based on the sync ranges from the edid. Any other modes need to be user added. Adding additional default modes gets tricky as every user has an ideal set modes so it become an issue of which modes to add, and lots of LCD monitors are very picky about what mode timings and won't work with arbitrary modes.
Originally Posted by borsook
Yes i know but he dont save this. for each start i have to do this. in the past i have make a little script that the xserver at each start launch. But i think this is not the best solution.
Originally Posted by agd5f
As I also said, you can add modelines to the monitor sections associated with each output to your xorg.conf as well. These will be added every time you start X assuming the monitor is connected. See this page for more info:
Originally Posted by Nille