Older blog entries for mjg59 (starting at number 263)

Linux backlight control

Backlight control is one of those things that you'd think would be simple, but ha ha this is computing so of course it's an utter disaster and everything is a huge mess. There's three main classes of backlight control in the x86 world, all of which have drawbacks:

  • ACPI specifies a mechanism for backlight control, and the majority of modern machines implement it. It has the advantage that the brightness query interface is generally aware of anything else in the system which may have changed the brightness, so it's unlikely to get out of sync with reality if the platform tries to do something odd like change the backlight itself in response to an ambient light sensor or some other event. The main drawback is that there's typically a fairly small number of available backlight values, usually somewhere between 8 and 20.
  • A platform-specific mechanism. This used to be more popular before the ACPI backlight interface took off, but some machines still require it. The idea here is that there's some sort of platform-specific way of requesting a backlight change, ranging from a vendor-specific ACPI method through to triggering system management calls by magic register writes. These methods usually (but not always) keep in sync with other firmware changes, but rarely provide any more brightness steps than the standard ACPI interface.
  • Many mobile GPUs have backlight control registers built in. These usually give you a range of several thousand possible values, but using them will almost certainly leave you out of sync with reality if the firmware touches them at all. To make things worse, the firmware control of the backlight may occur after the gpu - so you could end up with two different controls that both need to be full in order to get maximum brightness. The worst case scenario is that the firmware gets confused by the values not being what it programmed and you end up with a hung machine.

Right now, if there's an ACPI backlight interface then that's usually the only thing we'll show you. We can do that because we can identify if there's an ACPI backlight interface when we parse the ACPI tables at the start of booting, and that information can be registered before we start setting up any other backlights. The problem comes when we have no ACPI backlight interface. We don't have any idea whether there's a platform mechanism until a platform driver loads, which could be at any time. As a result, we've been reluctant to expose GPU-level backlight control because doing so would often give you two separate backlight controls and no indication as to which should be used. Userspace doesn't really have a way to make that decision either, so everyone ends up unhappy.

This is especially problematic with some machines which provide no ACPI or known platform control (or, in the case of some Samsungs, only provide platform control if you have a special Linux BIOS that Samsung won't give you) but can control the backlight via the gpu. Right now you get nothing, because giving you something would potentially break other systems and the needs of the many etc. Sorry! But this is obviously problematic in the long term, especially because multi-GPU machines tend to have multiple ACPI backlight interfaces, so I've been working on a better approach.

When a backlight device is registered, it appears under /sys/class/backlight. If it's an ACPI device it has a symlink pointing to some random ACPI device. If it's a platform device it's pointing at something like "dell-laptop" which is approximately unhelpful when it comes to figuring out what it controls. If it's a GPU-level device then it probably points at the PCI device, which is helpful except in the case where you have multiple backlight controls on a single GPU. So, by and large, you have no good way to identify which backlight control is preferable unless you keep a huge list of all possible backlights along with some scoring.

The first thing I've added to improve this is a "type" attribute. This tells you whether a given backlight is firmware-level (like ACPI), platform-level (like the various laptop drivers) or performs raw register writes (like a GPU driver). That lets userspace decide which interface is preferable. It'll typically be the ACPI interface, because that's the most likely to keep synchronisation and so avoid bizarre brightness bugs. The next thing has been to start fixing up the parent links. There's nothing we can do for the platform level devices, but the ACPI drivers could at least point at PCI devices rather than into ACPI space. That means that multi-GPU systems can now identify which interface to use based on the currently active GPU. Finally, I've started pointing the GPU-level backlight controls at the specific output rather than merely at the PCI device. This probably makes little difference for laptops as such, but once we start exposing backlight control for monitors that support ddcci it'll make things much easier as we'll know which backlight control corresponds to which monitor.

I've then written a small library that accepts information about the output and picks the "best" backlight for the device. It's obviously based on a pile of heuristics and there's a couple of bits of API that I suspect need to be nailed down yet, but it means that this code only needs to be written once. It's then simple to glue this into X drivers, which means that they can expose a "Backlight" xrandr property on each relevant display. That means that backlight control is then handled at the session level with the X server acting as the privileged agent, which simplifies a bunch of things and means we can finally let hal die entirely. Long-term this means we'll have unified backlight control for all of your displays, which is a wonderful thing.

Summary: We kind of suck right now, but there's a reasonably clear path to getting better.

Syndicated 2010-09-09 21:43:34 from Matthew Garrett

Things

The last few months have been busier than I expected, resulting in various failures to get stuff done. The good news is that things are a little more relaxed now and I'm gradually catching up, but if you've emailed me and I haven't replied then you should probably do so again.

A couple of updates - the source code for the Augen Android tablets I wrote about still hasn't been released, but the vendor does seem to be doing their best. Their supplier seems to be refusing to hand over the source code (they were given a tarball that was supposed to be it, but in fact just turned out to be the various GPLed bits of Android) and they're obviously stuck between a rock and a hard place. The obvious observation is that they should have done due diligence before starting to ship these things, but given that they're out in the wild and they're trying to improve things it seems reasonable to carry on working to try to obtain the source rather than insisting that kmart stop selling them.

Fusion Garage, on the other hand, are still failing to provide source and seem entirely unconcerned about it - they've failed to respond to any of my emails since the first. Augen aren't providing source because they can't, while Fusion Garage aren't providing source because they won't. Irked by this, I've decided to try Don Marti's suggestion and file a case with US Customs. I'll admit that I have absolutely no idea how seriously these cases get taken, and so I've no great expectation of any sort of interesting outcome. But even so, if you're in the US and try to buy a Joojoo then there's a chance that it'll be seized by US customs on the way in.

Syndicated 2010-09-09 13:58:36 from Matthew Garrett

AE_AML_BUFFER_LIMIT in \_SB_._OSC

If you get messages like this:

ACPI Error (psparse-0537): Method parse/execution failed [\_SB_._OSC] (Node ffff8801e8c62b30), AE_AML_BUFFER_LIMIT

then you've fallen foul of one of the less appealing aspects of ACPI. _OSC methods are defined as methods to allow the operating system and the firmware to handshake over their support of optional features. Different _OSC methods apply to different types of hardware. CPU _OSC methods allow the operating system to inform the firmware that it supports ACPI 3.0 throttling states, while PCIe _OSC methods allow the operating system to indicate that it can manage native PCIe hotplug. The firmware can choose whether or not to give up control of these features, and the OS then has to cope.

The problem arises when we get to the _OSC method on the system bus. This wasn't specified until ACPI 4.0, leaving an attractive mechanism for vendors to add OS/firmware integration. To that end, we now have at least three different _SB_._OSC methods in the wild:

  1. The ACPI specified _OSC. This exists purely for the OS to tell the firmware what it supports, without the firmware having the opportunity to disagree. As such it passes 8 bytes of data to the method.
  2. The Microsoft WHEA _OSC. This exists to allow the firmware and Windows to handshake over whether or not the firmware supports Microsoft's hardware error reporting.
  3. HP's PCC _OSC method, designed to allow handshaking between the OS and the firmware in order to determine whether they support OS interaction with the firmware-level CPU scaling


This wouldn't be enough to be a problem in itself. The ACPI spec requires _OSC methods to have GUIDs in order to protect users from exactly this kind of situation - Windows can attempt to enable WHEA on a machine with a spec-compliant _OSC, and the _OSC method will return an immediate failure because the GUID doesn't match. Except that the WHEA and PCC versions of _SB_._OSC pass 12 bytes of data in the third argument, against the ACPI spec version's 8. And many _OSC implementations attempt to access the region between bytes 9 and 12 before checking the GUID, resulting in the AE_AML_BUFFER_LIMIT error.

This is made even more annoying due to the fact that argument 2 contains the number of parameters being passed in argument 3, making it straightforward to avoid this kind of failure. Firmware authors, tbh.

Syndicated 2010-08-06 20:44:00 from Matthew Garrett

Kmart Android tablets and the GPL

The Augen Android tablet being sold in Kmart stores at the moment is (shockingly) running a 2.6.29 kernel and Android 2.1 on top of that. It's also (shockingly) currently impossible to get hold of the source code for the kernel - Augen (whose corporate address is a small unit in Florida) say that the software comes installed on the units by the OEM and they don't have any access to the source either. This isn't an excuse, of course, and they say that they hope to have it on their website within the next few days - but even so, it seems that the Android device GPL violation trend is still on course. It'll be interesting to see what the long-term outcome of this kind of violation is, especially with these devices increasingly being sold by mainstream stores.

Syndicated 2010-07-29 21:51:22 from Matthew Garrett

Meego kernel watch

sgx535 drivers in today's Meego kernel tree: 3 (GMA600, CE4100, N900)
sgx535 drivers submitted upstream: 1 (Tungsten GMA500 driver, submitted March 2009, rejected due to significant chunks of functionality there purely to support closed userspace)

To be fair, the rest of the Moorestown support code seems to be shaping up fairly nicely. But the lack of a coherent story about what graphics support is going to look like isn't hugely reassuring.

Syndicated 2010-07-23 19:22:22 from Matthew Garrett

Power management at Plumbers

I'm running a power management track at the Linux Plumbers Conference again this November. Unlike most conferences which focus on presenting completed work, Plumbers is an opportunity to focus on unsolved problems and throw around as many half-baked solutions as you want in order to try to find one that seems to stick. The suspend/resume problem in Linux is mostly solved[1], which means that it's time for us to focus on runtime power management and quality of service.

This has been an especially interesting year in the field. We've landed the infrastructure for generic runtime power management, glued that into PCI and started implementing that at the driver level. pm_qos is being reworked to improve performance and scalability as we start seeing more drivers that need to express their own constraints. And, of course, we had the wakelock/suspend blockers conversation that didn't end in a terribly satisfactory manner, although Rafael is now working on an implementation that presents equivalent functionality with a different userspace API. Runtime full-system suspend isn't solved yet either - the current cpuidle-based solution doesn't work well on multicore systems. And maybe we could be more aggressive still by looking at reclocking more system components on the fly even if the existing interfaces don't allow that. Do we have all the hooks we need to identify which system resources are being used? Are we doing the best we can in terms of avoiding trading off performance for power savings?

So if you'd like to talk about any of these things, or if there's any other problems that you don't think have been solved yet, head on over to the call for submissions and help make sure that we can make Linux the most power-efficient OS possible.

[1] Yes, some machines are broken, but those tend to be individual weird bugs which we're gradually tracking down rather than fundamental issues in our core code, so they're not really in the scope of Plumbers

Syndicated 2010-07-12 13:53:43 from Matthew Garrett

Complications

It turns out that it's actually really, really easy to set up an l2tp tunnel. You just need to install xl2tpd, configure some address ranges and then add an authentication entry to chap-secrets. It's just that the entire known universe appears to be more interested in using ipsec as well, and that looks worse than setting up Kerberos and I've already done that enough in my life thanks. I don't care about my connection being encrypted (I've got encrypted protocols for that), so this seems to be an entirely reasonable solution.

Syndicated 2010-06-29 18:41:21 from Matthew Garrett

The paradox of choice

Searching for information on setting up an L2TP VPN takes me here, where I get to choose between OpenSWAN, KAME and some OpenBSD port. Searching for information on setting up a PPTP VPN takes me here, where I'm told exactly what I need to do.

Given choices, I chose the one that reduced my choices. THERE IS A LESSON HERE.

(Sadly, I'm now going to have to deal with L2TP anyway because something in the intermediate network is dropping GRE)

Syndicated 2010-06-29 17:37:04 from Matthew Garrett

In better news

The GNOME Foundation released their conference speaker guidelines today. This is an important step not just in helping speakers know what's acceptable, but also in helping audience members understand in advance what the community is likely to find objectionable and ensure that they can feel comfortable in raising concerns.

Of course, guidelines mean little without enforcement. My original draft of these suggested that event runners be able to stop presentations if they felt they were gratuitously in breach of the guidelines. Opinions on this were fairly strongly split, with several people concerned that this effectively allowed individuals to immediately shut down presentations with little oversight. That's a genuine concern, but it does seem to assume bad faith on the part of conference organisers in a way we've rarely (never?) seen. On the other hand, conferences in our field have endured presentations that have contained offensive material from start to finish. If an offended individual is in a minority then it's not easy for them to potentially challenge the audience by vocally expressing their unhappiness, and even standing up and leaving may be a difficult and obvious act.

But I don't set the behavioural standards of the community, and attempting to enforce standards that people don't agree with isn't going to fly. Some people are likely to feel that even the level of enforcement suggested is an unwelcome intrusion into free discussion of some topics, so I think this is a good compromise that is a great signal for our unwillingness to accept inappropriate presentations. With luck we'll see other communities enact similar guidelines and we can come to a broad consensus that covers the majority of our conferences.

Syndicated 2010-06-25 00:09:17 from Matthew Garrett

Joojoo

I've had the opportunity to look into the Joojoo tablet recently. It's an interesting device in various ways, ranging from the screen being connected upside down and everything having to be rotated before display, to the ACPI implementation that's so generic it has no support for actually attaching most embedded controller interrupts to ACPI devices and so relies on a hacked kernel that exposes individual interrupts as ACPI events that are parsed in userspace, to the ChangeOrientation binary that's responsible for switching between landscape and portrait modes containing gems like ps aux | grep fgplayer | grep -v grep and containing references to org.freedesktop.PandaSystem, a somewhat gratuitous namespace grab. Hardware-wise it seems to be little more than battery, generic nvidia reference design board and touchscreen with an accelerometer and LED glued to the chipset's GPIO lines. The entire impression is one of an ambitious project not backed up by the level of technical expertise required to get things done properly. Frankly, I think Michael Arrington came out of this rather better than he could have done - behind the reasonably attractive UI, the entire device is pretty much held together by string and a following wind.

Of course, releasing shoddily put together technology isn't generally illegal and from that point of view Fusion Garage aren't any worse than a number of products I've had the misfortune to actually spend money on. But they're distributing Linux (stock Ubuntu with some additional packages and a modified kernel) without any source or an offer to provide source. I emailed them last week and got the following reply:

Dear Sir,

we are still actively making changes to the joojoo software. We will make
the source release available once we feel we are ready to do so and also
having the resources to get this sorted out and organized for publication.
We seek your kind understanding on our position and appreciate your
patience on this. Thank you.

Best Regards
joojoo Support Team


Strong work, Fusion Garage. Hardware and software may not be your strong points, but you're managing copyright infringement with the best of them.

Syndicated 2010-06-24 16:10:37 from Matthew Garrett

254 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!