Profile cover photo
Profile photo
Maarten Lankhorst
Maarten's posts

Post has shared content
On the 1st of December we published a video showing the results of some initial work done on getting good ol' X applications running on Xmir/Mir.  (

It showed a single Mir surface and a few glitchy X applications.

And now here we are today, a little over two weeks later.  

We've come a long way, baby.

Thanks to +Maarten Lankhorst and to increasingly mistitled Unity 7 team for all the hard work.

Expect more goodies in the new year.

Submitted a fence proposal to reach out to the android devs, not much feedback on it yet. :(

Post has shared content
CVE-2013-1940: shaggy bug story

So myself and +Peter Hutterer  found a pretty low risk security bug in the X server last week, but I decided to document how we found it, for my own posterity!

So +Maarten Lankhorst mentioned that GPU hotplug when you have multiple X servers running was fail, and I was just about to start writing the code to fix it. The problem is of course the X server that is VT switched takes control of the hotplugged USB device as well as the one that is currently running the VT. So Peter and myself were in the office and I decided to ask him that input hotplug does to stop this. He wasn't sure but he thought it might not handle it so well, and he also realised it was a possible CVE for input devices.

So instead of reading the code, I started an X session, opened a terminal, left the cursor in it, VT switched the X server, plugged in the keyboard, typed some stuff, and VT switched back, and there were my keystrokes in the terminal window. So this could lead to someone being able to steal your login details if they left a VT switched X server in the background and jumped to a gdm login screen.

So clearly there was nothing in the VT switched X server blocking new input devices being attached. Except then we read the code, and there was. Very explicitly we don't enable new input devices on VT switched X servers. So we had a found a bug, just not the bug we had been trying to find.

Head scratching, wtf, WTUF ensued.

So keystrokes from the device were getting buffered somewhere, but where could that be. When we VT switched back to the X server and it enables input devices, the evdev driver eventually calls xf86FlushInput to remove any queued input events for the device. Also when we VT switch away we closed all the file descriptors and reopen them on VT switch back.

Except when evdev hotplugged something it plumbed some pieces of the device in, it opened the file descriptor for example, and kept it open. So that was hint one, we had an open fd, so maybe the kernel was putting stuff in there, and we weren't flushing it. A few straces later, and I located the flush code reading from the device, and getting -EINVAL back  (queue another wtf).

Investigating the flushing code which was written back when devices were serial and read always returned whatever bytes it could, the kernel evdev drivers won't allow partial reads of input events, the X server flush code only used a 4-byte buffer as its flush buffer. So the X server was never actually flushing evdev devices, one 4->256 in a char array and it was all fixed.

What I find wierd, if we had read the code first and I hadn't gone straight to just see what happened, we'd have decided there was no problem at all and this would have lived on, until someone noticed it some other way.

Are there any smartphones out there that can stay charged for (at least!) a full week, while playing at least 6-8 hours worth of music in that week?

It seems my 1st generation iPod touch still beats any smartphone that's out there for that. :(

Getting synchronization between i915 and radeon to work means locking up both cards (and sometimes kernel) without extra effort when one single thing fails. It can make it hard to see whether it's a i915 bug, a radeon bug, or I messed up locking and kernel dies on me type of bug. Lockdep dies early on for now since the first locking violation happens very ealry on, so it's not of much use.

Nouveau is still completely TODO for synchronization, the patches in general have become less intrusive though, but I can't enable/disable fence interrupts on fermi and later, so deferred indefinitely. Maybe I'll wait for nvidia to support it first, then approach i in the same way they do it. Strictly speaking you could map the intel status page readonly and issue a fifo wait on that directly, this was the first thing I tried early on, and worked succesfully. Then the big driver rewrite landed and nothing applied any more. :-/

Post has attachment
Well, restarted yesterday on vdpau for fun. First visual that worked without crashing again on nouveau with blobby firmware. I messed up the samplers used by the presentation shader, but since the best way to show something is not completely working is a broken screenshot it felt appropriate to upload this instead of the 'working' version that gives people too much hope.

Tons of ubuntu sessions at ubuntu dev summit this week. For some reason all of the X sessions have been scheduled on the last day, which makes my life a bit of a hassle.

I talked with the some ttm and linaro devs about getting dma-buf supporting (cross-device) eviction, reservation and synchronization. Unfortunately despite multiple attempts I have had no contact from nvidia, so it's hard to even see if it would be useful for them. Being a nouveau developer who wants to keep contributing to nouveau (open source drivers are great test environments for these kind of things) doesn't help much I suppose, even though it's ultimately beneficial for them as well..

On a plus note, optimus support is coming, eventually..

Hats for participating in steam 4 linux beta are not confirmed. :(

So after my rant on how to do bad leds have some help on how to do it properly. :)

I recently bought a new logitech keyboard to upgrade after my old one was worn out. The old one had a clock and 4 batteries, the battery indicator was passive like displays on old calculators. It also displayed time and date, which you could use the numeric keys or arrow keys to adjust for summer time and leap days. If you replaced 2 batteries at a time it wouldn't lose clock settings so you never had to worry about losing clock, I think it worked for a month or 2 on 4 of them.

The new one has 3 green leds to indicate status, but they only turn on briefly after you haven't used the keyboard for a few hours or if you specifically ask for the status. Now if only my screens did the same, I can see if a screen is on just by looking at it, so the blinking led is really annoying. The power button should just behave differently instead. If no signal is detected the screen should turn itself off and immediately turn on when it detects signal again or when the power button is pressed. No need for a led ever.

Somehow this feels like I'm describing the behavior of an apple screen without ever having owned one. Are high dpi screens going to become mainstream any time soon or will I have to wait for apple to make affordable ones?

Blinking blue leds, I've grown to hate you. Why does every power indicator have to be blue nowadays and BLINK when in low power mode/suspended? I now either tape those leds off or disconnect them where I can.
Wait while more posts are being loaded