BlinkOn 2: Zürich

Last  week I traveled to Zürich to attend to BlinkOn 2 at the office Google has there. This is the first time the event is done in Europe (previous one at US) and it was a very good opportunity to meet all the people working around Blink, Chromium and Skia.

Zürich photograph


As Igalia has a long experience working on browsers technologies, it was represented by four igalians who are working on different areas: Manuel Rego on CSS, Xabier Rodríguez on multimedia and Eduardo Lima together with me on graphics and Skia.

The attendees of this conference were not only googlers, there were people from Opera, Samsung, Intel and much more companies interested on meeting each other and collaborate to improve Blink.

Google Zürich office

Google Zürich office


The talks were covering a lot of different areas of a browser: from memory leaks or image filters to security models to name a few of them. Worth to mention Manuel Rego’s talk which was about his latest work on CSS Grid Layout (more details in his blog).

BlinkOn 2 photo

BlinkOn 2

I have attended to the talks more related to graphics on the browser as this is one of the areas I am currently working on: “Rendering for Glass Time“, “Responsive images“, “Chasing Pixels“, “Filter effects“, “Storage modes for 2D canvas” and “60fps on mobile“.

I would like to highlight the talk given by Justin Novosad (Google) where he explained his proposal of different storage modes for 2D canvas: persistent memory, discardable memory and none. Each one with different use cases and consequences on memory usage with focus on mobile devices dealing with very large canvases and there was a discussion about how to provide a useful API for web developers.

I attended to more that the aforementioned talks: the always interesting “Memory leaks in Blink” report, “Web animations“, “Out-of-process iframes“, “Smooth to the touch: challenges in input on mobile“, the Opening talk and “Trace reading clinic” which was very useful to learn more about the tracing tools available in Chromium.

This conference was also the excuse to meet some Skia developers in person and talk about Igalia’s contributions and future work on this 2D graphics library.

I would like to thank Google for its great job organizing BlinkOn at its office in Zürich and also Igalia for sponsoring my trip.

Logo Igalia


But as not everything would be work, I also met an old friend who is working at Google to give me an update of his last years  while drinking good coffee.

At the last day, just before returning home, I bought a very appreciated gift for my relatives… good Swiss chocolate! Yummy!

Convocatoria de Asamblea General Ordinaria de Socios de AsturLiNUX

Queda convocada una Asamblea General Ordinaria de Socios de AsturLiNUX para el Sábado 17 de Mayo de 2014, a las 16:30 en primera convocatoria y a las 17:00 en segunda convocatoria. El lugar será el Hotel de Asociaciones de Oviedo.

El orden del día es el siguiente:

1. Lectura y aprobación del acta de la Asamblea anterior
2. Estado de la asociación
3. Renovación de la Junta Directiva
4. Próximas actividades
5. Ruegos y preguntas

Hágase notar el punto segundo, donde se discutirá si los socios desean darle continuidad a la Asociación, o alternativamente comenzar a organizar y planificar los trámites de disolución. Por lo tanto, la Junta Directiva se renovará en función a las decisiones tomadas en el citado punto del orden del día.

Dada la importancia de los temas a tratar, se ruega la máxima asistencia posible.

Para los que no puedan asistir presencialmente, se organizará un evento de Google Plus con Hangout para poder participar remotamente. En la lista de correo ha comenzado una discusión preliminar del segundo punto del día (continuidad de la asociación). Asimismo, si cualquier tipo de presencia en la asamblea es imposible, Samuel se ha ofrecido voluntariamente a coleccionar vuestros comentaros/opiniones/pensamientos vía correo electrónico y a transmitirlos presencialmente durante la Asamblea de socios.

Más información en la web de AsturLiNUX.

AIME on Technology of Controls for Accelerators and Detectors

Last week, Javier Muñoz and myself attended the conference HEPTech Academia – Industry Matching Event on Technology of Controls for Accelerators and Detectors, which was hosted at DEMOKRITOS, Athens.

The target of this event was to have Academia and Industry together in the same place to share ideas and potential applications around Control Systems. Igalia was invited to participate as member of the Industry side to talk about our collaboration with CERN on Linux device drivers, KiCAD and HW virtualization areas.

Open Hardware slideThe conference’s agenda covered very exciting control system’s technologies used by High Energy Physics facilities. For example, CERN staff explained ATLAS and CMS detectors control systems, what they are planning to do for next years and how the next-gen accelerator, CLIC, is being designed.

However, there were also very good talks from other accelerators. One of the talks explained how the proton therapy cures eye cancer with a huge percentage of success. I recommend you to check out all the slides from the agenda because you will learn how the accelerator’s control systems are made and how the companies are collaborating on this area. Very interesting for both scientists and engineers!

Our talk was part of the “Open Hardware vs Conventional Development approach” track, where concepts like Open Hardware or projects like WhiteRabbit were explained to the audience. We were explaining our work developing the FMC TDC driver and how QEMU helped us a lot to debug the driver and improve its robustness by using SW techniques such as continuous integration and testing. Our slides are publicly available if you want to read them.

In the same track, we represented Igalia in the round table by giving our opinion about Open Hardware and sharing some advices based on our experience in the Free Software world that can be applied on Open Hardware based companies.

I would like to finish this post by saying that the organizers did a great job in taking care of the success of the event. Everything was well explained and organized, even when this was the first event of this kind organized around control systems for accelerators and detectors.

Introduction to Linux Graphics drivers: DRM

Linux support for graphics cards are very important for desktop and mobile users: they want to run games, composite their applications and have a nice and modern user experience.

AGP Video Card photo

So it’s usual that all the eyes are on this area when you want to optimize your embedded device’s user experience… but how the graphics drivers communicate with user-space applications?

Víctor Jáquez, from Igalia, wrote a very nice introduction to this topic. If you are interest on Linux graphics stack in general, you have this post wrote by Jasper St. Pierre.

Direct Rendering Infraestructure schema

Direct Rendering Infraestructure schema (by Víctor Jáquez)

The Direct Rendering Infrastructure (DRI) in Linux is like is shown at the above picture. Using Xorg as an X server example, we see that it is in charge of X11 drawing commands along with Mesa or Gallium3D as the OpenGL software implementation for rendering three-dimensional graphics.

How they communicate with the actual HW? One possibility is using libdrm as a backend to talk with the Direct Rendering Manager at Linux kernel. DRM is divided in two in-kernel drivers: a generic drm driver and another which has specific support for the video hardware.

There is a Xorg driver running in user-space who receives the data to be passed to the HW. Using Nouveau as an example, the xf86-video-nouveau is the DDX (Device Dependent X) component inside of X stack.

It communicates with the in-kernel driver using ioctl. Some of them are generic for all the drivers and they are defined in the generic drm driver. Inside of drivers/gpu/drm/drm_drv.c file you have the relationship between the ioctl number, its corresponding function and its capabilities.

However, the specific driver for the video hardware can define its own ioctls in a similar way. For example, here you have the corresponding ones for the Nouveau driver (drivers/gpu/drm/nouveau/nouveau_drm.c file).

As you can see, most of these ioctls can be grouped by functionality:

  • Get information from the drm generic driver: stats, version number, capabilities, etc.
  • Get/set parameters: gamma values, planes, color pattern, etc.
  • Buffer’s management: ask for new buffer, destroy, push buffer, etc.
  • Memory management: GEM, setup MMIO, etc.
  • Framebuffer management.
  • In case of Nouveau: channel allocation (for context switching).

Basically, the xorg user-space driver may prepare a buffer of commands to be executed on the GPU and pass it through a ioctl call. Sometimes, it just want to use the framebuffer to draw on the screen directly. Others, it uses KMS capabilities to change parameters of the screen: video mode, resolution, gamma correction, etc.

There are more things that DRM can do inside of the kernel. It can setup the color pattern used to draw pixels on the screen, it can select which encoder is going to be used and on which connector (LVDS, D-Sub, HDMI, etc), pick EDID information from the monitor, manage vblank IRQ…

At Igalia we have a long background working in Linux multimedia stack (GStreamer, WebGL, OpenCL, drivers, etc). If you need help to develop, optimize or just you want advice, please don’t hesitate to contact us.

A great year has passed

Exactly one year ago, it was my first day as Igalia employee. I had arrived from Geneva some days before, I had rented an apartment here in Coruña the day before. I was very nervous and willing to start.

Today, I can say I am more than happy to be working for this company: I started contributing drivers upstream, I became one of the official maintainers of them, I went to LinuxCon Europe, gave talks at OSHWCon Madrid 2012 and 7th White Rabbit workshop, I learned a lot of things… but the most important thing is that I made real friends here.

Regarding my personal life, everything has been getting better last year. Living so close to my parent’s home gives me the possibility to see my relatives and friends more often. I just need to drive 3 hours and I am there!

I don’t know what is going to happen next year, but I am sure it’s going to be awesome :-)

7th White Rabbit workshop

This week I traveled to Madrid where the 7th White Rabbit workshop was held. It was a two day event where the White Rabbit community presented all the latest development efforts, installations, the White Rabbit standardization process and much more. It was amazing to find a broad range of experiments using or considering to use this technology, the applications, the new PCB designs to come, etc.

Apart from Research institutions like CERN, GSI, DESY, NIKHEF among others, there were a lot of HW companies that design, manufacture and support all the required boards needed by the experiments. They were showing their products like the White Rabbit switch and Sevensols‘s White Rabbit starter kit.

I went there to present, together with Javier Muñoz, the latest work Igalia‘s OS team did. We spoke about testing and how virtual HW helps on this task. We showed our experience on the FMC TDC driver development, the FMC TDC’s virtual model and its integration in a testing suite with continuous integration.

Also, some software companies were there, like Gnudd represented by Alessandro Rubini, Integrasys and others. They were describing their work on the software part: FMC bus drivers, sdbfs filesystem, White Rabbit switch software, etc.

I found this event very interesting to share ideas, talk about technologies and plan new designs to improve all the White Rabbit stack.

I wouldn’t like to finish this post without saying anything about the organization. It was a perfect event: CDTI made a great work hosting the event at their offices and BE/CO/HT section at CERN organizing the rest.

FMC TDC driver

During last few months we have been involved in the development of FMC TDC software support for Linux, i.e., writing a driver for it along with an user-space library and a bunch of test programs.

But first of all, let me show you what is a Time-to-Digital converter (TDC)

In electronic instrumentation and signal processing, a time to digital converter (abbreviated TDC) is a device for recognizing events and providing a digital representation of the time they occurred. For example, a TDC might output the time of arrival for each incoming pulse. Some applications wish to measure the time interval between two events rather than some notion of an absolute time.

Source: Wikipedia

In summary, it measures the time of arrival of each incoming pulse and saves the timestamp into the memory, ready to be read later on by the user. This time, this is a mezzanine board plugged to a carrier board across the FMC bus, hence its name.

FMC TDC board image

The board was designed by CERN to fulfill their needs in the control system. They published the schematics and all the needed design files under CERN Open Hardware license. You can check them out from its project page at OHWR website. Remember that it is still in the prototyping phase.

The FMC TDC driver depends on ZIO framework and FMC bus driver to work. Also, as we were developing it using the SPEC board as a carrier board, the SPEC driver is needed to perform the I/O operations from/to the FMC TDC board.

There is still work to be done like adapting the code to last ZIO changes and improve the documentation, but it is quite close to what we can call “1.0″ version :-)

All the code is hosted in OHWR, under its own project. If you are interested on following its development, I recommend you to subscribe to the mailing list.