https://wiki.archlinux.org/api.php?action=feedcontributions&user=Lloeki&feedformat=atomArchWiki - User contributions [en]2024-03-29T10:40:26ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=GNOME&diff=322931GNOME2014-07-03T10:56:35Z<p>Lloeki: client-side decorations settings and a few details</p>
<hr />
<div>[[Category:GNOME]]<br />
[[cs:GNOME]]<br />
[[de:GNOME]]<br />
[[es:GNOME]]<br />
[[fr:GNOME]]<br />
[[it:GNOME]]<br />
[[ja:GNOME]]<br />
[[nl:GNOME]]<br />
[[pl:GNOME]]<br />
[[pt:GNOME]]<br />
[[ru:GNOME]]<br />
[[sr:GNOME]]<br />
[[th:GNOME]]<br />
[[tr:Gnome Masaüstü Ortamı]]<br />
[[uk:GNOME]]<br />
[[zh-CN:GNOME]]<br />
[[zh-TW:GNOME]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Display manager}}<br />
{{Related|Window manager}}<br />
{{Related|GTK+}}<br />
{{Related|GDM}}<br />
{{Related|Nautilus}}<br />
{{Related|Gedit}}<br />
{{Related|GNOME Web}}<br />
{{Related|GNOME Flashback}}<br />
{{Related articles end}}<br />
<br />
[http://www.gnome.org/ GNOME] is a [[desktop environment]] developed by The GNOME Project.<br />
<br />
GNOME 3 has ''two'' sessions:<br />
<br />
*'''GNOME''' is the default, innovative layout.<br />
*'''GNOME Classic''' is a traditional desktop layout, similar to the GNOME 2 user interface whilst using GNOME 3 technologies. It does so through the use of pre-activated extensions and parameters (see [http://worldofgnome.org/welcome-to-gnome-3-8-flintstones-mode/ here] for a list). Hence it is more of a customized GNOME Shell than a truly distinct mode.<br />
<br />
Both of them use GNOME Shell, a desktop shell and plugin of the Mutter window manager. Mutter acts as a composite manager for the desktop, employing hardware graphics acceleration to provide effects aimed at reducing screen clutter. GNOME session manager automatically detects if your video driver is capable of running GNOME Shell and if not, falls back to software rendering using llvmpipe.<br />
<br />
== Installation ==<br />
<br />
GNOME 3 is available in the [[official repositories]] and can be [[pacman|installed]] with one of the following:<br />
*The {{Pkg|gnome-shell}} package provides a minimal desktop shell.<br />
*The {{Grp|gnome}} group contains the core desktop environment and applications required for the standard GNOME experience.<br />
*The {{Grp|gnome-extra}} group contains various optional tools such as an editor, an archive manager, a disk burner, a mail client, games, development tools and other non-critical applications that integrate well with the GNOME desktop. Installing just the {{Grp|gnome-extra}} group will not pull in the whole {{Grp|gnome}} group via dependencies. If you want to install all GNOME packages then you will need to explicitly install both groups.<br />
<br />
== Starting GNOME ==<br />
<br />
'''Graphical log-in'''<br />
<br />
For the best desktop integration, [[GDM]] (the GNOME [[Display manager]]) is recommended. GDM is installed as part of the {{grp|gnome}} group and can be used by enabling {{ic|gdm.service}} [[systemd#Using units|using systemd]].<br />
<br />
Other display managers can be used in place of GDM if desired.<br />
<br />
{{note|Native support for screenlocking in GNOME is provided by GDM. If you choose to not use GDM you will need to use a different screenlocking program such as [[XScreenSaver]].}} <br />
<br />
'''Starting GNOME manually'''<br />
<br />
If you prefer to start GNOME manually from the console, add the following line to your {{ic|~/.xinitrc}} file:<br />
{{hc|~/.xinitrc|<nowiki><br />
exec gnome-session<br />
</nowiki>}}<br />
<br />
Or {{ic|exec env GNOME_SHELL_SESSION_MODE&#61;classic gnome-session --session gnome-classic}} for GNOME Classic. After editing your {{ic|~/.xinitrc}}, GNOME can be launched by typing {{ic|startx}}.<br />
<br />
See [[xinitrc]] for details, such as preserving the logind session.<br />
<br />
After setting up your {{ic|~/.xinitrc}} file you can also arrange to [[Start X at Login]] so that you don't have to run {{ic|startx}} manually.<br />
<br />
== Using the shell ==<br />
<br />
=== GNOME Cheat Sheet ===<br />
<br />
The [https://wiki.gnome.org/Projects/GnomeShell/CheatSheet GNOME Shell Cheat Sheet] on the GNOME Wiki explains task switching, keyboard use, window control, the panel, overview mode, and more.<br />
<br />
=== Restarting the shell ===<br />
<br />
After appearance tweaks you are often asked to restart the GNOME shell. You could log out and log back in, but it is simpler and faster to issue the following keyboard command. Restart the shell by pressing {{ic|Alt}} + {{ic|F2}} then {{ic|r}} then {{ic|Enter}}<br />
<br />
=== Shell crashes ===<br />
<br />
Certain tweaks and/or repeated shell restarts may cause the shell to crash when a restart is attempted. In this case, you are informed about the crash and then forced to log out. Some shell changes cannot be accomplished via a keyboard restart; you must log out and log back in to effect them.<br />
<br />
{{note|Valuable documents should be saved (and perhaps closed) before attempting a shell restart. It is not strictly necessary; open windows and documents usually remain intact after a shell restart however there is a risk that data could be lost if documents are not saved.}}<br />
<br />
=== Shell freezes ===<br />
<br />
Sometimes shell extensions freeze the GNOME Shell. In this case a possible strategy is to switch to another terminal via {{ic|Ctrl+Alt+F2}} through {{ic|Ctrl+Alt+F6}}, log in, and restart gnome-shell with:<br />
<br />
# pkill -HUP gnome-shell<br />
<br />
All open applications will still be available after restarting the shell.<br />
<br />
Sometimes, however, merely restarting the shell might not be enough. Then you will have to restart X, losing all work in progress. You can restart X by:<br />
<br />
# pkill X<br />
<br />
The GNOME Shell then restarts automatically.<br />
<br />
If this does not work, you can try to restart your login manager. For instance, if you use GDM, try:<br />
<br />
# systemctl restart gdm.service<br />
<br />
{{Tip|You can also use '''htop''' in tty; press ''t'', select the ''gnome-shell'' tree, press ''k'' and send ''SIGKILL''.}}<br />
<br />
== Pacman integration: GNOME PackageKit ==<br />
{{Warning|1=As of Gnome 3.12 the pacman integration with packagekit is very outdated. See [https://bbs.archlinux.org/viewtopic.php?pid=1334848#p1334848 this forum thread] and [http://worldofgnome.org/gnome-software-on-arch/ this article] for more information.}}<br />
<br />
GNOME has its own Pacman GUI: {{Pkg|gnome-packagekit}}.<br />
<br />
Using the [https://www.archlinux.org/pacman/libalpm.3.html alpm] backend, it supports the following features:<br />
<br />
* Install and remove packages from the repos.<br />
* Periodically refresh package databases and prompt for updates.<br />
* Install packages from tarballs.<br />
* Search for packages by name, description, category or file.<br />
* Show package dependencies, files and reverse dependencies.<br />
* Ignore IgnorePkgs and hold HoldPkgs.<br />
* Report optional dependencies, .pacnew files, etc.<br />
<br />
You can change the {{ic|remove}} operation from -Rc to -Rsc by setting the DConf key {{ic|org.gnome.packagekit.enable-autoremove}}.<br />
<br />
=== Packages updates notifications ===<br />
<br />
If you want GNOME to check automatically for updates, you must install {{AUR|gnome-settings-daemon-updates}} from the official repository.<br />
<br />
== Customizing GNOME appearance ==<br />
<br />
The ''Systems Settings'' tool (provided by {{pkg|gnome-control-center}}) is a simple and streamlined panel which covers most basic settings. <br />
<br />
More elaborate graphical customization (such as modifying fonts, themes, titlebar buttons and such) can be done using the graphical ''GNOME tweak tool''. {{Pkg|gnome-tweak-tool}} is available from the [[official repositories]]. See [[#Theming]] below for more information about the subject.<br />
<br />
More extensive customisation may require more low-level configuration, using [[#gsettings and dconf]].<br />
<br />
==== Theming ====<br />
<br />
To install a new theme or icon set, put it in {{ic|~/.local/share/themes}} or {{ic|~/.local/share/icons}}. You can then activate it using ''GNOME tweak tool'', that is described above.<br />
<br />
Alternatively, you can set a GTK (icon) theme via {{ic|~/.config/gtk-3.0/settings.ini}}. In this file you can set the GTK theme ({{ic|gtk-theme-name}}), the icon theme ({{ic|gtk-icon-theme-name}}), the font ({{ic|gtk-font-name}}) and more.<br />
<br />
''Adwaita,'' the default GNOME 3 theme, is a part of {{pkg|gnome-themes-standard}}. Additional GTK3 themes can be found at [http://browse.deviantart.com/customization/skins/linuxutil/desktopenv/gnome/gtk3/ Deviantart web site]. For example:<br />
{{hc|~/gtk-3.0/settings.ini|<nowiki><br />
[Settings]<br />
gtk-theme-name = Adwaita<br />
# next option is applicable only if selected theme supports it<br />
gtk-application-prefer-dark-theme = true<br />
# set font name and dimension<br />
gtk-font-name = Sans 10<br />
</nowiki>}}<br />
<br />
It is necessary to restart the GNOME shell for settings to be applied. More GTK options are found at [http://developer.gnome.org/gtk3/3.0/GtkSettings.html#GtkSettings.properties GNOME developer documentation].<br />
<br />
==== gsettings and dconf ====<br />
<br />
dconf is a data store used by GNOME to store its settings. It can be edited with the graphical {{ic|dconf-editor}} or the command line {{ic|gsettings}} tool. See [http://blog.fpmurphy.com/2011/03/customizing-the-gnome-3-shell.html Customizing the GNOME Shell] for a tutorial on using gsettings.<br />
<br />
=== Customize top bar ===<br />
<br />
==== Show date in top bar ====<br />
<br />
By default GNOME displays only the weekday and time in the top bar. This can be changed with the following command. Changes take effect immediately. <br />
<br />
# gsettings set org.gnome.desktop.interface clock-show-date true<br />
<br />
==== Hiding icons in the top bar ====<br />
<br />
When installing GNOME, some unwanted icons might appear in the panel. These icons can be removed by manually editing the GNOME panel script.<br />
<br />
For example, to remove the keyboard button, comment out the {{ic|'keyboard'}} line in {{ic|PANEL_ITEM_IMPLEMENTATIONS}}:<br />
<br />
{{hc|/usr/share/gnome-shell/js/ui/panel.js|<nowiki><br />
const PANEL_ITEM_IMPLEMENTATIONS = {<br />
'activities': ActivitiesButton,<br />
'aggregateMenu': AggregateMenu,<br />
'appMenu': AppMenuButton,<br />
'dateMenu': imports.ui.dateMenu.DateMenuButton,<br />
'a11y': imports.ui.status.accessibility.ATIndicator,<br />
'a11yGreeter': imports.ui.status.accessibility.ATGreeterIndicator,<br />
//'keyboard': imports.ui.status.keyboard.InputSourceIndicator,<br />
};<br />
</nowiki>}}<br />
<br />
Then, save your results and restart the shell:<br />
<br />
#{{ic|Alt+F2}}<br />
#{{ic|r}}<br />
#{{ic|Enter}}<br />
<br />
==== Eliminate delay when logging out ====<br />
<br />
The following tweak removes the confirmation dialog and sixty second delay for logging out.<br />
<br />
This dialog normally appears when you log out with the status menu. This tweak affects the '''''Power Off''''' dialog as well. This is not a system-wide change; it affects only the user who enters this command. The change takes effect immediately after entering the command:<br />
<br />
$ gsettings set org.gnome.SessionManager logout-prompt 'false'<br />
<br />
==== Show system monitor ====<br />
<br />
The [https://extensions.gnome.org/extension/120/system-monitor/ system-monitor] extension is included in the {{pkg|gnome-shell-extensions}} package. The git version is available as {{AUR|gnome-shell-system-monitor-applet-git}} in the [[AUR]].<br />
<br />
==== Show weather information ====<br />
<br />
The [https://extensions.gnome.org/extension/613/weather/ Weather] extension can be installed from [https://extensions.gnome.org/extension/613/weather/ the official extension website]. The git version is available as {{AUR|gnome-shell-extension-weather-git}} in the [[AUR]].<br />
<br />
=== Activity view ===<br />
<br />
==== Remove entries from Applications view ====<br />
<br />
Like most desktop environments, GNOME uses .desktop files to populate its Applications view. These text files are located in the '''{{ic|/usr/share/applications}}''' folder. It is not possible to edit these files from a folder view ‒ Nautilus does not treat their icons as text files. Use a terminal to display or edit .desktop file entries. You will need root privileges to edit the .desktop files.<br />
<br />
# ls /usr/share/applications<br />
# nano /usr/share/applications/foo.desktop<br />
<br />
For system wide changes, edit files in '''{{ic|/usr/share/applications}}'''. For local changes, make a copy of ''foo.desktop'' in your home folder.<br />
<br />
$ cp /usr/share/applications/foo.desktop ~/.local/share/applications/<br />
<br />
Edit .desktop files to fit your wishes. <br />
<br />
{{Note|Removing a .desktop file does not uninstall an application, but instead removes its desktop integration: MIME types, shortcuts, and so forth.}}<br />
<br />
To hide an application launcher open its .desktop file in a text editor and add the following line:<br />
<br />
NoDisplay=true<br />
<br />
==== Sort applications into folders ====<br />
<br />
Gnome 3.12 allows the user to sort applications into folders. A GUI for this is provided by Gnome Software, which Arch does not package (due to PackageKit incompatibilities). However, applications can still be sorted into folders manually via dconf. To add a folder, navigate via dconf to '''{{ic|org.gnome.desktop.app-folders}}''' and set the value of '''{{ic|folder-children}}''' to an array of comma separated folder names:<br />
<br />
['Utilities', 'Sundry']<br />
<br />
To add applications to these folders, use '''{{ic|gsettings}}''':<br />
<br />
gsettings set org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Sundry/ apps "['alacarte.desktop', 'dconf-editor.desktop']"<br />
<br />
This adds the applications corresponding to '''{{ic|alacarte.desktop}}''' and '''{{ic|dconf-editor.desktop}}'''' to the Sundry folder.<br />
<br />
This will also create the folder '''{{ic|org.gnome.desktop.app-folders.folders.Sundry}}'''. The constituents of the folder can be updated from dconf or from '''{{ic|gsettings}}''', by appending applications to the list.<br />
<br />
To name the folder (if it has no name it will simply appear at the top of the applications), set the name key via '''{{ic|gsettings}}''':<br />
<br />
gsettings set org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Sundry/ name "Sundry"<br />
<br />
Applications can also be sorted by their category (specified in their '''{{ic|.desktop}}''' file):<br />
<br />
gsettings set org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Sundry/ categories "['Office']"<br />
<br />
If certain applications matching a category are not wanted in a certain folder, exclusions can be set:<br />
<br />
gsettings set org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Sundry/ excluded-apps "['libreoffice-draw.desktop']"<br />
<br />
For further information, refer to the [https://git.gnome.org/browse/gsettings-desktop-schemas/tree/schemas/org.gnome.desktop.app-folders.gschema.xml.in.in app-folders schema].<br />
<br />
==== Change icon size ====<br />
<br />
===== For applications in activity view =====<br />
<br />
To change the application icon size it is necessary to edit the GNOME-Shell theme.<br />
<br />
You can edit system files directly (make a backup first) or copy theme files to your local folder and edit these files. <br />
* For the '''default''' theme, edit '''{{ic|/usr/share/gnome-shell/theme/gnome-shell.css}}'''<br />
<br />
* For '''user themes''', edit '''{{ic|/usr/share/themes/<UserTheme>/gnome-shell/gnome-shell.css}}'''<br />
<br />
Edit ''gnome-shell.css'' and replace the following values. Afterward, [[#Restarting the shell|restart the GNOME shell]].<br />
<br />
{{hc|gnome-shell.css|<nowiki><br />
...<br />
/* Application Launchers and Grid */<br />
<br />
.icon-grid {<br />
spacing: 18px;<br />
-shell-grid-horizontal-item-size: 82px;<br />
-shell-grid-vertical-item-size: 82px;<br />
}<br />
<br />
.icon-grid .overview-icon {<br />
icon-size: 48px;<br />
}<br />
...<br />
</nowiki>}}<br />
<br />
===== In dash =====<br />
<br />
GNOME's Activities view has a dash on the left hand side, the size of the icons in this dash will scale depending on the amount of icons set to display. The scaling can be manipulated or set to a constant icon size. To do so, edit {{ic|/usr/share/gnome-shell/js/ui/dash.js}}.<br />
<br />
{{hc|dash.js|<nowiki><br />
...<br />
<br />
let iconSizes = [ 16, 22, 24, 32, 48, 64 ];<br />
<br />
...<br />
</nowiki>}}<br />
<br />
===== For switcher (alt-tab) =====<br />
<br />
GNOME comes with a built in task switcher, the size of the icons in this task switcher will scale depending on the amount of icons set to display. The scaling can be manipulated or set to a constant icon size. To do so, edit {{ic|/usr/share/gnome-shell/js/ui/altTab.js}}<br />
<br />
{{hc|altTab.js|<nowiki><br />
...<br />
<br />
const iconSizes = [96, 64, 48, 32, 22];<br />
<br />
...<br />
</nowiki>}}<br />
<br />
===== For system tray =====<br />
<br />
GNOME comes with a built in system tray, visible when the mouse is hovered over the bottom right corner of the screen. The size of the icons in this tray is set to a fixed value of 24. To change this value, edit {{ic|/usr/share/gnome-shell/js/ui/messageTray.js}}<br />
{{hc|messageTray.js|<nowiki><br />
...<br />
<br />
ICON_SIZE: 24,<br />
<br />
...<br />
</nowiki>}}<br />
<br />
==== Disable hot corner hovering ====<br />
<br />
===== Activity view =====<br />
<br />
To disable automatic activity view when the hot corner is hovered, edit {{ic|/usr/share/gnome-shell/js/ui/layout.js}} (that was ''panel.js'' in GNOME 3.0.x) :<br />
{{hc|layout.js|<nowiki><br />
this._corner = new Clutter.Rectangle({ name: 'hot-corner',<br />
width: 1,<br />
height: 1,<br />
opacity: 0,<br />
reactive: true });icon-size: 48px;<br />
}<br />
</nowiki>}}<br />
and set {{ic|reactive}} to {{ic|false}}. GNOME Shell needs to be restarted.<br />
<br />
{{tip|There are also [[GNOME#GNOME_shell_extensions|GNOME Shell extensions]] that can be installed which will modify this behaviour.}}<br />
<br />
===== Message Tray =====<br />
<br />
The message tray is shown when the mouse hovers at the bottom of the screen for one second. To disable this behavior, comment out the following line in {{ic|/usr/share/gnome-shell/js/ui/messageTray.js}}:<br />
{{hc|messageTray.js|<nowiki><br />
//pointerWatcher.addWatch(TRAY_DWELL_CHECK_INTERVAL, Lang.bind(this, this._checkTrayDwell));<br />
</nowiki>}}<br />
GNOME Shell needs to be restarted. The message tray is still visible in activity view.<br />
<br />
=== Titlebar ===<br />
<br />
==== Reduce title bar height ====<br />
<br />
* ''' global''' - edit {{ic|/usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml}}, search for {{ic|title_vertical_pad}} and reduce its value to a minimum of {{ic|0}}.<br />
* '''user-only''' - copy {{ic|/usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml}} to {{ic|/home/$USER/.local/share/themes/Adwaita/metacity-1/metacity-theme-3.xml}}, search for {{ic|title_vertical_pad}} and reduce its value to a minimum of {{ic|0}}.<br />
<br />
Then restart the GNOME shell. <br />
<br />
To restore the original values, [[pacman|install]] the package {{Pkg|gnome-themes-standard}} from the [[official repositories]] or remove {{ic|/home/$USER/.local/share/themes/Adwaita/metacity-1/metacity-theme-3.xml}}.<br />
<br />
==== Reorder titlebar buttons ====<br />
<br />
At present this setting can be changed through '''dconf-editor.'''<br />
<br />
For example, to move the close and minimize buttons to the left side of the titlebar, open '''dconf-editor''' and locate the '''''org.gnome.shell.overrides.button_layout''''' key. Change its value to '''{{ic|close,minimize:}}''' (colon symbol designates the spacer between left side and right side of the titlebar). Place the buttons in your preferred order. You cannot use a button more than once. Also, keep in mind that certain buttons are deprecated.<br />
<br />
For a more complete experience, one might need to set more values:<br />
<br />
<pre><br />
gsettings set org.gnome.desktop.wm.preferences button-layout 'close,minimize,maximize:'<br />
gsettings set org.gnome.shell.overrides button-layout 'close,minimize,maximize:'<br />
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "{'Gtk/DecorationLayout': <'close,minimize,maximize:'>}"<br />
</pre><br />
<br />
The first entry sets the order for the Gnome window manager. The second entry sets the order for the Gnome window manager when used together with Gnome Shell (the latter uses this key, which defaults to ':close', to override the previous non-Shell setting). The last one sets the order for '''client-side decorations'''[http://blogs.gnome.org/mclasen/2014/01/13/client-side-decorations-continued/]", a recent GTK feature allowing an application window to paint its own decorations in a more standard manner.<br />
<br />
The settings should apply on the fly.<br />
<br />
==== Hide titlebar when maximized ====<br />
The command below will hide the titlebar when windows are maximised:<br />
<br />
# sed -i -r 's|(<frame_geometry name="max")|\1 has_title="false"|' /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml<br />
<br />
After entering the command restart the GNOME shell. After this tweak, you may find it difficult to un-maximize a window when there is no titlebar to grab.<br />
<br />
With suitable keybindings, you should be able to use {{ic|Alt+F5}}, {{ic|Alt+F10}} or {{ic|Alt+Space}} to remedy the situation.<br />
<br />
To prevent {{ic|metacity-theme-3.xml}} from being overwritten each time package {{pkg|gnome-themes-standard}} is upgraded, add its name to {{ic|/etc/pacman.conf}} with {{ic|NoUpgrade}}:<br />
<br />
{{hc|/etc/pacman.conf|<nowiki>... previous lines ...<br />
<br />
# Pacman will not upgrade packages listed in IgnorePkg and members of IgnoreGroup<br />
# IgnorePkg =<br />
# IgnoreGroup =<br />
<br />
NoUpgrade = usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml # Do not add a leading slash to the path<br />
<br />
... more lines ...</nowiki>}}<br />
<br />
To restore original Adwaita theme values, install the {{pkg|gnome-themes-standard}} package.<br />
<br />
== Miscellaneous settings ==<br />
<br />
=== Power Management ===<br />
<br />
==== Turn off Suspend-To-RAM (S3) when closing the LID ====<br />
This setting is not available in GNOME, ''gnome-control-center'' and ''dconf'' make this available. The current approach is to manage this on the level of [[systemd]]. Edit {{ic|/etc/systemd/logind.conf}}, uncomment the {{ic|HandleLidSwitch}} line and set it to {{ic|ignore}}:<br />
<br />
{{hc|/etc/systemd/logind.conf|HandleLidSwitch&#61;ignore}}<br />
<br />
See the [[Power management#ACPI_events]] article for more information.<br />
<br />
==== No reaction on lid close ====<br />
<br />
When configuring the lid close events via [[Power management#ACPI_events]], the settings may seem to have no effect. If you have an external monitor connected to your laptop, this is default GNOME behaviour. Disconnect the monitor and the settings should work, otherwise your {{ic|/etc/systemd/logind.conf}} may be incorrect.<br />
To change default behaviour open the {{ic|dconf-editor}} and change {{ic|org.gnome.settings-daemon.plugins.xrandr.default-monitors-setup}} to {{ic|"do-nothing"}}.<br />
<br />
==== Change Critical Battery Level Action (for Laptops) ====<br />
<br />
The ''System Settings'' panel only allows the user to choose between ''Suspend'' or ''Hibernate''. To choose another option such as ''Do Nothing'' open the {{ic|dconf-editor}} and navigate to {{ic|org.gnome.settings-daemon.plugins.power}}. Edit the {{ic|"critical-battery-action"}} value to {{ic|"nothing"}}.<br />
<br />
=== Switch back scrolling behavior ===<br />
If you do not like the new scrollbar behavior just put {{ic|<nowiki>gtk-primary-button-warps-slider = false</nowiki>}} under the {{ic|<nowiki>[Settings]</nowiki>}} section in {{ic|~/.config/gtk-3.0/settings.ini}}:<br />
<br />
{{hc|~/.config/gtk-3.0/settings.ini|<nowiki><br />
[Settings]<br />
gtk-primary-button-warps-slider = false<br />
...<br />
</nowiki>}}<br />
<br />
=== Autostarting / Automatic program launch upon logging in ===<br />
<br />
As of Gnome 3.12 ''gnome-session-properties'' is deprecated. Specify which programs must start automatically after logging in using ''gnome-tweak-tool'' or via the manual method described [http://linuxandfriends.com/how-to-add-startup-programs-in-gnome-3/ here].<br />
<br />
{{Tip|Some users are unable to add autostart applications when {{ic|gnome-tweak-tool}} is launched from Gnome's overview. Launching it from a terminal sometimes fixes this. This issue can also be resolved by making changes described in this [https://bbs.archlinux.org/viewtopic.php?pid&#61;1414443#p1414443 post]. But users will still be unable to add any custom autostart programs such as scripts. <br> {{AUR|gnome-session-properties}} is still available in the [[AUR]].}}<br />
<br />
=== Editing applications menu ===<br />
<br />
{{pkg|alacarte}} provides a more complete menu editor for adding/editing menu entries.<br />
<br />
=== Gnome Terminal ===<br />
<br />
==== Inner padding ====<br />
<br />
To move the terminal output away from the window borders create the stylesheet {{ic|~/.config/gtk-3.0/gtk.css}} with the following setting:<br />
<br />
TerminalScreen {<br />
-VteTerminal-inner-border: 10px 10px 10px 10px;<br />
}<br />
<br />
==== Disable blinking cursor ====<br />
<br />
Since Gnome 3.8 and the migration to gsettings and dconf the key required to modify in order to disable the blinking cursor in the Terminal differs slightly in contrast to the old gconf key. To disable the blinking cursor in Gnome 3.8 use:<br />
<br />
gsettings set org.gnome.desktop.interface cursor-blink false<br />
<br />
If you prefer dconf to the gsettings CLI then open {{ic|dconf-editor}}, go to org -> gnome -> desktop -> interface and untick the option labelled '''cursor-blink'''.<br />
<br />
To disable the blinking cursor in Terminal only use (make sure profile uid is correct one):<br />
<br />
dconf write /org/gnome/terminal/legacy/profiles:/:b1dcc9dd-5262-4d8d-a863-c897e6d979b9/cursor-blink-mode "'off'"<br />
<br />
==== Make new tabs inherit current directory (for Gnome Terminal 3.8+) ====<br />
<br />
In Gnome 3.8, the behaviour of how current directories are tracked has changed. To restore this behaviour, you need to source the {{ic|/etc/profile.d/vte.sh}} file, put this in your {{ic|~/.bashrc}} or {{ic|~/.zshrc}} for zsh users:<br />
<br />
source /etc/profile.d/vte.sh<br />
<br />
For more information refer to the [https://wiki.gnome.org/action/show/Apps/Terminal/FAQ?action=show&redirect=Terminal%252FFAQ#How_can_I_make_new_terminals_start_in_the_working_directory_of_the_current_terminal.3F Gnome wiki].<br />
<br />
=== Move dialog windows ===<br />
The default configuration for dialogs will not allow you to move them which causes problems in some cases. To change this you will need to use gconf-editor and change this setting:<br />
<br />
/desktop/gnome/shell/windows/attach_modal_dialogs<br />
<br />
After the change you will need to restart the shell for it to take affect.<br />
<br />
=== GNOME shell extensions ===<br />
<br />
GNOME Shell can be customized with extensions. These provide features such as a dock or a widget for changing the theme.<br />
<br />
Many extensions are collected and hosted by [https://extensions.gnome.org/ extensions.gnome.org]. They can be browsed and installed simply activating them in the browser. More information about gnome shell extensions can be found [https://extensions.gnome.org/about/ here].<br />
<br />
See [[#When an extension breaks GNOME|when an extension breaks GNOME]] for troubleshooting information.<br />
<br />
=== Default Applications ===<br />
<br />
While one can right click any file and set the default applications in 'Preferences', the settings are actually saved in {{ic | $HOME/.local/share/applications/mimeapps.list}} and {{ic| $HOME/.local/share/applications/mimeinfo.cache}}.<br />
<br />
{{tip|If you are making the change systemwide you may to create the {{ic|/usr/share/applications/mimeapps.list}} file yourself.}}<br />
<br />
==== File browser/replace Nautilus ====<br />
<br />
You can specify a different file manager in the ''mimeapps.list'' file as shown below:<br />
<br />
'''User only''': add the line {{ic|<nowiki>inode/directory=myfilemanager.desktop</nowiki>}} to {{ic|~/.local/share/applications/mimeapps.list}}<br />
<br />
'''Systemwide''': add the line {{ic|<nowiki>inode/directory=myfilemanager.desktop</nowiki>}} to {{ic|/usr/share/applications/mimeapps.list}}<br />
<br />
Where my filemanager.desktop is the correct .desktop file for the file manager of your choice.<br />
<br />
Alternatively you can trick GNOME into using another file browser by editing the {{ic|Exec}} line in {{ic|/usr/share/applications/nautilus.desktop}}. See the correct parameters in the {{ic|.desktop}} file of the file manager of your choice, e.g.:<br />
<br />
{{hc|/usr/share/applications/nautilus.desktop|<br />
2=[...]<br />
Exec=thunar %F<br />
OR<br />
Exec=pcmanfm %U<br />
OR<br />
Exec=nemo %U<br />
[...]<br />
}}<br />
<br />
==== PDF viewer ====<br />
<br />
In some cases when you have installed Inkscape or other graphic programs Evince Document Viewer might no longer be selected as the default PDF application. If it is not available in the '''Open With''' entry which would be the GUI solution, you can use the following user command to make it the default application again:<br />
<br />
xdg-mime default evince.desktop application/pdf<br />
<br />
==== Terminal ====<br />
<br />
{{ic|gsettings}} (which replaces {{ic|gconftool-2}}) is used to set the default terminal. The setting affects ''nautilus-open-terminal'' (a Nautilus extension).<br />
To make [[rxvt-unicode|urxvt]] the default, run:<br />
<br />
gsettings set org.gnome.desktop.default-applications.terminal exec urxvtc<br />
gsettings set org.gnome.desktop.default-applications.terminal exec-arg "'-e'"<br />
<br />
{{Note|The {{ic|-e}} flag is for executing a command. When ''nautilus-open-terminal'' invokes {{ic|urxvtc}}, it puts a {{ic|cd}} command at the end of the command line so that the new terminal starts in the directory you opened it from. Other terminals will require a different (perhaps empty) {{ic|exec-arg}}.}}<br />
<br />
=== Middle mouse button ===<br />
<br />
By default, GNOME 3 disables middle mouse button emulation regardless of [[Xorg]] settings ('''Emulate3Buttons'''). To enable middle mouse button emulation use:<br />
<br />
$ gsettings set org.gnome.settings-daemon.peripherals.mouse middle-button-enabled true<br />
<br />
=== Display dimming ===<br />
<br />
By default GNOME 3 has a ten second idle timeout to dim the screen regardless of the battery and AC state:<br />
<br />
# gsettings get org.gnome.settings-daemon.plugins.power idle-dim-time<br />
<br />
To set a new value type the following<br />
<br />
# gsettings set org.gnome.settings-daemon.plugins.power idle-dim-time <int><br />
<br />
where <int> is the value in seconds.<br />
<br />
=== Changing hotkeys ===<br />
Certain hotkeys cannot be changed directly via the ''System Settings'' panel. In order to change these keys, use dconf-editor. An example of particular note is the hotkey Alt-Above_Tab. On US keyboards, this is Alt-`: is a hotkey often used in the [[Emacs]] editor. It can be changed by opening dconf-editor and modifying the ''switch-group'' key found in {{ic|org.gnome.desktop.wm.keybindings}}.<br />
<br />
It is possible to manually change the keys via an application's so-called accel map file. Where it is to be found is up to the application: For instance, Thunar's is at ~/.config/Thunar/accels.scm, whereas Nautilus's is located at ~/.config/nautilus/accels and ~/.gnome2/accels/nautilus on old release.<br />
<br />
The file should contain a list of possible hotkeys, each unchanged line commented out with a leading ";" that has to be removed for a change to become active.<br />
For example to replace the hotkey used by Nautilus to move files to the trash folder, change the line:<br />
<br />
; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")<br />
to this:<br />
<br />
(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")<br />
<br />
The file is regenerated regularly so do not comment the file. The uncommented line will stay but every comment you add will be lost.<br />
<br />
==== Hotkeys in Nautilus 3.4 and older ====<br />
Firstly, use '''dconf-editor''' to place a checkmark next to {{ic|can-change-accels}} in the key named ''org.gnome.desktop.interface.''<br />
<br />
We will replace the hotkey — a.k.a. keyboard shortcut, keyboard accelerator — used by Nautilus to move files to the trash folder.<br />
The default assignment is a somewhat-awkward {{ic|Ctrl+Delete}}.<br />
* Open Nautilus, select any file, and click '''Edit''' on the menu bar.<br />
* Hover over the ''Move to Trash'' menu item.<br />
* While hovering, press {{ic|Delete}}. The current accelerator is now unset.<br />
* Press the key that you wish to become the new keyboard accelerator.<br />
* Press {{ic|Delete}} to make the new accelerator be the Delete key.<br />
Unless you select a file or folder, ''Move to Trash'' will be grayed-out. Finally, disable {{ic|can-change-accels}} to prevent accidental hotkey changes.<br />
<br />
=== Screencast recording ===<br />
<br />
Gnome features the built-in possbility to create screencasts easily. Thereby Control+Shift+Alt+R keybinding starts and stops the recording. A red circle is displayed in the bottom right corner of the screen when the recording is in progress. After the recording is finished, a file named 'Screencast from %d%u-%c.webm' is saved in the Videos directory. In order to use the screencast feature you need to have installed the gst plugins which are:<br />
<br />
$ pacman -Qs gst<br />
<br />
=== Modify Keyboard with XkbOptions ===<br />
<br />
Using the '''dconf-editor''', navigate to the key named {{ic|org.gnome.desktop.input-sources.xkb-options}} and add desired XkbOptions (e.g. ''caps:swapescape'') to the list.<br />
<br />
See {{ic|/usr/share/X11/xkb/rules/xorg}} for all XkbOptions and {{ic|/usr/share/X11/xkb/symbols/*}} for the respective descriptions.<br />
<br />
{{Note|To enable the {{ic|Ctrl+Alt+Backspace}} combination to terminate Xorg, use the {{Pkg|gnome-tweak-tool}} from [[official repositories]]. Within the '''Tweak Tool''', navigate to ''Typing > Terminate'' and select the option {{ic|Ctrl+Alt+Backspace}} from the dropdown menu.}}<br />
<br />
=== Toggle keyboard layouts ===<br />
Since Gnome does not consider any configuration in {{ic|/etc/X11/conf.d/*.conf}} you have to set the command for layout switching either via the control center with the options ''Switch to previous source'' and ''Switch to next source'' or if you want to use Alt - Shift combination you have to use the Gnome-Tweak-Tool and set ''Typing -> Modifiers-only input sources -> select Alt-shift''. For more information see also the forum [https://bbs.archlinux.org/viewtopic.php?id=152127 thread].<br />
<br />
=== HiDPI Support (Retina Screens) ===<br />
<br />
See [[HiDPI]].<br />
<br />
=== Other tips ===<br />
See [[GNOME Tips]].<br />
<br />
== Tracker (search program) ==<br />
The {{Pkg|tracker}} provides the Tracker program, an indexing application. You can configure it with {{ic|tracker-preferences}}, and monitor status with {{ic|tracker-control}}. Once installed, indexing should start automatically when you log in. You can explicitly start indexing with {{ic|tracker-control -s}}. Search settings can also be configured in the ''System Settings'' panel.<br />
<br />
== Totem (movie player) ==<br />
<br />
Totem is a movie player based on [[GStreamer]]. For information about adding codecs or hardware acceleration, see [[GStreamer]].<br />
<br />
== Empathy (integrated messaging) and GNOME Online Accounts ==<br />
<br />
Empathy, the engine behind integrated messaging, GNOME Online Accounts, and all other system settings based on messaging accounts will not function correctly unless the {{grp|telepathy}} group of packages or at least one of the backends ({{pkg|telepathy-gabble}}, or {{pkg|telepathy-haze}}, for example) is installed.<br />
<br />
These packages are '''not''' included in either the {{grp|gnome}} or {{grp|gnome-extra}} groups . You can install the Telepathy and optionally any backends with:<br />
<br />
# pacman -S telepathy<br />
<br />
Without telepathy, Empathy will not open the account management dialog and can get stuck in this state. If this happens -- even after quitting Empathy cleanly -- the {{ic|/usr/bin/empathy-accounts}} application can remain running and will need to be killed before you can add any new accounts. Likewise, without telepathy installed, the 'Add an online account' button in GNOME Online Accounts will do nothing.<br />
<br />
View descriptions of telepathy components on the [http://telepathy.freedesktop.org/wiki/Components freedesktop.org telepathy wiki].<br />
<br />
[[Avahi]] daemon is required for connecting with the People Nearby account, and also in order for some desktop extensions to work correctly like [https://extensions.gnome.org/extension/746/chat-status/ Chat Status].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Cannot change settings in dconf-editor ===<br />
<br />
When one cannot set settings in {{pkg|dconf}}, it is possible their dconf user settings are corrupt. In this case it is best to delete the user dconf files in {{ic|~/.config/dconf/user*}} and set the settings in dconf-editor after.<br />
<br />
=== Extensions ===<br />
<br />
==== When an extension breaks GNOME ====<br />
<br />
When enabling shell extensions causes GNOME breakage, you should first remove the ''user-theme'' and ''auto-move-windows'' extensions from their installation directory.<br />
<br />
The installation directory could be one of {{ic|~/.local/share/gnome‑shell/extensions}}, {{ic|/usr/share/gnome‑shell/extensions}} or {{ic|/usr/local/share/gnome‑shell/extensions}}. Removing these two extension-containing folders may fix the breakage. Otherwise, isolate the problem extension with trial‑and‑error.<br />
<br />
Removing or adding an extension-containing folder to the aforementioned directories removes or adds the corresponding extension to your system. Details on GNOME Shell extensions are available at the [https://live.gnome.org/GnomeShell/Extensions GNOME web site.]<br />
<br />
==== Extensions do not work after GNOME 3 update ====<br />
<br />
Locate the folder where your extensions are installed. It might be {{ic|~/.local/share/gnome-shell/extensions}} or {{ic|/usr/share/gnome-shell/extensions}}.<br />
<br />
Edit each occurrence of {{ic|metadata.json}} which appears in each extension sub-folder.<br />
<br />
{| border="0"<br />
| Insert: || {{ic|"shell-version": ["3.6"]}}<br />
|-<br />
| Instead of (for example): || {{ic|"shell-version": ["3.4"]}}<br />
|}<br />
<br />
{{ic|"3.x"}} indicates the extension works with every shell version. If it breaks, you will know to change it back.<br />
<br />
==== Remove Gnome Shell Extensions ====<br />
<br />
If you have trouble with uninstalling Gnome Extensions via https://extensions.gnome.org/local/, then probably they have been installed as system-wide extensions with {{ic|pacman -S gnome-shell-extensions}} before. To remove them, you have to be careful, because the following instruction removes all extensions from other user's, too:<br />
<br />
# pacman -R gnome-shell-extensions<br />
<br />
Following that, you refresh Gnome Shell by pressing ALT+F2 and entering {{ic|restart}}.<br />
<br />
Then go to https://extensions.gnome.org/local/ again and have a look for your installed extensions list. It should have changed.<br />
<br />
All other extensions should be removable by pressing the red X icon to the right. If not, something may be broken. <br />
<br />
As a final step, you can remove them manually from {{ic|~/.local/share/gnome-shell/extensions/*}} and/or {{ic|/usr/share/gnome-shell/extensions}}. Restart Gnome Shell again and you should be fine.<br />
<br />
=== The "Windows" key ===<br />
By default, this key is mapped to the "overlay-key" to launch the Overview. You can remove this key mapping to free up your {{ic|Windows Key}} (also called {{ic|Mod4}}), which GNOME calls {{ic|Super_L}}, by utilizing {{ic|gsettings}}.<br />
<br />
Example:<br />
{{ic| gsettings set org.gnome.mutter overlay-key 'Foo';}}.<br />
You can leave out '''Foo''' to simply remove any binding to that function.<br />
<br />
{{Note| GNOME also uses {{ic|Alt+F1}} to launch the Overview.}}<br />
<br />
=== Keyboard Shortcut do not work with only conky running ===<br />
The gnome-shell keyboard shortcuts like {{ic|Alt+F2}}, {{ic|Alt+F1}}, and the media key shortcuts do not work if conky is the only program running. However if another application like gedit is running, then the keyboard shortcuts work.<br />
<br />
solution: edit .conkyrc <br />
<br />
own_window yes<br />
own_window_transparent yes<br />
own_window_argb_visual yes<br />
own_window_type dock<br />
own_window_class Conky<br />
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager<br />
<br />
=== Window opens behind other windows when using multiple monitors ===<br />
<br />
This is possibly a bug in GNOME Shell which causes new windows to open behind others.<br />
Unchecking "workspaces_only_on_primary" in desktop/gnome/shell/windows using gconf-editor solves this problem.<br />
<br />
=== Multiple monitors and dock extension ===<br />
<br />
If you have multiple monitors configured using Nvidia Twinview, the dock extension may get sandwiched in-between the monitors. You can edit the source of this extension to reposition the dock to a position of your choosing.<br />
<br />
Edit {{ic|/usr/share/gnome-shell/extensions/dock@gnome-shell-extensions.gnome.org/extension.js}} and locate this line in the source:<br />
<br />
this.actor.set_position(primary.width-this._item_size-this._spacing-2, (primary.height-height)/2);<br />
<br />
The first parameter is the X position of the dock display, by subtracting 15 pixels as opposed to 2 pixels from this it correctly positioned on my primary monitor, you can play around with any X,Y coordinate pair to position it correctly.<br />
<br />
this.actor.set_position(primary.width-this._item_size-this._spacing-15, (primary.height-height)/2);<br />
<br />
=== "Show Desktop" keyboard shortcut does not work ===<br />
<br />
GNOME developers treated the corresponding binding as bug (see https://bugzilla.gnome.org/show_bug.cgi?id=643609) due to Minimization being deprecated. To show the desktop again assign ALT+STRG+D to the following setting:<br />
<br />
System Settings --> Keyboard --> Shortcuts --> Navigation --> Hide all normal windows<br />
<br />
=== Unable to apply stored configuration for monitors ===<br />
<br />
If you encounter this message try to disable the xrandr gnome-settings-daemon plugin :<br />
<br />
$ dconf write /org/gnome/settings-daemon/plugins/xrandr/active false<br />
<br />
=== Lock button fails to re-enable touchpad ===<br />
<br />
Some laptops have a touchpad lock button that disables the touchpad so that users can type without worrying about touching the touchpad. It appears currently that although GNOME can lock the touchpad by pressing this button, it cannot unlock it. If the touchpad gets locked you can do the following to unlock it:<br />
<br />
# Start a terminal. You can do this by pressing {{ic|Alt+F2}}, then typing {{ic|gnome-terminal}} followed by pressing {{ic|Enter}}.<br />
# Type in the following command:<br />
<br />
$ xinput set-prop "SynPS/2 Synaptics TouchPad" "Device Enabled" 1<br />
<br />
=== Consistent cursor theme ===<br />
<br />
You may find that the cursor theme used in GNOME is not consistent. For example, it may change when moving the cursor across different application windows. To fix this problem, set the cursor theme by creating an {{ic|index.theme}} file which defines the cursor theme according to the XDG icon theme specification. See the following section of the [[Cursor Themes]] article: [[Cursor Themes#Using an index.theme file (recommended)]].<br />
<br />
=== Tracker & Documents do not list any local files ===<br />
<br />
In order for Tracker (and, therefore, Documents) to detect your local files, they must be stored in directories that it knows of. If your documents are contained in one of the usual XDG standard directories (i.e. "Documents" or "Music"), you should install {{Pkg|xdg-user-dirs}} and run:<br />
<br />
# xdg-user-dirs-update<br />
<br />
This will create all of the usual XDG home directories if they do not already exist and it will create the config file definining these directories that Tracker and Documents depend upon.<br />
<br />
=== Passwords are not remembered ===<br />
<br />
If you get a password prompt every time you login, and you find password are not saved, you might need to create/set a default keyring.<br />
<br />
Install {{pkg|seahorse}}. Open "Passwords and Keys" from the menu or run {{ic|seahorse}}. Select View > By Keyring. If there is no keyring in the left column (it will be marked with a lock icon), go to File > New > Password Keyring and give it a nice name. You will be asked to enter a password. If you do not give it a password it will be unlocked automatically even when using autologin, but passwords will not be stored securely. Finally, right-click on the keyring you just created and select "Set as default".<br />
<br />
=== Windows cannot be modified with Alt-Key + Mouse-Button ===<br />
<br />
Change the dconf-setting "org.gnome.desktop.wm.preferences.mouse-button-modifier" from <Super> back to <Alt>. It is not possible to change this with ''System Settings'' > "Keyboard" > "Shortcuts", you will find there only the regular keybindings. The developers of GNOME decided to change this from 3.4 to 3.6 because of this bug report https://bugzilla.gnome.org/show_bug.cgi?id=607797<br />
<br />
=== Gnome-shell 3.8.x fails to load with a black screen + cursor ===<br />
<br />
If you have a non-UTF8 language enabled, Gnome 3 can fail to load. Disable non-UTF-8 locales and perform a locale-gen until this is resolved.<br />
For more information see [https://bugzilla.gnome.org/show_bug.cgi?id=698952 this bug report].<br />
<br />
Additionally, if multiple locales of different languages are enabled, it may be necessary to disable all locales except for one (which is UTF-8).<br />
<br />
=== UI elements scale incorrectly ===<br />
<br />
Gnome introduced HDPI support in version 3.10. If your display does not provide the correct screen size through EDID, this can lead to incorrectly scaled UI elements. As a workaround you can open dconf-editor and find the key {{ic|scaling-factor}} in {{ic|org.gnome.desktop.interface}}. Set it to {{ic|1}} to get the standard scale.<br />
<br />
=== Tear-free video with Intel HD Graphics ===<br />
Enabling the [[Intel _Graphics#Tear-free_video|Xorg Intel TearFree option]] is a known workaround to tearing problems on Intel adapters, however the way this option acts makes it redundant with the use of a compositor (adds up memory consumption and lowers performance, see [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123 the original bug report's final comment]).<br />
<br />
On the other hand, GNOME Shell uses Mutter as a compositor which has a tweak known to address tearing problems (see [https://bugzilla.gnome.org/show_bug.cgi?id=657071#c1 the original suggestion for this fix] and its mention in [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c59 the Freedesktop bug report]): the line {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} must be appended to {{ic|/etc/environment}} and Xorg server restarted. This tweak solved tearing problems.<br />
<br />
=== Logging in through GDM or lightdm quickly returns to the login screen without any feedback ===<br />
As discovered by the person in [http://forums.debian.net/viewtopic.php?f=6&t=84115 this] thread, some aspect of checking for the existence of and then sourcing a bash_completion script seems to cause this issue. In addition to the bash completion setup in package {{Pkg|bash-completion}}, the Ruby Version Manager (RVM) includes the invocation of a bash completion script as part of it's init. It's worth keeping in mind that whatever causes this issue likely exists outside the exclusive realm of bash completion scripts, and that /etc/profile* is still worth poking around in while debugging even if a completion script isn't found.<br />
<br />
=== Gnome System Icons are not loaded properly ===<br />
Problems with the loading of system icons, such the ones in the title bar of Nautilus, might be solved by [[pacman#Installing specific packages|(re)installing]] the package {{Pkg|gdk-pixbuf2}}.<br />
<br />
This may also fix the "oh no" screen and/or very slow loading and login with GDM as described in [https://bbs.archlinux.org/viewtopic.php?pid=1414157 this] thread.<br />
<br />
== External links ==<br />
* [http://www.gnome.org/ The Official Website of GNOME]<br />
* [http://extensions.gnome.org/ Extensions for GNOME-shell]<br />
* Themes, icons, and backgrounds:<br />
** [http://art.gnome.org/ GNOME Art]<br />
** [http://www.gnome-look.org/ GNOME Look]<br />
* GTK/GNOME programs:<br />
** [http://www.gnomefiles.org/ GNOME Files]<br />
** [http://www.gnome.org/projects/ GNOME Project Listing]</div>Lloekihttps://wiki.archlinux.org/index.php?title=MacBookPro&diff=43695MacBookPro2008-06-26T10:33:31Z<p>Lloeki: /* Wireless */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
== Installing Archlinux on MacbookPro ==<br />
<br />
These instructions could work for the most part for the regular MacBook.<br />
<br />
You will need Archlinux 0.8 alpha3 or newer at least since GRUB and the kernel will work fine from this version.<br />
<br />
=== Arch Only System ===<br />
To install Arch and replace OSX you need to change the partition table type in MacOSX from bootcamp. Download bootcamp, install and run. Change disk from GPT to MBR partition table.<br />
<br />
Reboot, hold down the "C" key to boot from CD.<br />
<br />
Install Arch as normal. Don't forget to set one partition as bootable.<br />
<br />
After install you need to configure a couple of things...<br />
<br />
=== Dual Boot (Arch & MacOSX) ===<br />
<br />
Two possibilities:<br />
<br />
- Install Bootcamp, resize the MacOSX partition<br /><br />
<br />
When Mac OS X installation is finished. Go on http://refit.sourceforge.net[http://refit.sourceforge.net] and download rEFIT (Mac disk image)<br />
<br />
To install rEFIT, mount the rEFIT.dmg file (it's automatic normally).<br /><br />
There is an other way (refer to rEFIT documentation) but you can open a terminal then you copy /Volumes/rEFIT/efi/ to /<br /><br />
<br />
First you have to be root or you can use sudo. If you want to be logged as root you have to set a password for the root user typing :<br /><br />
sudo passwd root<br />
<br />
To be logged as root :<br /><br />
su<br />
<br />
Then to copy the folder to / :<br /><br />
cp -r /Volumes/rEFIT/efi /<br />
<br />
To install rEFIT :<br /><br />
cd /efi/refit/<br /><br />
./enable.sh<br />
<br />
Now we can synchronized MBR with GPT partition table thanks to rEFIT so you restart your computer. You can see rEFIT, you press down key to access to the Partitioning Tool. You press y to accept.<br />
<br />
Put your archlinux CD in the CD-ROM drive first then restart the computer. You can press C to boot from the CD or you can choose it in the rEFIT menu.<br />
<br />
Now it's the typical archlinux installation.<br />
<br />
At the end of the installation DO NOT install the bootloader in the MBR, but in a partition (e.g. sda3)<br />
<br />
= Configuration =<br />
<br />
== rc.conf ==<br />
Make sure your "rc.conf" at least has the following modules:<br />
MODULES=(sky2 fglrx speedstep_centrino)<br />
<br />
For CPU scaling use the "powernowd" package.<br />
<br />
== Xorg ==<br />
Install:<br />
pacman -S ati-fglrx-utils<br />
<br />
You can see my xorg.conf here:<br />
http://wiki.archlinux.org/index.php?title=MacBookPro_xorgconf<br />
<br />
OR you can just make the necessary changes: (ADD these to your xorg.conf, dont replace)<br />
<br />
Configure Xorg using xorgconfig. Once done edit your "xorg.conf" and change the driver type to "fglrx".<br />
Section "Device"<br />
Driver "fglrx"<br />
EndSection <br />
<br />
Configure your keyboard: (make right "apple key" right ALT key)<br />
Section "InputDevice"<br />
Option "XkbOptions" "lv3:rwin_switch"<br />
EndSection<br />
<br />
Configure your trackpad:<br />
Section "InputDevice"<br />
Option "Protocol" "Auto"<br />
Option "MinSpeed" "1.0"<br />
Option "MaxSpeed" "1.0"<br />
EndSection<br />
<br />
OR you may want to use this, that emulates the MacOSX behaviour:<br />
<br />
Section "InputDevice"<br />
Identifier "Synaptics Touchpad"<br />
Driver "synaptics"<br />
Option "CorePointer"<br />
Option "Device" "/dev/input/mouse1"<br />
Option "Protocol" "auto-dev"<br />
Option "LeftEdge" "60"<br />
Option "RightEdge" "900"<br />
Option "BottomEdge" "511"<br />
Option "HorizScrollDelta" "0"<br />
Option "MinSpeed" "0.4"<br />
Option "MaxSpeed" "1"<br />
Option "AccelFactor" "0.08"<br />
Option "MaxTapTime" "0"<br />
Option "TapButton1" "0"<br />
#Two Finger Scroll<br />
Option "VertTwoFingerScroll" "1"<br />
Option "HorizTwoFingerScroll" "1"<br />
EndSection<br />
<br />
<br />
<br />
Configure modules:<br />
Section "Module"<br />
Load "dbe" # Double buffer extension<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
EndSection<br />
<br />
== Wireless ==<br />
The airport card in the newest MacBook (PCI-ID 168c:0024) is not yet supported by Madwifi. In short: Madwifi does not yet have a version of the (binary-only) HAL (hardware-abstraction layer) for the new chipset and ETA is unknown. Workaround: If your kernel is 32-bit, you can use ndiswrapper in combination with the 32-bit windows driver for the [http://www.dlink.com/products/support.asp?pid=489&sec=0 D-Link DWA-645]. <br />
It's ugly, but it works. [http://ge.ubuntuforums.com/showpost.php?s=ca69b769276fb42cca3c591015993721&p=5141506&postcount=39 some ubuntu users] report it working with 64-bit too, albeit some have issues with WPA1/2.<br />
<br />
Madwifi drivers work on my second generation MBP following [http://ubuntu-tutorials.com/2007/10/24/how-to-enable-wireless-networking-on-the-macbook-ubuntu-710/ these] instructions.<br />
<br />
== Pommed ==<br />
[http://technologeek.org/projects/pommed/ Pommed] handles the hotkeys and is able to adjusts the LCD backlight, sound volume, keyboard backlight or to eject the CD-ROM drive.<br />
<br />
Pommed is in [community], there is also a GUI built on GTK (gpomme)<br />
<br />
== Suspend ==<br />
Suspend works most of the time (occasionally it dosn't wake up) with the latest version of [[pm-utils]].<br />
<br />
sudo pacman -S pm-utils<br />
<br />
Run the following to test suspension. (Pressing the power button, plugging in a usb device, or closing/opening the lid will resume.)<br />
<br />
sudo pm-suspend<br />
<br />
To suspend on closing of laptop lid, make sure you have acpi, and acpid installed with pacman, and that the acpid daemon is running. Then edit /etc/acpi/handler.sh and change the "button/lid)" section to look like the following:<br />
<br />
button/lid)<br />
#echo "LID switched!">/dev/tty5<br />
if grep -q closed /proc/acpi/button/lid/LID0/state<br />
then pm-suspend<br />
fi<br />
;;<br />
<br />
Acpid calls the button/lid) section whenever the lid is opened or closed. If pm-suspend is just added to this section, it will suspend when the lid is opened, and when the lid is closed. Causing it to wake up, and then immediately suspend again when you open the lid. Checking to see if the lid is closed with grep and only running pm-suspend when the lid is closed fixes this issue.<br />
<br />
= TODO =<br />
I WILL get around to doing these! I promise! In the mean time I just put them here to remind me to do them.<br />
<br />
- make package for refit<br />
(EDIT: refit is actually in [community])<br />
<br />
- make section for isight</div>Lloekihttps://wiki.archlinux.org/index.php?title=Hibernate-script&diff=40228Hibernate-script2008-04-25T09:06:52Z<p>Lloeki: /* Suspending */</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This article describes how to suspend a computer (usually a laptop) to disk. This means that all the running processes are saved to the hard drive and the power is completely shut down. The article discusses the two main methods to accomplish this task, that is userspace suspension (uswsusp) and tuxonice (formerly known as suspend2). See the [http://suspend.sourceforge.net/ ususpend website] and the [http://www.tuxonice.net/ tuxonice website] for complete documentation. There is a third method: using the kernelspace functionalities of the vanilla kernel. However, this method is the least developed, the slowest and the less reliable. On the contrary, tuxonice and ususpend are competing in features and stability. The only method to decide which method is better for you is to try both of them. From a general point of view, we can say that uswsusp does not force you to patch, configure and compile a kernel, while tuxonice does. However, tuxonice can be used without an initrd/initramfs, while using ususpend without an initrd/initramfs is discouraged; moreover, tuxonice allows you to suspend on a regular file if you have not a swap partition, while uswsusp give this possibility only if you run an experimental and unstable mm kernel.<br />
<br />
It is important to distinguish the core method of suspension to disk from the userspace application which you use to hibernate your machine to disk. A userspace application is required because the large majority of the laptops require some quirks in order to accomplish a proficient, successful hibernation cycle: unloading modules, restarting services, unmount windows partitions and usb keys, and so on.<br />
<br />
There are two widely used userspace applications for this purpose: [[pm-utils]] and hibernate-script. You can find both of them in the extra repo. However, since in this guide we need to describe two different, competing core methods, we will focus on the hibernate-script, since only this script allows the user to choose the core method he prefers. On the contrary, [[pm-utils]], at least in the version actually distributed by arch, forces you silently to use the old vanilla method. On the other side, the script, developed by the tuxonice development team, can be used nonetheless also to hibernate your machine with the ususpend method, and even to suspend the machine to ram (actually it is an excellent tool also for this task, but we are not going to discuss this aspect in this document, see [[Suspend to RAM]]).<br />
<br />
If you prefer to use pm-utils, refer to the specific [[pm-utils|wiki article]]. You should note that the pm-utils-opensuse package includes some patches from opensuse which allow the user to choose uswsusp as a core method. In the web you can find other patches which allow you to use tuxonice as a method. The upcoming release of pm-utils will include all these patches and pm-utils will be a serious competitor of the hibernate-script. Nonetheless, the hibernate-script is still much more configurable and documented, so this guide still assumes that you are using it (although it is very easy to translate each info for pm-utils).<br />
<br />
Thus:<br />
<br />
# pacman -S hibernate-script<br />
<br />
The discussion will be articulated in four parts. First of all, we will discuss the userspace method, secondly the tuxonice one, thirdly we will see how to use the power of the hibernate-script in order to circumvent some problems which could impair your ability to accomplish successful suspend/resume cycles. These last tips can be used with both methods. On the contrary, the first two parts will include instructions to use the hibernate-script in order to accomplish the basic operations with the two methods. In the fourth and last part, we will see how to combine suspension to disk and [[Suspend to RAM]] . <br />
<br />
When there is the need to modify the configuration of the bootloader, we will be always under the assumption that you use grub, but it should not be difficult to act analogously on the configuration of lilo.<br />
<br />
=Uswsusp method=<br />
<br />
The userspace method lets you resort to some advanced suspension abilities included in vanilla kernels > 2.6.17. You need two userspace tools, called s2disk and resume, which do what their names say. They are both included in the uswsusp package (which includes also s2ram, see [[Suspend to RAM]] ). You can find uswsusp in the AUR. The package in the AUR includes also an initramfs hook which allows you to resume properly using an initramfs.<br />
<br />
==Obtaining uswsusp==<br />
The first thing to do is to download the tarball from the AUR page. Compile the source and create the package with makepkg and install it with pacman -U.<br />
<br />
==Editing /etc/suspend.conf==<br />
On the contrary, you need to edit the s2disk configuration file, called /etc/suspend.conf. It is essential that you modify the resume device parameter:<br />
<br />
resume device = /dev/sda3<br />
<br />
It needs to point to your swap partition: in this case, the third partition of a primary pata-sata drive. It is also a good thing to enable compression, because this speeds up greatly your suspension/resume routine.<br />
<br />
Note that it is important that this configuration file be edited *before* recreating the initramfs (done below). Presently, the initramfs build process reads this configuration file, and embeds the current resume parameter. If not changed from the default '<path_to_resume_device_file>', this causes problems such as seeing, on bootup:<br />
<br />
# Could not stat the resume device file '<path_to_resume_device_file>'<br />
# Please type in the full path name to try again or press ENTER to boot the system.<br />
<br />
If you have experiencing this problem, simply edit the file as appropriate, and then rebuild the initramfs.<br />
<br />
==Recreate the intramfs==<br />
Now you need to recreate an initramfs with the new hook. So edit the /etc/mkinitcpio.conf file. In the HOOKS list add the uresume hook (it is different from the resume hook, which is on the contrary required by the tuxonice method). You should put it immediately before the filesystem hook. When the hook is executed the device file for the swap partition (which you have defined in /etc/suspend.conf) needs to exist (the standard udev hook will take care of this). Now proceed to regenerate your initramfs :<br />
<br />
# mkinitcpio -k `uname -r` -g /boot/kernel26.img<br />
<br />
You need to adjust this command according to the kernel you plan to use and the name of the initramfs in the grub configuration. Anyway you should not need to modify anything in the grub configuration.<br />
<br />
==Support for encryption==<br />
The package in the AUR does already support encryption. You need to:<br />
* generate a key with the suspend-keygen utility included in the uswsusp package;<br />
* write the name of the key in /etc/suspend.conf;<br />
* uncomment or add the following line in /etc/suspend.conf<br />
<br />
encrypt = y<br />
RSA key file = <path_to_keyfile><br />
* build a new initramfs with the uresume hook just before the filesystem one.<br />
<br />
==Support for splash screens and suspension to file==<br />
<br />
The AUR package does not provide support for splash screens: uswsusp would support splashy and fbsplash, but you need to modify the PKGBUILD in order to recompile uswsusp with libsplashy or fbsplash support: see the HOWTO and README in the source tarball for details.<br />
<br />
Please note that uswsusp can also suspend to a file, but only if you use an experimental mm-patched kernel. If you want to suspend to file, tuxonice is probably the way to go. In the case you like experimental things, see the instructions in the HOWTO of the uswsusp source tarball.<br />
<br />
==Suspending==<br />
<br />
Now you could try to suspend directly calling s2disk from the command line:<br />
<br />
# s2disk<br />
<br />
However, this is highly likely to fail, because some services could need to be stopped, some modules unloaded, etc. Thus it is probably necessary to resort to a userspace tool which calls internally s2disk, like [[Pm-utils]] since version 1.1 (which is now in core) or hibernate-script. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] about details for defining the ususpend-disk method as default in /etc/hibernate/hibernate.conf. For the moment being, remember that you can define specific options in /etc/hibernate/ususpend-disk.conf and, after having configured also /etc/hibernate/common.conf, you can suspend to disk with the uswsusp method with the following command:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-disk.conf<br />
<br />
=Tuxonice method=<br />
<br />
==Obtaining tuxonice==<br />
Tuxonice consists of a kernel patch, plus a user interface. Only the kernel patch is necessary, the user interface provides merely a semi-graphical interface displayed during the hibernation/resume cycle. <br />
<br />
Archlinux used to deliver a binary tuxonice-patched kernel, but none of the devs want currently to maintain it. <br />
<br />
However you can use the kernel26tuxonice in AUR unsupported. It automatizes all the patch routine, the compilation and installation of the kernel, the regeneration of the initramfs with an appropriate hook. <br />
<br />
Otherwise, you need to patch, configure and compile your own kernel. You can do this either with the ABS method (starting from the arch default kernel PKGBUILD and adding the tuxonice patchset, or with the plain, old, reliable, venerable routine of <br />
<br />
# make menuconfig<br />
# make<br />
# make modules_install<br />
# cp arch/i386/boot/bzImage /boot/kernel-tuxonice-2.6.*<br />
<br />
See [[Kernel Compilation From Source]] and [[Kernel Compilation with ABS]] for instructions.<br />
In both cases, you need to configure the options added by the patchset, which you can find in the ACPI section of make menuconfig. Anyway, the defaults should be suitable for the large majority of scenarios. You can also hardcode in the kernel the path of your swap partition. In this case you can skip the below [[Suspend to Disk#Editing the Grub menu.lst]] .<br />
<br />
Please note that, if you spend the time to reconfigure completely the kernel (and in particular if you compile into the kernel the stuff necessary to boot your machine), you can be dispensed by the necessity to generate and use an initramfs: tuxonice will be able to resume properly also without an initrd/initramfs.<br />
<br />
==Editing the Grub menu.lst==<br />
Before your can use the suspend function, you need to boot your computer with the "resume" parameter, unless you have hardcoded your swap partition during the kernel configuration. The resume parameter points to the swap partition or swap file. The parameter is a kernel boot parameter, that is it should be added, if you use GRUB, to the line of /boot/grub/menu.lst where the location of your kernel is specified. <br />
For example:<br />
<br />
# tuxonice kernel<br />
title ArchLinux<br />
kernel /boot/kernel-tuxonice-2.6 root=/dev/hda2 resume=swap:/dev/hda3<br />
initrd /boot/tuxonice.img<br />
<br />
This assumes that you installed Archlinux onto the second hard drive partition, that your swap partition is the third, that you have not a separate /boot partition and that you are using an initrd. Adjust accordingly to your case.<br />
<br />
==Recreating the initramfs==<br />
<br />
If you use an initramfs, you need to add the tuxonice hook (which is different from the uresume used by uswsusp and by the resume hook for vanilla kernel suspension) in the HOOKS in the configuration of mkinitcpio. The hook is provided by the tuxoniceinitcpio package in AUR unsupported. This package is a dependency of kernel26tuxonice and is applied by default by kernel26tuxonice. Once you have added the tuxonice hook, you need to regenerate your initramfs, with a command like the following:<br />
<br />
# mkinitcpio -k kernel-tuxonice-2.6 -g /boot/tuxonice.img<br />
<br />
==Using userui - a user interface for tuxonice==<br />
<br />
Optionally, you can use a text or fbsplash interface with a progress bar with tuxonice. To do this, install the userui package in the extra repo:<br />
<br />
# pacman -S userui<br />
<br />
In ''/etc/hibernate/suspend2.conf'', configure the user interface:<br />
<br />
## Specify a userui like this:<br />
# text interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_text<br />
<br />
or<br />
<br />
## Specify a userui like this:<br />
# fbsplash interface interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_fbsplash<br />
<br />
The ''fbsplash'' interface also needs a fbsplash theme in ''/etc/splash/suspend2/''.<br />
<br />
The text interface may be good for debugging suspend2, as it displays some messages.<br />
You won't see a user interface for the first few seconds of the resume process unless you add the ''userui'' hook to your mkinitcpio configuration and regenerate your initramfs, but this is also optional.<br />
<br />
==Suspending and Resuming==<br />
<br />
Now you need to tweak the hibernate script. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] for instructions about defining the tuxonice method as the default hibernation method. <br />
The specific file is /etc/hibernate/suspend2.conf (the hibernate-script still uses the old name of tuxonice):<br />
<br />
Make sure that the following lines are uncommented and appropriately configured:<br />
UseSuspend2 yes<br />
Reboot no<br />
EnableEscape yes<br />
DefaultConsoleLevel 1<br />
Compressor lzf<br />
<br />
Encryptor none<br />
<br />
Once you have tweaked what you want/need (also in /etc/hibernate/common.conf), you can try tuxonice hibernation with the following method:<br />
<br />
# hibernate -F /etc/hibernate/suspend2.conf<br />
<br />
You can abort a suspend cycle if you press the escape key. If you press a capital r, you will force the system to reboot after hibernation.<br />
If all goes well, you should be able to resume using the same Grub menu selection. If you make that option the default for Grub, you will always default to resuming if a resume image is available. '''Do never use a different kernel to resume than you used to suspend! If pacman updates your kernel, don't suspend before you have rebooted properly.''' It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X.<br />
<br />
You can make this practice safer adding the hibernate-cleanup service to your SERVICES array in /etc/rc.conf. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the grub prompt. The hibernate-cleanup service is included in the hibernate-script package.<br />
<br />
== References ==<br />
<br />
*The [http://www.tuxonice.net tuxonice website] and the [http://wiki.tuxonice.net/ tuxonice wiki] are excellent sources of documentation.<br />
*There is a good [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo wiki article] that covers a lot of the same material.<br />
<br />
<br />
=Hibernate tricks with the hibernate.script=<br />
<br />
This is a brief overview of the hibernate script. If you want to tweak it further, examine the ''common.conf'' and ''suspend2.conf'' files further and read the excellent and exhaustive man pages for hibernate and hibernate.conf.<br />
<br />
==Editing /etc/hibernate/hibernate.conf==<br />
<br />
In order to call directly the hibernate command without the -F option, you need to define your preferred hibernation method. This should be done in this file. If you list several methods, the first one will be used. Note that ''hibernate'' can also be used with [[Suspend to RAM]] or vanilla swsusp, but this is not part of this HOWTO).<br />
<br />
Then either:<br />
<br />
TryMethod ususpend-disk.conf<br />
<br />
or: <br />
<br />
TryMethod suspend2.conf<br />
<br />
==Editing /etc/hibernate/common.conf==<br />
<br />
The options in this file are used with any hibernation method (actually, the file is sourced by the configuration files of each method) and also by [[Suspend to RAM]] when accomplished with the hibernate-script. This file is complex and well commented. The man page hibernate.conf describes adequately all the options. Here, we can only stress the most commonly useful parts.<br />
<br />
Uncomment the lines for any filesystems that have the potential to change while your computer is suspended (for example shared partitions with windows like vfat or ntfs ones). They will be remounted upon resume. Otherwise you would risk corrupting the filesystems.<br />
<br />
### filesystems<br />
# Unmount /nfsshare /windows /mnt/sambaserver<br />
# UnmountFSTypes smbfs nfs<br />
# UnmountGraceTime 1<br />
# Mount /windows<br />
<br />
If you don't explicitly restore the volume levels, ALSA may have the sound channels muted after resuming. If this happens, look for<br />
<br />
### services<br />
<br />
in /etc/hibernate/common.conf and change the line just below to<br />
<br />
RestartServices alsa<br />
<br />
The alsa service will be stopped before suspension and restarted after resuming: the sound channels and volumes will be as before.<br />
You may want to restart other problematic services here.<br />
<br />
A common issue is that some drivers do not support suspension, that is they do not work properly after a suspension cycle or even they prevent the system from suspending or resuming properly. <br />
In these cases (which should be reported - at least for modules in the vanilla kernel - to the suspend-devel@lists.sourceforge.net mailing list, so that they can be fixed upstream) you can unload the module before suspension and reload it after resuming: the hibernate-script can automatize this routine with the LoadModules and UnloadModules options. Actually, the hibernate-script already unload some problematic modules, listed in /etc/hibernate/blacklisted-modules, so you can also add the modules in that file.<br />
<br />
<br />
To re-connect to networks after rebooting, you may want to add<br />
OnResume 25 netcfg2 -a<br />
OnResume 20 netcfg-auto-wireless <your-network-interface><br />
This will disconnect from all networks, then should automatically choose the correct one. If you use another way to connect to a network (such as netcfg2 <profile-name> then of-course, put that there instead.<br />
<br />
If you need/want to eject all PcCards before suspending and reinsert them after resuming, change the ''EjectCards'' setting in ''common.conf'':<br />
<br />
### pcmcia<br />
EjectCards yes<br />
<br />
This is necessary on some laptops, if the pccards stop working after resume.<br />
<br />
Finally, the most problematic aspect is constituted by the video card: its status needs often to be restored after resuming. In other cases, it is necessary to switch from X to the console.<br />
The following options in /etc/hibernate/common.conf will probably fix these issues (whose symptom could be a frozen machine or only a black display after resuming):<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
You can uncomment one or many of them in order to see if the problem is solved. In order to use the first block of options, you need to install the vbetool package from the extra repository. Each of the option is documented in man hibernate.conf. <br />
Please note that it is very important to try all the different combinations of these options before than anything else, becaause the problems with the display are the most common source of troubles in a suspension cycle.<br />
<br />
== NVidia specific settings ==<br />
If you have an NVidia graphics card and are using the binary driver by NVidia with an AGP card, you have to add the following line to your /etc/X11/xorg.conf:<br />
<br />
Option "NvAGP" "1"<br />
<br />
NVidia also suggest this setting for the hibernate script:<br />
<br />
ProcSetting extra_pages_allowance 0<br />
<br />
to the file /etc/hibernate/common.conf. This setting also seems to help with the binary ATI driver. At last, you need to uncomment the nvidia module in /etc/hibernate/blacklisted-modules.<br />
<br />
== Suspending with fglrx ==<br />
Following addition to /etc/hibernate/suspend2.conf is required:<br />
<br />
# For fglrx<br />
ProcSetting extra_pages_allowance 20000<br />
<br />
== Dropping Disk Caches ==<br />
<br />
As a way to speed up suspending, you can free the memory used for disk caches. so there will be less to write to the disk. The downside is the risk of crashing your system. but I have had no trouble with it so far, while reducing the size of the suspended image by half. Just run this before hibernating:<br />
<br />
sync; echo 3 > /proc/sys/vm/drop_caches<br />
[http://www.linuxinsight.com/proc_sys_vm_drop_caches.html drop_caches introduction]<br />
<br />
=Combining suspend to disk with suspend to RAM=<br />
<br />
If your motherboard or laptop supports [[Suspend to RAM]], you can combine it with suspend2. This will result in the following behavior:<br />
<br />
* When you call hibernate, your system will suspend to disk and after that suspend to RAM instead of powering down.<br />
* When you turn your system back on, it will resume directly from RAM (which only takes a few seconds)<br />
* If your battery fails in the meantime (and the image in your memory is therefore lost), you will be able to resumes from disk.<br />
<br />
This can be done both with uswsusp and with tuxonice. <br />
<br />
With uswsusp, you should use s2both. You can also call s2both from the hibernate script (with all its richness of options), resorting to the ususpend-both.conf method. Please note that s2both works only if s2ram (see [[Suspend to RAM]]) works in your system. There is no way to force it to work if your laptop model is not whitelisted in s2ram. See [[Suspend to RAM]] for instructions about how to whitelist your laptop in the local copy of s2ram and how to report that your laptop suspend to ram properly so that it is whitelisted in the next uswsusp release.<br />
<br />
To do it with tuxonice, edit ''/etc/hibernate/suspend2.conf'':<br />
<br />
## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff<br />
PowerdownMethod 3<br />
<br />
For this to work, your computer must be able to use suspend to RAM also without s2ram.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Hibernate-script&diff=40227Hibernate-script2008-04-25T09:05:06Z<p>Lloeki: /* Obtaining uswsusp */</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This article describes how to suspend a computer (usually a laptop) to disk. This means that all the running processes are saved to the hard drive and the power is completely shut down. The article discusses the two main methods to accomplish this task, that is userspace suspension (uswsusp) and tuxonice (formerly known as suspend2). See the [http://suspend.sourceforge.net/ ususpend website] and the [http://www.tuxonice.net/ tuxonice website] for complete documentation. There is a third method: using the kernelspace functionalities of the vanilla kernel. However, this method is the least developed, the slowest and the less reliable. On the contrary, tuxonice and ususpend are competing in features and stability. The only method to decide which method is better for you is to try both of them. From a general point of view, we can say that uswsusp does not force you to patch, configure and compile a kernel, while tuxonice does. However, tuxonice can be used without an initrd/initramfs, while using ususpend without an initrd/initramfs is discouraged; moreover, tuxonice allows you to suspend on a regular file if you have not a swap partition, while uswsusp give this possibility only if you run an experimental and unstable mm kernel.<br />
<br />
It is important to distinguish the core method of suspension to disk from the userspace application which you use to hibernate your machine to disk. A userspace application is required because the large majority of the laptops require some quirks in order to accomplish a proficient, successful hibernation cycle: unloading modules, restarting services, unmount windows partitions and usb keys, and so on.<br />
<br />
There are two widely used userspace applications for this purpose: [[pm-utils]] and hibernate-script. You can find both of them in the extra repo. However, since in this guide we need to describe two different, competing core methods, we will focus on the hibernate-script, since only this script allows the user to choose the core method he prefers. On the contrary, [[pm-utils]], at least in the version actually distributed by arch, forces you silently to use the old vanilla method. On the other side, the script, developed by the tuxonice development team, can be used nonetheless also to hibernate your machine with the ususpend method, and even to suspend the machine to ram (actually it is an excellent tool also for this task, but we are not going to discuss this aspect in this document, see [[Suspend to RAM]]).<br />
<br />
If you prefer to use pm-utils, refer to the specific [[pm-utils|wiki article]]. You should note that the pm-utils-opensuse package includes some patches from opensuse which allow the user to choose uswsusp as a core method. In the web you can find other patches which allow you to use tuxonice as a method. The upcoming release of pm-utils will include all these patches and pm-utils will be a serious competitor of the hibernate-script. Nonetheless, the hibernate-script is still much more configurable and documented, so this guide still assumes that you are using it (although it is very easy to translate each info for pm-utils).<br />
<br />
Thus:<br />
<br />
# pacman -S hibernate-script<br />
<br />
The discussion will be articulated in four parts. First of all, we will discuss the userspace method, secondly the tuxonice one, thirdly we will see how to use the power of the hibernate-script in order to circumvent some problems which could impair your ability to accomplish successful suspend/resume cycles. These last tips can be used with both methods. On the contrary, the first two parts will include instructions to use the hibernate-script in order to accomplish the basic operations with the two methods. In the fourth and last part, we will see how to combine suspension to disk and [[Suspend to RAM]] . <br />
<br />
When there is the need to modify the configuration of the bootloader, we will be always under the assumption that you use grub, but it should not be difficult to act analogously on the configuration of lilo.<br />
<br />
=Uswsusp method=<br />
<br />
The userspace method lets you resort to some advanced suspension abilities included in vanilla kernels > 2.6.17. You need two userspace tools, called s2disk and resume, which do what their names say. They are both included in the uswsusp package (which includes also s2ram, see [[Suspend to RAM]] ). You can find uswsusp in the AUR. The package in the AUR includes also an initramfs hook which allows you to resume properly using an initramfs.<br />
<br />
==Obtaining uswsusp==<br />
The first thing to do is to download the tarball from the AUR page. Compile the source and create the package with makepkg and install it with pacman -U.<br />
<br />
==Editing /etc/suspend.conf==<br />
On the contrary, you need to edit the s2disk configuration file, called /etc/suspend.conf. It is essential that you modify the resume device parameter:<br />
<br />
resume device = /dev/sda3<br />
<br />
It needs to point to your swap partition: in this case, the third partition of a primary pata-sata drive. It is also a good thing to enable compression, because this speeds up greatly your suspension/resume routine.<br />
<br />
Note that it is important that this configuration file be edited *before* recreating the initramfs (done below). Presently, the initramfs build process reads this configuration file, and embeds the current resume parameter. If not changed from the default '<path_to_resume_device_file>', this causes problems such as seeing, on bootup:<br />
<br />
# Could not stat the resume device file '<path_to_resume_device_file>'<br />
# Please type in the full path name to try again or press ENTER to boot the system.<br />
<br />
If you have experiencing this problem, simply edit the file as appropriate, and then rebuild the initramfs.<br />
<br />
==Recreate the intramfs==<br />
Now you need to recreate an initramfs with the new hook. So edit the /etc/mkinitcpio.conf file. In the HOOKS list add the uresume hook (it is different from the resume hook, which is on the contrary required by the tuxonice method). You should put it immediately before the filesystem hook. When the hook is executed the device file for the swap partition (which you have defined in /etc/suspend.conf) needs to exist (the standard udev hook will take care of this). Now proceed to regenerate your initramfs :<br />
<br />
# mkinitcpio -k `uname -r` -g /boot/kernel26.img<br />
<br />
You need to adjust this command according to the kernel you plan to use and the name of the initramfs in the grub configuration. Anyway you should not need to modify anything in the grub configuration.<br />
<br />
==Support for encryption==<br />
The package in the AUR does already support encryption. You need to:<br />
* generate a key with the suspend-keygen utility included in the uswsusp package;<br />
* write the name of the key in /etc/suspend.conf;<br />
* uncomment or add the following line in /etc/suspend.conf<br />
<br />
encrypt = y<br />
RSA key file = <path_to_keyfile><br />
* build a new initramfs with the uresume hook just before the filesystem one.<br />
<br />
==Support for splash screens and suspension to file==<br />
<br />
The AUR package does not provide support for splash screens: uswsusp would support splashy and fbsplash, but you need to modify the PKGBUILD in order to recompile uswsusp with libsplashy or fbsplash support: see the HOWTO and README in the source tarball for details.<br />
<br />
Please note that uswsusp can also suspend to a file, but only if you use an experimental mm-patched kernel. If you want to suspend to file, tuxonice is probably the way to go. In the case you like experimental things, see the instructions in the HOWTO of the uswsusp source tarball.<br />
<br />
==Suspending==<br />
<br />
Now you could try to suspend directly calling s2disk from the command line:<br />
<br />
# s2disk<br />
<br />
However, this is highly likely to fail, because some services could need to be stopped, some modules unloaded, etc. Thus it is probably necessary to resort to a userspace tool which calls internally s2disk. The hibernate-script does this. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] about details for defining the ususpend-disk method as default in /etc/hibernate/hibernate.conf. For the moment being, remember that you can define specific options in /etc/hibernate/ususpend-disk.conf and, after having configured also /etc/hibernate/common.conf, you can suspend to disk with the uswsusp method with the following command:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-disk.conf <br />
<br />
=Tuxonice method=<br />
<br />
==Obtaining tuxonice==<br />
Tuxonice consists of a kernel patch, plus a user interface. Only the kernel patch is necessary, the user interface provides merely a semi-graphical interface displayed during the hibernation/resume cycle. <br />
<br />
Archlinux used to deliver a binary tuxonice-patched kernel, but none of the devs want currently to maintain it. <br />
<br />
However you can use the kernel26tuxonice in AUR unsupported. It automatizes all the patch routine, the compilation and installation of the kernel, the regeneration of the initramfs with an appropriate hook. <br />
<br />
Otherwise, you need to patch, configure and compile your own kernel. You can do this either with the ABS method (starting from the arch default kernel PKGBUILD and adding the tuxonice patchset, or with the plain, old, reliable, venerable routine of <br />
<br />
# make menuconfig<br />
# make<br />
# make modules_install<br />
# cp arch/i386/boot/bzImage /boot/kernel-tuxonice-2.6.*<br />
<br />
See [[Kernel Compilation From Source]] and [[Kernel Compilation with ABS]] for instructions.<br />
In both cases, you need to configure the options added by the patchset, which you can find in the ACPI section of make menuconfig. Anyway, the defaults should be suitable for the large majority of scenarios. You can also hardcode in the kernel the path of your swap partition. In this case you can skip the below [[Suspend to Disk#Editing the Grub menu.lst]] .<br />
<br />
Please note that, if you spend the time to reconfigure completely the kernel (and in particular if you compile into the kernel the stuff necessary to boot your machine), you can be dispensed by the necessity to generate and use an initramfs: tuxonice will be able to resume properly also without an initrd/initramfs.<br />
<br />
==Editing the Grub menu.lst==<br />
Before your can use the suspend function, you need to boot your computer with the "resume" parameter, unless you have hardcoded your swap partition during the kernel configuration. The resume parameter points to the swap partition or swap file. The parameter is a kernel boot parameter, that is it should be added, if you use GRUB, to the line of /boot/grub/menu.lst where the location of your kernel is specified. <br />
For example:<br />
<br />
# tuxonice kernel<br />
title ArchLinux<br />
kernel /boot/kernel-tuxonice-2.6 root=/dev/hda2 resume=swap:/dev/hda3<br />
initrd /boot/tuxonice.img<br />
<br />
This assumes that you installed Archlinux onto the second hard drive partition, that your swap partition is the third, that you have not a separate /boot partition and that you are using an initrd. Adjust accordingly to your case.<br />
<br />
==Recreating the initramfs==<br />
<br />
If you use an initramfs, you need to add the tuxonice hook (which is different from the uresume used by uswsusp and by the resume hook for vanilla kernel suspension) in the HOOKS in the configuration of mkinitcpio. The hook is provided by the tuxoniceinitcpio package in AUR unsupported. This package is a dependency of kernel26tuxonice and is applied by default by kernel26tuxonice. Once you have added the tuxonice hook, you need to regenerate your initramfs, with a command like the following:<br />
<br />
# mkinitcpio -k kernel-tuxonice-2.6 -g /boot/tuxonice.img<br />
<br />
==Using userui - a user interface for tuxonice==<br />
<br />
Optionally, you can use a text or fbsplash interface with a progress bar with tuxonice. To do this, install the userui package in the extra repo:<br />
<br />
# pacman -S userui<br />
<br />
In ''/etc/hibernate/suspend2.conf'', configure the user interface:<br />
<br />
## Specify a userui like this:<br />
# text interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_text<br />
<br />
or<br />
<br />
## Specify a userui like this:<br />
# fbsplash interface interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_fbsplash<br />
<br />
The ''fbsplash'' interface also needs a fbsplash theme in ''/etc/splash/suspend2/''.<br />
<br />
The text interface may be good for debugging suspend2, as it displays some messages.<br />
You won't see a user interface for the first few seconds of the resume process unless you add the ''userui'' hook to your mkinitcpio configuration and regenerate your initramfs, but this is also optional.<br />
<br />
==Suspending and Resuming==<br />
<br />
Now you need to tweak the hibernate script. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] for instructions about defining the tuxonice method as the default hibernation method. <br />
The specific file is /etc/hibernate/suspend2.conf (the hibernate-script still uses the old name of tuxonice):<br />
<br />
Make sure that the following lines are uncommented and appropriately configured:<br />
UseSuspend2 yes<br />
Reboot no<br />
EnableEscape yes<br />
DefaultConsoleLevel 1<br />
Compressor lzf<br />
<br />
Encryptor none<br />
<br />
Once you have tweaked what you want/need (also in /etc/hibernate/common.conf), you can try tuxonice hibernation with the following method:<br />
<br />
# hibernate -F /etc/hibernate/suspend2.conf<br />
<br />
You can abort a suspend cycle if you press the escape key. If you press a capital r, you will force the system to reboot after hibernation.<br />
If all goes well, you should be able to resume using the same Grub menu selection. If you make that option the default for Grub, you will always default to resuming if a resume image is available. '''Do never use a different kernel to resume than you used to suspend! If pacman updates your kernel, don't suspend before you have rebooted properly.''' It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X.<br />
<br />
You can make this practice safer adding the hibernate-cleanup service to your SERVICES array in /etc/rc.conf. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the grub prompt. The hibernate-cleanup service is included in the hibernate-script package.<br />
<br />
== References ==<br />
<br />
*The [http://www.tuxonice.net tuxonice website] and the [http://wiki.tuxonice.net/ tuxonice wiki] are excellent sources of documentation.<br />
*There is a good [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo wiki article] that covers a lot of the same material.<br />
<br />
<br />
=Hibernate tricks with the hibernate.script=<br />
<br />
This is a brief overview of the hibernate script. If you want to tweak it further, examine the ''common.conf'' and ''suspend2.conf'' files further and read the excellent and exhaustive man pages for hibernate and hibernate.conf.<br />
<br />
==Editing /etc/hibernate/hibernate.conf==<br />
<br />
In order to call directly the hibernate command without the -F option, you need to define your preferred hibernation method. This should be done in this file. If you list several methods, the first one will be used. Note that ''hibernate'' can also be used with [[Suspend to RAM]] or vanilla swsusp, but this is not part of this HOWTO).<br />
<br />
Then either:<br />
<br />
TryMethod ususpend-disk.conf<br />
<br />
or: <br />
<br />
TryMethod suspend2.conf<br />
<br />
==Editing /etc/hibernate/common.conf==<br />
<br />
The options in this file are used with any hibernation method (actually, the file is sourced by the configuration files of each method) and also by [[Suspend to RAM]] when accomplished with the hibernate-script. This file is complex and well commented. The man page hibernate.conf describes adequately all the options. Here, we can only stress the most commonly useful parts.<br />
<br />
Uncomment the lines for any filesystems that have the potential to change while your computer is suspended (for example shared partitions with windows like vfat or ntfs ones). They will be remounted upon resume. Otherwise you would risk corrupting the filesystems.<br />
<br />
### filesystems<br />
# Unmount /nfsshare /windows /mnt/sambaserver<br />
# UnmountFSTypes smbfs nfs<br />
# UnmountGraceTime 1<br />
# Mount /windows<br />
<br />
If you don't explicitly restore the volume levels, ALSA may have the sound channels muted after resuming. If this happens, look for<br />
<br />
### services<br />
<br />
in /etc/hibernate/common.conf and change the line just below to<br />
<br />
RestartServices alsa<br />
<br />
The alsa service will be stopped before suspension and restarted after resuming: the sound channels and volumes will be as before.<br />
You may want to restart other problematic services here.<br />
<br />
A common issue is that some drivers do not support suspension, that is they do not work properly after a suspension cycle or even they prevent the system from suspending or resuming properly. <br />
In these cases (which should be reported - at least for modules in the vanilla kernel - to the suspend-devel@lists.sourceforge.net mailing list, so that they can be fixed upstream) you can unload the module before suspension and reload it after resuming: the hibernate-script can automatize this routine with the LoadModules and UnloadModules options. Actually, the hibernate-script already unload some problematic modules, listed in /etc/hibernate/blacklisted-modules, so you can also add the modules in that file.<br />
<br />
<br />
To re-connect to networks after rebooting, you may want to add<br />
OnResume 25 netcfg2 -a<br />
OnResume 20 netcfg-auto-wireless <your-network-interface><br />
This will disconnect from all networks, then should automatically choose the correct one. If you use another way to connect to a network (such as netcfg2 <profile-name> then of-course, put that there instead.<br />
<br />
If you need/want to eject all PcCards before suspending and reinsert them after resuming, change the ''EjectCards'' setting in ''common.conf'':<br />
<br />
### pcmcia<br />
EjectCards yes<br />
<br />
This is necessary on some laptops, if the pccards stop working after resume.<br />
<br />
Finally, the most problematic aspect is constituted by the video card: its status needs often to be restored after resuming. In other cases, it is necessary to switch from X to the console.<br />
The following options in /etc/hibernate/common.conf will probably fix these issues (whose symptom could be a frozen machine or only a black display after resuming):<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
You can uncomment one or many of them in order to see if the problem is solved. In order to use the first block of options, you need to install the vbetool package from the extra repository. Each of the option is documented in man hibernate.conf. <br />
Please note that it is very important to try all the different combinations of these options before than anything else, becaause the problems with the display are the most common source of troubles in a suspension cycle.<br />
<br />
== NVidia specific settings ==<br />
If you have an NVidia graphics card and are using the binary driver by NVidia with an AGP card, you have to add the following line to your /etc/X11/xorg.conf:<br />
<br />
Option "NvAGP" "1"<br />
<br />
NVidia also suggest this setting for the hibernate script:<br />
<br />
ProcSetting extra_pages_allowance 0<br />
<br />
to the file /etc/hibernate/common.conf. This setting also seems to help with the binary ATI driver. At last, you need to uncomment the nvidia module in /etc/hibernate/blacklisted-modules.<br />
<br />
== Suspending with fglrx ==<br />
Following addition to /etc/hibernate/suspend2.conf is required:<br />
<br />
# For fglrx<br />
ProcSetting extra_pages_allowance 20000<br />
<br />
== Dropping Disk Caches ==<br />
<br />
As a way to speed up suspending, you can free the memory used for disk caches. so there will be less to write to the disk. The downside is the risk of crashing your system. but I have had no trouble with it so far, while reducing the size of the suspended image by half. Just run this before hibernating:<br />
<br />
sync; echo 3 > /proc/sys/vm/drop_caches<br />
[http://www.linuxinsight.com/proc_sys_vm_drop_caches.html drop_caches introduction]<br />
<br />
=Combining suspend to disk with suspend to RAM=<br />
<br />
If your motherboard or laptop supports [[Suspend to RAM]], you can combine it with suspend2. This will result in the following behavior:<br />
<br />
* When you call hibernate, your system will suspend to disk and after that suspend to RAM instead of powering down.<br />
* When you turn your system back on, it will resume directly from RAM (which only takes a few seconds)<br />
* If your battery fails in the meantime (and the image in your memory is therefore lost), you will be able to resumes from disk.<br />
<br />
This can be done both with uswsusp and with tuxonice. <br />
<br />
With uswsusp, you should use s2both. You can also call s2both from the hibernate script (with all its richness of options), resorting to the ususpend-both.conf method. Please note that s2both works only if s2ram (see [[Suspend to RAM]]) works in your system. There is no way to force it to work if your laptop model is not whitelisted in s2ram. See [[Suspend to RAM]] for instructions about how to whitelist your laptop in the local copy of s2ram and how to report that your laptop suspend to ram properly so that it is whitelisted in the next uswsusp release.<br />
<br />
To do it with tuxonice, edit ''/etc/hibernate/suspend2.conf'':<br />
<br />
## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff<br />
PowerdownMethod 3<br />
<br />
For this to work, your computer must be able to use suspend to RAM also without s2ram.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Hibernate-script&diff=40226Hibernate-script2008-04-25T09:03:51Z<p>Lloeki: /* Obtaining uswsusp */</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This article describes how to suspend a computer (usually a laptop) to disk. This means that all the running processes are saved to the hard drive and the power is completely shut down. The article discusses the two main methods to accomplish this task, that is userspace suspension (uswsusp) and tuxonice (formerly known as suspend2). See the [http://suspend.sourceforge.net/ ususpend website] and the [http://www.tuxonice.net/ tuxonice website] for complete documentation. There is a third method: using the kernelspace functionalities of the vanilla kernel. However, this method is the least developed, the slowest and the less reliable. On the contrary, tuxonice and ususpend are competing in features and stability. The only method to decide which method is better for you is to try both of them. From a general point of view, we can say that uswsusp does not force you to patch, configure and compile a kernel, while tuxonice does. However, tuxonice can be used without an initrd/initramfs, while using ususpend without an initrd/initramfs is discouraged; moreover, tuxonice allows you to suspend on a regular file if you have not a swap partition, while uswsusp give this possibility only if you run an experimental and unstable mm kernel.<br />
<br />
It is important to distinguish the core method of suspension to disk from the userspace application which you use to hibernate your machine to disk. A userspace application is required because the large majority of the laptops require some quirks in order to accomplish a proficient, successful hibernation cycle: unloading modules, restarting services, unmount windows partitions and usb keys, and so on.<br />
<br />
There are two widely used userspace applications for this purpose: [[pm-utils]] and hibernate-script. You can find both of them in the extra repo. However, since in this guide we need to describe two different, competing core methods, we will focus on the hibernate-script, since only this script allows the user to choose the core method he prefers. On the contrary, [[pm-utils]], at least in the version actually distributed by arch, forces you silently to use the old vanilla method. On the other side, the script, developed by the tuxonice development team, can be used nonetheless also to hibernate your machine with the ususpend method, and even to suspend the machine to ram (actually it is an excellent tool also for this task, but we are not going to discuss this aspect in this document, see [[Suspend to RAM]]).<br />
<br />
If you prefer to use pm-utils, refer to the specific [[pm-utils|wiki article]]. You should note that the pm-utils-opensuse package includes some patches from opensuse which allow the user to choose uswsusp as a core method. In the web you can find other patches which allow you to use tuxonice as a method. The upcoming release of pm-utils will include all these patches and pm-utils will be a serious competitor of the hibernate-script. Nonetheless, the hibernate-script is still much more configurable and documented, so this guide still assumes that you are using it (although it is very easy to translate each info for pm-utils).<br />
<br />
Thus:<br />
<br />
# pacman -S hibernate-script<br />
<br />
The discussion will be articulated in four parts. First of all, we will discuss the userspace method, secondly the tuxonice one, thirdly we will see how to use the power of the hibernate-script in order to circumvent some problems which could impair your ability to accomplish successful suspend/resume cycles. These last tips can be used with both methods. On the contrary, the first two parts will include instructions to use the hibernate-script in order to accomplish the basic operations with the two methods. In the fourth and last part, we will see how to combine suspension to disk and [[Suspend to RAM]] . <br />
<br />
When there is the need to modify the configuration of the bootloader, we will be always under the assumption that you use grub, but it should not be difficult to act analogously on the configuration of lilo.<br />
<br />
=Uswsusp method=<br />
<br />
The userspace method lets you resort to some advanced suspension abilities included in vanilla kernels > 2.6.17. You need two userspace tools, called s2disk and resume, which do what their names say. They are both included in the uswsusp package (which includes also s2ram, see [[Suspend to RAM]] ). You can find uswsusp in the AUR. The package in the AUR includes also an initramfs hook which allows you to resume properly using an initramfs.<br />
<br />
==Obtaining uswsusp==<br />
The first thing to do is to download the tarball from the AUR page. Compile the source and create the package with makepkg and install it with pacman -U. From there you can either use the hibernate scripta s outlined below or use [[Pm-utils]] since version 1.1 (which is now in core).<br />
<br />
==Editing /etc/suspend.conf==<br />
On the contrary, you need to edit the s2disk configuration file, called /etc/suspend.conf. It is essential that you modify the resume device parameter:<br />
<br />
resume device = /dev/sda3<br />
<br />
It needs to point to your swap partition: in this case, the third partition of a primary pata-sata drive. It is also a good thing to enable compression, because this speeds up greatly your suspension/resume routine.<br />
<br />
Note that it is important that this configuration file be edited *before* recreating the initramfs (done below). Presently, the initramfs build process reads this configuration file, and embeds the current resume parameter. If not changed from the default '<path_to_resume_device_file>', this causes problems such as seeing, on bootup:<br />
<br />
# Could not stat the resume device file '<path_to_resume_device_file>'<br />
# Please type in the full path name to try again or press ENTER to boot the system.<br />
<br />
If you have experiencing this problem, simply edit the file as appropriate, and then rebuild the initramfs.<br />
<br />
==Recreate the intramfs==<br />
Now you need to recreate an initramfs with the new hook. So edit the /etc/mkinitcpio.conf file. In the HOOKS list add the uresume hook (it is different from the resume hook, which is on the contrary required by the tuxonice method). You should put it immediately before the filesystem hook. When the hook is executed the device file for the swap partition (which you have defined in /etc/suspend.conf) needs to exist (the standard udev hook will take care of this). Now proceed to regenerate your initramfs :<br />
<br />
# mkinitcpio -k `uname -r` -g /boot/kernel26.img<br />
<br />
You need to adjust this command according to the kernel you plan to use and the name of the initramfs in the grub configuration. Anyway you should not need to modify anything in the grub configuration.<br />
<br />
==Support for encryption==<br />
The package in the AUR does already support encryption. You need to:<br />
* generate a key with the suspend-keygen utility included in the uswsusp package;<br />
* write the name of the key in /etc/suspend.conf;<br />
* uncomment or add the following line in /etc/suspend.conf<br />
<br />
encrypt = y<br />
RSA key file = <path_to_keyfile><br />
* build a new initramfs with the uresume hook just before the filesystem one.<br />
<br />
==Support for splash screens and suspension to file==<br />
<br />
The AUR package does not provide support for splash screens: uswsusp would support splashy and fbsplash, but you need to modify the PKGBUILD in order to recompile uswsusp with libsplashy or fbsplash support: see the HOWTO and README in the source tarball for details.<br />
<br />
Please note that uswsusp can also suspend to a file, but only if you use an experimental mm-patched kernel. If you want to suspend to file, tuxonice is probably the way to go. In the case you like experimental things, see the instructions in the HOWTO of the uswsusp source tarball.<br />
<br />
==Suspending==<br />
<br />
Now you could try to suspend directly calling s2disk from the command line:<br />
<br />
# s2disk<br />
<br />
However, this is highly likely to fail, because some services could need to be stopped, some modules unloaded, etc. Thus it is probably necessary to resort to a userspace tool which calls internally s2disk. The hibernate-script does this. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] about details for defining the ususpend-disk method as default in /etc/hibernate/hibernate.conf. For the moment being, remember that you can define specific options in /etc/hibernate/ususpend-disk.conf and, after having configured also /etc/hibernate/common.conf, you can suspend to disk with the uswsusp method with the following command:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-disk.conf <br />
<br />
=Tuxonice method=<br />
<br />
==Obtaining tuxonice==<br />
Tuxonice consists of a kernel patch, plus a user interface. Only the kernel patch is necessary, the user interface provides merely a semi-graphical interface displayed during the hibernation/resume cycle. <br />
<br />
Archlinux used to deliver a binary tuxonice-patched kernel, but none of the devs want currently to maintain it. <br />
<br />
However you can use the kernel26tuxonice in AUR unsupported. It automatizes all the patch routine, the compilation and installation of the kernel, the regeneration of the initramfs with an appropriate hook. <br />
<br />
Otherwise, you need to patch, configure and compile your own kernel. You can do this either with the ABS method (starting from the arch default kernel PKGBUILD and adding the tuxonice patchset, or with the plain, old, reliable, venerable routine of <br />
<br />
# make menuconfig<br />
# make<br />
# make modules_install<br />
# cp arch/i386/boot/bzImage /boot/kernel-tuxonice-2.6.*<br />
<br />
See [[Kernel Compilation From Source]] and [[Kernel Compilation with ABS]] for instructions.<br />
In both cases, you need to configure the options added by the patchset, which you can find in the ACPI section of make menuconfig. Anyway, the defaults should be suitable for the large majority of scenarios. You can also hardcode in the kernel the path of your swap partition. In this case you can skip the below [[Suspend to Disk#Editing the Grub menu.lst]] .<br />
<br />
Please note that, if you spend the time to reconfigure completely the kernel (and in particular if you compile into the kernel the stuff necessary to boot your machine), you can be dispensed by the necessity to generate and use an initramfs: tuxonice will be able to resume properly also without an initrd/initramfs.<br />
<br />
==Editing the Grub menu.lst==<br />
Before your can use the suspend function, you need to boot your computer with the "resume" parameter, unless you have hardcoded your swap partition during the kernel configuration. The resume parameter points to the swap partition or swap file. The parameter is a kernel boot parameter, that is it should be added, if you use GRUB, to the line of /boot/grub/menu.lst where the location of your kernel is specified. <br />
For example:<br />
<br />
# tuxonice kernel<br />
title ArchLinux<br />
kernel /boot/kernel-tuxonice-2.6 root=/dev/hda2 resume=swap:/dev/hda3<br />
initrd /boot/tuxonice.img<br />
<br />
This assumes that you installed Archlinux onto the second hard drive partition, that your swap partition is the third, that you have not a separate /boot partition and that you are using an initrd. Adjust accordingly to your case.<br />
<br />
==Recreating the initramfs==<br />
<br />
If you use an initramfs, you need to add the tuxonice hook (which is different from the uresume used by uswsusp and by the resume hook for vanilla kernel suspension) in the HOOKS in the configuration of mkinitcpio. The hook is provided by the tuxoniceinitcpio package in AUR unsupported. This package is a dependency of kernel26tuxonice and is applied by default by kernel26tuxonice. Once you have added the tuxonice hook, you need to regenerate your initramfs, with a command like the following:<br />
<br />
# mkinitcpio -k kernel-tuxonice-2.6 -g /boot/tuxonice.img<br />
<br />
==Using userui - a user interface for tuxonice==<br />
<br />
Optionally, you can use a text or fbsplash interface with a progress bar with tuxonice. To do this, install the userui package in the extra repo:<br />
<br />
# pacman -S userui<br />
<br />
In ''/etc/hibernate/suspend2.conf'', configure the user interface:<br />
<br />
## Specify a userui like this:<br />
# text interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_text<br />
<br />
or<br />
<br />
## Specify a userui like this:<br />
# fbsplash interface interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_fbsplash<br />
<br />
The ''fbsplash'' interface also needs a fbsplash theme in ''/etc/splash/suspend2/''.<br />
<br />
The text interface may be good for debugging suspend2, as it displays some messages.<br />
You won't see a user interface for the first few seconds of the resume process unless you add the ''userui'' hook to your mkinitcpio configuration and regenerate your initramfs, but this is also optional.<br />
<br />
==Suspending and Resuming==<br />
<br />
Now you need to tweak the hibernate script. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] for instructions about defining the tuxonice method as the default hibernation method. <br />
The specific file is /etc/hibernate/suspend2.conf (the hibernate-script still uses the old name of tuxonice):<br />
<br />
Make sure that the following lines are uncommented and appropriately configured:<br />
UseSuspend2 yes<br />
Reboot no<br />
EnableEscape yes<br />
DefaultConsoleLevel 1<br />
Compressor lzf<br />
<br />
Encryptor none<br />
<br />
Once you have tweaked what you want/need (also in /etc/hibernate/common.conf), you can try tuxonice hibernation with the following method:<br />
<br />
# hibernate -F /etc/hibernate/suspend2.conf<br />
<br />
You can abort a suspend cycle if you press the escape key. If you press a capital r, you will force the system to reboot after hibernation.<br />
If all goes well, you should be able to resume using the same Grub menu selection. If you make that option the default for Grub, you will always default to resuming if a resume image is available. '''Do never use a different kernel to resume than you used to suspend! If pacman updates your kernel, don't suspend before you have rebooted properly.''' It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X.<br />
<br />
You can make this practice safer adding the hibernate-cleanup service to your SERVICES array in /etc/rc.conf. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the grub prompt. The hibernate-cleanup service is included in the hibernate-script package.<br />
<br />
== References ==<br />
<br />
*The [http://www.tuxonice.net tuxonice website] and the [http://wiki.tuxonice.net/ tuxonice wiki] are excellent sources of documentation.<br />
*There is a good [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo wiki article] that covers a lot of the same material.<br />
<br />
<br />
=Hibernate tricks with the hibernate.script=<br />
<br />
This is a brief overview of the hibernate script. If you want to tweak it further, examine the ''common.conf'' and ''suspend2.conf'' files further and read the excellent and exhaustive man pages for hibernate and hibernate.conf.<br />
<br />
==Editing /etc/hibernate/hibernate.conf==<br />
<br />
In order to call directly the hibernate command without the -F option, you need to define your preferred hibernation method. This should be done in this file. If you list several methods, the first one will be used. Note that ''hibernate'' can also be used with [[Suspend to RAM]] or vanilla swsusp, but this is not part of this HOWTO).<br />
<br />
Then either:<br />
<br />
TryMethod ususpend-disk.conf<br />
<br />
or: <br />
<br />
TryMethod suspend2.conf<br />
<br />
==Editing /etc/hibernate/common.conf==<br />
<br />
The options in this file are used with any hibernation method (actually, the file is sourced by the configuration files of each method) and also by [[Suspend to RAM]] when accomplished with the hibernate-script. This file is complex and well commented. The man page hibernate.conf describes adequately all the options. Here, we can only stress the most commonly useful parts.<br />
<br />
Uncomment the lines for any filesystems that have the potential to change while your computer is suspended (for example shared partitions with windows like vfat or ntfs ones). They will be remounted upon resume. Otherwise you would risk corrupting the filesystems.<br />
<br />
### filesystems<br />
# Unmount /nfsshare /windows /mnt/sambaserver<br />
# UnmountFSTypes smbfs nfs<br />
# UnmountGraceTime 1<br />
# Mount /windows<br />
<br />
If you don't explicitly restore the volume levels, ALSA may have the sound channels muted after resuming. If this happens, look for<br />
<br />
### services<br />
<br />
in /etc/hibernate/common.conf and change the line just below to<br />
<br />
RestartServices alsa<br />
<br />
The alsa service will be stopped before suspension and restarted after resuming: the sound channels and volumes will be as before.<br />
You may want to restart other problematic services here.<br />
<br />
A common issue is that some drivers do not support suspension, that is they do not work properly after a suspension cycle or even they prevent the system from suspending or resuming properly. <br />
In these cases (which should be reported - at least for modules in the vanilla kernel - to the suspend-devel@lists.sourceforge.net mailing list, so that they can be fixed upstream) you can unload the module before suspension and reload it after resuming: the hibernate-script can automatize this routine with the LoadModules and UnloadModules options. Actually, the hibernate-script already unload some problematic modules, listed in /etc/hibernate/blacklisted-modules, so you can also add the modules in that file.<br />
<br />
<br />
To re-connect to networks after rebooting, you may want to add<br />
OnResume 25 netcfg2 -a<br />
OnResume 20 netcfg-auto-wireless <your-network-interface><br />
This will disconnect from all networks, then should automatically choose the correct one. If you use another way to connect to a network (such as netcfg2 <profile-name> then of-course, put that there instead.<br />
<br />
If you need/want to eject all PcCards before suspending and reinsert them after resuming, change the ''EjectCards'' setting in ''common.conf'':<br />
<br />
### pcmcia<br />
EjectCards yes<br />
<br />
This is necessary on some laptops, if the pccards stop working after resume.<br />
<br />
Finally, the most problematic aspect is constituted by the video card: its status needs often to be restored after resuming. In other cases, it is necessary to switch from X to the console.<br />
The following options in /etc/hibernate/common.conf will probably fix these issues (whose symptom could be a frozen machine or only a black display after resuming):<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
You can uncomment one or many of them in order to see if the problem is solved. In order to use the first block of options, you need to install the vbetool package from the extra repository. Each of the option is documented in man hibernate.conf. <br />
Please note that it is very important to try all the different combinations of these options before than anything else, becaause the problems with the display are the most common source of troubles in a suspension cycle.<br />
<br />
== NVidia specific settings ==<br />
If you have an NVidia graphics card and are using the binary driver by NVidia with an AGP card, you have to add the following line to your /etc/X11/xorg.conf:<br />
<br />
Option "NvAGP" "1"<br />
<br />
NVidia also suggest this setting for the hibernate script:<br />
<br />
ProcSetting extra_pages_allowance 0<br />
<br />
to the file /etc/hibernate/common.conf. This setting also seems to help with the binary ATI driver. At last, you need to uncomment the nvidia module in /etc/hibernate/blacklisted-modules.<br />
<br />
== Suspending with fglrx ==<br />
Following addition to /etc/hibernate/suspend2.conf is required:<br />
<br />
# For fglrx<br />
ProcSetting extra_pages_allowance 20000<br />
<br />
== Dropping Disk Caches ==<br />
<br />
As a way to speed up suspending, you can free the memory used for disk caches. so there will be less to write to the disk. The downside is the risk of crashing your system. but I have had no trouble with it so far, while reducing the size of the suspended image by half. Just run this before hibernating:<br />
<br />
sync; echo 3 > /proc/sys/vm/drop_caches<br />
[http://www.linuxinsight.com/proc_sys_vm_drop_caches.html drop_caches introduction]<br />
<br />
=Combining suspend to disk with suspend to RAM=<br />
<br />
If your motherboard or laptop supports [[Suspend to RAM]], you can combine it with suspend2. This will result in the following behavior:<br />
<br />
* When you call hibernate, your system will suspend to disk and after that suspend to RAM instead of powering down.<br />
* When you turn your system back on, it will resume directly from RAM (which only takes a few seconds)<br />
* If your battery fails in the meantime (and the image in your memory is therefore lost), you will be able to resumes from disk.<br />
<br />
This can be done both with uswsusp and with tuxonice. <br />
<br />
With uswsusp, you should use s2both. You can also call s2both from the hibernate script (with all its richness of options), resorting to the ususpend-both.conf method. Please note that s2both works only if s2ram (see [[Suspend to RAM]]) works in your system. There is no way to force it to work if your laptop model is not whitelisted in s2ram. See [[Suspend to RAM]] for instructions about how to whitelist your laptop in the local copy of s2ram and how to report that your laptop suspend to ram properly so that it is whitelisted in the next uswsusp release.<br />
<br />
To do it with tuxonice, edit ''/etc/hibernate/suspend2.conf'':<br />
<br />
## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff<br />
PowerdownMethod 3<br />
<br />
For this to work, your computer must be able to use suspend to RAM also without s2ram.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Pm-utils&diff=40225Pm-utils2008-04-25T09:00:13Z<p>Lloeki: /* Tips and Tricks / FAQ */</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
= Summary =<br />
'''pm-utils''' is the new suspend and powerstate setting framework. It is designed to replace such scripts as those provided by the <tt>powersave</tt> package.<br />
<br />
It is usually used by HAL to execute the various hacks needed to work around bugs in drivers and subsystems that are not yet aware of suspend. It is easily extensible by putting custom hooks into a directory, which can either be done by the system administrator or those hooks can be part of a package, especially if this package needs special attention during a system suspend or power state transition.<br />
<br />
Used in conjunction with the [[Cpufrequtils]] package, notebook (and desktop) owners are provided with a complete power management suite.<br />
<br />
= Installation =<br />
<br />
The <tt>pm-utils</tt> package is now available from the [http://www.archlinux.org/packages/search/?q=pm-utils Extra] repository:<br />
# pacman -S pm-utils<br />
<br />
= Basic Configuration =<br />
== Hibernation (suspend2disk) ==<br />
In order for suspend2disk (hibernate) to work, we need to edit ''/boot/grub/menu.lst'' as root and add '''resume=/path/to/swap/drive''' (e.g. /dev/sda2) to the kernel options, for example:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 '''resume=/dev/sda2''' ro vga=0<br />
initrd /kernel26.img<br />
<br />
When the machine is placed into hibernation, it will now move all data from RAM to the swap partition... you ''did'' make your swap partition large enough to hold your RAM data, right?<br />
<br />
Remark: if you use an initrd at boot (as Arch does by default), the kernel will '''not''' resume, although you pass it the "resume=xxx" parameter. To get it to resume you have to add a 'suspend' hook to /etc/mkinitcpio.conf:<br />
#(last line of /etc/mkinitcpio.conf)<br />
#<br />
HOOKS="base udev autodetect ide scsi sata '''resume''' filesystems "<br />
<br />
Note that this is an ''example'', your HOOKS may look different, 'resume' has to be placed after 'ide', 'scsi' and/or 'sata' but before 'filesystems'. Of course there has to be an appropriate 'resume' file in /lib/initcpio/hooks, it should already be there, as it is part of the package 'mkinitcpio'.<br />
After that you need to rebuild the initrd (if you have a custom kernel you might have to change the value of the '-p' option):<br />
<br />
# mkinitcpio -p kernel26<br />
<br />
<br />
== Execute suspend/hibernate without root password ==<br />
Because the <tt>pm-utils</tt> scripts must be run as root, you may want to make the scripts accessible to normal users by running sudo without the root password. To do so, edit the <tt>/etc/sudoers</tt> file with visudo, for example:<br />
<br />
# visudo<br />
<br />
add the following lines, replacing ''username'' with your own:<br />
''username'' ALL = (ALL) NOPASSWD: /usr/sbin/pm-hibernate<br />
''username'' ALL = (ALL) NOPASSWD: /usr/sbin/pm-suspend<br />
save and exit visudo<br />
<br />
You can now run the scripts without a password by simply typing:<br />
$ sudo pm-hibernate<br />
or <br />
$ sudo pm-suspend<br />
<br />
= Advanced Configuration =<br />
The main configuration file is '''<tt>/usr/lib/pm-utils/defaults</tt>'''. You ''should not edit this file'', since after a package update it might be overwritten with the default settings. Put your config file into '''<tt>/etc/pm/config.d/</tt>''' instead.<br />
You can just put a simple text file with<br />
SUSPEND_MODULES="button uhci_hcd"<br />
named "modules" or "config" into <tt>/etc/pm/config.d</tt> and it will override the settings in the system wide configuration file.<br />
<br />
== Available Variables for use in config files ==<br />
SUSPEND_MODULES="button" # the list of modules to be unloaded before suspend<br />
<br />
== Disabling a hook ==<br />
If a hook is run which you do not like or which you think is not useful or even harmful, we'd appreciate a bugreport for that.<br />
You can however easily disable hooks by just creating an empty file corresponding to the hook in <tt>/etc/pm/sleep.d/</tt>. Say you want to disable the hook <tt>/usr/lib/pm-utils/sleep.d/45pcmcia</tt>, you can do this easily by calling<br />
touch /etc/pm/sleep.d/45pcmcia<br />
Do not set the executable bit on that dummy-hook.<br />
<br />
== Creating your own hooks ==<br />
If you want to do something specific to your setup during suspend / hibernate, then you can easily put your own hook into <tt>/etc/pm/hooks</tt>. The hooks in this directory will be called in alphabetic order during suspend (that's the reason their names all start with 2 digits, to make the ordering explicit) and in the reverse order during resume.<br />
<br />
I'm showing a pretty useless demonstration hook here, that will just put some informative lines into your logfile:<br />
<br />
#!/bin/bash<br />
case $1 in<br />
hibernate)<br />
echo "Hey guy, we are going to suspend to disk!"<br />
;;<br />
suspend)<br />
echo "Oh, this time we're doing a suspend to RAM. Cool!"<br />
;;<br />
thaw)<br />
echo "oh, suspend to disk is over, we are resuming..."<br />
;;<br />
resume)<br />
echo "hey, the suspend to RAM seems to be over..."<br />
;;<br />
*) echo "somebody is calling me totally wrong."<br />
;;<br />
esac<br />
<br />
Put this into /etc/pm/sleep.d/66dummy, do a <tt>chmod +x /etc/pm/sleep.d/66dummy</tt> and it will spew some useless lines during suspend / resume.<br />
<br />
'''''Warning:''' All the hooks run as user root. This means that you need to be careful when creating temporary files, check that the PATH variable is set correctly etc. to avoid security problems.''<br />
<br />
= How it Works =<br />
The concept is quite easy: the main script (<tt>pm-action</tt>, called via symlinks as either <tt>pm-suspend</tt>, <tt>pm-hibernate</tt> or <tt>pm-suspend-hybrid</tt>) executes so-called "hooks", executable scripts, in the alphabetical sorted order with the parameter <tt>suspend</tt> (suspend to RAM) or <tt>hibernate</tt> (suspend to disk).<br />
Once all hooks are done, it puts the machine to sleep. After the machine has woken up again, all those hooks are executed in reverse order with the parameter <tt>resume</tt> (resume from RAM) or <tt>thaw</tt> (resume from disk).<br />
The hooks do various stuff, for example preparing the bootloader, stopping the bluetooth subsystem or unloading of critical modules.<br />
<br />
Both pm-suspend and pm-hibernate are usually called from HAL, initiated by desktop applets as gnome-power-manager or kpowersave.<br />
<br />
'''''Note:''' <tt>suspend-hybrid</tt> is a placeholder right now, it is not completely implemented.''<br />
<br />
There is also the possibility to set the machine into high-power and low-power mode, the command <tt>pm-powersave</tt> is used with an additional parameter of <tt>true</tt> or <tt>false</tt>. It works basically the same as the suspend framework.<br />
<br />
The hooks for suspend are placed in<br />
* <tt>/usr/lib/pm-utils/sleep.d</tt> (distribution / package provided hooks)<br />
* <tt>/etc/pm/sleep.d</tt> (hooks added by the system administrator)<br />
<br />
The hooks for the power state are placed in <br />
* <tt>/usr/lib/pm-utils/power.d</tt> (distribution / package provided hooks)<br />
* <tt>/etc/pm/power.d</tt> (hooks added by the system administrator)<br />
<br />
Hooks in <tt>/etc/pm/</tt> take precedence over those in <tt>/usr/lib/pm-utils/</tt>, so the system administrator can override the defaults provided by the distribution.<br />
<br />
= Troubleshooting =<br />
If suspend or hibernate did not work correctly, you will probably find some information in the logfile '''<tt>/var/log/pm-suspend.log</tt>''', for example which hooks were run and what the output of them was.<br />
<br />
= Tips and Tricks / FAQ =<br />
== Triggering suspend manually ==<br />
If you want to trigger suspend manually for debugging, without using HAL and other frameworks, call '''<tt>pm-suspend</tt>''' or '''<tt>pm-hibernate</tt>''' as root.<br />
<br />
== Using another sleep backend (like uswsusp) ==<br />
create a file with a SLEEP_MODULE variable, like this:<br />
$ cat /etc/pm/config.d/module <br />
SLEEP_MODULE=uswsusp<br />
I don't know but you may have to chmod +x it.<br />
to list available modules, use:<br />
pacman -Ql pm-utils | grep module.d<br />
<br />
== Having the dreaded hd power management level automatically set again on resume ==<br />
do it like this:<br />
$ cat /etc/pm/sleep.d/50-hdparm_pm <br />
#!/bin/dash<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/sda > /dev/null<br />
fi<br />
<br />
<br />
== Restarting the mouse ==<br />
On some laptops the mouse will hang after an otherwise successful suspend. One way to remedy this is to force a reinit of the PS/2 driver (here <tt>i8042</tt>) through a hook in <tt>/etc/pm/hooks</tt> (see [[#Creating_your_own_hooks|hooks]])<br />
<br />
#!/bin/sh <br />
echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind<br />
echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind<br />
''Source: --Esox81 20:30, 22 August 2007 (UTC)''<br />
<br />
== It seems to not do anything / where is the logfile ==<br />
If it seem to not do anything when called via the desktop applets, then try to call <tt>pm-suspend</tt> or <tt>pm-hibernate</tt> [[#Triggering_suspend_manually|manually from a root shell in a terminal]]. Maybe you'll already get some output that will point you to the problem.<br />
The suspend scripts also write a [[#Troubleshooting|logfile at '''<tt>/var/log/pm-suspend.log</tt>''']].<br />
<br />
== Add sleep modes to Openbox menu ==<br />
Openbox users can add the new scripts as additional shutdown options within the Openbox menu by adding the items to a new or existing sub-menu in <tt>~/.config/openbox/menu.xml</tt>, for example:<br />
<menu id="64" label="Shutdown"><br />
<item label="Lock"> <action name="Execute"> <execute>xscreensaver-command -lock</execute> </action> </item><br />
<item label="Logout"> <action name="Exit"/> </item><br />
<item label="Reboot"> <action name="Execute"> <execute>sudo shutdown -r now</execute> </action> </item><br />
<item label="Poweroff"> <action name="Execute"> <execute>sudo shutdown -h now </execute> </action> </item><br />
'''''<item label="Hibernate"> <action name="Execute"> <execute>sudo pm-hibernate</execute> </action> </item>'''''<br />
'''''<item label="Suspend"> <action name="Execute"> <execute>sudo pm-suspend</execute> </action> </item>'''''<br />
</menu><br />
<br />
= Other Resources =<br />
[[Cpufrequtils]] - CPU Frequency Scaling and CPU Power schemes<br /><br />
[[SpeedStep]] - More information on CPU frequency scaling (some of which is obsolete)<br />
<br />
<br />
= Credits =<br />
''This wiki entry was originally sourced from the [http://en.opensuse.org/Pm-utils OpenSUSE Wiki] (Licensed under GPL). A big thank you goes to the <tt>pm-utils</tt> developers and documenters for their time.''</div>Lloekihttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=39848Xorg Input Hotplugging2008-04-15T17:28:50Z<p>Lloeki: /* Building and installing a HAL-enabled Xorg server */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tieing X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
<br />
== Current XInput status upstream ==<br />
<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
<br />
== Current status in Arch==<br />
<br />
As of currently, Arch's xorg-server 1.4.0.90-9, Xorg server hald support is disabled. This is unlikely to change soon. See the [http://archlinux.org/pipermail/arch-dev-public/2008-March/005248.html mailing list].<br />
If you seek help or details, take a look at this [http://bbs.archlinux.org/viewtopic.php?pid=348585 forum thread].<br />
<br />
<br />
== Building and installing a HAL-enabled Xorg server ==<br />
<br />
Get the xorg-xserver PKGBUILD+other files from abs the usual way (see [[ABS]] howto if necessary), and alter ./configure options in the PKGBUILD:<br />
* check that you have --disable-dmx (dmx is not yet compatible with new device system)<br />
* check that you have --disable-xprint (it should be so already, compile will currently fail with xprint enabled)<br />
* remove --disable-config-hal (obviously)<br />
<br />
then build and install the resulting package (pacman -U).<br />
<br />
We have to allow the xorg server to listen to hald via dbus. So, create this file (or copy it from the xorg-server source):<br />
<br />
<br />
$ cat /etc/dbus-1/system.d/xorg-server.conf <br />
<!DOCTYPE busconfig PUBLIC<br />
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<busconfig><br />
<policy context="default"><br />
<allow own="org.x.config.display0"/><br />
<allow send_destination="org.x.config.display0"/><br />
<allow send_interface="org.x.config.display0"/><br />
<allow own="org.x.config.display1"/><br />
<allow send_destination="org.x.config.display1"/><br />
<allow send_interface="org.x.config.display1"/><br />
</policy><br />
</busconfig><br />
<br />
evdev devices not only include mice but also keyboards, and for some reason once the server queries hal it will unfortunately discard any xorg.conf keyboard configuration you may have (I suppose it does not know what to do with the xorg.conf info, so it prioritizes the hal one instead of merging. what's more it maintains a consistent state with hal, in the event another app queries hal for the same info). So let's inform hal of the real layout:<br />
Code:<br />
<br />
$ cat /etc/hal/fdi/policy/11-kb.fdi <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.product" string="AT Translated Set 2 keyboard"><br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
Of course, change the match key to something relevant for you (use gnome-device-manager with view->device properties enabled to easily browse the hal tree, or grep lshal output), change 'fr' to your layout. You may also want to merge other keys like input.kxb.variant or input.kxb.model.<br />
<br />
Now for the last bit. Historically, the Xorg server needs an always connected and unique CoreKeyboard and CorePointer, other extra devices merely sending so called Core events (it just looks so much like the /dev/input/mice trick to have multiple devices act like one). Usually you set them in xorg.conf. If there's none in the config, some recent Xorg server version allows for automatic finding of those Core devices by looking into /dev/input. Notably, it will always find /dev/input/mice and create a default ExplorerPS/2 mouse with it (which is bad for us as we want evdev), as it's a sink device where all mice send events in a restricted way (that's why input-evdev can't use it, and if you use it with input-mouse driver it'll lack many buttons, because of the PS/2 fallback). So let's get rid of it as its purpose was precisely to be a workaround for hotplugging, which we now have properly implemented.<br />
<br />
Add this in your xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AllowEmptyInput"<br />
EndSection<br />
<br />
Also, you will want to remove any input device from xorg.conf, except e.g your Synaptics touchpad (and other special drivers I may not be aware of), so that's any device whose driver should be 'mouse', or 'evdev', or 'keyboard'. Don't forget to remove both the input device section and the entry in server layout section. Be aware that those devices should thus be present at X startup to be taken into account.<br />
It should be possible to inform X about your devices via hal configuration, like for the keyboard, but since my Synaptics device is always attached, I left the config there.<br />
<br />
Now, restart X, plug and unplug your mouse at will, and observe /var/log/Xorg.0.log output as it loses and sets your input devices up.<br />
<br />
In hope this helps someone, as I had a hard time gathering all this information. Documentation is really lacking and/or outdated...<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
* My mouse is jerky/uncontrollable in SDL apps/games! WTF?<br />
<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
* What did the .fdi look like when xorg-server had hal enabled in testing repo?<br />
<br />
Here it is. This is a good sample as how hal key matching works, and how you can set some keys:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<!-- FIXME: Support tablets too. --><br />
<match key="info.capabilities" contains="input.mouse"><br />
<merge key="input.x11_driver" type="string">mouse</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
</match><br />
</match><br />
<br />
<match key="info.capabilities" contains="input.keys"><br />
<merge key="input.xkb.rules" type="string">base</merge><br />
<br />
<!-- If we're using Linux, we use evdev by default (falling back to<br />
keyboard otherwise). --><br />
<merge key="input.x11_driver" type="string">keyboard</merge><br />
<merge key="input.xkb.model" type="string">pc105</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
<merge key="input.xkb.model" type="string">evdev</merge><br />
</match><br />
<br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
<br />
<merge key="input.xkb.variant" type="string" /><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
* How can I make mouse button XYZ do FOO?<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=39653Xorg Input Hotplugging2008-04-07T16:04:30Z<p>Lloeki: /* FAQ/Troubleshooting */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tieing X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
<br />
== Current XInput status upstream ==<br />
<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
<br />
== Current status in Arch==<br />
<br />
As of currently, Arch's xorg-server 1.4.0.90-9, Xorg server hald support is disabled. This is unlikely to change soon. See the [http://archlinux.org/pipermail/arch-dev-public/2008-March/005248.html mailing list].<br />
If you seek help or details, take a look at this [http://bbs.archlinux.org/viewtopic.php?pid=348585 forum thread].<br />
<br />
<br />
== Building and installing a HAL-enabled Xorg server ==<br />
<br />
Get the xorg-xserver PKGBUILD+other files from abs the usual way (see [[ABS]] howto if necessary), and alter ./configure options in the PKGBUILD:<br />
* change --enable-dmx to --disable-dmx (dmx is not yet compatible with new device system)<br />
* check that you have --disable-xprint (it should be so already, compile will currently fail with xprint enabled)<br />
* remove --disable-config-hal (obviously)<br />
<br />
then build and install the resulting package (pacman -U).<br />
<br />
We have to allow the xorg server to listen to hald via dbus. So, create this file (or copy it from the xorg-server source):<br />
<br />
<br />
$ cat /etc/dbus-1/system.d/xorg-server.conf <br />
<!DOCTYPE busconfig PUBLIC<br />
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<busconfig><br />
<policy context="default"><br />
<allow own="org.x.config.display0"/><br />
<allow send_destination="org.x.config.display0"/><br />
<allow send_interface="org.x.config.display0"/><br />
<allow own="org.x.config.display1"/><br />
<allow send_destination="org.x.config.display1"/><br />
<allow send_interface="org.x.config.display1"/><br />
</policy><br />
</busconfig><br />
<br />
evdev devices not only include mice but also keyboards, and for some reason once the server queries hal it will unfortunately discard any xorg.conf keyboard configuration you may have (I suppose it does not know what to do with the xorg.conf info, so it prioritizes the hal one instead of merging. what's more it maintains a consistent state with hal, in the event another app queries hal for the same info). So let's inform hal of the real layout:<br />
Code:<br />
<br />
$ cat /etc/hal/fdi/policy/11-kb.fdi <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.product" string="AT Translated Set 2 keyboard"><br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
Of course, change the match key to something relevant for you (use gnome-device-manager with view->device properties enabled to easily browse the hal tree, or grep lshal output), change 'fr' to your layout. You may also want to merge other keys like input.kxb.variant or input.kxb.model.<br />
<br />
Now for the last bit. Historically, the Xorg server needs an always connected and unique CoreKeyboard and CorePointer, other extra devices merely sending so called Core events (it just looks so much like the /dev/input/mice trick to have multiple devices act like one). Usually you set them in xorg.conf. If there's none in the config, some recent Xorg server version allows for automatic finding of those Core devices by looking into /dev/input. Notably, it will always find /dev/input/mice and create a default ExplorerPS/2 mouse with it (which is bad for us as we want evdev), as it's a sink device where all mice send events in a restricted way (that's why input-evdev can't use it, and if you use it with input-mouse driver it'll lack many buttons, because of the PS/2 fallback). So let's get rid of it as its purpose was precisely to be a workaround for hotplugging, which we now have properly implemented.<br />
<br />
Add this in your xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AllowEmptyInput"<br />
EndSection<br />
<br />
Also, you will want to remove any input device from xorg.conf, except e.g your Synaptics touchpad (and other special drivers I may not be aware of), so that's any device whose driver should be 'mouse', or 'evdev', or 'keyboard'. Don't forget to remove both the input device section and the entry in server layout section. Be aware that those devices should thus be present at X startup to be taken into account.<br />
It should be possible to inform X about your devices via hal configuration, like for the keyboard, but since my Synaptics device is always attached, I left the config there.<br />
<br />
Now, restart X, plug and unplug your mouse at will, and observe /var/log/Xorg.0.log output as it loses and sets your input devices up.<br />
<br />
In hope this helps someone, as I had a hard time gathering all this information. Documentation is really lacking and/or outdated...<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
* My mouse is jerky/uncontrollable in SDL apps/games! WTF?<br />
<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
* What did the .fdi look like when xorg-server had hal enabled in testing repo?<br />
<br />
Here it is. This is a good sample as how hal key matching works, and how you can set some keys:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<!-- FIXME: Support tablets too. --><br />
<match key="info.capabilities" contains="input.mouse"><br />
<merge key="input.x11_driver" type="string">mouse</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
</match><br />
</match><br />
<br />
<match key="info.capabilities" contains="input.keys"><br />
<merge key="input.xkb.rules" type="string">base</merge><br />
<br />
<!-- If we're using Linux, we use evdev by default (falling back to<br />
keyboard otherwise). --><br />
<merge key="input.x11_driver" type="string">keyboard</merge><br />
<merge key="input.xkb.model" type="string">pc105</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
<merge key="input.xkb.model" type="string">evdev</merge><br />
</match><br />
<br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
<br />
<merge key="input.xkb.variant" type="string" /><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
* How can I make mouse button XYZ do FOO?<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=39652Xorg Input Hotplugging2008-04-07T16:02:09Z<p>Lloeki: /* Building and installing a custom Xorg server */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tieing X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
<br />
== Current XInput status upstream ==<br />
<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
<br />
== Current status in Arch==<br />
<br />
As of currently, Arch's xorg-server 1.4.0.90-9, Xorg server hald support is disabled. This is unlikely to change soon. See the [http://archlinux.org/pipermail/arch-dev-public/2008-March/005248.html mailing list].<br />
If you seek help or details, take a look at this [http://bbs.archlinux.org/viewtopic.php?pid=348585 forum thread].<br />
<br />
<br />
== Building and installing a HAL-enabled Xorg server ==<br />
<br />
Get the xorg-xserver PKGBUILD+other files from abs the usual way (see [[ABS]] howto if necessary), and alter ./configure options in the PKGBUILD:<br />
* change --enable-dmx to --disable-dmx (dmx is not yet compatible with new device system)<br />
* check that you have --disable-xprint (it should be so already, compile will currently fail with xprint enabled)<br />
* remove --disable-config-hal (obviously)<br />
<br />
then build and install the resulting package (pacman -U).<br />
<br />
We have to allow the xorg server to listen to hald via dbus. So, create this file (or copy it from the xorg-server source):<br />
<br />
<br />
$ cat /etc/dbus-1/system.d/xorg-server.conf <br />
<!DOCTYPE busconfig PUBLIC<br />
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<busconfig><br />
<policy context="default"><br />
<allow own="org.x.config.display0"/><br />
<allow send_destination="org.x.config.display0"/><br />
<allow send_interface="org.x.config.display0"/><br />
<allow own="org.x.config.display1"/><br />
<allow send_destination="org.x.config.display1"/><br />
<allow send_interface="org.x.config.display1"/><br />
</policy><br />
</busconfig><br />
<br />
evdev devices not only include mice but also keyboards, and for some reason once the server queries hal it will unfortunately discard any xorg.conf keyboard configuration you may have (I suppose it does not know what to do with the xorg.conf info, so it prioritizes the hal one instead of merging. what's more it maintains a consistent state with hal, in the event another app queries hal for the same info). So let's inform hal of the real layout:<br />
Code:<br />
<br />
$ cat /etc/hal/fdi/policy/11-kb.fdi <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.product" string="AT Translated Set 2 keyboard"><br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
Of course, change the match key to something relevant for you (use gnome-device-manager with view->device properties enabled to easily browse the hal tree, or grep lshal output), change 'fr' to your layout. You may also want to merge other keys like input.kxb.variant or input.kxb.model.<br />
<br />
Now for the last bit. Historically, the Xorg server needs an always connected and unique CoreKeyboard and CorePointer, other extra devices merely sending so called Core events (it just looks so much like the /dev/input/mice trick to have multiple devices act like one). Usually you set them in xorg.conf. If there's none in the config, some recent Xorg server version allows for automatic finding of those Core devices by looking into /dev/input. Notably, it will always find /dev/input/mice and create a default ExplorerPS/2 mouse with it (which is bad for us as we want evdev), as it's a sink device where all mice send events in a restricted way (that's why input-evdev can't use it, and if you use it with input-mouse driver it'll lack many buttons, because of the PS/2 fallback). So let's get rid of it as its purpose was precisely to be a workaround for hotplugging, which we now have properly implemented.<br />
<br />
Add this in your xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AllowEmptyInput"<br />
EndSection<br />
<br />
Also, you will want to remove any input device from xorg.conf, except e.g your Synaptics touchpad (and other special drivers I may not be aware of), so that's any device whose driver should be 'mouse', or 'evdev', or 'keyboard'. Don't forget to remove both the input device section and the entry in server layout section. Be aware that those devices should thus be present at X startup to be taken into account.<br />
It should be possible to inform X about your devices via hal configuration, like for the keyboard, but since my Synaptics device is always attached, I left the config there.<br />
<br />
Now, restart X, plug and unplug your mouse at will, and observe /var/log/Xorg.0.log output as it loses and sets your input devices up.<br />
<br />
In hope this helps someone, as I had a hard time gathering all this information. Documentation is really lacking and/or outdated...<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
* My mouse is jerky/uncontrollable in SDL apps/games! WTF?<br />
<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
* What did the .fdi look like when xorg-server had hal enabled in testing repo?<br />
<br />
Here it is:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<!-- FIXME: Support tablets too. --><br />
<match key="info.capabilities" contains="input.mouse"><br />
<merge key="input.x11_driver" type="string">mouse</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
</match><br />
</match><br />
<br />
<match key="info.capabilities" contains="input.keys"><br />
<merge key="input.xkb.rules" type="string">base</merge><br />
<br />
<!-- If we're using Linux, we use evdev by default (falling back to<br />
keyboard otherwise). --><br />
<merge key="input.x11_driver" type="string">keyboard</merge><br />
<merge key="input.xkb.model" type="string">pc105</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
<merge key="input.xkb.model" type="string">evdev</merge><br />
</match><br />
<br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
<br />
<merge key="input.xkb.variant" type="string" /><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
* How can I make mouse button XYZ do FOO?<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=39651Xorg Input Hotplugging2008-04-07T16:00:20Z<p>Lloeki: New page: Category:X Server (English) Category:HOWTOs (English) {{i18n_links_start}} {{i18n_entry|English|Xorg_input_hotplugging}} {{i18n_links_end}} == Rationale == Historically, the X ...</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tieing X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
<br />
== Current XInput status upstream ==<br />
<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
<br />
== Current status in Arch==<br />
<br />
As of currently, Arch's xorg-server 1.4.0.90-9, Xorg server hald support is disabled. This is unlikely to change soon. See the [http://archlinux.org/pipermail/arch-dev-public/2008-March/005248.html mailing list].<br />
If you seek help or details, take a look at this [http://bbs.archlinux.org/viewtopic.php?pid=348585 forum thread].<br />
<br />
<br />
== Building and installing a custom Xorg server ==<br />
<br />
Get the xorg-xserver PKGBUILD+other files from abs the usual way (see [[ABS]] howto if necessary), and alter ./configure options in the PKGBUILD:<br />
* change --enable-dmx to --disable-dmx (dmx is not yet compatible with new device system)<br />
* check that you have --disable-xprint (it should be so already, compile will currently fail with xprint enabled)<br />
* remove --disable-config-hal (obviously)<br />
<br />
then build and install the resulting package (pacman -U).<br />
<br />
We have to allow the xorg server to listen to hald via dbus. So, create this file (or copy it from the xorg-server source):<br />
<br />
<br />
$ cat /etc/dbus-1/system.d/xorg-server.conf <br />
<!DOCTYPE busconfig PUBLIC<br />
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<busconfig><br />
<policy context="default"><br />
<allow own="org.x.config.display0"/><br />
<allow send_destination="org.x.config.display0"/><br />
<allow send_interface="org.x.config.display0"/><br />
<allow own="org.x.config.display1"/><br />
<allow send_destination="org.x.config.display1"/><br />
<allow send_interface="org.x.config.display1"/><br />
</policy><br />
</busconfig><br />
<br />
evdev devices not only include mice but also keyboards, and for some reason once the server queries hal it will unfortunately discard any xorg.conf keyboard configuration you may have (I suppose it does not know what to do with the xorg.conf info, so it prioritizes the hal one instead of merging. what's more it maintains a consistent state with hal, in the event another app queries hal for the same info). So let's inform hal of the real layout:<br />
Code:<br />
<br />
$ cat /etc/hal/fdi/policy/11-kb.fdi <br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.product" string="AT Translated Set 2 keyboard"><br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
Of course, change the match key to something relevant for you (use gnome-device-manager with view->device properties enabled to easily browse the hal tree, or grep lshal output), change 'fr' to your layout. You may also want to merge other keys like input.kxb.variant or input.kxb.model.<br />
<br />
Now for the last bit. Historically, the Xorg server needs an always connected and unique CoreKeyboard and CorePointer, other extra devices merely sending so called Core events (it just looks so much like the /dev/input/mice trick to have multiple devices act like one). Usually you set them in xorg.conf. If there's none in the config, some recent Xorg server version allows for automatic finding of those Core devices by looking into /dev/input. Notably, it will always find /dev/input/mice and create a default ExplorerPS/2 mouse with it (which is bad for us as we want evdev), as it's a sink device where all mice send events in a restricted way (that's why input-evdev can't use it, and if you use it with input-mouse driver it'll lack many buttons, because of the PS/2 fallback). So let's get rid of it as its purpose was precisely to be a workaround for hotplugging, which we now have properly implemented.<br />
<br />
Add this in your xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AllowEmptyInput"<br />
EndSection<br />
<br />
Also, you will want to remove any input device from xorg.conf, except e.g your Synaptics touchpad (and other special drivers I may not be aware of), so that's any device whose driver should be 'mouse', or 'evdev', or 'keyboard'. Don't forget to remove both the input device section and the entry in server layout section. Be aware that those devices should thus be present at X startup to be taken into account.<br />
It should be possible to inform X about your devices via hal configuration, like for the keyboard, but since my Synaptics device is always attached, I left the config there.<br />
<br />
Now, restart X, plug and unplug your mouse at will, and observe /var/log/Xorg.0.log output as it loses and sets your input devices up.<br />
<br />
In hope this helps someone, as I had a hard time gathering all this information. Documentation is really lacking and/or outdated...<br />
<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
* My mouse is jerky/uncontrollable in SDL apps/games! WTF?<br />
<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
* What did the .fdi look like when xorg-server had hal enabled in testing repo?<br />
<br />
Here it is:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<!-- FIXME: Support tablets too. --><br />
<match key="info.capabilities" contains="input.mouse"><br />
<merge key="input.x11_driver" type="string">mouse</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
</match><br />
</match><br />
<br />
<match key="info.capabilities" contains="input.keys"><br />
<merge key="input.xkb.rules" type="string">base</merge><br />
<br />
<!-- If we're using Linux, we use evdev by default (falling back to<br />
keyboard otherwise). --><br />
<merge key="input.x11_driver" type="string">keyboard</merge><br />
<merge key="input.xkb.model" type="string">pc105</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"<br />
string="Linux"><br />
<merge key="input.x11_driver" type="string">evdev</merge><br />
<merge key="input.xkb.model" type="string">evdev</merge><br />
</match><br />
<br />
<merge key="input.xkb.layout" type="string">fr</merge><br />
<br />
<merge key="input.xkb.variant" type="string" /><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
* How can I make mouse button XYZ do FOO?<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Uvesafb&diff=36929Uvesafb2008-02-11T11:15:36Z<p>Lloeki: /* The virtualizing daemon */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem foolish to emulate x86 code on a x86, but this is important if one wants to use the framebuffer code on other architectures (notably non-x86 ones). There is a package in the AUR for it, which includes an initcpio HOOK, with which you can use uvesafb with the custom archlinux kernel. Once you regenerate the initramfs. the v86d will be included in the initramfs.<br />
<br />
=Remove the kernel boot parameters=<br />
Just remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter is not needed because you can define the options for uvesafb in /etc/modprobe.conf, as with any other kernel module.<br />
<br />
=Recompile klibc=<br />
Although it works for some people, at the moment you usually also need to recompile klibc against a kernel tree including uvesafb. Just copy from your abs tree the folder of klibc (/var/abs/core/base/klibc). Edit the PKGBUILD: in the build function there is a line where the directory with the sources of the kernel is linked to ./linux in the directory where klibc is build. <br />
<br />
ln -sf /usr/src/linux-${_kver} linux<br />
<br />
The directory with the sources of the kernel is specified with the _kernver variable, which is defined in the preamble of the PKGBUILD. You can adjust the _kernver variable or, if your kernel resides outside the /usr/src path, modify the quoted so that it points to the right location. After that, just run 'makepkg -i' to repackage klibc and install the resulting package. This operation is needed only once and will not be needed at all once the kernel developers will have rebuilt the binary klibc against a 2.6.24 kernel. This is not possible at the moment, because some important packages (such as klibc-udev) fail to compile against klibc, if klibc has been compiled against a 2.6.24 kernel (follow [http://bugs.archlinux.org/task/9482 this bug] for details).<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reasom, 915resolution was created to patch the bios at boot time and allow the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution static==<br />
Compile 915 resolution statically (since it is going to be in an initramfs, it can not be linked to external libraries), with the following PKGBUILD:<br />
<br />
<pre><br />
pkgname=915resolution<br />
pkgver=0.5.3<br />
pkgrel=1<br />
pkgdesc="A tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets"<br />
arch=('i686' 'x86_64')<br />
url="http://www.geocities.com/stomljen"<br />
license=('custom')<br />
depends=('glibc')<br />
backup=(etc/conf.d/915resolution)<br />
source=(http://www.geocities.com/stomljen/$pkgname-$pkgver.tar.gz<br />
915resolution.rc.d<br />
915resolution.conf.d)<br />
md5sums=('ed287778a53d02c31a7a6a52bc146291'<br />
'4a5e9f60ba800883b361c9bb64ee0220'<br />
'4df864a584173398f79293014766d575')<br />
<br />
build() {<br />
cd $startdir/src/$pkgname-$pkgver<br />
export LDFLAGS="-s -static"<br />
make clean<br />
make || return 1<br />
unset LDFLAGS<br />
install -D -m755 915resolution $startdir/pkg/usr/sbin/915resolution<br />
install -m755 dump_bios $startdir/pkg/usr/sbin<br />
install -D -m755 ../915resolution.rc.d $startdir/pkg/etc/rc.d/915resolution<br />
install -D -m644 ../915resolution.conf.d $startdir/pkg/etc/conf.d/915resolution<br />
install -D -m644 LICENSE.txt $startdir/pkg/usr/share/licenses/915resolution/LICENSE.txt<br />
}<br />
</pre><br />
<br />
==915resolution hook==<br />
Write an initcpio hook for 915resolution. The following is /lib/initcpio/install/915resolution:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES="/usr/sbin/915resolution"<br />
FILES=""<br />
SCRIPT="915resolution"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This hook patches the video BIOS for widescreen displays<br />
HELPEOF<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/915resolution (adapt to your widescreen resolution):<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
==Uvesafb hook==<br />
Write an hook to load uvesafb. The following is /lib/initcpio/install/uvesafb:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES="uvesafb"<br />
SCRIPT="uvesafb"<br />
}<br />
<br />
help ()<br />
{<br />
echo "This hook loads uvesafb"<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/uvesafb:<br />
<br />
run_hook<br />
{<br />
/sbin/modprobe uvesafb<br />
}<br />
<br />
==V86d==<br />
Install v86d from the AUR<br />
<br />
==Modify modprobe.conf==<br />
Add to /etc/modprobe.conf the options for uvesafb, so that it uses the resolution you have added to the bios with 915resolution:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
==Binaries and files in mkinitcpio.conf==<br />
In mkinitcpio.conf, leave MODULES empty, and write:<br />
<br />
BINARIES="/sbin/modprobe /sbin/v86d"<br />
FILES="/etc/modprobe.conf"<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the uvesafb hook to HOOKS in mkinitcpio.conf. Put them after the hooks of the hard disk and before those for the keymap, the resume from suspension and the filesystems<br />
<br />
==Finalize==<br />
Regenerate your initcpio, reboot and enjoy your widescreen framebuffer.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Uvesafb&diff=36928Uvesafb2008-02-11T11:13:58Z<p>Lloeki: /* The virtualizing daemon */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem foolish to emulate x86 code on a x86, but this is important if one wants to easily use the framebuffer code on other architectures. There is a package in the AUR for it, which includes an initcpio HOOK, with which you can use uvesafb with the custom archlinux kernel. Once you regenerate the initramfs. the v86d will be included in the initramfs.<br />
<br />
=Remove the kernel boot parameters=<br />
Just remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter is not needed because you can define the options for uvesafb in /etc/modprobe.conf, as with any other kernel module.<br />
<br />
=Recompile klibc=<br />
Although it works for some people, at the moment you usually also need to recompile klibc against a kernel tree including uvesafb. Just copy from your abs tree the folder of klibc (/var/abs/core/base/klibc). Edit the PKGBUILD: in the build function there is a line where the directory with the sources of the kernel is linked to ./linux in the directory where klibc is build. <br />
<br />
ln -sf /usr/src/linux-${_kver} linux<br />
<br />
The directory with the sources of the kernel is specified with the _kernver variable, which is defined in the preamble of the PKGBUILD. You can adjust the _kernver variable or, if your kernel resides outside the /usr/src path, modify the quoted so that it points to the right location. After that, just run 'makepkg -i' to repackage klibc and install the resulting package. This operation is needed only once and will not be needed at all once the kernel developers will have rebuilt the binary klibc against a 2.6.24 kernel. This is not possible at the moment, because some important packages (such as klibc-udev) fail to compile against klibc, if klibc has been compiled against a 2.6.24 kernel (follow [http://bugs.archlinux.org/task/9482 this bug] for details).<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reasom, 915resolution was created to patch the bios at boot time and allow the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution static==<br />
Compile 915 resolution statically (since it is going to be in an initramfs, it can not be linked to external libraries), with the following PKGBUILD:<br />
<br />
<pre><br />
pkgname=915resolution<br />
pkgver=0.5.3<br />
pkgrel=1<br />
pkgdesc="A tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets"<br />
arch=('i686' 'x86_64')<br />
url="http://www.geocities.com/stomljen"<br />
license=('custom')<br />
depends=('glibc')<br />
backup=(etc/conf.d/915resolution)<br />
source=(http://www.geocities.com/stomljen/$pkgname-$pkgver.tar.gz<br />
915resolution.rc.d<br />
915resolution.conf.d)<br />
md5sums=('ed287778a53d02c31a7a6a52bc146291'<br />
'4a5e9f60ba800883b361c9bb64ee0220'<br />
'4df864a584173398f79293014766d575')<br />
<br />
build() {<br />
cd $startdir/src/$pkgname-$pkgver<br />
export LDFLAGS="-s -static"<br />
make clean<br />
make || return 1<br />
unset LDFLAGS<br />
install -D -m755 915resolution $startdir/pkg/usr/sbin/915resolution<br />
install -m755 dump_bios $startdir/pkg/usr/sbin<br />
install -D -m755 ../915resolution.rc.d $startdir/pkg/etc/rc.d/915resolution<br />
install -D -m644 ../915resolution.conf.d $startdir/pkg/etc/conf.d/915resolution<br />
install -D -m644 LICENSE.txt $startdir/pkg/usr/share/licenses/915resolution/LICENSE.txt<br />
}<br />
</pre><br />
<br />
==915resolution hook==<br />
Write an initcpio hook for 915resolution. The following is /lib/initcpio/install/915resolution:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES="/usr/sbin/915resolution"<br />
FILES=""<br />
SCRIPT="915resolution"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This hook patches the video BIOS for widescreen displays<br />
HELPEOF<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/915resolution (adapt to your widescreen resolution):<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
==Uvesafb hook==<br />
Write an hook to load uvesafb. The following is /lib/initcpio/install/uvesafb:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES="uvesafb"<br />
SCRIPT="uvesafb"<br />
}<br />
<br />
help ()<br />
{<br />
echo "This hook loads uvesafb"<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/uvesafb:<br />
<br />
run_hook<br />
{<br />
/sbin/modprobe uvesafb<br />
}<br />
<br />
==V86d==<br />
Install v86d from the AUR<br />
<br />
==Modify modprobe.conf==<br />
Add to /etc/modprobe.conf the options for uvesafb, so that it uses the resolution you have added to the bios with 915resolution:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
==Binaries and files in mkinitcpio.conf==<br />
In mkinitcpio.conf, leave MODULES empty, and write:<br />
<br />
BINARIES="/sbin/modprobe /sbin/v86d"<br />
FILES="/etc/modprobe.conf"<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the uvesafb hook to HOOKS in mkinitcpio.conf. Put them after the hooks of the hard disk and before those for the keymap, the resume from suspension and the filesystems<br />
<br />
==Finalize==<br />
Regenerate your initcpio, reboot and enjoy your widescreen framebuffer.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Uvesafb&diff=36927Uvesafb2008-02-11T11:13:34Z<p>Lloeki: /* The virtualizing daemon */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem stupid to emulate x86 code on a x86, but this is important if one wants to easily use the framebuffer code on other architectures. There is a package in the AUR for it, which includes an initcpio HOOK, with which you can use uvesafb with the custom archlinux kernel. Once you regenerate the initramfs. the v86d will be included in the initramfs.<br />
<br />
=Remove the kernel boot parameters=<br />
Just remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter is not needed because you can define the options for uvesafb in /etc/modprobe.conf, as with any other kernel module.<br />
<br />
=Recompile klibc=<br />
Although it works for some people, at the moment you usually also need to recompile klibc against a kernel tree including uvesafb. Just copy from your abs tree the folder of klibc (/var/abs/core/base/klibc). Edit the PKGBUILD: in the build function there is a line where the directory with the sources of the kernel is linked to ./linux in the directory where klibc is build. <br />
<br />
ln -sf /usr/src/linux-${_kver} linux<br />
<br />
The directory with the sources of the kernel is specified with the _kernver variable, which is defined in the preamble of the PKGBUILD. You can adjust the _kernver variable or, if your kernel resides outside the /usr/src path, modify the quoted so that it points to the right location. After that, just run 'makepkg -i' to repackage klibc and install the resulting package. This operation is needed only once and will not be needed at all once the kernel developers will have rebuilt the binary klibc against a 2.6.24 kernel. This is not possible at the moment, because some important packages (such as klibc-udev) fail to compile against klibc, if klibc has been compiled against a 2.6.24 kernel (follow [http://bugs.archlinux.org/task/9482 this bug] for details).<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reasom, 915resolution was created to patch the bios at boot time and allow the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution static==<br />
Compile 915 resolution statically (since it is going to be in an initramfs, it can not be linked to external libraries), with the following PKGBUILD:<br />
<br />
<pre><br />
pkgname=915resolution<br />
pkgver=0.5.3<br />
pkgrel=1<br />
pkgdesc="A tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets"<br />
arch=('i686' 'x86_64')<br />
url="http://www.geocities.com/stomljen"<br />
license=('custom')<br />
depends=('glibc')<br />
backup=(etc/conf.d/915resolution)<br />
source=(http://www.geocities.com/stomljen/$pkgname-$pkgver.tar.gz<br />
915resolution.rc.d<br />
915resolution.conf.d)<br />
md5sums=('ed287778a53d02c31a7a6a52bc146291'<br />
'4a5e9f60ba800883b361c9bb64ee0220'<br />
'4df864a584173398f79293014766d575')<br />
<br />
build() {<br />
cd $startdir/src/$pkgname-$pkgver<br />
export LDFLAGS="-s -static"<br />
make clean<br />
make || return 1<br />
unset LDFLAGS<br />
install -D -m755 915resolution $startdir/pkg/usr/sbin/915resolution<br />
install -m755 dump_bios $startdir/pkg/usr/sbin<br />
install -D -m755 ../915resolution.rc.d $startdir/pkg/etc/rc.d/915resolution<br />
install -D -m644 ../915resolution.conf.d $startdir/pkg/etc/conf.d/915resolution<br />
install -D -m644 LICENSE.txt $startdir/pkg/usr/share/licenses/915resolution/LICENSE.txt<br />
}<br />
</pre><br />
<br />
==915resolution hook==<br />
Write an initcpio hook for 915resolution. The following is /lib/initcpio/install/915resolution:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES="/usr/sbin/915resolution"<br />
FILES=""<br />
SCRIPT="915resolution"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This hook patches the video BIOS for widescreen displays<br />
HELPEOF<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/915resolution (adapt to your widescreen resolution):<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
==Uvesafb hook==<br />
Write an hook to load uvesafb. The following is /lib/initcpio/install/uvesafb:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES="uvesafb"<br />
SCRIPT="uvesafb"<br />
}<br />
<br />
help ()<br />
{<br />
echo "This hook loads uvesafb"<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/uvesafb:<br />
<br />
run_hook<br />
{<br />
/sbin/modprobe uvesafb<br />
}<br />
<br />
==V86d==<br />
Install v86d from the AUR<br />
<br />
==Modify modprobe.conf==<br />
Add to /etc/modprobe.conf the options for uvesafb, so that it uses the resolution you have added to the bios with 915resolution:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
==Binaries and files in mkinitcpio.conf==<br />
In mkinitcpio.conf, leave MODULES empty, and write:<br />
<br />
BINARIES="/sbin/modprobe /sbin/v86d"<br />
FILES="/etc/modprobe.conf"<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the uvesafb hook to HOOKS in mkinitcpio.conf. Put them after the hooks of the hard disk and before those for the keymap, the resume from suspension and the filesystems<br />
<br />
==Finalize==<br />
Regenerate your initcpio, reboot and enjoy your widescreen framebuffer.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Uvesafb&diff=36926Uvesafb2008-02-11T11:11:20Z<p>Lloeki: /* The virtualizing daemon */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. There is a package in the AUR for it, which includes an initcpio HOOK, with which you can use uvesafb with the custom archlinux kernel. Once you regenerate the initramfs. the v86d will be included in the initramfs.<br />
<br />
=Remove the kernel boot parameters=<br />
Just remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter is not needed because you can define the options for uvesafb in /etc/modprobe.conf, as with any other kernel module.<br />
<br />
=Recompile klibc=<br />
Although it works for some people, at the moment you usually also need to recompile klibc against a kernel tree including uvesafb. Just copy from your abs tree the folder of klibc (/var/abs/core/base/klibc). Edit the PKGBUILD: in the build function there is a line where the directory with the sources of the kernel is linked to ./linux in the directory where klibc is build. <br />
<br />
ln -sf /usr/src/linux-${_kver} linux<br />
<br />
The directory with the sources of the kernel is specified with the _kernver variable, which is defined in the preamble of the PKGBUILD. You can adjust the _kernver variable or, if your kernel resides outside the /usr/src path, modify the quoted so that it points to the right location. After that, just run 'makepkg -i' to repackage klibc and install the resulting package. This operation is needed only once and will not be needed at all once the kernel developers will have rebuilt the binary klibc against a 2.6.24 kernel. This is not possible at the moment, because some important packages (such as klibc-udev) fail to compile against klibc, if klibc has been compiled against a 2.6.24 kernel (follow [http://bugs.archlinux.org/task/9482 this bug] for details).<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reasom, 915resolution was created to patch the bios at boot time and allow the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution static==<br />
Compile 915 resolution statically (since it is going to be in an initramfs, it can not be linked to external libraries), with the following PKGBUILD:<br />
<br />
<pre><br />
pkgname=915resolution<br />
pkgver=0.5.3<br />
pkgrel=1<br />
pkgdesc="A tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets"<br />
arch=('i686' 'x86_64')<br />
url="http://www.geocities.com/stomljen"<br />
license=('custom')<br />
depends=('glibc')<br />
backup=(etc/conf.d/915resolution)<br />
source=(http://www.geocities.com/stomljen/$pkgname-$pkgver.tar.gz<br />
915resolution.rc.d<br />
915resolution.conf.d)<br />
md5sums=('ed287778a53d02c31a7a6a52bc146291'<br />
'4a5e9f60ba800883b361c9bb64ee0220'<br />
'4df864a584173398f79293014766d575')<br />
<br />
build() {<br />
cd $startdir/src/$pkgname-$pkgver<br />
export LDFLAGS="-s -static"<br />
make clean<br />
make || return 1<br />
unset LDFLAGS<br />
install -D -m755 915resolution $startdir/pkg/usr/sbin/915resolution<br />
install -m755 dump_bios $startdir/pkg/usr/sbin<br />
install -D -m755 ../915resolution.rc.d $startdir/pkg/etc/rc.d/915resolution<br />
install -D -m644 ../915resolution.conf.d $startdir/pkg/etc/conf.d/915resolution<br />
install -D -m644 LICENSE.txt $startdir/pkg/usr/share/licenses/915resolution/LICENSE.txt<br />
}<br />
</pre><br />
<br />
==915resolution hook==<br />
Write an initcpio hook for 915resolution. The following is /lib/initcpio/install/915resolution:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES="/usr/sbin/915resolution"<br />
FILES=""<br />
SCRIPT="915resolution"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This hook patches the video BIOS for widescreen displays<br />
HELPEOF<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/915resolution (adapt to your widescreen resolution):<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
==Uvesafb hook==<br />
Write an hook to load uvesafb. The following is /lib/initcpio/install/uvesafb:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES="uvesafb"<br />
SCRIPT="uvesafb"<br />
}<br />
<br />
help ()<br />
{<br />
echo "This hook loads uvesafb"<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/uvesafb:<br />
<br />
run_hook<br />
{<br />
/sbin/modprobe uvesafb<br />
}<br />
<br />
==V86d==<br />
Install v86d from the AUR<br />
<br />
==Modify modprobe.conf==<br />
Add to /etc/modprobe.conf the options for uvesafb, so that it uses the resolution you have added to the bios with 915resolution:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
==Binaries and files in mkinitcpio.conf==<br />
In mkinitcpio.conf, leave MODULES empty, and write:<br />
<br />
BINARIES="/sbin/modprobe /sbin/v86d"<br />
FILES="/etc/modprobe.conf"<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the uvesafb hook to HOOKS in mkinitcpio.conf. Put them after the hooks of the hard disk and before those for the keymap, the resume from suspension and the filesystems<br />
<br />
==Finalize==<br />
Regenerate your initcpio, reboot and enjoy your widescreen framebuffer.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Uvesafb&diff=36925Uvesafb2008-02-11T11:10:25Z<p>Lloeki: /* The regulating daemon */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
However, it needs a userspace virtualizing daemon, called v86d. There is a package in the AUR for it, which includes an initcpio HOOK, with which you can use uvesafb with the custom archlinux kernel. Once you regenerate the initramfs. the v86d will be included in the initramfs.<br />
<br />
=Remove the kernel boot parameters=<br />
Just remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter is not needed because you can define the options for uvesafb in /etc/modprobe.conf, as with any other kernel module.<br />
<br />
=Recompile klibc=<br />
Although it works for some people, at the moment you usually also need to recompile klibc against a kernel tree including uvesafb. Just copy from your abs tree the folder of klibc (/var/abs/core/base/klibc). Edit the PKGBUILD: in the build function there is a line where the directory with the sources of the kernel is linked to ./linux in the directory where klibc is build. <br />
<br />
ln -sf /usr/src/linux-${_kver} linux<br />
<br />
The directory with the sources of the kernel is specified with the _kernver variable, which is defined in the preamble of the PKGBUILD. You can adjust the _kernver variable or, if your kernel resides outside the /usr/src path, modify the quoted so that it points to the right location. After that, just run 'makepkg -i' to repackage klibc and install the resulting package. This operation is needed only once and will not be needed at all once the kernel developers will have rebuilt the binary klibc against a 2.6.24 kernel. This is not possible at the moment, because some important packages (such as klibc-udev) fail to compile against klibc, if klibc has been compiled against a 2.6.24 kernel (follow [http://bugs.archlinux.org/task/9482 this bug] for details).<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reasom, 915resolution was created to patch the bios at boot time and allow the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution static==<br />
Compile 915 resolution statically (since it is going to be in an initramfs, it can not be linked to external libraries), with the following PKGBUILD:<br />
<br />
<pre><br />
pkgname=915resolution<br />
pkgver=0.5.3<br />
pkgrel=1<br />
pkgdesc="A tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets"<br />
arch=('i686' 'x86_64')<br />
url="http://www.geocities.com/stomljen"<br />
license=('custom')<br />
depends=('glibc')<br />
backup=(etc/conf.d/915resolution)<br />
source=(http://www.geocities.com/stomljen/$pkgname-$pkgver.tar.gz<br />
915resolution.rc.d<br />
915resolution.conf.d)<br />
md5sums=('ed287778a53d02c31a7a6a52bc146291'<br />
'4a5e9f60ba800883b361c9bb64ee0220'<br />
'4df864a584173398f79293014766d575')<br />
<br />
build() {<br />
cd $startdir/src/$pkgname-$pkgver<br />
export LDFLAGS="-s -static"<br />
make clean<br />
make || return 1<br />
unset LDFLAGS<br />
install -D -m755 915resolution $startdir/pkg/usr/sbin/915resolution<br />
install -m755 dump_bios $startdir/pkg/usr/sbin<br />
install -D -m755 ../915resolution.rc.d $startdir/pkg/etc/rc.d/915resolution<br />
install -D -m644 ../915resolution.conf.d $startdir/pkg/etc/conf.d/915resolution<br />
install -D -m644 LICENSE.txt $startdir/pkg/usr/share/licenses/915resolution/LICENSE.txt<br />
}<br />
</pre><br />
<br />
==915resolution hook==<br />
Write an initcpio hook for 915resolution. The following is /lib/initcpio/install/915resolution:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES="/usr/sbin/915resolution"<br />
FILES=""<br />
SCRIPT="915resolution"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This hook patches the video BIOS for widescreen displays<br />
HELPEOF<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/915resolution (adapt to your widescreen resolution):<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
==Uvesafb hook==<br />
Write an hook to load uvesafb. The following is /lib/initcpio/install/uvesafb:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES="uvesafb"<br />
SCRIPT="uvesafb"<br />
}<br />
<br />
help ()<br />
{<br />
echo "This hook loads uvesafb"<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/uvesafb:<br />
<br />
run_hook<br />
{<br />
/sbin/modprobe uvesafb<br />
}<br />
<br />
==V86d==<br />
Install v86d from the AUR<br />
<br />
==Modify modprobe.conf==<br />
Add to /etc/modprobe.conf the options for uvesafb, so that it uses the resolution you have added to the bios with 915resolution:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
==Binaries and files in mkinitcpio.conf==<br />
In mkinitcpio.conf, leave MODULES empty, and write:<br />
<br />
BINARIES="/sbin/modprobe /sbin/v86d"<br />
FILES="/etc/modprobe.conf"<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the uvesafb hook to HOOKS in mkinitcpio.conf. Put them after the hooks of the hard disk and before those for the keymap, the resume from suspension and the filesystems<br />
<br />
==Finalize==<br />
Regenerate your initcpio, reboot and enjoy your widescreen framebuffer.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Uvesafb&diff=36924Uvesafb2008-02-11T11:09:27Z<p>Lloeki: /* Recompile klibc */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The regulating daemon=<br />
However, it needs a userspace regulating daemon, called v86d. There is a package in the AUR for it, which includes an initcpio HOOK, with which you can use uvesafb with the custom archlinux kernel. Once you regenerate the initramfs. the v86d will be included in the initramfs. <br />
<br />
=Remove the kernel boot parameters=<br />
Just remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter is not needed because you can define the options for uvesafb in /etc/modprobe.conf, as with any other kernel module.<br />
<br />
=Recompile klibc=<br />
Although it works for some people, at the moment you usually also need to recompile klibc against a kernel tree including uvesafb. Just copy from your abs tree the folder of klibc (/var/abs/core/base/klibc). Edit the PKGBUILD: in the build function there is a line where the directory with the sources of the kernel is linked to ./linux in the directory where klibc is build. <br />
<br />
ln -sf /usr/src/linux-${_kver} linux<br />
<br />
The directory with the sources of the kernel is specified with the _kernver variable, which is defined in the preamble of the PKGBUILD. You can adjust the _kernver variable or, if your kernel resides outside the /usr/src path, modify the quoted so that it points to the right location. After that, just run 'makepkg -i' to repackage klibc and install the resulting package. This operation is needed only once and will not be needed at all once the kernel developers will have rebuilt the binary klibc against a 2.6.24 kernel. This is not possible at the moment, because some important packages (such as klibc-udev) fail to compile against klibc, if klibc has been compiled against a 2.6.24 kernel (follow [http://bugs.archlinux.org/task/9482 this bug] for details).<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reasom, 915resolution was created to patch the bios at boot time and allow the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution static==<br />
Compile 915 resolution statically (since it is going to be in an initramfs, it can not be linked to external libraries), with the following PKGBUILD:<br />
<br />
<pre><br />
pkgname=915resolution<br />
pkgver=0.5.3<br />
pkgrel=1<br />
pkgdesc="A tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets"<br />
arch=('i686' 'x86_64')<br />
url="http://www.geocities.com/stomljen"<br />
license=('custom')<br />
depends=('glibc')<br />
backup=(etc/conf.d/915resolution)<br />
source=(http://www.geocities.com/stomljen/$pkgname-$pkgver.tar.gz<br />
915resolution.rc.d<br />
915resolution.conf.d)<br />
md5sums=('ed287778a53d02c31a7a6a52bc146291'<br />
'4a5e9f60ba800883b361c9bb64ee0220'<br />
'4df864a584173398f79293014766d575')<br />
<br />
build() {<br />
cd $startdir/src/$pkgname-$pkgver<br />
export LDFLAGS="-s -static"<br />
make clean<br />
make || return 1<br />
unset LDFLAGS<br />
install -D -m755 915resolution $startdir/pkg/usr/sbin/915resolution<br />
install -m755 dump_bios $startdir/pkg/usr/sbin<br />
install -D -m755 ../915resolution.rc.d $startdir/pkg/etc/rc.d/915resolution<br />
install -D -m644 ../915resolution.conf.d $startdir/pkg/etc/conf.d/915resolution<br />
install -D -m644 LICENSE.txt $startdir/pkg/usr/share/licenses/915resolution/LICENSE.txt<br />
}<br />
</pre><br />
<br />
==915resolution hook==<br />
Write an initcpio hook for 915resolution. The following is /lib/initcpio/install/915resolution:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES="/usr/sbin/915resolution"<br />
FILES=""<br />
SCRIPT="915resolution"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This hook patches the video BIOS for widescreen displays<br />
HELPEOF<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/915resolution (adapt to your widescreen resolution):<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
==Uvesafb hook==<br />
Write an hook to load uvesafb. The following is /lib/initcpio/install/uvesafb:<br />
<br />
<pre><br />
install ()<br />
{<br />
MODULES="uvesafb"<br />
SCRIPT="uvesafb"<br />
}<br />
<br />
help ()<br />
{<br />
echo "This hook loads uvesafb"<br />
}<br />
</pre><br />
<br />
The following is /lib/initcpio/hooks/uvesafb:<br />
<br />
run_hook<br />
{<br />
/sbin/modprobe uvesafb<br />
}<br />
<br />
==V86d==<br />
Install v86d from the AUR<br />
<br />
==Modify modprobe.conf==<br />
Add to /etc/modprobe.conf the options for uvesafb, so that it uses the resolution you have added to the bios with 915resolution:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
==Binaries and files in mkinitcpio.conf==<br />
In mkinitcpio.conf, leave MODULES empty, and write:<br />
<br />
BINARIES="/sbin/modprobe /sbin/v86d"<br />
FILES="/etc/modprobe.conf"<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the uvesafb hook to HOOKS in mkinitcpio.conf. Put them after the hooks of the hard disk and before those for the keymap, the resume from suspension and the filesystems<br />
<br />
==Finalize==<br />
Regenerate your initcpio, reboot and enjoy your widescreen framebuffer.</div>Lloekihttps://wiki.archlinux.org/index.php?title=ACPI_modules&diff=35597ACPI modules2008-01-25T23:58:29Z<p>Lloeki: /* How to select the correct ones */</p>
<hr />
<div>[[Category: Power management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|ACPI_modules}}<br />
{{i18n_entry|中文(简体)|ACPI_modules(acpi模块)}}<br />
{{i18n_links_end}}<br />
<br />
===ACPI modules===<br />
<br />
====Summary====<br />
Since kernel 2.6.20.7 acpi modules are all modularized, to avoid acpi issues that were reported on some machines.<br />
<br />
This is a small list and summary of kernel acpi modules, that enables special acpi functions or add information to /proc, that can be parsed by acpid for events or other monitoring applications.<br />
<br />
====Which modules are available?====<br />
* ac (power connector status) => autoloaded during boot initscripts-0.8-7!<br />
* asus-laptop (useful on asus/medion laptops)<br />
* battery (battery status) => autoloaded during boot initscripts-0.8-7!<br />
* bay (bay status)<br />
* button (catch button events, like LID or POWER BUTTON) => autoloaded during boot initscripts-0.8-7!<br />
* container (container status)<br />
* dock (docking station status)<br />
* fan (fan status) => autoloaded during boot initscripts-0.8-7<br />
* i2c_ec (EC SMBUs driver)<br />
* ibm_acpi (useful on ibm laptops) (thinkpad_acpi since 2.6.22)<br />
* processor (processor status) => built into kernel 2.6.20.7-2!<br />
* sbs (smart battery status)<br />
* thermal (status of thermal sensors) => built into kernel 2.6.20.7-2!<br />
* toshiba_acpi (useful for toshiba laptops)<br />
* video (status of video devices)<br />
<br />
complete list of your running kernel:<br />
ls -l /lib/modules/$(uname -r)/kernel/drivers/acpi<br />
<br />
====How to select the correct ones==== <br />
You have to try yourself which module works for your machine:<br />
modprobe <yourmodule><br />
then check if the module is supported on your hardware by using<br />
dmesg<br />
or<br />
/proc/acpi/<dir><br />
<br />
Add the working ones to your MODULES=() array in rc.conf<br />
<br />
On laptops, basically those ones should work:<br />
* ac<br />
* battery<br />
* button<br />
* fan<br />
<br />
On desktops/servers, basically those ones should work:<br />
* button<br />
<br />
====Updates since 2.6.24==== <br />
proc is being deprecated, so you will find the information again in sysfs, e.g for battery:<br />
/sys/class/power_supply/BAT0/</div>Lloekihttps://wiki.archlinux.org/index.php?title=Talk:64-bit_FAQ&diff=23535Talk:64-bit FAQ2007-04-30T08:20:48Z<p>Lloeki: New page: ===32 bits apps in Arch64=== Using_32-bit-applications_on_Arch64 mentions lib32-* being in community. Also, emul-* from gentoo are in the AUR. So maybe this should be updated: "Maybe we w...</p>
<hr />
<div>===32 bits apps in Arch64===<br />
Using_32-bit-applications_on_Arch64 mentions lib32-* being in community. Also, emul-* from gentoo are in the AUR.<br />
<br />
So maybe this should be updated: "Maybe we will place them into the AUR or community repo"</div>Lloekihttps://wiki.archlinux.org/index.php?title=Talk:Install_Arch_from_within_another_distro&diff=23526Talk:Install Arch from within another distro2007-04-29T18:25:16Z<p>Lloeki: </p>
<hr />
<div>Really useful page, as I can't boot the x86_64 voodoo cd for some reason, I booted the 0.7 one and followed this method to jump straight to current.<br />
<br />
The following step was useless to me:<br />
cd /dev<br />
mknod -m 660 console c 5 1<br />
mknod -m 660 null c 1 3<br />
This seems to be taken care of by filesystem package<br />
<br />
Also, on x86_64, after having installed grub, I had to do:<br />
cp /usr/lib/grub/i386-pc/* /boot/grub/'<br />
for 'grub' or 'grub-install' to work.</div>Lloekihttps://wiki.archlinux.org/index.php?title=Talk:Install_Arch_from_within_another_distro&diff=23525Talk:Install Arch from within another distro2007-04-29T18:21:08Z<p>Lloeki: New page: This step was useless to me (this seems to be taken care of by filesystem package): cd /dev mknod -m 660 console c 5 1 mknod -m 660 null c 1 3 On x86_64, after having installed grub, I ha...</p>
<hr />
<div>This step was useless to me (this seems to be taken care of by filesystem package):<br />
cd /dev<br />
mknod -m 660 console c 5 1<br />
mknod -m 660 null c 1 3<br />
<br />
On x86_64, after having installed grub, I had to do 'cp /usr/lib/grub/i386-pc/* /boot/grub/' for 'grub' or 'grub-install' to work.</div>Lloeki