the "User" part of the way more often used UserFileSystem and the other
classes that had it accordingly for consistency.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20237 a95241bf-73f2-0310-859d-f6bbb57e9c96
FS interface. Adjusted old hooks, but didn't add the new ones yet. The
module builds now at least.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20235 a95241bf-73f2-0310-859d-f6bbb57e9c96
Sweet cracker sandwich! I actually figured out something for a Jamfile on my own -- it took a while to figure out how to link against the app_server. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20213 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes bug #1029, though make sure to use BGL_ALPHA flag with BGLView constructor
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20201 a95241bf-73f2-0310-859d-f6bbb57e9c96
the code is now very compact, on par with other Mesa drivers
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20172 a95241bf-73f2-0310-859d-f6bbb57e9c96
updated the mesa software addon to work again (maybe would need more work)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20137 a95241bf-73f2-0310-859d-f6bbb57e9c96
when the new attribute data was too large to fit into the small data section at all.
This fixes the Trash icon update with a block size of 1024 bytes.
* This also fixes a bug where AddSmallData() required you to write back the inode even
if it failed with B_DEVICE_FULL, but no one did it.
* _RemoveSmallData() no longer requires you to write the inode back on success.
* Made most small data methods private.
* WriteAttribute() now tries to put the data into the small data section even if it
existed as a separate file before (the file is then removed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20103 a95241bf-73f2-0310-859d-f6bbb57e9c96
the timer functions could access invalid memory.
* The endpoint manager now panics if a bound endpoint is not in the hash.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20100 a95241bf-73f2-0310-859d-f6bbb57e9c96
which wasn't enough when tampering with the inode's data, and it also acquired that
lock too late.
Thanks to Stefano for pointing this out.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20079 a95241bf-73f2-0310-859d-f6bbb57e9c96
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20072 a95241bf-73f2-0310-859d-f6bbb57e9c96
Semaphore::ZeroCount() on new semaphores, not on used ones. Found by Stefano, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20052 a95241bf-73f2-0310-859d-f6bbb57e9c96
by Jon Watte.
This was a tough but interesting problem. My version still isn't quite as nice
as his. I think the color generation could be improved, and I KNOW the x and y
placement of the text could be improved.
I also think it would be nice to display the full message at the bottom of the
screen (similar to ShowImage showing the file type and name in full screen
mode.)
But this is a good base to work from.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20035 a95241bf-73f2-0310-859d-f6bbb57e9c96
I'm considered splashing it up a bit by adding parameters for colors, etc, but
this will make a good baseline.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20005 a95241bf-73f2-0310-859d-f6bbb57e9c96
So the mechanism with the global variable did not work for R5 what caused two USB stacks and host controller drivers to be active concurrently which resulted in completely unpredictable results.
This kind-of-inelegant fix was all I could come up with, if someone has a better idea please send it this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20003 a95241bf-73f2-0310-859d-f6bbb57e9c96
2048 bytes. This should fix bugs #993 and #997.
On BeOS R5 asking for 2 bytes too much wasn't a problem, as we
only need the first page_entry, and it didn't return any Error.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19992 a95241bf-73f2-0310-859d-f6bbb57e9c96
crashes at a later time. I observed one error at 8033a802, but the address
was allocated by the driver and should have been fully locked.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19988 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold