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
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
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.
>>>
>
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
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"
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
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
Yoshinori K. Okuji wrote:
> On Saturday 10 December 2005 11:05 am, Vesa Jääskeläinen wrote:
>> Changing coding guide of using grub_errno we could probably get this
>> issue "working". But then there is still problem with lost error
>> messages if subsequent code fails with real error.
>>
>> If we j
On Dec 10, 2005, at 10:47 AM, Marco Gerards wrote:
Can you describe your biarch change and how that affects the AMD64
port? Can I still crosscompile like I was used to?
http://cvs.savannah.gnu.org/viewcvs/grub/grub2/configure.ac.diff?
tr1=1.17&tr2=1.18&r1=text&r2=text
Heh, that's code and
On Sat, 2005-12-10 at 01:23 +0100, Yoshinori K. Okuji wrote:
> On Saturday 10 December 2005 12:32 am, Marco Gerards wrote:
> > Anyways, my primary concerns are making things work and moving
> > forwards to something that is releasable. Making GRUB work in a way
> > so it works like everyone wants
Hollis Blanchard <[EMAIL PROTECTED]> writes:
>> Eight. And when in doubt, better flush too much.
>
> Eight lines?
> http://cvs.savannah.gnu.org/viewcvs/grub/grub2/kern/powerpc/
> cache.S.diff?tr1=1.1&tr2=1.2&r1=text&r2=text says it's two.
s/Eight/Right/ :-)
> My first approach was just to flush
On Dec 10, 2005, at 8:18 AM, Marco Gerards wrote:
Hollis Blanchard <[EMAIL PROTECTED]> writes:
I just fixed an embarassing bug in kern/powerpc/cache.S, where if
`address' is not cacheline-aligned (which is a common and reasonable
thing), it would fail to flush/invalidate the last cacheline. (I
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Friday 09 December 2005 12:40 am, Peter Jones wrote:
>> Now, the obvious retort to this is that no setuid programs are calling
>> grub, so it's not even one of those cases. That's not a good answer
>> either. I've got one I'd really *like* to
Hollis Blanchard <[EMAIL PROTECTED]> writes:
> I just fixed an embarassing bug in kern/powerpc/cache.S, where if
> `address' is not cacheline-aligned (which is a common and reasonable
> thing), it would fail to flush/invalidate the last cacheline. (It
> takes a little thinking, but draw a picture
On Saturday 10 December 2005 11:05 am, Vesa Jääskeläinen wrote:
> Changing coding guide of using grub_errno we could probably get this
> issue "working". But then there is still problem with lost error
> messages if subsequent code fails with real error.
>
> If we just zero out grub_errno in code b
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
>>
Marco Gerards wrote:
> Vesa Jääskeläinen <[EMAIL PROTECTED]> writes:
>
>> Some folks might have overlooked my earlier post as I wrote it to video
>> subsystem thread. As this problem needs some kind of resolution and it
>> affects larger area of code than just video subsystem it needs to be
>> dis
17 matches
Mail list logo
