Update on video subsystem draft

Update on video subsystem draft

[Vesa Jääskeläinen]

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.

Here is the URL there:
http://grub.enbug.org/VideoSubsystem

I also decided to release sneak peak of current version for those
wanting to see what there is currently.

WARNING! This sneak peak is not usable and is only released in order to
get feedback of its functionality. It is not optimized in any way at the
moment and contains debug code that will slow it down and render
unnecessary debug pixels. Also note that code is not synched lately with
CVS so other parts is not up to date.

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 :).

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.
- You are of course free to provide optimization ideas. At this point I
have only considered dirty regions.
- 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
at the moment there is no code to support this.
- Other issues?

Here is the URL for sneak peak:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051231.tar.gz

Quick guide:
# mkdir grubtmp
# cd grubtmp
tar -xzvf grub2-video-20051231.tar.gz
# Please study makegrub script if it needs some changes for your system.
cd grub2.video
./configure
make
../makegrub

Thanks,
Vesa Jääskeläinen

Re: Update on video subsystem draft

[Hollis Blanchard]

On Dec 30, 2005, at 7:39 PM, Vesa Jääskeläinen wrote:

> - 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
> at the moment there is no code to support this.

The best way to debug video drivers is with a serial console. You could 
make grub_serial_putchar() non-static, then call it directly from the 
code you're trying to debug.

Of course it would also be cool if you could output to two consoles at 
once, but I'm not sure if that's currently possible or how to do that.

-Hollis

Re: Update on video subsystem draft

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

Hi Vesa,

> 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.

> 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.

> 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?

> 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.

What I have in mind is extending grub-emu so we can use grub-emu+XFree
to debug the video code.  I could have a look next Monday what needs
to be done in order to accomplish that.

Thanks,
Marco

Re: Update on video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> 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.

Re: Update on video subsystem draft

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

>> 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.

Perhaps bochs or qemu would work.

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

Because for a GNU project references in official documentation to
non-free software is not allowed.  Of course you are free to put on
your website whatever you want to put there :-).  But I seriously doubt
that vmware has the debugging features bochs has.

--
Marco