Smokes your problems, coughs fresh air.

Tag: Gentoo (Page 1 of 2)

Configuring X input devices through HAL

When I went from X.org < 7.3 to X.org > 7.3, I had to make some changes to my X input configuration.

First of all, I had to replace x11-drivers/synaptics (http://web.telia.com/~u89404340/touchpad/) with the newer x11-drivers/xf86-input-synaptics, which is automatically installed if you set INPUT_DEVICES="${INPUT_DEVICES} synaptics" or if you add “x11-base/xorg-server input_devices_synaptics” to /etc/portage/package.use.

Starting with X.org 7.3, you’re supposed to use HAL for all the X input configuration. All the "InputDevice" sections have to be removed from xorg.conf (and of course the references in "ServerLayout"). If you don’t want this, you can add the following options:

Section "ServerFlags"
  Option "AllowEmptyInput" "off"
  Option "AutoEnableDevices" "off"
EndSection

I chose HAL. I wanted to replicate the following settings using HAL.

Section "InputDevice"
    Identifier "Keyboard1"
    Driver     "kbd"
    Option "AutoRepeat" "500 30"
    Option "XkbRules"  "xorg"
    Option "XkbModel"  "thinkpadintl"
    Option "XkbLayout" "us"
    Option "XkbOptions"        "ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e"
EndSection
 
Section "InputDevice"
    Identifier "Synaptics Touchpad"
    Driver     "synaptics"
    Option "SendCoreEvents" "true"
    Option "Device" "/etc/psaux"
    Option "Protocol"    "auto-dev"    # Auto detect
#    Option "TouchpadOff" "1" #Uncomment if you just want to disable the touchpad and use only the trackpoint
#    Option "HorizScrollDelta" "0" #Why is this in here by default. By Gods, it kill horizontal scrolling!
    Option "RightEdge" "5500" #This is a little bigger than the default narrowing the scroll region
    Option "BottomEdge" "4500" #This is a little bigger than the default narrowing the scroll region
    Option "RTCornerButton" "0" #disable Right Top corner "button" 
    Option "RBCornerButton" "0" #disable Right Top corner "button" 
    Option "SHMConfig" "on" #this allows configuration of the touchpad using qsynaptics, synclient, or what have you
EndSection

The keyboard part was easy. I copied /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy/99-keymap.fdi and made a few adjustments:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>
 
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">xorg</merge>
 
      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.xkb.model" type="string">thinkpadintl</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>
 
      <merge key="input.xkb.layout" type="string">us</merge>
      <merge key="input.xkb.variant" type="string" />
      <merge key="input.xkb.autoRepeat" type="string">500 30</merge>
      <merge key="input.xkb.options" type="string">ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e</merge>
    </match>
  </device>
</deviceinfo>

The Touchpad configuration was a little more involving, because I added a few options which, before, I didn’t know the thing supported. 99-x11-synaptics.fdi:

<?xml version="1.0" encoding="ISO-8859-1"?>
 
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
 
    <merge key="input.x11_driver" type="string">synaptics</merge>
    <!-- Arbitrary options can be passed to the driver using
         the input.x11_options property since xorg-server-1.5. -->
 
    <!-- Switch on shared memory, enables the driver to be configured at runtime -->
    <!-- This allows configuration of the touchpad using qsynaptics, synclient, or what have you -->
    <merge key="input.x11_options.SHMConfig" type="string">on</merge>
 
    <!-- Enable vertical scrolling by dragging your finger along the right edge -->
    <merge key="input.x11_options.VertEdgeScroll" type="string">1</merge>
 
    <!-- Enable horizontal scrolling by dragging your finger along the left edge -->
    <merge key="input.x11_options.HorizEdgeScroll" type="string">1</merge>
 
    <!-- This is a little bigger than the default narrowing the scroll region -->
    <merge key="input.x11_options.RightEdge" type="string">5500</merge>
 
    <!-- This is a little bigger than the default narrowing the scroll region -->
    <merge key="input.x11_options.BottomEdge" type="string">4500</merge>
 
    <!-- disable Right Top corner "button" -->
    <merge key="input.x11_options.RTCornerButton" type="string">0</merge>
 
    <!-- disable Right Bottom corner "button" -->
    <merge key="input.x11_options.RBCornerButton" type="string">0</merge>
 
    <!-- Enable vertical scrolling when dragging with two fingers anywhere on the touchpad -->
    <merge key="input.x11_options.VertTwoFingerScroll" type="string">1</merge>
 
    <!-- Enable horizontal scrolling when dragging with two fingers anywhere on the touchpad -->
    <merge key="input.x11_options.HorizTwoFingerScroll" type="string">1</merge>
 
    <!-- Enable tapping to emulate mouse buttons -->
    <merge key="input.x11_options.TapButton1" type="string">1</merge>
    <merge key="input.x11_options.TapButton2" type="string">2</merge>
    <merge key="input.x11_options.TapButton3" type="string">3</merge>
 
    <!-- Maximum movement of the finger for detecting a tap -->
    <merge key="input.x11_options.MaxTapMove" type="string">221</merge>
 
    <!-- For other possible options, check CONFIGURATION DETAILS in synaptics man page -->
</match>
</device>
</deviceinfo>

I’m still not completely satisfied with the Touchpad configuration (actually less so than before I started messing with HAL), so I wrote a little tool to be able to mess around with my configuration a little bit easier.

Introducing synclient-sync

With SHMConfig on, you can use the synclient program to make changes to the touchpad configuration without having to restart X. I decided that it would be handy if I could utilize this to test out changes I made to the HAL config file without having to reload it, so I wrote a little script which detects the differences between the current (live) configuration and the configuration in the HAL .fdi file. The running configuration is then updated to reflect the changes in this file. (Newer versions of the script can be found on GitHub)

#!/bin/bash
 
HAL_FILE=/etc/hal/fdi/policy/99-x11-synaptics.fdi
 
VERBOSITY_LEVEL=2
 
usage()
{
    cat <<EOF
Usage: $0 options
 
OPTIONS:
--verbosity [level] Control the level of output processed by the script.
Level 0: No output at all
Level 1: Only output changed options
Level 2: Only output options the configuration file
Level 3: Output all options
--verbose Shortcut verbosity level 3
- Show this
EOF
 
    1
}
 
options_from_hal_file()
{
    HAL_SED_FILTER='s%^\s*<merge\s*key="input\.x11_options\.\(.*\?\)"\s*type="string">\(.*\)</merge>%\1=\2%'
    cat $HAL_FILE \
        | grep '<merge key="input.x11_options.' \
        | grep -v 'SHMConfig' \
        | sed -e $HAL_SED_FILTER
}
 
from()
{
     synclient -l \
        | grep '=' \
        | sed -e 's/\s//g' \
        | option;
key= $option|cut -f 1 -d '='`
            old_val= $option|cut -f 2 -d '='`
            new_val=`options_from_hal_file|grep $key|cut -f 2 -d '='`
 
            [ -z $new_val ];
                [ $VERBOSITY_LEVEL == 3 ] && -e "\e[1;30m$key = $old_val\e[0m"
            [ $old_val != $new_val ];
                [ $VERBOSITY_LEVEL -ge 1 ] && -e "\e[1m$key = \e[1;31m$old_val \e[1;4;32m$new_val\e[0m"
                synclient "$key=$new_val"
            # The HAL file and the life configuration are in sync
                [ $VERBOSITY_LEVEL -ge 2 ] && -e "\e[1m$key = \e[4m$new_val\e[0m"
           
}
 
do_from=0 [ $# -gt 0 ]; do
"$1"
        --from-hal)
            do_from=1
            ;;
        --verbose)
            VERBOSITY_LEVEL=3
            ;;
        --verbosity)
            VERBOSITY_LEVEL=$2
           
            ;;
        -)
            usage
            ;;
   
  [ $do_from == 1 ];
from
usage
 
# vim: set shiftwidth=4 tabstop=4 expandtab: 

References

Native execution of Windows programs on Linux

When I installed this laptop last year, I was pleasantly surprised by the performance of vanilla Wine (and Gentoo’s default Wine configuration). At that time, my only memory of Wine was that getting anything useful to work took work and that your best bet to get anything working was to install CrossOver Office. Things change and in the meantime Wine has even come to version 1.0.

I want to write down what I had to do to be able to execute Windows executables as if they are Linux native. This can be done thanks to Linux’ support for misc. binaries.

First, you have to enable CONFIG_BINFMT_MISC in your kernel configuration. If it was configured as a module, run /sbin/modprobe binfmt_misc.

Then you have to register the appropriate binary formats:

':windows:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register

That’s it. Of course, the .exe files need to have their executable bit set:

chmod u+x program.exe

Done.

Impossible to fix file collision when upgrading qt 4.3 to 4.5

I’m trying to upgrade my qt 4.3 to 4.5. Version 4.5 seems to be split up in several ebuils, one of which is qt-dbus. When trying to install qt-dbus, it says that the files conflict with qt-4.3. This is only normal, because in version 4.3, the files did belong to qt.

The thing is, some time ago, collision protection was disabled by default, which I thought made sense because when I tried enabling it, I’d get errors like these all the time. I disabled it for now (by putting “-collision-protect -protect-owned” in the FEATURES variable in make.conf), to be able to install Qt, but because it is enabled by default, I’d rather not keep it disabled.

(Text was copied from the post I made on the Gentoo forum about it.)

Really enabling portage compile cache

I always thought I had portage’s compile cache enabled, but upon recent inspection, it appears that I didn’t. What was missing, was the package dev-util/ccache. I also increased the cache size to 2 GB, as per the Gentoo documentation.

I noticed this because recently, portage started saying this:

!!! Directory does not exist: '/usr/lib/ccache/bin'
!!! Disabled FEATURES='ccache'

Gentoo update: system

This Gentoo box needs upgrading badly. I started this in February, so perhaps it’s time to continue.

Trying to update the world profile causes a few too many problems, so I start with updating everything in the system profile:

# emerge --update --deep --newuse system

sys-apps/man-pages

The first blockage of the day is “sys-apps/man-pages-3” that is blocking “sys-apps/man-pages-posix-2003a“. The latter is pulled in by “sys-apps/man-pages-posix“, which in turn is required by “sys-apps/man-pages-3.20“.

Somehow, unmerging “sys-apps/man-pages” resolved this blockage:

# emerge --unmerge sys-apps/man-pages

I just had to ignore a few warnings about the package being part of my system profile and I could reissue the system update command. The unmerged package is neatly remerged.

# emerge --update --deep --newuse system

This command started merging 99 packages. The only interruption left in this process was caused by the savedconfig use flag which made the busybox ebuild fail.

Gentoo update: Portage configuration confusion

During the first gentoo update session for this machine, I didn’t get very far. I already mentioned the problem I had with e2fsprogs, but this was not the first or the last problem that I had.

Until a few moments ago, I actually thought I made a bit of a fuck-up. I was meaning to make regular snapshots of /etc/portage files for a while now, because I was always just an echo something >> /etc/portage/package.keywords with one >-symbol too few away from destroying my configuration. Despite this fear, I thought I had already started deleting entries from /etc/portage/package.keywords and /etc/portage/package.unmask without backing up first.

Luckily, it turns out that I did make a dated copy of /etc/portage/package.keywords before starting on my modifications. I didn’t do so for /etc/portage/package.unmask, but I recovered a recent enough version from a recent full system rsync backup. So, everything is good. Still, I’m glad that I now use Git to track all changes in /etc/. All this goes to show that my methods are sometimes a bit more organized than my mind, which, I suppose, is a good thing. 😕

The point of this post—yes, there is a point—the point is that once you start mixing stable and unstable stuff, your system becomes, ehm, unstable. I have this huge amount of crap already in /etc/portage to cater to my wish to run stuff that I know to be quite stable but that isn’t yet marked as such in the Gentoo porttree. Now, after many months, I want to remove everything from package.keywords and package.unmask that is no longer necessary.

I was going to write about all the complicated upgrades, downgrades and conflicts suggested by Portage (mostly related to me removing KDE 4 stuff from package.keywords and package.unmask), because I was confused about what changes I had made. With the relevant backups readily available for comparison, I am no longer in a hurry to untangle my thoughts and I’ve moved the preliminary notes to a new draft for when I’ll actually update KDE 4.

Actual justification for this post

I’m trying to get into a blogging style were I post a lot more rubbish like this that can’t possibly be of any use to anybody except myself. I have plenty of reasons/excuses for this (about which I’ll likely post in the future), but I shouldn’t actually need any. That Ryan wanker who thinks I publish this blog for him should really shut the fuck up. Sure enough, he isn’t talking about this blog but I still think he’s a big-time asshole. Fuck you, Ryan!

Tracking /etc/ updates with Git

During my recent Gentoo update session, I was once again confronted with the inconvenience of not having my /etc/ directory under version management. This time, I thought I had the ideal SCM for this job: Git.

I found a blog post of a chap who has done the same. It includes a few notes I might not have thought about on my own and also a few very cool Debian tricks.

One of the steps that I might have overlooked myself is that it’s essential to make the .git directory group/world inaccessible with chmod go-rwx. If I would have forgotten this, a smart attacker might use my Git repo to access forbidden file contents.

The author also describes a cool Post-Invoke for Debian’s dpkg that will automatically stage and commit configuration changes made by apt/dpkg (although, later, he mentions that Debian has gotten a package could etckeeper that does this automatically.

Now I would like to learn how I can let Gentoo’s etc-update do as much. In its /etc/dispatch-conf.conf I can only find the option to use (of all things) RCS to track replaced configuration files in a special directory (/etc/config-archive/ by default). Hopefully, there is some drop-in replacement for etc-update which does this and which can rid me of etc-update’s awkward interface at once.

« Older posts

© 2024 BigSmoke

Theme by Anders NorenUp ↑