blue print - develop spec for GUI application for changing modes on the fly

Len Ovens len at
Thu Aug 9 18:49:55 UTC 2012

Having looked at this and made something for my own box, and in talking to
others about it, I have come up with a sketch of what I think is needed
and I have implemented it on one of my machines.

The idea of changing operating mode on the fly is an added feature. Most
users of "modern" PCs should not need this. It is for those who have HW
issues (like me) or are picky and want the quietest (meaning fewest
unneeded services running) machine they can get.

I see a need to break this into two parts. A command line part and a gui
part. The reason for this is that part of the Ubuntu idea is to have good
out of the box experience. This varies for different people. Changing
modes is one more thing to do. With a cli version the changing of modes
can be done by qjackctl when jack starts or by a session manager. It then
becomes one more thing that the user doesn't have to worry about. However,
there are some people who want a button to push so that they can know when
the mode is changed.

So, the GUI: This can be as easy or hard as we want. In my case I set it
up as a systray icon using alltray and a short tk/tcl script. The tcl
script when called, finds out what mode we are in right now and runs
alltray with an icon unique to the mode running and exits. Alltray when
started displays the icon in the systray and when clicked shows a minimenu
that gives a choice of modes. If a mode is selected, the mode is set and a
new instance of alltray is called with the new icon for the mode and
alltray exits to make room for it. From the user's POV, the old icon
vanishes and the new one then shows up.

Currently I have set up 4 of them: Off, Audio, Graphics and Video. I have
heard from some users that there are some settings that would benefit
graphics/video (CPU scaling for one) the biggest gain is in audio though.
In my case graphics/video doesn't do anything right now, they are the same
as "OFF" (or normal if you like). I have not lumped a tweak editor in with
it though it would be easy to add a menu option to launch the editor.
There is already work happening on a controls application to adjust what
tweaks/settings are used. It would be the best settings editor for these

I have not looked at or started with a configuration/settings editor, it
is under a separate blueprint item.

The CLI part is quite simple too. This is where we get into how changing
modes works. Most thing we want to change are system side things and
require root access. There are two things we don't want. We don't want to
make a general script require no password, and we do want the user not to
have to put a password in just to change modes. So we need a layer in
between. It turns out there already is a method of doing this. We use it
all the time when we reboot or shutdown. It is called run levels and was
designed to change system modes. Normally we run in RL 2. There are
normally 7 run levels (0 to 6) 0 is used for halt, 1 is used for
"safe"/repair mode, 6 is reboot and 2 is what we use all the time. RL 3 to
5 are not normally used. Init can use other RL besides 0 to 6, but
upstart, systemd and other init replacements may not. So we are best to
use RL 3-5. These used to be used when memory was small and X was slow so
that run level 2 the main level was command line and run level 3 was an X
session. Anyway, I have been using RL 3 as audio, RL 4 for graphics and RL
5 for Video.

I could call telinit directly, but there are two things that telinit can
do that should not be done without passwording. Reload init's config and
reload init itself. The second is dangerous as it reloads upstart which
doesn't deal with that very well... it can no longer see what is running
and has problems shutting down. So I made a small app that calls telinit
with only rl 2 - 5. It still has to run as root. So it has to be called
with policy kit (the same thing that calls shutdown). Then there is the
scripts in either /etc/init.d or /etc/init. I have been using upstart
scripts, but there is the possibility that some where down the road we end
up with systemd. Both support init.d scripts. Anyway, these can set cpu
throttling, turn off cron and friends (no checking for new software
thanks) the print server, netmananger, mysql server.. etc. It can
load/unload kernel modules if needed too. Even change priority of the irq
handlers if needed. Pulse can be turned off (but not on) too.

(this is taking more time to explain than it took to do)

There are some things that need to be done user side (like turning pulse
back on or playing with pulse's modules) So there should be a script that
gets run in userland. It would need to be setup similar to the inti.d
script where the script for each mode gets run both to start and stop the

I know, it sounds complex. It could be done simpler, but I think this is
the least intrusive method as it plays with the system as it was designed
to be. It is interesting to watch... there is mostly nothing to see. It is
all a non-event... the only sign is if net manager is removed the net goes
away. The fan may come on as the cpu goes full speed. The only problem I
can foresee is that something started by cron may continue running till
complete. (upgrade scan for example)

Anyone see holes in this?

Len Ovens

More information about the Ubuntu-Studio-devel mailing list