Re: [RFC] QR encoding for Oops messages

["Teodora Băluţă" <teobaluta@gmail.com>]

On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper <jason@lakedaemon.net> 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@lakedaemon.net>:
>> > 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@linux.com> 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.
>
>> 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.

Thanks,
--
Teodora

>
> thx,
>
> Jason.