stored now.
* Extended the debugger message for B_DEBUGGER_MESSAGE_HANDED_OVER by the
causing thread.
* Also send B_DEBUGGER_MESSAGE_HANDED_OVER to the debugger to which the team
was handed over. The message will be the very first one the debugger gets
from the team in question.
* Some harmless refactoring (added thread_hit_serious_debug_event()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29302 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debugger commands to resolve usb_ids to pipes.
* Adjusted the physical memory allocator to be usable in a slimmed down mode
when running inside the kernel debugger.
* Implemented USB keyboard support for KDL through a kernel debugger add-on.
* Added kgetc() and made use of it where previously individual methods were used
to ensure that reading characters always goes through the kernel debugger
add-ons and the other methods.
This has some preconditions to meet though:
1) The keyboard must be in the boot protocol (currently the case but needs to
be revisited once we have a full usb_hid).
2) The keyboard must be attached to a UHCI root port (i.e. not use EHCI or OHCI,
also not through hubs unless those are USB 1.1).
3) the usb_hid driver has to be opened for this to work. This means that for the
time between initializing USB and when usb_hid is opened by the input_server
there is no keyboard support.
Also note that this has no way of detecting hot-plug, meaning that you can't
re-attach your USB keyboard from the hub to the root port once in KDL.
On the bright side of things, since this is a non-destructive mechanism it is
possible to enter and leave KDL without loosing the USB state.
Tested OK in QEMU, not tested on real hardware yet, will see in a few minutes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29291 a95241bf-73f2-0310-859d-f6bbb57e9c96
needed at all when used as intended. Thanks Ingo for the explanation on how this
is intended to work. Adjusted the overlay fs accordingly and updated/reverted
the changes to the other filesystems.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29250 a95241bf-73f2-0310-859d-f6bbb57e9c96
been mounted. This is to allow layered filesystems to setup internal data that
requires all the sub/super volumes to be available.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29248 a95241bf-73f2-0310-859d-f6bbb57e9c96
It causes the interrupt handler to be inserted at the very end of the list
instead of at the top. It is intended to be used as a workaround when a
interrupt handler cannot know if it actually handled the interrupt. This
should never be used by native drivers. Also if we know that the result is
not valid because of this flag we won't disable the vector in case we count
many unhandled interrupts as those numbers are then unreliable.
* Moved B_NO_LOCK_VECTOR to be a private flag as well.
* Made the interrupt handler list a simple manually maintaned singly linked list
instead of the doubly linked one used with insque and remque as it greatly
simplifies things for such an easy use case and is more compact.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29241 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
* Softer recessed frame for BMenuField to distinguish more from BButton
and make it slightly more similar to BTextControl.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29235 a95241bf-73f2-0310-859d-f6bbb57e9c96
overheard that they looked too ninety-ish.
TODO: The code behind this is work in progress. The basic idea
is to extract all drawing code into a new class BControlLook,
of which there is a global instance be_control_look, instantiated
in InterfaceDefs.cpp. At the moment, all the old drawing code is
still there, and the usage of be_control_look is inside if-bodies
checking the instance against NULL. In another words, by not
instanitating be_control_look, you can revert back to the old look.
BControlLook's job is to provide reusable methods for drawing
certain types of frames, backgrounds and labels, so that application
developers can make controls that re-use the same drawing code
as built-in controls and adopt to changes made there. I have added
the notion of "borders". Each of the frame drawing methods can be
made to draw certain borders only, which is supposed to help when
controls shall visually attach. This feature is not fully explored
at all ATM.
TODO: Update BColumnListView header view and BStringItem text
spacing. Update other apps where it makes sense to use BControlLook.
For the moment, only Tracker and LaunchBox are updated. More...
NOTE: The new look is not very radically different, so that existing
apps do not immediately look too ugly or out of place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29221 a95241bf-73f2-0310-859d-f6bbb57e9c96
Renamed BGradient::color_step to BGradient::ColorStop
as it's called everywhere else. Also renamed BGradient::gradient_type
to just BGradient::Type. Renamed BGradient::Type() to GetType().
* Simplification of method names in Painter.cpp. Some not yet
complete and yet inactive code to accelerate vertical gradients
(bypassing AGG for this special case).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29214 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Remove the previous method of applying the overlay by flags. In the future the
overlay can just be mounted as a filesystem layer. This is probably how layers
were intended to work in the first place.
* Move the filesystem module info and filesystem name from the fs_mount to the
fs_volume structure. Filesystem layering is done by having multiple layered
volumes and we want to be able to have a different fs per layer.
* Adapt VFS code to this move.
* Implement mounting layered filesystems. Specifying multiple filesystems
separated by a colon on mount will cause the layers to be set up and the
corresponding filesystems to be mounted at that layer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29199 a95241bf-73f2-0310-859d-f6bbb57e9c96
node. That is needed for a layered filesystem to be able to construct a full
fs_vnode out of a volume/inode pair.
* Adapt places where get_vnode is used. Sadly this is a C API and we can't just
use a default NULL for that argument.
* Introduce a flag B_VNODE_WANTS_OVERLAY_SUB_NODE that can be returned in the
flags field of a fs get_vnode call. A filesystem can use this flag to indicate
that it doesn't support the full set of fs features (attributes, write support)
and it'd like to have unsupported calls emulated by an overlay sub node.
* Add a perliminary overlay filesystem that emulates file attributes using files
on a filesystem where attributes aren't supported. It does currently only
support reading attributes/attribute directories though. All other calls are
just passed through to the super filesystem.
* Adjust places where a HAS_FS_CALL() is taken as a guarantee that the operation
is supported. For the overlay filesystem we may later return a B_UNSUPPORTED,
so make sure that in that case proper fallback options are taken.
* Make the iso9660 filesystem request overlay sub nodes. This can be fine tuned
later to only trigger where there are features on a CD that need emulation
at all.
If you happened to know the attribute file format and location you could build
an iso with read-only attribute support now. Note that this won't be enough to
get a bootable iso-only image as the query and index support is yet missing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29177 a95241bf-73f2-0310-859d-f6bbb57e9c96
support _POSIX_VDISABLE at all. It's even questionable whether the value
(unsigned char)-2 is a good choice.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29137 a95241bf-73f2-0310-859d-f6bbb57e9c96
add the const in any case. As Axel points out these are C functions and we do
not affect binary compatibility by changing their signature.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29124 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enable -Werror on GCC4 builds as well (limited to the same selected targets).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29118 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Replaced the use of offsetof() for structs that aren't PODs. Add a
offset_of_member() macro to util/khash.h because that's what it's used for
in our cases.
* Change the signature of add_debugger_command()/remove_debugger_command() on
GCC > 2 to avoid the depricated conversion from string constants to char *.
* Adding some "suggested" parenthesis. I know that not everyone likes that, but
it pointed out at least one bug that is fixed here as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29113 a95241bf-73f2-0310-859d-f6bbb57e9c96
* DoLayout did not work as expected, after the call
the scrollbars would have an 1px offset inside the target
* the target needs to be resized while setting a new border, otherwise
it would overlap the border and give some drawing artefacts
- I'm still unsure if the behavior change introduced with the layout stuff is nice
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29103 a95241bf-73f2-0310-859d-f6bbb57e9c96
- This means that buffers with a initial size of 0 work now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29006 a95241bf-73f2-0310-859d-f6bbb57e9c96
build. I sure hope that this doesn't break the build for anyone else.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28992 a95241bf-73f2-0310-859d-f6bbb57e9c96
bug #2237. Thanks!
* Cleaned up the file a bit (removed the _P() and fixed indentation).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28961 a95241bf-73f2-0310-859d-f6bbb57e9c96
register. Therefore "cc" should be added to the clobber list. Adding that here
as it's part of a patch attached to the freetype bugtracker.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28945 a95241bf-73f2-0310-859d-f6bbb57e9c96
constraint, so I replaced it with a "d" input and "=d" output constraint
instead, which should be equivalent. Please yell if my logic is flawed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28944 a95241bf-73f2-0310-859d-f6bbb57e9c96
- This has the side effect that now it actually works.
- This also indirectly fix BNetEndpoint usage of BNetBuffer.
- Added DynamicBuffer (the underlying buffer implementation) to the Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28928 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Default buffer size is now set to 1 instead of 0, which would cause the
construction without a given size to fail.
- Added copy constructor.
- Changed _GrowToFit() to have a boolean parameter to indicate if we want
to resize the buffer to an exact size. Used by the copy constructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28924 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Will be used by the new (R5 compatible) NetBuffer class.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28918 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is a very welcome addition.
* There are a few issues, and maybe questionable decisions (like the dependence
on ACPI), but I see no reason why it shouldn't be added in its current form
already.
* Unfortunately, I could not test it yet, though, as the CPU of my laptop is
not supported; will see if I can find a supported hardware, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28903 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implementing dirname and basename
I removed dirname from glibc/misc and reimplemented in order
to (hopefully) keep thing tidy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28888 a95241bf-73f2-0310-859d-f6bbb57e9c96
* whitespace cleanup, etc
* some renaming to fit Haiku style
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28856 a95241bf-73f2-0310-859d-f6bbb57e9c96
old invalid user listeners yet, though (ie. if a team dies).
* Implemented userland network monitor functions.
* Added a few notifications to the network stack, even though this part isn't
complete yet (especially notify_interface_changed()).
* Added optional debug output to the notifications module.
* Added the module to the image, it basically works now (tested).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28825 a95241bf-73f2-0310-859d-f6bbb57e9c96
