* API for formatting a number and recovering the field positions
* Some changes in the preflet to display the formatted number and start filling in the fields.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38335 a95241bf-73f2-0310-859d-f6bbb57e9c96
(not currently used anywhere, but should be part of the BTimeZone interface)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38333 a95241bf-73f2-0310-859d-f6bbb57e9c96
First B_MEDIA_SEEK_TO_FRAME was handled to compute a time, then
it was ignored and frame was used as time stamp. Also the
conversion from frame to time had the num and den members of
the time base swapped in the computation, so it computed
bogus time stamps. Refactored the conversion methods, always
seek based on the time. Needs more testing (perhaps there are rounding
issues), but overriding a lot of native reader implementations with
AVFormatReader holds up very well now with a lot of files I tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38332 a95241bf-73f2-0310-859d-f6bbb57e9c96
The fWriterThread and fWriterStackBase were reset in WriteUnlock()
without holding any lock. While running a DEBUG compile of app_server,
I ran repeatedly into an assertion in the mouse event thread, that
it was not the write lock holder anymore when calling WriteUnlock().
My theory (also discussed with Axel, thanks!) is as this: Some random
thread holds the write-lock. The mouse event thread is allowed to run
when that thread releases the write-lock, but the thread is rescheduled
before it resets the write-lock-holder values (B_DO_NOT_RESCHEDULE only
means rescheduling is not forced, but it may happen anyway). Then the
mouse thread runs, acquires the write-lock, sometime later the original
thread continues to run, and completes WriteUnlock() with resetting the
holder values. When the mouse thread continues to run and eventually
calls WriteUnlock(), the holder values do not match anymore. The theory
is further confirmed by the fact, that fWriterThread was always -1 in the
assert and not some random other thread.
As mentioned, only affected DEBUG builds of app_server, in release builds,
another lock protects the holder values.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38331 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved tracing in PluginManager.cpp when loading an add-on.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38330 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Read the EDID info on both port A (analog VGA monitor) and C (LVDS panel)
* If an LVDS panel is detected, report the EDID resolutions instead of the BIOs settings
This fixes#6326, likely #5096, and possibly some others intel_extreme problems. Please test.
On the other hand, this make the screen preflet show the full list of more reported by the LVDS panel. As we don't support
scaling, some of these modes are unuseable and lead to a garbled screen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38329 a95241bf-73f2-0310-859d-f6bbb57e9c96
to BEntry and back to entry_ref. This ommits a check to
BEntry::InitCheck(), but AddOnMonitor should pass us only valid
entry_refs.
* Removed no longer valid TODO.
TODO: There is still some problem with reloading add-ons, once they have
been reloaded, they fail to instantiate properly, as if the entry_ref
is pointing to the wrong node.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38328 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the chosen preferred languages weren't restored in Locale preflet
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38325 a95241bf-73f2-0310-859d-f6bbb57e9c96
A grackle-compatible Motorola MPC106 PCI controller can be found in the
PowerMac G3 (ticket #6247). For now just let the user know.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38323 a95241bf-73f2-0310-859d-f6bbb57e9c96
* use upon-demand initialization in BTimeZone to avoid unnecessary work
* renamed BTimeZone::Code() to BTimeZone::ID() and adjusted all callers
* avoid using BCountry in the Time preflet for the time being, this means
the icon-flags are gone for now (but they could be re-added if the demand
is pressing ;-)
* group the timezones by regions and then by country instead
The performance improvement is considerable and I personally think the new grouping is an improvement, too. Please share your thoughts!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38322 a95241bf-73f2-0310-859d-f6bbb57e9c96
if the size of the window is not a multiple of the text font size is cleared.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38317 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also make the color attribute propagate to the end of a line. This fixes part of #6143 and allows to use vim with a multicolor syntax highlighting without too much trouble.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38316 a95241bf-73f2-0310-859d-f6bbb57e9c96
Read the EDID from OF and pass it on to the kernel.
Last part of ticket #6105.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38307 a95241bf-73f2-0310-859d-f6bbb57e9c96
Use the OF "screen" device alias to query frame buffer properties. Postpone
the opening of the device as far as possible as it erases the screen output.
Initialize the kernel arguments and hook into generic code to display the
splash screen.
Like on x86, the frame buffer is enabled by default. To disable it, either
press ESC during early boot or, for debugging, make sure in start.cpp that
platform_boot_options() has the BOOT_OPTION_DEBUG_OUTPUT flag set.
Resolves ticket #6105.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38306 a95241bf-73f2-0310-859d-f6bbb57e9c96
Avoid writing to stdout if the frame buffer is enabled.
Part of ticket #6105.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38305 a95241bf-73f2-0310-859d-f6bbb57e9c96
Introduce a non-blocking function for checking keyboard input, and refactor
existing code to share the escape key translations. The comment that key-up and
key-down result in a zero char is confirmed to apply.
If the space bar is pressed, enter the boot menu. If the escape key is pressed,
disable the frame buffer and keep showing the usual debug output. Apparently
the key press must come after console/keyboard initialization but before the
"Welcome to the Haiku bootloader!" line.
Closes ticket #6140.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38304 a95241bf-73f2-0310-859d-f6bbb57e9c96
The frame buffer will need more generic sources than just the text menu.
Adapted from bios_ia32 platform.
Part of ticket #6105.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38301 a95241bf-73f2-0310-859d-f6bbb57e9c96
Debug output calls OpenFirmware methods writing text into the frame buffer.
Depending on the screen mode this leads to garbled display or parts of the
screen overwritten, so mute the output during frame buffer use for now.
A better solution would be to redirect the output elsewhere (e.g., #6168),
so that ConsoleHandle::WriteAt() is not called for the problematic handle
in the first place. That does not work inside the kernel yet.
Part of ticket #6105.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38300 a95241bf-73f2-0310-859d-f6bbb57e9c96
Initialize the frame buffer as not enabled. Add checks for this condition
and for the debug boot option to the video functions.
Code is adapted from bios_ia32 platform. Part of ticket #6105.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38299 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is a leftover from the r25913 build fix. It used to be an out parameter.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38294 a95241bf-73f2-0310-859d-f6bbb57e9c96
This remedies "Current thread pointer [...] is an address we can't read from."
on entering KDL. Closes ticket #6163.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38293 a95241bf-73f2-0310-859d-f6bbb57e9c96
Let setting the memory type to B_MTR_UC succeed.
Add initial support for those memory types in the translation map,
pointed out by Ingo in ticket #5193.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38292 a95241bf-73f2-0310-859d-f6bbb57e9c96
Revert r36886 and fix compilation of insert_virtual_range_to_keep().
The use of void* vs. addr_t matches the surrounding boot loader code
but should probably be revised in favour of addr_t.
create_area() in the kernel wrongly assumed a RAM-backed address range,
which was destined to fail since ranges below the kernel address space
were ignored anyway. Use vm_map_physical_memory() instead.
This fixes a hang once the frame buffer and other resources used by OF
get unmapped. Closes ticket #5193 again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38291 a95241bf-73f2-0310-859d-f6bbb57e9c96
There are TODO's in here, because the ACPI module needs restructuring and which I will take care of.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38289 a95241bf-73f2-0310-859d-f6bbb57e9c96
