Re: [RFC] QR encoding for Oops messages

[Levente Kurusa]

Hi,

2014-04-01 23:07 GMT+02:00 Teodora Băluţă <teobaluta@xxxxxxxxx>:
> On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:
>> On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote:
>>> Hi all,
>>>
>>> (sorry for the late reply, looks like this mail has ran away from my clients)
>
> same here.
>
>>>
>>> 2014-03-23 20:38 GMT+01:00 Jason Cooper <jason@xxxxxxxxxxxxxx>:
>>> > All,
>>> >
>>> > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote:
>>> >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa <levex@xxxxxxxxx> wrote:
>>> >> > On 03/21/2014 02:28 PM, Jason Cooper wrote:
>>> > ...
>>> >> >> I would definitely like to see the QR output incorporated into a
>>> >> >> kernel.org url.  That would remove the need for installing another app,
>>> >> >> and would ease bug reporting.
>>> >> >
>>> >> > I still struggle to understand how could that be done. We can encode the
>>> >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding
>>> >> > 'Unable to handle kernel paging request at 0000000f' gave a 449 character
>>> >> > long sequence with very strange characters [0]. We should try to shorten
>>> >> > it, imho. Not sure how to do that though.
>>> >
>>> > The man page for qrencode says you can have up to 4000 characters in a
>>> > qrcode.  However, I've seen readers have trouble with a 2048bit ascii
>>> > armored PGP public key (3929 characters).
>>> >
>>> > I grabbed a random oops from oops.kernel.org, it weighed in at 1544
>>> > bytes, not too bad.  I then did:
>>> >
>>> > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0`" | wc -c
>>> > 993
>>>
>>> I did the same with another OOPS and it had 1953 characters. That's quite a big
>>> a big difference! :-)
>>>
>>> I created a QR image from the URL then, and it was 147x147, which is
>>> pretty small.
>>> It took me quite a long time to make my phone recognize it, but it
>>> worked nicely.
>>>
>>> Result of work is in this directory:
>>>
>>> http://levex.fedorapeople.org/kernel/qr/
>>
>> nice!
>>
>>> > The benefit of a url is that any QR reader can automagically report an
>>> > oops.  While a specific app could parse the URL/oops locally if the
>>> > user desires.
>>> >
>>> >> it misses the point of having a QR code in the first place. The way I
>>> >> see it, having a QR decoder app installed that can do an offline
>>> >> decoding is a less greater effort than popping out a browser on the
>>> >> machine you're working on.
>>> >
>>> > I think you're selling the advantage of the QR code short.  Automated
>>> > reporting (via the url) is a _huge_ plus.  The app you conceive of could
>>> > still parse it in place if the user desires.
>>> >
>>> > My point for the URL isn't to use the internet/server to automate oops
>>> > parsing for the user.  Rather it's to make it easy to report oopses to
>>> > developers.  While still preserving the ability of your app to parse it
>>> > for the user.
>>>
>>> Ah I see now. oops.kernel.org/?qr=<QR> would simply parse the
>>> base64'd+gzip'd oops message and then report it.
>>
>> If you mean the server behind oops.k.o would parse it, then yes.  No
>> special app should be required other than a QR code scanner for the
>> usecase of reporting oopses to developers.

Yup, clear now.

>>
>>> Now I guess we need to think how to make it work without a
>>> framebuffer. I already suggested using the ASCII characters,
>>> but seeing the resolution of this QR code for example (147x147),
>>> made me realize that we can't shuffle that into a 80x25 textmode
>>> display. Any ideas how to fix that or should we just simply depend
>>> on a framebuffer being present?
>>
>> I think depending on the framebuffer being present (via kconfig) is
>> sane.  Folks running old systems know what they're in for, like missing
>> shiny new features. ;-)
>
> Ok, this may work. I agree that doing this with the help of the frame
> buffer is more natural.

Okay, Teodora I'll send you a commit ASAP and then
we should start working on getting libqr into an acceptable
state. I am not sure if we can shuffle it into staging though,
it's not a driver and AFAIK staging.git is for drivers which aren't
yet finished. So, I would say, let's start working on fixing the
OOPness of libqr first. If we were to rework that, then
we can as well avoid having GFP_ATOMIC in library code
by using the more conventional kmalloc(struct); init_struct(ptr);
scheme.

Oh and I had an idea of adding a new kernel parameter, something
like 'qr_oops.*'. (Looking for a better name! :-) )
Basically, I thought of the following options so far:

*  qr_oops.disable=1  - disable it
*  qr_oops.scale=600x600 - scale the qr code so its easier to read
   with a phone. In my testing I had huge difficulties reading the
   QR codes, but when scaled to be a bit bigger it worked magically.
   This might not be so easy to implement this way, but with preset
   values, i.e. 4x4 squares instead of a pixel, it could work.

Objections, ideas are welcome!

Teodora, have you worked on anything recently in qr-linux-kernel?
Just to make sure we aren't working on the same.

Thanks,
Levente Kurusa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/