rom1v is a user on hostux.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
rom1v @rom1v@hostux.social
Follow

Hey, nous venons de publier une appli que j'ai développée pour afficher et contrôler un device Android à partir du PC:

blog.rom1v.com/2018/03/introdu
github.com/Genymobile/scrcpy

· Web · 6 · 1

@rom1v @valere

Ah. KdeConnect fait la même chose dans le sens inverse.

@rom1v Comment on fait pour installer dans /usr/ au lieu de /usr/local?

@rom1v haha j’ai trouvé en fait, j’ai eu l’idée de regarder la doc de Meson y a une seconde

@rom1v Je t'envoie ce message depuis scrcpy compilé sur Arch Linux! Par contre y a plein de caractères comme €«» etc. qui ne passent pas?

@melunaka \o/ Ouais, il y a un workaround pour les caractères accentués (et encore, je me suis aperçu aujourd'hui qu'il ne fonctionnait pas avec les claviers google), mais pour les autres caractères non-ASCII, je n'ai pas de solution.

cf blog.rom1v.com/2018/03/introdu

@rom1v Je crois que KDEConnect gère mieux ça. Tu as regardé comment ils font?

@melunaka Mon collègue @agateau vient de me faire une démo de KDEConnect, c'est cool! Par contre, je pense qu'il ne permet pas d'envoyer des événements clavier du PC vers le device (c'est dans l'autre sens).

@rom1v @agateau Ah oui en effet, je me suis emmêlé les pinceaux ^^ Y a pas moyen de simuler un clavier physique branché à l'appareil? Ou pour les caractères, envoyer son code unicode, ou c'est complètement impossible?

C'est vrai que faire le lien niveau périphériques d'entrée entre deux systèmes a l'air bien relou…

@melunaka Techniquement, il est possible d'envoyer des événements clavier USB en utilisant AOA: source.android.com/devices/acc

Y'a même pas besoin d'adb d'ailleurs pour ça :)

J'ai déjà implémenté le forward d'événements clavier et souris (dans une appli pas open source) en utilisant AOA, mais ça apporte son lot de problèmes (c'est de la communication sur USB, multiplateforme difficile, etc).

Et au passage, ça ne marche pas pour les devices avec un kernel 3.18: github.com/rom1v/aoa-hid-bug

@melunaka Et comme je "forwardais" uniquement les événements USB (y'aurait du boulot et de la lecture de doc pour les générer), ce que j'ai fait ne marche qu'avec les claviers et souris USB (donc pas le clavier d'un laptop), et pas sans fil (car y'a des couches intermédiaires). Mais c'est cool quand même.

@melunaka Pour envoyer son code unicode, avec certains claviers (mais pas le clavier virtuel auquel je peux accéder), il est possible d'envoyer son code suivi de \uef00 (souvent bindé à Ctrl+Shift+X). Par exemple, pour envoyer "e", "0065\uef00".

@rom1v Je comprends pas bien le rapport avec le clavier virtuel, ça marche aussi avec AnySoftKeyboard chez moi

@melunaka Concrètement:

KeyCharacterMap charMap = KeyCharacterMap.load(KeyCharacterMap.VIRTUAL_KEYBOARD);
KeyEvent[] events = charMap.getEvents("0065\uef00".toCharArray());

// events est null!

@rom1v on pourrait donc créer une application de clavier virtuel qui servirait uniquement à produire les caractères qu'il recevrait de scrcpy? évidemment je me doute que ça nécessiterait du temps à faire ^^

@melunaka Et ça ferait une appli à installer, un clavier à configurer… Y'a le même problème avec UIAutomator (qui ne sait injecter que des caractères ASCII), et ce contournement: github.com/sumio/uiautomator-u

@rom1v oui oui, je comprends bien que c’est galère, c’était plus par curiosité du fonctionnement d’Android et des difficultés techniques du truc :)

@rom1v J’ai fait un paquet AUR pour Arch Linux, j’attends d’être chez moi pour le mettre en ligne :)

@rom1v nope, moi je voulais pas me casser le cul à installer le Android-SDK donc mon paquet utilise le serveur précompilé mais hier j'ai pas dormi chez moi donc j'ai pas pu m'en occuper x)