Date:	Sun, 30 Mar 2014 12:17:17 +0200
From:	Levente Kurusa <levex@...ux.com>
To:	Jason Cooper <jason@...edaemon.net>,
	Teodora Băluţă <teobaluta@...il.com>
Cc:	Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Subject: Re: [RFC] QR encoding for Oops messages

Hi all,

(sorry for the late reply, looks like this mail has ran away from my clients)

2014-03-23 20:38 GMT+01:00 Jason Cooper <jason@...edaemon.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@...ux.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/


>
> 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.

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?

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

Powered by blists - more mailing lists