If one points with the camera to a QR-code (like the one in the picture below to get WPA credentials for a public Wifi), millipixel (with a bit luck) shows a flickering rectangle around the QR and it’s a PITA to get the ASCII content into the cut&paste buffer, hitting again and again the blue lines.
Is there some trick to hit the flickering rectangle? Why millipixel not just put the content into the buffer?
the trick is you select it and it will open the browser pretty sure, i noticed in dark places (like most bars) you need to turn on the torch for it to have enough light to read the QR code, I think you dont select the line but the entire rectangle with touch
I think that might be dodgy from a security point of view unless done in response to some explicit user action. You don’t want the mere act of panning the camera across a scene that happens to include a QR code to take any action automatically.
Also, this shouldn’t go into the paste buffer at all.
What should happen is that the QR code is recognised as encoding one of the many possibly supported actions (in this case wifi:...), the application informs the user in readily-understandable terms what would happen if the user tells the phone to “process” the QR code, and the user confirms that the phone should go ahead and process the QR code - which in this case would result in the automatic creation of a WiFi-based network connection and then (presumably) the activation of that connection (association with the WiFi Access Point).
For the record that QR code reads as follows.
WIFI:S:Gastzugang Gasthof Trenner;T:WPA;P:p28p16m29j27;;
(I assume that this really is public WiFi so there’s no problem for me to dox their password but you already made their password public with your post anyway - and hopefully they change the password from time to time also.)
I expressed it wrong. When one finally manages to hit the blue flickering at the right place, a small dialog comes up showing the string from the QR code and with buttons to open it or to copy it (into the cut&paste). My question was: Why not just bring this dialog up, when to QR string is recognized by the cam?
The picture with the QR is in a small restaurant on any table so that the guests do no bother the service personal with this and afterwards use a wrong listened WPA key 
That’s probably right from a usability point of view. I guess the bias here was towards keeping the user in control i.e. things don’t “just happen”. I think that’s always a fine balance (with computers generally).
So the answer for me is always “config”. If you want to have to touch the blue square then configure it that way (user is in control). If you want the dialog box to come up automatically without having to touch the blue square whenever a QR code is recognised1 then configure it that way (easier to use, less interaction required from user).
1I am leaving it open whether “recognised” means “any validly decodable QR code” or “any validly decodable QR code that encodes a supported action” - because probably some users will want individual control over the supported actions e.g. support opening an http: or https: URL in the browser but e.g. not support the sending of an SMS / making of a phone call or e.g. support creating a WiFi connection on a case-by-case basis - and there will always be actions that can’t be supported because there is no code to handle the action.
currently get the error on megapixels from purism repo apt:
/usr/share/megapixels/config/purism,librem5r4.ini not found
Could not find any config file
fro milipixel apt returns
Unable to locate package millipixel
Decoder from flatpak doesn’t detect the cameras.
so what options do we have currently in 2026 for QR codes?
Best I can give is snap a picture with Gnome Camera and read the image file with QTQR.
I just grabbed my phone running Crimson, pointed it to the computer’s screen displaying the photo above and it has instantly (once it focused) shown me a blue rectangle which I could just easily tap and copy the contents of the code into the clipboard.
Well sure it does, once you try it……..
Doh!
I had this issue with a 2FA System too, about the Link, but solved it by Copy the Code. It is working but kind of ugly. We need to fix it. However we need no Camera if its kind of ugly or with a small scale. However its kind of enhance privacy. But we need modern hardware on the L5…
Android/iOS user wants their QR code to automatically open web browser or automatically create a new WiFi entry, because their privacy and security don’t matter to then so opening a URL automatically without asking is fine for them.
Librem 5 user wants to have privacy and security so they might want to read what the URL is and second guess whether to open it. Maybe they want to copy the url and hit it with cURL in command line to check if the site they are connecting to has the zero day vulnerability they are currently interested in.
If the problem then is the usability of this blue square not staying on the screen, why don’t we edit Millipixels to have a QR Code Viewer History button small and usually out of the way. If the blue square is seen once by the camera then disappeared, we can click this small QR Code Viewer History button and it opens a list of QR codes previously observed by the camera in the current process lifetime. Each distinct entry has a button to copy it or open in browser, or whatever else, if that is what the user should choose to do.
In 2026 isn’t it the case that an LLM could add the feature I described above to this application almost instantly? I work in software for my job and face a lot of pressure now that I must use LLMs, or that my work is no longer as valuable, because of this happening. If I lose my job to a future where all software is created all the time, why is software still the Achilles heel of our modern personal computers? I just wrote the prompt above about the second page hidden by the small button.
I read a test where AI had to create code of software problems human already have done just fine. around 3.75% of the generated code by best LLM had a quality equal to human made stuff. And LLMs are already slow down improvements a lot. You chef is just as stupid as most chefs of most bigger companies these days if he forces you using LLMs. Just give a look at Microsoft and Win11 how many features they broke just in a few months … task manager that does not close correctly (fills up memory on any new program start), start-button dysfunctional, terminal broken and many many more such things. “30% AI generated code” … sounds worth it.
So yeah, if you want slop code into your software, go full in with AI. But I don’t want to have it into my devices. A single feature is probably not the big deal, but as more code is generated as more vulnerabilities will be build in over time, especially if not all devs have the same serious attention to validate the code.
The history-feature itself is not a bad idea I think.
I think history may be overkill. Just caching the most recent recognised and decoded QR code URL should be sufficient. However I am not opposed to having history if that’s what people want.
As to what privacy and security measures might be applied before “opening” the URL, that’s probably a much bigger discussion. For a start, a user might want the option to outright disable all such URLs in a given scheme e.g. disable making phone calls from QR codes or e.g. disable sending text messages from QR codes. But if we limit ourselves just to http: and https: URLs, users might want to
Is not really a difference to a list of recently used QR codes. You just argument for the length and/or time until entries become deleted.
Also the current solution only shows the message you can copy or ignore. It does not open anything automatically (and that is good). That also should not change on any kind of history.
… in the sense that if the user is given control over that and a full history list is implemented then I can easily configure in order to get what I want … but
There is also the question of whether the list is persisted e.g. stored on disk. I think the previous post was implying that the list is stored in memory only, which is somewhat better for privacy.
If I would worry a QR-scan-list I probably should not give other people access to my local account. 
UI-wise I would just make a list with maximum n entries (maybe 3-10) with deletion buttons. The actual behavior could be configured in app settings the way people prefer the deletion behavior (or the amount of entries).
I still would call it a kind of history, no matter the implementation. And I don’t care if it gets another name. All the same in my mind.
