All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Update on video subsystem draft
Date: Sun, 01 Jan 2006 16:24:01 +0200	[thread overview]
Message-ID: <43B7E601.8020209@nic.fi> (raw)
In-Reply-To: <877j9lb4zg.fsf@xs4all.nl>

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.



  reply	other threads:[~2006-01-01 14:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-31  1:39 Update on video subsystem draft Vesa Jääskeläinen
2005-12-31 15:54 ` Hollis Blanchard
2005-12-31 16:34 ` Marco Gerards
2006-01-01 14:24   ` Vesa Jääskeläinen [this message]
2006-01-01 17:16     ` Marco Gerards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43B7E601.8020209@nic.fi \
    --to=chaac@nic.fi \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.