macOS support possibly?

Nyarumi commented 3 years ago

This is a longshot, but is there any possibility of adding macOS support? There's no low-latency streaming services that support macOS hosting (Parsec, Rainway, Moonlight, etc.). I think I got it to build on macOS by installing all the build dependencies with brew and port, but when I run gen-deb I get Can't fund sunshine as an error. I am not a programmer though, just a tinkerer, so I have no idea if this was close to success or did absolutely nothing. I attached a screenshot of the terminal window when running gen-deb as well as the log for when I built it with cmake. Just in case it matters to any of the smart programmers here.

Terminal Saved Output.txt

abusse commented 3 years ago

Unfortunately, Sunshine does not work on MacOS out of the box as both the video and the audio subsystem of MacOS is completely different from Linux and Windows. I have been tinkering around to add MacOS support lately, but due to very limited time, so far, I only came up with a very basic version that still requires a lot of work and optimizations before it will be usable. I will probably keep improving it as far as my time allows it, however, in case someone else likes to help or needs a starting point, I just pushed what I got so far and will keep pushing my improvements: 63ac9ea37d5721da036d9ceb88186f7b7a130c42

Besides the million small bugs that are still present, I am currently trying to integrate more of the Apple provided Frameworks for video encoding as they will probably be more efficient and use hardware acceleration if supported by the machine.

Nyarumi commented 3 years ago

Oh wow, that's great! I've downloaded those files but I can't seem to get them to build properly. I think it's the part with -DBOOST_ROOT=[boost path] that is causing the problem. I tried it just like that, as well as substituting [boost path] with some solutions I found online, but I can't seem to get it to work and it always just throws an error or builds incompletely. Any ideas? I am on an M1 Mac, which might be causing the problem.

abusse commented 3 years ago

This is almost certainly not an M1 issue. You can first try to omit the option completely. I only needed to use it recently and haven't figured out the issue completely. If that doesn't wort you have to find the path where boost was installed to. For me for example its /opt/local/libexec/boost/1.76. You should look for files like libboost_thread-mt.dylib.

However to curb the enthusiasm, be warned. Even if you get it working, it will still be a very bumpy ride. For example, my MBP 2016 can barely handle a 1080p stream. Audio can suffer from CPU load. Input is barely tested. And there are probably a million other annoying bugs.

Nyarumi commented 3 years ago

I got it to work, yay! For what you make sound like a pre-alpha alpha, it works pretty well. The biggest problem I have is that I have a 4k screen, so on resolutions lower than native the downscaling gets all weird and choppy. On 4k native it's fine, though my computer can't really handle that kind of streaming and goes down to about 20 FPS. Audio works really well though, and I could only get it to stutter by running a CPU benchmark. Overall, if this is a super alpha alpha (which it seems like it is), it's super promising. This makes me super happy, and I really appreciate the work you've done on it. Thank you!

chrisknepper commented 3 years ago

@Nyarumi I am also very interested in this, let me know if you have any other tips. I have an M1 Mac Mini with a 4K screen and my goal is to remote into the Mac using Moonlight on an Android device.

With respect to your original comment, the closest low-latency application I've found to work on macOS (as a host) is the proprietary AnyDesk. But unfortunately that has many shortcomings (aside from being proprietary) -- the input mappings for meta keys like Command, Control, and Option don't work well when using a physical keyboard on the Android side.

Anyway, happy to help test. I'm not too familiar with macOS APIs but I wonder if this may be of any help. The screen recording/broadcasting application OBS apparently has a (third-party?) plugin that enables hardware acceleration for encoding with h.265 on Apple Silicon: https://obsproject.com/forum/threads/%E2%80%9Capple-vt-h264-hardware-encoder-unlocked-for-apple-silicon-m1.138433/

abusse commented 3 years ago

@Nyarumi Thank you for the feedback, especially regarding the audio. I still have problems with this and was not sure whether it is a load problem or a bug in the implementation. Since it looks like the former one, I can stop investing time there for now.

Like I said everything beyond 1080p is probably not feasible with the software encoder. @chrisknepper FFMPEG does also have an encoder that uses the same Apple Framework (VideoToolbox) as OBS does. I am currently looking into making use of it and already get some video with a significant reduced CPU load. However, the either some frames get lost or have the wrong order, because the image looks very bad. I am currently investigating that, but the problem seems to be more complicated than tuning just some encoding parameters. However, on the bright side, if I get it working, it should in theory run on every MacOS platform with hardware acceleration without additional work.

Nyarumi commented 3 years ago

I’m open to testing whatever as well, and I have the same device as @chrisknepper (M1 Mac Mini). I can’t really provide programming help, but I’d be glad to provide logs or whatever when I test things.

loki-47-6F-64 commented 3 years ago

@abusse

I'm all for getting it to work on different platforms.

If you go to the Discord of Moonlight, in channel sunshine, we could discuss any changes to Sunshine's architecture that are required to get it to run smoothly on MacOS. :P

sajty commented 3 years ago

Hi @abusse,

thanks for your changes. I have tried it out on m1 mac and it is working insanely well, when I run it inside lldb, but if I run it without lldb, then sunshine is deadlocking at initialization. It seems the apple m1 cpu is too fast for this. ;) I'm using the latest version from this branch: https://github.com/abusse/sunshine/tree/macos-dev I get following backtraces, when I start sunshine without lldb, then attach lldb at the deadlock:

(lldb) bt all 
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001a09b8548 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x00000001a09efdac libsystem_pthread.dylib`_pthread_cond_wait + 1248
    frame #2: 0x0000000100f6a760 sunshine`platf::av_display_t::dummy_img(platf::img_t*) + 100
    frame #3: 0x0000000100f69b44 sunshine`platf::display(platf::mem_type_e, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) + 760
    frame #4: 0x0000000100f3b010 sunshine`video::reset_display(std::__1::shared_ptr<platf::display_t>&, AVHWDeviceType, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) + 560
    frame #5: 0x0000000100f41fb8 sunshine`video::validate_config(std::__1::shared_ptr<platf::display_t>&, video::encoder_t const&, video::config_t const&) + 60
    frame #6: 0x0000000100f42678 sunshine`video::validate_encoder(video::encoder_t&) + 420
    frame #7: 0x0000000100f435d0 sunshine`video::init() + 1084
    frame #8: 0x0000000100e8ee4c sunshine`main + 3100
    frame #9: 0x00000001a0a0d430 libdyld.dylib`start + 4
  thread #2
    frame #0: 0x00000001a09b8548 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x00000001a09efdac libsystem_pthread.dylib`_pthread_cond_wait + 1248
    frame #2: 0x000000010281039c libboost_log-mt.dylib`boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) + 76
    frame #3: 0x00000001028102e8 libboost_log-mt.dylib`boost::log::v2_mt_posix::aux::generic_event::wait() + 60
    frame #4: 0x0000000100e9635c sunshine`boost::log::v2_mt_posix::sinks::asynchronous_sink<boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>, boost::log::v2_mt_posix::sinks::unbounded_fifo_queue>::run() + 196
    frame #5: 0x0000000102c7e628 libboost_thread-mt.dylib`boost::(anonymous namespace)::thread_proxy(void*) + 176
    frame #6: 0x00000001a09ef878 libsystem_pthread.dylib`_pthread_start + 320
  thread #3
    frame #0: 0x00000001a09b8548 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x00000001a09efdac libsystem_pthread.dylib`_pthread_cond_wait + 1248
    frame #2: 0x00000001a0949efc libc++.1.dylib`std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
    frame #3: 0x0000000100e90f6c sunshine`util::ThreadPool::_main() + 388
    frame #4: 0x0000000100e914fc sunshine`void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (util::ThreadPool::*)(), util::ThreadPool*> >(void*) + 64
    frame #5: 0x00000001a09ef878 libsystem_pthread.dylib`_pthread_start + 320
  thread #4
    frame #0: 0x00000001a09b6a8c libsystem_kernel.dylib`__workq_kernreturn + 8

Can you take a look? I want to screen mirror (no input or audio needed) my macbook air to my "Google TV with chromecast" and sunshine inside lldb with software encoding outperforms in latency and quality chrome's chromecast screen mirroring by a lot! This is not a joke! I would like to use sunshine on a regular basis if this deadlock is fixed. Thanks!

abusse commented 3 years ago

Hi @sajty,

Thank you for the feedback and I'm happy to hear that the performance is ok on the M1. I was lately a little bit short on time because of my daytime job and could't look much into pushing the port further. Sorry for that.

I already know what the issue is as I tried to solve it before. I thought I had it fixed, but apparently I haven't. My Mac is probably not fast enough to trigger it and it is working in lldb because it simply slows down the execution. I will have to look into it in more detail and put in some more brain to (hopefully) solve that issue for good. I will let you know when I come up with a solution.

abusse commented 3 years ago

@sajty after looking closer at the issue, it was something else than I had initially suspected, but I think I have a fix. Just pushed it. Have a try and let me know if it works.

Nyarumi commented 3 years ago

I have the newest MBP if you need any testing on a newer machine/Apple silicon.

sajty commented 3 years ago

@abusse Thanks for the changes, but unfortunately it didn't fix the issue. Now, it is locked inside the semaphore in the same manner as before.

(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000019ace4e10 libsystem_kernel.dylib`semaphore_wait_trap + 8
    frame #1: 0x000000019ab70428 libdispatch.dylib`_dispatch_sema4_wait + 28
    frame #2: 0x000000019ab70aec libdispatch.dylib`_dispatch_semaphore_wait_slow + 132
    frame #3: 0x0000000104ae9da0 sunshine`platf::av_display_t::dummy_img(platf::img_t*) + 88
    frame #4: 0x0000000104ae91a0 sunshine`platf::display(platf::mem_type_e, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) + 760
    frame #5: 0x0000000104ab99d8 sunshine`video::reset_display(std::__1::shared_ptr<platf::display_t>&, AVHWDeviceType, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) + 560
    frame #6: 0x0000000104ac08a4 sunshine`video::validate_config(std::__1::shared_ptr<platf::display_t>&, video::encoder_t const&, video::config_t const&) + 60
    frame #7: 0x0000000104ac0f68 sunshine`video::validate_encoder(video::encoder_t&) + 420
    frame #8: 0x0000000104ac1ec0 sunshine`video::init() + 1084
    frame #9: 0x0000000104a0bf70 sunshine`main + 3100
    frame #10: 0x000000019ad3d430 libdyld.dylib`start + 4
  thread #2
    frame #0: 0x000000019ace8548 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x000000019ad1fdac libsystem_pthread.dylib`_pthread_cond_wait + 1248
    frame #2: 0x00000001065f839c libboost_log-mt.dylib`boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) + 76
    frame #3: 0x00000001065f82e8 libboost_log-mt.dylib`boost::log::v2_mt_posix::aux::generic_event::wait() + 60
    frame #4: 0x0000000104a13480 sunshine`boost::log::v2_mt_posix::sinks::asynchronous_sink<boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>, boost::log::v2_mt_posix::sinks::unbounded_fifo_queue>::run() + 196
    frame #5: 0x00000001067e2628 libboost_thread-mt.dylib`boost::(anonymous namespace)::thread_proxy(void*) + 176
    frame #6: 0x000000019ad1f878 libsystem_pthread.dylib`_pthread_start + 320
  thread #3
    frame #0: 0x000000019ace8548 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x000000019ad1fdac libsystem_pthread.dylib`_pthread_cond_wait + 1248
    frame #2: 0x000000019ac79efc libc++.1.dylib`std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
    frame #3: 0x0000000104a0e090 sunshine`util::ThreadPool::_main() + 388
    frame #4: 0x0000000104a0e620 sunshine`void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (util::ThreadPool::*)(), util::ThreadPool*> >(void*) + 64
    frame #5: 0x000000019ad1f878 libsystem_pthread.dylib`_pthread_start + 320
  thread #4
    frame #0: 0x000000019ace6a8c libsystem_kernel.dylib`__workq_kernreturn + 8

I have added log entries for semaphore creation and signaling, and it seems without lldb it is never signaled. Also, the "Zero Metal services found" line is missing.

Log output without lldb:

sajty@MacBook-Air build % ./sunshine           
[2021:11:14:08:48:08]: Info: //////////////////////////////////////////////////////////////////
[2021:11:14:08:48:08]: Info: //                                                              //
[2021:11:14:08:48:08]: Info: //   Testing for available encoders, this may generate errors.  //
[2021:11:14:08:48:08]: Info: //   You can safely ignore those errors.                        //
[2021:11:14:08:48:08]: Info: //                                                              //
[2021:11:14:08:48:08]: Info: //////////////////////////////////////////////////////////////////
[2021:11:14:08:48:08]: Info: Trying encoder [videotoolbox]
semaphore created
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): PlugInMain version=1.3.0
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): HardwarePlugIn_QueryInterface 
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): HardwarePlugIn_Release sRefCount now = 0
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): HardwarePlugIn_InitializeWithObjectID self=0x1097e1638
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): HardwarePlugIn_ObjectSetPropertyData OBSDALDevice(33) kCMIOObjectPropertyListenerAdded self=0x1097e1638 data(int)=1684629094
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): HardwarePlugIn_ObjectSetPropertyData OBSDALDevice(33) kCMIOObjectPropertyListenerAdded self=0x1097e1638 data(int)=1869180523
2021-11-14 08:48:08.085 sunshine[9084:378222] mac-virtualcam(DAL): HardwarePlugIn_ObjectSetPropertyData OBSDALDevice(33) kCMIOObjectPropertyListenerAdded self=0x1097e1638 data(int)=1885762592

Log output with lldb:

sajty@MacBook-Air build % lldb -o run ./sunshine
(lldb) target create "./sunshine"
Current executable set to '/Users/sajty/dev/sunshine/build/sunshine' (arm64).
(lldb) run
[2021:11:14:08:50:14]: Info: //////////////////////////////////////////////////////////////////
[2021:11:14:08:50:14]: Info: //                                                              //
[2021:11:14:08:50:14]: Info: //   Testing for available encoders, this may generate errors.  //
[2021:11:14:08:50:14]: Info: //   You can safely ignore those errors.                        //
[2021:11:14:08:50:14]: Info: //                                                              //
[2021:11:14:08:50:14]: Info: //////////////////////////////////////////////////////////////////
[2021:11:14:08:50:14]: Info: Trying encoder [videotoolbox]
semaphore created
2021-11-14 08:50:14.715500+0100 sunshine[9129:381236] +[MTLIOAccelDevice registerDevices]: Zero Metal services found
2021-11-14 08:50:14.761866+0100 sunshine[9129:381236] mac-virtualcam(DAL): PlugInMain version=1.3.0
2021-11-14 08:50:14.761935+0100 sunshine[9129:381236] mac-virtualcam(DAL): HardwarePlugIn_QueryInterface
2021-11-14 08:50:14.761952+0100 sunshine[9129:381236] mac-virtualcam(DAL): HardwarePlugIn_Release sRefCount now = 0
2021-11-14 08:50:14.762052+0100 sunshine[9129:381236] mac-virtualcam(DAL): HardwarePlugIn_InitializeWithObjectID self=0x116e65638
2021-11-14 08:50:14.762133+0100 sunshine[9129:381236] mac-virtualcam(DAL): HardwarePlugIn_ObjectSetPropertyData OBSDALDevice(33) kCMIOObjectPropertyListenerAdded self=0x116e65638 data(int)=1684629094
2021-11-14 08:50:14.762148+0100 sunshine[9129:381236] mac-virtualcam(DAL): HardwarePlugIn_ObjectSetPropertyData OBSDALDevice(33) kCMIOObjectPropertyListenerAdded self=0x116e65638 data(int)=1869180523
2021-11-14 08:50:14.762160+0100 sunshine[9129:381236] mac-virtualcam(DAL): HardwarePlugIn_ObjectSetPropertyData OBSDALDevice(33) kCMIOObjectPropertyListenerAdded self=0x116e65638 data(int)=1885762592
2021-11-14 08:50:14.778550+0100 sunshine[9129:381236] [plugin] AddInstanceForFactory: No factory registered for id <CFUUID 0x106d5b770> 30010C1C-93BF-11D8-8B5B-000A95AF9C6A
semaphore signaled
[2021:11:14:08:50:16]: Info: Color coding [Rec. 601]
[2021:11:14:08:50:16]: Info: Color range: [JPEG]
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Error: Could not send a frame for encoding: Generic error in an external library
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Info: Color coding [Rec. 601]
[2021:11:14:08:50:16]: Info: Color range: [JPEG]
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Error: Could not send a frame for encoding: Generic error in an external library
[2021:11:14:08:50:16]: Info: Encoder [videotoolbox] failed
[2021:11:14:08:50:16]: Info: Trying encoder [software]
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Info: Color coding [Rec. 601]
[2021:11:14:08:50:16]: Info: Color range: [JPEG]
semaphore created
semaphore signaled
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Info: Color coding [Rec. 601]
[2021:11:14:08:50:16]: Info: Color range: [JPEG]
semaphore created
semaphore signaled
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Info: Color coding [Rec. 601]
[2021:11:14:08:50:16]: Info: Color range: [JPEG]
semaphore created
semaphore signaled
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Error: Unsupported Pixel Format.
semaphore created
semaphore signaled
[2021:11:14:08:50:16]: Info: Color coding [Rec. 601]
[2021:11:14:08:50:16]: Info: Color range: [JPEG]
semaphore created
semaphore signaled
[2021:11:14:08:50:17]: Warning: software: h264: replacing nalu prefix data
[2021:11:14:08:50:17]: Info: 
[2021:11:14:08:50:17]: Info: //////////////////////////////////////////////////////////////
[2021:11:14:08:50:17]: Info: //                                                          //
[2021:11:14:08:50:17]: Info: // Ignore any errors mentioned above, they are not relevant //
[2021:11:14:08:50:17]: Info: //                                                          //
[2021:11:14:08:50:17]: Info: //////////////////////////////////////////////////////////////
[2021:11:14:08:50:17]: Info: 
[2021:11:14:08:50:17]: Info: Found encoder software: [libx264]
[2021:11:14:08:50:17]: Error: Couldn't find any of the following libraries: [libavahi-common.3.dylib, libavahi-common.dylib]
[2021:11:14:08:50:17]: Info: Configuration UI available at [https://localhost:47990]

abusse commented 3 years ago

@sajty just to make absolutely sure that we don't have a permissions issue: Are you sure that the sunshine binary is allowed to record the screen (Systems Preferences -> Privacy -> Screen Recording). If this is missing, it would present the behavior as you described. When running with lldb it probably uses a different set of privacy settings. I didn't have time yet, to include a detection logic with a nice user information about that issue.

As I see that you are already editing the code, you could also try to change DISPATCH_TIME_FOREVER to dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC) in dummy_img function. This will avoid a deadlock, but only work if the privacy permissions are correct.

sajty commented 3 years ago

@abusse Sunshine has screen recording permission, but if I remove the permission, then without lldb it is not even getting to the point to ask me for permission. So the access pop-up is only showing on lldb runs, but after adding it, it is not showing on lldb runs again, unless I change the binary.

I have tried the proposed changes, but it ends in a segfault with the following backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x168001061a2b90)
  * frame #0: 0x000000019abb7240 libobjc.A.dylib`objc_msgSend + 32
    frame #1: 0x000000019bd1ce9c Foundation`empty + 76
    frame #2: 0x000000019bbb8258 Foundation`dealloc + 52
    frame #3: 0x000000019bbb81d8 Foundation`-[NSConcreteMapTable dealloc] + 84
    frame #4: 0x0000000104b73e38 sunshine`-[AVVideo dealloc] + 60
    frame #5: 0x0000000104b760f8 sunshine`platf::av_display_t::~av_display_t() + 40
    frame #6: 0x0000000104b45944 sunshine`video::reset_display(std::__1::shared_ptr<platf::display_t>&, AVHWDeviceType, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) + 524
    frame #7: 0x0000000104b4c834 sunshine`video::validate_config(std::__1::shared_ptr<platf::display_t>&, video::encoder_t const&, video::config_t const&) + 60
    frame #8: 0x0000000104b4cf0c sunshine`video::validate_encoder(video::encoder_t&) + 440
    frame #9: 0x0000000104b4de50 sunshine`video::init() + 1084
    frame #10: 0x0000000104a97f00 sunshine`main + 3100
    frame #11: 0x000000019ad3d430 libdyld.dylib`start + 4

abusse commented 3 years ago

@sajty Unfortunately, the permission system is not very reliable and I had to reset it several times during development. Fortunately, since Big Sur, it seems to have become easy to check for the screen capture permission. I just pushed a patch that checks if the permission is given or not. Please test it and let me know. If it doesn't complain about missing screen capture permission, I have to dig deeper to find the issue.

sajty commented 3 years ago

@abusse Thanks! That pointed out the issue! Now it works! :) It turned out that I need to add screen recording permission to the Terminal, when running it directly. Maybe the issue is that sunshine doesn't have a Bundle ID, so it is using the parent process's Bundle ID? I need to use this command to see the request again: tccutil reset ScreenCapture com.apple.Terminal

abusse commented 3 years ago

@sajty yeah, as I said the permissions management is less than optimal. But at least now we have some feedback for the user...getting closer to something stable one bug at a time...

@Nyarumi Sorry, I almost overlook your answer. Feel free to test as much as you like and to give as much feedback and suggestions as possible. I'm at a point where everything works for me, but there are still a million bugs left for sure that will, however, only show up with different use cases that I haven't foreseen.

DevSrSouza commented 3 years ago

This would be really awesome project to use for accessing in a MacOS VMs, in the same machine (with GPU passthrough) or in the home network. The currently applications, for example NoMachine, have a really really bad image quality.

fragtion commented 2 years ago

Hi. I tried running the macos-dev fork using the Macports method

First problem I ran into is /opt/local/etc/sunshine/apps_mac.json didn't exist. So i moved apps.json to apps_mac.json.

Next problem is, ~/.config/sunshine/sunshine_state.json was not created on first run, and got an error that the file does not exist.

Tried to change password with the WEB UI but it's not working because of this.

How to get past this issue? Thanks

Edit: I launched sunshine with --creds argument with user and password parameters and now its fine !

Edit #2: Seems to be working great, except for a problem with the mouse cursor which is offset to bottom-right from the actual (client-side) mouse cursor. Using Moonlight, press CTRL+ALT+SHIFT+C to see what I mean.. Could this have something to do with resolution difference perhaps ... mouse acceleration? IDK. Web UI is also not rendering correctly. Other than that, this is is awesome - huge potential here and on the verge of a breakthrough release :). Thank you all contributors for the great work.

abusse commented 2 years ago

Hi,

so regarding the creds and web UI: the Portfile missed to install some files. I updated the Portfile and everything regarding that should work again (including the UI rendering).

Regarding the mouse issue: Are you using relative or absolute mouse mode? I think it's called something like "optimize mouse for Remote Desktop" in the UI if I remember right.

fragtion commented 2 years ago

Yes that option is checked It's something else causing the offset unfortunately

shoesio commented 2 years ago

Any chance of gamepad support for Mac? Would love to use this for game streaming...

abusse commented 2 years ago

@fragtion Sorry for not coming back earlier to you, but I haven't been able to reproduce the issue you mentioned. Can you maybe give me more information regarding your setup, e.g., macOS version, client OS, resolutions client/server, etc.?

@shoesio I already looked into that, however, there seem to be no easy way to emulate a game pad in macOS. If someone has an idea or a direction to look into, I would happily revisit that issue.

shoesio commented 2 years ago

Would this be of any use? https://github.com/360Controller/360Controller

fragtion commented 2 years ago

@fragtion Sorry for not coming back earlier to you, but I haven't been able to reproduce the issue you mentioned. Can you maybe give me more information regarding your setup, e.g., macOS version, client OS, resolutions client/server, etc.?

Hey @abusse thanks for following up on this. Here's a screen cap of the issue in action: https://youtu.be/8gY0Y3duVMU

I don't personally own a Mac, this is me logging into my dad's macbook pro remotely/on another continent (around 280ms latency)

You can see I am able to get the mouse to any part of the remote display, but the strange acceleration bug, combined with the high latency slows down my ability to work (although I still use it even in this state, because it's more responsive than other solutions like RDP, AnyDesk, or VNC).

One of the main benefits/advantages of showing the local cursor (CTRL+SHIFT+C in Moonlight), is to overcome the impediment of high latency. For example, I can move the local cursor and click, knowing that it will take around 280ms to show me the result visually (but in half of that time the action would have reliably happened on the remote device already). But if the two cursors aren't aligned, you need to wait before you can click anything which kind of defeats this objective

If the mouse cursor is at the top of the screen on the client portal, it's at the top of the screen on the remote device If the mouse cursor is at the half way down the screen on the client portal, it's already all the way at the bottom of the screen on the remote device Same effect for horizontal. Seems to be doing some kind of 2:1 ratio acceleration, idk

Some info about the device is present in the video where I open the 'About My Mac' section. Let me know if there's anything else I should check and get back to you or how else I can help diagnose and test the issue further.

I didn't try other resolutions or windowed/full screen modes for the screen capture video, because I can confirm on good faith that the issue happens the same way regardless of those settings in Moonlight (although I am open to testing other settings on the Mac). From my Windows Client PC side, nothing out of the ordinary with mouse or mouse accel etc, I can remote into any other windows PC's with Moonlight without the issue showing up even on different resolutions etc.

I think we have good reason to think that it has something to do with the mouse capture implementation of sunshine daemon running on the Mac (server) side and how that is being correlated to the input coming from the client

Thank you for your continued works on this project.

abusse commented 2 years ago

@shoesio unfortunately that doesn't work as it is a driver for Xbox360. Even tough on Windows (and maybe Linux?) that controller is emulated that is basically just a random choice. What we need is an emulation of the controller. That doesn't have to be necessarily an Xbox controller.

@fragtion First of all I'm glad to see that it even works somehow for the new MacBook Pros with the notch since they have some odd resolution. From the video it looks a little like a scaling issue. Is my assumption right that the local and remote cursor align at the top left and are half the display apart on the bottom right? Are you having some resolution scaling on the Windows side as well?

fragtion commented 2 years ago

From the video it looks a little like a scaling issue. Is my assumption right that the local and remote cursor align at the top left and are half the display apart on the bottom right?

Correct. Top left is where they two cursors are closest together. Bottom right is where they're most divergent. The mac cursor hits bottom right of its display when local cursor is still half way, so it's like the distance moves further apart exponentially as you move progressively further from the top left corner

Are you having some resolution scaling on the Windows side as well?

No. Standard 1920x1080p with default windows zoom on 23inch display

Btw here's the output from the recorded session from the mac terminal if it helps any: https://pastebin.com/JN2MwuC8

abusse commented 2 years ago

Ah yes, I might have an idea then. I don't know when I have time to work on it though...I will let you know when I come up with something.

Good point that you mentioned the terminal output. The one you posted is not helpful, but you could set the logging level to debug in the Sunshine conf file. Be warned, there will be ALOT of additional output. The interesting part for me is the output at the time when the cursor moves around in the top left and the bottom right. This way I can see what comes in and see what the code makes out of it afterwards.

fragtion commented 2 years ago

Ah yes, I might have an idea then. I don't know when I have time to work on it though...I will let you know when I come up with something.

No problem, and no rush. This is completely understood :)

One thing I just noticed already with debug mode is:

[2022:01:30:12:09:25]: Debug: Display 1, pixel dimention: 1728x1117

While the resolution for the retina display, is 3456 x 2234 (exactly twice the detected amount). Smoking gun if you ask me

P.S. @loki-47-6F-64 : "dimention" is spelt wrong there also and should be "dimensions" ;)

Maybe this is all we need to know? Should I still try post full debug log? you can let me know if it's still needed ;)

abusse commented 2 years ago

That should be ok, because it's the resolution it is scaled to. What is of interest to me are the mouse move packets.

shoesio commented 2 years ago

Can't make this branch build over here. Is it compatible with Monterey do we know?

abusse commented 2 years ago

@shoesio I'm developing on Monterey, so it should work. What issue are you facing?

shoesio commented 2 years ago

(I think!) Everything looks good up to the actual make and then the output of that is here: https://pastebin.com/h3kruRWD

"make[1]: [CMakeFiles/sunshine.dir/all] Error 2 make: [all] Error 2"

abusse commented 2 years ago

@shoesio The problem is that you are building the Linux version. Platform detection should work automatically. What branch/commit are you using?

shoesio commented 2 years ago

Ah ok, I’m pretty sure I followed the instructions in the mac section of the readme? Can you double check the clone instruction is right down there?

https://github.com/abusse/sunshine/tree/macos-dev

edit - I tried swapping in what I assume is the correct git address: https://github.com/abusse/sunshine.git but got a similar result :(

J

On Wed, 2 Feb 2022 at 20:27, Anselm Busse @.***> wrote:

@shoesio https://github.com/shoesio The problem is that you are building the Linux version. Platform detection should work automatically. What branch/commit are you using?

— Reply to this email directly, view it on GitHub https://github.com/loki-47-6F-64/sunshine/issues/127#issuecomment-1028329034, or unsubscribe https://github.com/notifications/unsubscribe-auth/APQT5OLMSXQJYRD6L46DYVLUZGHUPANCNFSM5AGCBBUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

abusse commented 2 years ago

Ah yes sorry, the developer documentation is already prepared for a pull request. Besides my repository you have to switch to the macos-dev branch via git checkout macos-dev after the checkout.

shoesio commented 2 years ago

You've lost me there, i get "fatal: not a git repository (or any of the parent directories): .git" if I stab that into terminal after the clone command?

abusse commented 2 years ago

You have to run the command in the directory where the source code was cloned to.

shoesio commented 2 years ago

now cmake fails with: "-- Configuring done CMake Error at CMakeLists.txt:424 (add_executable): Cannot find source file:

sunshine/platform/macos/TPCircularBuffer/TPCircularBuffer.c

Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc

CMake Error at CMakeLists.txt:424 (add_executable): No SOURCES given to target: sunshine"

(plus a load of other stuff, but that bit was in red!)

abusse commented 2 years ago

Try git submodule update --init --recursive in the directory with the source code. That should pull the missing files.

shoesio commented 2 years ago

OK, that made the build file work ok, but the compile still failed :(

"Undefined symbols for architecture x86_64: "_EVP_DigestSignUpdate", referenced from: crypto::sign(util::uniq_ptr<evp_pkey_st, util::Destroy<evp_pkey_st, void, &(EVP_PKEY_free)> > const&, std::1::basic_string_view<char, std::1::char_traits > const&, evp_md_st const) in crypto.cpp.o "_EVP_DigestVerifyUpdate", referenced from: crypto::verify(util::uniq_ptr<x509_st, util::Destroy<x509_st, void, &(X509_free)> > const&, std::1::basic_string_view<char, std::1::char_traits > const&, std::1::basic_string_view<char, std::1::char_traits > const&, evp_md_st const) in crypto.cpp.o "_SSL_get1_peer_certificate", referenced from: std::1::function::__func<nvhttp::start()::$_4, std::__1::allocator<nvhttp::start()::$_4>, int (ssl_st)>::operator()(ssl_st&&) in nvhttp.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: [sunshine] Error 1 make[1]: [CMakeFiles/sunshine.dir/all] Error 2 make: *** [all] Error 2"

Sorry for spamming up the thread.

abusse commented 2 years ago

Can you post the whole build run to pastebin?

shoesio commented 2 years ago

Sure - thanks for helping :)

https://pastebin.com/FtjUBX53

abusse commented 2 years ago

No problem. Can you redo the whole thing and build with make VERBOSE=1 and also include the commands you run in the pastebin?

shoesio commented 2 years ago

Here's the megapaste! https://pastebin.com/95tmqZkr