Based on usb_ecm and other native USB ethernet drivers which share a
similar structure.
References used to implement this:
- FreeBSD urndis driver
- [MS-RNDIS].pdf v20140501
- Microsoft list of RNDIS OIDs
TODO:
- Better handling of "request id" field to make sure the replies we get
match up with the requests we sent, and it could allow to have
multiple requests in flight. However, the FreeBSD driver doesn't
bother to implement this, if you only ever have one request in flight
and wait for a reply before sending another, this isn't really needed.
- Endian safety, this code will only work on little endian systems for
now. Several structures sent/received to/from the device must be little
endian, so on big endian platforms a lot of byteswapping will be needed,
or the code rewritten to use some smarter object and not a plain
struct for all of these.
- Investigate if it's possible to send/receive multiple ethernet frames
in a single USB transaction for better performance. Our driver
structure doesn't really allow for it unless the driver implements
some buffering on its own.
Change-Id: I2c6dacf0c1aeb6c7c1c112e9b16a63e586ea979a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5281
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
In a previous commit I flipped this around because the command interrupt
doesn't always trigger on Ricoh controllers. However, this leads to
command execution continuing before the interrupt actually triggers on
some other controllers.
Might solve #17031 but it could also break things on other hardware.
Change-Id: I96cba90358f0b04ef1ac319aead898c0f4155114
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4985
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
I changed the way we decide which registers to use in a previous
patch review but I changed it in only one of two places. As a result
we were using the old code with the new registers, resulting in invalid
backlight settings.
Should fix#17692
Change-Id: I4e977d5700d3a002986beafff5ca511673c86540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5185
Reviewed-by: Richard Zak <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
- Newer devices use a different layout for the backlight PWM registers
- Get the min brightness level from the BDB
Change-Id: I99745a022dd38733a4c2386f91c4c57016dd2acd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5162
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Internal display on my laptop isn't detected yet so modesetting doesn't
work, but at least I get vblank interrupts and backlight control.
Fixes#17569
Change-Id: I86dd56bc3fc2c288688242e34d9220028036ab74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5156
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
The revision 1 structure should have 21 items, but on my laptop, it doesn't.
That's fine, we can parse it as if it was a revision 0 structure. This way I
can see the battery status on my machine.
Change-Id: I743173e05318d686049454983e378a08c0a1980a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5155
Reviewed-by: waddlesplash <[email protected]>
This is a bit excessive: a file with a B_MINI_ICON resource of the wrong
size should not result in crashing Tracker, the resource should simply
be ignored.
Fixes#17668.
Change-Id: I55a210eb829e568d254d8ab569720145c0ea5a09
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5115
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Yet another 16550 clone under a different name. Why does device-tree
have a "compatible" setting if everyone puts a different name for the
same thing?
Change-Id: Ia889a527a36739df747ba48d4606c09764703607
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5103
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
They were hardcoded to 2, which is not correct on all devices. As a
result, getting addresses and sizes on pure 32bit devices would fail.
Change-Id: Icf542c9e8d6b7136219014fe08dd601387de4762
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5102
Reviewed-by: Fredrik Holmqvist <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Some improvements to allow setting 8, 15, 16 and 32bit modes, and detect
the correct mode number after patching the BIOS automatically, instead
of hardcoding it.
Also move the patching code to a separate file.
Fixes#10570.
Change-Id: I920f448b59ad7373cb8595d92ce3fa52324be67e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4629
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This uses atombios headers to find where in the BIOS the video mode
tables is located. Then, we can replace entries in the table (in a RAM
copy of the BIOS, of course) and inject any video mode we need. To make
the table easy to find, the Atombios headers from the radeon_hd are
reused, but no atombios code execution takes place here.
Change-Id: If1981b1574822d4ce1e072dd6437a727192ce7cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4628
Reviewed-by: waddlesplash <[email protected]>
Get the OEM string from the VESA info block (and also get the memory
size from there while we are at it). If the string is empty, use the
BIOS type (identified in other ways) to still report something.
Change-Id: I8cbd75d19f624a43db05e82d1e1b2a536cc418b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4625
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The VESA standard does not define any way for software to set a custom
video mode, which means normally we would be constrained to whichever
modes the video card manufacturer decided to provide. However, since we
run the BIOS in an emulated environment, it is possible (and even quite
easy) to patch it and inject any video mode we want, provided we know
the format to use and where to put the info in.
This approach was used in the NewOS VESA driver, as well as in
915resolution (a tool that predates the availability of native drivers
for Linux for Intel videocards). Later on it was also used in Chameleon
and Clover, bootloaders that are used for hackintoshes (running MacOS on
unsupported hardware).
This commit implements full support for Intel cards only, AMD and NVidia
will be added later (but there is preliminary code to detect them)
Change-Id: I2c528ba18b3863f486da694860a10761efcbfb3f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4624
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
MSI was never implemented in this driver and only used for a log during
initialization. Remove it for now.
This makes it easier to use the driver on non-x86 systems where there is
no MSI.
Change-Id: I39ccbb82b78ea98c0d045ef07ee9bb28c775e292
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4847
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
This reverts commit d493aae3c4.
The default shine and shadow color are pure black and white. They are
not meant to be used directly, but mixed with the background color for
more subtle results.
The previous code using tint_color was also just fine.
Fixes#17577.
The stat structure fields are not standardized, so we can't use an
hardcoded field name. The code in all other places was already adjusted
with a macro to handle the access, but hrev55802 introduced a new place
where we need to read the access and modification times. Use the macro
there as well.
Thanks to anuragpd4 for reporting the problem!
Regression caused by refactorings in hrev55348.
The logic for deciding when to use a built-in tracker icon was changed
incorrectly to ignore attributes on directories, trash, etc (anything
but executable applications). So the built-in icon was always used.
This commit restores the previous logic.
Shoud fix#17320 and #17371
Change-Id: I51ba22db59a8b6dd2bd1121b56c753ed47224c57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4841
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This partially reverts commit cc0226fad0.
This commit caused high CPU usage in app_server. The double buffering in
ActivityMonitor is not to avoid flickering, it allows to draw just a few
pixels of the the curves at each update, and reuse most of the bitmap
from the previous run.
Removing this means all the curves are fully redrawn at each update,
resulting in higher CPU usage (one core at 30% on my machine with 5
different graphs).
Keep the part of the changes removing code for custom background
drawing. B_TRANSPARENT_VIEW flag can be used instead.
Change-Id: Ie3438ca634c934f3e96ce5f7ad71ce7b3a435013
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4833
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Axel Dörfler <[email protected]>
Skip pixels with a coverage of 0. Since the source alpha channel is
ignored, we would otherwise cover pixels that shouldn't be.
Fixes#17449.
Change-Id: I373672a765b99efce5dceed4ffa81741f78b9d9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4836
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This code was written with wired ethernet in mind, where changes are
rare. However, on wifi the "media" changes all the time (switching
between different connection speeds). So, only log linkup and linkdown.
The other events are not that important.
Change-Id: Iaafb74ceb05a59dedf94184eee23a4e81fa5e983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4827
Reviewed-by: waddlesplash <[email protected]>
- Number of retries could overflow. If we retry something more than 255
times and it fails, just stop, instead of flooding the network with
bogus requests
- The timeout could also overflow. It was stored in microseconds in a
time_t, which allows a bit more than an hour. This is fine for the
initial timeout (which starts at a few seconds and will go up to 64
seconds), but after that we switch to a slower rate driven by the
"state time". In particular, this can be the lease time, which DHCP
servers may set to several days, or at least easily more than an hour.
- The computaiton of the timeout in the "slow lease" case attempted to
do "not less than a minute", but missed a conversion from microseconds
to seconds so it ended up doing "not less than 60 microseconds"
The combination of all these things means we can end up with a negative
timeout, and we will send a burst of requests without ever stopping,
flooding the network.
Change-Id: I0eb811c90f4a4dd8c9d92bff728bc2bbb52fbd56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4826
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It is now at https://review.haiku-os.org/admin/repos/jamfile-engine
This was added in the Haiku repository in the intent of adding it to
release images, a long time ago. Now with the packaging system in place,
there is no reason to host it in the main repo anymore (and it was never
actually packaged anyway).
I also added a recipe at haikuports for it.
Fixes#5360.
Change-Id: I4f2a1529cbadf7af8a16025c30a1332108475807
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4720
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
I found this at the bottom of my TODO list…
- UdpDomainSupport methods were referring to the object through a static
variable when they could just use the "this" object instead.
- Use BAutoDeleter to simplify the code a little
- Style problem (missing != NULL in pointer check)
- Move referencing of domainSupport in _GetDomainSupport instead of
OpenEndpoint. This way the two _GetDomainSupport methods both return
an already referenced object
Thanks to Axel for the code review and sorry for the super late reply.
Change-Id: Ic50ebb1a63a203d5aa393d28f4631c345acacc79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3908
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Some symbols were available because they were reexported by haikuwebkit
1.8.2, but they won't be exported anymore in the next releases. So we
need to link to libnetservices.a directly, and link to it before the .so
files to make sure the symbols from the static library are used.
If there are undefined symbols, we can't load the kernel (the bootloader
complains about missing relocations). It makes sense to not allow that
at compile time.
Change-Id: I430bebada16544ffa8be293cd6c075338970d8ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4668
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: X512 <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
In most cases we don't need to use the complete display_mode struct and
we just need the timings. This will avoid future confusion between the
virtual width/height and the actual display timings, if we implement
scrolling someday.
Change-Id: I6c4430b84130b956a47ea0a01afb0843f5a34fd2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4665
Reviewed-by: waddlesplash <[email protected]>
Apparently my comment about the width and height being swapped in this
register was not visible enough, so I make it a bit more obvious by
adding some uppercase.
Change-Id: I27621032d071ed09f82aa109f37482178351db04
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4664
Reviewed-by: waddlesplash <[email protected]>
On Sparc Openboot, we get allocated a stack of only 8 kilobytes, and
each called function costs at least 176 bytes for the stack frame.
This means we need to be more careful than usual about stack usage. Move
some large-ish allocations off the stack by either making them static,
or allocated dynamically.
Add a compiler flag to error on functions which use too much stack. The
threshold is at 1023 bytes, because that's what allowed me to find the
two functions that were causing a stack overflow (open_from and
_ParseActivatedPackagesFile)
Change-Id: Ia0d13a9247e1a3fff4ce654bdffd6edb16e7cbc7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2371
Reviewed-by: waddlesplash <[email protected]>
These are helper functions for long double math. On sparc there is no
hardware implementation of long double instructions, and the ABI defines
these methods which must be part of the C library. GCC calls the methods
directly in its generated code.
They were already added to libroot, but they also need to be in the
stub, which is used during bootstrapping to link mpfr (during the
target gcc build).
I put these in a separate file because I assume the generation of the
stubs file from the real libroot.so will usually not be run on sparc,
and will not include these symbols otherwise. This may become a problem
if libroot for different architectures starts to diverge further.
Change-Id: I6070394c685fee35b3dc12a507f5a6271571b993
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4636
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Most importantly include zstd, which is a new requirement for the
bootstrap build.
Change-Id: I981401e7d70fb7e1befaf7fc37f2fddc6d7e327d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4635
Reviewed-by: waddlesplash <[email protected]>
This is an internal ICU library, used by their command line tools only.
libbe (or anything in Haiku sources) does not need to link to it.
Change-Id: Id322572c6833c225d5501a7e9520dd3dc82934f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4634
Reviewed-by: waddlesplash <[email protected]>
The code in this module was derived from the one in driver/tty. However,
the driver uses a shared lock between the master and slave side of a
TTY, and this was changed to use two separate locks. The approach with
two locks does not work. It seems the change was unfinished and the
second TTY was never locked. But attempting to lock it will result in
lock inversion problems, unless we do complicated things (try to find
which of the two TTY is the master side, and lock that first, for
example). It is simpler to restore the shared lock as used in the
driver.
To set up the shared lock, I modified the tty_create function to take a
pointer to the master TTY when creating the slave. Maybe it makes more
sense to create both sides in the same call, create_tty_pair?
However, this does not work as easily as I wanted, because there is some
recursion going on: at least in one case, the tty_control function is
calling the driver's tty_service function, which in turns attempts to
call back into tty_control for the "other side" TTY. To handle this
case, replace the mutex with a recursive_lock.
Fixes#17091, where the root problem was access to
other_tty->select_pool without locking. This was also made unconvenient
to debug because select_pool objects are self-deleting, when the last
item in the pool is removed. As a result, the code accessing it without
log would suddenly find out that the data it was accessing had been
freed and erased.
This also makes the TTY code in driver/tty and generic/tty a bit more
similar than it was before, and brings us one step closer to merging the
two together. There are still two main differences and I don't know
enough about TTY to decide if they are important, and which version
should be kept:
- The driver has extra code for "background" read and write. I don't
know what this is used for.
- The driver has a single "settings" instance shared by a master and
slave TTY, while the module has two separate instances, but seems to
copy one to the other. I'm not sure which approach is correct.
Change-Id: Ie2daddd027859ce32ba395af76b4f109f8b984b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4604
Reviewed-by: waddlesplash <[email protected]>
There is no need to construct and destruct nested objects. The new and
delete calls on the struct will take care of it. However, some fields
have C functions for construction/destruction and these should be
called.
Change-Id: I09d5930f499ef3fa4ff580d482c682172b00b6a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4603
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Currently I'm trying to debug things using the generic tty module, and I
can't use the command from the driver for that. I hope someday the
driver and module will use the same structure for the ttys and can share
the same command...
Change-Id: I167dab600ac8567368604f9b6463f787857f4d20
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4602
Reviewed-by: Jérôme Duval <[email protected]>
The tty module started its life as a copy of the driver, and they
diverged over time as fixes and refactorings were not always brought to
both sides.
This commit does not improve the situation, but it tries to make the
two versions of the tty_private.h and tty.cpp files as similar as
possible to ease comparison.
Change-Id: I62255262b167ab81c9a0619c8f19b36b1a165fad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4601
Reviewed-by: Adrien Destugues <[email protected]>
- All network add-ons are now built with Werror, collapse the list to a
single entry
- Add a few busses add-ons that were not listed (to be checked and fixed if
needed)
When a library is not found, it is useful to know why it was linked in
by showing the previous link in the dependency chain. We had the
information available, but did not use it in the error message.
These were used in function_remapper.cpp but can be used elsewhere too,
so move them to a private header. Also use them for the stack protector
hidden function definition (probably not so useful since gcc2 doesn't
support using the stack protector anyway?).
The gcc2 way to make a symbol hidden is to manually generate the .hidden
directive in the assembler output. This is not perfect: it is hard to
use for C++ functions and methods (manual mangling of the name is
needed), and inline assembler can only be inserted inside functions. But
the alternative is patching gcc2 to add support for the function
attribute, and I don't want to dig into that today.
- Show view names in addition to class names
- Use class_name from ClassInfo.h to get class names (no functional change)
- Use 4 spaces for indentation instead of 2
This is an old version of libc++ that was imported in an early attempt
of building Haiku with clang. It is currently not used for anything. In
fact there never was a Jamfile to build it.
Some logs are emitted even when nothing at all is happening, constantly
spamming the syslog. Log them only the first time they happen.
Change-Id: I81511a7ce245c2141fa3dcd141b2f3732d9b51ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4424
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
In some cases, we don't need the full tracking of every byte received at
the PS2 level, but higher level traces from specific devices will be
enough.
Change-Id: I31984e6b7784b5d033b457f43f3793f772213f4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4423
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
It's not allowed to enable the screen before having set a mode. At least
in the case of the intel_extreme driver, this creates some problem. Move
the call just a bit later in the init process, where the mode is already
set.
Change-Id: Iaa665f0edc15316890032f1a5928f33634dc8749
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4362
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: François Revol <[email protected]>
Reviewed-by: <[email protected]>
Various functions would return an error if trying to use them on the
last page of userspace, as they tested the permissions for the first
byte out of the requested range. Also, the code was duplicated in
several places
- Rename validate_user_range to validate_memory_range. The "user" in the
name was to mean that the range is provided by the user calling the
syscall, but it is a bit confusing, as the function accepts any range
that is either in kernel or in user memory.
- Add a new function validate_user_memory_range that only accepts
userspace memory, and use this one where appropriate.
Change-Id: I135f8d584340f0ba4ae7e4b8cb6f8600fbf3ef2d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4212
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
We must keep an untranslated version of the text for use with the
expression parser. Only the key label in the user interface should be
translated.
Fixes#15709.
This is in the code to print a text dump of the layout constraints, so
it does not fix any layout problems, but it makes debugging things a bit
easier.
The APIs for this were introduced in ICU 63, so we'll need an update.
ICU 63 does not build with gcc2, so this method is disabled there.
Change-Id: Iabe49509ed6d4e578560d497d3ca336a97db4625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1874
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
HTTP errors can have some content sent with them (a message to display
to the user, usually). The package kit would not ignore this and append
the content to the end of the downloaded file. This could result in a
file larger than the expected size, and in that case, it would keep
growing infinitely by adding more error messages to it.
Also add some more specific error messages for some HTTP codes, in
particular, "invalid range" which is likely to happen if something goes
wrong with range requests. Now this case will be detected and the
download will stop.
Change-Id: I18927f361235e9f72a5701c1bd7977abda9e21ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4210
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
We were incorrectly reporting a B_IO_ERROR for these requests because we
could not read the content after the headers. There is no content in
these cases.
Add an unit test for both HEAD and 204 status, checking that there is no
content and the headers are correct.
Fixes#16885.
Change-Id: I98fefc5c604253bb2545b50395b7af9f8834def0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4142
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Niels Sascha Reedijk <[email protected]>
The code allowed execution to continue as soon as the "command inhibit"
bit was cleared. This is incorrect: we need to wait for a command result
(either command complete, or timeout) to be available before continuing.
This should fix#17031.
Change-Id: I8f3fe60c2e47582b399952b19c05c6ed2161afd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4121
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This was based on the FreeBSD wi driver. The FreeBSD driver is removed
in FreeBSD 13. Most of the supported hardware was PC-Card, which we
never supported in the first place. All the devices, even the few
supported PCI ones, are restricted to 11Mbps Wifi, and the driver never
supported WPA. This makes this hardware largely irrelevant today.
The driver had already been removed from the build. This ocmmit just
deletes the sources.
Fixes#16942.
This resolves the confusion about the "url" field in repository
definition files. However it changes the identifier of repositories. It
seems to be a good idea to do this with a new release, as users will
need to switch to new repos anyway and can accept special instructions
at that time (we will include the instructions in the release notes).
The new format uses a tag: uri as specified in https://tools.ietf.org/html/rfc4151
The rationale for this is:
- We need a way to uniquely identify repositories
- We want anyone to be able to create a repository easily, with no
central registration, and in a way that does not results in accidental
conflicts. We do not want to be running a registry to grant people an
identifier for their repository.
- Backwards compatibility with existing repositories and software should be
preserved: some code and file formats in Haiku package tools expect or
expected the identifier to be parsable as a BUrl. Existing 3rd-party
repositories use an http or https URL as an identifier and may
continue to do so (changing the identifier of existing repositories is
not desirable)
- Forwards compatibility if we want to change this again later
- Optional: repository identifiers should be user readable.
The tag: URI resolves this in the following way:
- Backwards compatibility: it is still an URI, as the identifier
previously was.
- Forward compatibility: We can change to another URI scheme if we want to.
In fact, each repository can decide what type of URI they want to use,
"tag" is only a recommendation and put in use for the repos we
provide.
- Uniqueness + no centralization: the tag: URI specifies namespaces tied
to a domain name (which is already needed to host a repository) and a
date at which the domain is owned by the entity generating a tag. Inside
that namespace, they can do as they wish.
- User readability: the format is simple and text-based.
Other possible alternatives are:
- keeping the current solution of using http URLs. It has proven
confusing because the repository hosting may be moved or mirrored
while preserving the identifier. There is also work in progress to
distribute packages using other protocols (eg. IPFS).
- Using an uuid. This provides unique, decentralized identifiers, but
is not user-readable. Backwards compatibility can be provided by
wrapping the uuid into an "urn:uuid:" URI (see
https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx).
- Using some other URI scheme such as "urn:oid:". I investigated some, but
found none that provide a decentralized namespacing solution (except
for "tag", of course).
- Using a custom URI scheme of our own. This would normally require declaring
it to the IANA (example: https://www.iana.org/assignments/uri-schemes/prov/apt
for Debian packages) in order to not make the internet more of a mess
than it already is. We would still need to define a way to generate
URIs that protects people from getting accidental conflicts. The
solution would probably be similar to what the "tag" URI scheme does, as
there doesn't seem to be many other ways to guarantee uniqueness in
(cyber)space and time without registration.
- Not using an URI scheme: in addition to the problems of a custom URI
scheme, this would break backwards compatibility (existing software
would not accept the new format) and forwards compatibility (without a
scheme in the identifier, it is hard to detect what it is supposed to
be if we change formats later on)
Change-Id: I970c23a546569994632c7bd570d11bdea95ba52e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4106
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
This reverts hrev54422.
I'm not sure what I was trying to fix with this change. The way the
media kit is currently designed, the list of supported formats
(including for reading) comes only from writer plugins. This means it is
impossible to have a decode-only plugin currently. And the list is
called "fWriterFileFormats" but in fact is the only list used to
implement get_next_file_formats, so it should contain all formats.
This current setup works for the ffmpeg plugin, but it should be
cleaned.
This fixes Youtube playback. The problem was simply that we were not
reporting support for any of the Youtube video formats anymore.
Unfortunately, the app_server crashes when playing Youtube videos are
still there.
Change-Id: Ie5025cd48e2ab23b616bad49eec1401331ffb0ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4103
Reviewed-by: X512 <[email protected]>
Reviewed-by: Panagiotis Vasilopoulos <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
Tested-by: Commit checker robot <[email protected]>
- Add madmax
- Move rudolfc back to active contributors
- Add Shubham and Suhel to contributors, as former GSoC students and as
GSoC mentors
Change-Id: I2c4c1d4795e54158b837510b5a9832881ae80c21
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3909
Reviewed-by: Jérôme Duval <[email protected]>
- Switch to Python3
- Switch to mawk instead of gawk
- Update ffmpeg (there are several new dependencies)
- Update ICU
- Fix various pre-existing problems with packages not being properly
declared for gcc2 (but somehow it ended up working)
- remove curl, subversion, mercurial
Confirmed that both nightly and release images are building fine on both
32 and 64bit. However, non-x86 architecture may require re-bootstrapping
to do a complete nightly or release image build (the minimal profile
should be fine)
Fixes#16751.
Change-Id: Iacac92923c4113b3e0a49a64b0b4cc1b8e2f5e2e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3871
Reviewed-by: Adrien Destugues <[email protected]>
Whenever a device is removed, let usb_raw cancel all its pending
transfers. Does not seems to help with the issue I'm getting however.
Change-Id: Ie2856e68ea402c9f1cc352ac47bbca624e17d3dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1424
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Fredrik Modéen <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
I think this bug was introduced when modifying the code to handle
multiple slots. It would result in slots after the first two to use
incorrect bar offsets.
Should fix one of the problems seen in #16778.
Implement the needed parts in both the userland add-on (loaded in
DriveSetup) and the kernel side one (used by disk system manager in the
kernel).
This allows changing the active partition in DriveSetup.
Change-Id: Ia65768b5f8f11d626ef24621ae7735723dcbc39d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3771
Reviewed-by: Adrien Destugues <[email protected]>
When editing a partition parameters, we want to get the editor from the
parent partition. This will be the editor used to set the active
partition on Intel partition map, for example. The code testing if this
is supported and the code to apply the parameters did this, but the code
to get the parameter editor didn't.
Fixes the remaining part of #11641.
Change-Id: I25a6cf11fe315b8f6e118529f2395816101b7fe1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3766
Reviewed-by: Adrien Destugues <[email protected]>
Just ask the partition if its parameters can be changed, instead of
trying to guess.
Now the menu is always disabled. This is because none of our
partitioning systems actually allow changing any of the parameters of an
already created partition (they don't enable B_DISK_SYSTEM_SUPPORTS_SETTING_PARAMETERS).
Fixes#11641 (but we should implement editing parameters in the intel
partitionning system to set the active partition).
Change-Id: I242e7f73c4188824ba0e3984c0d97172da84e9a7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3765
Reviewed-by: Fredrik Holmqvist <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
- Replace the popup menu with a BOptionPopUp to simplify the code
- Remove an unused menu to select "warp mode"
- The focus mode is not stored in the mouse settings file
(config/settings_Mouse_settings), it is in another file
(config/settings/system/app_server/mouse). This file is not read or
written directly by mouse preferences, but we get the settings by
asking app_server. However, the code to get these was missing in one
place, resulting in these settings not being correctly initialized.
Fixes#16524
Change-Id: Ia1efc235c9d1a5408e3c6abc2526da7a0a639fa4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3796
Reviewed-by: Jérôme Duval <[email protected]>
Follow-up to #16670.
I have previously changed the locale kit to load all add-ons once at
start, but did not notice that it would unload them later on. This can
also create race conditions if the locale kit is used from inside
load_add_on (as is the case in translation kit add-ons for example).
Should fix the remaining problems in #16670
Change-Id: I0e22f8e146abe4fc85d8357ebe178db948fec1cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3734
Reviewed-by: Adrien Destugues <[email protected]>
- Unify storage of "FPU" registers between debugger and signal handler
to use xsave format on both sides
- Handle YMM registers in Debugger (they are the same as XMM, but wider)
Tested:
- The system still boots with and without AVX
- The hello_avx test program can be debugged and the full value of YMM is visible
This changes the API of vregs in signal.h but not the ABI (structure are
declared differently but memory layout is the same). This changes the
API and ABI of arch_debugger.h for x86_64, but I don't think anything
outside Haiku uses it (did we ever have a 64bit compatible gdb?)
Change-Id: If93680ffa0339c19bab517876b4e029f5d66b240
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3038
Reviewed-by: Rene Gollent <[email protected]>
We never told the disk system that the partition had been initialized.
As a result, the disk device jobs to clean and reinit the partition
table were not run. This would lead to:
- The bootloader code not being replaced with our MBR code
- Old partitions not being removed from the disk
This would maybe solve itself when creating a partition, but it's better
to do these changes immediately when the user asks to initialize the
disk.
Fixes#9108.
Change-Id: Icc8ebe3830d948367852a57cf46d034b0f1c6c19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3673
Reviewed-by: Niels Sascha Reedijk <[email protected]>
Pick the most advanced partial download to resume from if there are
multiple ones.
Fixes the remaining part of #16744.
Change-Id: I0ed7daf42e0346632918552e97d660b4946405cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3672
Reviewed-by: Stephan Aßmus <[email protected]>
The catalog loading has been done lazily since forever (this code was
imported from OpenTracker). It results in a race condition as explained
in #16670.
Moving the catalog loading earlier in the locale loading process avoids
this problem, since load_add_on is called before the locale roster lock
is used.
This should fix#16670.
Change-Id: If07054077f7dde41cb342a43af2abe8422239b05
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3661
Reviewed-by: Jérôme Duval <[email protected]>
PulkoMandy