Now that the infrastructure of the Graphics subsystem is quite stable,
it is time to try to fix a long-standing problem, which is the lack of
locking on display connector devices. Reading and writing from multiple
processes to a framebuffer controlled by the display connector is not a
huge problem - it could be solved with POSIX locking.
The real problem is some program that will try to do ioctl operations on
a display connector without the WindowServer being aware of that which
can lead to very bad situations, for example - assuming a framebuffer is
encoded at a known resolution and certain display timings, but another
process changed the ModeSetting of the display connector, leading to
inconsistency on the properties of the current ModeSetting.
To solve this, there's a new "master" ioctl to take "ownership" and
another one to release that ownership of a display connector device. To
ensure we will not hold a Process object forever just because it has an
ownership over a display connector, we hold it with a weak reference,
and if the process is gone, someone else can take an ownership.
This header file represents the entire interface between the kernel and
userland, and as such, no longer should be called FB.h but something
that represents the whole graphics subsystem.
This style is the same as what is used in WebKit/Blink, it is a bit
ugly, but you're expected to override it. Adding more than a
background color here could cause some issues, as sites don't
expect to have to unset the styles.
This disables this system progress bar, and instead creates one
out of pseudo elements, that can be selected and styled with the
::-webkit-progress-bar/value selectors.
These will be needed for styling progress bars, sadly this can
only be done with these non-standard selectors. These are, hovever,
in use on real sites such as https://rpcs3.net/compatibility.
This isn't called out in TR-35, but before ICU even looks at CLDR data,
it adds a hard-coded set of default patterns to each locale's calendar.
It has done this since 2006 when its DateTimeFormat feature was first
created. Several test262 tests depend on this, which under ECMA-402,
falls into "implementation defined" behavior. For compatibility, we
can do the same in LibUnicode.
This is a minor refactor of XHR::extract_body() letting it return
ErrorOr<...> instead of just Fetch::Infrastructure::BodyWithType.
This also updates the one place extract_body() is used.
This is a minor refactor of IDL::get_buffer_source_copy() letting it
return ErrorOr<ByteBuffer> instead of Optional<ByteBuffer>.
This also updates all places that use IDL::get_buffer_source_copy().
This patch implements man pages opened using the help url protocol
properly getting added to the navigation history as well as enabling
the back and forward buttons in such cases.
This patch makes the picker applet react instantly to a click on a
workspace or scroll on the widget, instead of waiting for an event from
WindowServer and as such until the switching animation has ended. This
synchronises the switching with the overlay shown.
Note that WindowServer events will still get handled in case the
workspace were to be updated from somewhere else.
The audio enqueuer thread goes to sleep when there is no more audio data
present, and through normal Core::EventLoop events it can be woken up.
However, that waking up only happens when the thread is not currently
running, so that the wake-up events don't queue up and cause weirdness.
The atomic variable responsible for keeping track of whether the thread
is active can lead to a racy deadlock however, where the audio enqueuer
thread will never wake up again despite there being audio data to
enqueue. Consider this scenario:
- Main thread calls into async_enqueue. It detects that according to the
atomic variable, the other thread is still running, skipping the event
queue wake.
- Enqueuer thread has just finished playing the last chunk of audio and
detects that there is no audio left. It enters the if block with the
dbgln "Reached end of provided audio data..."
- Main thread enqueues audio, making the user sample queue non-empty.
- Enqueuer thread does not check this condition again, instead setting
the atomic variable to indicate that it is not running. It exits into
an event loop sleep.
- Main thread exits async_enqueue. The calling audio enqueuing system
(see e.g. Piano, but all of them function similarly) will wait until
the enqueuer thread has played enough samples before async_enqueue is
called again. However, since the enqueuer thread will never play any
audio, this condition is never fulfilled and audio playback deadlocks
This commit fixes that by allowing the event loop to not enqueue an
event that already exists, therefore overloading the audio enqueuer
event loop by at maximum one message in weird situations. We entirely
get rid of the atomic variable and the race condition is prevented.
This will conflict with apps that don't use this thread and it also
creates unnecessary overhead for non-enqueuing clients like AudioApplet.
Use the new Thread is_started info to start the thread only if necessary
(on first call to async_enqueue).
Users can now determine whether a thread has been started or not. A
started thread might also have already terminated.
Implementation note: We *could* detect this with pthread APIs maybe, but
this is much simpler.
We likely won't be able to test `pthread_cancel` itself, but this at
least makes sure that we use the correct values by default and that we
correctly reject invalid values.
In the generated unique string list, index 0 is the empty string, and is
used to indicate a value doesn't exist in the CLDR. Check for this
before returning an empty calendar symbol.
For example, an upcoming commit will add the fixed day period "noon",
which not all locales support.
Commit ec7d535 only partially handled the case of flexible day periods
rolling over midnight, in that it only worked for hours after midnight.
For example, the en locale defines a day period range of [21:00, 06:00).
The previous method of adding 24 hours to the given hour would change
e.g. 23:00 to 47:00, which isn't valid.
Previously, end block was inconsistent. GUIDPartitionTable treated
end block as an inclusive bound, while MBRPartitionTable and
EBRPartitionTable treated end block as an exclusive bound.
Now all three treat end block as an inclusive upper bound.
