From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 04B534D4 for ; Tue, 13 May 2014 07:09:05 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 868731FD47 for ; Tue, 13 May 2014 07:09:03 +0000 (UTC) Date: Tue, 13 May 2014 00:08:51 -0700 From: Josh Triplett To: Teodora =?utf-8?B?QsSDbHXFo8SD?= Message-ID: <20140513070851.GA20002@thin> References: <20140511041449.GP12708@titan.lakedaemon.net> <20140511162918.GA2527@linux.com> <1995824.rdvEX5SOIt@avalon> <20140511171824.GB2527@linux.com> <20140512161539.GX12708@titan.lakedaemon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Cc: PJ Waskiewicz , Anton Arapov , Dirk Hohndel , ksummit-discuss@lists.linuxfoundation.org, Sarah A Sharp Subject: Re: [Ksummit-discuss] Fwd: [TECH TOPIC] QR encoded oops for the kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora B=C4=83lu=C5=A3=C4=83 w= rote: > On Mon, May 12, 2014 at 7:15 PM, Jason Cooper wr= ote: > > I'd like the URL to be valid (meaning base64 the compressed data) so > > that we can get the data to the kernel.org server as easily as possib= le. > > Making the app a requirement for reporting is too onerous for > > non-developers. I see no reason we can't link to (Open in/Install) i= t > > on the webform though. >=20 > So from what I can understand, the QR code has an URL that has the > base64 of the compressed Oops message. Right? I see three problems > with this approach: >=20 > - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded > characters + padding). One issue with QR codes is that they have a > limited amount of characters they can hold so that's why I do the > compression in the first place Putting base64-encoded data in a URL in a binary-format QR code with 8 bits per character does indeed waste quite a bit of space. However, you could put base32-encoded data into an alphanumeric-formatted QR code with 5.5 bits per character, which would waste very little space. (Or, more efficiently but less conveniently, base40 or so.) > - besides doing compression in a kernel that's had issues, you add the > base64 encoding inside the kernel > - you would still use a device with a camera (smartphone, tablet) to > scan the QR from the framebuffer, so basically that means an app, > right? What is the point of doing the URL validation inside the kernel > when an app can do that? It doesn't add to the difficulty of sending > the Oops to kernel.org (just one button away) Many users will already have a QR-code scanning app installed, and such apps always support loading URLs in a browser. Another possibility to consider: current mobile browsers support the HTML Media Capture API, which allows capturing an image from the camera from within a file upload control. Together with a bit of Javascript, that would allow app-less oops capturing just by visiting a page and using that page to capture the oops image. - Josh Triplett