Older blog entries for mjg59 (starting at number 255)

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

Tch.

The benefits of Meego's "Upstream first" policy are amply demonstrated by the Meego kernel tree now carrying two separate PowerVR drivers with significant quantities of duplicate code, neither of which is upstream.

Wait. What?

Syndicated 2010-06-22 16:05:12 from Matthew Garrett

What

The WIndows 7 installer runs using vesa, in the wrong resolution and aspect ration, and does sub-pixel anti-aliasing anyway?

Syndicated 2010-06-10 19:39:51 from Matthew Garrett

Lie Bot, what is the saddest thing?

Syndicated 2010-06-07 17:47:53 from Matthew Garrett

Poulsbo still makes me sad

Meego 1.0 was released last month. Predictably enough, it lacks any form of support for the GMA500 graphics chipset[1], which is reasonably in line with Intel's placing of US15W as an embedded product for MID-type devices rather than having anything to do with netbooks. Of course, the market pretty much ignored that detail, so we're left with the release of a netbook experience that's incompatible with a large number of netbooks.

There's been hints that there might be some sort of new driver coming, though, and Intel's rapidly heading towards the release of Moorestown - their new MID platform that's x86 but not a PC, that replaces Poulsbo (unless you want to run Windows) and which has the same SGX 3D core[2] as Poulsbo. Moorestown support has started landing in the mainline Linux kernel and Intel are talking about devices shipping with it this year, so we ought to see the graphics driver soon, right?

Well, kind of. Digging through the Meego kernel git tree reveals an updated driver with Moorestown support. The blob is too big for gitorious to display, so I've put up a copy here. Things to note - this isn't a new driver (it's clearly derived from the PSB one), it includes a huge blob of Imagination's platform-independent code, the front end of the driver is still pretty much the i915 driver with a small number of PSB-specfic changes and despite the cheerily optimistic "Patch-mainline: 2.6.35?" at the top it stands pretty much no chance whatsoever of going mainline given that it's even more offensive than the previous version and that one got rejected out of hand.

So it's not clear what Intel's doing here. If this is the driver that Intel are developing for upstream then there's been a pretty serious breakdown in communication over what their driver has to look like. If it's not, Intel have another and presumably better driver somewhere that they're developing entirely behind closed doors despite having shipped millions of units of hardware that people would dearly love to be able to run mainline kernels on. Neither case looks especially good, so the continuing perception would seem to be that only a subset of the company understands the Linux development model - we'll see how this ends up interacting with Meego as a whole.

(Huh. I was about to hit "Post" on this, and then found that another and entirely different driver was submitted for the Meego kernel last week. A copy of it's here. "IVI" in this context appears to stand for "In-vehicle interface" and is aimed at those contexts rather than generic ones. It includes much the same Imagination glue code as the Moorestown driver, appears to be derived from a driver that has support for other Intel chipsets, was written to be at least partially OS-independent given that it abstracts things like PCI and stands even less chance of going upstream than the other driver - as acknowledged by "Patch-mainline: Never". Hilariously, if we include IEGD, that makes three different drivers for the same hardware from the same company, each having no chance to go upstream. Thintel.)

[1] Weirdly, it includes the kernel DRM for Matrox cards. No X driver though.
[2] It's clocked higher, though

Syndicated 2010-06-03 14:03:58 from Matthew Garrett

10:45: Restate my assumptions.

1. all software contains bugs.
2. all bugs can be represented and understood through files.
3. if you graph files against bugs, a pattern emerges. Therefore: We must reduce the number of files.

Syndicated 2010-05-28 14:46:41 from Matthew Garrett

Using qemu to instrument Windows

Part of the problem that we face in providing Linux hardware support is that we're lucky if there's a spec, and even if there's a spec there almost certainly isn't a test suite. Linux still isn't high on the list of things that vendors test with, so as a result hardware and firmware tend to be written to work with Windows rather than some more ideal notion of what a spec actually says.

This can lead to all kinds of problems. If the spec says we can do something and Windows never does that, we'll often find that there's at least one piece of hardware out there somewhere that breaks in response. But sometimes there'll be several different workarounds, and picking the wrong one may break some other system instead. It's helpful to know what Windows is actually doing, if only because that's the only configuration most systems have been tested with.

The problem is that doing this at the hardware level is next to impossible. I'm sure there are people out there who salivate at the possibility of working out i8042 initialisation sequences by hooking up oscilloscopes to their mouse, but I'm not one of them. There's a much easier alternative involving qemu.

The qemu source base is reasonably large and complex, but that's ok - we don't need to care about most of it. For our purposes we really only want to trace accesses to given bits of hardware. There's three main types of hardware access we're likely to care about: io ports, memory mapped io and pci configuration space. io ports are easy. Each piece of qemu that performs hardware emulation will call register_ioport_read or register_ioport_write. Just grep for those, find the ports that correspond to your hardware and then edit the functions to dump the information you want. PCI configuration space will be handled via pci_default_read_config or pci_default_write_config unless the driver overrides them. Finally, for PCI devices mmio will be handled via pci_register_bar - the last argument is the function called when the memory region is accessed.

All of which makes it pretty easy to watch register reads and writes performed by Windows when it's starting up. Suspend/resume is also an interesting problem, but sadly one that's harder to work with. First of all, you need at least version 0.6c of vgabios in order to indicate to Windows that it's possible to suspend at all. Secondly, for Vista or later you'll also need a WDDM driver for the graphics. Sadly there isn't one for the Cirrus that qemu emulates, which is unsurprising given how ancient it is. So I've had to perform my testing under XP, which was enough to give me an indication as to what Windows does with the SCI_EN bit on resume (answer: Ignores both the bit of the spec that says it should already be enabled and the bit of the spec that says it should never be written by hand). Nice, but if someone would like to write a WDDM driver for Cirrus it'd make my life easier.

The other thing I've been testing is keyboard controller probing. Some Macs deal badly with you banging on the keyboard controller, which is dumb but on the other hand they don't claim to have one. Linux will look at your ACPI tables and use any keyboard controllers it finds there, but if there isn't one it'll go on to try probing the legacy locations. Adding some debug code to the read and write functions of the keyboard driver in qemu and then editing the DSDT in Seabios to remove the declarations for the keyboard showed that Windows will only probe if there's a device with a recognised keyboard PNP ID. No keyboard for you if that's missing. So we probably need to emulate that behaviour as well.

The main reason to do this work is to try to reduce the number of DMI tables in the kernel. These are cases where we alter the kernel's behaviour based on the identity string of the hardware, allowing us to work around functional differences. The problem with this approach is that Windows generally works fine on these machines without knowing anything special about them, and chances are that the tables aren't exhaustive - there may well be some other piece of hardware that's also broken, but the user just gave up and went back to Windows instead of ever letting us know. Using qemu to work out how Windows actually behaves gives us the opportunity to fix things up in a way that will (with luck) work on all machines.

Syndicated 2010-05-14 17:59:11 from Matthew Garrett

Google

It turns out that even failing a Google interview isn't enough to keep Google recruiters away.

Syndicated 2010-05-03 23:19:56 from Matthew Garrett

PCI power management problems

I've previously written about some of the implementation details of runtime PCI power management. One of the key aspects for PCI devices is that the PME line on the device be able to generate a wakeup event. Unfortunately, it turns out that since Windows makes no use of this functionality at present, some vendors have started failing to wire this up. This is problematic because the device itself still announces PME support and will even raise a PME signal when it gets woken up - but it's pretty much screaming as hard as it can and nobody's listening because somebody's replaced the air with cheese.

Bother, etc.

The obvious question is what to do next. We could poll all the PCI devices every second or so to see if there's a PME status register that's been set. This would be reasonably cheap (we're going to wake up at least once a second on x86 anyway, so it makes no real difference to power consumption) but would introduce obvious latency in the wakeup path. This would be fine for certain types of situation (you're probably not going to be too sad if your SD reader takes a second longer to notice a card insertion) but not others (if an sdio wireless card generates a wakeup interrupt then we really ought to do something about it in a more sensible timeframe). A second is to force users to pass a boottime argument to enable this at all. That kind of sucks.

The third possibility is limited to a subset of hardware, but does allow the introduction of some kind of elegance into what would otherwise be one of those nightmarish scenarios that makes me consider taking up farming instead. If we can trigger a PME ourselves then we can test whether the line is connected. This doesn't appear to be possible on SDHCI but the spec for firewire makes it look like we can do it there - one of the interrupt sources is the port enable/disable register, and we can hit toggle that ourselves. I haven't actually tested this yet, but if it works that would let us make this determination.

It's depressing that doing anything interesting with power management is still heavily determined by what Microsoft have bothered to implement - to the extent that on some machines (hello, Thinkpads) there are no GPE methods at all for PME signals and you don't get runtime power management at all. The only thing that saves us is that (a) it's pretty hard to be able to screw up stuff that's already all glued into one chip package, so integrated stuff like USB should be fine anyway, and (b) PCIe does this as part of the normal traffic stream so there's no way to get that wrong. Unless you're still missing the GPE methods for the signals (hello, Thinkpads) in which case you get nothing unless the native PCIe signalling works. I suspect that we can always force that, so there's some hope yet.

In summary, then: dispassionate.

Syndicated 2010-05-03 21:25:26 from Matthew Garrett