drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
In monochrome mode the lowest 2 bits of the attribute are used for the
intensity. If a 512 glyph font is loaded the lowest attribute bit is
used for the MSB.
The result is that with normal intensity (1) the MSB of the glyph can
be set.
Due to this on my setup the erase character becomes 0x120 instead of
0x20. As 0x120 is allocated to U+0161 in the loaded font the erased area
will be filled with "s" instead of spaces.
To make the 512 glyph case work in monochrome mode the intensity was cut
down to one bit (bold only) in this patch.
Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org>
---
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 62049ceb3..8eebb5f17 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -667,7 +667,7 @@ static u8 build_attr(struct vc_data *vc, u8 _color,
{
u8 a = _color;
if (!vc->vc_can_do_color)
- return _intensity |
+ return (_intensity & ~(vc->vc_hi_font_mask ? 1 : 0)) |
(_italic << 1) |
(_underline << 2) |
(_reverse << 3) |
--
2.30.2
On Thu, Aug 21, 2025 at 05:55:33AM +0200, Zsolt Kajtar wrote: > In monochrome mode the lowest 2 bits of the attribute are used for the > intensity. If a 512 glyph font is loaded the lowest attribute bit is > used for the MSB. > > The result is that with normal intensity (1) the MSB of the glyph can > be set. > > Due to this on my setup the erase character becomes 0x120 instead of > 0x20. As 0x120 is allocated to U+0161 in the loaded font the erased area > will be filled with "s" instead of spaces. > > To make the 512 glyph case work in monochrome mode the intensity was cut > down to one bit (bold only) in this patch. > > Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org> > --- > drivers/tty/vt/vt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 62049ceb3..8eebb5f17 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -667,7 +667,7 @@ static u8 build_attr(struct vc_data *vc, u8 _color, > { > u8 a = _color; > if (!vc->vc_can_do_color) > - return _intensity | > + return (_intensity & ~(vc->vc_hi_font_mask ? 1 : 0)) | For some reason you didn't cc: all of the maintainers and the subsystem mailing list for this code :( Anyway, this is anything but obvious as to what is happening, can this somehow be documented in the change to make it more clear? thanks, greg k-h
> For some reason you didn't cc: all of the maintainers and the subsystem > mailing list for this code :( Sorry, will do next time. Checked the linux-serial archive and now I see that it's also related to VT. > Anyway, this is anything but obvious as to what is happening, can this > somehow be documented in the change to make it more clear? Thanks! Meanwhile I've thought about the problem and this patch was not the right approach. Lets just forget about it. Instead the 512 glyph handling in fbcon needs to be done differently. As far as I see there are already fbcon specific hacks in the vt code related to this and it'd be better to remove them instead of adding a few more. -- -soci-
© 2016 - 2025 Red Hat, Inc.