<kdebug>qrencode broken since outsourcing of libqrencode

[mmlr]

The outsourced libqrencode library used by the qrencode kernel debugger addon is not built to be usable from the kernel debugger. It was outsourced in hrev47126, which shows the culprit: ​the Jamfile redefined the malloc functions to use their kernel debugger equivalent when building the libqrencode sources, which the outsourced package doesn't do. Using the addon results in normal kernel heap functions being used, which mustn't be used inside the kernel debugger.

I see three options:

• Put the sources back so the library can be built with the defines again.
• Build a kernel debugger version of the libqrencode package.
• Remove the qrencode kernel debugger addon completely.

Since the addon doesn't seem to be in broad use (probably due to it's non-intuitive interface), removing it would be an easy way out. Building a kernel debugger aware package shouldn't be too involved either, as it's just about redefining the malloc functions.

[waddlesplash]

I vote for removing it.

[pulkomandy]

I added a qrencode_kdl recipe to haikuports, which can be used for this. The build features definition needs to be adjusted to use it. It is safe to remove/modify the existing qrencode feature since we don't use this anywhere else.

And I vote for keeping it, and making it simpler to use.

[bonefish]

+1 for removing it. The idea was nice, but I think it would only get really useful, if we also added a phone app for capturing the data in a convenient way (and ideally adding it to a ticket). Otherwise taking a picture of the screen works just as well.

[jessicah]

Fixed in hrev48047.

[pulkomandy]

There is a "qrwebpost" command which will wrap the data in an URL to send it to some pastebin-like service directly. Any qrcode scanning app can be used then. Several qrcodes can be chained and the output is appended to the same post on the web service. And this is documented in the post about qrencode: ​https://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your_kdl_output

I don't know where the webservice is hosted and wether it's still online, however.

[bonefish]

Replying to pulkomandy:

There is a "qrwebpost" command which will wrap the data in an URL to send it to some pastebin-like service directly. Any qrcode scanning app can be used then. Several qrcodes can be chained and the output is appended to the same post on the web service. And this is documented in the post about qrencode: ​https://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your_kdl_output

I understand the process, and that's exactly what I mean. It is not very convenient. The process of taking pictures, connecting the phone to the computer, and adding the pictures to the ticket isn't that complicated and nowadays one cannot complain about the quality of pictures taken by the phone cameras. So for the QR thing to become really usable it would have to be a lot more convenient. I was thinking of an app that captures a complete KDL session (codes could be shown in intervals of a few seconds) and optionally adds it to a ticket directly. Unfortunately it is also quite a bit of work and I don't think the time would be particularly well invested. Time invested in implementing KDL debugging via USB or ethernet OTOH would be, though.

[richienyhus]

Replying to bonefish:

Replying to pulkomandy:

There is a "qrwebpost" command which will wrap the data in an URL to send it to some pastebin-like service directly. Any qrcode scanning app can be used then. Several qrcodes can be chained and the output is appended to the same post on the web service. And this is documented in the post about qrencode: ​https://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your_kdl_output

I understand the process, and that's exactly what I mean. It is not very convenient. The process of taking pictures, connecting the phone to the computer, and adding the pictures to the ticket isn't that complicated and nowadays one cannot complain about the quality of pictures taken by the phone cameras. So for the QR thing to become really usable it would have to be a lot more convenient. I was thinking of an app that captures a complete KDL session (codes could be shown in intervals of a few seconds) and optionally adds it to a ticket directly. Unfortunately it is also quite a bit of work and I don't think the time would be particularly well invested. Time invested in implementing KDL debugging via USB or ethernet OTOH would be, though.

There is also the possability of of using an audio-modem if the midi kit or media kit is available. ​https://github.com/romanz/amodem & ​http://chirp.io

The other option is to use blinking CMYK, CcMmYK or greyscale barcodes and have the user capture that on their cellphone as a video and get them to decode the it to text.

There are iOS and Andriod apps that decode morse code sent via lamp singals/heliographs in real time and an open source project to decode morse code from video.

So it a possability, but obviously a pretty low priority.

Also those blinkin' bebox lights might be a good idea for a comeback: ​http://en.wikipedia.org/wiki/Optical_Wireless_Communications ​http://en.wikipedia.org/wiki/Li-Fi

[phoudoin]

libqrencode already supports structured-append mode, which allow to split data into a sequence of qrcodes. The main issue is on reader side: the usual QR reader apps for mobile phones don't support it. Alas.

[richienyhus]

Replying to phoudoin:

libqrencode already supports structured-append mode, which allow to split data into a sequence of qrcodes. The main issue is on reader side: the usual QR reader apps for mobile phones don't support it. Alas.

What about a web app?

This could be hosted by Haiku and could submit the output to trac.

​http://www.webqr.com

​https://github.com/LazarSoft/jsqrcode ​https://github.com/gmkarl/zxing

[taos]

Sorry to reanimate this ticket, but how is this supposed to work?

Should qrencode for kernel debugger be automatically included in a nightly? If yes, then I can only tell that, at least since outsourcing of qrencode, I haven't been able to use one of the qrencode commands (qrencode, qrappend, ...) in kernel debugger land - not in downloaded nightlies or self-built images (release targets). Alpha 4 used to have a qrencode binary in system/addons/kernel/debugger/ but that is missing from the haiku package.

With qrencode_kdl_devel package installed (there is one for gcc2hybrids available in the repository) I can build <kdebug>qrencode, copy the resulting binary in system/non-packaged/add-ons/kernel/debugger and - after rebooting - go to kdl and use qrencode to generate QR codes. So, in principle this still works. Is there a reason why this binary is not included in a nightly by default? And if there is, is it still possible to include it by editing UserBuildConfig?

I have to admit that I miss this functionality. Cameras of mobile phones might have come a long way in the last few years, they can produce photos of really high quality where you can actually read anything from the kdl output on a WQXGA or UHD screen, however, they still only produce pictures. In contrast to text, pictures that are attached to a ticket can't be searched (at least for now).

[pulkomandy]

This ticket was only about fixing the build issues, as you could test yourself it is posible again to build and enable the feature. However some developers have said this is not useful enough in the current situation, so this was not included in the default image.

I would sugest to put the kernel debugger add-on inside the qrencode_kernel package so installing that is enough to get the command available. This would make it easy to use, without needing to add it to the default haiku install.