Results 1 to 10 of 10

Thread: What does atieventsd actually do?

  1. #1
    Join Date
    Nov 2007
    Posts
    14

    Default What does atieventsd actually do?

    Hello guys and girls!

    I'm using Kubuntu Hardy with ATI 8.5 drivers with a X1950XT PCIe card.

    I had some problems with atieventsd with computer lockups when logging out or shutting the computer. I tried this mod but without success.

    The modded file atieventsd.sh didn't exist in my /etc/ati folder (why?) so I did create a new one. Anyway I disabled the atieventsd with the command:

    Code:
    sudo update-rc.d -f atieventsd remove
    (I don't understand what it technically does, only deleting some files)

    and also deleted my newly created atieventsd.sh file.

    But now I'm a little concerned if this is a really good thing to do. What does atieventsd actually do? What does it control? Fan-speed? Dynamic optimizing of games?

    Please make me a little less concerned. I think many others also want to know what ativentsd actually do, and if it is really important to have it active.

  2. #2
    Join Date
    Apr 2007
    Location
    Michigan
    Posts
    51

    Default

    There was a lot of discussion on this script most users including my Desktop had to patch that file in order for the fix to really work, once patched it did its job. i know this is not the answer your looking for but just wanted to confirm that patching it works, i had to do that for my Kubuntu and Ubuntu test installs for my AT!1300 .
    Try using google and searching on atieventsd Hardy patch (or similar)
    I found this thread to be interesting https://bugs.launchpad.net/ubuntu/+s...24/+bug/118605

  3. #3
    Join Date
    Nov 2007
    Posts
    14

    Default

    Ok, thanks anyway. Maybe it was stupid to use the command:
    Code:
    sudo update-rc.d -f atieventsd remove
    . Is it possible to revert and enable atieventsd again? I'll try to mix and trix to see if it is possible to have atieventsd active without the lockups I get. Maybe I got the atieventsd.sh file wrong.

  4. #4
    Join Date
    Apr 2007
    Location
    Michigan
    Posts
    51

    Default

    Quote Originally Posted by Vantskruv View Post
    Ok, thanks anyway. Maybe it was stupid to use the command:
    Code:
    sudo update-rc.d -f atieventsd remove
    . Is it possible to revert and enable atieventsd again? I'll try to mix and trix to see if it is possible to have atieventsd active without the lockups I get. Maybe I got the atieventsd.sh file wrong.
    try sudo update-rc.d atieventsd install but you really need the patch, i just copied the file to atieventsd.sh.bak then made the changes, it took at least two reboots for it to take affect. I had to use RSEIUB (search google for use)

  5. #5
    Join Date
    Nov 2007
    Posts
    14

    Default

    Ok. I restored the atieventsd with the command:
    Code:
    sudo update-rc.d -f atieventsd defaults
    (install doesn't work) and update-rc.d restored the files it deleted before. Also I did copy the new authatieventsd.sh back to the /etc/ati folder. With several restarts still the computer locks up, I have to use CTRL+ALT+DELETE (or the RSEIUB as you told me) to get out of the lock. It seems that I yet have to disable atievents.d to get rid of the lockout.

    The strange file in /var/run/xauth looks like this:

    A:0-OFWoME and the end letters (i.e. OFWoME) seems to change after every restart. I guess this is normal, but I feel a eager to point this out.

    The code in the authatieventsd.sh file looks like this:
    Code:
    #!/bin/sh
    
    #
    # Control script grant/revoke access to X for the ATI External Events Daemon
    #
    # Distro maintainers may modify this reference script as necessary to conform
    # to their distribution policies.
    #
    # Copyright (c) 2006, ATI Technologies Inc.  All rights reserved.
    #
    
    #
    # Parameters:
    #   $1 is a keyword, either "grant" or "revoke"
    #   $2 is the display name
    #   $3 is the X authorization file to be authorized
    #
    # Returns:
    #   0 if authorization was successfully granted/revoked
    #   nonzero on failure
    #
    # Note:
    #   The third parameter only makes sense if xauth is being used.  If another
    #   mechanism such as xhost is being used it can be ignored.  For setups that
    #   do not do any form of authentication(!) this script can be trimmed down
    #   to just "exit 0" and the daemon will assume that it is always authorized.
    #
    
    GetServerAuthFile()
    {
        # Determine where the authorization key may be hiding.  The location will
        # vary depending upon whether X was started via xdm/kdm, gdm or startx, so
        # check each one in turn.
    
        # Check xorg 7
        XDM_AUTH_MASK=/var/run/xauth/A$1*
        XDM_AUTH_FILE=`ls -t $XDM_AUTH_MASK 2>/dev/null | head -n 1`   # Choose the newest file
        if [ -n "$XDM_AUTH_FILE" ]; then
          SERVER_AUTH_FILE=$XDM_AUTH_FILE
          DISP_SEARCH_STRING="#ffff#"
          return 0
        fi
    
        # Check xdm/kdm
    
        XDM_AUTH_MASK=/var/lib/xdm/authdir/authfiles/A$1*
        XDM_AUTH_FILE=`ls -t $XDM_AUTH_MASK 2>/dev/null | head -n 1`   # Choose the newest file
        if [ -n "$XDM_AUTH_FILE" ]; then
            SERVER_AUTH_FILE=$XDM_AUTH_FILE
            DISP_SEARCH_STRING="#ffff#"
            return 0
        fi
    
        # Check gdm
    
        GDM_AUTH_FILE=/var/lib/gdm/$1.Xauth
        if [ -e $GDM_AUTH_FILE ]; then
            SERVER_AUTH_FILE=$GDM_AUTH_FILE
            DISP_SEARCH_STRING="$1"
            return 0
        fi
    
        # Finally, check for startx
    
        for XPID in `pidof X`; do
            TRIAL_XAUTH_FILE=`tr '\0' '\n' < /proc/$XPID/environ | grep -e "^XAUTHORITY=" | cut -d= -f2`
            TRIAL_XAUTH_KEY=`xauth -f $TRIAL_XAUTH_FILE list | grep "unix$1"`
            if [ -n "$TRIAL_XAUTH_KEY" ]; then
                SERVER_AUTH_FILE=$TRIAL_XAUTH_FILE
                DISP_SEARCH_STRING="unix$1"
                return 0
            fi
        done
    
        # Couldn't find the key
    
        return -1
    }
    
    # Main part of script
    
    #
    # Since the daemon is usually started during init time before X comes up,
    # $PATH may not yet contain the paths to the X binaries, particularly xauth.
    # Add the usual location for where xauth may live and fail out if we still
    # can't find it.
    #
    
    PATH=$PATH:/usr/bin:/usr/X11R6/bin
    which xauth > /dev/null || exit -1
    
    case "$1" in
        grant)
            GetServerAuthFile $2 || exit -1
            DISP_AUTH_KEY=`xauth -f $SERVER_AUTH_FILE list | grep $DISP_SEARCH_STRING | awk '{ print $3 }'`
            if [ -n "$DISP_AUTH_KEY" ]; then
                xauth -f $3 add $2 . $DISP_AUTH_KEY || exit -1
            else
                exit -1
            fi
            ;;
    
        revoke)
            xauth -f $3 remove $2 || exit -1
            ;;
    
        *)
            exit -1
            ;;
    esac
    exit 0
    The file looks like this with the ls -l command:

    Code:
    -rw-r--r-- 1 root root  3161 2008-05-25 08:15 authatieventsd.sh

  6. #6
    Join Date
    Apr 2007
    Location
    Michigan
    Posts
    51

    Default

    Quote Originally Posted by Vantskruv View Post
    Ok. I restored the atieventsd with the command:
    Code:
    sudo update-rc.d -f atieventsd defaults
    (install doesn't work) and update-rc.d restored the files it deleted before. Also I did copy the new authatieventsd.sh back to the /etc/ati folder. With several restarts still the computer locks up, I have to use CTRL+ALT+DELETE (or the RSEIUB as you told me) to get out of the lock. It seems that I yet have to disable atievents.d to get rid of the lockout.

    The strange file in /var/run/xauth looks like this:

    A:0-OFWoME and the end letters (i.e. OFWoME) seems to change after every restart. I guess this is normal, but I feel a eager to point this out.

    The code in the authatieventsd.sh file looks like this:
    Code:
    #!/bin/sh
    
    #
    # Control script grant/revoke access to X for the ATI External Events Daemon
    #
    # Distro maintainers may modify this reference script as necessary to conform
    # to their distribution policies.
    #
    # Copyright (c) 2006, ATI Technologies Inc.  All rights reserved.
    #
    
    #
    # Parameters:
    #   $1 is a keyword, either "grant" or "revoke"
    #   $2 is the display name
    #   $3 is the X authorization file to be authorized
    #
    # Returns:
    #   0 if authorization was successfully granted/revoked
    #   nonzero on failure
    #
    # Note:
    #   The third parameter only makes sense if xauth is being used.  If another
    #   mechanism such as xhost is being used it can be ignored.  For setups that
    #   do not do any form of authentication(!) this script can be trimmed down
    #   to just "exit 0" and the daemon will assume that it is always authorized.
    #
    
    GetServerAuthFile()
    {
        # Determine where the authorization key may be hiding.  The location will
        # vary depending upon whether X was started via xdm/kdm, gdm or startx, so
        # check each one in turn.
    
        # Check xorg 7
        XDM_AUTH_MASK=/var/run/xauth/A$1*
        XDM_AUTH_FILE=`ls -t $XDM_AUTH_MASK 2>/dev/null | head -n 1`   # Choose the newest file
        if [ -n "$XDM_AUTH_FILE" ]; then
          SERVER_AUTH_FILE=$XDM_AUTH_FILE
          DISP_SEARCH_STRING="#ffff#"
          return 0
        fi
    
        # Check xdm/kdm
    
        XDM_AUTH_MASK=/var/lib/xdm/authdir/authfiles/A$1*
        XDM_AUTH_FILE=`ls -t $XDM_AUTH_MASK 2>/dev/null | head -n 1`   # Choose the newest file
        if [ -n "$XDM_AUTH_FILE" ]; then
            SERVER_AUTH_FILE=$XDM_AUTH_FILE
            DISP_SEARCH_STRING="#ffff#"
            return 0
        fi
    
        # Check gdm
    
        GDM_AUTH_FILE=/var/lib/gdm/$1.Xauth
        if [ -e $GDM_AUTH_FILE ]; then
            SERVER_AUTH_FILE=$GDM_AUTH_FILE
            DISP_SEARCH_STRING="$1"
            return 0
        fi
    
        # Finally, check for startx
    
        for XPID in `pidof X`; do
            TRIAL_XAUTH_FILE=`tr '\0' '\n' < /proc/$XPID/environ | grep -e "^XAUTHORITY=" | cut -d= -f2`
            TRIAL_XAUTH_KEY=`xauth -f $TRIAL_XAUTH_FILE list | grep "unix$1"`
            if [ -n "$TRIAL_XAUTH_KEY" ]; then
                SERVER_AUTH_FILE=$TRIAL_XAUTH_FILE
                DISP_SEARCH_STRING="unix$1"
                return 0
            fi
        done
    
        # Couldn't find the key
    
        return -1
    }
    
    # Main part of script
    
    #
    # Since the daemon is usually started during init time before X comes up,
    # $PATH may not yet contain the paths to the X binaries, particularly xauth.
    # Add the usual location for where xauth may live and fail out if we still
    # can't find it.
    #
    
    PATH=$PATH:/usr/bin:/usr/X11R6/bin
    which xauth > /dev/null || exit -1
    
    case "$1" in
        grant)
            GetServerAuthFile $2 || exit -1
            DISP_AUTH_KEY=`xauth -f $SERVER_AUTH_FILE list | grep $DISP_SEARCH_STRING | awk '{ print $3 }'`
            if [ -n "$DISP_AUTH_KEY" ]; then
                xauth -f $3 add $2 . $DISP_AUTH_KEY || exit -1
            else
                exit -1
            fi
            ;;
    
        revoke)
            xauth -f $3 remove $2 || exit -1
            ;;
    
        *)
            exit -1
            ;;
    esac
    exit 0
    The file looks like this with the ls -l command:

    Code:
    -rw-r--r-- 1 root root  3161 2008-05-25 08:15 authatieventsd.sh
    I rechecked the history of what command i used, it was
    sudo update-rc.d -f atieventsd install (i missed the -f on my first reply) this is the pastebin for my http://paste.debian.net/4251/
    also ls -l /etc/ati/authatieventsd.sh
    -rwxr-xr-x 1 root root 3090 2008-05-08 20:22 /etc/ati/authatieventsd.sh
    my patched file is in the pastebin.
    I compared your current authatieventsd.sh and it is missing the patch that mine has.
    I do not know the affect or differences from the options used in "default" and "install" but if you make a backup of your file and then
    make the changes that mine has it might work, I had to reboot a couple of times for it to take hold.

  7. #7
    Join Date
    Nov 2007
    Posts
    14

    Default

    It seemed to help changing the permissions of the authatieventsd.sh file. Now atieventsd is up and running and there is no lockdown when restarting the computer. Thanks very much for the help wirechief!!

    And at last now, ON-TOPIC!

    Edit:sudo update-rc.d -f atieventsd install doesn't work. It seems only to work if you replace the tag install with defaults. Maybe I'm using another version of update-rc.d. I checked the manpage of the app and there is no install tag. But it looked ok creating new files when using the defaults tag.
    Last edited by Vantskruv; 05-26-2008 at 01:36 PM.

  8. #8
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    What does atieventsd actually do?
    Heh, I'd really like to know too what, if anything, actually does.

    For what is worth, I too deleted the apropriate symlinks and don't allow it to run at any moment. This way I don't have lockups when logging out. I haven't noticed anything particularl bad by doing this, although I only use fglrx for gaming; when I'm done I switch to radeon, so I don't know if there is some situation when atieventsd would do something more useful than a hard lock.

  9. #9
    Join Date
    Jan 2008
    Posts
    112

    Default

    first google hit for atieventsd:
    http://www.phoronix.com/scan.php?pag...ntry&item=3750
    One of the new features for the ATI fglrx 8.26.18 drivers is the introduction of the atievents daemon. At this point the ATI fglrx daemon supports hotkey display switching (only with IBM/Lenovo laptops at this time), DFP hotplug, and thermal event power management. If you're not a Lenovo notebook user, the key benefit to the atieventsd daemon should largely be the thermal event power management. Basically this feature will use PowerPlay to down-clock the GPU if the reported temperature exceeds safe levels, and will continue to run at reduced speeds until returning to safe levels. Shortly I will be examining all of the atieventsd features, and hopefully we will continue to see additional daemon improvements from ATI.
    I shall have to look at the permissions for authatieventsd.sh next time I try to install my HD3650, I'm pretty much pulling my hair out every time I try to use this card and I have not looked at the permissions as yet.

  10. #10
    Join Date
    Jan 2011
    Location
    Russia
    Posts
    1

    Default thanks 4 all

    that's fine, thanks

Posting Permissions

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