Personally, I would gladly make a replacement to DRIConf if...:
* I had a modern nvidia GPU
* I knew more about what features can and can't be enabled for each device
* If I had a clear idea of what all the features actually do (there are way too many ambiguous or vague GUIs out there, and I don't want to make yet another one)
* If the linux community wasn't filled with so many self-righteous assholes who will always find something to be lacking
It surprises me that DRIConf hasn't been updated since, from a programming perspective, it really is generally a very easy straight-forward GUI to make. However, it wouldn't surprise me if the developer canceled it because too many people complained "it's missing this feature" or "its getting too user unfriendly" and so on. When you take on a project of this caliber, you're going to get a lot of flak if you don't keep up with it and have a solid plan.
I think what we need now is a protocol, sitting behind a dbus service (somewhat like what XRandR does). This way you can separate the job of writing clients and services, meaning developers can work on what is good for them. e.g. desktop guys can worry about getting it looking good, whereas backend/driver guys can worry about it working.
and for fstab:Code:mount -t debugfs none /sys/kernel/debug
Yes, it use lm_sensors. Today I modified some code responsible for gathering temp info from sensors, so maybe now it will work.Code:debugfs /sys/kernel/debug debugfs defaults 0 0
I can provide support only for Radeons (I have SI in PC and R730 in laptop).
For the DRI, there is only these options?
That seems to be far from exposing all available options.