Re: Update on video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <address@hidden> writes:
>> I have made some updates to wiki . Changed some parameters from
>> grub_[u]int32_t to standard C types ([unsigned] int). Added functions
>> used to manage and use render targets.
> 
> Nice.  I am not really sure what a render target exactly is.  It would
> be really nice if this could be added to the documentation.

I will write short terminology chapter shortly containing that term.

>> Here is the URL there:
>> http://grub.enbug.org/VideoSubsystem
> 
> Nice.  I can change some of the coding style so it matches the GCS if
> you do not mind.  I am not at home now, I'll do that when I am back
> home.

No, not at all. Please tell me what are your changes so I can improve my
knowledge of how to use GCS. (As I tried to follow that ;))

>> There is currently some issues with videoterm, screen is only rendered
>> when terminal refresh is called. Actually I would like to get more
>> information what each terminal function is supposed to do and how they
>> should be used. At the moment you have to blindly write commands at this
>> point as command line is not refreshed all the time :).
> 
> Right, and this behavior should not be changed.  This approach
> drastically improves performance for some terminal, I think the same
> is true for the frame buffer, right?

Yep, refreshing the whole screen is slow process. There must be a way to
render only certain sections of screen. There are currently some
"limitations" for this but still doable. I need to think more and then
decide whether API's should change or just to use currently available
method.

>> I would like to have some feedback on following areas:
>> - Is there all needed video API's present? If not give a description
>> what functionality is required and let's see where that should be
>> implemented.
> 
> I'll look over it Monday, but it looks that way for now.  If we miss
> something we can always add it, but it is easier to do that now, of
> course.
> 
>> - You are of course free to provide optimization ideas. At this point I
>> have only considered dirty regions.
> 
> Ok.
> 
>> - What would be a good way to debug code like this :)... I have VMware
>> running here and could use one of it's devices to get debug messages but
> 
> For a GNU project VMWare is absolutely not an option.  You are of
> course free to do whatever you like, but it is not something that can
> be documented.

Well I don't even run a Linux natively on this system :). I use VMware a
lot for different things on this system, so for me it is natural to also
develop grub2 on this configuration.

But there are open source systems like bochs and others that might
support also virtual serial ports/nic's or so that can also be used on
VMware. Serial debugging could be a nice feature.

May I ask why that cannot be documented? Of course I can provide this
information on my own website if required.