From: Adam Borowski <kilobyte@angband.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
linux-console@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements
Date: Mon, 23 Jul 2018 12:41:51 +0200 [thread overview]
Message-ID: <20180723104151.z3lasjmdd3ubh2sc@angband.pl> (raw)
In-Reply-To: <CAMuHMdWvZnU_p-c98sag8t1BCaBLSqZmiH88sgD2kACbvax0pA@mail.gmail.com>
On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski <kilobyte@angband.pl> wrote:
> > Technically, every console can be made to blink by drawing/clearing affected
> > characters a few times per second, but that'd be quite a waste of coding
> > time and kernel size. There's a reason browsers dropped support for <blink>
> > and text-decoration:blink.
>
> It's very simple and fast to implement in fbcon for FB_TYPE_PLANES or
> FB_TYPE_INTERLEAVED_PLANES and FB_VISUAL_PSEUDOCOLOR ;-)
Interesting... I'm still not going to do the effort to implement that
(which would require learning fbdev internals first), though. But while I
dislike this feature, someone else might want it.
The main problem here is that there are only 8 or 7 bits available for
attributes, thus it's better to use them for something more useful. And
here, fbcon already interprets this bit as bright background, thus this
patchset makes vt use it instead of non-existant blink.
There'll be more bits available once attributes get migrated into uniscr --
either 11 or 32 bits depending on chosen implementation. But I still
wouldn't go too wild with them: the console is meant for recovery tasks as
on any properly working system you can have an X terminal configured for
pixel-to-pixel identical behaviour as anything console can do. Thus, only
cheap improvements to attributes make sense. This patchset is currently at
+3 net lines, this certainly counts as cheap.
On the other hand, displaying the _glyph_ better would be worth some effort.
Nicolas' uniscr that's already in Greg's tree did most of the work, what
remains is a way to load and store a font with more glyphs (needs a sparse
representation).
Meow!
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
next prev parent reply other threads:[~2018-07-23 10:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 3:01 [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements Adam Borowski
2018-07-18 3:03 ` [PATCH 1/6] vt: drop unused struct vt_struct Adam Borowski
2018-07-18 3:03 ` [PATCH 2/6] vt: add console flag "unblinking" Adam Borowski
2018-07-18 3:03 ` [PATCH 3/6] vt: let \e[100m use bright background if unblinking Adam Borowski
2018-07-18 3:03 ` [PATCH 4/6] vt: change 256-color palette to match all(?) modern terminals Adam Borowski
2018-07-18 3:03 ` [PATCH 5/6] vt: compensate for brightening the 256-color palette Adam Borowski
2018-07-18 3:03 ` [PATCH 6/6] vt: support bright backgrounds for \e[48m if unblinking Adam Borowski
2018-07-19 10:47 ` [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements Alan Cox
2018-07-19 14:28 ` Adam Borowski
2018-07-19 14:34 ` Geert Uytterhoeven
2018-07-21 7:43 ` Greg Kroah-Hartman
2018-07-21 21:38 ` Adam Borowski
2018-07-23 8:53 ` Geert Uytterhoeven
2018-07-23 10:41 ` Adam Borowski [this message]
2018-07-23 11:07 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180723104151.z3lasjmdd3ubh2sc@angband.pl \
--to=kilobyte@angband.pl \
--cc=b.zolnierkie@samsung.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-console@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).