Igalia has been developing a new open source Mesa driver for the Raspberry Pi 4 since December 2019, and FOSDEM 2021 had a presentation with the status of the driver at that point. This talk will describe the current status of the driver, and discuss the improvements on the driver since last year presentation, focusing on all the work that was done to improve the driver performance, and a high level overview of the path that got the driver Vulkan 1.1 conformant. Finally, we will talk about future plans and how to contribute to the on-going development effort.

Igalia has been developing a new open source Mesa driver for the Raspberry Pi 4 since December 2019. This talk will discuss the development story and current status of the driver, provide a high level overview of the major design elements, discuss some of the challenges we found in bringing specific aspects of Vulkan 1.0 to the V3D GPU platform and finally, talk about future plans and how to contribute to the on-going development effort.

arbglspirv: bringing SPIR-V to Mesa OpenGL

Since OpenGL 2.0, released more than 10 years ago, OpenGL has been using OpenGL Shading Language (GLSL) as a shading language. When Khronos published the first release of Vulkan, almost 2 years ago, shaders used a binary format, called SPIR-V, originally developed for use with OpenCL.

That means that the two major public 3D graphics API were using different shading languages, making porting from one to the other more complicated. Since then there were efforts to allow making this easier.

On July 2016, the extension ARBglspirv was approved by Khronos, that allows a SPIR-V module to be specified as containing a programmable shader stage, rather than using GLSL, whatever the source language was used to create the SPIR-V module. This extension is now part of OpenGL 4.6 core, making it mandatory for any driver that wants to support this version.

This talk introduces the extension, what advantages provides, and explain how it was implemented for the Mesa driver.

Imagine trying to use your computer, tablet, or phone and being unable to: not due to a dead battery or lack of connectivity, but rather because there was some setting... somewhere... which you had to locate and enable on that device before you could use that device.

This unfortunate catch-22 is something that GNU/Linux users with disabilities have had to struggle with for years, because using the accessibility features of their environment required first enabling accessibility support for that environment -- or find someone to do so for them. And yet there was nothing these users could do to change this situation because enabling accessibility support by default would result in instability and performance degradation for all users.

GNOME has long felt that this was a condition which could not continue, and slowly but surely began identifying and tackling these issues. In 2012, things had improved to the point that the developer community felt confident that enabling accessibility support by default was something worth attempting. The end result: GNOME 3.6 was the first GNU/Linux graphical desktop environment to be released with no ""enable accessibility"" setting. For our users, accessibility is always on.

This talk will provide an overview of the steps we took to make our desktop environment immediately accessible to users with disabilities without any associated negative impact on other users. And it will include the specific steps you need to take to accomplish the same thing for the software you develop, because software freedom should include the freedom to ""just use"" your devices.

In GNOME, accessibility is a core value that touches all aspects of the system. [1] From the infrastructure, to the graphical toolkit, to the applications, to the assistive technologies, accessibility has been a central consideration from the very early days. On April 2011 GNOME 3.0 was released, and although GNOME and the accessibility made a huge effort, the accessibility support was not ideal. But not are bad news. Finally the accessibility technologies are starting to be used from the two main free desktops. AT-SPI is starting to be used on KDE distros, and Orca is starting to be functional with Qt apps. Since GNOME 3.0 a big effort was done in order to improve the situation. At the moment of this proposal writing an ATK/AT-SPI2 hackfest is being organized, in order to fix the issues from the framework itself. The purpose of this presentation is explaining: * Introduce accessibility on GNOME. * Briefly explain the status towards GNOME 3.4 * Summarize the output of the ATK/AT-SPI2 hackfest * Compare GNOME 3.0 vs GNOME 3.4 * KDE status and cooperation * Future [1] http://library.gnome.org/devel/accessibility-devel-guide/nightly/gad-how-it-works.html.en