The skeleton 'hdb' application does nothing usefull beside, as I was trying to get fluent in team_debugger
messages.
That's pretty much all what I came with during a pathetic attempt to secure some free time to work on
a (indeed) most wanted native graphical debugger for Haiku. Building libdwarf was pending when I've realized
I wont have time ever.
Ingo, I hope you don't mind. Fee free to do whatever you want with it, remove included.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31066 a95241bf-73f2-0310-859d-f6bbb57e9c96
Instead, let's call /bin/fortune without specific file by default to use its random selection
feature.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30310 a95241bf-73f2-0310-859d-f6bbb57e9c96
easily: moved out of config.h some definitions that we could do
dynamically per target architecture.
NOTE: ppc, m68k and sparc optimizations are currently missing and should
be imported from ffmpeg 0.5 before we can build avcodec plugin for these
targets. Hence why it's still X86_ONLY qualified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30185 a95241bf-73f2-0310-859d-f6bbb57e9c96
to support more than just x86. Not yet SubInclude'd, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30179 a95241bf-73f2-0310-859d-f6bbb57e9c96
them to the image. Thanks Urias for testing, submitting patches and... being
patient ;)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30094 a95241bf-73f2-0310-859d-f6bbb57e9c96
the job instead of dispatch.c.
* Fixed BYTE_ORDER support for BIG_ENDIAN targets (PPC).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30093 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed a bug I've miss last time: everything under /boot/system was considered
a server team, including system apps and demos!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30051 a95241bf-73f2-0310-859d-f6bbb57e9c96
Before, it was spread in libmesa.a *and* mesa_arch_$(TARGET_ARCH).o,
the later was broken for non-x86 targets.
Now, GL API dispatching is entirely in glapi-dispatching.o,
while libmesa.a contains only the software GL implementation.
* This should fix PPC libGL.so build - UNTESTED
* Added SPARC assembly code introduced by Mesa 7.2 and sooner - UNTESTED
* Removed a non-longer need workaround in glthread.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30050 a95241bf-73f2-0310-859d-f6bbb57e9c96
At least, this system directory relayout show vividly that in many places we should use find_directory()
instead. Ironically, these ones can't but keep hardcoded paths, except if I've missed some
/bin/find_directory tool ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29892 a95241bf-73f2-0310-859d-f6bbb57e9c96
Please review, as I clearly dunno what I'm doing here ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29889 a95241bf-73f2-0310-859d-f6bbb57e9c96
"Haiku Media Kit: ", as it's given for any caller of a Media Kit API ;-)
* This remove an systematic line feed in the codec pretty name returned;
* Updated MediaPlayer info window text layout to take this change into account.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29836 a95241bf-73f2-0310-859d-f6bbb57e9c96
Quick because a better option is use the layout feature.
Dirty because it's assert BMediaTrack::GetCodecInfo() return a two-lines pretty name.
BTW, why prefixing "Haiku Media Kit:\n" the codec name?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29806 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixed a typo in method name.
Please forgive me Stephan if I just screw your next commit...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29240 a95241bf-73f2-0310-859d-f6bbb57e9c96
MPS table CPU entries for the enabled flag.
This caused Haiku to fail to boot under KVM on Linux.
Thanks you, jkeeping.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29222 a95241bf-73f2-0310-859d-f6bbb57e9c96
BTW, changing cursor shape when he's invisible will show it immediatly
right now. Sounds like wrong...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28978 a95241bf-73f2-0310-859d-f6bbb57e9c96
BTW, sometimes it is (undocumented application pages), sometimes it's not.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28895 a95241bf-73f2-0310-859d-f6bbb57e9c96
(can't tell if it was the same for audio, as mine -hda- is not supported
yet).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25894 a95241bf-73f2-0310-859d-f6bbb57e9c96
(P5W-DH motherboard have two of those gigabit ethernet controllers),
seems to work fine.
* Add libglut.so alias to the development libs symlinks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23902 a95241bf-73f2-0310-859d-f6bbb57e9c96
taken as-is from a previous launch time, as number of CPUs could have changed since last boot.
Size is now enforced and height is always dynamically computed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23785 a95241bf-73f2-0310-859d-f6bbb57e9c96
(I guess frenchies are guilty here, as mmu_man's ThemeAddOn have the same disease...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23757 a95241bf-73f2-0310-859d-f6bbb57e9c96
#1542 is not fixed yet, as the crash happened in Mesa Software Renderer add-on first.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22573 a95241bf-73f2-0310-859d-f6bbb57e9c96
Make our DPC named differently to avoid this confusion.
Detected while testing our ACPI (which needs our DPC) under
R5...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21703 a95241bf-73f2-0310-859d-f6bbb57e9c96
* On these targets, we must load ACPI's modules dependencies ourself!
* Only the main B_ACPI_MODULE_NAME will work on non-Haiku targets, as
the (work-in-progress?) extra ACPI modules (ACPI_ROOT_MODULE_NAME, ACPI_NS_DUMP_MODULE_NAME,
and ACPI_DEVICE_MODULE_NAME) needs Haiku's Device Manager.
* "cat /dev/power/namespace" was successfully tested on a BeOS R5+Bone system.
* My P5W DH Deluxe-based system have a huge ACPI namespace ;-)
* A graphical ACPI Namespace Viewer will be welcomed (Hint)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21595 a95241bf-73f2-0310-859d-f6bbb57e9c96
For the moment, these two just does a quick check for nvidia or radeon drivers been loaded and running.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21229 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also prepare uname to return the build SVN revision number,
which will work only if I could figure out how to define it from Jamfile.
Or, better, in build/jam/BuildSetup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20023 a95241bf-73f2-0310-859d-f6bbb57e9c96
Pending DPCs at queue death time are now called too, to avoid possible leaks.
Meanwhile, queue_dpc() will refuse to add another DPC and returns B_CANCELLED.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19798 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixed most obvious issues, as reported by Marcus and Axel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19765 a95241bf-73f2-0310-859d-f6bbb57e9c96
Until, it's obvioulsy not ready for prime time: using it to queue AcpiOsExecute() event/method callbacks...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19761 a95241bf-73f2-0310-859d-f6bbb57e9c96
Hardware GLRenderers will surely needs to check which screen device (so which window)
a GLView beg him to render to as fast as possible.
Unless such hardware is not serving this screen...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19464 a95241bf-73f2-0310-859d-f6bbb57e9c96
std::map [] creates a new entry when none can be found!
* Disabled libmesa.a being build with DEBUG turn on, as it's broken ATM.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19357 a95241bf-73f2-0310-859d-f6bbb57e9c96
of Mesa framework (src/kits/opengl/mesa) and make
clearer here live the Mesa Software Renderer add-on for
Haiku's OpenGL stack.
* Renamed the class for the same reason.
* Changed the string returned for GL_RENDERER to
help sorting out Haiku's renderer add-on(s) from
Mesa3D BeOS ports's monolithic libGL.so renderer.
* Make the renderer context current if none is already. This fix
the need in GLInfo to call LockGL() before calling any
glGet*() calls, when it was not necessary under R5
(and Mesa3D beos ports)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19287 a95241bf-73f2-0310-859d-f6bbb57e9c96
Locking GL context is better, even if it's not mandatory under Be's R5 OpenGL stack.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19259 a95241bf-73f2-0310-859d-f6bbb57e9c96
But the default size is the view one, not the view's window size, which doesn't make much sense.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17798 a95241bf-73f2-0310-859d-f6bbb57e9c96
He published it on its web site and
made an annouce on our forums here:
http://www.haiku-os.org/forums/viewtopic.php?t=866
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17684 a95241bf-73f2-0310-859d-f6bbb57e9c96
On PPC, both dispatch.c and GLDispatcher.cpp were exporting gl* OpenGL API. Twice is not better, even when "none" was the previous state for PPC port ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17578 a95241bf-73f2-0310-859d-f6bbb57e9c96
Untested for non x86 architecture. Axel, could you check if it now build fine under PPC?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17532 a95241bf-73f2-0310-859d-f6bbb57e9c96
environment: actually build it! :-)
Next step: fix the Jamfile to create the symlink to userland "obos_network" add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17520 a95241bf-73f2-0310-859d-f6bbb57e9c96
Our libGL.so GLView is still a stub, drawing "No OpenGL renderer available!"
instead ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17406 a95241bf-73f2-0310-859d-f6bbb57e9c96
Philippe Houdoin