Opened 6 years ago

Last modified 6 years ago

#9924 new bug

Incorrect resolution at boot

Reported by: anevilyak Owned by: bonefish
Priority: low Milestone: R1
Component: System/Boot Loader Version: R1/Package Management
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

On package management builds, the boot loader shows up at the wrong resolution, and is squashed/offset. This doesn't occur on regular Haiku builds. If it matters, the GPU in this instance is a Radeon X800, and the resolution is correct again once the desktop is hit.

Attachments (1)

syslog (161.6 KB ) - added by anevilyak 6 years ago.

Download all attachments as: .zip

Change History (4)

by anevilyak, 6 years ago

Attachment: syslog added

comment:1 by bonefish, 6 years ago

Save for the boot loader now supporting to read the kernel and drivers from within a package, nothing much has changed. I'm not familiar with the graphics related code, though. The only thing I can think of ATM is that the VESA drivers settings file could not be loaded. Can you add some debug output in src/system/libroot/os/driver_settings.cpp:load_driver_settings_from_file(), so we see what file is attempted to be opened and whether that succeeds (use dprintf() in an #ifdef _BOOT_MODE block).

in reply to:  1 comment:2 by anevilyak, 6 years ago

Replying to bonefish:

The only thing I can think of ATM is that the VESA drivers settings file could not be loaded. Can you add some debug output in src/system/libroot/os/driver_settings.cpp:load_driver_settings_from_file(), so we see what file is attempted to be opened and whether that succeeds (use dprintf() in an #ifdef _BOOT_MODE block).

Will look into it after work. For what it's worth though, I don't recall explicitly setting up a VESA setttings file, as the correct resolution has always been automatically selected on my hardware without intervention. Perhaps some other block of code isn't executed that should be as a result of the above idea though.

comment:3 by anevilyak, 6 years ago

Interestingly, with a dprintf in place I can no longer reproduce the problem. Opening the vesa settings file does indeed fail as it's not in fact present on disk. Reverting back to the original code causes the problem to resurface; I'm wondering if there's possibly a timing issue at play here. I did also have to add an include for <boot/platform.h> to get at dprintf in boot mode, so alternatively I suppose it's possible that had some other influence, though given that was only for driver_settings.cpp I'm not really seeing how. The indicated selected video mode (1280x1024x32) matches between both logs though.

Note: See TracTickets for help on using tickets.