Kualiti penstriman, konfigurasi input dan kekunci pintas mengatasi...
mempunyai persekitaran yang boleh digunakan pada tablet ke program (dengan emacs).
Gunakan tablet sebagai klien nipis untuk persediaan desktop yang betul.
VNC dan RDP kelihatan agak perlahan, tetapi harus menjadi yang paling mesra bateri, RDP sepatutnya lebih baik pada Windows sekurang-kurangnya.
Splashtop kelihatan di suatu tempat di tengah, bukan kependaman yang hebat dan kadar bingkai yang rendah, tetapi kawalan input yang baik.
NOMesin (Protokol NX) kelihatan lebih baik sedikit daripada splashtop, lebih boleh dikonfigurasikan dan fleksibel daripada splashtop.
Cahaya bulan (pelanggan) dan cahaya matahari (pelayan) (Saya mempunyai AMD R9 290 lama) nampaknya berfungsi dengan baik pada 30FPS, manakala pada 60FPS ia mempunyai kependaman yang besar.
Parsec . Yang ini nampaknya mempunyai kependaman terbaik (pada 60FPS) tetapi saya belum menguji penggunaan bateri, pada masa ini ia adalah yang saya gunakan.
Saya menggunakan papan kekunci mekanikal tablet /w kerana komputer riba dengan papan kekunci mekanikal yang baik sebenarnya tidak wujud...adakah? Atau jika ia wujud, ia mahal dan papan kekuncinya ratabagaimanapun. Memastikan skrin pada sudut tontonan yang betul memerlukan dirian, atau salah satu pemegang dengan rod boleh dibengkokkan, dengan genggaman magnetik atau pengapit.
Saya melampirkan papan kekunci mekanikal pada tablet, dengan penukar OTG . Bluetooth juga baik... Masalahnya ialah beberapa peta android agak biasa pintasan yang digunakan pada tingkap, yang menggunakan sama adaMETA (ALT ) atauMETA (kunci tingkap). Dan tidak menyediakan cara untuk melumpuhkan mereka. KeyMapper sebahagiannya berfungsi, kerana ia boleh melumpuhkan tindakan dari sisi android, tetapi saya masih tidak dapat memajukan gabungan kekunci.
Adakah menggunakan pelanggan jauh semuanya baik? Mungkin menggunakan emacs terus pada android dan menggunakan keupayaan jauh emacs adalah persediaan yang lebih serasi? Untuk memasang emacs pada android anda perlu menggunakan chroots. UserLand memudahkan untuk mencipta chroot pengedaran biasa dan terus memulakan XServer. Walau bagaimanapun, mempunyai pengalaman emacs yang betul masih memerlukan banyak konfigurasi. Adakah emacs-nox pada termux lebih baik daripada emacs-gtk melalui userland/VNC? Termux mempunyai sokongan untuk aplikasi x11 . Ia menggunakan Xwayland untuk menyediakan sokongan X11 untuk apl, ia nampaknya jauh lebih pantas daripada pelayan xsdl x11, kerana (saya rasa) ia menggunakan memori kongsi untuk penimbalan strim (bukannya soket TCP atau unix). Masih tiada sokongan pecutan HW, tablet saya juga mempunyai GPU POWERVR yang masih tidak mempunyai sebarang bentuk pemacu sumber terbuka (tetapi nampaknya ia dijadualkan akan dikeluarkan di suatu tempat pada Q2 2022). Saya juga telah berjaya menjalankan a linuxdeploychroot dikonfigurasikan yang tidak mempunyai overhed proot di atas pelayan termux-x11. Walau bagaimanapun chroot mesti sepadan dengan versi wayland (dan mungkin mesa juga) termux.
Memandangkan kos konfigurasi untuk menjalankan emac pada tablet android, pada masa ini sesi jauh masih lebih mudah. Jika usaha termux X11 ditambah dengan keluaran pemacu powervr akhirnya berjaya, baki mungkin beralih ke persediaan asli.
Jika emacs mempunyai sokongan untuk timbunan grafik android Ia tidak akan menjadi banyak pilihan lagi, tetapi itu tidak berlaku, dan nampaknya tiada minat terhadapnya, (terdapat juga sifar minat dalam antara muka sentuh, jadi yang terbaik pilihan untuk menggunakan emac pada peranti pegang tangan tanpa papan kekunci yang betul pada ketika ini ialah emacspeak).
NixOnDroid boleh meringankan kesakitan konfigurasi untuk menambah semua perkakas yang diperlukan oleh emacs, sama ada itu atau sokongan nix yang akan datang untukarm64.
Masih terdapat masalah beberapa pintasan papan kekunci yang tidak melaluinya, yang penyelesaian biasa adalah dengan memetakannya ke pintasan lain, untungnya terdapat pintasan yang sangat berkuasa aplikasi pemetaan kunci untuk android . Saya perlu menyemak penggunaan bateri parsec, dan jika ia terlalu tinggi, saya akan mempertimbangkan sama ada RDP biasa, atau ringkas sesi ssh jauh dengan emacsi dalam terminal.
