All of lore.kernel.org
 help / color / mirror / Atom feed
From: Levente Kurusa <levex@linux.com>
To: Jason Cooper <jason@lakedaemon.net>, David Lang <david@lang.hm>
Cc: "Teodora Băluţă" <teobaluta@gmail.com>,
	"Dave Jones" <davej@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Subject: Re: [RFC] QR encoding for Oops messages
Date: Fri, 04 Apr 2014 18:17:25 +0200	[thread overview]
Message-ID: <533EDB15.40305@linux.com> (raw)
In-Reply-To: <20140404151542.GB28334@titan.lakedaemon.net>

Hi,

On 04/04/2014 05:15 PM, Jason Cooper wrote:
> On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote:
>> On Tue, 1 Apr 2014, Jason Cooper wrote:
>>
>>>> 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. ;-)
>>
>> First get it working and into acceptable form, but after that, take
>> a look at the various ASCII-art tools out there. While the display
>> may be limited to 80x25, that's not a hard requirement (and I'd
>> happily run systems with a smaller text console if this was an
>> option), and then you can look at the possibility of using
>> characters that represent more than one pixel per character. While
>> this may not be able to render everything perfectly, remember that
>> qr codes can include redundancy to correct for bad pixels, you may
>> be able to get something working.

I am not sure depending on the error recovery is good practice.
We also have to take into account that scanners themselves also
create noise and may not be perfect. Better reserve the error
recovery for those details instead of messing the QR code with
characters...

> 
> I'm not sure this will work.  The screen space allocated to a single
> character isn't square.  However, the QR pixels are square.  I see a lot
> of fragile complexity ahead...
> 

... not to mention this as well.


IMHO supporting textmode is just not worth the effort. Besides,
what would we gain from it? Supporting those devices without
a framebuffer? Do devices like that even exist anymore? In fact,
even to make this you need a screen, and AFAIK most screens come
with some kind of a framebuffer to drive them.

-- 
Regards,
Levente Kurusa

  reply	other threads:[~2014-04-04 16:17 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-17 21:59 [RFC] QR encoding for Oops messages Teodora Baluta
2014-03-18 21:49 ` Matthew Garrett
2014-03-19 20:09   ` Teodora Băluţă
2014-03-19 18:03 ` Borislav Petkov
2014-03-19 20:18   ` Teodora Băluţă
2014-03-19 20:18 ` Dave Jones
2014-03-19 20:28   ` Levente Kurusa
2014-03-19 20:50     ` Teodora Băluţă
2014-03-19 20:51       ` Teodora Băluţă
2014-03-19 21:17       ` Levente Kurusa
2014-03-19 20:38   ` Teodora Băluţă
2014-03-21 13:28     ` Jason Cooper
2014-03-22 17:09       ` Levente Kurusa
2014-03-22 18:20         ` Teodora Băluţă
2014-03-22 18:29           ` Levente Kurusa
2014-03-23 11:51             ` Levente Kurusa
2014-03-23 19:38           ` Jason Cooper
2014-03-30 10:17             ` Levente Kurusa
2014-04-01 14:20               ` Jason Cooper
2014-04-01 21:07                 ` Teodora Băluţă
2014-04-03 20:21                   ` Levente Kurusa
2014-04-04 15:12                     ` Jason Cooper
2014-04-04 15:42                       ` Levente Kurusa
2014-04-03 20:57                 ` David Lang
2014-04-04 15:15                   ` Jason Cooper
2014-04-04 16:17                     ` Levente Kurusa [this message]
2014-04-04 21:42                       ` Teodora Băluţă
2014-04-05  9:11                         ` Levente Kurusa
2014-04-07 15:20                           ` Jason Cooper
2014-04-08 15:42                             ` Levente Kurusa
2014-04-08 17:20                               ` Jason Cooper
2014-04-08 17:29                                 ` Levente Kurusa
2014-04-13 20:43                                   ` Levente Kurusa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533EDB15.40305@linux.com \
    --to=levex@linux.com \
    --cc=davej@redhat.com \
    --cc=david@lang.hm \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=teobaluta@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.