For mouse probing to work reliably, it's important that we don't
simultaneously send commands to the keyboard as well. This normally
happens because we don't publish the keyboard device until the probing
is complete.
However, if the mouse probing results in the keyboard sending some
replies, this can be detected as a "hot plugin" and leads to publishing
the keyboard device a lot earlier.
To prevent this, disable the "hot plugin" feature until we are done
initializing. This way the keyboard device is published only after we
are done with the probing.
Fixes#17806
Change-Id: Ia6a2b031550c845fa305df5b5f4d513d5c7931d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5388
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Before this patch, calling functions in the `printf` family and
passing %F in the format string, such as
printf("%6.2F\n", 580.0f);
would incorrectly output numbers in the exponential format:
5.8D+02
This patch fixes the output for this situation:
580.00
and fixes the behavior for programs that use %F, such as
several tests for the `fish` shell.
Change-Id: I124a5a7b93b5f551fa190501a5778726812d347c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5424
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This is for platforms where information from parsed ACPI namespace
is necessary to fully configure PCI subsystem.
Change-Id: I8bdcfab6b99cbe7fdbc902b9fc13b44133325961
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5273
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Previously, any accelerants failing would cause an
app_server crash.. so we would do everything in our
power to get "something"
* After hrev56252, the app_server properly handles
accelerant failures and vesa / framebuffer accelerants
should will be used.
* Thus, if no monitors were detected (due to none being
plugged-in, or some other fault), bail and return B_ERROR
so vesa fallback can give it a try.
Change-Id: Ib9695dd7cf1914e50547ca8661c55b80152a66a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5442
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
As far as I can tell, nothing checks these, so this should not
actually make any kind of difference.
The timeout_set change is also not a functional one, either,
as callout_init with mpsafe=0 uses &Giant also.
* Do not open() devices while looping but only open() the one
we were actually asked to open.
* Try the VESA or Framebuffer driver even if deviceNumber is something
other than 1.
* Start iterating at 0 instead of 1 following loop iteration changes.
Ideally this iteration should occur a completely different way, in order
to properly support multiple graphics cards, but that's a problem for
another day.
Fixes#4303.
AccelerantHWInterface and the Remote engines already did this.
These are not used at all outside of test_app_server, so we do not
need to even compile them in to the regular one.
Some syscall headers are generated during the build process, and jam is
not smart enough to add an automatic dependency.
Change-Id: I7c19da7aca9da4a52c4537a5f5c279fdbe24a48a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5435
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Set a flag if TFilePanel::RestoreState successfully reads the
FilePanelSettings file.
* Check for this flag in BFilePanel::Show.
* Part of #17374.
Change-Id: I4431c01f9282fe411fa7b30667215bba9249bd96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5433
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The referenced section of the specification gives no indication that
the bit should not be set if there was no data; indeed it indicates
it should always be set.
This brings our behavior here in line with other OSes seem to do.
Change-Id: I86b2eb2a6a5fa3af84fd0941e0a3ec601c7037bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5421
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
While pipe() only supports a read end and a write end, named FIFOs
are supposed to allow opening in read/write mode (which, indeed,
is something the Fish shell seems to require.)
The code that checks open_mode in the read/write routines was introduced
all the way back in 2003 (2469f26dfc).
At that time, the VFS did not do open_mode checks on FDs in the
I/O syscalls, so these doubled as permissions checks. Now, however,
the VFS does check that in common_user_io, so we can remove these
entirely and let things behave as they should.
Additionally, there is now also no reason to prevent select()ing
on both events for the same FD independent of open_mode, so
allow that too.
Change-Id: Ib3cba76d18e91b7c00d1695e8d29dd47cae06b79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5427
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Page directory physical address must be aligned on 16K and
it must be mapped to a contiguous physical region.
Change-Id: I6723023c9deaa1c4a1081cf5a984a1766241a532
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5423
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* instead try to guess the type, find the app, and launch the app with the document refs.
* fix#5783
Change-Id: Icd25a81ff28038fec0494045390edc6271433b07
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5425
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... to explain hrev562209 by Jim906 which fixes#17733
StyledEdit: give initial focus to the TextView
No functional change
Change-Id: Id428290d8d3530e5ef9213489625c1968984d323
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5422
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: nephele <nep@packageloss.eu>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
