<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 29, 2015 at 11:00 PM, Alexandre Oliva <span dir="ltr"><<a href="mailto:lxoliva@fsfla.org" target="_blank">lxoliva@fsfla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Nov 28, 2015, Alexandre Oliva <<a href="mailto:lxoliva@fsfla.org">lxoliva@fsfla.org</a>> wrote:<br>
<br>
> On Nov 28, 2015, Iru Cai <<a href="mailto:mytbk920423@gmail.com">mytbk920423@gmail.com</a>> wrote:<br>
>> I bought a Chromebook pixel 2013 recently. When it runs Trisquel with<br>
>> Linux-libre 3.13, the touchscreen and touchpad work fine. However, in later<br>
>> kernel release, it needs to load non-free firmware in mxt_initialize(),<br>
>> which is in drivers/input/touchscreen/atmel_mxt_ts.c, and the atmel_mxt_ts<br>
>> driver fails to work. Is there a work around for this?<br>
<br>
> I suspect blacklisting the specific driver might get the device to<br>
> fallback to generic emulation mode, which is presumably what you were<br>
> get on 3.13 (assuming there isn't a specific driver there).<br></span></blockquote><div><br></div><div>Sorry for not cc the replied mail to the mailing list when I was replying the previous mails. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>I've taken a look at the driver, and it is buggy.  Even though it works<br>
without the blob, it treats an -EINVAL return from r*t_firmware_nowait<br>
as a hard error, instead of ignoring as it could/should, to work even<br>
upstream, when the firmware loader is disabled altogether in the build<br>
configuration.<br></blockquote><div>I forgot to mention one thing. The reject_firmware_nowait sometimes causes a kernel panic in atmel_mxt_ts driver. I didn't save the kernel error messages, but I think there may be something wrong with the reject firmware logic. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We could work around that bug in GNU Linux-libre, using an alternate<br>
call that fakes a success return status, but...  I'd much rather it be<br>
fixed upstream, so that we can keep local changes to a minimum. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would you report that, saying it doesn't work with the firmware loader<br>
disabled, or if request_firmware_nowait fails for whatever reason, even<br>
though you know it could work just fine?<br></blockquote><div>I meant that it works if I changed reject_firmware_nowait to request_firmware_nowait, although the kernel will say it fails to load firmware. It doesn't give a 'Failed to invoke firmware loader.' error. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the mean time, I suggest patching the driver so that it doesn't take<br>
the error status from reject_firmware_nowait as fatal, reporting it but<br>
ignoring it.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Alexandre Oliva, freedom fighter    <a href="http://FSFLA.org/~lxoliva/" rel="noreferrer" target="_blank">http://FSFLA.org/~lxoliva/</a><br>
You must be the change you wish to see in the world. -- Gandhi<br>
Be Free! -- <a href="http://FSFLA.org/" rel="noreferrer" target="_blank">http://FSFLA.org/</a>   FSF Latin America board member<br>
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer<br>
</div></div></blockquote></div><br></div></div>