There's a few things there.

The console keyboard layout you get should be, I think, /usr/lib/kbd/keymaps/xkb/ge.map.gz . That's an auto-converted xkb layout. For consistency between graphical and console environments, in Fedora, we mostly ship console layouts that are converted from xkb layouts. The exception is that, if we detect that the xkb-converted layout cannot input ASCII characters, we delete it and fall back on the 'legacy' layout from kbd. The check we use is whether the layout has a mapping for the Latin character 'A', which ge.map.gz does indeed have:

keycode 30 = +U+10d0 +U+0041 +U+10fa +U+10fa Control_a Control_a +U+10fa Control_a Meta_A Meta_A +U+10fa Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+10d0 +U+0041 +U+10fa +U+10fa Control_a Control_a +U+10fa Control_a Meta_A Meta_A +U+10fa Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+10d0 +U+0041 +U+10fa +U+10fa Control_a Control_a +U+10fa Control_a Meta_A Meta_A +U+10fa Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+10d0 +U+0041 +U+10fa +U+10fa Control_a Control_a +U+10fa Control_a Meta_A Meta_A +U+10fa Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+1c90 +U+0061 +U+1cba +U+1cba Control_a Control_a +U+1cba Control_a Meta_A Meta_A +U+1cba Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+1c90 +U+0061 +U+1cba +U+1cba Control_a Control_a +U+1cba Control_a Meta_A Meta_A +U+1cba Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+1c90 +U+0061 +U+1cba +U+1cba Control_a Control_a +U+1cba Control_a Meta_A Meta_A +U+1cba Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a +U+1c90 +U+0061 +U+1cba +U+1cba Control_a Control_a +U+1cba Control_a Meta_A Meta_A +U+1cba Meta_A Meta_Control_a Meta_Control_a Meta_Control_a Meta_Control_a

But...looking at that...it looks like this layout can input Latin *capital* letters - A, D etc. - but not *lower case* ones - it doesn't have a mapping for U+0061, which is a lower-case a. It looks like the key that's A on a US keyboard inputs A when shifted, but the Georgian character ა when not shifted. Is that right?

If so, we should probably wipe the xkb-converted layout. But that presents another problem: what would we fall back to in that case? There doesn't appear to be a Georgian layout in kbd at all - I can't find one under /usr/lib/kbd/keymaps/legacy , which is where all the 'original' kbd layouts live. So if we don't have the xkb-converted layout, Georgian installs would probably wind up using a US layout at the console. Is that what Georgian users would expect?

The second thing is the display of Georgian characters at the console. Console fonts are limited in size; they can't contain enough characters to display all scripts. So there are various fonts which can display various sets of characters. The default for Fedora is eurlatgr, which supports European languages written in Latin or Greek script (hence the name). anaconda does have a codepath, though, which looks up whether langtable tells it to use a *different* console font for the chosen language, and if it does, it will use that font instead (if this codepath works, I don't think we test it). Looking at langtable, it has an entry for Georgian, and it specifies a console font...but the font it specifies is latarcyrheb-sun16 (see https://raw.githubusercontent.com/mike-fabian/langtable/refs/heads/main/langtable/data/languages.xml ). That font, AIUI, supports (to some extent) Latin, Arabic, Cyrillic, and Hebrew scripts...but not Georgian.

The console fonts also come from kbd - https://github.com/legionus/kbd/tree/master/data/consolefonts . As best as I can tell, sadly, none of them has Georgian characters :/ So I guess latarcyrheb-sun16 was picked for Georgian on the basis it might at least be useful to render some Cyrillic characters, or something.

So on the whole, it seems like the best we could do here - without somebody implementing a console font that supports Georgian characters, and a 'native' console layout for Georgian, with switching between Georgian and Latin characters, like ru.map.gz for Russian with Cyrillic/Latin switching - is just to tweak the 'non-ASCII-capable' detection in kbd.spec to check for both lower-case 'a' *and* upper-case 'A' support, and wipe the layout if it doesn't have both. That would just cause Georgian installs to use a US layout at the console, which is probably better than a layout that can only type characters you can't see, and upper-case Latin characters :/

https://src.fedoraproject.org/rpms/kbd/pull-request/2 should check for 'a' as well as 'A' and thus cause xkb-converted ge.map.gz to be wiped.

https://manpages.debian.org/testing/console-setup/console-setup.5.en.html seems to suggest Debian has a console font called "Fixed" which covers Georgian (and, somehow, every other character set in the world? seems suspicious) but...it's a bit weird, and I can't find any other reference to such a console font, so I'm not sure what's going on there. Have you tried Ubuntu or Debian in Georgian? Are they capable of typing/rendering Georgian characters at the console?

Hi,

Firstly, thank you for prompt reply.

Will try to answer them:

But...looking at that...it looks like this layout can input Latin *capital* letters - A, D etc. - but not *lower case* ones - it doesn't have a mapping for U+0061, which is a lower-case a. It looks like the key that's A on a US keyboard inputs A when shifted, but the Georgian character ა when not shifted. Is that right?

- A is not displayed at all when layout is Georgian. a however, is ა.

If so, we should probably wipe the xkb-converted layout. But that presents another problem: what would we fall back to in that case? There doesn't appear to be a Georgian layout in kbd at all - I can't find one under /usr/lib/kbd/keymaps/legacy , which is where all the 'original' kbd layouts live. So if we don't have the xkb-converted layout, Georgian installs would probably wind up using a US layout at the console. Is that what Georgian users would expect?

- Most probably - yes. Is there any way to just switch layout in CLI before login to en_US? Also, just as a remark, Georgian language code is "ka", not "ge" (not completely true tho, I've seen "ge" also.

Have you tried Ubuntu or Debian in Georgian? Are they capable of typing/rendering Georgian characters at the console?

- Does exactly the same. I just am more familiar to RH systems, so preferred to ask here :)

The console fonts also come from kbd - https://github.com/legionus/kbd/tree/master/data/consolefonts . As best as I can tell, sadly, none of them has Georgian characters :/ So I guess latarcyrheb-sun16 was picked for Georgian on the basis it might at least be useful to render some Cyrillic characters, or something.

- Now, three's a thing. that font by some reason/magic really has (at least, had) Georgian symbols in.
Other than that, I found a guy who draw and released font in GPL
link: https://bpgfonts.wordpress.com/2017/12/21/bpg-2017-dejavu-sansmono/
license: https://bpgfonts.wordpress.com/2018/09/07/gnu-gpl-license-grant-to-linux-distributors/

But file is TTF and I really got no idea how to convert it to psfu (tried several things, but none of them worked).

Hope I answered all questions.

(In reply to Adam Williamson from comment #3)
> https://manpages.debian.org/testing/console-setup/console-setup.5.en.html
> seems to suggest Debian has a console font called "Fixed" which covers
> Georgian (and, somehow, every other character set in the world? seems
> suspicious) but...it's a bit weird, and I can't find any other reference to
> such a console font, so I'm not sure what's going on there. Have you tried
> Ubuntu or Debian in Georgian? Are they capable of typing/rendering Georgian
> characters at the console?

Could it be this?

$ rpm -ql console-setup | grep Fixed
...
/usr/share/consolefonts/Georgian-Fixed13.psf.gz
/usr/share/consolefonts/Georgian-Fixed14.psf.gz
/usr/share/consolefonts/Georgian-Fixed15.psf.gz
/usr/share/consolefonts/Georgian-Fixed16.psf.gz
/usr/share/consolefonts/Georgian-Fixed18.psf.gz
...

> - A is not displayed at all when layout is Georgian. a however, is ა.

Sorry, I should have clarified - this question only applies to console mode. Graphical mode behaves differently (see below). Is that still the case in console mode? I guess I can just do a Georgian install and see for myself...

> - Most probably - yes. Is there any way to just switch layout in CLI before login to en_US?

So, "switching layout" is a complex concept here :D Linux really has two completely different keyboard layout concepts; that's the big factor in this and various other similar cases. There are two keyboard input systems commonly used in Linux, xkb and kbd. xkb is used in graphical environments (Wayland as well as X). kbd is used at the console (that is, when you're really at a VT with just a console on it, not for terminal apps in graphical environments). Each has its own format for defining layouts, and - historically - a separate set of layout definitions that weren't always entirely consistent with each other.

In xkb, when you "switch layouts", you really switch layouts. The xkb Georgian ('ge') layout only defines the mappings you need to type Georgian. When you need to type English/Latin characters, you literally "switch" to the 'us' layout, right? Most desktops have some kind of indicator for this.

kbd does not implement layout switching in the same way. At a console, you really only have one layout loaded at a time, and the only way to really "switch layouts" is to actually run 'loadkeys' or something like that. So for cases where we really need to 'switch' layout at the console, the way it actually works is that the layout has *both* necessary mappings in it. If you look at /usr/lib/kbd/keymaps/legacy/i386/qwerty/ru.map.gz , which is very nicely commented, you'll see it has *four* mappings for each letter key. The key alone inputs a lower-case Latin character, the key plus shift inputs an upper-case Latin character, the key plus alt-gr inputs a lower-case Cyrillic character, and the key plus alt-gr plus shift inputs an upper-case Cyrillic character. When you 'switch inputs' at the console with ctrl+shift, what actually happens is that it does "alt-gr lock" - just like "caps lock" locks the shift key down, it locks the alt-gr key down. So now every key press has an implied alt-gr, unless you hold the alt-gr key, and so you have effectively 'switched' to inputting Cyrillic characters with non-modified keypresses. (So if you have this layout loaded, when it's in "Latin mode" you can still type Cyrillic by holding down the alt-gr key, and vice versa; this isn't the case with xkb).

This is why we have to have this mechanism that throws out xkb-converted layouts that can't input ASCII. For keyboard layouts that are just different ways of inputting the ASCII characters (plus whatever others they support), and which aren't typically "switched" with a different Latin layout, the xkb-converted layouts are fine. But the xkb-converted kbd layouts for "switched" layouts are useless due to this difference. The mechanism mainly exists to find these "switched" layouts and throw out the xkb-converted versions so we use the "legacy" (correct) kbd layouts with internal switching instead.

Sorry for the lecture, but all this is to explain - since there's no ge.map.gz with Latin characters on the regular levels and Georgian characters on the alt-gr levels, like we have for Russian and several others, there is no way to "switch layouts" for Georgian at the console. All we can do is give you the kinda useless xkb-converted layout which you can't type lower-case Latin characters with, or give you a US layout (or we could give you some other layout if that's more commonly used for Latin input in Georgia, but it looks to me like US is the expected layout for Latin input, right?)

> Also, just as a remark, Georgian language code is "ka", not "ge" (not completely true tho, I've seen "ge" also.

ge is the country code for "Georgia" - see https://www.iban.com/country-codes . ka is the language code for "Georgian" - see https://www.loc.gov/standards/iso639-2/php/code_list.php . Keyboard layouts are generally named for a country, not a language, as layouts are commonly most strongly associated with *countries* rather than with *languages* (or scripts).

> - Now, three's a thing. that font by some reason/magic really has (at least, had) Georgian symbols in.

So, there are plenty of fonts with Georgian characters. That's why you can type and see them no problem in a *graphical* environment (like the installer). But console fonts are different. TrueType (ttf) - and other font types usually used in graphical environments, like OpenType (otf) - are "vector fonts". They kinda "describe a shape". Console fonts are bitmap fonts: they're basically pixel art. Each character is drawn, pixel-by-pixel. That means they don't scale (unless the designer implements multiple sizes - that's what's going on when you see fonts in /usr/lib/kbd/consolefonts like 'lat9u-08.psfu.gz'. 'lat9u-10.psfu.gz', 'lat9u-12.psfu.gz' etc., those are all the same font at different sizes).

Since these are really different approaches, 'converting' fonts between the two usually doesn't work well. 'converting' a bitmap font to a vector font will usually give you a weirdly blocky mess that doesn't scale properly. 'converting' a vector font to a bitmap font will give you a smeary mess that's hard to read. You really need a *native* font in both cases.

Terminal apps in graphical environments can usually use either vector or bitmap fonts (though these days they pretty much always default to using a vector font, and we have some really nice ones), but real consoles can only do bitmap fonts. So we'd need a bitmap font with support for Georgian characters to display them at a console. We can't use any of the vector fonts we have that support Georgian characters. This is why (according to your initial description) you only see blocks when typing Georgian at a console. If you mean that in *some* situation you saw Georgian characters at a console (a real console, not just a terminal in a desktop), that would mean there *is* an appropriate console font somewhere, which would be great news...but I'm not sure if that's what you're saying.

One thing you might be wondering by this point in my lecture is "why can't the console just support xkb and vector fonts?" And this is an excellent question! It would make the experience way better for users, and make things much simpler for distributors. There's no fundamental reason it can't. But it doesn't. There've been a few efforts to implement this, but AFAIK they're all kinda stalled / abandoned at this point. It doesn't look like it's a high enough priority for anyone with enough resources to actually get all the work done and all the changes accepted by various upstreams (including the kernel).

Vitezslav: oh yeah, I guess that is it. Maybe we can steal it? It's kinda useless without a font, though. I wonder if Debian also has a console font with Georgian support somewhere? I don't see one in console-setup, though.

oh, hey, looks like there's a 'georgian' bitmap font in BDF format in https://sources.debian.org/src/console-setup/1.233/Fonts/bdf/ . maybe we can rip that, and the keyboard layout, from console-setup, submit them to kbd upstream, and backport them downstream? I'll try and find some time to poke at this later...

sigh, got confused between fonts and layouts. so poking at this a bit more - console-setup has a whole thing for building combined PSF fonts out of BDF 'sources' on the fly, the Georgian-Fixed14.psf fonts Vitezslav found are the outputs from that, the bdf dir I found is the inputs. So we can either just copy or rebuild that PSF font to get console Georgian character display support. It also has a whole thing for building kbd layouts from xkb ones, by the looks of it, kinda like our on-the-fly conversions in the kbd package but more extensive; I'm looking into that now to see if it produces a usable console switched georgian layout, and if so, how to steal/reproduce it.

Sorry, I should have clarified - this question only applies to console mode. Graphical mode behaves differently (see below). Is that still the case in console mode? I guess I can just do a Georgian install and see for myself...

-> actually, both. nothing happens if I press shift+a when in "Georgian console" neither in Graphical nor in terminal, nor in ssh connection.

So, "switching layout" is a complex concept here :D Linux really has two completely different keyboard layout concepts; that's the big factor in this and various other similar cases. There are two keyboard input systems commonly used in Linux, xkb and kbd. xkb is used in graphical environments (Wayland as well as X). kbd is used at the console (that is, when you're really at a VT with just a console on it, not for terminal apps in graphical environments). Each has its own format for defining layouts, and - historically - a separate set of layout definitions that weren't always entirely consistent with each other.

-> Oh yeah, I've asked my friend to go through systemd-logind source for this and he said he'll better fight a bull with bare hands rather try to implement this :)

About rendering fonts, I almost got it :) ( I'm with RH from 2001, was compiling freetype and fontconfig by hand when needed :) )

ge is the country code for "Georgia" - see https://www.iban.com/country-codes . ka is the language code for "Georgian" - see https://www.loc.gov/standards/iso639-2/php/code_list.php . Keyboard layouts are generally named for a country, not a language, as layouts are commonly most strongly associated with *countries* rather than with *languages* (or scripts).

-> Agree :)

Answer on last part is rendering process on terminal :) especially hinting. noone can guarantee videodrivers will not give up on "dmesg"

About stealing/forking/whatever, please, just make it happen.

Also, my question is, even if font will be there and I'll see unicode, how I will be entering my user and password in latin while keyboard will have Georgian layout?

I mean, this makes sense for LC_MESSAGES, but not with input.

In case there is anything I can help with to solve all this burden, please feel free to ask :)

P.S. how to know if font works? Just try to type. Georgian is extremely beautiful to look  at :)

And another question: How do other languages do it? Like Ukrainian, for example. If one installs RHEL in Ukrainian, on bootup one is able to login on terminal (CLI/multi-user.target, you name it) in Latin?

So for languages where we have a proper console switched layout, the unmodified levels of the layout type *Latin*, not the native language. So effectively the layout is in "Latin mode" on boot. The modified levels of the layout type the native language. So you have to "switch layout" to type native characters. So yes, you can type passwords, usernames and so on in Latin at boot.

I've been poking at this for the last few hours and I don't understand everything console-setup does, but it has a thing called kbdcompiler which outputs a kinda huge concatenated stream of kbd layout definitions that use includes heavily, including a Georgian one which - when you parse out all the includes - should more or less implement a switched Georgian layout. I've kinda manually parsed that into a standalone file (and added an alt-gr lock definition, which it was missing). I also managed to 'compile' the georgian14 combined psf font properly (I think). I've patched both of those into a test build of our kbd package - https://koji.fedoraproject.org/koji/taskinfo?taskID=127747432 . If you update to that, you *should* be able to load the 'ge' layout and the 'georgian14' console font and things should work; by default it will type Latin characters, you should be able to press ctrl+shift to type georgian characters instead, and you should be able to see them.

I didn't look at the graphical case yet - I understood your initial report to mean you could type Georgian in the installer, so I assumed it was working OK there. If it doesn't, I can look into that later. Possibly we're just missing a bit in systemd and/or langtable (I forget which one anaconda uses these days) to tell anaconda that it should configure the ge and us xkb layouts together.

For GUI part, there's less troubles, other than gdm showing only Georgian input option by some reason, but after I had to move to new laptop (reinstalled Fedora) issue just disappeared.

For console...
I'm sorry, somehow there is no screenshot attachment button anymore, so you have to trust me on words.
On my fc rawhide virtualbox vm I somehow managed to get Latin input working while having ka_GE as LC_LANG. However, any "dnf update" commands would still give squares on terminal.
After updating to your kbd and running "loadkeys georgian14" and running "dnf update" again, font is ugly, but still, it's a correct Georgian font. success :)

Now, I got no idea how I managed to get my system do Latin input.

content of relevant (that I know about) files are:

[root@fedora etc]# cat locale.conf
LANG="ka_GE.UTF-8"
[root@fedora etc]# cat vconsole.conf
KEYMAP=us
FONT=latarcyrheb-sun16
XKBLAYOUT=us
XKBMODEL=pc105+inet
XKBOPTIONS=terminate:ctrl_alt_bksp

setfont * not loadkeys. Mea culpa.

I'm trying to test my changes now, but first I did an unmodified install to check the base state, and I can't actually reproduce your initial description. When I do a Fedora Rawhide install and pick Georgian as the language on the first screen, the console keymap actually gets configured as 'us-acentos' (this is due to a kinda corner case in how systemd parses kbd-model-map; it's a wrong behaviour, we should patch systemd for it). That layout is very similar to us, and can type Latin characters just fine (and can't type Georgian characters at all). So I'm confused how you got into a state where you were typing Georgian (we assume) characters on the console.

The LANG and LC_* env vars aren't relevant here, it should be only the /etc/vconsole.conf settings that matter. But *your* vconsole.conf says KEYMAP=us , so it should just be loading the 'us' console layout and your keyboard should act like a US keyboard. So...if it isn't, that's weird.

For attaching screenshots - do you see a "Show advanced fields" button or something up there somewhere? If you click that, it might show up.

I cannot "type" Georgian on my fc rawhide, but I can "see" (with correct font) Georgian and at last login to system (because of "us" layout I guess)

About attaching screenshots, I see no any :)
About keyboard acting as "us" keyboard, yes, it does. When booting into CLI mode, everything what user is caring about is *seeing* output in their language and *maybe* able to switch to another layout, but *not* entering in their language by default, since, well, it will prevent people from logging in. 

Oh my god, this is going deep =/ But anyways, I'm willing to finish it.

At the moment I'm talking about without my patches. In your original description you wrote "but after reboot, I can only type in Georgian (and see squares in place of symbols, because by some reason terminal fonts for Georgian are not installed. Even when I booted system up with systemd.debug-shell=1 and switched to terminal, I still cannot see Georgian symbols (no font) and thus cannot do 'loadkeys us' thing.", so that's what I was trying to reproduce, and I can't.

I can still test that my fixes make things better, I just wanted to try and figure out how you wound up in a state where you can't type Latin characters at the console, if that's what your initial report meant.

You're completely right. 
I got 2 systems, fc rawhide and fc41 with Georgian by default.
When I was talking about "not able to type", it was fc41 and when I mentioned "fc rawhide" I meant second VM, where I still can type in Latin and run commands.

Sorry for inconvenience

Hum, I'd expect the behaviour to be the same in f41, but maybe systemd changed its kbd-model-map parsing or something? I will test an F41 install too...

Booted into my fc41 instance with rocky9.1 image to rescue mode and did 'cat /etc/{locale.conf|vconsole.comf}'. Output:
locale.conf
LANG="C.UTF-8"

vconsole.conf
KEYMAP="ge"
FONT="latarcyrheb-sun16"

Huh. That's odd. I just did a fresh F41 install and go us-acentos again. Can you attach /var/log/anaconda/journal.log , if you have it? Thanks!

Should be here: https://drive.google.com/file/d/1j0dw0X2qGwt3hlFlVCgpawobjwYQukKX/view?usp=sharing

That looks like it's from a RHEL 9 install? I mostly deal with Fedora, I don't really know which version of the keyboard layout code we had in RHEL 9. I'd have to go back and refresh my memory. But I'd mostly focus on fixing this for future Fedoras, and maybe trying to get the fix into RHEL 10 too.

Omg, I can't believe I did this.
So, I did reinstall fc41 again in a vm and by some magic I got us-acentos too.
I really got no idea how and why it does it.
Squares are still there, but at least I can login and run commands.

https://drive.google.com/file/d/17qxTMF4hp5Jubxj_KOL04cZ81O06kQVW/view?usp=sharing

Here's anaconda's log file.

Well, how it works is that anaconda/langtable decide the desired xkb layout, then localed takes that and compares it against https://github.com/systemd/systemd/blob/main/src/locale/kbd-model-map to decide what console layout to use. it uses some pretty wacky heuristics for that (some of which I wrote). it works fine for our intended cases, but in trickier cases like this - where *nothing* is a very good match - it can come up with some odd results. in this case it's deciding the best match for map ge,us with model pc105 is us-acentos on line 39; I think probably what's going on is our model here is pc105 (not pc105+inet), so that line winds up being a 'better' match than the 'normal' us line, line 11. I could try and tweak the heuristics there or the model langtable tells anaconda to use or something, but it'd probably be nicer just to add a specific 'ge,us' line to kbd-model-map.

this is all crazy stuff - that file started life as part of an ancient RHL thing called system-config-keyboard, where it was used to populate a menu that let you *choose* one of those lines which would give you that entire config, then systemd/localed kinda stole it as a lookup table, it's all awful and I hate it. :P

anyway, if you run an install with https://adamwill.fedorapeople.org/04592750-127749703_127752836-netinst-x86_64.iso and pass inst.addrepo=https://adamwill.fedorapeople.org/georgrepo , you *should* get an install that "works right" - you should get a switchable georgian keyboard layout by default, and a console font that can show georgian characters. Use shift+ctrl to switch between Latin and Georgian input. It works for me.

About system-config-language - yep. I translated both system-config-language and anaconda to Georgian, along with all the CLI stuff.
I'll try to install system you provided and report back.
Meanwhile I tried to test this behavior on different RHEL based systems. Centos/Rocky/RHEL 8/9 does exactly this (squares, input default is Georgian/cannot type Latin symbols). Cannot make CentOS/RHEL 10 boot in virtualbox for now (kernel panic with random errors), but will get there eventually and report that too.

about crazy stuff - how to fix it? :)

P.S. I would take this as "It's not a bug, most probably it's me who messes things up, just go read more" thing, but I really want to get Georgian working before RHEL10 release :)

agh, got the arg wrong - it's inst.addrepo=georgrepo,https://adamwill.fedorapeople.org/georgrepo

there isn't really a way to 'fix' the craziness besides implementing xkb/ttf font support for consoles; everything else is going to involve weird translation layers and lookup tables *somewhere*. other distros do it other ways, but it's equally crazy everywhere in the end.

and no, I agree it was a good idea to file a bug! I think we can definitely aim to get this working better for F42 and Rawhide. I've filed https://github.com/legionus/kbd/issues/126 to discuss how we can get some kinda Georgian support into kbd upstream.

wow, what a journey in 7AM :)
ISO you provided and centos 10 both failed to boot on virtualbox VM, later complaining about missing CPU flags? CPU is from 2024.
then tried both on vmware workstation. this time both failed to boot wayland (on both vmware and virtualbox) but I managed to install fedora with your repo via RDP, installed it and .. 
worked as charm. no squares anymore and keyboard switching also works.
font is ugly (one of reasons I got big hatred towards debian based systems, tho. I do not like their terminal font).
What's the next step? :)

well, the github issue. I listed some ideas there, but will wait to hear from the maintainer. I don't think we want to carry this stuff as downstream patches, I did it more as a proof of concept.

I use libvirt mainly, but I have tested Fedora on current VirtualBox and VMWare on Windows and they mostly worked fine for me. Make sure you have the latest versions, and fiddling with the graphics card options can help if you run into problems.

(In reply to Adam Williamson from comment #9)
> sigh, got confused between fonts and layouts. so poking at this a bit more -
> console-setup has a whole thing for building combined PSF fonts out of BDF
> 'sources' on the fly, the Georgian-Fixed14.psf fonts Vitezslav found are the
> outputs from that, the bdf dir I found is the inputs. So we can either just
> copy or rebuild that PSF font to get console Georgian character display
> support. It also has a whole thing for building kbd layouts from xkb ones,
> by the looks of it, kinda like our on-the-fly conversions in the kbd package
> but more extensive; I'm looking into that now to see if it produces a usable
> console switched georgian layout, and if so, how to steal/reproduce it.

Adam, we do have console-setup package in Fedora and actually it's used
during the kbd build (as a BR) to do the xkb to console layout conversion
for kbd using 'ckbcomp' script.

'Georgian-Fixed14.psf' font is also part of that package and available to
be loaded by 'setfont'.

Thanks. Yeah, I'm aware we have the package, I didn't realize it was a BR for kbd though. I was assuming we don't want to make it a default runtime installed package as it seems like it kinda 'conflicts' with our 'standard' way of handling this stuff and installing it by default might have some surprising results in other ways. I've been working on the assumption that anything we want to be sure will be available as 'standard' on Fedora and handled by anaconda must be in kbd somehow or other.

I suppose since it's a BR we could just copy 'Georgian-Fixed14.psf' in wholesale at kbd build time, but that feels...odd?

Yeah, that feels a little odd. But on the other hand, we could copy all
console-setup fonts to kbd and make them more easily available to users -
to have them within a package where they would be expected and within
'setfont' search path ('/usr/share/consolefonts/' is not there).

Or split fonts from console-setup to separate subpackage, put them
to '/usr/lib/kbd/consolefonts' and make that default runtime installed
package (or require it by 'kbd-misc').

I'm not sure what is the best and cleanest solution here.

Are we ending up in a scenario when if system locale is ka_GE, system font will be set to georgian14? this font is VERY different from latarcyrheb, not in a good way.. better than nothing, but just saying.

Yeah, I mentioned that as a concern in the upstream bug. Ideally we might want to do a font based on latarcyrheb with maybe the Cyrillic characters swapped out for the Georgian ones from the console-fonts georgian BDF source, assuming we can clarify the licensing? But that requires knowing or figuring out how to actually do that. :D

Created attachment 2073765 [details]
Console font for Georgian

Hello,
Just got reply from Gia Shervashidze with terminal font which is attached here.

Quoting text he sent:

Well, here is the font created possible helps.

Created full set of contemporary Georgian Unicode (block 10D0-10FF)
https://www.unicode.org/charts/PDF/U10A0.pdf (block 10D0-10FF)

As a base font used LatArCyrHeb-14.psfu 512-char font (Georgian letters replaces/overwrites Arabic ones).
https://adeverteuil.github.io/linux-console-fonts-screenshots//screenshots/LatArCyrHeb-14.psfu.png (Georgian occupies last 3 columns)
In the font Georgian characters range is 464-511.

Possible issues: Unicode values assigned manualy via HEX Editor (hope, it works).
FileName: up to You (any appropriate for U) 
License: up to You (any appropriate for U) 
Keyboard Driver: up to You (i'm not Linux guy)
Keyboard Layout: seems something like this https://en.wikibooks.org/wiki/Georgian/Georgian_on_your_computer (NorweyFun can manage it in best way)

Note: for desktop You can use free Unicode font with my Georgian contribution also.
https://github.com/opensourcedesign/fonts/tree/master/gnu-freefont_freesans


end of quote.

Yes, I know font attached is 16 and screenshot is for 14. He made it 14 first and then I asked him to make 16 sized version too.
I gzipped font, copied it to /lib/kbd/consolefonts, did setfont and it works!

What's next? :)


BR, Temuri

Thanks a lot, that's awesome! It would help to have clarity about the license, though. "License: up to You (any appropriate for U)" is I think not clear legally. :D Let me put it this way. The font is based on LatArCyrHeb, which is part of kbd, and kbd is under GPL 2 or later. So this font should probably be under the same license. Here's a draft license statement for the font:

"LatCyrHebKa is licensed under the GNU General Public License (GPL), version 2, or at your option any later version."

Can you ask if he accepts this draft and releases the font under the GPL? Thanks! I think that should be sufficient (though I'm not a lawyer).

Just in case there's a concern - this doesn't stop him releasing it any other way he chooses as well. He is still the copyright holder. He could also choose to make it available under another license if he wanted.

Font is basedon latarcyrheb-sun16, I wanted it to look like as much as default RHEL font as it could.

Sure, we can use draft statement by you, no problem at all:)

Awesome, thanks, that's great. I will work up upstream and downstream PRs tomorrow to include it in kbd.

Created attachment 2073961 [details]
Keyboard mapping

Excellent! Thank you!
I also went ahead and tweaked ru.map from kbd to be Georgian one. Hope I didn't mess up with codes, was triple-checking each of them.

And there was something to do with systemd checkups if I recon it correctly. (in Georgian we got no symbol for capital A)

I already did a keyboard mapping, it was in those test packages from a while ago. Was there anything wrong with it?

Oh, OK then. no, nothing, it's all ok. I just didn't check typing part, only paid attention to font.

OK, so I compared yours and mine and they're pretty much functionally identical except for one apparent error in yours - it maps U+10ED twice (on keycode 17 and 36) and does not map U+10DF at all. Mine (based on the console-setup one) has U+10DF as altgr+shift on keycode 36. Probably should be the same on yours?

I guess I'll edit yours with that change and include it in the PR, since you did the work to hand-make it.

Upstream PRs:

* https://github.com/legionus/kbd/pull/127 kbd
* https://github.com/systemd/systemd/pull/36194 systemd
* https://github.com/mike-fabian/langtable/pull/24 langtable

ops.
altgr   shift           keycode  36 = U+10ED        # Georgian zh (J)

this should be 10DF

everything else seems to be correct :)

and again, thank you!

Package PRs:

* https://src.fedoraproject.org/rpms/kbd/pull-request/3 kbd
* https://src.fedoraproject.org/rpms/langtable/pull-request/8 langtable
* https://src.fedoraproject.org/rpms/systemd/pull-request/183 systemd

I did a test image build and install with those, and it works great: after a Georgian install, the correct font and layout are configured at the console, I can type Georgian characters, and the font definitely looks much better than georgian16. Thanks a lot for all the help with this! Let's hope we can get it all in for F42.

(In reply to Adam Williamson from comment #47)

Thank you, I merged Adam’s pull requests 

https://github.com/mike-fabian/langtable/pull/24 
and:
https://src.fedoraproject.org/rpms/langtable/pull-request/8

Hello,

Yesterday got updates for my fc rawhide. all langtable, kbd, systemd packages are with Georgian support now.
Also changed to new font in /etc/vconsole.conf and everything works as it should.

Thank you very much!

Just one question, please. When I boot up in CLI, login with latin layout and do "loadkeys ge" to be able to type in Georgian.
How do I switch back if I cannot type 'loadkeys us' anymore? shift+ctrl (which by itself was weird, I always used Ctrl+Shift in older windows systems) doesn't work anymore. I guess it has something to do with systemd? or is there any other way, please?

Temuri

It should work...I tested it and it worked. Did you definitely get the new kbd-legacy package, version 2.7.1-3 ? That contains your 'ge' map, which has switching implemented.

[root@fedora ~]# rpm -q kbd-legacy
kbd-legacy-2.7.1-3.fc42.noarch
[root@fedora ~]# cat /etc/vconsole.conf
KEYMAP=us
FONT=LatCyrHebKa-16_GIA
XKBLAYOUT=us
XKBMODEL=pc105
XKBOPTIONS=terminate:ctrl_alt_bksp
[root@fedora ~]# cat /etc/locale.conf
LANG="ka_GE.UTF-8"

Just adding more details to make it easier to debug this situation
I got 2 fedora systems in a VMs.
1) fedora rawhide in a virtualbox VM, with packages and configuration mentioned in a post upper. I'm using this VM whenever I need to do testing, do some manual work I need while translating software, etc etc etc. on this VM, when I login via console, does not let me to switch layouts

2) fresh fedora rawhide in a vmware workstation VM, with inst.addrepo=https://adamwill.fedorapeople.org/georgrepo . When I try to switch keyboard layout with Shift+Ctrl, it works and I can see Georgain symbols.
configs/versions on this machine are:

[root@localhost ~]# cat /etc/vconsole.conf
KEYMAP="ge"
FONT="georgian16"
[root@localhost ~]# cat /etc/locale.conf
LANG="ka_GE.UTF-8"
[root@localhost ~]# rpm -q kbd-legacy
kbd-legacy-2.7.1-1.1awb.fc42.noarch
[root@localhost ~]# rpm -q systemd
systemd-257.2-5.fc42.x86_64


When i copy content of vconsole.conf from VM2 to VM1, it does not work anyways, so I think it has to do something with something else.

Now I did another experiment, installed ISO you sent with inst.addrepo (it makes no sense anymore I guess, since packages in mainstream repo are newer than ones in your repo) on virtualbox. Wayland requirement is killing me, had to install it via rdp again..

results:
config files:
[root@localhost ~]# cat /etc/vconsole.conf
KEYMAP="ge"
FONT="georgian16"
[root@localhost ~]# cat /etc/locale.conf
LANG="ka_GE.UTF-8"

In console I cannot see Georgian symbols for some reason, but layout switching works. (there should be something very wrong with my another FC VM)
Also, for some weird reason vconsole service fails to start.

After replacing font in vconsole.conf to LatCyrHebKa-16_GIA everything works as expected ( I can see Georgian symbols, can switch layout in CLI and vconsole service starts/stops OK)

OK, so a couple of things: no need to use custom ISO or inst.addrepo any more, and it will actually cause problems (as it did in your "another experiment" - it's configuring the wrong font). Just use a Rawhide ISO from the last couple of days, no addrepo arg. This should configure the keyboard map as 'ge' and the font as 'LatCyrHebKa-16_GIA'.

The no-keyboard-switch-in-virtualbox issue sounds like a virtualbox issue, honestly. Check its options about inhibiting and passing through keypresses. It might be not passing either the shift or the ctrl (or the combination of the two...) through to the machine.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

I've just updated kbd to version 2.8.0 in Rawhide. Both keymap and font were present in upstream tarball. Please check that everything looks and works as expected.