linux-kernel - Re: [RFC] QR encoding for Oops messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 04 Apr 2014 18:17:25 +0200
From:	Levente Kurusa <levex@...ux.com>
To:	Jason Cooper <jason@...edaemon.net>, David Lang <david@...g.hm>
CC:	Teodora Băluţă <teobaluta@...il.com>,
	Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Subject: Re: [RFC] QR encoding for Oops messages

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/