Commit graph

121 commits

Author SHA1 Message Date
Fernando Sahmkow
f3a39e0c9c NVServices: Address Feedback 2019-07-05 15:49:33 -04:00
Fernando Sahmkow
737e978f5b nv_services: Correct buffer queue fencing and GPFifo fencing 2019-07-05 15:49:10 -04:00
Fernando Sahmkow
ceb5f5079c nvflinger: Implement swap intervals 2019-07-05 15:49:08 -04:00
Weiyi Wang
8d6342384b HLE/IPC: HLEContext can memorize the client thread and use it for SleepClientThread
This reduces the boilerplate that services have to write out the current thread explicitly. Using current thread instead of client thread is also semantically incorrect, and will be a problem when we implement multicore (at which time there will be multiple current threads)
2019-05-18 19:53:39 +02:00
bunnei
e86b26cd2b
Merge pull request #2334 from lioncash/override
core: Add missing override specifiers where applicable
2019-04-05 23:39:52 -04:00
Lioncash
7f506be2ee hle/service: Resolve unused variable warnings
In several places, we have request parsers where there's nothing to
really parse, simply because the HLE function in question operates on
buffers. In these cases we can just remove these instances altogether.

In the other cases, we can retrieve the relevant members from the parser
and at least log them out, giving them some use.
2019-04-04 13:18:09 -04:00
Lioncash
5b0a9f8ba8 core: Add missing override specifiers where applicable
Applies the override specifier where applicable. In the case of
destructors that are  defaulted in their definition, they can
simply be removed.

This also removes the unnecessary inclusions being done in audin_u and
audrec_u, given their close proximity.
2019-04-04 12:19:44 -04:00
bunnei
e8a21f5276
Merge pull request #2166 from lioncash/vi-init-service
service/vi: Unstub GetDisplayService
2019-03-13 10:01:54 -04:00
Lioncash
b9238edd0d common/math_util: Move contents into the Common namespace
These types are within the common library, so they should be within the
Common namespace.
2019-02-27 03:38:39 -05:00
Lioncash
92ea1c32d6 service/vi: Unstub GetDisplayService
This function is also supposed to check its given policy type with the
permission of the service itself. This implements the necessary
machinery to unstub these functions.

Policy::User seems to just be basic access (which is probably why vi:u
is restricted to that policy), while the other policy seems to be for
extended abilities regarding which displays can be managed and queried,
so this is assumed to be for a background compositor (which I've named,
appropriately, Policy::Compositor).
2019-02-26 20:16:23 -05:00
Lioncash
1b2872eebc service/vi: Remove use of a module class
This didn't really provide much benefit here, especially since the
subsequent change requires that the behavior for each service's
GetDisplayService differs in a minor detail.

This also arguably makes the services nicer to read, since it gets rid
of an indirection in the class hierarchy.
2019-02-26 17:44:03 -05:00
Lioncash
be7dad5e7e service/vi: Update IManagerDisplayService's function table
Amends it to add the 7.0.0+ CreateStrayLayer function.
2019-02-25 08:09:00 -05:00
Lioncash
90528f1326 service/nvflinger: Store BufferQueue instances as regular data members
The NVFlinger service is already passed into services that need to
guarantee its lifetime, so the BufferQueue instances will already live
as long as they're needed. Making them std::shared_ptr instances in this
case is unnecessary.
2019-02-21 22:09:46 -05:00
Lioncash
ef073ff117 service/nvflinger,service/vi: Handle failure cases with exposed API
Converts many of the Find* functions to return a std::optional<T> as
opposed to returning the raw return values directly. This allows
removing a few assertions and handles error cases like the service
itself does.
2019-02-05 18:03:28 -05:00
Lioncash
3c02cdcc57 service/nvflinger: Rename GetVsyncEvent() to FindVsyncEvent()
This was missed within #2075. Renames the member function to make it
consistent with the rest of the Find* functions.
2019-02-05 15:55:18 -05:00
Lioncash
1d11def9c4 service/nvflinger: Rename Get prefix on function to Find
This more accurately describes what the function is actually attempting
to do (it's not a simple trivial getter).
2019-01-30 11:11:32 -05:00
Lioncash
5e636d1f6e service/vi: Remove stubbed notifier from SetLayerVisibility
This appears to be a vestigial API function that's only kept around for
compatibility's sake, given the function only returns a success error
code and exits.

Since that's the case, we can remove the stubbed notification from the
log, since doing nothing is technically the correct behavior in this
case.
2019-01-28 08:22:28 -05:00
bunnei
17a68e5ebe
Merge pull request #1989 from lioncash/set
service/vi: Unstub IApplicationDisplayService's SetLayerScalingMode
2019-01-07 12:59:33 -05:00
Lioncash
9e8737b535 service/vi: Correct scaling mode conversions
These values are not equivalent, based off RE. The internal value is put
into a lookup table with the following values:

[3, 0, 1, 2, 4]

So the values absolutely do not map 1:1 like the comment was indicating.
2019-01-04 21:45:18 -05:00
Lioncash
56e51da1d9 service/vi: Factor out scaling mode conversions from the IPC function itself
Avoids entangling the IPC buffer appending with the actual operation of
converting the scaling values over. This also inserts the proper error
handling for invalid scaling values.
2019-01-04 21:45:18 -05:00
Lioncash
40aa1ea9f9 service/vi: Unstub IApplicationDisplayService' SetLayerScalingMode()
This appears to only check if the scaling mode can actually be
handled, rather than actually setting the scaling mode for the layer.

This implements the same error handling performed on the passed in
values.
2019-01-04 21:45:14 -05:00
Lioncash
bf036b46fc service/vi: Correct reported dimensions from IApplicationDisplayService's GetDisplayResolution()
Within the actual service, it makes no distinguishing between docked and
undocked modes. This will always return the constants values reporting
1280x720 as the dimensions.
2019-01-04 19:13:32 -05:00
bunnei
de4f931d13
Merge pull request #1975 from lioncash/vi
service/vi: Minor updates and corrections to the DisplayInfo struct
2019-01-03 22:45:27 -05:00
bunnei
2c0f831468
Merge pull request #1976 from lioncash/display
service/vi: Implement OpenDefaultDisplay in terms of OpenDisplay
2019-01-02 21:51:20 -05:00
Lioncash
ceeff8ebfd service/vi: Implement SetDisplayEnabled()
This IPC command is simply a stub inside the actual service itself, and
just returns a successful error code regardless of input. This is likely
only retained in the service interface to not break older code that relied
upon it succeeding in some way.
2019-01-02 20:48:04 -05:00
bunnei
7538fa4a67
Merge pull request #1977 from lioncash/vi-log
service/vi: Log more information where applicable
2019-01-02 20:36:40 -05:00
Lioncash
5bfd810ab5 service/vi: Log more information where applicable
In many cases, we didn't bother to log out any of the popped data
members. This logs them out to the console within the logging call to
provide more contextual information.
2019-01-02 19:42:10 -05:00
Lioncash
dea1db0414 service/vi: Implement OpenDefaultDisplay in terms of OpenDisplay
Internally within the vi services, this is essentially all that
OpenDefaultDisplay does, so it's trivial to just do the same, and
forward the default display string into the function.
2019-01-02 18:16:36 -05:00
Lioncash
351f010cfc service/vi: Correct initial width and height values
Based off RE, it appears that almost all display types seem to use
1920x1080 except for a few (null display, edid display).
2019-01-02 17:36:03 -05:00
Lioncash
fe3bf4f075 service/vi: Document unknown DisplayInfo struct members
It appears that the two members indicate whether a display has a bounded
number of layers (and if set, the second member indicates the total
number of layers).
2019-01-02 17:35:58 -05:00
Lioncash
1f0c8bfeda core/kernel: Remove unnecessary inclusions
Gets rid of a few unnecessary header dependencies in some source files.
2018-12-31 19:04:16 -05:00
bunnei
ef69b4b830
Merge pull request #1803 from DarkLordZach/k-able-event
kernel: Divide Event into ReadableEvent and WritableEvent
2018-12-03 17:05:57 -05:00
Subv
583bd20f02 Services/VI: Dereferencing an uninitialized std::optional is undefined behavior.
Assert that it is not empty before using it in the DequeueBuffer wait callback.
2018-11-30 16:06:49 -05:00
Zach Hilman
170d707850 hle_ipc: Refactor SleepClientThread to avoid ReadableEvent 2018-11-29 09:14:20 -05:00
Zach Hilman
ff610103b5 core: Port all current usages of Event to Readable/WritableEvent 2018-11-29 08:45:41 -05:00
David Marcec
a2cc3b10bb Changed logging to be "Log before execution", Added more error logging, all services should now log on some level 2018-11-26 17:06:13 +11:00
bunnei
e65966bcfc
Merge pull request #1708 from ogniK5377/res-scale
Report resolution scaling support for vi and am
2018-11-23 23:32:19 -05:00
David Marcec
60fecee1ec Removed hard coded values for width and height 2018-11-19 15:20:47 +11:00
Zach Hilman
c91dc417d5 vi: Implement TransactParcel for Disconnect and DetachBuffer
Used by homebrew on exit. According to switchbrew, returns an empty response parcel with one zero in it.
2018-11-17 17:10:19 -05:00
David Marcec
9359655712 Report resolution scaling support for vi and am
Specifying an internal resolution in yuzu now will report the scaled changes to vi and am.
2018-11-16 18:07:42 +11:00
Frederic L
7a5eda5914 global: Use std::optional instead of boost::optional (#1578)
* get rid of boost::optional

* Remove optional references

* Use std::reference_wrapper for optional references

* Fix clang format

* Fix clang format part 2

* Adressed feedback

* Fix clang format and MacOS build
2018-10-30 00:03:25 -04:00
David
92d8ad3770 Implement VI ConvertScalingMode (#1475)
* Implement VI ConvertScalingMode

* Fixed push enum

* Scale mode now uses Nintendo scale mode as an enum as well
2018-10-16 11:25:42 -04:00
bunnei
8f2ad3a66d
Merge pull request #1338 from raven02/service_vi
Implement ISystemDisplayService::GetDisplayMode
2018-09-30 15:39:54 -04:00
raven02
4092907687 Implement ISystemDisplayService::GetDisplayMode 2018-09-30 10:04:03 +08:00
David Marcec
6a0612f2bf Removed the use of rp.MakeBuilder
Due to keeping the code style consistent in the yuzu codebase. `rb = rp.MakeBuilder(...)` was replaced with `rb{ctx, ...}`
2018-09-19 15:09:59 +10:00
bunnei
2c9c0d70a3
Merge pull request #1312 from lioncash/fwd
service/vi: Replace includes with forward declarations where applicable
2018-09-17 12:32:28 -04:00
fearlessTobi
63c2e32e20 Port #4182 from Citra: "Prefix all size_t with std::" 2018-09-15 15:21:06 +02:00
Lioncash
0258b444ef service/vi: Replace includes with forward declarations where applicable 2018-09-13 16:55:47 -04:00
Lioncash
2ea45fe75b kernel/thread: Include thread-related enums within the kernel namespace
Previously, these were sitting outside of the Kernel namespace, which
doesn't really make sense, given they're related to the Thread class
which is within the Kernel namespace.
2018-09-13 16:05:57 -04:00
Lioncash
6ac955a0b4 hle/service: Default constructors and destructors in the cpp file where applicable
When a destructor isn't defaulted into a cpp file, it can cause the use
of forward declarations to seemingly fail to compile for non-obvious
reasons. It also allows inlining of the construction/destruction logic
all over the place where a constructor or destructor is invoked, which
can lead to code bloat. This isn't so much a worry here, given the
services won't be created and destroyed frequently.

The cause of the above mentioned non-obvious errors can be demonstrated
as follows:

------- Demonstrative example, if you know how the described error happens, skip forwards -------

Assume we have the following in the header, which we'll call "thing.h":

\#include <memory>

// Forward declaration. For example purposes, assume the definition
// of Object is in some header named "object.h"
class Object;

class Thing {
public:
    // assume no constructors or destructors are specified here,
    // or the constructors/destructors are defined as:
    //
    // Thing() = default;
    // ~Thing() = default;
    //

    // ... Some interface member functions would be defined here

private:
    std::shared_ptr<Object> obj;
};

If this header is included in a cpp file, (which we'll call "main.cpp"),
this will result in a compilation error, because even though no
destructor is specified, the destructor will still need to be generated by
the compiler because std::shared_ptr's destructor is *not* trivial (in
other words, it does something other than nothing), as std::shared_ptr's
destructor needs to do two things:

1. Decrement the shared reference count of the object being pointed to,
   and if the reference count decrements to zero,

2. Free the Object instance's memory (aka deallocate the memory it's
   pointing to).

And so the compiler generates the code for the destructor doing this inside main.cpp.

Now, keep in mind, the Object forward declaration is not a complete type. All it
does is tell the compiler "a type named Object exists" and allows us to
use the name in certain situations to avoid a header dependency. So the
compiler needs to generate destruction code for Object, but the compiler
doesn't know *how* to destruct it. A forward declaration doesn't tell
the compiler anything about Object's constructor or destructor. So, the
compiler will issue an error in this case because it's undefined
behavior to try and deallocate (or construct) an incomplete type and
std::shared_ptr and std::unique_ptr make sure this isn't the case
internally.

Now, if we had defaulted the destructor in "thing.cpp", where we also
include "object.h", this would never be an issue, as the destructor
would only have its code generated in one place, and it would be in a
place where the full class definition of Object would be visible to the
compiler.

---------------------- End example ----------------------------

Given these service classes are more than certainly going to change in
the future, this defaults the constructors and destructors into the
relevant cpp files to make the construction and destruction of all of
the services consistent and unlikely to run into cases where forward
declarations are indirectly causing compilation errors. It also has the
plus of avoiding the need to rebuild several services if destruction
logic changes, since it would only be necessary to recompile the single
cpp file.
2018-09-10 23:55:31 -04:00