Accessibility at the GTK Hackfest 2020

Old town

The GTK 2020 hackfest took place last January, just before FOSDEM 2020, in Brussels, Belgium. The focus was on GTK4 schedule and pending work, and on the state and future of accessibility in GTK4. I only attended the second half, the accessibility part, which is my job’s focus working at Hypra, a small French company focusing on free and open source accessibility and computer literacy.

I was slightly scared of how the meeting would go at first, because some discussions prior to the hackfest gave an impression that accessibility as not something GTK would keep on supporting and promoting anymore.

There were legitimate concerns about the state of affairs in the technical side of GUI accessibility in GTK and Linux more generally: despite GTK being the most usable toolkit for accessibility users for a long time, the technology leveraging it grew old and didn’t adapt to the environment around it, mostly due to lack of attention and resources. There were also legitimate concerns that some things didn’t actually work so well, which again is mostly due to code aging and lack of resources to keep it current during more than a decade, with only a handful of people working on this on their spare time.

Basically, GUI Linux accessibility was left behind since the mid-2000s and struggled to catch up more and more with new technology replacing other aging ones, and Wayland sounding like it would be the last punch it needed to fall.

Fortunately, the meeting, and most importantly the people attending it, quickly wiped off my fears: GTK developers present were clearly on board and motivated, interested in learning more about a variety of accessibility use cases, and willing to get their hands dirty to build a brighter accessibility future on Linux.

Met GTK, Mutter, AT-SPI, Hypra developers and trainers, and a few other developers relying on accessibility for their day-to-day computer usage. We had a healthy proportion of people actually relying on accessibility every day, and a wide knowledge of usages and needs, allowing to discuss and showcase some of them for everyone’s understanding. This gave a great mix of technical and sociological knowledge about accessibility and lead to relevant and focused discussions on how to shape its future under Linux.

Together, we managed to refine and agree on the tasks needed to move forward, dispatch them and set up a roadmap. Don’t get too excited just yet because there is quite some work ahead of us, but I’m confident we are going in the right direction and will get concrete results in the upcoming quarters.

Even if we’re still greatly under-resourced in the care of accessibility, I’m happy to see things moving again, and hopeful that with a refreshed and consolidated ground this will become a less scary topic and get more attention and resources.

Next step would be to raise awareness to the general developer, and spread knowledge about things to do or not to do at the application level. We discussed this as well and plan to improve documentation and facilitate developer’s work (“make it easier to do it right and harder to do it wrong”), but it will only really spread if accessibility stops being seen as a niche irrelevant to most, and fortunately, you can help with this! Take it seriously, document yourself and spread the word: often only little effort it is required to make things better for everyone once one knows what to do.

A beer to celebrate!

I wish to thank every single one of the attendants for their involvement, commitment and effort in getting things moving again and on the right track. I’d like to especially thank Emmanuele Bassi who was a great interlocutor and who will undertake a large part of the work, and Samuel Thibault for his still unmatched versatility around accessibility topics. But truly everyone was key for making this meeting so pleasant and fruitful, thanks again!

RV350 et XVideo

J’ai installé Debian Squeeze sur un Asus A3000 pour une amie il y a quelques jours, sans anicroches1. Wifi ipw2200 avec le firmware qui va bien (firmware-ipw2x00) ; lecteur de cartes SD ; veille ; accesskeys ; et même un peu de 3D (c’est une 9600M, faut pas rêver non-plus). Tout va bien sans aucune manip, mis à par l’installation du firmware non-libre.

Sauf qu’aujourd’hui, sa propriétaire passant le chercher après quelques jours de vacances, elle l’essaie. Je reste à côté, la laissant s’habituer à GNOME (elle avait Lenny sous KDE 32) et répondant à deux-trois gentilles questions – auxquelles elle aurait répondu elle-même si je n’avais été là d’ailleurs. Jusqu’au moment ou elle essaie de lire un film. Ça fonctionne… presque : l’image saccade.

Comprenez ma petite gêne, mon installation peaufinée trois jours plus tôt3 ne marche finalement pas si bien que ça. Ni d’une ni de deux, mon instinct geek refait surface et commence à chercher. Diagnostique simple : XV ne fonctionne pas, il n’y a donc pour ainsi dire pas d’accélération. Je vérifie, mais oui, la Mobility Radeon 9600 M10 (RV350) est supposée être très bien supportée par le pilote radeon de Squeeze. Continuant posément sur ma lancée, je jette un œil au log de Xorg, qui me le confirme, j’utilise bien radeon mais tout ne se passe pas si bien… cependant, le log est peu explicite sur le problème, et se borne à lister une série de disabled pas spécialement engageants, mais finalement pas si terribles. Après deux-trois essais à feinter Xorg en lui suggérant des options – inutiles – dans un xorg.conf manuel, je me reporte à la source de bien des solutions : internet. Pour une fois il n’est pas très bavard, pas grand chose au sujet d’une RV350 sans XVideo. Qu’importe, quelqu’un, quelque part, suggère d’utiliser fglrx. Je n’ai pas l’habitude d’installer le pilote propriétaire (et soyons honnête, celui d’AMD est loin d’être parfait) là où le libre devrait bien fonctionner, mais puisque ce n’est justement pas le cas, je me prépare à essayer.

Il me faut donc décharger radeon et installer fglrx. Je ne sais pas trop pourquoi, je commence par enlever radeon avant même d’installer fglrx, et bien-sûr de nos jours radeon utilise le KMS et ne peut donc être retiré si facilement – il ne faut pas que le modsetting ait été activé. Je reboot donc (avant même une tentative, qu’on ne me prenne pas pour un manche – j’avoue, c’est uniquement que j’ai déjà donné) et ajoute un petit radeon.modeset=0 sur la ligne de boot du noyau. Ça démarre, sans modesetting donc. Et là, pour une raison que j’ignore encore, je vérifie que XV ne fonctionne toujours pas, peut-être qu’un miracle… et oui, xvinfo trouve maintenant un adaptateur ! Je teste, et encore oui, je n’ai pas rêvé, XVideo fonctionne vraiment.

J’apprends donc que le modesetting empêchait XVideo de fonctionner. Je ne sais toujours pas pourquoi, je ne peux que supposer que c’est un problème de quantité de mémoire – il semble qu’il y ai eu dans les 53M avec et maintenant 64M sans, si je déchiffre le log de Xorg correctement. Quoi qu’il en soit, j’ai maintenant désactivé le modesetting de façon permanente (dans /etc/modprobe.d/radeon-kms.conf), configuré Grub 2 pour définir la résolution des TTY au boot (GRUB_GFXPAYLOAD_LINUX=1024x768 dans /etc/default/grub), et ça fonctionne très bien. Je suis un peu déçu de devoir désactiver le KMS, mais finalement il n’est pas très utile ici, largement moins que XVideo en tout cas.

Voilà, la petite histoire est terminée, bonne nuit les enfants !

Notes

  1. À part pour la WebCam ALi M5603 qui ne semble pas avoir vraiment de pilote pour le moment – le seul que j’ai pu trouver ne semble pas encore être inclus à gspca, n’a pas subi de changement depuis plusieurs mois et semble être relativement ardu à compiler lorsque l’on est un novice des pilotes gspca. Cela étant, la WebCam ne sert pas, j’ai donc arrêté les frais assez rapidement.
  2. Hehe :p
  3. Pas sous ses yeux malheureusement, car pour une raison que j’ignore, le CD de netinstall n’avait pas (plus) les bonnes clés, et qu’elle était pressée – forcement ça calme quand on vous dit que c’est facile, on vous montre, et qu’en fait ça ne marche pas…