next »

[moocapiean]

Thanks!  I've been struggling all day trying to get the permission problem solved myself.  I installed sudo and got it to work running from the terminal, but when I used the keys, it wouldn't work.  What was your hack?

[ktrout153]

My hack involved chmod 666...  Terrible but effective.  Like I said, I am horrible with permissions.  I live in the boonies so I am not worried about it for now.  I know if you change the ownership to olpc, it would work fine but might break all kinds o' other stuff!

My guess is that the "proper" way would be to change the ownership of this file to a group that includes both root and olpc.  I just don't know how to do it right.  It is easy to fix a file's permissions, but much harder to fix that kind o' screw up! 

I just realized I missed something that simplifies mute toggling.  It is built into the mixer program.  Go figure...

"amixer -c 0 Master,0 toggle"


Kilgore Trout

[ktrout153]

Here's an improvement.  It is not world writable now so should be *more* secure...

Change the "brightness" file's group to olpc:
chown root:olpc brightness

Change the permissions for owner and group writing:
chmod 764 brightness

As an extra step, I gave ownership of my script to root
chown root:olpc scriptname

Now, here is the real problem.  The brightness file's permissions are "fixed" when you reboot.  I'm hunting for where this happens but the worst case is that these commands can be added to rc.local.

Kilgore

[moocapiean]

Now, here is the real problem.  The brightness file's permissions are "fixed" when you reboot.  I'm hunting for where this happens but the worst case is that these commands can be added to rc.local.

I'm putting them in a script in my home directory, then telling Xfce to run that script when you log in (Xfce Menu -> Settings -> Autostarted Applications).

[moocapiean]

I finally have the brightness thing working.  Thanks to those who provided some of the steps!

First, install and set up xbindkeys (see ktrout153's comment: http://olpcnews.com/forum/index.php?topic=592.msg6317#msg6317).

Now, as root, copy this file and put it in /usr/bin/adjust_brightness.sh

Code:

#!/bin/bash
# The first argument is whether to increase the brightness (+) or
# decrease the brightness (-).
# The second argument is optional and indicates the step size when
# increasing or decreasing the brightness. The default is 1.

if [ $# -eq 0 ]; then exit 1; fi

bright_file="/sys/class/backlight/dcon-bl/brightness"
mbright_file="/sys/class/backlight/dcon-bl/max_brightness"

while read line; do
brightness=$line
done < <(cat "$bright_file")

while read line; do
max_brightness=$line
done < <(cat "$mbright_file")

step=1
if [ $# -gt 1 ]; then
 step=$2
fi

declare -i brightness
if [ $1 = "-" ]; then
 if [ $brightness -ne 0 ]; then
  brightness=$brightness-$step;
  echo $brightness > /sys/class/backlight/dcon-bl/brightness
 fi
else
 if [ $brightness -ne $max_brightness ]; then
  brightness=$brightness+$step;
  echo $brightness > $bright_file
 fi
fi

chmod a+x /usr/bin/adjust_brightness.sh

Now open ~/.xbindkeysrc and add at the bottom of the file:

Code:

# Increase brightness
"adjust_brightness.sh +"
c:76
# Decrease brightness
"adjust_brightness.sh -"
c:75

We want xbindkeys to start when we log in.  I'm sure there's a more proper way to do this, but here's what I did:
Create a new file in your home directory, I called mine ~/.xfce4_startup

Code:

#!/bin/bash
xbindkeys

Add it to the startup scripts using Xfce Menu -> Settings -> Autostarted Applications
Also, run:
chmod +x ~/.xfce4_startup

Now all that remains is to set the permissions on the brightness sys file:
(as root:)
chgrp olpc /sys/class/backlight/dcon-bl/brightness
chmod g+w /sys/class/backlight/dcon-bl/brightness

Unfortunately, these changes won't last when you restart, so we need to make sure those happen every time we turn on our XO.  Here's the way I came up with to do that:

We first need to install sudo.  As root:
yum install sudo

Now, we need to give the olpc user permission to change the permissions on /sys/class/backlight/dcon-bl/brightness.  Again as root:
/usr/sbin/visudo

That'll open a file in vi.  If you're not familiar with vi, I'd recommend using nano.  Run this instead:
EDITOR=/usr/bin/nano /usr/sbin/visudo

Now that you have the file open, scroll down to the bottom and add these lines:

Code:

olpc ALL=(root) NOPASSWD: /bin/chgrp olpc /sys/class/backlight/dcon-bl/brightness
olpc ALL=(root) NOPASSWD: /bin/chmod g+w /sys/class/backlight/dcon-bl/brightness

Since we want those commands to execute when we log in, we should add those to our startup script too.  Open that startup script we created above and put at the bottom:

Code:

sudo chgrp olpc /sys/class/backlight/dcon-bl/brightness
sudo chmod g+w /sys/class/backlight/dcon-bl/brightness

Well, that should be everything.  Again, thanks to those who provided some of the steps above.

[amorfeusz]

Some may find this helpful as well:

http://wiki.laptop.org/go/Xfce

Also, can anyone post the contents of the .xsession-example ? This does not appear to be included in the 653 build. Thanks

[ktrout153]

Here it is:

Code:

# Copy this file to ~/.xsession to customize your X session
#
# Contents of this file are preserved on updates because it lives in your $HOME
# Check the master copy in /etc/skel/.xsession-example for updates
#

# Uncomment the following lines to turn on many sugar debugging
# log files and features
#export LM_DEBUG=net
#export GABBLE_DEBUG=all
#export GABBLE_LOGFILE=/home/olpc/.sugar/default/logs/telepathy-gabble.log
#export SALUT_DEBUG=all
#export SALUT_LOGFILE=/home/olpc/.sugar/default/logs/telepathy-salut.log
#export GIBBER_DEBUG=all
#export PRESENCESERVICE_DEBUG=1
#export SUGAR_LOGGER_LEVEL=debug

# Uncomment the following line to enable core dumps
#ulimit -c unlimited

# Uncomment the following line to debug sugar startup problems
#exec xterm

# If you drop out of this script, the normal olpc-session will proceed
# Uncomment the following line to prevent it
#exit 0

Kilgore

[amorfeusz]

Thank you! - I also just figured out it was a hidden file (linux newbie)

[joshuajon]

Some may find this helpful as well:

http://wiki.laptop.org/go/Xfce

This works great! One question though, how does one use the genmon plugin to monitor battery status?

Nevermind, I must not have installed it the first time.  BTW I found a nice post explaining how to use genmon to monitor battery life:

http://www.freelikegnu.org/?p=15&page=1

Cheers!

[jdebay]

Thanks to all, I am working on something else at the moment.

Just got qemu working correctly to emulate XO, writing from there.

When I have another day off. I will Install Xfce to qemu, then if all goes well, with testing, then on to the lean-mean-green machine. I was wondering along these lines a few days ago. I am doing some testing in cold New England weather with it as a camera in the neighborhood. Cat does not understand me stand in the snow storms, with my green system.

Again, Thanks a million to all that have done and shared in Post Xfce.

J
 

[patnukem]

I used the instructions on the post about Ubuntu on the xo,  it points to this site http://lists.laptop.org/pipermail/devel/2007-December/009026.html  for the unofficial xfce-debian etch build it was quite easy and allows you to switch between them on boot with the O game pad key.  it does require the dev key.  as for kevin_stevens comment below I just added the Requires dev key since the instructions ask for it in the link.

[Andrew Jensen]

as for choosing between sugar and xfce, it seems like you could just use the original line in .xsession (exec xterm) to start up X with a terminal, and then type either sugar or startxfce4 from there to launch either window manager.

I've done this. First, Sugar has a Grey circle app in the wheel when I start sugar from the terminal, and killing it kills sugar and drops me down to command line again.

Second, the terminal that opens up is really, really tiny. I have trouble reading it. Is there anything I can do about that?

[kevin_stevens]

I used the instructions on the post about Ubuntu on the xo,  it points to this site http://lists.laptop.org/pipermail/devel/2007-December/009026.html  for the unofficial xfce-debian etch build it was quite easy and allows you to switch between them on boot with the O game pad key.  it does require the dev key. 

No, it doesn't.  Again, the dev key is required to change OpenFirmware settings, or to specify boot images.  The alternate system boot capability provided by the O key startup is an integral part of the machine.  The debian load can be performed on a security-enabled G1G1 650 build XO.

KeS

[Andrew Jensen]

I decided to run xfce alongside sugar (watch out on memory usage though, I had to start using a usb stick as swap!), so I installed it like so:

Code:

$ su -
# yum install xfce-utils

Then I dropped to a virtual-console via CTRL-ALT-F2 (that's F2 as in the friends view button), logged in as user olpc (I had to run passwd olpc as root first to get a password), and ran the following (inspired by this page):

Code:

$ startx /usr/bin/startxfce4 -- :1 -fp built-ins -wr

This started xfce fullscreen in a new separate x-server.  Open a terminal or file manager and go to town!  To switch between sugar and xfce, use CTRL-ALT-F3 (that's the home view key) to go to sugar, and CTRL-ALT-F4  (activity/frame key) to go to xfce.

I followed these directions and got the following error:

Code:

fatal server error:
Server is already active for display 0
            If this server is no longer running, remove /tmp/.XO-lock
            and start again.

I'm having the same problem and I'm not sure what's going on either.  The emulated XO (build 653) doesn't appear to have this problem though.  I've been working on getting rid of all those ~/.serverauth.* files and setting up a display manager (to choose between sugar and xfce).

During my work on those, I've come across some evidence to suggest it's caused by shutting down X through X (such as using xfce's Quit button):
http://www.shallowsky.com/blog/linux/serverauth.html
Quote
Okay, so why is the current code a problem? Because startx creates the file, calls xinit, then removes the file. In other words, it relies on xinit (and the X server) exiting gracefully. If anything else happens -- for example, if you shut your machine down from within X -- the startx script (which does not catch signals) can die without ever getting to the code that removes the file. So if you habitually shut down your machine from within X, you will have a .serverauth.Huh? file from each X session you ever shut down that way.

That's talking about the .serverauth files, but I'm wondering if the problems are related.

I don't have my XO with me right now, but I'll experiment some more tomorrow.

Hopefully that helps shed some light on this.

Have you tried the fix suggested in the page you link? It's for Ubuntu, so would iit still work for the fedora build the XO is using?

[bradpitcher]

Second, the terminal that opens up is really, really tiny. I have trouble reading it. Is there anything I can do about that?

sounds like you may be opening xterm.  have you tried Terminal?  If it is xterm you should be able to change the font size using the Ctrl-Right-click menu, although I haven't gotten it to work.