On Wed, Dec 5, 2018 at 7:42 PM Randy Dunlap wrote:
>
>converted
>
> Where does "ter-i32b.psf" come from?
> I.e., where can I find it?
The Unix/Linux Terminus sources are available for download
at SourceForge. Simply running "make" in source directory
will build the .psf font files
On 12/5/18 3:56 PM, Amanoel Dawod wrote:
> This patch adds an option to compile-in a high resolution
> and large Terminus (ter16x32) bitmap console font for use with
> HiDPI and Retina screens.
>
> The font was convereted from standard Terminus ter-i32b.psf
conver
This patch adds an option to compile-in a high resolution
and large Terminus (ter16x32) bitmap console font for use with
HiDPI and Retina screens.
The font was convereted from standard Terminus ter-i32b.psf
(size 16x32) with the help of psftools and minor hand editing
deleting useless characters
On Mon, Nov 26, 2018 at 04:21:15AM -0500, Amanoel Dawod wrote:
> This patch adds an option to compile-in a high resolution and large
> Terminus (ter16x32) bitmap console font for use with HiDPI and Retina screens.
>
> The font was convereted from standard Terminus ter-i32b.psf (size 1
Hi.
On Sun, 2018-11-25 at 22:47 -0500, nimrud wrote:
> This patch adds an option to compile-in a high resolution and large
> Terminus (ter16x32) bitmap console font for use with HiDPI and Retina screens.
>
> The font was convereted from standard Terminus ter-i32b.psf (size 16x32)
>
This patch adds an option to compile-in a high resolution and large
Terminus (ter16x32) bitmap console font for use with HiDPI and Retina screens.
The font was convereted from standard Terminus ter-i32b.psf (size 16x32)
with the help of psftools and minor hand editing deleting useless characters
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Nov 26, 2018 at 03
On Sun, Nov 25, 2018 at 10:47:34PM -0500, nimrud wrote:
> This patch adds an option to compile-in a high resolution and large
> Terminus (ter16x32) bitmap console font for use with HiDPI and Retina screens.
>
> The font was convereted from standard Terminus ter-i32b.psf (size 16x32
On Sun, Nov 25, 2018 at 10:47:34PM -0500, nimrud wrote:
> This patch adds an option to compile-in a high resolution and large
> Terminus (ter16x32) bitmap console font for use with HiDPI and Retina screens.
>
> The font was convereted from standard Terminus ter-i32b.psf (size 16x32
This patch adds an option to compile-in a high resolution and large
Terminus (ter16x32) bitmap console font for use with HiDPI and Retina screens.
The font was convereted from standard Terminus ter-i32b.psf (size 16x32)
with the help of psftools and minor hand editing deleting useless characters
you have appropriate font size for 1920x1080,
no need to lower resolution via "video=x".
Perhaps '32' is too large, so choose <= '28', e.g. ter-v28b or ter-v24b.
/usr/share/doc/terminus-fonts-console/README[.fedora]
poma
[1] systemd-vconsole-setup: /
On Wed 15 May 2013 13:40:50 Geert Uytterhoeven wrote:
> The current Makefile rules to build font support are messy and buggy.
> Replace them by Kconfig rules:
> - Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
> code,
> - Select CONFIG_FONT_SUPPORT for all drivers th
The current Makefile rules to build font support are messy and buggy.
Replace them by Kconfig rules:
- Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
code,
- Select CONFIG_FONT_SUPPORT for all drivers that use fonts,
- Select CONFIG_FONT_8x16 for all drivers that d
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when
3.5.7.7 -stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when
From: Dave Airlie
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.
The thing is the generic code is doing the right
Hi, since 3.6-rc7 I'm *sometimes* seeing console font corruption on
tty1 after I leave xorg [ I'm old enough to use 'startx' ]. This is
with a 512-glyph font. What seems to be happening is that many
lower-case ASCII letters, and also '0', are replaced by other
glyph
On Friday 04 May 2007 11:34:40 Jesse Barnes wrote:
> On Thursday, May 03, 2007, Antonino A. Daplas wrote:
> > On Thu, 2007-05-03 at 23:58 -0400, Daniel Hazelton wrote:
> > > On Thursday 03 May 2007 20:39:05 H. Peter Anvin wrote:
> > > > Kyle Moffett wrote:
> > >
> > > I guess I could start on that
On Thursday, May 03, 2007, Antonino A. Daplas wrote:
> On Thu, 2007-05-03 at 23:58 -0400, Daniel Hazelton wrote:
> > On Thursday 03 May 2007 20:39:05 H. Peter Anvin wrote:
> > > Kyle Moffett wrote:
> >
> > I guess I could start on that work again - shouldn't take me all that
> > long to recover the
On Thu, 2007-05-03 at 23:58 -0400, Daniel Hazelton wrote:
> On Thursday 03 May 2007 20:39:05 H. Peter Anvin wrote:
> > Kyle Moffett wrote:
> I guess I could start on that work again - shouldn't take me all that long to
> recover the stuff I lost when a blackout caused my hard drive to get
> corr
On Thursday 03 May 2007 20:39:05 H. Peter Anvin wrote:
> Kyle Moffett wrote:
> > Actually I think the real problem was that "KD_GRAPHICS" got overloaded
> > to mean "some userspace program is probably poking at the GPU in very
> > direct ways possibly including /dev/mem". As such it really isn't s
Kyle Moffett wrote:
>
> Actually I think the real problem was that "KD_GRAPHICS" got overloaded
> to mean "some userspace program is probably poking at the GPU in very
> direct ways possibly including /dev/mem". As such it really isn't safe
> at all for the kernel to write stuff to the screen in
On May 03, 2007, at 16:16:51, Jan Engelhardt wrote:
On May 3 2007 13:15, H. Peter Anvin wrote:
Jan Engelhardt wrote:
Put people didn't like that, and disabled text output when the
console is in KD_GRAPHICS mode...
at the cost of not getting the kernel oops, heh.
I thought the reason we d
On May 3 2007 13:15, H. Peter Anvin wrote:
>Jan Engelhardt wrote:
>>
>>> Put people didn't like that, and disabled text output when the console
>>> is in KD_GRAPHICS mode...
>>
>> at the cost of not getting the kernel oops, heh.
>
>I thought the reason we didn't display text in KD_GRAPHICS mode
Jan Engelhardt wrote:
>
>> Put people didn't like that, and disabled text output when the console
>> is in KD_GRAPHICS mode...
>
> at the cost of not getting the kernel oops, heh.
>
I thought the reason we didn't display text in KD_GRAPHICS mode was that
KD_GRAPHICS might mean "in a completely
On May 3 2007 17:56, Geert Uytterhoeven wrote:
>>
>> Actually, the kernel could just "jump in". That is, when you start
>> in fb mode, you get the regular 8x16 vga font - on your choice of
>> resolution, and can also set it with setfont. So far so nice.
>> Now, when you start fbiterm -- for examp
On Tue, May 01, 2007 at 12:09:46AM -0400, Albert Cahalan wrote:
> I'm having problems with a font I just created. It's a rather big one,
> intended for a framebuffer console in UTF-8 mode. The strace program
> reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
> In reading the kernel
On Thu, 3 May 2007, Jan Engelhardt wrote:
> On May 3 2007 10:14, Albert Cahalan wrote:
> > On 5/3/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> On May 3 2007 02:17, Albert Cahalan wrote:
> >
> >> > Those sizes are unreadable on the 200 dpi OLPC XO screen,
On May 3 2007 10:14, Albert Cahalan wrote:
> On 5/3/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> On May 3 2007 02:17, Albert Cahalan wrote:
>
>> > Those sizes are unreadable on the 200 dpi OLPC XO screen,
>>
>> Hm that should have read, for you:
>> I don't object implementing support for larg
On 5/3/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On May 3 2007 02:17, Albert Cahalan wrote:
> Those sizes are unreadable on the 200 dpi OLPC XO screen,
Hm that should have read, for you:
I don't object implementing support for larger sizes.
(But I wonder how that should work without FB/CV
On Thu, 03 May 2007 00:19:59 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Albert Cahalan wrote:
> > Font size is not a sane place to draw the line. Features are.
>
> Font sizes are an eminently sane place to draw the line, because the
> crossover is largely determined by the point at which
H. Peter Anvin wrote:
Albert Cahalan wrote:
Font size is not a sane place to draw the line. Features are.
Font sizes are an eminently sane place to draw the line, because the
crossover is largely determined by the point at which nailing down too
much memory (kernel memory = unswappable
Albert Cahalan wrote:
> Font size is not a sane place to draw the line. Features are.
Font sizes are an eminently sane place to draw the line, because the
crossover is largely determined by the point at which nailing down too
much memory (kernel memory = unswappable memory) gets too expensive.
On May 3 2007 02:17, Albert Cahalan wrote:
> Note: I never suggested going beyond #3.
>
>> 0. yes we want that
>>
>> 1. can't tell
>>
>> 2. utf8 yes, many text files are in that encoding.
>> large fonts - can't tell, I am fine with the regular vga
>> font infrastructure (8x16, 8x8)
>
> Those siz
On 5/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On May 1 2007 11:49, Albert Cahalan wrote:
>>
>> Well, I think the consensus is that anything beyond that should be done
>> in userspace; the main such console daemon was Kon2 last I checked.
>
> Font size is not a sane place to draw the line.
On May 1 2007 11:49, Albert Cahalan wrote:
>>
>> Well, I think the consensus is that anything beyond that should be done
>> in userspace; the main such console daemon was Kon2 last I checked.
>
> Font size is not a sane place to draw the line. Features are.
> The levels of support go something lik
king at that an hour before I read your mails) _if_ the font
has room to fit in a "private use" character which can hold the
precomposed value.
For any letter where a precomposed version is in the unicode
standards, the only use for combining characters in a console font
seems to be as
On 5/1/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Antonino A. Daplas wrote:
>
> And this will entail a lot of work to change (Is it worth it to rework
> the code and remove the limitation?). The linux-console project
> (http://linuxconsole.sourceforge.net/) might have , but I don't know its
>
Antonino A. Daplas wrote:
>
> And this will entail a lot of work to change (Is it worth it to rework
> the code and remove the limitation?). The linux-console project
> (http://linuxconsole.sourceforge.net/) might have , but I don't know its
> current status.
>
Well, I think the consensus is tha
On Tue, 2007-05-01 at 13:49 +0200, Geert Uytterhoeven wrote:
> On Tue, 1 May 2007, Albert Cahalan wrote:
> > I'm having problems with a font I just created. It's a rather big one,
> > intended for a framebuffer console in UTF-8 mode. The strace program
> > reports that /bin/setfont fails on a KDFON
On Tue, 1 May 2007, Albert Cahalan wrote:
> I'm having problems with a font I just created. It's a rather big one,
> intended for a framebuffer console in UTF-8 mode. The strace program
> reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
> In reading the kernel code, I find this:
>
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc, st
45 matches
Mail list logo
