Bug 892340 - font settings are lost when kernel fb drivers are changed
Summary: font settings are lost when kernel fb drivers are changed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 876512 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-06 19:12 UTC by Julian Sikorski
Modified: 2014-03-12 11:32 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 972635 (view as bug list)
Environment:
Last Closed: 2013-04-03 16:09:38 UTC
Type: Bug


Attachments (Terms of Use)
Font problem screenshot (20.56 KB, image/png)
2013-04-05 09:48 UTC, Andrew Travneff
no flags Details

Description Julian Sikorski 2013-01-06 19:12:24 UTC
Description of problem:
Even though I have 
FONT=latarcyrheb-sun32
KEYMAP=pl2
set in /etc/vconsole.conf, it has no effect unless I run
# systemctl restart systemd-vconsole-setup.service manually. Some digging got me here:
http://archlinux.2023198.n4.nabble.com/systemd-fails-to-set-console-font-tp4657110p4657130.html

Version-Release number of selected component (if applicable):
systemd-195-13.fc18.x86_64

How reproducible:
always

Steps to Reproduce:
1. change the font in /etc/vconsole.conf to latarcyrheb-sun32
2. reboot
  
Actual results:
font is still tiny

Expected results:
font is twice the size

Comment 1 Lennart Poettering 2013-01-13 21:30:39 UTC
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.

Comment 2 Julian Sikorski 2013-01-13 21:32:09 UTC
Incidentally, when I exited plymouth with escape key, the font size was applied properly.

Comment 3 Lennart Poettering 2013-01-14 17:48:49 UTC
(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?

Comment 4 Lennart Poettering 2013-01-14 17:50:16 UTC
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?

Comment 5 Julian Sikorski 2013-01-14 18:00:15 UTC
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?

Comment 6 Lennart Poettering 2013-01-14 22:23:19 UTC
*** Bug 876512 has been marked as a duplicate of this bug. ***

Comment 7 Kay Sievers 2013-01-15 19:53:07 UTC
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'

Comment 8 Andrew Travneff 2013-01-15 20:05:34 UTC
#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

Comment 9 Kay Sievers 2013-01-15 20:40:03 UTC
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.

Comment 10 Lennart Poettering 2013-01-15 22:00:20 UTC
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?

Comment 11 Dave Airlie 2013-01-15 23:18:37 UTC
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.

Comment 12 Lennart Poettering 2013-01-15 23:44:58 UTC
(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.

Comment 13 Kay Sievers 2013-01-16 01:27:41 UTC
(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.

Comment 14 Andrew Travneff 2013-01-16 10:51:59 UTC
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

Comment 15 Josh Boyer 2013-04-01 20:34:12 UTC
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?

Comment 17 Josh Boyer 2013-04-03 16:09:38 UTC
(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.

Comment 18 Andrew Travneff 2013-04-05 09:48:47 UTC
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).

Comment 19 Andrew Travneff 2013-04-05 09:56:56 UTC
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).

Comment 20 Andrew Travneff 2013-05-01 07:26:39 UTC
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.

Comment 21 Marcos Mello 2014-03-11 18:49:52 UTC
I am having this problem with kernel-3.13.6-200.fc20.x86_64 + AMD 880G on F20.

Comment 22 Andrew Travneff 2014-03-12 11:32:55 UTC
(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


Note You need to log in before you can comment on or make changes to this bug.