How to move local git repo with branches to a server

As my HAL/hal-info git repos were lost last year at people.freedesktop.org, I restored them from my last existing local checkouts. I simply copied the local checkout/repo to the server and created a new git repository as proposed in the git user manual:

git clone --bare ~/hal hal.git

touch hal.git/git-daemon-export-ok

But as I, some months later, tried to switch to my hal-0_5_12-SUSE_CODE11 branch, there was no such branch. To be exact: there was neither this branch nor any of the upstream branches. I couldn't find any information on the web how to solve this problem. Everything I tried didn't work. When I cloned the new repo from the upstream repo, all branches where available.

At the end I found my own solution once I compared the .git/refs/ directories of the cloned repo from the upstream and the local repo. Looks as if the clone command don't copy the branches under .git/refs/remotes/origin/ to .git/refs/heads/ if you use a local repo/checkout as source. Here is what I did to get my branches available again:

cd hal

find refs/remotes/origin/ -type f | grep -v -E 'HEAD|master' | xargs cp --target=../hal.git/refs/heads/

I don't know if there is an other, more standard, way to do this. I couldn't find anything else and at least it solved the problem for me.

Tech Tags: git Tutorial HAL

My freedesktop.org stuff is online again

It's a while since the last post on my blog, so here the latest news:

Two weeks ago, after some weeks of absence, I tried to commit some patches to my hal/hal-info git repo at freedesktop.org, but there was no git repo anymore. In fact my complete home at people.freedesktop.org was empty. 

After wonder around about the reason, I found out that the freedesktop admins lost the complete /home filesystem during a power outage (see the announcement). Unfortunately there was obviously no backup (whyever!) and also no email announcement to the affected users after all . That's why my repos weren't reachable for nearly a month. Thanks for the service at  people.freedesktop.org in general (really!), but this was a lousy incident handling.

Anyway! You can find now again:

• my HAL git repo: here
  
• my hal-info git repo: here
• several different versions of the HAL specification: here

Tech Tags: HAL

HAL: new keys to match kernel version

Since a while there is the problem that e.g. suspend quirks or key mappings differ between kernel versions. While machines with newer kernel versions may need no longer to map scancodes (as in case of ThinkPads) or need no special suspend handling anymore, systems with older kernels may need other handling.

With current HAL versions it's not possible to match the kernel versions (e.g. > 2.6.28), except for a special version, because system.kernel.version is a string. This is especially a problem with data from the hal-info package, since the package depends on no special kernel version.

I added a patch to HAL to provide now these new comparable (using e.g. compare_*) keys:

• system.kernel.version.major (int)
• system.kernel.version.minor (int)
• system.kernel.version.micro (int)

This change will be part of the upcomming 0.5.12 release. For openSUSE 11.1 you can get the latest HAL snapshot from my OSBS repo.

Tech Tags: HAL Patches

HAL: support for linux leds kernel subsystem

I've implemented HAL support for the linux kernel leds (light-emitting diode) subsystem some days ago. The new namespace provides these information for leds devices:

• leds.device_name: The name of the related led device.
  
• leds.colour: The colour of the LED. (e.g. green, orange)
  
• leds.function: The function of the LED. (e.g. radio, power, standby, batt)

The new leds devices offer via a singleton addon also a DBus interface to set the brightness of the LED. It works the same way as e.g. the org.freedesktop.Hal.Device.LaptopPanel interface by providing a GetBrightness() and a SetBrightness() method. The values for the brightness depends on the kernel driver and should be normally between 0 and 255 (0 normally deactivates the LED, any other value > 0 activates the LED again).

You can get the patches from my git repo [1] [2] [3].

Tech Tags: HAL Patches

HAL: v0.5.12-RC1 released

I've released today the first release candidate of HAL v0.5.12 and a snapshot of hal-info (20081127). You can get the sources here:

• http://hal.freedesktop.org/releases/hal-0.5.12rc1.tar.bz2
  
• http://hal.freedesktop.org/releases/hal-info-20081127.tar.bz2
  

More information about the changes since the last HAL version (v0.5.11, released 2008-05-08) and the last official released hal-info package (released 2008-05-08) can you find here.

For openSUSE 11.1/Factory you can find packages in my openSUSE Buildservice Repository.

Please test the packages heavily and carefully. Please report bugs (no features get included until the final version, as already announced) to the HAL mailing list or via the freedesktop bugzilla.

Tech Tags: HAL

HAL: fixed device locking

Some days ago I had a discussion with Matthias Kretz at the Akademy 2008 about HAL, the handling of audio devices in HAL and the needs/requirements from the perspective of phonon.

One aspect was that phonon needs to find out of some other tool already uses a audio device. The HAL device locking would be a solution to detect this. I took a look at the HAL code for device locking and while playing around with the interfaces I wondered why it didn't work as it should. The lock information (info.locked* keys) where never removed if the lock owner died or exited without unlock the interface again. The handling was also broken if someone requested more than one lock (e.g. two or more different devices).

I really wonder why there was only one bugreport about problems with device locking (if the lock owner dies). Did nobody ever used these interfaces?

I've wrote a quik patch to solve these problems. As first I changed the hashtable which contains the lock info from key={lockowner}/value={device} to key={lockowner}/value={list of devices} so that locking multiple devices is now possible. And the other part of this patch is to remove the lock based on the old_service_name (and not the new_service_name) on NameOwnerChanged events from DBus to solve the 'lock owner died' problem.

Tech Tags: KDE Akademy HAL

HAL patch collection (5)

Here my actual HAL patch collection. I didn't send them to the HAL ML yet, but I try as soon as I find the time.

• a patch to fix handling of PMU battery and AC if the devices are available via the power_supply kernel interface to fix problems with duplicated devices from the proc interface (should also fix fd.o#15482)
  
• patch for fd.o#16427 to fix the PropertyModified signal in SPEC to do what the code already do
• small memory leak fix
• a patch to remove the storage.model property from all volume devices (it's always empty and should be only part of devices which use the storage namespace)
• a bigger patch to cleanup the code of some addons, removed check_priv() from the addons and added it to a new file to be able to simply reuse it for all addons if needed
• a patch to prevent get truncated model strings for some IDE devices (I think it's atm not the final version of the patch, this need some more testing)
• a patch to fix the FDI match directive for the uint64 type (fd.o#16575)

I wrote also two patches to improve the performance of HAL. These patches move some often used stuff from the scripts to addons to prevent multiple (at least 2-3) forks for each DBus method call. The patches are:

• one for the generic kernel backlight interface
  
• and another for the Intel WLAN (ipw) killswitch interface

These patches are against current HAL git or against the v0.5.11 sources. If a link to a patch doesn't work, the patch was maybe moved to this directory. The patches are already part of the HAL package in my openSUSE Factory buildservice repo.

Tech Tags: HAL Patches

HAL 0.5.11 released

Yes, it's a delayed blog entry ... I forgot to blog as I officially announced HAL v0.5.11 and a hal-info package (20080805) last month.

You can download the source packages here:

• http://hal.freedesktop.org/releases/hal-0.5.11.tar.gz
• http://hal.freedesktop.org/releases/hal-info-20080508.tar.gz

A list with all changes since the last release can you find here or in the announcement email on the HAL mailing list.

Thanks to all contributors, testers and bugreporters which helped during the (too) long release cycle. I hope we see the next release faster (than the 8 months between 0.5.10 and the actual version).

Small note for openSUSE user: this HAL/hal-info version is already part of the upcoming openSUSE 11.0.

Tech Tags: HAL

HAL: v0.5.11-RC2 released

Due to problems with the 'parallel event processing'-patches I've opened a branch for hal v0.5.11. We reverted the relevant changes in this branch and added some patches from the list.
I've decided to stretch the announced release plan with a RC2 to get some time or testing. At the moment I plan to release the final 0.5.11 until Friday (2008-03-21) if there are no new critical bugs.

You can download the snapshots here:

• http://hal.freedesktop.org/releases/hal-info-20080317.tar.gz
• http://hal.freedesktop.org/releases/hal-0.5.11rc2.tar.gz

For openSUSE (Factory/11.0) you can find packages in my hal-beta openSUSE Buildservice Repository as soon as they get build.

For more information about the changes since the last release check this email. Please test the packages carefully and report bugs to the HAL mailing list or via freedesktop bugzilla. Special thanks to Rob Taylor and Sjoerd Simons for testing and patches.

Tech Tags: HAL

HAL: v0.5.11-RC1 released

I've released some hours ago the first release candidate of HAL v0.5.11 and a snapshot of hal-info (20080313). You can get the sources here:

• http://hal.freedesktop.org/releases/hal-0.5.11rc1.tar.gz
• http://hal.freedesktop.org/releases/hal-info-20080313.tar.gz

For more about the changes since the last HAL version (released 2007-10-12) and the last offical released hal-info package (released 2007-12-12) can you find here.

For openSUSE you can find packages in my hal-beta openSUSE Buildservice Repository (named as git snaphot to prevent problems with update packages later).

Please test the packages heavily and carefully. Please report bugs (no features get included until the final version, as already announced) to the HAL mailing list or via the freedesktop bugzilla.

Tech Tags: HAL

HAL: release schedule for v0.5.11

The next HAL version is on the way and since I manage this time the release, here the current release schedule for hal v0.5.11:

• feature and major changes go into until Wednesday (2008-03-12)
  
• HAL 0.5.11 RC1 get announced and offered as source package (2008-03-13)
• bugfixes and hal-info related changes until Friday (2008-03-14)
• release of new version on the weekend (2008-03-16), or depending on open critical bugs by Monday (2008-03-17) at the latest.

I would like to see atm these (major) patches go into the release:

• optimization patches (Rob Taylor)  [1] ff.
• TabletPC support (Danny Kukawka) [2]

So please review and test them carefully. Let me know, if there are other patches left, that need to go into the release.

Tech Tags: HAL

HAL: some deprecated keys ...

... will be removed from HAL with end of this month, because they are deprecated since 12 months now and already replaced by other keys/properties. The affected keys  (old --> new/replacement) are:

2008-02-28:

• smbios.system.manufacturer --> system.hardware.vendor
• smbios.system.product --> system.hardware.product
• smbios.system.version --> system.hardware.version
• smbios.system.serial --> system.hardware.serial
• smbios.system.uuid --> system.hardware.uuid
• smbios.bios.vendor --> system.firmware.vendor
• smbios.bios.version --> system.firmware.version
• smbios.bios.release_date --> system.firmware.release_date
• smbios.chassis.manufacturer --> system.chassis.manufacturer
• smbios.chassis.type --> system.chassis.type
• system.vendor --> system.hardware.vendor

2008-03-01:

• info.bus --> info.subsystem
• *.physical_device --> *.orginating_device

Please note, that there are some other (IMO rarely used) keys which are planed to be removed end of March:

2008-03-21:

• usb_device.speed_bcd (int) --> usb_device.speed (double)
• usb_device.version_bcd (int) --> usb_device.version (double)
  

Please check your packages for these keys (code and shipped fdi-files) and prepare them for the next HAL package. If you use openSUSE or you package RPMs  for openSUSE:  the next HAL version for openSUSE 11.0 (Beta) will be shipped without support for these keys.

Tech Tags: HAL Packaging SUSE

HAL: sysfs ACPI batteries fixed

With the recently released linux kernel v2.6.24 and if configured with ACPI_PROCFS_POWER and ACPI_SYSFS_POWER, you get now two ACPI battery interfaces in the system. One, as before, under /proc/acpi/battery/ and a new in the power_supply subsystem in the sysfs under /sys/class/power_supply/ . HAL listed both batteries, which was fixed by show the proc batteries only if there is no power_supply battery in the system [1]. Unfortunatly the sysfs battery was never updated (except on add/remove events of the AC adapter). This could lead, besides missing information updates, to a system crash on empty batteries if the userspace tools as e.g. KPowersave trusted these information. They never reached critical battery levels in this case.

I have now fixed this problem in HAL git master with several patches (last one was this), which also fix the power_supply battery handling in general (since it were several bug in the code). HAL poll now the power_supply ACPI batteries every 30 seconds as HAL already does for proc batteries. The code should work basicly, but I assume there are some corner cases left. Need to check the existing ACPI code for the proc batteries to find and port them. Maybe it make sense to split up the ACPI sysfs battery part from the existing power_supply handling to merge it into the existing ACPI code ... we will see.

I have added an updated HAL version for openSUSE factory (and for openSUSE 10.3 as testing package) to my OSBS HAL project repo and to the next Alpha2 of openSUSE 11.0. Fell free to test and report problems.

Tech Tags: HAL ACPI battery sysfs

New hal-info package released

Yesterday I released a new package of hal-info. The new version (20071212) contains now also most of the suspend quirks from the s2ram whitelist. For more information about the changes see the release mail on hal@lists.freedesktop.org.

For openSUSE you can get an up-to-date hal package (which contains the latest hal-info) for Factory and 10.3 here.

Tech Tags: HAL hal-info

HAL patch collection (4)

Here my actual HAL patch collection. I send them already to the HAL mailing list, but they are not aproved yet (also because David isn't active/present on the list).

• a patch to remove the Eject() methode from dm-devices. The eject command is a ioctl and not supported by dm-devices (at least on Linux). On crypto volumes you should use Teardown() instead, which do the same.
• a patch to fix calculation of the remaining time of ACPI batteries, if they report the wrong charging state (e.g. if they report 'charged' if the battery is charging). With this patch HAL try to guess the correct state depending on the AC state and the state of the other primary ACPI batteries in the system.
• a small fix to prevent endless loops on fdi-files with a empty rule (only a match, but nothing merged etc.).
• two patches for the Dell brightness [1] and killswitch [2] (against hal-info) devices. With kernel 2.4.24 (or this patch) there is now a uevent if the platform device of the dcdbas module get added/removed. Attach the Dell devices now to this platform device in the HAL device tree. This should fix the problem that HAL provide the Dell devices and methodes also if the needed kernel module isn't loaded.
• extend HAL try to get the smbios information from sysfs on startup instead of call a prober (which call dmidecode, parse the output and set the properties to HAL). If /sys/class/dmi/id isn't present it falls back to the prober.
• small fix to ignore module and drivers uevents in HAL, since they aren't events for devices
• a patch, needed also for the Dell devices, to remove also via fdi-files spawned devices if the parent device get removed. Currently the devices get not removed, also if they are not visible in lshal (because the parent was removed), which mean also the may started addons get not stopped.
• two patches to add more checks: to the partutil code [3] which should prevent possible crashes and to libhal [4] to check e.g. if a given UDI is valid (should start with: /org/freedesktop/Hal/devices/)
• extend HAL to add also drm (Direct Rendering Manager) devices to the device tree.
• a fix to stop HAL from flood syslog with warnings if the remaining time get over 60 hours (which can happen on broken batteries)
• small patch to fix possible segfaults if HAL get compiled without IDs (PCI/PnP/USB) support

These patches are against current HAL git. As always: you can find all my current HAL patches here, if a link to a patch doesn't work, the patch was maybe moved to this directory. The patches are already part of the HAL beta package in my openSUSE buildservice repo.

Tech Tags: HAL Patches

HAL patch collection (3)

Some time since I posted the last blog entry. So now the first message of the new year.

Here some new patches I send to the HAL mailing list which aren't included in the git repository because they are not approved (I think David Zeuthen is currently in Australia, so he is maybe not that often online.):

• two patches to cleanup the Linux LUKS scripts [1] and fix the password handling to prevent the bash from word splitting and path expanding [2]
• a patch to add support for IBM ACPI hotkey events, which allow HAL to send e.g. the sleep and s2disk/hibernate button event as currently already for other machines: here
• a patch which fixes the detection of libsmbios for the Dell backlight addon - the code of the addon need libsmbios >= 0.11.6 - by proof the library version: here
• a fix for set/get brightness on machines which supported by sonypi kernel module: here
• a fix support the old and the newer version of the omnibook kernel module, which try to find the max. supported levels of brightness: here

These patches are against current HAL git. As always: you can find all my current HAL patches here.

Tech Tags: HAL Patches

HAL patch collection (2)

Today again some new patches I send to the HAL mailing list which aren't included in the git repository because they are not approved so far :

• fix detection of wireless network capability for devices which use drivers with dscape stack as e.g. rt2500pci: here
• fix to add hardware specific/dependent sound devices to HAL (as e.g. /dev/snd/hwC0D0): here
• fix of libhal related to changed behavior of dbus_error_is_set(error) if error == NULL in the new D-Bus. Now the check would crash the realated application which use libhal. Download: here
  

These patches are against current HAL git. As always: you can find all my current HAL patches here.

Tags: HAL Patches

HAL patch collection

There a currently some patches I send to the HAL mailing list which aren't included in the git repository so far. They should be included in the new HAL package for openSUSE 10.2 Beta2. Here a list of these patches (feel free to use them on your own distribution):

• fix build (hald-addon-macbookpro-backlight) against newer versions of libpci: here
  
• add support for Standby (S1) to HAL: here
• remove backend postfix from script filenames (need maybe rename files by hand, for more see this mail thread): here
• A performance fix for search in pci.ids for vendor and product information of PCI devices. This patch is a reworked version of a inital patch from Ihno Krumreich. I extended the patch to fix bug in the search algorithm and to stop search if found everything we looking for. This patch speed up the search in the list by factor ~8-15 if HAL starts up: here
  
• A new version of my patch to detect Tablet PCs (as e.g. with Wacom tablet devices and some Fujitsu Siemens machines) and to set the needed serial ports on boot: here

These patches are against current HAL git. You can find all my current HAL patches here.

Tags: HAL patches

KPowersave development for next stable (0.8.x)

Today a (short) brief/information about the current planed and already started development for the new KPowersave development tree (0.7.x) and the next stable version (0.8.x):

Preamble

Since Powersave starts to die and the powermanagement tasks going into HAL we need to change KPowersave to use HAL instead of Powersave.

Only for the log: I don't like this step and for me is the concept to put _all_ (hardware information, powermanagement, mounting, partition, format ...) stuff into one daemon, (into this crappy HAL and only because some desktop developer are not able to write a UNIX like daemon for special tasks) a really stupid idea.

I liked the old powersave. This was a great piece of code which contains several man-years of knowledge about ACPI/APM and powermanagement and did a great job over the years. I'm not happy about losing it.

This changes mean at least also more trouble in KPowersave.

Table of contents:

1. HAL/Powersave basics
2. Replace Powersave
3. GUI
4. Testing
5. Documentation/Translation
6. Timeframe

(1) HAL/Powersave basics

Currently KPowersave use Powersave and libpower from powersave to get hardware information, to switch schemes, to set CPU Freq and to trigger suspend2*/standby.

In general we need to connect now directly to HAL to get a signal if something on hardware changed, if we want to avoid permanent polling e.g. for battery information via libpower. There are two possible ways: listen to HAL for changes and call libpower to fresh up device information or listen to HAL and collect all device information directly in KPowersave.

I would go the second way. This should reduce the overhead of the library (libpower currently (old version KPowersave currently depends on) provide several info we never need and miss some other info we need now). If we implement this directly in KPowersave we can cache the information and need only to update the changed values (e.g. we need only call hal for current battery percentage and only for this key and only for this special battery) which should reduce the overhead on DBUS and allow KPowersave a finer grained signal and information pool.

Needed work:

implement a new class to:

• hold connection to the HAL interface via DBUS (done)
• to provide a layer to libhal to get device info (done)
• add methods to find devices by capability and property (done)
• to provide a layer to call DBUS methodes on HAL/DBUS interface (done)

implement a class to collect and abstract:

• battery, ac, lid information (75% done, need to think about the battery stuff)
• info about suspend, brightness, CPU Freq (done, TODO: add support for PolicyKit information)
• add function to update the related info if something changed. (in progress, Danny/Frank)

(2) replace Powersave

To replace currently by powersave provided functionality we need to change several issues in KPowersave:

suspend2*/standby:

Old Powersave provided a interface to trigger suspend2*/standby and to check if the user is allowed to call this methodes. HAL provide currently only a abstraction of the kernel interface, which mean we can only say if the machine/kernel can suspend in general, but we can't say if:

• the user is allowed to call these methodes
• the machine is really suspendable (or if the machine is e.g. not able to suspend2ram and is blacklisted e.g. in s2ram).

Problems:

• I have currently no idea how we can fix this. Maybe via PolicyKit, but this is not sure because we don't know if this go really in SUSE 10.2 or if PolicyKit is mandatory for HAL upstrean in the future. This situation is really bad and the sideeffects are annoying for the user.
• HAL only support suspend2* and not standby atm upstream (on SUSE we have a patch for this).

battery alarm states:

Powersave currently provide the battery alarm states and the config at which point which state is reached. We need to move this to KPowersave and make it configurable only in general and not per scheme. We need to configure the three states and the related actions (e.g. warn user, suspend, shutdown)

Problems:

• Several different users can be connected to the system and every user can define different states and different actions which results in a chaos. This is at least again the same problem as with CPU freq via HAL and fighting clients. Maybe we add this to a admin mode dialog as e.g. in KControl and allow only a systemwide config, but this is only a solution for KDE. (evaluate: discussion started by Holger at: g-p-m Mailing list)

CPU Frequency Policy:

Since CPUFreq settings are moved from powersave to HAL, we need also to replace the current settings in KPowersave. There are two issues:

• make the currently existing different CPUFreq Policies configurable
• make them configurable per scheme

Problems:

• Fighting Clients and other tools (see above).

Schemes:

Powersave currently provide some schemes (powersave, performance, presentation and acoustic), two of them are automatically switched if the AC plug is removed/inserted. We need to implement _real_ schemes in KPowersave. We have currently schemes in KPowersave (with brightness, screensaver, DPMS, autosuspend settings and so on), but we need to make them configurable. This mean we need this stuff:

• create new/remove/edit for current schemes
• make configurable default schemes for AC online/offline (and maybe other events as e.g. lidclose or if detectable adding a beamer to the machine for presentation scheme)
• per scheme CPU Frequency settings (see above)
• per scheme disk settings

Problems:

• There is currently no way to set the harddisk settings, but we need this on some machines which change the settings e.g. via the BIOS on suspend or if the AC plug is removed (which maybe increase Load_Cycle_Count and reduce lifetime of the disk).
• Fighting clients with different settings.

(3) GUI:

Based on the changes from (2) we need to update the configuration dialog to make all the settings configureable for the user. As a first step we don't need to implement this (first finish the basic stuff), we can do the config via the config file. Tasks to do:

• create/remove schemes, as first new schemes with a default config (first steps done). Later we can maybe add a wizard for inexperienced users
• CPU Freq stuff (per scheme, and per policy)
• AC state and actions (global settings)
• Battery states (global settings)

(4) Testing

Provide first working version as always on sf.net/freshmeat and kde-apps.org, send a mail to opensuse ML.

(5) Documentation/Translation

Need to extend, update and translate the documentation. We need also some new translations.

(6) Timeframe

A first stable running version - without not needed stuff from (3) - until openSUSE Beta1/2/final. With the new stable and without dependecy to powersave we can think about push KPowersave into KDE SVN as default KDE powermanagement applet.

You can find all already done changes in the KPowersave SVN at trunk.

Tags: kpowersave

The last two weeks ...

I didn't wrote anything here since two weeks. So here a update about some of the issues I worked on in this time:

Powersave:

• I installed the first time a SUSE Linux 10.1 Beta 7 on a Apple iBook G4. The installation process is really abortive compared to normal install on ix86 or x86_64. By the way powersave also work on ppc and I tested (K)Powersave on this machine. Suspend to Disk work perfect, but I could not get Suspend to RAM running on this machine. Looks as if this not work on ppc via apm, need to investigate if this maybe is possible somehow via pmu. I added support for change brightness on machines with pmu support to powersave.
• I also added brightness support for the omnibook kernel module. They released now a updated version of the package and now you can also unload the module on a 2.6.x kernel. I try to build a km_omnibook package in the next days.
  

HAL:

• Added more support for TabletPCs to HAL. From now HAL set automatically the serial port (by call the correct setserial command) for the Wacom Tablets if they are detected. Because HAL starts early enough before the X server this addon should be able to activate the port to be used in X. I also added a FDI file to set the correct ttyS* device on machines where we should not use ttyS0.