* Renamed i386_context_switch() to x86_context_switch().
* x86_context_switch() no longer sets the page directory.
arch_thread_context_switch() does that explicitly, now. This allows to solve
the TODO by reordering releasing the previous paging structures reference and
setting the new page directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37024 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed vm_translation_map_arch_info to X86PagingStructures, and all
members and local variables of that type accordingly.
* arch_thread_context_switch(): Added TODO: The still active paging structures
can indeed be deleted before we stop using them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37022 a95241bf-73f2-0310-859d-f6bbb57e9c96
That makes the automatic stack traces in case of kernel panics work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37021 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Remove the options panel, and the "-o, --options" switch, put all options
inside the main panel as discussed in ticket #3831.
- Add a "Copy to clipboard" button, as discussed in ticket #3831.
- Add a "-c, --clipboard" switch to quickly copy a screenshot to the clipboard
without launching the GUI.
- All settings apply directly to the current schreenshot as well as new
Screenshots, as discussed in ticket #4100.
- Separate executables for the CLI (Screenshot) and GUI (ScreenshotApp).
When "Screenshot" is launched it runs in the background, and launches the
GUI (if not run with the -s or -c switch) before quiting itself. When a new
screenshot is requested through the ScreenshotApp GUI interface,
ScreenshotApp launches Screenshot before quiting itself, after which
Screenshot re-launches ScreenshotApp. This fixes ticket #4100.
Note that because of this change the deskbar entry will show "ScreenshotApp"
and not "Screenshot" as might be expected. I am not sure if this is a
problem.
- Fixed the code that determines the active window because it was just finding
the top most window. This change fixes tickets #3112, #4878, and #4423.
- Hide the cursor by calling BApplication::HideCursor().
This fixes ticket #2988 (but *not* #2997).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37017 a95241bf-73f2-0310-859d-f6bbb57e9c96
vm_translation_map_arch_info to X86VMTranslationMap where they actually
belong.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37014 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added quirks for idt 0x76b2 and apple macbook 0x00a1
* add headphones to the output path in case one input has a path to a used output
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37012 a95241bf-73f2-0310-859d-f6bbb57e9c96
vm_free_unused_boot_loader_range(): Don't free any memory beyond the given
range.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37010 a95241bf-73f2-0310-859d-f6bbb57e9c96
even have to be available in the generic case. See bug #6105, patch 1 & 2.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37007 a95241bf-73f2-0310-859d-f6bbb57e9c96
warnings, but also some oversights from earlier changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
that are wide enough for both virtual and physical addresses.
* DMABuffer, IORequest, IOScheduler,... and code using them: Use
generic_io_vec and generic_{addr,size}_t where necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Select() didn't actually reselect even when asked to force things from AddMessage(), making the uploaded mail get an off-by-one unique id assigned and a second copy downloaded on subsequent fetching, though this would really need proofreading as I'm not really sure how it all works,
- the allocated buffer wasn't freed, making mail_daemon allocate 650MB, which obviously crashed when out of physical ram, now it only uses 15MB :p,
- try to find workable IMAP flags for sent and pending mails, or use custom ones when the server allows arbitrary flags,
- the LIST command wasn't checked for correct response, making subsequent commands like CREATE mailbox fail from the OK answer of previous ones when syncing on a new accound,
- try to read the creating time (actually modification time since creation time is reset when copying files around) and pass it to APPEND command so I won't get the whole 10000 mails all received as of today.
Now I can put all my old mails on an imap server (tested on dovecot) to read it from other OSes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36995 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debug output to test_capacity().
* Minor other cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36990 a95241bf-73f2-0310-859d-f6bbb57e9c96
capacity by trying to read at the end of the medium.
* Not tested at all yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36989 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Internally, moved the contents of periph_io() into a static read_write()
function, and use it from the new periph_read_write() as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36988 a95241bf-73f2-0310-859d-f6bbb57e9c96
of having the logic be triggered by IOScheduler::SetDeviceCapacity(), as that
one might actually be called more often (for each call to update_capacity(),
ie. each B_GET_GEOMETRY/B_GET_DEVICE_SIZE will trigger it), and there is no
reason to throw away the cache every time (will make a difference during
partition/file system detection).
* In cd_init_device() just call update_capacity() instead of duplicating its
code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36986 a95241bf-73f2-0310-859d-f6bbb57e9c96
gradients are the same as in other HAIKU logo files. The fourth leaf is using
the blue colors from the Walter logo at www.dauwalder.net/OpenBeOS/walter.html
The ideal intention is that this will help create an "Open Use Logo"; similar
to the ideas in http://wiki.debian.org/ProposedTrademarkPolicy
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36974 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added HAIKU logo - white on black, which is based on the boot logo
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36970 a95241bf-73f2-0310-859d-f6bbb57e9c96
