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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
