controller. The device doesn't use the PCI_ide subclass (but
PCI_mass_storage_other) and requires not using compatibility mode. Otherwise
it's pretty much the generic_ide_pci driver.
* Directly adding the driver to the image.
This driver could either be merged into the generic ide driver so it supports
not quite standard devices, or this could be made into a driver that collects
all those non standard devices. Either way, this works for now and lets my
machine boot off the IDE drive :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25868 a95241bf-73f2-0310-859d-f6bbb57e9c96
the parent bus. It is possible that there are other busses below the root
bus and we must therefore always iterate through the child devices when
searching for a device with a bus unequal to our own. Otherwise devices for
non-null busses could not be found which would lead to crashes in operations
involving them.
* Adding a panic in case finding a device failed as this should clearly not
happen.
This probably fixes bug #2293 and might affect #2284 too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25867 a95241bf-73f2-0310-859d-f6bbb57e9c96
still open transfer has enough time to cleanly exit with error. Fixes a crash
when removing a device while a control transfer on the device endpoint was
open and would have timed out otherwise.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25863 a95241bf-73f2-0310-859d-f6bbb57e9c96
the same name but different path. In case of usb_disk that is now loaded as
a boot module the driver got registered with a different path, which prevented
later rescans from working. USB mass storage should now work again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25862 a95241bf-73f2-0310-859d-f6bbb57e9c96
prevents deadlocks in cases where a new transfer is scheduled from within the
cancel callback. This is an edge case, as generally you don't want to schedule
anything when explicitly canceling transfers, but there are a valid use cases
when you cancel because of a timeout and then have to reset the device for
example. Note that this hides bug #2353, where the cancel case is probably
not handled correctly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25861 a95241bf-73f2-0310-859d-f6bbb57e9c96
what the ports of a team are up to without having to go through each port
individually.
* Enlarge the port id column so even large ids fit nicely.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25857 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix using fScreenAndUserClipping directly in CopyBits() that could crash
when in fScreenAndUserClipping wasn't used (when there's no user clipping
for example).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25856 a95241bf-73f2-0310-859d-f6bbb57e9c96
get drawn into a window with random colors. With that one can for example add
code to the app_server or interface kit classes that push through rects or
regions to see what exactly is going on in drawing operations. Code examples
of how to use are at the top of the file. Has fixed window dimensions though
as I was lazy :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25855 a95241bf-73f2-0310-859d-f6bbb57e9c96
clipping region pointer.
* Provide _ScreenClipping() that only includes local and screen clipping but
not user clipping.
* Provide ScreenAndUserClipping() that returns screen clipping if no user
clipping is present, or returns a combined region that is then cached.
* Adapt all places where the former methods are used and decide which one to
use depending on the relevance of user clipping.
User clipping is now ignored for background clearing and when determining
whether or not to call Draw() on a view. This should make Haiku behaviourally
compatible with BeOS (confirmed by the ClippingAndRedraw test app) and should
also fix the Firefox redraw issues. Stephan please review!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25854 a95241bf-73f2-0310-859d-f6bbb57e9c96
(or at least incompatibly) uses the user set clipping region when determining
whether or not to call Draw() on a view. Under BeOS when a some part of a view
is exposed it will always trigger a Draw(), even if the current clipping region
disallows drawing in the supplied update rect. Under Haiku however the view is
not considered for an update when the current clipping region does not
intersect with the newly exposed area.
Running this test app from the Terminal this behaviour can be seen. When
clicking inside the window a floating window pops up. When clicking again it
goes away and triggers a redraw. When hitting a key, a clipping region is set
that does not overlap with the floating window. After this clipping is set,
the view does not get any Draw() call anymore when the floating window goes
away.
This is the reason for the redraw issues in firefox, as firefox uses the
clipping region to constrain its asynchronous drawing, but does never reset
the clipping to NULL. As firefox just collects the update rects in Draw() and
then draws the contents itself, once the clipping region is set, many of the
Draw() calls don't get called and the interface parts are never redrawn.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25853 a95241bf-73f2-0310-859d-f6bbb57e9c96
play any more clips." Of course I was searching in my own commits. In the
end, I resorted to binary searching revisions for when this broke. Turns out
it is your change r25793/r25794, in which you forgot to attach the colorspace
to the app_server message. Which of course makes it lock up. Another of those
instances where you think passing data structures between client and app_server
instead of this "protocol" would be the better idea...
* Fixed bitmaps_support_space() retrieving the currently supported overlay
flags for a given color space. This makes MediaPlayer play files again, the
media node connection would time out because of the broken app_server
communication. (I have not tested this change yet, but I will in a minute, on
a different computer.)
* Also retrieve the overlay supported flag for YCbCr colorspaces.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25847 a95241bf-73f2-0310-859d-f6bbb57e9c96
should make default images bootable from USB automatically. DDing one to a
USB stick should work out of the box then (but this wipes the stick of course).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25836 a95241bf-73f2-0310-859d-f6bbb57e9c96
volume labels at all.
* Use the common function in both identifying and mounting the volume so the
name is in sync between what the disk device manager got through scanning and
what Tracker gets through reading the fs stat.
* Strip trailing spaces from volume names in all places.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25828 a95241bf-73f2-0310-859d-f6bbb57e9c96
itself to (0,0), and broke further item width computation. We now use the parent view width (BarView) instead. This fixes#471
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25826 a95241bf-73f2-0310-859d-f6bbb57e9c96
