From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751785AbaDAVHt (ORCPT ); Tue, 1 Apr 2014 17:07:49 -0400 Received: from mail-qa0-f42.google.com ([209.85.216.42]:58665 "EHLO mail-qa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751755AbaDAVHr convert rfc822-to-8bit (ORCPT ); Tue, 1 Apr 2014 17:07:47 -0400 MIME-Version: 1.0 In-Reply-To: <20140401142051.GO28304@titan.lakedaemon.net> References: <1395093587-2583-1-git-send-email-teobaluta@gmail.com> <20140319201838.GA11403@redhat.com> <20140321132816.GW15608@titan.lakedaemon.net> <532DC3D3.9060008@linux.com> <20140323193839.GY15608@titan.lakedaemon.net> <20140401142051.GO28304@titan.lakedaemon.net> Date: Wed, 2 Apr 2014 00:07:46 +0300 Message-ID: Subject: Re: [RFC] QR encoding for Oops messages From: =?ISO-8859-2?B?VGVvZG9yYSBC42x1/uM=?= To: Jason Cooper Cc: Levente Kurusa , Dave Jones , "linux-kernel@vger.kernel.org" , "Waskiewicz Jr, Peter P" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper 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 : >> > 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 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= 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.