Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Sunday 18 September 2005 11:03 pm, Vesa Jääskeläinen wrote:
>> Sorry it took a bit longer to check those out, but after returning from
>> my vacation it took some time to get back to normal day life.
> 
> Presumably you didn't sleep enough in your airplain...

For the first flight I tried... and for the returning flight I didn't
even try :|... A bit too small space for me :( Total travel time for a
day was something like 23 hours. But that was compensated in a couple of
days, it was the other stuff that has been keeping me away.

>> Also there was small semantic change in grub_vbe_probe, now if user
>> provides info_block parameter, it will always call VESA BIOS to get
>> information even though this would be cached in second run. I have no
>> problem with this, but out of curiosity, was there some reason for this
>> change?
> 
> As I wrote in ChangeLog, you cannot reuse the information block over multiple 
> BIOS calls, because that region resides at a BIOS data area, and it is 
> overwritten in next call. In fact, vbeinfo didn't show correct modes, until I 
> fixed it.

Perhaps you mixed this with vbeinfo code itself? Because in
grub_vbe_probe (in video/i386/pc/vbe.c) there has been grub_memcpy to
copy this information from scratch to local static variable
(controller_info) and then if caller provided non NULL pointer, it would
also be copied to caller's variable. And as this information is now
copied in static variable controller_info it can be used and cached for
later usage.

For me vbeinfo has always showed correct information, but if something
uses scratch area while walking that mode list it could give some nice
side effects. So making copy of those modes doesn't hurt. Perhaps this
should be hidden and be generalized a bit.

Let me think this a day or two (hopely not weeks) and I try to make a
some kind of draft how to implement this gfx stuff more nicely. I'll try
to take account ideas that have been posted to this list while making
that draft.

> But, according to Subdino, vbetest does not run twice correctly. So there 
> must 
> be still something I looked over.

That is a bit odd I might say. Do you have any more details about this
problem? What exactly is wrong? Is there any way to reproduce this?

I will look at the code later on and see if I could spot something that
could be related to this.

Thanks,
Vesa Jääskeläinen