lkml.org 
[lkml]   [2014]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] QR encoding for Oops messages
    Hi,

    On 04/04/2014 11:42 PM, Teodora Băluţă wrote:
    > 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. :-)

    Awesome, good luck on your thesis, take your time, we are not
    rushing. :-)

    Yea, I began the work on the parameter and scaling but using
    'oops.qr=' isn't easy to use in a file called 'print_oops.c'.
    Reason is that KBUILD_MODNAME will become 'print_oops' and then
    MODULE_PARAM_PREFIX will be 'print_oops.' (note the dot character)
    and so the final parameter will be 'print_oops.qr'. I have solved
    this with:

    #undef MODULE_PARAM_PREFIX
    #define MODULE_PARAM_PREFIX "oops."

    but I think this is ugly and is a hack. The good solution
    would be to change KBUILD_MODNAME to 'oops' but I am not sure
    how to do that, since I have little to no knowledge (and
    experience) in how kbuild works.

    Or, we could use core_param and simply have 'oops_qr' or
    'qr_oops'. In my humble opinion the latter sounds better.

    Or, there is __setup as well and that could achieve 'oops.qr',
    but that is for *very* core stuff and this is probably not *that*
    core. :-)

    So, yea, if anyone knows how to change KBUILD_MODNAME without
    ugly hacks, I would be grateful to be informed.


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

    I am not sure if we ever wanted to output a link, but yes filling the
    screen with ASCII characters and relying on the error recovery to
    ensure readability is very bad.

    Nice screenshot, I had as well successfully set up a testsuite
    with qemu that allows me to test if it displays correctly. I can
    share the testsuite if needed.

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

    Not sure, since we are already in a very bad situation when the
    Oops happens, I think it is better use something that has existed
    for ages and seems to be a bit more simple, and has less chance to
    fail. Adding a lot of new code to a fragile part of the kernel
    is a hotbed for a recursive oops so I would say just stick with
    fb for now...

    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.


    --
    Regards,
    Levente Kurusa
    --
    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/

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