Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: DRIConf Is Still A Mess & Leaves A Lot To Be Desired

  1. #11
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,316

    Default

    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.

  2. #12
    Join Date
    Oct 2008
    Posts
    3,137

    Default

    Quote Originally Posted by schmidtbag View Post
    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.
    Just to be clear, guys, DRIConf has new options/settings added to it all the time. The program just reads in xml files to generate the UI. I'm sure it's that process that hasn't changed in forever, no doubt because the devs feel like it performs well enough for their needs and they are focused on actually making the hardware work rather than beautifying the GUI.

  3. #13
    Join Date
    Jan 2008
    Location
    South Africa
    Posts
    233

    Default

    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.

  4. #14
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,316

    Default

    Quote Originally Posted by smitty3268 View Post
    Just to be clear, guys, DRIConf has new options/settings added to it all the time. The program just reads in xml files to generate the UI. I'm sure it's that process that hasn't changed in forever, no doubt because the devs feel like it performs well enough for their needs and they are focused on actually making the hardware work rather than beautifying the GUI.
    True, but it doesn't mean it isn't still lacking in features, such as the ones mentioned in the article. Also, there could still be better ways of approaching some of the options.

  5. #15
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,112

    Default

    Quote Originally Posted by Vim_User View Post
    So, do you think we should wait another 7 years until someone implements the available options?
    It's all dynamic - the GUI generates the buttons by asking the driver what options it has. If you want to see the XML yourself, type "xdriinfo options 0", it even includes translations in a few languages.

    So technically it doesn't matter the code is from 2006.

  6. #16
    Join Date
    Aug 2013
    Location
    Poland
    Posts
    27

    Default

    Quote Originally Posted by Hamish Wilson View Post
    It looks nice and is conveniently in the AUR, but it does not fully seem to probe my card properly:



    EDIT: It needs root privileges - but still can't see my temperature, which is strange since it uses lm_sensors.
    The clocks and volts data are in debugfs so it need to be mounted:
    Code:
    mount -t debugfs none /sys/kernel/debug
    and for fstab:
    Code:
    debugfs  /sys/kernel/debug  debugfs  defaults  0  0
    Yes, it use lm_sensors. Today I modified some code responsible for gathering temp info from sensors, so maybe now it will work.
    I can provide support only for Radeons (I have SI in PC and R730 in laptop).

    For the DRI, there is only these options?
    http://dri.freedesktop.org/wiki/ConfigurationOptions/

  7. #17
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by curaga View Post
    It's all dynamic - the GUI generates the buttons by asking the driver what options it has. If you want to see the XML yourself, type "xdriinfo options 0", it even includes translations in a few languages.

    So technically it doesn't matter the code is from 2006.
    Oh, I have done that already, as I was curious and had a look at the code. I get the astonishing amount of 11 options here on my HD6870, except setting vblank none of them is useful (who the hell needs options like ""A post-processing filter to remove the blue channel").
    That seems to be far from exposing all available options.

  8. #18
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,030

    Default

    Quote Originally Posted by marazmista View Post
    Yes, it use lm_sensors. Today I modified some code responsible for gathering temp info from sensors, so maybe now it will work.
    Cheers, it now works like a charm, with the right privileges.

    Last edited by Hamish Wilson; 10-17-2013 at 03:28 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •