I was trying to get a JPG splash screen working and found a problem
displaying the image correctly. I'm going to bypass the arguments around
including a splash screen inside a product that completes before the monitor
can even sync; this is simply about code.
Anyway, the code as written was finding the first video mode of the correct
width/height and using that. Unfortunately, the mode was a 5-5-5 while the
JPG was being decoded as 5-6-5 (bits per RGB channel). The patch below add
a check for the proper bits-per-channel value before accepting/using the
mode. I'm not a JPG expert, so I don't know if this will work for all
situations but I thought I'd submit it for review.
-- Steve G.
diff --git a/src/bootsplash.c b/src/bootsplash.c
index 76b72c1..69ba018 100644
--- a/src/bootsplash.c
+++ b/src/bootsplash.c
@@ -53,7 +53,8 @@ static int
find_videomode(struct vbe_info *vesa_info, struct vbe_mode_info *mode_info
, int width, int height, int bpp_req)
{
- dprintf(3, "Finding vesa mode with dimensions %d/%d\n", width, height);
+ dprintf(3, "Finding vesa mode with dimensions %d x %d (%d bpp)\n",
+ width, height, bpp_req);
u16 *videomodes = SEGOFF_TO_FLATPTR(vesa_info->video_mode);
for (;; videomodes++) {
u16 videomode = *videomodes;
@@ -84,6 +85,12 @@ find_videomode(struct vbe_info *vesa_info, struct
vbe_mode_info *mode_info
if (depth != bpp_req)
continue;
}
+ // if this is 16 bits per pixel but R:G:B is not 5:6:5 format,
continue
+ if ((depth == 16) &&
+ ((mode_info->red_size != 5) ||
+ (mode_info->green_size != 6) ||
+ (mode_info->blue_size != 5)))
+ continue;
return videomode;
}
}
On Sat, Apr 07, 2012 at 10:09:28PM +0200, Fred . wrote:
> http://www.seabios.org/Releases
>
> Why did the version jump from 0.6.2 to 1.6.3 ?
I increased the major number as I felt the project was no longer in a
"beta" stage.
-Kevin
On Wed, Apr 04, 2012 at 04:04:54PM +0900, Daniel Castro wrote:
> Hello All,
>
> I have a little problem, when I try to get my drive on boot (16bit) I
> am getting the wrong address:
>
> This code:
> struct xendrive_s * xendrive =
> GLOBALFLAT2GLOBAL(container_of(GET_GLOBAL(op->drive_g), struct
> xendrive_s, drive));
op is on the stack, so one must not use GET_GLOBAL on it. Also,
drive_g is already a "global", so GLOBALFLAT2GLOBAL must not be called
on it. So, this should read:
struct xendrive_s * xendrive = container_of(op->drive_g, struct xendrive_s, drive))
If one looks at the other disk drivers, they'll see something similar
- for example ahci_cmd_data() has:
struct ahci_port_s *port = container_of(
op->drive_g, struct ahci_port_s, drive);
-Kevin
On Wed, Apr 4, 2012 at 4:04 PM, Daniel Castro <evil.dani(a)gmail.com> wrote:
> Hello All,
>
> I have a little problem, when I try to get my drive on boot (16bit) I
> am getting the wrong address:
>
> This code:
> struct xendrive_s * xendrive =
> GLOBALFLAT2GLOBAL(container_of(GET_GLOBAL(op->drive_g), struct
> xendrive_s, drive));
> dprintf(1,"Xendrive at:%p\n",xendrive);
> Returns this:
> Xendrive at:0xfff10000
>
> But it should be this instead:
> dprintf(1,"TEST drive 0 %p \n",i,GET_GLOBAL(xendrives[0]));
> returns this:
> TEST drive 0 0x000fd620
>
> This last address is the address returned when done this:
> struct xendrive_s *xd = malloc_fseg(sizeof(struct xendrive_s*));
> SET_FLATPTR(xendrives[count_drives],xd);
> The xd pointer is later used for:
> boot_add_hd(&xd->drive,desc,drives);
>
> Any tip to solve this will be greatly appreciated.
I found a way around it, I create a global array with the drives as I
add them to the boot, when the read operation is called, I compare the
op->drive address to the ones I have registered, that way I can
recover the struct that contains the drive and my custom struct for
the drive.
>
> Thanks you all,
>
> Daniel
>
>
>
>
>
> --
> +-=====---------------------------+
> | +---------------------------------+ | This space intentionally blank
> for notetaking.
> | | | Daniel Castro, |
> | | | Consultant/Programmer.|
> | | | U Andes |
> +-------------------------------------+
--
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| | | Daniel Castro, |
| | | Consultant/Programmer.|
| | | U Andes |
+-------------------------------------+
in current code, pci hot-plug gpe event handler is defined as
a level one "_L01"
1. hw adds device, sets GPE.1 bit and sends SCI
2. OSPM gets SCI, reads GPE00.sts and masks GPE.1 bit in GPE00.en
3. OSPM executes _L01
4. hw adds second device and sets GPE.1 bit but SCI is not asserted
since GPE00.en masks event
5. OSPM resets GPE.1 bit in GPE00.sts and umasks it in GPE00.en
as result event for step 4 is lost because step 5 clears it and OS
will not see added second device.
ACPI 50 spec: 5.6.4 General-Purpose Event Handling
defines GPE event handling as following:
1. Disables the interrupt source (GPEx_BLK EN bit).
2. If an edge event, clears the status bit.
3. Performs one of the following:
* Dispatches to an ACPI-aware device driver.
* Queues the matching control method for execution.
* Manages a wake event using device _PRW objects.
4. If a level event, clears the status bit.
5. Enables the interrupt source.
Switching from level to edge event handler reduces chances to
hit race window.
Same applies to cpu-hotplug, so switch it to edge handler as well.
Tested with RHEL6, 3.3.+ kernel, winxp, and w2008r2, and I wasn't
able to trigger race after using edge event handler.
Signed-off-by: Igor Mammedov <imammedo(a)redhat.com>
---
src/acpi-dsdt.dsl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 4e04c48..4bdc268 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -723,11 +723,11 @@ DefinitionBlock (
Method(_L00) {
Return(0x01)
}
- Method(_L01) {
+ Method(_E01) {
// PCI hotplug event
Return(\_SB.PCI0.PCNF())
}
- Method(_L02) {
+ Method(_E02) {
// CPU hotplug event
Return(\_SB.PRSC())
}
--
1.7.7.6
Hello All,
I have a little problem, when I try to get my drive on boot (16bit) I
am getting the wrong address:
This code:
struct xendrive_s * xendrive =
GLOBALFLAT2GLOBAL(container_of(GET_GLOBAL(op->drive_g), struct
xendrive_s, drive));
dprintf(1,"Xendrive at:%p\n",xendrive);
Returns this:
Xendrive at:0xfff10000
But it should be this instead:
dprintf(1,"TEST drive 0 %p \n",i,GET_GLOBAL(xendrives[0]));
returns this:
TEST drive 0 0x000fd620
This last address is the address returned when done this:
struct xendrive_s *xd = malloc_fseg(sizeof(struct xendrive_s*));
SET_FLATPTR(xendrives[count_drives],xd);
The xd pointer is later used for:
boot_add_hd(&xd->drive,desc,drives);
Any tip to solve this will be greatly appreciated.
Thanks you all,
Daniel
--
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| | | Daniel Castro, |
| | | Consultant/Programmer.|
| | | U Andes |
+-------------------------------------+
What is the outcome of this patch? I mean, does it actually fix
something visible, instead of a potential problem?
[]
>>> Anyone interested in this ? Is there a maintainer for x86emu ? The
>>> MAINTAINERS file in xorg-docs doesn't mention anything about it.
>>
>> CCed: Adam Jackson
>>
>> Adam, you seem to be the maintainer of the xorg vesa driver. I think
>> this patch is closely related. Would you mind taking a look at it ?
I asked another question related to xorg vesa driver, also related to
qemu, about it being unable to find available resolutions when run under
qemu -- this: http://lists.x.org/archives/xorg-devel/2012-March/030037.html
Is this 0x66 issue related to my question somehow? :)
Thanks,
/mjt
On Thu, Mar 15, 2012 at 10:45 PM, Julian Pidancet
<julian.pidancet(a)gmail.com> wrote:
> On Thu, Mar 15, 2012 at 10:39 PM, Julian Pidancet
> <julian.pidancet(a)gmail.com> wrote:
>> On Fri, Mar 9, 2012 at 2:08 AM, Guillem Jover <guillem(a)hadrons.org> wrote:
>>> On Fri, 2012-03-09 at 00:02:55 +0000, Julian Pidancet wrote:
>>>> Some instructions are not emulated correctly by x86emu when they
>>>> are prefixed by the 0x66 opcode.
>>>> I've identified problems in the emulation of these intructions: ret,
>>>> enter, leave, iret and some forms of call.
>>>>
>>>> Most of the time, the problem is that these instructions should push or
>>>> pop 32-bit values to/from the stack, instead of 16bit, when they are
>>>> prefixed by the 0x66 special opcode.
>>>>
>>>> The SeaBIOS project aims to produce a complete legacy BIOS
>>>> implementation as well as a VGA option ROM, entirely written in C and
>>>> using the GCC compiler.
>>>>
>>>> In 16bit code produced by the GCC compiler, the 0x66 prefix is used
>>>> almost everywhere. This patch is necessary to allow the SeaBIOS VGA
>>>> option ROM to function with Xorg when using the vesa driver.
>>>>
>>>> v2: - Decrement BP instead of EBP in accordance with the Intel Manual
>>>> - Assign EIP instead of IP when poping the return address from the
>>>> stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret
>>>> - When poping EFLAGS from the stack in iret in 32-bit operand size
>>>> mode, apply some mask to preserve Read-only flags.
>>>>
>>>> Signed-off-by: Julian Pidancet <julian.pidancet(a)gmail.com>
>>>
>>> Looks good to me:
>>>
>>> Reviewed-by: Guillem Jover <guillem(a)hadrons.org>
>>>
>>> thanks,
>>> guillem
>>
>> Anyone interested in this ? Is there a maintainer for x86emu ? The
>> MAINTAINERS file in xorg-docs doesn't mention anything about it.
>>
>
> CCed: Adam Jackson
>
> Adam, you seem to be the maintainer of the xorg vesa driver. I think
> this patch is closely related. Would you mind taking a look at it ?
>
> Thanks,
>
Ping ?
--
Julian