Bug 391624

*** Bug 413774 has been marked as a duplicate of this bug. ***

*** Bug 425913 has been marked as a duplicate of this bug. ***

If there was an easy way to achieve scrcpy's functionality without requiring adb I'm sure its developers would have found it, so I don't see us implementing that.

Another possible option could be MiraCast, but as far as I know there are no good Linux implementations and I'm definitly not going to do that myself

*** This bug has been marked as a duplicate of bug 345483 ***

*** Bug 345483 has been marked as a duplicate of this bug. ***

I may be mistaking but from what I understood scrcpy is using adb to push an application on the phone, which serves as a screensharing server. I thought it was possible to use KDE connect as the screensharing server instead and use its communication canal instead of the usb.

But I may have misunderstood how scrcpy uses adb.

(In reply to Côme Chilliet from comment #6)
> I may be mistaking but from what I understood scrcpy is using adb to push an
> application on the phone, which serves as a screensharing server.

It says in https://github.com/Genymobile/scrcpy/issues/13:

> adb is required to call adb shell to have shell permissions granted (to capture the screen).
> 
> (instead, it could be an app using MediaProjection requesting the permission to the user, but then, this would be a different app).

So it seems that `adb` has a second use, here.

Should sharing the screen of the PC side to the phone side be here too, or should it be a different bug/feature request? Seems like it'd be a natural extension to the existing remote input feature, although I guess that would kind of overlap with VNC and Krfb.

Would like to add my stone here :-=)

Enabling adb is acceptable for our target user I think
When wireless adb is enabled on the phone  , Kdeconnect could srccpy directly to the phone IP which is already known
So this feature is really low on code impact , even maybe easier enough I could give a try :-)

Created attachment 155320 [details]
attachment-20881-0.html

Relying upon adb is fine for some (power) users, but isn't really
acceptable for random consumer users. Better than nothing, but imho not
really a consumer grade product solution.

M

On Mon, 9 Jan 2023 at 13:22, michel Ekimia <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=391624
>
> michel Ekimia <mm@ekimia.fr> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|REPORTED                    |CONFIRMED
>      Ever confirmed|0                           |1
>                  CC|                            |mm@ekimia.fr
>
> --- Comment #9 from michel Ekimia <mm@ekimia.fr> ---
> Would like to add my stone here :-=)
>
> Enabling adb is acceptable for our target user I think
> When wireless adb is enabled on the phone  , Kdeconnect could srccpy
> directly
> to the phone IP which is already known
> So this feature is really low on code impact , even maybe easier enough I
> could
> give a try :-)
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

This should be at wishlist importance.

As mentioned by the scrcpy author, the MediaProjection API is what would be more applicable here:
https://developer.android.com/reference/android/media/projection/MediaProjection

Do note though that the usability would be limited, it wouldn't be anything like desktop remote control as phone OSes in general including Android are a minefield of user limitations, even scrcpy couldn't overcome restrictions controlling what's allowed to be recorded:
https://github.com/Genymobile/scrcpy/issues/36

*** Bug 474247 has been marked as a duplicate of this bug. ***

kde connect can have only screen mirroring via media projection and if a user want to have controls also they can enable it via developer option.

adding sharing potions first should be a nice start