Excuse me while I kiss the sky 🌅🍄🟫
My brother’s award-winning book.
Recent content on Tiago Vignatti
My brother’s award-winning book.
Making PDFs readable for everyone.
Co-op principles for everyone.
Princípios para qualquer organização.
Principles for any organization.
Beyond the browser.
Chromium and friends in Seoul.
Wildfires and Igalia’s 20th.
Skateboards to VR.
Wedding, baby, and grandma’s birthday.
A beach.
It won’t run Rift apps.
About a year ago Ozone platform abstraction layer started to take its shape in Chromium and we were excited how easily we could s upport Wayland platform using it. Everything went great and we helped a few Chromium targets like Crosswalk to debut in the Tizen ecosystem for example. More recently, different Ozone platforms have been implemented and only now it’s becoming evident the…
Some state-of-the-art progress of the project we’re proudly working with: https://www.youtube.com/watch?v=EJB2pznc6iY
A few weeks ago we released Ozone-Wayland and now we’d like to detail for you the development process and strategy behind it… ah, and the title is not developing Chromium, the browser; it’s developing Chromium,** the project**! You will understand why next.
The following message was sent out this morning – I’m copying it here and attaching a cute screenshot of my desktop :) Ozone is a set of C++ classes in Chromium for abstracting different window systems on Linux. It provides abstraction for the construction of accelerated surfaces underlying Aura UI framework, input devices assignment and event handling.
Let’s forget for a second about video drivers, whether it has acceleration or not, and all the related issues with hardware support on Wayland. This is all solved . Let’s talk about the user interface (UI) and ways to customize it all over the computing continuum – from phones, tablets and TV box to desktop PCs, Invehicle Infotainment (IVI), aeroplane systems, among others.
Wayland 1.0 release is knocking the door and people keep asking “why Wayland if we got X already”, or things like performance, memory consumption, power savings and other kind of advantages on having Wayland instead X. Those are very important points to consider, of course, but for one individual actually programming the graphics system the answer should be straightforward: Wayland API…
A rather cool feature on Weston compositor is xwayland, to support X11 native applications on Wayland. It’s a quite important feature because gives the compatibility with the “old” windowing system, so say you have an application written on Motif/Xt or even something more “fancy” like a Web browser all tied with GTK2 and whatever dependency, then you better not bother…
Do you wanna contribute to a funky open-source project? Are you tired of your nerdy and boring community of developers? Are you the one that wants to get rid of X because it’s a giant, old and fat dinosaur in your system? :) Cool, I have a project to solve your problems!
To run Qt applications on Wayland is fairly simple nowadays. Thank to Qt developers, they are following up quite well our last changes on Wayland protocol and updating accordingly on Qt5 code base – by the way, the fresh and just released Qt 4.8 does not ship the latest protocol additions, so that’s not the one I’m referring.
Hello Intel Finland :) Here I am now; four months already at OTC big team.
Actually this is not a big news but it’s nice to see on practice X being used on the advanced age :) Here I’ve played with some UI configuration settings, browsed for while, toyed with facebook, opened some photos in the viewer and etc, all for about 5 minutes:
Following is the census of 1.10 window for all X infrastructure - raw numbers here . I did it in a similar way as the previous version . Worth to mention that there’s almost no relation between the cycles of development from each of the components listed below, which can lead to some misunderstanding. Anyway, still a nice indicative to see and evaluate how the free desktop community behaved.
I am a candidate for the elections 2011 of the board of directors :) Following are my answers based on the questionnaire formulated by the members. You can check other candidates answers here .
Moikka. If you follow here [0] you will see a set of Debian packages that Graphics team at Nokia are continuously working to deploy a X11 implementation for MeeGo-Harmattan , where we target embedded systems only. Feel free to use it!
Topic’s name is a funny (and friendly) devotion to GNOME Census . So let’s take a look at some numbers from the time Xorg 1.9 was in development - raw data is here . Would be unfair to measure only the work that happened e.g. in X server or in the drivers being developed and come up with the statistics about “who developed X”. X and X development community are quite…
That’s what I’m using for MeeGo now. Autoconf parameters, theeere we go: –disable-static –disable-aiglx –disable-config-dbus –disable-config-hal –disable-dbe –disable-dga –disable-dpms –disable-dri –disable-glx –disable-glx-tls –disable-int10-module –disable-ipv6 –disable-screensaver –disable-secure-rpc…
Last week I’ve been in Brazil at 11th International Free Software Forum (FISL) talking about Linux Graphics for Small Devices*. I tried to cover a bit of everything that I learned in the world I’ve been immersed in some near past - I guess there aren’t many news for freedesktopers though. Anyway, everyone is very welcome to give any kind of feedback and comment on it. Just follow…
Usually faster the number of commits, faster the development process. But development without strict reviewing doesn’t guarantee quality on the code. Unfortunately, rarely you will see people willing or even just being able to review the changes you are proposing. Attract reviewers is hard!
Previously, the message was for toolkit , now it targets new upcoming developers… okay, if I’d be offensive I could say it targets vendor distributions which care for desktop on Linux :)
We all know since 2006 (?) that the world is turning to use XCB instead Xlib as the interface between X clients and the server. The advantages of using XCB is well know but, even so, it’s being adopted very slowly for some reason - for instance no toolkits yet ported it. If this serves as a motivation, Alan got a really nice measurements porting a simple X app.
So here goes some statistics of the Xorg process running. All the informations were fetch from /proc/ pidof Xorg /{smaps, status}. I used also a script found on the Web to parse and organize these informations; Mikhail Gusarov has extended this script to show a very useful output .
This series of documents explore how the memory is used by the Xorg server. They aim to eventually shrinks the memory footprint of the server and its related components, like X clients, modules being loaded and drivers. Embedded devices with constrained resources are the main focus here. All texts are mostly based on x86 and ARM architectures, under Linux 2.6.33 with Xorg from upstream.
For the first time in life, Xorg is being used in a single platform and for a given device only (other devices have used an X11 implementation but using other non-canonical servers, such kdrive’s based - Tiny-X).
I like UI and I’m not gay. Some time ago someone posted a comment , complaining about the white fonts over the dark background in my blog, which makes the read be difficult. The guy teased me, recommending an ironic page where shows how hard is to read texts like this. He was right…
Just a thought is this something that should be deleted? This seems to be using about 7% of my RAM I don’t have words for it.
Portland, OR I was so proud for the forth time be part of the X crew, this time in Portland. Really amazing the city. I had the opportunity to play tourist and visit some nice places .
So last week I posted on lkml an old patch that we were carrying for a long time in the Linux community. It basically brings the multiple (old) video cards functionally again on Linux and X server (and this time doing on the right and beauty way). For the people that was following multiseat implementations, this is a HUGE step: we will finally be able to discard the old and ugly hack (a mix of…
… here I’am :)
Being quick about my last months: finished my Master course, moving to Helsinki tomorrow (!), got my first real job. Yessh, three great steps in my crazy life and I’m very happy with it! Hope to stay closer with the desktop communities again ;)
One thing that I learned with open communities is when you send a proposal idea and no one replies. This seems to be odd at first but it isn’t . If you did something strange or wrong then at least someone will reply. OTOH if you did something that can be promiser and no one objects, then great! 99% that you did something interesting :)
Trying to put some order with all the multiseat documentation found on Web, today I updated the following: Multiseat’s article, in X.Org Foundation wiki: http://wiki.x.org/wiki/Development/Documentation/Multiseat Multiseat’s history, in Wikipedia: http://en.wikipedia.org/wiki/Multiseat#History So if you are trying to setup or help in development, probably the foundation’s wiki…
This week our laboratory at university released the MDM utility to ease the process of installation and configuration of a multiseat box. The idea is that the end-user should not use some boring and hard howtos anymore to deploy it. Just installing a distro package must be enough now. Try it, use it, report the bugs and send the patches! :)
Unfortunately that model which I described some weeks ago to put the input event delivery of the X server in a separate thread wouldn’t be an advantage. I precipitated myself thinking that it could be feasible. Sorry :(
Input events routed through another thread/process can have bad effects on latency because we can’t guarantee that it will get scheduled at the right moment. Although this is hard to see happening with the current X server threaded implementation, we must design something to avoid it. One way to improve the responsiveness is to give a high priority to the input thread and also adjust the CPU…
Given that GSoC ‘08 is getting close to the end, strategy number 2 showed more feasible to proceed my work. Strategy #3 would be a lot of fun but would imply a hell massive codification as well (also a little out of our scope ). Unfortunately no-no for now.
GSoC summary #1 - July 29 The current implementation of X Window System relies in a signal scheme to manage the input event coming from hardware devices. This scheme frequently get blocked when lot of IO is occurring (for instance, when the process is swapping in/out). Get blocked means for instance a jumping cursor on the screen and in GUI is always desirable to prioritize the system…
The current DRM kernel modesetting tree is already taking care to update the cursor registers and paint it to the screen. Very cool [0]. What I’ve done today is a shortcut between the kernel input layer and DRM to update the cursor directly on screen without the X server be notified always. Of course, a lot of issues raised up together. So let’s try to delegates the tasks again.
I really don’t like to read large blog posts. Anyway… What I did so far is a separated thread that takes care only the injection stage on the X server queue. Who is interested with the results, please read some past posts in my blog. It is currently in a very good shape (synced with post-mpx merge, all input devices are inside the thread and etc). The implementation looks like this:…