Bug 892340

Hmm, so it appears that the font settings are lost when the graphics drivers are loaded. Not sure what we can do about that since graphics drivers are loaded fully asynchronously, i.e. we never wait for that really.

Not sure what we can do about that. The kernel should probably be fixed not to lose the font settings.

Incidentally, when I exited plymouth with escape key, the font size was applied properly.

(In reply to comment #2)
> Incidentally, when I exited plymouth with escape key, the font size was
> applied properly.

Hmm, hmm? so if you exit ply early during boot it works, but if you leave it running it doesn't?

A couple of more questions:

do you use an initrd?

do you use plymouth?

do you have an special bits in the early boot process?

what happens if you drop ply or the initrd from the boot process?

Yes, I do use (In reply to comment #3)
> (In reply to comment #2)
> > Incidentally, when I exited plymouth with escape key, the font size was
> > applied properly.
> 
> Hmm, hmm? so if you exit ply early during boot it works, but if you leave it
> running it doesn't?

Yes, exactly.

I use both initrd and plymouth. How do I drop one or the other from the boot process?

*** Bug 876512 has been marked as a duplicate of this bug. ***

It works all fine here. It could be a kernel issue, that changing the framebuffer driver removes the uploaded font.

What's the output of the following commands? Please just paste it directly inline here if possible:

1. $ cat /proc/cmdline

2. $ cat /proc/fb

3. $ grep . /sys/class/vtconsole/*/{name,bind}

4. $ dmesg | grep -Ew 'fb[0-9]|fb'

#876512 reproduces for me at two machines with nouveau and intel drivers.
First one:

1.

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.6.11-3.fc18.x86_64 root=UUID=0eec14ac-304b-4aa0-befb-f07555432c88 libahci.ignore_sss=1 raid=noautodetect ro rd.info rd.md=0 rd.luks=0 rd.lvm=0 rd.dm=0 plymouth.enable=0 LANG=uk_UA.UTF-8 KEYTABLE=ua-utf SYSFONT=ter-v16n drm.debug=0x04

2.

$ cat /proc/fb
0 nouveaufb

3.

$ grep . /sys/class/vtconsole/*/{name,bind}
/sys/class/vtconsole/vtcon0/name:(S) dummy device
/sys/class/vtconsole/vtcon1/name:(M) frame buffer device
/sys/class/vtconsole/vtcon0/bind:0
/sys/class/vtconsole/vtcon1/bind:1

4.

$  dmesg | grep -Ew 'fb[0-9]|fb'
[    0.686678] fb0: VESA VGA frame buffer device
[   13.900667] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing generic driver
[   14.218397] [drm] nouveau 0000:01:00.0: allocated 1280x1024 fb: 0x49000, bo ffff8800373d4800
[   14.218595] fbcon: nouveaufb (fb0) is primary device
[   14.218671] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[   14.282119] fb0: nouveaufb frame buffer device

It looks like a kernel driver issue. I can produce the same issue here with an Intel driver. A blacklisted i915 in runlevel 2 will have the font applied just fine. A modprobe i915 will change the resolution and the font is lost.

The uploaded font should survive a framebuffer driver change, but it is lost when the kms driver takes over the screen from vesa.

Hmm, OK,  I have added Dave Airlie to CC now. Dave, any idea about this? any chance the fb drivers can be fixed not to drop the fonts when switching drivers?

hmm I've little idea how fbcon works at that level, but it should all be happening above the fb drivers level. Maybe when we drop the first console it loses the font, and we create the second it doesn't have it anymore. Since we never overlap their existance.

(In reply to comment #11)
> hmm I've little idea how fbcon works at that level, but it should all be
> happening above the fb drivers level. Maybe when we drop the first console
> it loses the font, and we create the second it doesn't have it anymore.
> Since we never overlap their existance.

Hmm, anybody who feels responsible for this bit of the kernel? ;-)

Since this appears to be something to fix in the kernel, will reassign to kernel.

(In reply to comment #11)
> Maybe when we drop the first console it loses the font, and we create
> the second it doesn't have it anymore. Since we never overlap their existance.

hmm, the font should hang at the vc structure, which should stay around. Changing the driver should re-use the font, exactly in the same way the
screen content is re-used when the vcs get re-bound to the new driver.

Actually it works all fine within qemu and the cirrus fb driver, the earlier
loaded font is perfectly applied after a "modprobe cirrus". Maybe it's driver
specific, or depends on some specifics of the earlier fb driver.

Just in case, info for intel machine.
Video:

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)

CPU: Core i5-2540M

1.

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.6.11-1.fc17.x86_64 root=UUID=bd9b55f7-43f7-489d-86d8-8c0520323c79 ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=ter-v16n KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 plymouth.enable=0

2.

$ cat /proc/fb
0 inteldrmfb

3.

$ grep . /sys/class/vtconsole/*/{name,bind}
/sys/class/vtconsole/vtcon0/name:(S) dummy device
/sys/class/vtconsole/vtcon1/name:(M) frame buffer device
/sys/class/vtconsole/vtcon0/bind:0
/sys/class/vtconsole/vtcon1/bind:1

4.

$ grep -Ew 'fb[0-9]|fb' /tmp/messages
[    0.936754] fb0: VESA VGA frame buffer device
[   21.007130] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[   21.655793] fbcon: inteldrmfb (fb0) is primary device
[   22.052147] fb0: inteldrmfb frame buffer device

Dave, Kay, I remember something being sent upstream for this, but I can't find it at the moment.  Did this get fixed upstream, and is that in 3.8.x?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae1287865f5361fa138d4d3b1b6277908b54eac9

(In reply to comment #16)
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=ae1287865f5361fa138d4d3b1b6277908b54eac9

Right!  Ok, that was pulled into 3.8.1, so this is fixed.

Thanks for the pointer Kay.

Created attachment 731865 [details]
Font problem screenshot

I still have problem with it, however is seems a bit different. FB screenshot attached, initial state is the default for me.
Wrong chars can be seen in "grep --help" and command prompt.

Can be fixed for runtime with systemd-vconsole-setup restart or "setfont -f ter-v16n".

Reproduces at two quite different machines (intel and nouveau video drivers).

Sorry, forgot to mention: kernel 3.8.5-201.fc18.x86_64, HW info is present above.

Besides that, sometimes I catch other funny issues while playing with setfont. For example, one machine hung while executing it with no reaction even for the magic keys. Another one just lost the "g" and "j" chars in Firefox and Thunderbird (however I'm not sure it's related here).

Saw it good by default couple of times in a row with 3.8.9-200.fc18.x86_64.
Then I've checked if it's broken for 3.8.8-202.fc18.x86_64 (it is) and after that 3.8.9 came back to the broken state too.

I am having this problem with kernel-3.13.6-200.fc20.x86_64 + AMD 880G on F20.

(In reply to Marcos Mello from comment #21)

Current issue is closed, I cloned it for newer Fedora versions: https://bugzilla.redhat.com/show_bug.cgi?id=972635