The Wayland protocol [1] is designed to be more secure than X, when X was designed there wasn t much thought given to the possibility of programs with different access levels displaying on the same desktop. The Xephyr nested X server [2] is good for running an entire session from a remote untrusted host on a local display but isn t suitable for multiple applications in the same session. GNOME supported Wayland by default in Debian since the Bullseye release and for KDE support you can install the plasma-workspace-wayland which gives you an option for the session type of KDE Plasma Wayland when you login. For systems which don t use the KDE Plasma workspace but which have some KDE apps you should install the package qtwayland5 to allow the KDE apps to use the Wayland protocol. See the KDE page of the Debian Wiki [3] for more information. The Debian Wiki page on Wayland has more useful information [4]. Apparently you have to use gdm instead of sddm to get Wayland for the login prompt. To get screen sharing working on Wayland (and also to get a system that doesn t give out error messages) you need to install the pipewire package (see the Pipewire project page for more information [6]). Daniel Stone gave a great LCA talk about Wayland in 2013 [5]. I have just converted two of my systems to Wayland. It s pretty uneventful, things seem to work the same way as before. It might be theoretically faster but in practice Xorg was fast enough that there s not much possibility to appear faster. My aim is to work on Linux desktop security to try and get process isolation similar to what Android does on the PC desktop and on Debian based phones such as the Librem 5. Allowing some protection against graphics based attacks is only the first step towards that goal, but it s an important step. More blog posts on related topics will follow. Update: One thing I forgot to mention is that MAC systems need policy changes for Wayland. There are direct changes (allowing background daemons for GPU access to talk to a Wayland server running in a user context instead of an X server in a system context) and indirect changes (having the display server and window manager merged).

• [1] https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)
• [2] https://en.wikipedia.org/wiki/Xephyr
• [3] https://wiki.debian.org/KDE
• [4] https://wiki.debian.org/Wayland
• [5] https://www.youtube.com/watch?v=cQoQE_HDG8g
• [6] https://pipewire.org/

Next week our friends at Igalia will be hosting this year s Web Engines Hackfest. Collabora will be there! We are gold sponsors, and have three developers attending. It will also be an opportunity to celebrate Igalia s 15th birthday \o/. Looking forward to meet you there! =) Carlos Garcia has recently released WebKitGTK+ 2.14, the latest stable release. This is a great release that brings a lot of improvements and works much better on Wayland, which is becoming mature enough to be used by default. In particular, it fixes the clipboard, which was one of the main missing features, thanks to Carlos Garnacho! We have also been able to contribute a bit to this release =) One of the biggest changes this cycle is the threaded compositor, which was implemented by Igalia s Gwang Yoon Hwang. This work improves performance by not stalling other web engine features while compositing. Earlier this year we contributed fixes to make the threaded compositor work with the web inspector and fixed elements, helping with the goal of enabling it by default for this release. Wayland was also lacking an accelerated compositing implementation. There was a patch to add a nested Wayland compositor to the UIProcess, with the WebProcesses connecting to it as Wayland clients to share the final rendering so that it can be shown to screen. It was not ready though and there were questions as to whether that was the way to go and alternative proposals were floating around on how to best implement it. At last year s hackfest we had discussions about what the best path for that would be where collaborans Emanuele Aina and Daniel Stone (proxied by Emanuele) contributed quite a bit on figuring out how to implement it in a way that was both efficient and platform agnostic. We later picked up the old patchset, rebased on the then-current master and made it run efficiently as proof of concept for the Apertis project on an i.MX6 board. This was done using the fancy GL support that landed in GTK+ in the meantime, with some API additions and shortcuts to sidestep performance issues. The work was sponsored by Robert Bosch Car Multimedia. Igalia managed to improve and land a very well designed patch that implements the nested compositor, though it was still not as efficient as it could be, as it was using glReadPixels to get the final rendering of the page to the GTK+ widget through cairo. I have improved that code by ensuring we do not waste memory when using HiDPI. As part of our proof of concept investigation, we got this WebGL car visualizer running quite well on our sabrelite imx6 boards. Some of it went into the upstream patches or proposals mentioned below, but we have a bunch of potential improvements still in store that we hope to turn into upstreamable patches and advance during next week s hackfest. One of the improvements that already landed was an alternate code path that leverages GTK+ s recent GL super powers to render using gdk_cairo_draw_from_gl(), avoiding the expensive copying of pixels from the GPU to the CPU and making it go faster. That improvement exposed a weird bug in GTK+ that causes a black patch to appear when shrinking the window, which I have a tentative fix for. We originally proposed to add a new gdk_cairo_draw_from_egl() to use an EGLImage instead of a GL texture or renderbuffer. On our proof of concept we noticed it is even more efficient than the texturing currently used by GTK+, and could give us even better performance for WebKitGTK+. Emanuele Bassi thinks it might be better to add EGLImage as another code branch inside from_gl() though, so we will look into that. Another very interesting igalian addition to this release is support for the MemoryPressureHandler even on systems with no cgroups set up. The memory pressure handler is a WebKit feature which flushes caches and frees resources that are not being used when the operating system notifies it memory is scarce. We worked with the Raspberry Pi Foundation to add support for that feature to the Raspberry Pi browser and contributed it upstream back in 2014, when Collabora was trying to squeeze as much as possible from the hardware. We had to add a cgroups setup to wrap Epiphany in, back then, so that it would actually benefit from the feature. With this improvement, it will benefit even without the custom cgroups setups as well, by having the UIProcess monitor memory usage and notify each WebProcess when memory is tight. Some of these improvements were achieved by developers getting together at the Web Engines Hackfest last year and laying out the ground work or ideas that ended up in the code base. I look forward to another great few days of hackfest next week! See you there o/

Inspired by a discussion in #wayland today, here are snippets from three people explaining why X declares its DPI as 96, and why a single 'DPI' sledgehammer isn't actually what basically anyone<super>*</super> wants. Please read them. Thanks. Adam Jackson:

I am clearly going to have to explain this one more time, forever. Let's see if I can't write it authoritatively once and simply answer with a URL from here out.

Matthew Garrett:

But what about the single monitor case? Let's go back to your Vaio. It's got a high DPI screen, so let's adjust to that. Now you're happy. Right up until you plug in an external monitor and now when you run any applications on the external display your fonts are twice the size they should be. WOOHOO GO TEAM of course that won't make us look like amateurs at all. So you need another heuristic to handle that, and of course "heuristic" is an ancient african word meaning "maybe bonghits will make this problem more tractable".

Federico Mena-Quintero:

People who know a bit of typography may know a few factoids:
- Printed books generally use fonts which can be from about 9 to about 12 points in size.
- A point is roughly 1/72 of an inch. For people in civilized countries, this translates to "I have no idea what the fuck a quarter pounder is".

*: Yes, I know you need to have actual point equivalence, and you've had all your displays and printer colour-calibrated for the past ten years too. You're doing all this in the GIMP or some other kind of design tool, so please yell at them to use the display size information that XRandR gives you right now, already, today.

My current running Xorg server, built with -O0 -g3 -ggdb, having been through a few suspend cycles, hosting a full GNOME Shell session with several billion tabs in a long-running Chromium instance, a couple of terminals, and a freshly-opened gedit, is currently sitting at 20MB resident memory usage, of which 11MB is shared. The freshly-opened gedit instance has 25MB resident, of which 17MB is shared. Bloat is in the eye of the beholder, I guess.

(Those numbers are RES/SHR respectively in top. Correct me if I'm wrong about what they mean.)

So, I've been working on multitouch on and off the past few months (which have included a solid ten weeks of holiday), but have finally posted the third patch series, which I think should be pretty close to final, to the list today.

Touch events look kind of similar to standard Xi 2.1 events (DeviceMotionNotify and friends), but the implementation of grabbing and event delivery is quite different from the traditional X model that we all know and love.

Firstly, touch grabs are not strictly grabs as with other input events. When a synchronous pointer or keyboard grab activates, it 'freezes' the device, stopping delivery of all further events until the grabbing client has decided what to do. The client can either pass on the event to the next client (replay), opt to continue receiving all events with the device freezing again after each event (synchronous mode), or continue receiving all events with the device unfrozen (asynchronous). While this is happening, the grabbing client is the only one receiving events, hence the name.

Touch grabs break both of these assumptions. Firstly, the device never freezes: delivery of all events (pointer, keyboard, touch, whatever) continues at full tilt, and a touch grab never affects pointer or keyboard events, with the possible future exception of pointer events that are emulated from touch events. Secondly, all clients with grabs, as well as the client with the first selection we find<super>0</super>, receive the events. An 'owner' flag is set (or unset) to indicate to the client that it does, or does not, own the touch stream in question.

The owner principle is important: the theory is that all touch streams must be considered as a whole (i.e. from init, through all the motion events, to the touch stream ending), and cannot be separated into component parts. So a client which does not own a touch stream can do gesture recognition or whathaveyou in the background, but must not act upon it until it becomes the owner. We added an extra request, XIAllowTouchEvents, to control ownership: clients can either reject ownership, passing it on to the next in line, or assert their ownership and permanently remove all other clients from the delivery list.

So it's somewhat different, but (hopefully) not without reason. The motivation behind this was to keep latency as low as humanly possible, since people seem to demand lower latencies from direct touch-based devices. Sticking to the traditional grab model would have meant a flurry of round trips between all the clients in the stack and the server, as well as maintaining huge buffers in the server for every touch event, which each client would have to transfer in turn.

This model is a compromise between my original design and Ubuntu's suggested design; both of us had far more simple designs, but oriented towards different usecases. The original Ubuntu usecase was for a global gesture recognition system, which apps would only opt out of in rare cases. My primary usecase was exactly the reverse: apps doing their own gesture recognition, with a very small, if any, global system. Hopefully it's actually the best of both worlds, rather than the worst possible intersection: I guess we'll find out. :)

At the moment, it's all largely theoretical, but some of the Nokia Qt guys are working on a port and have provided really helpful feedback, and hopefully the GTK+ multitouch branch, which was written against a much earlier and, er, speculative, version of the spec, gets updated too.

Finally, some thanks: to both Nokia and my excellent employer Collabora for sponsoring my part of this work; to Chase Douglas from Canonical for his contributions and for not just giving us the finger and vanishing when we rejected the X Gesture Extension, but hanging around and working through it; and to Peter Hutterer, for spec work and review. There were also numerous others involved earlier (including, but not limited to, Henrik Rydberg working on mtdev and others) who deserve credit, so sorry if I forgot anyone.

If you want to get it and play around with it, the patches/repositories are all laid out in my initial mail linked to earlier, as well as the follow-up mail noting the evdev repository location. The spec has more details, and will hopefully be cleaned up to be a lot less clunkily-written.

[0]: The delivery order is unchanged. For grabs, we start at the root window and proceed down the window stack to the innermost child window, activating grabs in that order. For events selected for with XISelectEvents, we start at the innermost child window, work our way up towards the root window, and stop as soon as we find one.

Whenever someone asks how to force their window to be raised to the top in X, because their program is so great that their users shouldn't be allowed to even see other programs, the answer looks a lot like the Windows equivalent:

Yes, I realize you wrote a program so awesome that all other programs pale in comparison, and that part of your mission is to make all the other programs literally pale in comparison to your program. Sorry. Maybe you can meet up with that other program that is the most awesome program in the history of the universe and share your sorrows over a beer.

Just a reminder that the linux.conf.au 2011 call for papers is closing THIS SATURDAY, 14th August! If you haven't already submitted your talk, get in now while you still can ...

So, #collabora was putting chunks of code into iwritelike.com, and I decided to join in the fun. While Telepathy, GStreamer and other similarly soft projects are all apparently written like Dan Brown or David Foster Wallace, I put a chunk of xkbActions.c into iwritelike.com, and apparently it's written like Chuck Norris. Brilliant.

So, flipping through the otherwise good MeeGo SDK setup instructions, I was pretty disheartened to see this:

Next, configure X on the host machine to enable the Simulator (running from the chroot) to access the display of the normal user:

xhost +local:

This gives everyone who can execute anything on your machine full permission to rip your credit card numbers out of Chromium and your password out of gnome-terminal. Sweet. This comes up all the time, so man wouldn't it be great if there was some kind of better way?

xhost +SI:localuser:usernametogiveaccesstogoeshere

I'm pretty sure this has been available in every single X.Org release since 6.8 or so, so next time you see someone advocating something as daft as the above, please point them towards the correct way. Thanks.

(Pushed it with the wrong date originally; couldn't fix it without bumping it to the top again. Sorry!)

So, flipping through the otherwise good MeeGo SDK setup instructions, I was pretty disheartened to see this:

Next, configure X on the host machine to enable the Simulator (running from the chroot) to access the display of the normal user:

xhost +local:

This gives everyone who can execute anything on your machine full permission to rip your credit card numbers out of Chromium and your password out of gnome-terminal. Sweet. This comes up all the time, so man wouldn't it be great if there was some kind of better way?

xhost +SI:localuser:usernametogiveaccesstogoeshere

I'm pretty sure this has been available in every single X.Org release since 6.8 or so, so next time you see someone advocating something as daft as the above, please point them towards the correct way. Thanks.

So, I spent an hour or two this afternoon following the iPhone 4 liveblog. It all looked fairly compelling (the screen!), right up until Steve's 'and one more thing': video calling.



HELLO I'M IN 2007, CAN YOU HEAR ME
(Photo of the Nokia N800, which shipped in January 2007, from rnair.)

The moral of the story? If you want to be four years ahead of the WWDC closing bombshell, email sales@collabora.co.uk. :)


PS: The 2010 'fuck it, we're going to fivefour blades' version; we also had a six-way video call going earlier today.

'Can you get cp to give a progress bar like wget?'

DoctorMO is calling Paypal the Pocketing Police after this Paypal [...] decided we were scammers and took our money comment by Daniel Stone during the Xorg foundation election discussions. Our co-op has avoided Paypal for a number of years for two reasons:

1. Paypal didn t recognise UK company registration numbers that contain letters (like ours) for years after they first occurred, so we couldn t register as a seller;
2. the terms and conditions are very unequal, there are shedloads of complaints like paypalsucks.com and I don t believe they re all fiction.

We ve not boycotted it yet because there are two of our current suppliers who are very expensive for us to pay by international bank transfer, accept Paypal and don t offer much alternative. I think I ll go ask them again. At least one of them should be sympathetic to Xorg.

I'm glad to see that Sam 'When All Else Fails, Call 'Em Racists' Varghese has admitted that he's definitely not a part of the open source community. Which is good, because I'd be pretty upset if he was. (Though his claim to be a professional journalist is no doubt fairly upsetting and phenomenally insulting to actual journalists.)

'I give permission for IBM, its customers, partners, and minions, to use JSLint for evil.'

As ajax quite elegantly summed up, due to a series of catastrophic power failures at PSU, where fd.o is hosted, we were down for a good chunk of yesterday. Despite the machines having redundant power supplies, being connected to separate power rails in the rack, which were hooked up to independent, UPS-backed, power supplies, we still (like a good chunk of Portland, and certainly everyone in the PSU machine room) lost our power.

As far as we can tell, when annarchy.fd.o (websites, people.fd.o, cgit, anongit, et al) came back up, power was again interrupted while the ext3 journal was being replayed. When it came up the n'th time, fsck dumped almost the entire filesystem in lost+found, then started saying increasingly unhappy things about the state of the filesystem on its second pass. In the end, we just went with mkfs, and now we have a brand new and shiny filesystem.

It's worth pointing out that even if this was another filesystem, such as /srv, which hosts all project data, we would've been fine, as they're all backed up. But, unfortunately for some, we made a decision a while ago to not back /home up, and didn't advertise that as widely as we should have. So, if you had stuff in annarchy:/home, it's now gone, and I hope you have backups.

Sorry about that. On the upside, I got to see PSU's new and really very nice machine room this morning, thanks to XDC being about 250m away from the PSU machine room, and fd.o is otherwise running fine. We've been talking this week about replacing our ageing hardware, which would also allow for more redundancy as well as better performance from those machines. But we still have no plans to back up /home, so if you put stuff there, please, please keep your own backups (or make sure the Wayback Machine knows about it).

Since all the cool kids are doing it, here are some of the more interesting stats from the Google analysis tools. The third most popular search term used to hit my site has been 'jdub' of late, which is a bit worrying. Number five is 'scandinavian window systems' (?), number fifteen is 'abortions', number seventeen is 'word up for hilltop hoods' (okay, I share the sentiment, but will Googling for it really be that useful?), and number eighteen is 'bluetooth beatbox', which really defies explanation beyond being a googlewhack, but it's not even that.

The mind boggles. At least it's not quite as odd as when I maintained a very large, Google-indexed, IRC quotes file.

So, thanks to the effort of our fearless team, new Xorg hotness is available, and even brings those blue sparks. You might note that this is a mere five months after X11R7.0, and note the 7.2 release plans, which have us releasing X11R7.2 in a mere six months. We're back. Oh yes, we are back.

Luis, If you can still find the ThinkPad T43 around, it would seem to be a perfect fit for your needs. It's 1400x1050, has an ATI X300 SE in it (supported by Free drivers, including DRI), and the wireless is Centrino, which only has the firmware problem. The only thing wrong with it is that it's a behemoth both in size and weight compared to my dainty little X40, but I guess that's what you wanted if you were asking for T series recommendations.

While I'm here, you all get a bonus picture of the moon over the Baltic:


If you zoom in, you can see that it's roughly four picodegrees over the sea. Brilliant.

Sorry for the hideously late announcement, but an extraordinary comedy of errors involving quite a long chain of people and a series of unfortunately timed holidays meant we couldn't confirm this until now.

Anyway, the 2008 X Developers' Summit will be held from Sep 3rd-5th at Edinburgh Zoo (nearest airport EDI, or overnight sleeper train from London). More details and links to come later today. See you there!