Eu finalmente consegui remapear o scancode para BTN_STYLUS2 usando ir-keytable . O comando foi:
sudo ir-keytable --device /dev/input/event8 --set-key 0xd003c=BTN_STYLUS2
No entanto, enquanto eu podia ver que o scancode tinha sido recuperado com sucesso, o botão permaneceu morto. evtest não relatou mais nenhum evento quando o botão foi pressionado.
Antes disso, não havia nenhum evento MSC_SCAN relatado por evtest quando esse botão foi pressionado, embora houvesse scancodes relatados para o outro botão e também para o toque da caneta. Isso não me pareceu mais do que um truque estranho na época, mas agora parece que o botão realmente não gera scancode. Como evtest relatou um evento keycode, então? Beats me, e neste momento estou fazendo um erro do kernel.
No final, eu apenas juntei um script bash para assistir evtest para BTN_TOOL_RUBBER eventos e simular um clique com o botão direito do mouse com xdotool :
#!/bin/bash
# Find the input device number.
devicename="ELAN Touchscreen Pen"
numevents=$(ls /dev/input | grep -c event*)
for ((devnr=0;devnr<$numevents;devnr++)); do
input-kbd $devnr | grep -q "$devicename"
if [[ $? == 0 ]]; then
break
fi
done
# Listen for BTN_TOOL_RUBBER events.
evtest /dev/input/event$devnr | while read line; do
for value in {0..1}; do
echo $line | grep -q "type 1 (EV_KEY), code 321 (BTN_TOOL_RUBBER), value $value"
if [[ $? == 0 ]]; then
case $value in
0) xdotool mouseup 3 ;;
1) xdotool mousedown 3 ;;
esac
fi
done
done
Isso me dá essencialmente a funcionalidade básica que eu queria de qualquer maneira. Não é perfeito: o evento mouseup só acontece quando a caneta deixa a proximidade, não quando o botão é liberado (é quando o evento de BTN_TOOL_RUBBER é relatado em evtest ), mas funciona bem o suficiente para que eu seja não vai tentar depurar o kernel.