Re: Update on video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> 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 diffe

Re: Update on video subsystem draft

Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> 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 t

Re: Update on video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> 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.

Re: Update on video subsystem draft

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

Update on video subsystem draft

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 thos

Re: Video subsystem draft

Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: >> I thinked that selecting the bpp is not important and I optimized it out >> :), but if this is wanted feature I think guiding is better option. >> There are many different RGB modes and I think that it would be most >> reasona

Re: Video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: >> I would just used `int' and `unsigned int'. It's just important that >> you don't explicitly use a specific amount of bits and leave that to >> the compiler. > > Ok. Can I assume that unsigned int always has at least 32 bits? Or do I > need to spec

Re: Video subsystem draft

Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > >>> I don't like using grub_uint*_t for parameters. Just use normal >>> integers instead. These types just have to be used for ABIs and >>> network and disk access. In the case of APIs such types should be >>> avoided. >>> >

Re: Video subsystem draft

Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > >>> First of all I'd like to see some double buffering feature. Will that >>> be somehow possible? In that case we need functions like: >>> >>> - Switching to a buffer, making it visible. >>> - Selecting which buffer is used

Re: Video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: >> I don't like using grub_uint*_t for parameters. Just use normal >> integers instead. These types just have to be used for ABIs and >> network and disk access. In the case of APIs such types should be >> avoided. >> >> So better use "int height"

Re: Video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: >> First of all I'd like to see some double buffering feature. Will that >> be somehow possible? In that case we need functions like: >> >> - Switching to a buffer, making it visible. >> - Selecting which buffer is used for output. > > Yes, double b

Re: Video subsystem draft

Marco Gerards wrote: > What is the emulation you talk about for set palette? In order to support theming, there is most likely some predefined colors. We could use palette to save those defaults. When certain color would be needed then we just ask for color with grub_video_map_color () and it woul

Re: Video subsystem draft

Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > >> Vincent Pelletier wrote: >>> By the way, I think we should start a discussion on the API common to >>> all architectures for framebuffer handling. >> Currently there is a terminal implementation that uses video subsystem >>

Re: Video subsystem draft

On Friday 09 December 2005 11:44 pm, Marco Gerards wrote: > Why are viewports needed? Because we want to set a region to display a menu, I guess. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > Vincent Pelletier wrote: >> By the way, I think we should start a discussion on the API common to >> all architectures for framebuffer handling. > > Currently there is a terminal implementation that uses video subsystem > to render screen. So basicly

Re: Video subsystem draft

Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > If I remember correctly I also saw caching of sectors in disk code, so > basicly if disk cache is big enough old font data will already be in > memory. And this will only cause little delay as there is no I/O > latency. Actual testing in real hardwar

Re: Video subsystem draft

Ok... The problem is with grub_errno. There might be other cases where this problem shows up too. But with font manager this is easy to see. In my testerr3 testing function (in video.c) I added simple: grub_errno = GRUB_ERR_NOT_IMPLEMENTED_YET; grub_printf("error: no error :)\n"); Now it cor

Re: Video subsystem draft

Vesa Jääskeläinen wrote: > Just in case you (or someone else) want to test current version, I have > uploaded it to: > http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051126.tar.gz > > I noticed that when ever I call grub_error something brakes, but what is > doing it I can't tell. There is a tes

Re: Video subsystem draft

Yoshinori K. Okuji wrote: > On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote: >>> Compression might make the performance horrible, because PPF is very >>> optimized. >> When there is a caching implemented in a one day, it's only initial >> cost. So far I haven't seen performance probl

Re: Video subsystem draft

Vincent Pelletier wrote: > By the way, there is already a font format handled by IEEE1275 > frame buffercards. > - From the standard : > > set-font ( addr width height advance min-char #glyphs -- ) > Set the current font as specified. > > So I think they can handle arbitrary-sized glyphs. > I ca

Re: Video subsystem draft

Vincent Pelletier wrote: > By the way, I think we should start a discussion on the API common to > all architectures for framebuffer handling. Currently there is a terminal implementation that uses video subsystem to render screen. So basicly in every arch there must be a video driver if you want

Re: Video subsystem draft

On Saturday 26 November 2005 03:36 pm, Vincent Pelletier wrote: > By the way, there is already a font format handled by IEEE1275 > frame buffercards. > From the standard : > > set-font ( addr width height advance min-char #glyphs -- ) > Set the current font as specified. If my understanding is cor

Re: Video subsystem draft

On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote: > > Compression might make the performance horrible, because PPF is very > > optimized. > > When there is a caching implemented in a one day, it's only initial > cost. So far I haven't seen performance problems with this. But then > ag

Re: Video subsystem draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 26 Nov 2005 02:28:53 +0200 Vesa Jääskeläinen <[EMAIL PROTECTED]> wrote: > Yoshinori K. Okuji wrote: > > If you want to improve it, feel free to do it. It is our own > > format. But I think the byte order was set conveniently. > > Byte order is

Re: Video subsystem draft

Yoshinori K. Okuji wrote: > On Tuesday 22 November 2005 08:06 pm, Vesa Jääskeläinen wrote: >> I think it can be gzipped to fit more nicely :).. (and it seems to work >> too). > > Compression might make the performance horrible, because PPF is very > optimized. When there is a caching implemented

Re: Video subsystem draft

On Tuesday 22 November 2005 08:06 pm, Vesa Jääskeläinen wrote: > I think it can be gzipped to fit more nicely :).. (and it seems to work > too). Compression might make the performance horrible, because PPF is very optimized. > After something calls grub_error first read from font file fails, wit

Re: Video subsystem draft

Yoshinori K. Okuji wrote: > On Friday 18 November 2005 12:19 am, Vesa Jääskeläinen wrote: >> What is the procedure to generate font file to font manager? Or should I >> just add some functionality to import VGA font to font manager. > > First, download unifont.hex from

Re: Video subsystem draft

On Friday 18 November 2005 12:19 am, Vesa Jääskeläinen wrote: > What is the procedure to generate font file to font manager? Or should I > just add some functionality to import VGA font to font manager. First, download unifont.hex from . Then, convert it

Re: Video subsystem draft

Vesa Jääskeläinen wrote: >>> In order to make GRUB 2's video subsystem more flexible, there is a need >>> to modify font manager in order to support more variety of different >>> character types. I already tested it with one idea and it seems to work >>> nicely, but in order to support more charac

Re: Video subsystem draft

Yoshinori K. Okuji wrote: > On Sunday 23 October 2005 01:24 pm, Vesa Jääskeläinen wrote: >> I made a draft how video subsystem could work. It doesn't currently >> contain information about internals, but is more concentrated on usage >> of the API. > > It looks good. Then I'll do the first implem

Re: Video subsystem draft

On Sunday 23 October 2005 01:24 pm, Vesa Jääskeläinen wrote: > I made a draft how video subsystem could work. It doesn't currently > contain information about internals, but is more concentrated on usage > of the API. It looks good. > In order to make GRUB 2's video subsystem more flexible, there

Re: Video subsystem draft

Timothy Baldwin wrote: > On Sunday 23 Oct 2005 12:24, Vesa Jääskeläinen wrote: >> Hi, >> >> I made a draft how video subsystem could work. It doesn't currently >> contain information about internals, but is more concentrated on usage >> of the API. > > GRUB should support modes with fixed palettes

Re: Video subsystem draft

On Sunday 23 Oct 2005 12:24, Vesa Jääskeläinen wrote: > Hi, > > I made a draft how video subsystem could work. It doesn't currently > contain information about internals, but is more concentrated on usage > of the API. GRUB should support modes with fixed palettes, in order to support (firmware)

Video subsystem draft

Hi, I made a draft how video subsystem could work. It doesn't currently contain information about internals, but is more concentrated on usage of the API. In order to make GRUB 2's video subsystem more flexible, there is a need to modify font manager in order to support more variety of different