1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Questions about Enlightenment porting

Discussion in 'Userland Programming and Scripting' started by vertexSymphony, Jan 2, 2013.

  1. vertexSymphony

    vertexSymphony New Member

    Messages:
    79
    Likes Received:
    0
    Hi people !
    I recently did some changes in my system and wanted to go something more lightweight than KDE (what I normally use) but without losing some aesthetics, so I went with E17.

    I saw some widgets not behaving nice (cpufreq, mixer, temperature, and such) and thought that it could be a good excuse to poke some code and possibly have some experience developing under FreeBSD and contributing.

    Regarding cpu frequency I always solved my problems (in scripts) with the sysctl's under the dev.cpu "tree", is this a correct way of doing it? this goes along same lines with temperature information which also resides under that sysctl tree.

    Thanks for your time and pointers !!

    Regards
     
  2. cpm

    cpm Member

    Messages:
    1,377
    Likes Received:
    2
    Yes, its correct. If you want monitoring CPU temperature just run
    # sysctl -n dev.cpu.0.temperature
    where 0 is the specified core to show.
     
  3. shepper

    shepper Member

    Messages:
    118
    Likes Received:
    0
    Enlightenment just went through some heavy development culminating in a stable release at the end of December. I'm running the stable release in Slackware and I'm impressed.

    When I tried earlier snapshot builds there were alot of things that did not work. Unless you built e17 from current ports it is likely that your desktop is based on pre-release source code and failure to get all the features working may not accurately represent the desktop environment. In Slackware I have only run into one minor quirk - it utilizes pam which is not included in the base Slackware release. If you use the XDM login in manager, when you log out of e17 in Slackware, XDM does not restart. My understanding is that pam is available in FreeBSD.
     
  4. vertexSymphony

    vertexSymphony New Member

    Messages:
    79
    Likes Received:
    0
    @shepper > I installed from ports a couple of days ago (compiled with base gcc, because clang - which is the CC on CURRENT - emits something that causes runtime misbehavior around evas ), and this is a fresh run with no old configs of release e17.

    I had these applets/modules enabled by default and they simply don't work: cpufreq, mixer, keyboard (layout) and temperature

    Well, as soon as I finish setting this up and restore some backups, I'll dig it up.

    @cpu82 > Yep, that's how I read it in my scripts (and I also check for freq, as I have powerd running), but I wanted to ask just to know if there's a specific facility instead of sysctl and if such facility would be a better solution (for example, I can get zfs information through sysctl, but there's a dedicated library for dealing with zfs and using that from C code seems more appropriate )

    Regards.
     
  5. cpm

    cpm Member

    Messages:
    1,377
    Likes Received:
    2
    Try sysutils/zfs-stats to displays general ZFS information and human-readable ZFS statistics about the following subsystems: ARC, L2ARC, zfetch (DMU) and vdev cache.

    zfs-stats: analyzes settings and counters since boot.
    zfs-mon: real-time statistics with averages.

    This data can help to make tuning decisions.

    Take a look at the collectd mailing list, e.g. simple sysctl plugin.
     
  6. vertexSymphony

    vertexSymphony New Member

    Messages:
    79
    Likes Received:
    0
    Well, I took a look at the code and It's actually implemented, here it doesn't work because of this:

    * cpufreq module actually looks for dev.cpu.X.freq, but it's unable to "work" because it lacks privileges.
    * temperature module looks into the hw.acpi.thermal.X.temperature sysctl, which is unexistant in my system; that's because I use amdtemp, which exposes the data through dev.amdtemp and dev.cpu.
    * mixer is actually implemented, but for alsa and pulseaudio (so, if that's running, it may work), no OSS

    I'll poke with it, but unfortunately e17 hangs at initializing =/
    it doesn't happen if I make suid enlightenment_start (without this, it complains about not being to assume root privileges), but that's not a solution, it's a workaround that causes other problems (like runner not being able to lauch certain apps. and such), noticed that enlightenment_sys is not suid and afaik it should.

    enlightenment used to work so well .... *sigh*

    Regards.

    P.S > ty, but the thing about ZFS was an example about getting data from different places and how suitable is each place; Oh, in fact I use zfs-stats :p
     
  7. shepper

    shepper Member

    Messages:
    118
    Likes Received:
    0
    I tried the e17 packages in OpenBSD current and had the same problems with CPU, temp and the mixer.

    I did find a FreeBSD patch for the mixer. I noticed that the patch is over 6 weeks old and did not make it into the final release. OpenBSD has a pulseaudio package that the gnome maintainer came up with (?out of necessity?) that may be worth trying.