nvidia support

[Donjan Rodic]

Binary package hint: conky

This has been written by ushimitsudoki in the questions section.
It doesn't appear to be noted much... well, maybe I should simply give it a bit more time.
But I'm going to reiterate it here as a report anyway ;)

_________________________________________________________________________

Conky has some native nvidia support now but it doesn't appear to be compiled into the ubuntu package.

If I understand correctly, the compile switch is "--enable-nvidia" and it enables several documented nvidia variables such as temperature, image quality, and so forth.

However, currently if the .conkyrc contains something like:
${nvidia threshold}

Then conky startup will report:
Conky: unknown variable nvidia

I think the Ubuntu package should include this support.
_________________________________________________________________________

I'm confirming this on Intrepid and supporting the request to add the nvidia variable to the default repository package.

[Cesare Tirabassi (norsetto)]

I'm against implemeting this for two reasons:

1, Not all users have nvidia cards, and not all nvidia card users may want to use this. Enabling this during compilation will increase the executable size and perhaps have some undesidered side effects too.

2. We would loose our sync from Debian, which we use as a source for this package for no practical benefit.

If however you can convince the Debian maintainer to enable it by default than we would also benefit from this change.

[Donjan Rodic (bryonak)]

I don't want to sound respectless, because I greatly value the work of the devs here... but Cesare, I pretty much disagree with you.

1. Not all users have temperature sensors in their hard drives, and not all users with such sensors want to read the temperature. Should we disable the hddtemp variable? Same goes for almost every single tool in conky: they mostly increase the executable size.
Of course one might argue that the nvidia functionality adds more size, but hey... executable size?? What kind of people makes up the vast majority that runs conky? Users who like eye candy (== Conky compared to CLI based monitors) and run stuff like Compiz on machines with at least 512 - 1024 MB RAM or folks who try to run conky on low-memory embedded systems? And how much difference does the few KB make? How much is it actually?
CPU cycles is a completely different issue, because this would waste performance and battery life (on laptops, which will probably be the majority of end user computers in the future), but I don't think the nvidia variable will increase that one if it's compiled but not used (by users with an ATI card... and Nvidia people then at least have a CHOICE).

_Perhaps_ some undesired side effects? Everything may or may not have undesired side effects... but you know: innocent until proven guilty. Or at least some kind of suspicion, based on reproducible clues.

2. Ubuntu alters packages from Debian if it benefits their users. Your point sounds to me like pushing off responsibility.
And there is obviously benefit because at least two users went to find the right bug tracker and report. As always, only a few actually report, but there's a plethora of other folks who'd like this implemented. For example one of my friends who is new to FOSS and not yet familiar with the user-dev interaction.

I know one shouldn't make assumptions about other people's opinion over the internet.. but still I can't help thinking that you personally dislike Nvidia (mainly because of your 1. reason).

Hopefully you can see my points, even though they might sound a bit harsh.

Regards

[Colin Kelly (colinrk)]

I'm going to side with the devs on this one, I don't think it should be enabled by default for all the reasons mentioned previously. Users that really want it can compile it themselves. Aditionally, the restricted binary driver can report temps and other data to conky just fine without the option enabled at compile time in conky.

[Donjan Rodic (bryonak)]

I don't get it... isn't software supposed to make our lives simpler?
Should we take out hddtemp support because the users who really want it can compile it themselves? The hddtemp tool can report the temperature to Conky fine aswell, without the builtin function.

@Colin Kelly: no related dev has voiced his opinion on this matter yet, so you can't side with one ;)

[Cesare Tirabassi (norsetto)]

As is, we have today enough changes in our package that we would have to merge anyhow from Debian, so, an additional build-dep its not a big deal (this means, reason #2 is not valid anymore).
However, I'm still not convinced that we should enable this at compilation time since it could really benefit only a minority of Ubuntu conky users.

Some data gathering should help: could somebody with the right hardware let me know what is the difference in terms of performance (memory and cpu) of using conky with an exec on nvidia-settings, and with the built-in ${nvidia} variable?
To have representative data please give conky a relatively short update interval and collect your samples at a frequency at least double of that.

Another possibility we can consider is to have a conky-nvidia binary package (or even a conky-all with all compile options enabled). However, to go this way we would need a clear request from the Ubuntu conky user base, which so far doesn't clearly transpire from the attention this bug report got.

[Cesare Tirabassi (norsetto)]

In preparation for the next release, I'm planning to have 3 binary packages: conky-cli, conky and conky-full.

conky-cli should be a basic package to be used in servers or piped with dzen2.
I plan to includes the following support:

MPD, MOC, math, portmon, ALSA mixer, apcupsd

conky should be a good compromise for most users.
It should include the following support:

X11, XDamage, XDBE, Xft, MPD, MOC, math, hddtemp, portmon, RSS,
wireless, Imlib2, ALSA mixer, apcupsd, lua

conky-full should include almost all of the available support:

X11, XDamage, XDBE, Xft, MPD, MOC, OpenMP, math, hddtemp, portmon, RSS
Weather (METAR), wireless, IBM, nvidia, eve-online, Imlib2, ALSA mixer
apcupsd, I/O stats, Lua

Any suggestion/remark?
If anyone wants to post about this on the forums please do.

[Donjan Rodic (bryonak)]

Awesome, thank you for your work!

[Cesare Tirabassi (norsetto)]

There are pre-release jaunty packages in https://launchpad.net/~norsetto/+archive/ppa available for testing.
Feel free to raise eventual bugs here in Launchpad or upstream (http://sourceforge.net/tracker/?group_id=143975&atid=757308, non-packaging bugs only obviously).

PS. In case anyone is interested about the source package, I have already improved both debian/control and debian/copyright so ask before if you have a problem with those.

[Launchpad Janitor (janitor)]

This bug was fixed in the package conky - 1.7.2-0ubuntu1

---------------
conky (1.7.2-0ubuntu1) karmic; urgency=low

  * New upstream release:
    - Improved Lua API (lua_read_parse has been removed in favour of the
      conky_parse() Lua API call).
    - Cairo and Imlib2 bindings for Lua.
    - Built-in weather support.
    - Added own_window_type panel.
    - Added border_inner_margin and border_outer_margin.
      The border_margin config option is now deprecated.
    - Added format_human_readable option.
    - Added fancy new 'temperature gradients'.
    - Several new variables such as $blink, $curl, $desktop, $entropy_perc,
      $swapfree, $to_byte and $top_io.
    - Comments in TEXT section are now possible.
      If necessary the comment character (#) can be escaped with a
      backslash (\#).
    - Added a different default configuration file for builds without X11.
    - Added io_perc, io_read and io_write to $top.
    - Alignment special variables can now be used with objects that span
      multiple lines.
    - Enhanced Imlib2 cache control.
    - $battery_short can now also display F (full), N (not present),
      E (empty) or U (unknown).
    - Counteless bug fixes (LP: #405701, LP: #405340, LP: #405188).
  * Complete overhaul of the packaging (LP: #294933, LP: #387209):
    3 binary packages are now created: conky-cli, conky and conky-all.
    conky-cli is a basic package that could be used in servers
    or piped with dzen2,
    conky supports the most commonly used variables,
    conky-all includes almost all of the available support.
    Use conky-all if you are not sure of your needs.
    Some of the packaging changes include:
    - copyright is now in line with the new format specification
    - rules has been overly simplified
    - short/long descriptions have been updated
    - TODO is not installed anymore, lua.html is installed
    - README.Debian has been obsoleted
    - no change bump of Standards-Version
    - added NEWS and README.source
    - changed automake from automake1.10 to automake1.11, since the former
      has been obsoleted.

 -- Cesare Tirabassi <email address hidden> Tue, 25 Aug 2009 11:27:23 +0200