Sistem operasi
Server: Apa saja (Linux?)
Klien: Apa saja (Windows?)
Versi Penghalang
Setiap
Langkah-langkah untuk mereproduksi bug
- Buka keyboard di layar pada klien Windows - ini menyoroti tombol pengubah yang saat ini ditekan
- Tekan LSHIFT, LCTRL, LALT, RALT, RCTRL, RSHIFT
- Perhatikan bahwa hanya RALT yang tidak menyala saat ditekan
Info lain
Saya hanya menggunakan satu bahasa selain bahasa Inggris, tetapi saya pikir menyelesaikan masalah ini juga dapat menutup banyak bahasa lain yang terkait dengan tata letak keyboard dan mengetik karakter non-latin.
Bahasa Polandia ditulis dengan alfabet Polandia standar, yang memiliki sembilan tambahan pada huruf-huruf dari aksara Latin dasar (ą, , , , , ó, , , ).
Misalnya, untuk mengetik ą , saya harus menekan RALT+a . Itu berfungsi pada Host, tetapi tidak pada klien. Ketika saya mengaktifkan alt kanan secara manual (melalui keyboard di layar), itu berfungsi seperti yang diharapkan.
Saya menduga bahwa Windows menggunakan kode kunci lain untuk RALT daripada Linux, dan itu mengabaikan apa pun yang sedang dikirim.
key ef7e is not on keyboard
adalah apa yang saya dapatkan dari DEBUG1 di klien.
wjtk4444
Semua 4 komentar
Jadi, setelah (dua?) tahun menggunakan Barrier (dan garpu sinergi lainnya) hampir setiap hari, saya akhirnya menyadari ada opsi untuk mengkonfigurasinya dengan file .conf . Rupanya, ini memungkinkan seseorang untuk memetakan kembali kunci sesuka hati. Lebih baik terlambat dari pada tidak sama sekali.
Melihat beberapa utas masalah sambil juga mencoba berbagai hal dan gagal (banyak), itulah dua baris yang memperbaiki masalah. Sepertinya tidak masuk akal (jika ada, saya berharap altgr = alt berfungsi alih-alih ini), tetapi itu hanya berfungsi.
section: screens
linux:
windows7:
meta = altgr
altgr = shift
end
Jadi, sepertinya
- masalahnya bisa diatasi
- Saya bodoh karena tidak membaca file readme
manual f@!#ingsebelumnya
Tidak yakin apakah ada gunanya membiarkan yang ini tetap terbuka - bukan bug khusus Penghalang dan itu sudah dilaporkan dan dijelaskan dengan cukup baik di sinergi-core . Saya membiarkan keputusan apakah akan menutup atau membiarkan yang ini terbuka untuk pengelola repositori.
wjtk4444
pada 20 Sep 2019
@AdrianKoshka Apakah masuk akal untuk menutup masalah?
p12tic
pada 21 Sep 2019
Saya kira begitu, jika masalah ini perlu dibuka kembali, bisa saja.
AdrianKoshka
pada 21 Sep 2019
Ini menyelamatkan saya dari kegilaan.
Untuk referensi: Saya menggunakan keyboard mac berkabel di server Linux dan campuran klien Windows10/linux
Elexy
pada 23 Jul 2020
Masalah terkait
technovangelist
·
5Komentar
autotoxicus
·
4Komentar
graingert
·
4Komentar
elig0n
·
3Komentar
jwalton
·
3Komentar
Komentar yang paling membantu
Jadi, setelah (dua?) tahun menggunakan Barrier (dan garpu sinergi lainnya) hampir setiap hari, saya akhirnya menyadari ada opsi untuk mengkonfigurasinya dengan file .conf . Rupanya, ini memungkinkan seseorang untuk memetakan kembali kunci sesuka hati. Lebih baik terlambat dari pada tidak sama sekali.
Melihat beberapa utas masalah sambil juga mencoba berbagai hal dan gagal (banyak), itulah dua baris yang memperbaiki masalah. Sepertinya tidak masuk akal (jika ada, saya berharap
altgr = altberfungsi alih-alih ini), tetapi itu hanya berfungsi.Jadi, sepertinya
manual f@!#ingsebelumnyaTidak yakin apakah ada gunanya membiarkan yang ini tetap terbuka - bukan bug khusus Penghalang dan itu sudah dilaporkan dan dijelaskan dengan cukup baik di sinergi-core . Saya membiarkan keputusan apakah akan menutup atau membiarkan yang ini terbuka untuk pengelola repositori.