Ignoring partitions…

Yet another public service announcement. You use HAL. Every time you log in you get a device icon for a “recovery partition” that you can't use, and really don't want cluttering your desktop. HAL provides a way to blacklist certain partitions and sets a key to ignore the volume and not be automounted.

  <!-- HP ships desktops with a recovery partition -->  <match key="volume.fstype" string="vfat">   <match key="volume.label" string="HP_RECOVERY">    <merge key="volume.ignore" type="bool">true</merge>   </match>  </match> 

So. Do you see a recovery partition on your Linux desktop? If so, please email me (richard_at_hughsie_dot_com) and send me the output of “lshal | grep volume.label” and we can fix this for future versions of HAL. Cheers. edit: Also provide the output of “lshal | grep volume.fstype” – THANKS! edit2: Already I've added IBM_SERVICE, SERVICEV001, SERVICEV002, HP_RECOVERY, “Recovery Partition”, DellUtility, DellRestore, RECOVERY, PQSERVICE.

McCann driving the multiuser desktop…

Jon McCann absolutely rocked yesterday explaining how to do a multiuser desktop correctly. I've uploaded his slides here, which you really should read. There's some cool new ideas which makes stuff like gnome-power-manager in a gdm session possible (in a sane way), which we've wanted for ages. But that's trivializing all Jons' work. Seriously, this new stuff will be really cool. Read the PDF.

Dude, keep rocking.

Nouveau 2D progress

Time taken to do the gtkperf benchmark:

Nouveau driver from two days ago: 54.94 seconds
Nouveau driver from today: 24.86 seconds
NV driver (for comparison): 40.78 seconds

So you can see the nouveau driver is now substantially quicker than it used to be, and now even quicker than the old nv driver.

Keep rocking guys!

Mapping keys : unfucking one keyboard at a time

So the “unfuck my keyboard” project is going well. We now have a way to map scancodes to keycodes even for the vendors that choose non-standard scancodes that don't get input events.

The thinkpad-acpi and sony-laptop kernel drivers now also support the setkeycode ioctl and report key presses over input. This means we can map the acpi events to keys, even when vendors do crazy things and move the decal on the button between models and ranges for no apparent reason.

ALL LINUX USERS:

So now I need your help.

Do you get something similar to this in dmesg?:

atkbd.c: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e017 ' to make it known.

Try using all the fn-buttons and the special multimedia buttons, you might find you could help make this work.

SONY USERS:

I need to know what button does what on your laptop. You can already see I've fixed Bastiens laptop by looking at this file. This gives you an idea how simple it is.

THINKPAD USERS:

I also need to know what mapping you have. See this file and send me a patch to make it “just work” for you in the future.

Big Note:

You'll need to be using a very new HAL and hal-info to make this work right now. If you want the sony and thinkpad bits to work you'll also need kernel modules from git. Actually getting it working now is unimportant – getting the data as soon as possible makes sure it should work for as many people as possible for Fedora 8, or the next version of Ubuntu or Suse.

So please, visit the quirk site and help me try to fix broken keys by sending patches. I need your help.

Walking around half open

I've just had a bug reported:

At Ottawa Linux Symposium, it was common to see people walking around with
their laptops half-open because they didn't want them to sleep. Whether wardriving, Web serving, or music playing, some people do not want their PCs to sleep.

I cast my mind back to GUADEC, and sure enough I can remember an entrance hall full of people walking about with half-open laptops. This made me smile.

I figured I could use the inhibit applet for people to use for a “don't do what you normally do” type action.

So now we have a new toy. With gnome-power-manager from SVN you can add the standard  “inhibit” applet into the panel, click the button, shut the lid and walk over to show someone your new coolness.

But wait! Some laptops melt or get rather hot when you do this. So just in case we have the following warning that is displayed when you manually inhibit and you have either suspend or hibernate configured as the battery lid close action.

New warning…

So, maybe for GUADEC this year we'll see less half-open laptops…

powertop is getting it wrong…

The powertop utility from INTEL has been very interesting to use. Unfortunately, I'm quite pissed off.

“gnome-power-manager doesn't dim the backlight to save power it actually just changes the colour of the pixels on the screen”

Err no. It never has and never will. It actually dims the backlight on all the hardware I have tested it on.

Dimming to 30% when idle saves me about 1-3W of power on all three laptops I own. That's a X60 (ibm+intel), n100 (lenovo+nvidia) and a A10 (toshiba+old-intel).

For the X60, g-p-m calls HAL, which writes to the thinkpad_acpi controlled backlight class. This then writes a value into the embedded controller address space (or issues a CMOS command) which changes the hardware backlight brightness.

Really impressive graph by the way – but what crack are you smoking?

DBus System Activation

For the last few days I've been working on DBus system activation, extending and slightly modifying on the work David Zeuthen did a few months ago. So what is is?

You already see activation working in the session, for instance where notify-send can get dbus to start notification-daemon only when a notification needs to be shown. The bigger problem was to launch stuff on the system bus under different users. Securely.

We think we've worked out how to do this securely, but further review would be lovely. The patch is here, and I've got a SRPM also here.

So what?

  • We can launch helpers to do things as different users, for instance use a combination of PolicyKit and a system helper to set gconf defaults for all users. We can do some cool things with this.
  • We can launch some automatically, only when required. For instance, we only need to start ConsoleKit when HAL is started, and this is done automatically for us on the first method that HAL requests from the ConsoleKit service.

So, for a non-legacy system (think OLPC) we can just do:

  • kernel….udev….messagebus….login-screen

And that is it. As sugar (or another interface) requests the network state, then NetworkManager is started. This calls into HAL, so that is started. That calls into ConsoleKit, so that is started. As soon as we are on the network, we search for users, which queries avahi, so that is started. Can you see where this is headed? Parallel start-up with dependencies essentially for free.

Already, I've taken my Fedora 7 boot time from 20 seconds to 14 seconds by dropping a few service files in directory and turning off services in chkconfig. That's pretty substantial in my book. I've yet to build this for OLPC, but I'm guessing it will be a more substantial reduction.

Fixing lid state after resume…

So you are using gnome-power-manager on your laptop. You notice that sometimes when you shut the lid it suspends, and sometimes it doesn't. After a suspend it also acts a little funny, but you can't quite work out why…

The lid “up” event is not sent when you resume from suspend as the lid state changing triggers the resume, but no event is sent to userspace. This took me ages to work out yesterday. See my patch to LKML for a fix. Hopefully this is headed to 2.6.22 as it's a trivial fix, although it might be a little late in the day. Distributions might want to add this patch in the meantime.

Shutting down too early…

When g-p-m doesn't have a complete profile of your battery, it tries to shutdown or hibernate when the known battery remaining is very low. If you've never tried to take your battery to 10%, g-p-m assumes it can't and calculates only the capacity it has seen being used.

This fixes many broken batteries. It also introduces a problem when you first start using the profiling code, in that g-p-m knows nothing about what the battery actually can do.

What about the following tooltip:

Laptop battery 30 minutes remaining (97%)
Battery discharge profile is estimated
Policy actions will not be performed until battery profiled

As usual, my spelling and grammar are sh1te and so suggestions welcome. The last line is far too techy, but I'm not sure what to write. Please add a comment to this blog (or email me) with better suggestions, thanks!