One fring to rule them all…

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/fring2.html

A while ago I
played around with Cairo and created a Python tool fring, similar to KDE’s Filelight, however not
interactive and very simple. Frédéric Back took my code and gave it a little
GUI love, and this is the result:

fring screenshot

Frédéric added a nice interactive GTK GUI and a fully asynchronous directory
walker based on Gnome-VFS which runs in a background thread and thus doesn’t
block the UI. This makes the user interface snappier than Filelight’s ever was.
It’s a lot of fun to navigate your directories like this!

I would have liked to post a screencast of the new fring in action here, to show how
snappy it is. But unfortunately both Byzanz and Istanbul failed horribly on my 16bpp
display.

The current version of fring is not yet polished for a public
release. In the meantime, you can get the sources from the SVN:

svn checkout svn://svn.0pointer.de/fring/trunk fring

Yes, I am aware that a future version of Baobab will offer a similar view of
the filesystem. However, it just was so much fun to hack on fring, and
due to the power of Python it was so easy and quick to develop this tool, that
we just couldn’t resist to do it.

Updates

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/stuff.html

Various, unrelated news:

Thanks to Marvin Stark my project syrep is now
available in Debian. As you might know all the cool kids have written their
own distributed revision control systems. This is my contribution on this
topic. Although I started to work on it four years ago syrep is still unrivaled
and unbeaten in its specific feature set. (Which is admittedly very different
from the feature set of most other software in this area.)

Thanks to CJ van den Berg and Sjoerd Simons (and a few others from
#pulseaudio) PulseAudio is now available in
Debian
, the auxiliary GUI tools like pavucontrol seem to
be still missing. Nonetheless: it’s now easier then ever to try PulseAudio:

sudo aptitude install pulseaudio
pulseaudio-module-hal
pulseaudio-esound-compat
pulseaudio-utils
libgstreamer-plugins-pulse0.10-0
pulseaudio-module-gconf
pulseaudio-module-x11
pulseaudio-module-zeroconf

For the next months I will focus on my Diplomarbeit (German equivalent of a master thesis). Due to this I passed maintainership of Avahi to Trent Lloyd and of PulseAudio to Pierre Ossman. I hope to resume maintainership of both projects in January.

My first non-trivial kernel patch has been merged into Linus’ kernel, although the 2.6.19 merge window was already closed. I take this as birthday present from Linus.

If you have a laptop (such as the MSI S270) with Ricoh SD/MMC
interface (not one of the new controllers which are SDHCI compatible, but the
old ones where the SD/MMC is a virtual PCMCIA slot identifying itself as
Bay1Controller), then please support me in writing a Linux driver for
it and request the necessary documentation and datasheets from Ricoh. For more
information on this issue see this
posting on the s270-linux mailing list
, and this followup.

That’s all for now.

Updates

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/stuff.html

Various, unrelated news:

Thanks to Marvin Stark my project syrep is now
available in Debian. As you might know all the cool kids have written their
own distributed revision control systems. This is my contribution on this
topic. Although I started to work on it four years ago syrep is still unrivaled
and unbeaten in its specific feature set. (Which is admittedly very different
from the feature set of most other software in this area.)

Thanks to CJ van den Berg and Sjoerd Simons (and a few others from
#pulseaudio) PulseAudio is now available in
Debian
, the auxiliary GUI tools like pavucontrol seem to
be still missing. Nonetheless: it’s now easier then ever to try PulseAudio:

sudo aptitude install pulseaudio \
    pulseaudio-module-hal \
    pulseaudio-esound-compat \
    pulseaudio-utils \
    libgstreamer-plugins-pulse0.10-0 \
    pulseaudio-module-gconf \
    pulseaudio-module-x11 \
    pulseaudio-module-zeroconf

For the next months I will focus on my Diplomarbeit (German equivalent of a master thesis). Due to this I passed maintainership of Avahi to Trent Lloyd and of PulseAudio to Pierre Ossman. I hope to resume maintainership of both projects in January.

My first non-trivial kernel patch has been merged into Linus’ kernel, although the 2.6.19 merge window was already closed. I take this as birthday present from Linus.

If you have a laptop (such as the MSI S270) with Ricoh SD/MMC
interface (not one of the new controllers which are SDHCI compatible, but the
old ones where the SD/MMC is a virtual PCMCIA slot identifying itself as
Bay1Controller), then please support me in writing a Linux driver for
it and request the necessary documentation and datasheets from Ricoh. For more
information on this issue see this
posting on the s270-linux mailing list
, and this followup.

That’s all for now.

avahi-autoipd Released and ‘State of the Lemur’

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.14.html

A few minutes ago I released Avahi 0.6.14
which besides other, minor fixes and cleanups includes a new component avahi-autoipd.
This new daemon is an implementation of IPv4LL (aka RFC3927, aka
APIPA), a method for acquiring link-local IP addresses (those from the range
169.254/16) without a central server, such as DHCP.

Yes, there are already plenty Free implementations of this protocol
available. However, this one tries to do it right and integrates well with the
rest of Avahi. For a longer rationale for adding this tool to our distribution
instead of relying on externals tools, please read this
mailing list thread
.

It is my hope that this tool is quickly adopted by the popular
distributions, which will allow Linux to finally catch up with technology that
has been available in Windows systems since Win98 times. If you’re a
distributor please follow these
notes
which describe how to integrate this new tool into your distribution
best.

Because avahi-autoipd acts as dhclient plug-in by default,
and only activates itself as last resort for acquiring an IP address I hope
that it will get much less in the way of the user than previous implementations
of this technology for Linux.

State of the Lemur

Almost 22 months after my first SVN commit to the flexmdns (which was the
name I chose for my mDNS implementation when I first started to work on it)
source code repository, 18 months after Trent and I decided to join our two
projects under the name “Avahi” and 12 months after the release of Avahi 0.1,
it’s time for a little “State of the Lemur” post.

To make it short: Avahi is ubiquitous in the Free Software world. 😉

All major (Debian, Ubuntu, Fedora, Gentoo, Mandriva, OpenSUSE) and many
minor distributions have it. A quick Google-based poll I did a few weeks ago
shows that it is part of at least 19 different
distributions
, including a range of embedded ones. The list of applications
making native use
of the Avahi client API is growing, currently bearing 31
items. That list does not include the legacy HOWL applications and the
applications that use our Bonjour compatibility API which can run on top of
Avahi, hence the real number of applications that can make use of Avahi is
slightly higher. The first commercial hardware appliances which include Avahi are
slowly appearing on the market. I know of at least three such products, one
being Bubba.

If you package Avahi for a distribution, add Avahi support to an
application, or build a hardware appliance with Avahi, please make sure to add
an item to the respective lists linked above, it’s a Wiki. Thank you!
(Anonymous registration without Mail address required, though)

avahi-autoipd Released and ‘State of the Lemur’

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.14.html

A few minutes ago I released Avahi 0.6.14
which besides other, minor fixes and cleanups includes a new component avahi-autoipd.
This new daemon is an implementation of IPv4LL (aka RFC3927, aka
APIPA), a method for acquiring link-local IP addresses (those from the range
169.254/16) without a central server, such as DHCP.

Yes, there are already plenty Free implementations of this protocol
available. However, this one tries to do it right and integrates well with the
rest of Avahi. For a longer rationale for adding this tool to our distribution
instead of relying on externals tools, please read this
mailing list thread
.

It is my hope that this tool is quickly adopted by the popular
distributions, which will allow Linux to finally catch up with technology that
has been available in Windows systems since Win98 times. If you’re a
distributor please follow these
notes
which describe how to integrate this new tool into your distribution
best.

Because avahi-autoipd acts as dhclient plug-in by default,
and only activates itself as last resort for acquiring an IP address I hope
that it will get much less in the way of the user than previous implementations
of this technology for Linux.

State of the Lemur

Almost 22 months after my first SVN commit to the flexmdns (which was the
name I chose for my mDNS implementation when I first started to work on it)
source code repository, 18 months after Trent and I decided to join our two
projects under the name “Avahi” and 12 months after the release of Avahi 0.1,
it’s time for a little “State of the Lemur” post.

To make it short: Avahi is ubiquitous in the Free Software world. 😉

All major (Debian, Ubuntu, Fedora, Gentoo, Mandriva, OpenSUSE) and many
minor distributions have it. A quick Google-based poll I did a few weeks ago
shows that it is part of at least 19 different
distributions
, including a range of embedded ones. The list of applications
making native use
of the Avahi client API is growing, currently bearing 31
items. That list does not include the legacy HOWL applications and the
applications that use our Bonjour compatibility API which can run on top of
Avahi, hence the real number of applications that can make use of Avahi is
slightly higher. The first commercial hardware appliances which include Avahi are
slowly appearing on the market. I know of at least three such products, one
being Bubba.

If you package Avahi for a distribution, add Avahi support to an
application, or build a hardware appliance with Avahi, please make sure to add
an item to the respective lists linked above, it’s a Wiki. Thank you!
(Anonymous registration without Mail address required, though)

Playing with Cairo

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/fring.html

Play around with Cairo: Check!

One thing that has been sitting on my TODO list for a very long
time was playing around with Cairo. No longer! Yesterday I spent a
little time on hacking a Cairo based equivalent of KDE’s Filelight (Which
BTW is one of the two programs that KDE has but GNOME really lacks,
the other being KCacheGrind). The
result after two hours is this:

Fring Screenshot

This screenshot shows the development tree of my Syrep tool.

This tool has definitely nicer anti-aliased graphics than
Filelight, doesn’t it? The source code is here: fring.py. Anyone
interested in turning this into a proper GNOME application?

Playing with Cairo

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/fring.html

Play around with Cairo: Check!

One thing that has been sitting on my TODO list for a very long
time was playing around with Cairo. No longer! Yesterday I spent a
little time on hacking a Cairo based equivalent of KDE’s Filelight (Which
BTW is one of the two programs that KDE has but GNOME really lacks,
the other being KCacheGrind). The
result after two hours is this:

Fring Screenshot

This screenshot shows the development tree of my Syrep tool.

This tool has definitely nicer anti-aliased graphics than
Filelight, doesn’t it? The source code is here: fring.py. Anyone
interested in turning this into a proper GNOME application?

A few updates on PulseAudio

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-news.html

Thanks to Marc-Andre Lureau there’s now a jhbuild file
for PulseAudio
. And there is this (little bit chaotic)
Wiki page
in GNOME Live! about the relation of PulseAudio and
GNOME.

A few weeks ago I wrote a new page for our Wiki where I tried to
describe the steps necessary to get the most out of PulseAudio. It’s
called the Perfect
Setup
.

A few minutes ago I released PulseAudio 0.9.5 and new versions of the auxiliary tools. The changelog:

Add module-hal-detect, a module that detects all local sound hardware using HAL and loads the necessary modules. Handles hot-plug and hot-removal of audio devices. (Contributed by Shahms E. King)
Add shared memory transfer method for local clients
Update module-volume-restore to automatically restore the output device last used by an application in addition to the volume it last used
Add a new module module-rescue-streams for automatically moving streams to another sink/source if the sink/source they are connected to dies
Add support for moving streams “hot” between sinks/sources
Reduce memory consumption and CPU load as result of Valgrind/Massif profiling
Add new module module-gconf for reading additional configuration statements from GConf
Fix module-tunnel to work with the latest protocol
Miscellaneous fixes

One of the nicest new features of PulseAudio 0.9.5 is HAL
integration (which has been contributed by Shahms King). PulseAudio will
now automatically detect all available sound devices and will make
use of them. It supports both hot-plug and hot-remove.

Another nice feature is the GConf integration which allowed us to add another nice application to the PulseAudio toolset: the PulseAudio Preferences utility:

paprefs screenshot

The idea is to have a simple, nice configuration dialog that allows
configuration of the more exotic features of PulseAudio which we do
not enable by default due to security considerations or to not
confuse the user. Right now a lot of features are hidden behind
non-trivial configuration file statements. This preferences tool shall
make them available for the users which are not so keen on editing
configuration files.

Playing around with Valgrind‘s
Massif tool and KCachegrind I did a little bit of memory and perfomance profiling of
the PulseAudio daemon. The 0.9.5 release contains a lot of
optimizations which are result of this work.

Before:

Massif before

After:

Massif after

These plots show the memory consumption against the time, from
starting the server, to playing stream, to stopping the stream and
shutting down the server again. The major improvement was actually an
update to libsamplerate done
by its maintainer to improve the memory handling of that library. (He
didn’t release an updated version of his library containing the
changes shown in the plots yet).

PulseAudio had the nice feature of remembering the playback volume of every
application for quite a while. Starting with 0.9.5 PulseAudio it also remembers
the output device for every application. Together with an updated Volume
Control tool which now allows moving streams between sinks while they are
played this can be used to configure a ruleset like “Ekiga always on the USB
headset, Rhytmbox always on the external speakers” very intuitively and easily:

pavucontrol screenshot

And here’s a final screenshot showing all the tools we currently have for PulseAudio 0.9.5.

PA Screenshot

A few updates on PulseAudio

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-news.html

Thanks to Marc-Andre Lureau there’s now a jhbuild file
for PulseAudio
. And there is this (little bit chaotic)
Wiki page
in GNOME Live! about the relation of PulseAudio and
GNOME.

A few weeks ago I wrote a new page for our Wiki where I tried to
describe the steps necessary to get the most out of PulseAudio. It’s
called the Perfect
Setup
.

A few minutes ago I released PulseAudio 0.9.5 and new versions of the auxiliary tools. The changelog:

  • Add module-hal-detect, a module that detects all local sound hardware using HAL and loads the necessary modules. Handles hot-plug and hot-removal of audio devices. (Contributed by Shahms E. King)
  • Add shared memory transfer method for local clients
  • Update module-volume-restore to automatically restore the output device last used by an application in addition to the volume it last used
  • Add a new module module-rescue-streams for automatically moving streams to another sink/source if the sink/source they are connected to dies
  • Add support for moving streams “hot” between sinks/sources
  • Reduce memory consumption and CPU load as result of Valgrind/Massif profiling
  • Add new module module-gconf for reading additional configuration statements from GConf
  • Fix module-tunnel to work with the latest protocol
  • Miscellaneous fixes

One of the nicest new features of PulseAudio 0.9.5 is HAL
integration (which has been contributed by Shahms King). PulseAudio will
now automatically detect all available sound devices and will make
use of them. It supports both hot-plug and hot-remove.

Another nice feature is the GConf integration which allowed us to add another nice application to the PulseAudio toolset: the PulseAudio Preferences utility:

paprefs screenshot

The idea is to have a simple, nice configuration dialog that allows
configuration of the more exotic features of PulseAudio which we do
not enable by default due to security considerations or to not
confuse the user. Right now a lot of features are hidden behind
non-trivial configuration file statements. This preferences tool shall
make them available for the users which are not so keen on editing
configuration files.

Playing around with Valgrind‘s
Massif tool and KCachegrind I did a little bit of memory and perfomance profiling of
the PulseAudio daemon. The 0.9.5 release contains a lot of
optimizations which are result of this work.

Before:

Massif before

After:

Massif after

These plots show the memory consumption against the time, from
starting the server, to playing stream, to stopping the stream and
shutting down the server again. The major improvement was actually an
update to libsamplerate done
by its maintainer to improve the memory handling of that library. (He
didn’t release an updated version of his library containing the
changes shown in the plots yet).

PulseAudio had the nice feature of remembering the playback volume of every
application for quite a while. Starting with 0.9.5 PulseAudio it also remembers
the output device for every application. Together with an updated Volume
Control tool which now allows moving streams between sinks while they are
played this can be used to configure a ruleset like “Ekiga always on the USB
headset, Rhytmbox always on the external speakers” very intuitively and easily:

pavucontrol screenshot

And here’s a final screenshot showing all the tools we currently have for PulseAudio 0.9.5.

PA Screenshot

Launchpad is Evil

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/launchpad-stole-my-name.html

I always think twice before entering my name in any web form or posting to a
mailing list. Is the web site/list respectable? Do the owners of the web site
have any commercial interest in my name (spam, marketing, …)? Would I ever
regret that my name can be found with Google in context with this web
site/mailing list? If I enter my name is it used for collecting data about me?
Is there any reasonable privacy policy?

Often enough I refrain from entering my name after deciding that the answers
to these questions are unsatisfactory. I like to be in control of my name. If I
am not confident that I remain in control I don’t enter my name to any
service.

Recently it came to my attention that Canonical decided to create an account (!) for me in their
commercial, proprietary bug tracker called “Launchpad”. I never asked for one!
I never even considered having one, because their service clearly is nothing
that would pass the tests mentioned above. They are a commercial service, my
account data is apparently “content” for them, they don’t seem to have any
privacy policy. (At least I couldn’t find any, the navigation is pretty
crappy.)

Canonical’s nimbus of being “the good guys” doesn’t hinder them to
incorporate data from free sources (apparently they got my data from the Debian
BTS) and make a commercial service of it, without even asking the original
contributors if that would be OK with them, or if it is OK to incorporate their
name or personal profile in the service. Apparently Canonical is not much
better than a common spam harvester: generating personal profiles for
business, without consent of the “victim”.

If anyone from Canonical reads this: It is not OK for me to use my name as
“content” for your commercial, proprietary service. Please remove any
reference to my name from your “account” database. I don’t want to have a
Launchpad account. I don’t plan to use Launchpad. Let me decide if I ever want to
join! Thank you very much.

Update: I especially dislike the fact that they created an account for me in
a service where Hitler apparently already has six (!) accounts. I am very sure
that I don’t want to be part of that community.

Launchpad is Evil

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/launchpad-stole-my-name.html

I always think twice before entering my name in any web form or posting to a
mailing list. Is the web site/list respectable? Do the owners of the web site
have any commercial interest in my name (spam, marketing, …)? Would I ever
regret that my name can be found with Google in context with this web
site/mailing list? If I enter my name is it used for collecting data about me?
Is there any reasonable privacy policy?

Often enough I refrain from entering my name after deciding that the answers
to these questions are unsatisfactory. I like to be in control of my name. If I
am not confident that I remain in control I don’t enter my name to any
service.

Recently it came to my attention that Canonical decided to create an account (!) for me in their
commercial, proprietary bug tracker called “Launchpad”. I never asked for one!
I never even considered having one, because their service clearly is nothing
that would pass the tests mentioned above. They are a commercial service, my
account data is apparently “content” for them, they don’t seem to have any
privacy policy. (At least I couldn’t find any, the navigation is pretty
crappy.)

Canonical’s nimbus of being “the good guys” doesn’t hinder them to
incorporate data from free sources (apparently they got my data from the Debian
BTS) and make a commercial service of it, without even asking the original
contributors if that would be OK with them, or if it is OK to incorporate their
name or personal profile in the service. Apparently Canonical is not much
better than a common spam harvester: generating personal profiles for
business, without consent of the “victim”.

If anyone from Canonical reads this: It is not OK for me to use my name as
“content” for your commercial, proprietary service. Please remove any
reference to my name from your “account” database. I don’t want to have a
Launchpad account. I don’t plan to use Launchpad. Let me decide if I ever want to
join! Thank you very much.

Update: I especially dislike the fact that they created an account for me in
a service where Hitler apparently already has six (!) accounts. I am very sure
that I don’t want to be part of that community.

Avahi 0.6.13 released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.13.html

Avahi Logo

I am happy to bring you yet another release of Avahi, everyone’s favourite Zeroconf stack.

Add a new D-Bus method for changing the mDNS host name during
runtime. This functionality is only available to members of the
UNIX group “netdev”, which is the same access group that is
enforced by GNOME’s NetworkManager daemon. Since NM will probably
be the most prominent user of this new method, we decided to limit
access to the same group. The access group can be set by passing
–with-avahi-priv-access-group= to “configure”. If you need more
sophisticated access control you can freely edit
/etc/dbus/system.d/avahi-dbus.conf.
Add a new utility “avahi-set-host-name” which is a command line
wrapper around the aforementioned SetHostName() method.
Bonjour API compatibility library:

Implement DNSServiceUpdateRecord()
Allow passing NULL as callback function for DNSServiceRegister()
Implement subtype registration in DNSServiceRegister() in a
way that is compatible with Bonjour.
Update to newer copy of dns_sd.h

If the host name changes update names of static services wich
contain wildcards.
Don’t build documentation about embedding the Avahi mDNS stack into
other programs by default. This is a feature used only by embedded
developers. Pass –enable-core-docs to “configure” to enable
building these docs, like in Avahi <= 0.6.12.
Build Qt documentation only when Qt support is enabled in
the configuration. Same for GLib.
Change algorithm used to find a new host name on conflict. In
Avahi <= 0.6.12 a conflicting host name of “foobar” would be
changed to the new name “foobar2”. With 0.6.13 “foobar-2” will be
picked instead. This follows Bonjour’s behaviour and has the
advantage not confusing people with regular host names ending in
digits.
Don’t disable all static services when SIGHUP is recieved.
Fix build when Avahi is configured without Gtk+ but with Python
support
Fix build on MacOS X
Support using Solaris DBM instead of gdbm for the service type
database. The latter is still recommended
Minor other fixes and documentation updates

The relevant NetworkManager bug about SetHostName() is #352828.

And our bug tracker is back to only two open bugs for Avahi. That’s a good feeling, I can tell you!

Avahi 0.6.13 released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.13.html

Avahi Logo

I am happy to bring you yet another release of Avahi, everyone’s favourite Zeroconf stack.

  • Add a new D-Bus method for changing the mDNS host name during
    runtime. This functionality is only available to members of the
    UNIX group “netdev”, which is the same access group that is
    enforced by GNOME’s NetworkManager daemon. Since NM will probably
    be the most prominent user of this new method, we decided to limit
    access to the same group. The access group can be set by passing
    –with-avahi-priv-access-group= to “configure”. If you need more
    sophisticated access control you can freely edit
    /etc/dbus/system.d/avahi-dbus.conf.
  • Add a new utility “avahi-set-host-name” which is a command line
    wrapper around the aforementioned SetHostName() method.
  • Bonjour API compatibility library:
    • Implement DNSServiceUpdateRecord()
    • Allow passing NULL as callback function for DNSServiceRegister()
    • Implement subtype registration in DNSServiceRegister() in a
      way that is compatible with Bonjour.
    • Update to newer copy of dns_sd.h
  • If the host name changes update names of static services wich
    contain wildcards.
  • Don’t build documentation about embedding the Avahi mDNS stack into
    other programs by default. This is a feature used only by embedded
    developers. Pass –enable-core-docs to “configure” to enable
    building these docs, like in Avahi <= 0.6.12.
  • Build Qt documentation only when Qt support is enabled in
    the configuration. Same for GLib.
  • Change algorithm used to find a new host name on conflict. In
    Avahi <= 0.6.12 a conflicting host name of “foobar” would be
    changed to the new name “foobar2”. With 0.6.13 “foobar-2” will be
    picked instead. This follows Bonjour’s behaviour and has the
    advantage not confusing people with regular host names ending in
    digits.
  • Don’t disable all static services when SIGHUP is recieved.
  • Fix build when Avahi is configured without Gtk+ but with Python
    support
  • Fix build on MacOS X
  • Support using Solaris DBM instead of gdbm for the service type
    database. The latter is still recommended
  • Minor other fixes and documentation updates

The relevant NetworkManager bug about SetHostName() is #352828.

And our bug tracker is back to only two open bugs for Avahi. That’s a good feeling, I can tell you!

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

acpi-ec-transaction.patch
acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
grep MICRO-STAR yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

  1. acpi-ec-transaction.patch
  2. acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan                 # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth            # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
grep MICRO-STAR
yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.

Apple Bonjour adopts the Apache License 2.0

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/bonjour-apache-license.html

Yesterday Apple Bonjour has
been
released
under the Apache License 2.0, replacing the old much criticized (because
non-free) APSL licensing.

What does this mean for Avahi? First of all
although the Apache
License
is much better than the APSL it still isn’t GPL
compatible (at least in the eyes of the FSF), which effectively means that
Bonjour still cannot be used by more than 66% of the Free Software
projects available. Secondly Avahi is more powerful in most areas than Bonjour
ever was. (In fact, there is only a single feature where Bonjour surpasses us:
writable “Wide Area DNS-SD”). Avahi uses all the “hot” Free technologies like
D-Bus and a has much better integration in the Linux networking subsystem. Avahi is more secure (chroot()…)
Avahi is compatible API- and ABI-wise with Bonjour, but not the other way
round. Avahi is now part of every major Linux distribution.

Avahi is actively developed. The aforementioned Wide Area DNS-SD is currently
being worked on by Federico Lucifredi. Since I will write my master thesis
about mDNS scalability a lot of additional development will be done for Avahi
in the next month.

In short: Avahi is here to stay. Apple’s move to the Apache license is too little, too late.

Update: the Bonjour client libraries are BSD licensed, so the 66% argument doesn’t hold.

Apple Bonjour adopts the Apache License 2.0

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/bonjour-apache-license.html

Yesterday Apple Bonjour has
been
released
under the Apache License 2.0, replacing the old much criticized (because
non-free) APSL licensing.

What does this mean for Avahi? First of all
although the Apache
License
is much better than the APSL it still isn’t GPL
compatible (at least in the eyes of the FSF), which effectively means that
Bonjour still cannot be used by more than 66% of the Free Software
projects available. Secondly Avahi is more powerful in most areas than Bonjour
ever was. (In fact, there is only a single feature where Bonjour surpasses us:
writable “Wide Area DNS-SD”). Avahi uses all the “hot” Free technologies like
D-Bus and a has much better integration in the Linux networking subsystem. Avahi is more secure (chroot()…)
Avahi is compatible API- and ABI-wise with Bonjour, but not the other way
round. Avahi is now part of every major Linux distribution.

Avahi is actively developed. The aforementioned Wide Area DNS-SD is currently
being worked on by Federico Lucifredi. Since I will write my master thesis
about mDNS scalability a lot of additional development will be done for Avahi
in the next month.

In short: Avahi is here to stay. Apple’s move to the Apache license is too little, too late.

Update: the Bonjour client libraries are BSD licensed, so the 66% argument doesn’t hold.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close