I just tested scrcpy which works really well for seeing and controlling an android device from my computer. It would be awesome if KDE connect could reuse the code/ideas to have the same feature but without the need to activate adb and to plug in USB. I also opened a ticket on their side: https://github.com/Genymobile/scrcpy/issues/13
*** 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. ***