miracle-sinkctl without /etc/dbus-1/system.d/?

[pinuke]

We seem to have hit a roadblock at Chromebrew on the port of miraclecast to Chrome OS

• Add miraclecast package chromebrew/chromebrew#7893
• Add miraclecast package chromebrew/chromebrew#7893 (comment)

Chrome OS has this directory as readonly as a security measure:

• https://chromium.googlesource.com/chromiumos/docs/+/master/write_protection.md

Using that same article, I could disable the write-protection and write the .conf to it:

• /etc/dbus-1/system.d/org.freedesktop.miracle.conf

But I'm sure most Chromebook users would like to avoid disabling that. Additionally, that's only possible on a limited selection of Chromebooks.

Is there a way to run miracle-sinkctl without that write access?

[pinuke]

relevant - chromebrew/chromebrew#7892

[pinuke]

If this is possible, from an initial code search, it looks like it may be possible to change where cmake builds the files to:

• Add miraclecast package chromebrew/chromebrew#7893 (comment)

It will require cmake to be run with a custom -DCMAKE_INSTALL_SYSCONFDIR parameter

• https://stackoverflow.com/questions/41024820/how-do-you-control-the-location-of-header-files-in-cmake

Now whether or not miracle-wifid will find the file, and be able to use it is a different story

[albfan]

This file needs to be somewhere where systemd package can read it.

Is there any other example where a chrome OS package provides a systemd service? As you found CMAKE_INSTALL_SYSCONFDIR is the way to customize its installation path.

[albfan]

Looks to me the path is /opt/google/chrome/dbus

https://chromium.googlesource.com/chromiumos/docs/+/master/dbus_in_chrome.md#Creating-Chrome-D_Bus-services

[pinuke]

Looks to me the path is /opt/google/chrome/dbus

https://chromium.googlesource.com/chromiumos/docs/+/master/dbus_in_chrome.md#Creating-Chrome-D_Bus-services

From the docs, it appears that you need build access to make use of that path.

Building ChromeOS from source is not a recommended solution for these issues, as the public can't build ChromeOS from source, just ChromiumOS and ChromeOS Flex (which both are stripped down of Google-only features)

I'll have to powerwash my chromebook and reset my write access to do test that. I'm more interested in forking miraclecast, and rewriting miracle-wifid to play more nicely with ChromeOS

[albfan]

it's ok to support chrome os, but you need to figure out how to do that, many packages uses dbus, so should be a way to add a dbus service.

if it's not possible, I'm unsure if rewrite all makes sense, that would be basically a different project

[pinuke]

many packages uses dbus, so should be a way to add a dbus service.

The issue isn't a lack of a dbus. It's that ChromeOS locks the system dbus down.

The system dbus is there. It just can't be modified without circumventing ChromeOS security.

ChromeOS locks down most of its system utilities to pretty much prevent any malware from working on it or being installed permanently. Because of its read-only root file system, ChromeOS can simply be power-washed/updated to remove any custom software or malware from the machine.

Currently, the only way to get miraclecast to work is to disable the readonly rootfs, so that you can modify the system dbus.

[albfan]

if the only option is to hack chromeOS I think this is a no-go.

Not using dbus is in fact a different implementation of miracast spec

My suggestion is to abbandon the port

[pinuke]

Not using dbus is in fact a different implementation of miracast spec

I don't know about that (that would imply that miracast doesn't work on Windows). I'll have to dig into finding the source spec, but I don't see why it wouldn't be possible to find another IPC method. As far as I can tell miracast is just a layer on top of the WiFi Direct specification. Technically, WiDi doesn't require the dbus, it's just commonly built on top of it.

if the only option is to hack chromeOS I think this is a no-go.

It's not hacking. The end-user owns the product, so disabling write-protect is built into all Chromebooks - Google. The issue is that it voids warranty.

I'd like to port it as a proof-of-concept to Google. If I can prove that it works on Chrome OS without voiding warranty or modifying the rootfs, then there's a case to merge miraclecast into the CrOS source code.

This would add the ability to use Chromebooks as an external touchscreen monitor (using UIBC). That would be an amazing feature.

My suggestion is to abandon the port

I haven't hit a wall yet from porting it, so no.

If I do find anything, I will let you know. I do understand if you don't believe me (Chrome OS has been historically an extremely locked-down OS).

I just believe that I can make this work. I've got a pretty good grasp of how low-level specifications work/are implemented from my experience in the engineering field. I've also been doing this kind of stuff to Chromebooks for about 11 years now.

[albfan]

I think you talk about lot of offtopic questions here.

If the only way to use new dbus services in chromeOS is to change that write protect, issue solved. From point of view of miraclecast there's nothing else to discuss. issue must be closed.

If you do not close it, I suppose is because you plan to remove dbus on miraclecast ,and I just inform you that is not an option.

miraclecast is an implementation of a specification (miracast) as microsoft implementation is.

Of course you can implement miracast without dbus, but that would be another project, not miraclecast.

If you want to see what I mean, if you port miraclecast to java, that's ok, but that is just a different implementation, and open isssues here has no point.

[AtesComp]

Strictly speaking, DBus is NOT part of the Miracast specification, but Miracast used it none the less and is bound to it by the project. Therefore, it's quite a double standard to suggest your position is anywhere near correct. By the extremely long term issues that remain open, half the specification is not even clearly supported.

To enhance Miraclecast by separating it's dependency strictly to DBus should be a supported endeavour. Being dismissive of such an effort is extremely ignorant. The fact that Miraclecast has failed to become an integral Linux application project during it's long time development without a release should be a clear indication that it needs fresh eyes and input.

You should be less concerned about open issues and more concerned about the quality of the software. Arbitrarily closing issues is meaningless when the project is clearly lacking constructive guidance.

[pinuke]

It's not that big of a deal tbh. I can always continue commenting if it gets closed.

My intention is to reuse miraclecast source code, so I don't exactly plan to drop the discussion here, and I do see keeping limitations on miraclecast causing the project issues down the road.

However, I don't see that as a reason to keep it open. If the developer doesn't want to support that now, it's OK. I can always fork the repo and rewrite it myself.

He did say that he's willing to look at a PR.

So, no complaints from me if he closes it.

[albfan]

If this helps to understand how open source works, great, because you're getting it all wrong.

A specification this a description how how something should work. That is miracast.

An implementation is to code a solution matching an specification. Miraclecast is an implementation that uses dbus.

You want to port miraclecast to Chrome OS, you're welcome. There's a technical debt you cannot bypass? (not use dbus) cannot help there.

Is not on me to close the issue. Is on you if you don't find a solution to port it to Chrome OS.

Support the package in all distros is not a duty for this project, we can help as much as we can, but maintaners of those packages needs to find reasonable solutions.

Open an issue is not a silver bullet, sometimes It cannot be solved

[pinuke]

@albfan is that for me or for @AtesComp? It doesn't bother me that you don't want to steer miraclecast towards dropping the dbus. I just want to keep the conversation open, since I want to reuse your source code (or possibly share any improvements via PR).

Closing the issue is also fine with me, I can still comment even if the issue is closed.

I just want to make sure that I'm openly communicating with you, since I'm reusing your source code.

[pinuke]

FR: @AtesComp

Strictly speaking, DBus is NOT part of the Miracast specification, but Miracast used it none the less and is bound to it by the project.
...
To enhance Miraclecast by separating it's dependency strictly to DBus should be a supported endeavour.

...and FR: @albfan:

An implementation is to code a solution matching an specification. Miraclecast is an implementation that uses dbus.

I was thinking that a solution could be to implement the dbus using interface(s) within the Miraclecast code (perhaps as a library). This would still keep the dbus as the main IPC method within Miraclecast's code, but would also achieve inversion of control over the IPC method used.

@albfan I know you're from spain, so I'll try to reword that in case I'm not using the best English:

Writing the dbus-dependent code as a library/interface would loosen its coupling to miraclecast. This loose-coupling would then allow the dbus to still be the main IPC method, but allow contributors to replace it with another.

What do you fellas think? I could make that rewrite and submit it as pull? Perhaps start a new testing branch once I start working on it.

[spoelstraethan]

@pinuke I'd definitely be interested in helping test this as I've got enough Chromebooks to outfit an army (of developers) and miracast + UIBC would double or triple how much I value and use my Chromebooks, and given the fact that they are already my primary work and personal devices, that's a lot.