pages tagged inputdevThadeu Lima de Souza Cascardohttps://cascardo.eti.br/tags/inputdev/Thadeu Lima de Souza Cascardoikiwiki2016-05-14T15:26:51ZChromebook Trackpadhttps://cascardo.eti.br/blog/Chromebook_Trackpad/2016-05-14T15:26:51Z2016-05-14T15:26:51Z
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>