On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote:
> Hi all,
>
> (sorry for the late reply, looks like this mail has ran away from my clients)
>
> 2014-03-23 20:38 GMT+01:00 Jason Cooper <[email protected]>:
> > All,
> >
> > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote:
> >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa <[email protected]> wrote:
> >> > On 03/21/2014 02:28 PM, Jason Cooper wrote:
> > ...
> >> >> I would definitely like to see the QR output incorporated into a
> >> >> kernel.org url. That would remove the need for installing another app,
> >> >> and would ease bug reporting.
> >> >
> >> > I still struggle to understand how could that be done. We can encode the
> >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding
> >> > 'Unable to handle kernel paging request at 0000000f' gave a 449 character
> >> > long sequence with very strange characters [0]. We should try to shorten
> >> > it, imho. Not sure how to do that though.
> >
> > The man page for qrencode says you can have up to 4000 characters in a
> > qrcode. However, I've seen readers have trouble with a 2048bit ascii
> > armored PGP public key (3929 characters).
> >
> > I grabbed a random oops from oops.kernel.org, it weighed in at 1544
> > bytes, not too bad. I then did:
> >
> > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0`" | wc -c
> > 993
>
> I did the same with another OOPS and it had 1953 characters. That's quite a big
> a big difference! :-)
>
> I created a QR image from the URL then, and it was 147x147, which is
> pretty small.
> It took me quite a long time to make my phone recognize it, but it
> worked nicely.
>
> Result of work is in this directory:
>
> http://levex.fedorapeople.org/kernel/qr/
nice!
> > The benefit of a url is that any QR reader can automagically report an
> > oops. While a specific app could parse the URL/oops locally if the
> > user desires.
> >
> >> it misses the point of having a QR code in the first place. The way I
> >> see it, having a QR decoder app installed that can do an offline
> >> decoding is a less greater effort than popping out a browser on the
> >> machine you're working on.
> >
> > I think you're selling the advantage of the QR code short. Automated
> > reporting (via the url) is a _huge_ plus. The app you conceive of could
> > still parse it in place if the user desires.
> >
> > My point for the URL isn't to use the internet/server to automate oops
> > parsing for the user. Rather it's to make it easy to report oopses to
> > developers. While still preserving the ability of your app to parse it
> > for the user.
>
> Ah I see now. oops.kernel.org/?qr=<QR> would simply parse the
> base64'd+gzip'd oops message and then report it.
If you mean the server behind oops.k.o would parse it, then yes. No
special app should be required other than a QR code scanner for the
usecase of reporting oopses to developers.
> 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. ;-)
thx,
Jason.
On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper <[email protected]> wrote:
> On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote:
>> Hi all,
>>
>> (sorry for the late reply, looks like this mail has ran away from my clients)
same here.
>>
>> 2014-03-23 20:38 GMT+01:00 Jason Cooper <[email protected]>:
>> > All,
>> >
>> > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote:
>> >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa <[email protected]> wrote:
>> >> > On 03/21/2014 02:28 PM, Jason Cooper wrote:
>> > ...
>> >> >> I would definitely like to see the QR output incorporated into a
>> >> >> kernel.org url. That would remove the need for installing another app,
>> >> >> and would ease bug reporting.
>> >> >
>> >> > I still struggle to understand how could that be done. We can encode the
>> >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding
>> >> > 'Unable to handle kernel paging request at 0000000f' gave a 449 character
>> >> > long sequence with very strange characters [0]. We should try to shorten
>> >> > it, imho. Not sure how to do that though.
>> >
>> > The man page for qrencode says you can have up to 4000 characters in a
>> > qrcode. However, I've seen readers have trouble with a 2048bit ascii
>> > armored PGP public key (3929 characters).
>> >
>> > I grabbed a random oops from oops.kernel.org, it weighed in at 1544
>> > bytes, not too bad. I then did:
>> >
>> > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0`" | wc -c
>> > 993
>>
>> I did the same with another OOPS and it had 1953 characters. That's quite a big
>> a big difference! :-)
>>
>> I created a QR image from the URL then, and it was 147x147, which is
>> pretty small.
>> It took me quite a long time to make my phone recognize it, but it
>> worked nicely.
>>
>> Result of work is in this directory:
>>
>> http://levex.fedorapeople.org/kernel/qr/
>
> nice!
>
>> > The benefit of a url is that any QR reader can automagically report an
>> > oops. While a specific app could parse the URL/oops locally if the
>> > user desires.
>> >
>> >> it misses the point of having a QR code in the first place. The way I
>> >> see it, having a QR decoder app installed that can do an offline
>> >> decoding is a less greater effort than popping out a browser on the
>> >> machine you're working on.
>> >
>> > I think you're selling the advantage of the QR code short. Automated
>> > reporting (via the url) is a _huge_ plus. The app you conceive of could
>> > still parse it in place if the user desires.
>> >
>> > My point for the URL isn't to use the internet/server to automate oops
>> > parsing for the user. Rather it's to make it easy to report oopses to
>> > developers. While still preserving the ability of your app to parse it
>> > for the user.
>>
>> Ah I see now. oops.kernel.org/?qr=<QR> would simply parse the
>> base64'd+gzip'd oops message and then report it.
>
> If you mean the server behind oops.k.o would parse it, then yes. No
> special app should be required other than a QR code scanner for the
> usecase of reporting oopses to developers.
>
>> 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. ;-)
Ok, this may work. I agree that doing this with the help of the frame
buffer is more natural.
Thanks,
--
Teodora
>
> thx,
>
> Jason.
Hi,
2014-04-01 23:07 GMT+02:00 Teodora B?lu?? <[email protected]>:
> On Tue, Apr 1, 2014 at 5:20 PM, Jason Cooper <[email protected]> wrote:
>> On Sun, Mar 30, 2014 at 12:17:17PM +0200, Levente Kurusa wrote:
>>> Hi all,
>>>
>>> (sorry for the late reply, looks like this mail has ran away from my clients)
>
> same here.
>
>>>
>>> 2014-03-23 20:38 GMT+01:00 Jason Cooper <[email protected]>:
>>> > All,
>>> >
>>> > On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora B?lu?? wrote:
>>> >> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa <[email protected]> wrote:
>>> >> > On 03/21/2014 02:28 PM, Jason Cooper wrote:
>>> > ...
>>> >> >> I would definitely like to see the QR output incorporated into a
>>> >> >> kernel.org url. That would remove the need for installing another app,
>>> >> >> and would ease bug reporting.
>>> >> >
>>> >> > I still struggle to understand how could that be done. We can encode the
>>> >> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding
>>> >> > 'Unable to handle kernel paging request at 0000000f' gave a 449 character
>>> >> > long sequence with very strange characters [0]. We should try to shorten
>>> >> > it, imho. Not sure how to do that though.
>>> >
>>> > The man page for qrencode says you can have up to 4000 characters in a
>>> > qrcode. However, I've seen readers have trouble with a 2048bit ascii
>>> > armored PGP public key (3929 characters).
>>> >
>>> > I grabbed a random oops from oops.kernel.org, it weighed in at 1544
>>> > bytes, not too bad. I then did:
>>> >
>>> > $ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0`" | wc -c
>>> > 993
>>>
>>> I did the same with another OOPS and it had 1953 characters. That's quite a big
>>> a big difference! :-)
>>>
>>> I created a QR image from the URL then, and it was 147x147, which is
>>> pretty small.
>>> It took me quite a long time to make my phone recognize it, but it
>>> worked nicely.
>>>
>>> Result of work is in this directory:
>>>
>>> http://levex.fedorapeople.org/kernel/qr/
>>
>> nice!
>>
>>> > The benefit of a url is that any QR reader can automagically report an
>>> > oops. While a specific app could parse the URL/oops locally if the
>>> > user desires.
>>> >
>>> >> it misses the point of having a QR code in the first place. The way I
>>> >> see it, having a QR decoder app installed that can do an offline
>>> >> decoding is a less greater effort than popping out a browser on the
>>> >> machine you're working on.
>>> >
>>> > I think you're selling the advantage of the QR code short. Automated
>>> > reporting (via the url) is a _huge_ plus. The app you conceive of could
>>> > still parse it in place if the user desires.
>>> >
>>> > My point for the URL isn't to use the internet/server to automate oops
>>> > parsing for the user. Rather it's to make it easy to report oopses to
>>> > developers. While still preserving the ability of your app to parse it
>>> > for the user.
>>>
>>> Ah I see now. oops.kernel.org/?qr=<QR> would simply parse the
>>> base64'd+gzip'd oops message and then report it.
>>
>> If you mean the server behind oops.k.o would parse it, then yes. No
>> special app should be required other than a QR code scanner for the
>> usecase of reporting oopses to developers.
Yup, clear now.
>>
>>> 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. ;-)
>
> Ok, this may work. I agree that doing this with the help of the frame
> buffer is more natural.
Okay, Teodora I'll send you a commit ASAP and then
we should start working on getting libqr into an acceptable
state. I am not sure if we can shuffle it into staging though,
it's not a driver and AFAIK staging.git is for drivers which aren't
yet finished. So, I would say, let's start working on fixing the
OOPness of libqr first. If we were to rework that, then
we can as well avoid having GFP_ATOMIC in library code
by using the more conventional kmalloc(struct); init_struct(ptr);
scheme.
Oh and I had an idea of adding a new kernel parameter, something
like 'qr_oops.*'. (Looking for a better name! :-) )
Basically, I thought of the following options so far:
* qr_oops.disable=1 - disable it
* qr_oops.scale=600x600 - scale the qr code so its easier to read
with a phone. In my testing I had huge difficulties reading the
QR codes, but when scaled to be a bit bigger it worked magically.
This might not be so easy to implement this way, but with preset
values, i.e. 4x4 squares instead of a pixel, it could work.
Objections, ideas are welcome!
Teodora, have you worked on anything recently in qr-linux-kernel?
Just to make sure we aren't working on the same.
Thanks,
Levente Kurusa
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.
David Lang
On Thu, Apr 03, 2014 at 10:21:39PM +0200, Levente Kurusa wrote:
...
> Oh and I had an idea of adding a new kernel parameter, something
> like 'qr_oops.*'. (Looking for a better name! :-) )
> Basically, I thought of the following options so far:
>
> * qr_oops.disable=1 - disable it
> * qr_oops.scale=600x600 - scale the qr code so its easier to read
> with a phone. In my testing I had huge difficulties reading the
> QR codes, but when scaled to be a bit bigger it worked magically.
> This might not be so easy to implement this way, but with preset
> values, i.e. 4x4 squares instead of a pixel, it could work.
oops.qr=0 - disabled
oops.qr=3 - make each QR pixel 3x3 screen pixels.
I've found 3x3 works well for business cards and such.
0.02c...
thx,
Jason.
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'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...
thx,
Jason.
Hi,
On 04/04/2014 05:12 PM, Jason Cooper wrote:
> On Thu, Apr 03, 2014 at 10:21:39PM +0200, Levente Kurusa wrote:
> ...
>> Oh and I had an idea of adding a new kernel parameter, something
>> like 'qr_oops.*'. (Looking for a better name! :-) )
>> Basically, I thought of the following options so far:
>>
>> * qr_oops.disable=1 - disable it
>> * qr_oops.scale=600x600 - scale the qr code so its easier to read
>> with a phone. In my testing I had huge difficulties reading the
>> QR codes, but when scaled to be a bit bigger it worked magically.
>> This might not be so easy to implement this way, but with preset
>> values, i.e. 4x4 squares instead of a pixel, it could work.
>
> oops.qr=0 - disabled
> oops.qr=3 - make each QR pixel 3x3 screen pixels.
>
> I've found 3x3 works well for business cards and such.
>
Yea this makes more sense. I'll go and implement this
right now and send the changes to Teodora once finished.
--
Regards,
Levente Kurusa
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
On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa <[email protected]> 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
Hi,
On 04/04/2014 11:42 PM, Teodora Băluţă wrote:
> On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa <[email protected]> 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
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.
Hi,
On 04/07/2014 05:20 PM, Jason Cooper wrote:
> 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. :-)
Pushed to Teodora. Hopefully she will pull it soon.
>
>> 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.
Yup, I'll be traveling on the train a lot this week, so I'll
have plenty of time to implement scaling and centering. Maybe
we could also implement this:
qr_oops=center (center the QR code with scale 1)
qr_oops=center,3 (center the QR code with scale 3)
'center' could also be 'topleft', 'bottomright', etc.
Or just remain at the KISS rule? (keep it simple)
Any objections?
>
> 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.
Yea we also need to prevent it from happening on panics. Currently on
panics, (i.e. exit when init=/bin/sh) will cause half of the QR code
not rendered on screen due to some reason. It looks like it is due
to scrolling, but I am not sure then why doesn't happen when I
do 'echo c > /proc/sysrq-trigger' which as well causes a panic.
Any ideas why this happens?
--
Regards,
Levente Kurusa
PGP: 4EF5D641
On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote:
> On 04/07/2014 05:20 PM, Jason Cooper wrote:
> > On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote:
> >> 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.
>
> Yup, I'll be traveling on the train a lot this week, so I'll
> have plenty of time to implement scaling and centering. Maybe
> we could also implement this:
>
> qr_oops=center (center the QR code with scale 1)
> qr_oops=center,3 (center the QR code with scale 3)
>
> 'center' could also be 'topleft', 'bottomright', etc.
> Or just remain at the KISS rule? (keep it simple)
>
> Any objections?
KISS. ;-)
Iff we find we need the feature later, we can always add qr_oops_pos or
similar.
thx,
Jason.
Hi,
On 04/08/2014 07:20 PM, Jason Cooper wrote:
> On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote:
>> On 04/07/2014 05:20 PM, Jason Cooper wrote:
>>> On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote:
>>>> 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.
>>
>> Yup, I'll be traveling on the train a lot this week, so I'll
>> have plenty of time to implement scaling and centering. Maybe
>> we could also implement this:
>>
>> qr_oops=center (center the QR code with scale 1)
>> qr_oops=center,3 (center the QR code with scale 3)
>>
>> 'center' could also be 'topleft', 'bottomright', etc.
>> Or just remain at the KISS rule? (keep it simple)
>>
>> Any objections?
>
> KISS. ;-)
>
> Iff we find we need the feature later, we can always add qr_oops_pos or
> similar.
>
Alright, I'll start the work on that tomorrow.
Maybe I'll also find some time to clean up the library,
since I guess that should be our primary priority.
--
Regards,
Levente Kurusa
PGP: 4EF5D641
Hi,
2014-04-08 19:29 GMT+02:00 Levente Kurusa <[email protected]>:
> Hi,
>
> On 04/08/2014 07:20 PM, Jason Cooper wrote:
>> On Tue, Apr 08, 2014 at 05:42:00PM +0200, Levente Kurusa wrote:
>>> On 04/07/2014 05:20 PM, Jason Cooper wrote:
>>>> On Sat, Apr 05, 2014 at 11:11:02AM +0200, Levente Kurusa wrote:
>>>>> 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.
>>>
>>> Yup, I'll be traveling on the train a lot this week, so I'll
>>> have plenty of time to implement scaling and centering. Maybe
>>> we could also implement this:
>>>
>>> qr_oops=center (center the QR code with scale 1)
>>> qr_oops=center,3 (center the QR code with scale 3)
>>>
>>> 'center' could also be 'topleft', 'bottomright', etc.
>>> Or just remain at the KISS rule? (keep it simple)
>>>
>>> Any objections?
>>
>> KISS. ;-)
>>
>> Iff we find we need the feature later, we can always add qr_oops_pos or
>> similar.
>>
>
> Alright, I'll start the work on that tomorrow.
>
> Maybe I'll also find some time to clean up the library,
> since I guess that should be our primary priority.
Just a quick reminder that scaling was just merged in [0].
I'd highly appreciate feedback. Thanks!
Now that rendering is a bit cleaner I'll start cleaning up
the library. This is what I intend to do next week:
* Extract bitstream.c into a new kernel library. No point
in restricting this to QR only.
* Rework bitstream to propagate errors, to use a caller
allocation scheme and remove the ugly OOPness.
* Fix up the QR library so that it propagates errors
from the new bitstream code.
Any objections?
[0]: https://github.com/teobaluta/qr-linux-kernel/commit/70401a9918e0810e7b0784fa6e1bdc766df20352
--
Regards,
Levente Kurusa
PGP: 4EF5D641
