From: Adam Borowski <kilobyte@angband.pl>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
linux-console@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements
Date: Thu, 19 Jul 2018 16:28:44 +0200 [thread overview]
Message-ID: <20180719142844.u3u4p7tywb54y4yd@angband.pl> (raw)
In-Reply-To: <20180719114749.00a7f979@alans-desktop>
On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
> On Wed, 18 Jul 2018 05:01:52 +0200
> Adam Borowski <kilobyte@angband.pl> wrote:
>
> > Hi!
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> > allows disabling it, rendering such characters with a bright background
> > instead.
>
> That's a matter of taste so needs to configurable. Changing the default
> ought I think to be its own patch as it's a separate discussion to having
> the choice there and easy to make.
For vgacon yeah, you have a good point, as it can support either (and to be
exact, exactly one of the two as they share a hardware bit). Only reason to
not have this configurable would be avoiding bloating the kernel with knobs
hardly anyone flips -- but you can already set minutiae like replacement
color for underline/italic/dim. Thus you're right that if/when killing
blink on vgacon is implemented, it probably should be settable.
This is not an option on fbcon, though -- it can't blink (doable but I'm not
seeing anyone wanting to implement that) and already interprets that
attribute bit the way VGA would. Thus, this patch merely makes vt behave a
way to match what the driver does. This fixes some visual corruption in
certain user programs.
> For the palette why does it needs changing and exactly what standards
> document defines 'right', especially given we don't do ICC in console
> mode ? Have you tested the values used against multiple monitor types and
> cards with a light meter ?
You don't need a light meter for a difference of 53-out-of-256. Most
desktop environments don't do ICC out of the box either, but there's an
assumption that whatever your monitor does, it gives the same result for the
same input (in the same lighting conditions).
That patch's purpose is:
* behave consistently between two APIs to set the same thing (\e[38;5;m vs
\e[38;2;m) in a way that matches other terminals
* in case a future driver has better color handling we'd be different from
other terminals
By the way, you can have ICC on console: "apt install vtgamma"
(https://github.com/kilobyte/vtgamma).
> BTW visibly breaking the Nvidia crud is also fine. They'll then actually
> bother to fix it and uually quite soon.
Yeah, but they haven't fixed 512-glyph yet (at least the last time I
looked), broken since day one. In any case, this patchset doesn't support
vgacon yet, thus this is moot for now. I picked the easy case (fbcon which
is always unblinking) over writing stuff to ports, we can update other
drivers later.
And vgacon has code that looks like it can do CGA and MDA (redundant with
mdacon?), either of which I haven't used in... quite a while. Might be
tricky getting access to such hardware to test...
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-19 14:28 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 [this message]
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
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=20180719142844.u3u4p7tywb54y4yd@angband.pl \
--to=kilobyte@angband.pl \
--cc=b.zolnierkie@samsung.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--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).