Egmont Koblinger <[email protected]> wrote:
> 2. My patch introduced "question mark with inverted color attributes" as a
> last resort fallback glyph. Though it perfectly works on VGA console, on
> framebuffer you may end up with question marks that are highlighed but
> shouldn't be, and normal characters that are accidentally highlighed.
> This is caused by missing FLUSHes when changing the color attribute.
Does the FLUSH DTRT by design, or does it just shrink and hide the original
race? And why wasn't VGA affected, too?
--
Backups? We doan NEED no steenking baX%^~,VbKx NO CARRIER
Fri?, Spammer: [email protected]
[email protected] [email protected]
On Tue, Jun 19, 2007 at 03:54:52PM +0200, Bodo Eggert wrote:
> Does the FLUSH DTRT by design, or does it just shrink and hide the original
> race?
I haven't deeply studied this aspect of the source, don't know what
_exactly_ this FLUSH does, but of course I have an inner feeling about this.
Kind of this macro does the _real_ print on the screen. It actually calls
vc->vc_sw->con_putcs, whereas I guess vc_sw refers to the particular
implementation (vga, fb) and con_putcs might be doing the real job.
Without these two new FLUSHes the behavior was very funny: applications
(e.g. text editors) highlighed incorrect cells, but either switching between
VTs, or gpming over these cells corrected the display. So the logical
content behind the scenes (reflected by /dev/vcsa*) was maintained
correctly, the bug is somewhere when the content is first displayed.
I saw that this FLUSH was already used 3 times inside do_con_write(), I
placed it here 2 more times (when changing color attr to inverse and when
reverting to normal). I think it cannot hurt, and apparently it fixes the
problem.
But you may be right: yes, it might be a bug (or misfeature) in the FB code,
too. Could you please look after it? I don't think I'd be able to do it and
have time for this.
> And why wasn't VGA affected, too?
I guess tt must be some difference between the actual VGA and FB code that
is called from here. I don't know whether it's a bug in FB or just some
difference.
Perhaps it's that the FB driver's con_putcs() call uses vc->vc_attr (the
current attr for the console) for each char cell to be printed, instead of
the own attr values of the cells themselves. Just an idea...
--
Egmont
On Tue, 19 Jun 2007, Egmont Koblinger wrote:
> On Tue, Jun 19, 2007 at 03:54:52PM +0200, Bodo Eggert wrote:
>
> > Does the FLUSH DTRT by design, or does it just shrink and hide the original
> > race?
<long snip>
> But you may be right: yes, it might be a bug (or misfeature) in the FB code,
> too. Could you please look after it? I don't think I'd be able to do it and
> have time for this.
I have neither the insight nor the time to do that. I just read the bug
description and drew my conclusions.
--
Never stand when you can sit, never sit when you can lie down, never stay
awake when you can sleep.