I had been using my Samsung Galaxy S Relay 4G for almost three years when I decided to get a new phone. I would use this new phone for daily tasks and take the chance to get a new model for hacking in the future. My apexqtmo would still be my companion and would now be more available for real hacking.

And so it also happened that its power button got stuck. It was not the first time, but now it would happen every so often, and would require me to disassemble it. So I managed to remove the plastic button and leave it with a hole so I could press the button with a screwdriver or a paperclip. That was the excuse I needed to get it to running Debian only.

Though it's now always plugged on my laptop, I got the chance to hack on it on my scarce free time. As I managed to get a kernel I built myself running on it, I started fixing things like enabling devtmpfs. I didn't insist much on running systemd, though, and kept with System V. The Xorg issues were either on the server or the client, depending on which client I ran.

I decided to give a chance to running the Android userspace on a chroot, but gave up after some work to get some firmware loaded.

I managed to get the ALSA controls right after saving them inside a chroot on my CyanogenMod system. Then, restoring them on Debian allowed to play songs. Unfortunately, it seems I broke the audio jack when disassembling it. Otherwise, it would have been a great portable audio player. I even wrote a small program that would allow me to control mpd by swiping on the touchscreen.

Then, as Debian release approached, I decided to investigate the framebuffer issue closely. I ended finding out that it was really a bug in the driver, and after fixing it, the X server and client crashes were gone. It was beautiful to get some desktop environment running with the right colors, get a calculator started and really using the phone as a mobile device.

There are two lessons or findings here for me. The first one is that the current environments are really lacking. Even something like GPE can't work. The buttons are tiny, scrollbars are still the only way for scrolling, some of the time. No automatic virtual keyboards. So, there needs to be some investing in the existing environments, and maybe even the development of new environments for these kinds of devices. This was something I expected somehow, but it's still disappointing to know that we had so much of those developed in the past and now gone. I really miss Maemo. Running something like Qtopia would mean grabing a very old unmaintained software not available in Debian. There is still matchbox, but it's as subpar as the others I tested.

The second lesson is that building a userspace to run on old kernels will still hit the problem of broken drivers. In my particular case, unless I wrote code for using Ion instead of the framebuffer, I would have had that problem. Or it would require me to add code to xorg-xserver that is not appropriate. Or fix the kernel drivers of available kernel sourcecodes. But this does not scale much more than doing the right thing and adding upstream support for these devices.

So, I decided it was time I started working on upstream support for my device. I have it in progress and may send some upstream patches soon. I have USB and MMC/SDcard working fine. DRM is still a challenge, but thanks to Rob Clark, it's something I expect to get working soon, and after that, I would certainly celebrate. Maybe even consider starting the work on other devices a little sooner.

Trying to review my post on GNU on smartphones, here is where I would put some of the status of my device and some extra notes.

On Halium

I am really glad people started this project. This was one of the things I criticized: that though Ubuntu Phone and FirefoxOS built on Android userspace, they were not easily portable to many devices out there.

But as I am looking for a more pure GNU experience, let's call it that, Halium does not help much in that direction. But I'd like to see it flourish and allow people to use more OSes on more devices.

Unfortunately, it suffers from similar problems as the strategy I was trying to go with. If you have a device with a very old kernel, you won't be able to run some of the latest userspace, even with Android userspace help. So, lots of devices would be left unsupported, unless we start working on some upstream support.

On RYF Hardware

My device is one of the worst out there. It's a modem that has a peripherical CPU. Much has already been said about Qualcomm chips being some of the least freedom-friendly. Ironically, it's some with the best upstream support, as far as I found out while doing this upstreaming work. Guess we'll have to wait for opencores, openrisc and risc-v to catch up here.

Diversity

Though I have been experimenting with Debian, the upstream work would sure benefit lots of other OSes out there, mainly GNU+Linux based ones, but also other non-GNU Linux based ones. Not so much for other kernels.

On other options

After the demise of Ubuntu Phone, I am glad to see UBports catching up. I hope the project is sustainable and produce more releases for more devices.

Rooting

This needs documentation. Most of the procedures rely on booting a recovery system, which means we are already past the root requirement. We simply boot our own system, then. However, for some debugging strategies, getting root on the OEM system is useful. So, try to get root on your system, but beware of malware out there.

Booting

Most of these devices will have their bootloaders in there. They may be unlocked, allowing unsigned kernels to be booted. Replacing these bootloaders is still going to be a challenge for another future phase. Though adding a second bootloader there, one that is freedom respecting, and that allows more control on that booting step to the user is something possible once you have some good upstream support. One could either use kexec for that, or try to use the same device tree for U-Boot, and use the knowledge of the device drivers for Linux on writing drivers for U-Boot, GRUB or Libreboot.

Installation

If you have root on your OEM system, this is something that could be worked on. Otherwise, there is magic-device-tool, whose approach is one that could be used.

Kernels

While I am working on adding Linux upstream support for my device, it would be wonderful to see more kernels supporting those gadgets. Hopefully, some of the device driver writing and reverse engineering could help with that, though I am not too much optimistic. But there is hope.

Basic kernel drivers

Adding the basic support, like USB and MMC, after clocks, gpios, regulators and what not, is the first step to a long road. But it would allow using the device as a board computer, under better control of the user. Hopefully, lots of eletronic garbage out there would have some use as control gadgets. Instead of buying a new board, just grab your old phone and put it to some nice use.

Sensors, input devices, LEDs

There are usually easy too. Some sensors may depend on your modem or some userspace code that is not that easily reverse engineered. But others would just require some device tree work, or some small input driver.

Graphics

Here, things may get complicated. Even basic video output is something I have some trouble with. Thanks to some other people's work, I have hope at least for my device. And using the vendor's linux source code, some framebuffer should be possible, even some DRM driver. But OpenGL or other 3D acceleration support requires much more work than that, and, at this moment, it's not something I am counting on. I am thankful for the work lots of people have been doing on this area, nonetheless.

Wireless

Be it Wifi or Bluetooth, things get ugly here. The vendor driver might be available. Rewriting it would take a long time. Even then, it would most likely require some non-free firmware loading. Using USB OTG here might be an option.

Modem/GSM

The work of the Replicant folks on that is what gives me some hope that it might be possible to get this working. Something I would leave to after I have a good interface experience in my hands.

GPS

Problem is similar to the Modem/GSM one, as some code lives in userspace, sometimes talking to the modem is a requirement to get GPS access, etc.

Shells

This is where I would like to see new projects, even if they work on current software to get them more friendly to these form factors. I consider doing some work there, though that's not really my area of expertise.

Next steps

For me, my next steps are getting what I have working upstream, keep working on DRM support, packaging GPE, then experimenting with some compositor code. In the middle of that, trying to get some other devices started.

But documenting some of my work is something I realized I need to do more often, and this post is some try on that.

Posted Thu 06 Jul 2017 01:20:05 AM -03 Tags:
Preparando-se para instalar Debian no seu smartphone
Posted Fri 17 Mar 2017 08:43:55 AM -03
Posted Fri 17 Mar 2017 08:43:55 AM -03

No próximo sábado, dia 18 de Março de 2017, vou participar de uma oficina de Debian em gadgets, incluindo smartphones. Com esse post e outros por vir, gostaria de ajudar a preparar outras oficinas do tipo, e documentar algumas das atividades propostas e realizadas durante a oficina.

Você pode ver os demais posts aqui.

Para se preparar para a oficina, um aviso é muito importante: você pode perder seu aparelho e seus dados. Faça um backup dos seus dados antes de vir para a oficina. E caso opte por tentar alguns dos procedimentos descritos, esteja ciente dos riscos do seu aparelho não ligar mais, ou de você perder seus dados no processo.

Além disso, se possível, traga consigo um cabo USB de dados, um cartão SD compatível com seu aparelho, e um notebook com os seguintes pacotes instalados: abootimg, adb, fastboot, heimdall-flash. Traga o máximo que puder. Se for capaz de obter root em seu aparelho, melhor ainda.

Outros preparativos também são bem-vindos para algumas versões mais avançadas da oficina, o que vou tentar abordar durante a Mini Debconf Brasil 2017. Lembre-se de fazer a sua inscrição gratuita no site do evento. Ela é necessária para a entrada na UTFPR, local do evento.

Posted Fri 17 Mar 2017 08:43:55 AM -03

Declarando IRPF com software livre

Escrevi há um bom tempo sobre o IRPF GUI, uma interface de usuário para editar arquivos XML para utilização do IRPF Livre, software mantido e distribuído por Alexandre Oliva.

Comecei a escrever o código utilizando Python. Mas como não sou proficiente na linguagem e outras mudanças exigiriam alterar o código em Java do IRPF Livre, o processo de desenvolvimento travou.

Então me veio a idéia de utilizar comandos que serviriam como um formato de entrada em simples texto para dar maior usabilidade comparada à edição de XML. Aproveitei a idéia e comecei a escrever em C. No entanto, ao invés de gerar como saída o XML que serviria de entrada ao IRPF Livre, decidi gerar o arquivo em formato DEC de uma vez. Este formato é o formato final utilizado para envio à Receita Federal.

Com a minha experiência anterior com o rnetclient, ajuda do código do IRPF Livre, um arquivo que descreve os campos de cada linha do arquivo DEC e um pouco mais de engenharia reversa, tive sucesso em emitir minhas declarações nos últimos dois anos.

Mas o programa ainda não é tão amigável quanto eu gostaria. Os comandos não são documentados, os erros nem sempre são muito claros, e alguns usuários ainda prefeririam uma interface de formulários.

Para mudar isso, adicionei ao código, recentemente, uma interface de linha de comandos e um comando de ajuda, além do código necessário para emitir melhores mensagens de erro. Agora, as mensagens de erro precisam ser escritas, assim como os textos de ajuda.

Outra idéia que tive foi a de criar um modo tutorial, já que a interface de linha de comando foi adicionada. De alguma maneira, tal modo tutorial poderia indicar pontos de melhoria no programa para permitir novas interfaces no futuro.

Assim como no caso do rnetclient, discussões sobre o desenvolvimento do declara são bem-vindas na lista software-impostos. Também estamos no canal #libreceita da Freenode.

Posted Sat 14 Jan 2017 01:59:59 PM -02 Tags:

I am typing this on an editor running on Debian on my Samsung Galaxy S Relay 4G, aka apexqtmo. Sorry if I got you the wrong image. I am not using its touchscreen or keyboard for input or its screen for output. And the editor is not graphical. I am using a console editor over an SSH session.

I will try to summarize the steps needed to get there, what else I got, the challenges that I had to overcome, and some of the challenges ahead.

My first challenge was to get some output so that I could debug any problems. If I had a terminal, even better. So, this device has a keyboard, which makes things easier for input. I once had it running with a small initrd with GNU bash and got output on the framebuffer, though a little garbled. I realize there are some problems with the framebuffer driver after I have done some tests, which would explain that. For some reason, that didn't work again for me for some time.

So, in the effort to get some debug output, I have spent a lot of time trying to get a Linux binary that would manage to output to a framebuffer console, but without no luck. Then, I realized that besides ADB, I could just configure the USB gadget to act like a serial ACM device, and have a serial console. After that, I have made a lot of progress.

So, I had a small init which would do the configuration, then mount an SD card partition as the root filesystem and have bash for me. Some of the first challenges here were the fact that this old kernel didn't support metadata checksum on ext4, so I had to tune or recreate the filesystem.

After a success with bash, I went for init. As I had a debootstrapped Debian Jessie, that would be systemd, which failed for no known reason yet, but that was expected. Though this was a 3.4 Linux, there are many missing features in the binary which would explain it. So, I went for System V, and after setting it up to have a getty at ttyGS0, I had a login console.

So, another problem is that udev initscript requires devtmpfs, which this Linux binary didn't have enabled. I decided to ignore that and skip udev. I had created some static nodes at /dev/, which were good enough for me.

Then, for the network, I noticed this kernel didn't have wireless as well, so I booted with a different one, but it looks like it requires some extra initialization, maybe some userspace loading firmware, so I skipped that as well. Now, as for a network connection, I then thought I could use the same USB strategy and have it as a multiple interface gadget, with both serial ACM and network functions. That worked wonders.

Now, I could SSH into the smartphone and start running apt, and install packages. You know what's the next step? Get that framebuffer working and have X.org running. More work getting back to a kernel where framebuffer worked. Lots of headaches for that. Though there was a framebuffer driver, it wouldn't work for the kernel that is used for CyanogenMod. It seems it requires OpenGL to work. Or some fiddling with sysfs that I couldn't mimick in order for the display to turn on. So, back to a different kernel, where things seemed to work somehow.

Now, as udev was not running, X.org would give me something at the framebuffer, but no input would work. After trying to configure it manually, change some settings here and there, I found out that only the init scripts checked for the presence of devtmpfs. So, I removed some part of that, and udev was on. But that was after an upgrade to sid, so that might have been necessary, though I can't tell for sure.

For some reason, some X clients didn't like when I used nodm as a display manager, so I went for xinit. And the X server crashed when I used certain clients. I have a hunch this is caused by a framebuffer driver bug in the kernel, which would be a very sad fact if true. So, I got xterm and matchbox-keyboard running. The touchscreen and keyboard worked fine, so now I had something to show off. Though I was excited already when I had "Hello, World!" at my USB serial console.

So, now we realize what a problem we have! These binary kernels, even the ones built by a community like CyanogenMod, require a userspace in order to initialize drivers, including OpenGL and wireless. They don't have basic features turned on, like devtmpfs. It's a daunting task to run a different userspace, that might require these features or not have any code to do those required initializations.

It's still doable to some point, but maybe not sustainable for long. We would either have to work on an alternative userspace, one that does not require or can work without some kernel features, and that can do some of the initialization or workaround some of the bugs we find in the drivers, like the framebuffer one.

The best alternative is to get those devices supported upstream. And, for that, the first step is to get some source code that builds and runs on those things. I didn't manage to get there yet. After some failures with what is supposed to be used for CyanogenMod, I tried getting source code directly from Samsung. As I couldn't find my device in their opensource site, I asked them for the source code. Four days later, they sent me a message that the source was now available in their site. That was a nice surprise. I didn't expect them to answer, and that was quick enough for me to try it before I was about to present this topic at Latinoware. It turns out I couldn't boot that yet either, and it is a 3.0 Linux, so old enough not to be supported by the latest Debian.

Next I am going to write how to try the same thing for your own Samsung gadget at your own risk, no warranties.

Posted Sun 30 Oct 2016 07:24:06 AM -02 Tags:

Some time ago, I built a static program that I wanted to run on an Android tablet. What was my surprise when I saw a message saying "FATAL: kernel too old".

After some investigation, it turns out that GNU libc may assume some Linux features are present during build time. This means that given a minimum Linux version, that built libc might only work on that version or newer.

Since 2014, GNU libc itself requires 2.6.32 as the minimum. Previously, it was 2.6.16, changed in 2012.

Debian, as of 2015, builds it with a required minimum Linux version of 3.2.

To give an idea about the history of these kernel releases, we have:

  • December 2009, Linus releases Linux 2.6.32.
  • November 2010, Red Hat releases RHEL 6.0, Linux 2.6.32.
  • February 2011, Debian 6.0 Squeeze, Linux 2.6.32.
  • January 2012, Linus releases Linux 3.2.
  • April 2014, GNU Libc requires Linux 2.6.32.
  • December 2015, Debian GNU Libc uploaded to unstable requires Linux 3.2.

So, at least for GNU libc upstream, it would appear that not many devices would stop being supported, though the situation would not be as good for binary versions of Debian. However, I have a small list of devices that might show otherwise.

  • Nokia N900 shipped with Linux 2.6.28.
  • Android emulator, a platform called Goldfish, uses Linux 2.6.29.
  • The Wii port most widely tested is based on Linux 2.6.32.

Many Android devices have been shipped with Linux 3.4, but I encountered at least one using Linux 3.0.

So, even though many new devices ship with newer versions of Linux, it's still possible to find some new and older devices using versions older than 3.2, and even versions older than 2.6.32 may be found.

Another interesting note is that, without a few patches, it's not possible to build Linux 2.6.32 with GCC 5 and newer. For that and many other reasons, it's important that we update. For bug fixes, and so we can make progress and use better software are some of the other reasons.

So, it's imperative that we have devices support upstream. Otherwise, the task of doing updates with forward porting becomes daunting. And that's the current state for many devices, which is why I have been trying to use new software with older versions of Linux. But as time passes, I realize how hard a task this is, as most new software these days, even a building block like GNU libc, requires ever new versions of Linux.

For now, most gadgets I have support Linux 3.4 or newer. But not long ahead, that support will be dropped as well. And that means there will be no more updates for those devices. It's a consequence of both targeting time-to-market and programmed obsolescence as business practices. Upstream support is no priority, and maintenance is only that required until the next model is available on the stores.

This is one more reason why we need to have more operating systems available for those devices. Systems that are designed to last more than a couple of years. As I said, upstream support is imperative, but as a step forward, I still believe we can provide the GNU experience to lots of devices out there.

Posted Thu 01 Sep 2016 08:34:13 AM -03 Tags:

Acesso a bancos sem software livre

Há muitos anos, usuários de grandes bancos no Brasil são obrigados a utilizar software não livre em seus computadores para fazerem consultas e operações via Internet.

Em muitos desses casos, era comum a utilização de um applet Java, muitas vezes funcionando apenas com um plugin e um JRE não livre, fornecido pela Sun, hoje Oracle. Tal JRE utilizava uma EULA draconiana, que me recordo interpretar como impedindo aquele que a aceitasse de realizar engenharia reversa, algo que algumas juridições permitem.

Recentemente, vários bancos passaram a exigir a instalação de um software que opera fora da caixa do applet da JVM, executando como superusuário. Trata-se, na verdade, de um servidor WebSocket, com o qual o JavaScript fornecido pelo Internet Banking ao acessá-lo se conecta.

Esses bancos e outros que não exigem tais instalações operam com bastante JavaScript, muitas vezes obfuscados, código não livre executado em nossos computadores. Não há como utilizar o sistema sem desabilitá-los. E executar versões modificadas e distribuí-las para que sejam de fácil uso para o usuário ainda é um desafio hoje.

Além do mais, há a limitação da interface a um browser Web, dificultando o acesso via outras interfaces, como linha de comando, e automação de operações por parte do usuário.

Acesso a bancos com software livre

Não seria muito melhor se o software para acesso aos bancos fosse livre e permitisse o uso de diferentes interfaces e automação? Que modificações a esse software pudessem ser feitas e compartilhadas para que outras pessoas pudessem utilizá-las?

Imagine poder obter seus extratos periodicamente e alimentar um banco de dados próprio, agregando movimentações financeiras de múltiplas fontes. E fazê-lo de forma automática, conhecendo como o software funciona e o adaptando como preferir.

Documentação

Esse é um projeto em que venho trabalhado há algum tempo, sem muito sucesso, mas com algum progresso que nunca documentei apropriadamente. Tal documentação é uma forma de compartilhar meu trabalho com outros, para que possam contribuir e ajudar no progresso de tal trabalho.

Meu objetivo com este post é documentar uma parte do trabalho que venho fazendo com a Caixa Econômica Federal. A CEF exigia um applet Java até alguns meses atrás, quando passou a exigir a instalação de um servidor WebSocket.

Cookies

Uma primeira observação importante é que, independente do mecanismo, seja o applet ou o servidor WebSocket, após o login, cookies podem ser reutilizados e operações realizadas.

Ou seja, é possível fazer o login utilizando um computador com o software proprietário instalado, exportar os cookies da sessão de navegação, e importá-los em outra sessão em outro computador. A partir daí, as operações podem ser realizadas sem utilização e interferência do software não livre.

Isto é importante, pois permite que o software livre para realização de consultas e operações possa ser desenvolvido sem a engenharia reversa desse software proprietário, e apenas a engenharia reversa da comunicação Web e, talvez, do JavaScript.

Login

Antes da substituição do applet Java, escrevi um script que permitia fazer um login e obter o saldo através de requisições HTTP. Sem utilização do applet Java, uma máquina podia ser cadastrada e seu cadastro utilizado para o login. No entanto, outras operações não eram permitidas. Ainda que utilizado o cookie em um browser, até mesmo qualquer consulta que não o saldo era negada.

Talvez fosse uma falha no cadastro, ou na operação de login, mas não pude determinar antes que a substituição acontecesse.

No entanto, novamente nenhuma substituição de operações realizadas pelo applet foram necessárias. O que me levou a descobrir que o applet não estava sequer operando como esperado.

WebSocket

Uma nova opção é fazer a engenharia reversa da comunicação WebSocket e substituir o servidor WebSocket. Daí, tal comunicação poderia ser substituída por chamadas locais.

Ainda assim, deve ser avaliada a possibilidade de ignorar tal comunicação totalmente. No entanto, ainda não tive sucesso em realizar o login como anteriormente, sem uso de algumas chaves aparentemente geradas pelo servidor.

Contribuindo

Para aqueles que quiserem saber mais detalhes e contribuir mais com o projeto, tenho um escopo de código aqui e aqui, que funcionavam anteriormente.

Também sugiro conversar na lista de e-mails software-impostos.

Posted Thu 14 Jul 2016 04:06:04 PM -03 Tags:

On recent posts, I mentioned that I have a Chromebook, and that I would like to run Debian on devices that ship with old Linux versions. The Samsung ARM Chromebook is such a device, it has Linux 3.4, and that's still what I am running on it most of the time.

After an upgrade of Debian, systemd stopped working, and it took me some time before I could look into it. In order to boot, I had to temporarily use System V init. The bug involves the use of new interfaces, bugs in such interfaces, and how versioning would not be a solution to such cases. Cases like this are not common, so it's no excuse to doing the right thing when developing software, like considering portability, API and ABI maintenance and not bundle. But they expose some of the challenges when trying to support different OSes on top of old versions of Linux, or maybe even new versions.

The new version of systemd included in Debian Jessie uses a feature of Linux of checking the mount ID of a file by inspecting the mnt_id line in the fdinfo files. fdinfo files are not that new, they have been present since 2007, Linux 2.6.22. The mnt_id line, however, is from Linux 3.15, from 2014. So, a fairly new feature. But systemd falls back to other methods if the feature is not present.

However, during the last few weeks of development of Linux 3.4, a bug was introduced to fdinfo handling, which will cause its access to fail in a way that will cause systemd to halt. It simply will refuse to mount the most basic filesystems and not proceed. The bug was fixed not much longer than two weeks after that, but that window of time was enough to have it on a shipped product, one that was not using systemd, let alone one that required a feature not yet present on Linux.

But now I wanted to run this new systemd on this old Linux version. Being too early in the boot process, systemd even ignored some of the debug options and I had to resort to other methods of debugging. As I am running a kernel I built by myself, it wasn't hard for me to have a fixed kernel up and running after I found out the problem. Unfortunately, not everyone will be able to do it by themselves. And the point of getting different OSes working on these many varied devices is scaling. If every device needs to be tested, we lose this scalability.

The other problem I found was that this old Linux version didn't load firmware files by itself, and requested help from userspace, which used to be the job of udev. Well, udev now does not support loading firmware, and the kernel must do it by itself. I managed to backport that feature too. But now, it sounds like I should get upstream support for this device.

Unfortunately, this means not working on the scalability problem, but going back to get upstream support for a lot of devices out there, which is very hard to scale without the necessary people to do the work. I am certainly going to do that, because it's the right thing to do. But not as many people will benefit from that.

But I think it has been interesting to look into the possible problems we might find when trying to make Debian and other OSes working on old Linux versions. I know even older Debian versions won't boot fine on Linux 2.6.32, one of the LTS versions of Linux. I have one other device which runs on it, and I am also working on getting better upstream support for it. Let's see if I can get some news on that soon.

Posted Sat 02 Jul 2016 11:18:00 PM -03 Tags:

Three years ago, I wanted to get a new laptop. I wanted something that could run free software, preferably without blobs, with some good amount of RAM, good battery and very light, something I could carry along with a work laptop. And I didn't want to spend too much. I don't want to make this too long, so in the end, I asked in the store anything that didn't come with Windows installed, and before I was dragged into the Macbook section, I shouted "and no Apple!". That's how I got into the Chromebook section with two options before me.

There was the Chromebook Pixel, too expensive for me, and the Samsung Chromebook, using ARM. Getting a laptop with an ARM processor was interesting for me, because I like playing with different stuff. I looked up if it would be possible to run something other than ChromeOS on it, got the sense that is, it would, and make a call. It does not have too much RAM, but it was cheap. I got an external HD to compensate for the lack of storage (only 16GB eMMC), and that was it.

Wifi does require non-free firmware to be loaded, but booting was a nice surprise. It is not perfect, but I will see if I can get to that another day.

I managed to get Fedora installed, downloading chunks of an image that I could write into the storage. After a while, I backed up home, and installed Debian using debootstrap.

Recently, after an upgrade from wheezy to jessie, things stopped working. systemd would not mount the most basic partitions and would simply stop very early in the boot process. That's a story on my backlog as well, that I plan to tell soon, since I believe this connects with supporting Debian on mobile devices.

After fixing some things, I decided to try libinput instead of synaptics for the Trackpad. The Chromebook uses a Cypress APA Trackpad. The driver was upstreamed in Linux 3.9. The Chrome OS ships with Linux 3.4, but had the driver in its branch.

After changing to libinput, I realized clicking did not work. Neither did tapping. I moved back to synaptics, and was reminded things didn't work too well with that either. I always had to enable tapping.

I have some experience with input devices. I wrote drivers, small applications reacting to some events, and some uinput userspace drivers as well. I like playing with that subsystem a lot. But I don't have too much experience with multitouch and libinput is kind of new for me too.

I got my hands on the code and found out there is libinput-debug-events. It will show you how libinput translates evdev events. I clicked on the Trackpad and got nothing but some pointer movements. I tried evtest and there were some multitouch events I didn't understand too well, but it looked like there were important events there that I thought libinput should have recognized.

I tried reading some of libinput code, but didn't get too far before I tried something else. But then, I had to let this exercise for another day. Today, I decided to do it again. Now, with some fresh eyes, I looked at the driver code. It showed support for left, right and middle buttons. But maybe my device doesn't support it, because I don't remember seeing it on evtest when clicking the Trackpad. I also understood better the other multitouch events, they were just saying how many fingers there were and what was the position of which one of them. In the case of a single finger, you still get an identifier. For better understanding of all this, reading Documentation/input/event-codes.txt and Documentation/input/multi-touch-protocol.txt is recommended.

So, in trying to answer if libinput needs to handle my devices events properly, or handle my device specially, or if the driver requires changes, or what else I can do to have a better experience with this Trackpad, things were tending to the driver and device. Then, after running evtest, I noticed a BTN_LEFT event. OK, so the device and driver support it, what is libinput doing with that? Running evtest and libinput-debug-events at the same time, I found out the problem. libinput was handling BTN_LEFT correctly, but the driver was not reporting it all the time.

By going through the driver, it looks like this is either a firmware or a hardware problem. When you get the click response, sound and everything, the drivers will not always report it. It could be pressure, eletrical contact, I can't tell for sure. But the driver does not check for anything but what the firmware has reported, so it's not the driver.

A very interesting I found out is that you can read and write the firmware. I dumped it to a file, but still could not analyze what it is. There are some commands to put the driver into some bootloader state, so maybe it's possible to play with the firmware without bricking the device, though I am not sure yet. Even then, the problem might not be fixable by just changing the firmware.

So, I left with the possibility of using tapping, which was not working with libinput. Grepping at the code, I found out by libinput documentation that tapping needs to be enabled. The libinput xorg driver supports that. Just set the Tapping option to true and that's it.

So, now I am a happy libinput user, with some of the same issues I had before with synaptics, but something you get used to. And I have a new firmware in front of me that maybe we could tackle by some reverse engineering.

Posted Sat 14 May 2016 12:26:51 PM -03 Tags:

O rnetclient 2016.0 já está disponível aqui.

A nova versão suporta a transmissão de declarações de 2016, além de retificações de 2013 a 2015. Possivelmente, anos posteriores são suportados, desde que não haja mudanças inesperadas no protocolo da Receita Federal.

Outras melhorias incluem:

  • Não transmitir a declaração se não for possível gravar o arquivo de recibo. Em versões anteriores, se um arquivo de recibo já existisse, o arquivo não era sobrescrito, mas o novo recibo não era gravado em nenhum arquivo.

  • Teste unitário, verificando que alterações no código ainda permitem a correta identificação e leitura de declarações de anos anteriores.

Agradeço ao Gabriel F. T. Gomes pelos testes e contribuições a esta versão.

Caso tenha algum problema com o uso do rnetclient, por favor, reporte na lista software-impostos.

Thadeu Cascardo.

Posted Wed 06 Apr 2016 11:21:32 PM -03