lkml.org 
[lkml]   [2014]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] QR encoding for Oops messages
From
On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa <levex@linux.com> wrote:
> 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...

You do have the option of error recovery for up to 30% recovery (H
level), but that means the space you get for storing is smaller.

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

Guys, first things first is cleaning the library up. I haven't managed
to do anything yet as I am working on my thesis (bachelor's degree,
yay!). I will do some this weekend and that is removing the kanji mode
support. So, Levente, pleaso do that parameter thing you mentioned.
Merging that with the cleanup shouldn't be a problem. :-)

I think writing the QR to the frame buffer is the way to do it for
now. Doing a QR in text mode (as in displaying it, not as previously
mentioned idea with the link base64 encoding &/ compression) would
mean that for each square you get an ASCII character filling up your
screen. To get an idea of how the QR looks on the frame buffer I've
made a screenshot. That's the whole Oops message being encoded and
compressed. [0]

The problem with frame buffer is that I currently implemented it using
the generic frame buffer API. There are some issues as mentioned in
the first post of this RFC [1]. Would making it work with KMS be
better? Any opinions?

Thanks,
--
Teodora

[0] http://swarm.cs.pub.ro/~teobaluta/QR_code_fb.jpg
[1] https://lkml.org/lkml/2014/3/17/525

>
> --
> Regards,
> Levente Kurusa


\
 
 \ /
  Last update: 2014-04-05 07:01    [W:1.778 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site