Embedding a specific type of keyboard in the efi stub is an advanced requirement - and one could ask - if first introduced - where does it end?
…
If you require a special keymap or other complex steps that GRUB is not able to configure automatically
…
Firstly, taking as an example a requirement for the dvorak keymap embedded in early-boot in order to enter a password for an encrypted /boot on a UEFI system:
…
– GRUB/Tips and tricks - ArchWiki
The distro doesn’t add features, and the features it does add I don’t want
I want Manjaro to add a feature which I want. I can’t do it myself but it’s really important to what I currently think is important so Manjaro should add it.
The developers are lazy because they don’t do what I want them to do, but they still find time to add features which other people ask for. That’s stupid and lazy.
Those features which other people want aren’t what I want, so they are a waste of time and completely bloat.
I hate bloat. Bloat is extra features that I don’t want. Not like the extra features which I do want because they aren’t bloat because I want them.
Why does Manjaro include stuff which I don’t want? Why won’t Manjaro include what I want instead of what other people want?
Why can’t Manjaro be made into what I want, and also what everyone else at the same time wants because they also want what I want (apart from the people who don’t want because they are noob and hate privacy)?
I keep asking for someone else to do something for me over and over and over again and yet they still haven’t done what I want them to. This means Manjaro is terrible and shouldn’t be used by anyone, ever. I never liked Manjaro anyway because it’s made by script kiddies, but I’m doing this because I want Manjaro to be popular because if it did what I wanted then it would be more popular and more people would want to use it because everyone wants the same thing that I want.
It just shows that because you don’t do what I want that you don’t know what you’re doing and I’m never going to recommend Manjaro to anyone.
But if you did do just this one thing which I want then Manjaro would be the best.
Embedding a specific type of keyboard in the efi stub is an advanced requirement
Having a functional keyboard when entering a password is not a advanced requirement, it’s a basic one. Most distros don’t have this issue. This is not an issue for people that use a US QWERTY layout, but not the whole world is the US.
I want Manjaro to add a feature which I want. I can’t do it myself but it’s really important to what I currently think is important so Manjaro should add it.
The developers are lazy because they don’t do what I want them to do, but they still find time to add features which other people ask for. That’s stupid and lazy. […]
You are deforming what I said, and yes this is funny, but you are not addressing the core issue. Please, I don’t want this thread to become an Internet argument where everyone thinks that they are right and that will come to nothing productive. We all want the same thing: improving Manjaro. This is a feedback not a feature request: a simple warning during the install process would be fine, I’m not asking to make every keyboard layouts work in the GRUB.
Also, I was respectful in my initial post, so please don’t twist my words to make me say that “the developers are stupid and lazy”. I have a huge respect for the Manjaro team.
You will always have a functional keyboard - but adressing a specific keyboard - in this case AZERTY instead of QWERTY where the latter is - I think - more common.
It then becomes an advanced use as it requires a custom build of the efi stub and the loader becomes hardcoded to that layout.
Your reference to Ubuntu may be valid - I don’t know - I have never tested exotic keyboard layouts - they could be providiing their own efi stub where they have compiled’in various common layouts.
It is common knowledge that when it comes to passwords et al. you should stay within the bounds of the ASCII character table - because - ASCII is the only charset which is guaranteed to produce the same result on different systems.
Yes - the location of the characters within a keyboard layout may deviate but - the keycode produced for an ASCII character will always be the same no matter the layout.
If you press A on the AZERTY layout it produces the same A on the QWERTY layout.
When you have used a keyboard for as long as I have - I learned typewriting in 1975 - the letters on the keyboard becomes irrelevant - it is their location which matters - you can the set a AZERTY keyboard layout using Danish locale and I would be able to write a danish sentence anyway - using locale specific characters like æøå and know where *'&/(%&= is located as well.
And I know that my keyboard atlethics is above average - but the point is - the qwerty layout is a standard - so memorizing the difference between a AZERTY and QWERTY is a help.
There is no operating system which can accomodate for each and every possible use case.
The reference made in a comment equalling Manjaro Company and Manjaro Linux is null and void.
It is not the same … not by any measure.
Manjaro Linux is a community effort by volunteers - myself included - the community makes it possible by donations - which then makes it possible for the team to rent the necessary server space, attend conferences and buy the necessary hardware used by team members to continue providing a privacy respecting operating system free of charge to anyone.
Speaking of community effort
It would be nice if those requiring specific features actually providing working implementations of how to make it possible - this would make it much more possible the functionality would find it’s way into the ISO.
I kinda see both sides of the issue. And I agree with both.
A simple improvement would be at least an informative message inside the installer, this is possible by Manjaro team easily I think, no need to update Calamares code to add a message warning at some point in the install process.
It is common knowledge that when it comes to passwords et al. you should stay within the bounds of the ASCII character table - because - ASCII is the only charset which is guaranteed to produce the same result on different systems.
Yes - the location of the characters within a keyboard layout may deviate but - the keycode produced for an ASCII character will always be the same no matter the layout.
If you press A on the AZERTY layout it produces the same A on QWERTY.
This is the most important point that was overlooked in the previous thread. I don’t know where this miss-conception come from, but no, if you press a A on the AZERTY layout but the QWERTY layout is loaded, a Q will be produced, not a A. So, even if you use ASCII only character, you will still be impacted by this.
When you have used a keyboard for as long as I have - I learned typewriting in 1975 - the letters on the keyboard becomes irrelevant
I can see why this is not an issue to you, but this kind of “design choice” would throw off new users. Manjaro meant to be “user-friendly and suitable for those new to computers”.
A simple improvement would be at least an informative message inside the installer.
Yes, that would be the right thing to do in my opinion.
You are misunderstanding or misinterpreting my comment.
Forget what is printed on the keycap - an A is an A no matter where it is located - that is my point.
You are referring to - and is confused by - the visual layout - what I am saying is the visual layout is irrelevant when you know what layout is configured.
When you know that grub defaults to US QWERTY layout - you know what key to press to get a specific result.
The amount of work required to implement something, that - in this case a specific keyboard layout in grub - is not a widely recognized issue - simply does not add up.
OK, I see what you meant and I understand why this is a non-issue to you.
I’m just trying to view this in the eyes of a new user, someone who never tried Linux before, who don’t know what GRUB is or what key codes are. If this person types a A and a Q come up. If you start to explain to them that the A is just paint on the key, and that it’s actually a Q, maybe a warning message was needed.
They know it is bound to be different - and they will likely gladly accept the explanation.
The joke aside - I challenge you to come up with a workable solution and create a merge request for Calamares so your contribution will serve for generations to come.
I challenge you to come up with a workable solution and create a merge request for Calamares so your contribution will serve for generations to come.
Thanks for the challenge, but I’m not a Linux dev. I didn’t even knew that Calamares was called that way before starting this thread. I’m just an humble user making a feedback, which is my humble little contribution.
QWERTY is the defacto standard - and this makes the grub defaulting to QWERTY a sane default.
However I like the idea of providing some kind of label to the Encrypt checkbox in Calamares which becomes visible when you choose to encrypt the system - much like the keyphrase boxes which is not visible unless the box is ticked.
I will suggest you create an issue in the Manjaro Gitlab for Calamares - and suggest just that - you are free to use my wording - I will leave that up to you.
It is not that easy and you where correct - of course.
I should have read the link in your post.
What I said only works when one has an unencrypted /boot partition.
The way Calamares installs an encrypted system is fully encrypted and Grub has to do the decryption of the container - not the tools in the initrd. (also the reason for why decryption is so slow)
These are only available once the decryption has already happend - the password has already been given.
This means that one would need to build a custom grub image - which is not exactly easy.
Details here, this post and further down. (link to EOS forum)
The procedure looks a bit daunting:
But a warning/heads up should be added when full encryption is selected, so that people are aware of the potential problem with different keyboard layouts.
What has the efi-stub todo with keyboard layouts
The used layout is used by the software asking for the input, which is not the efi-stub
Exactly
The point is, if you keep to the topic, is the characters interpreted for the password input by the user, which does not use the key-codes but instead uses the produced char…
When it comes to Grub, yes they need to add support for it, just like they did when they made Grub able to decrypt partitions
Need by users makes devs implement stuff, unless they keep saying “I don’t mind cause i don’t use it”…
They could just add another module you can load, like the other modules they use now.
Ofcourse a bit problematic if distro’s keep installing grub in /boot instead of the ESP…
I don’t know why Ubuntu and some other distros don’t have this issue. However this doesn’t seem to be exclusive to Manjaro. Endeavour OS have the same problem.
It seems like the issue comes from upstream Calamares or GRUB. There is indeed an active discussion on the upstream Calamares repo, with someone willing to tackle this.
I don’t think that this discussion is relevant to Manjaro.
While this might be hard to implement, i also think more kbd layouts should be available in the future. Maybe not now but at some point. It is the only logical thing to do in a OS that should be used outside US
That said, i think the Manjaro Team is underestimating the impact of the issue. And the issue is not only with the encryption, it is with the logon (there is en-us indicator on login screen but clicking on it does nothing). I am pretty sure some users were stuck and had to reinstall on the first login because of this. Yes, “common sense”, use passwords in english, but come on…it is 2023 now, not 1993.
The solution if you cannot fix the early boot stages and the login of the OS is at least to sanitize the input field and to warn the user in Calamares installer in the live ISO, or at the very least you must add a note / explanation / warning in Calamares interface where the “choose a password to keep your account safe” field is. Adding another sentence there will take like 30 seconds.
I did a very recent test install using luks encryption using danish input and the subsequent restart inputting the password using danish keyboard layout worked.
I suspect it is a bi-product of the recent plymouth boot splash implementation as it is plymouth which is handling the password prompt.
I have to take this back. I discovered today, the small language menu in LightDM greeter actually works. But it uses the default manjaro touchpad behavior and you have to press the touchpad and not just tap…
