Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754677AbaDGPUU (ORCPT ); Mon, 7 Apr 2014 11:20:20 -0400 Received: from mho-03-ewr.mailhop.org ([204.13.248.66]:51362 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753143AbaDGPUN (ORCPT ); Mon, 7 Apr 2014 11:20:13 -0400 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 96.249.243.124 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SmkanntzyaNY+KJRNqFOg2LupDuu93UM= X-DKIM: OpenDKIM Filter v2.0.1 titan 286FD553BD0 Date: Mon, 7 Apr 2014 11:20:04 -0400 From: Jason Cooper To: Levente Kurusa Cc: Teodora =?utf-8?B?QsSDbHXFo8SD?= , David Lang , Dave Jones , "linux-kernel@vger.kernel.org" , "Waskiewicz Jr, Peter P" Subject: Re: [RFC] QR encoding for Oops messages Message-ID: <20140407152003.GF28334@titan.lakedaemon.net> References: <532DC3D3.9060008@linux.com> <20140323193839.GY15608@titan.lakedaemon.net> <20140401142051.GO28304@titan.lakedaemon.net> <20140404151542.GB28334@titan.lakedaemon.net> <533EDB15.40305@linux.com> <533FC8A6.6050905@linux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533FC8A6.6050905@linux.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote: > Or, we could use core_param and simply have 'oops_qr' or > 'qr_oops'. In my humble opinion the latter sounds better. Ack. My original suggestion was focused on 0=disable, >0 is scale. I literally pulled the name from my nether-regions. :-) > Oh and another suggestion, I think placing it in the bottom-right > corner would be better since then we wouldn't overwrite some of > the timestamps and messages. The real text is still sent to the (hopefully written to disk) logs. If a user (or distro) builds with this feature, I would think centered and scaled for ease of scanning would be highest priority. I don't think there is a 'safe' part of the framebuffer real estate where the QR could be written for all scenarios. Best to make it easy to scan. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/