Wiki github lama Synnergy membuat saya berpikir bahwa masalah Anda tidak pernah direncanakan, karena tidak ada kunci alt gr yang tercantum dalam panduan konfigurasi teks mereka

shift = {shift | ctrl | alt | meta | super | tidak ada}
ctrl = {shift | ctrl | alt | meta | super | tidak ada}
alt = {shift | ctrl | alt | meta | super | tidak ada}
meta = {shift | ctrl | alt | meta | super | tidak ada}
super = {shift | ctrl | alt | meta | super | tidak ada}
Petakan tombol pengubah yang ditekan di keyboard server ke pengubah lain di klien ini. Opsi ini hanya berpengaruh pada layar klien; itu diterima dan diabaikan di layar server.
Misalnya, Anda dapat memetakan tombol Shift ke Shift (default), Ctrl, Alt, Meta, Super, atau tidak sama sekali. Biasanya, Anda tidak akan memetakan ulang Shift atau Ctrl. Namun, Anda mungkin memiliki server X11 dengan Meta yang terikat ke tombol Alt. Untuk menggunakan server ini secara efektif dengan klien Windows, yang tidak menggunakan Meta tetapi menggunakan Alt secara ekstensif, Anda ingin klien Windows memetakan Meta ke Alt (menggunakan meta = alt).

Punya masalah yang sama di sini! Windows7 (Server) Raspi Rasbian (Klien)

tolong perbaiki :-)

untuk garis miring terbalik saya gunakan sekarang ALT 92

Hai,
Saya memiliki masalah yang sama

bagaimana kami menerapkannya, ini adalah masalah kritis bagi siapa saja yang menggunakan keyboard non-AS.

salam Hormat
Paul

Hai,
Saya telah mengidentifikasi bahwa altgr diteruskan sebagai ctrl + alt (ini setara altgr untuk windows tetapi bukan linux) dan di sanalah masalah dimulai.
Apalagi menambah baik
kotoran = altgr
atau
alt = altgr
di bagian layar (dalam konfigurasi klien) memungkinkan untuk menggunakan tombol pengubah tersebut untuk bekerja sebagai altgr yang tepat sehingga tampaknya lebih banyak masalah pada sisi layanan jendela dan menangkap sinyal altgr asli daripada alt + kontrol karena altgr = anymeta tidak berfungsi di kedua klien atau bagian server
Apalagi alt + ctrl cukup banyak digunakan di linux saat ini (manipulasi ruang kerja fe) sehingga bahkan mencegat ctrl + alt dan mengubahnya kembali ke altgr tampaknya bukan solusi yang tepat.

sebagai solusi sementara di ubuntu menggunakan gnome-tweaks menggunakan
keyboard & mouse / opsi / tombol tata letak tambahan untuk memilih tombol level / menu ke-3
izinkan saya menggunakan tombol menu dari keyboard windows sebagai altgr di klien linux

Saya memiliki masalah yang sama dengan Server Linux, Klien Windows dan keyboard jerman.

Dengan klien windows Anda bisa menambahkan alt = altgr atau altgr = alt di konfigurasi server Anda di bagian windowspc: Anda dan itu seharusnya berfungsi

Pada penyelidikan lebih lanjut, pilihan keymap jendela memiliki dampak yang luar biasa pada bagaimana kunci tersebut dikirimkan. Saya yakin kami tidak menangkap data cukup awal dalam proses dan terjemahan peta kunci dilakukan sebelum kami mendapatkan kode pindai di windows.

Memiliki masalah yang sama server Linux, Klien Windows

Bagi siapa pun yang mencoba membasmi bug ini, ini terlihat mencurigakan:

bool KeySequence::appendKey(int key, int modifiers)
{
    if (m_Sequence.size() == 4)
        return true;

    switch(key)
    {
        case Qt::Key_AltGr:
            return false;
...

Dari baris 115-123 dari KeySequence.cpp

dan saya menemukan beberapa dokumentasi (temukan di halaman Key_AltGr)

Dengan server sinergi (1.8.7-stable) di UbuntuGnome17.04 dan klien (1.8.8-stable) di Win10, baris-baris di synergy.conf ini tampaknya telah membantu saya menggunakan layout keyboard Norwegia termasuk. tombol AltGr {[]} @ etc di Win PC:

section: screens
    mywinpc:
        meta = altgr
        altgr = shift
end

Ini dengan coba-coba. HTH.

Ini memperbaiki masalah pada versi 2.2.0-Release-00000000 (10 Oktober 2018)
Bekerja dengan Linux (Ubuntu 18.10 dengan kernel 4.19.5) dan Windows 10.

Sumber

Saya mengalami masalah serupa tetapi tidak hanya dengan tombol altgr, semua simbol salah. Saya memiliki keyboard yang sama (klien dan server) tetapi misalnya Shift + 0 adalah '=' di server dan '_' di klien. Ini adalah qwerty spanyol dengan keyboard titik tengah. Klien menjalankan Ubuntu 18.04 LTS dan server Windows 10. Ada ide?

Mungkin membuka edisi baru @ Raxe88?

Maaf soal itu. Bagi siapapun yang tertarik saya menemukan solusi untuk masalah saya ini masalah .

Ini masih menjadi masalah dengan 2.2.0, menggunakan server Linux dengan klien Windows 10, dan menggunakan tata letak keyboard Jerman. Karakter seperti @ , \ , atau ~ berada di level kunci ketiga dan perlu AltGr (tombol Alt kanan) untuk dimasukkan.

Pekerjaan saya saat ini menggunakan Alt + Ctrl kiri (yang mengemulasi AltGr di sebagian besar OS) untuk memasukkan karakter ini, tetapi ini sangat tidak nyaman sebagai pengguna keyboard Jerman.

Saya menyelesaikan ini di file konfigurasi dengan mengatur yang berikut:

bagian: layar
windowsmachine1:
meta = altgr
altgr = shift
windowsmachine2:
meta = altgr
altgr = shift
akhir

Ini serangga yang sangat tua. Untuk menyimpulkan:

AltGr misalnya untuk @ at keyboard jerman bekerja dengan Linux-Server dan Windows Client bekerja sebagian:
a) altgr = shift # OK, berdiri sendiri di win10, tetapi tidak di WSL bash @ win10
b) tetapi tidak dengan putty, wsl (Subsistem Windows untuk Linux) misalnya bash, lihat keluaran xev terlampir
c) SOLUSI: sinergi-v1.8.2-stable-36cd521-Windows-x64.msi + # altgr = alt # OK, (win10 + wsl / putty) ... tetapi hanya sinergi <= 1.8.2.

SALAH (dari server linux)

Peristiwa KeyRelease, serial 33, sintetis NO, jendela 0x380001,
root 0x5a5, subw 0x0, waktu 3031843, (80,95), root: (398,436),
status 0x8, kode kunci 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString memberikan 0 byte:
XFilterEvent mengembalikan: False

OK (keyboard klien windows)

Peristiwa KeyRelease, serial 33, sintetis NO, jendela 0x380001,
root 0x5a5, subw 0x0, waktu 3110031, (1237.773), root: (1581,1140),
status 0x80, kode kunci 20 (keysym 0x5c, backslash), same_screen YES,
XLookupString memberikan 1 byte: (5c) "\"
XFilterEvent mengembalikan: False

Dengan server sinergi (1.8.7-stable) di UbuntuGnome17.04 dan klien (1.8.8-stable) di Win10, baris-baris di synergy.conf ini tampaknya telah membantu saya menggunakan layout keyboard Norwegia termasuk. tombol AltGr {[]} @ etc di Win PC:

section: screens
    mywinpc:
        meta = altgr
        altgr = shift
end

Ini dengan coba-coba. HTH.

Ini memperbaiki masalah pada versi 2.2.0-Release-00000000 (10 Oktober 2018)
Bekerja dengan Linux (Ubuntu 18.10 dengan kernel 4.19.5) dan Windows 10.

Sumber

Ini memperbaikinya untuk saya juga di server 2.3.1 Linux dan 2.3.1 Klien Windows. Adakah rencana untuk benar-benar memperbaikinya dengan benar?

Saya hanya ingin memberi tahu Anda bahwa kunci _Alt-Gr_ dan semua orang berfungsi dengan sempurna setelah klien ditangguhkan dan dilanjutkan .

Saya hanya berurusan dengan Linux , karena saya tidak menggunakan penghalang dengan yang lain.

Setup saya:
Kedua Server dan Klien : Arch Linux dengan penghalang 2.3.1 dan tata letak Italia

Untuk referensi, tata letak keyboard Italia .

Langkah:

• Mulai Server
• Mulai Klien
• Mengetik _Alt-Gr + ò_ keluaran _2_ (harus mencetak _ @ _)
• Tangguhkan dan lanjutkan Klien (penangguhan systemctl)
• Mengetik _Alt-Gr + ò_ keluaran _ @_ seperti yang diharapkan

Mungkin ada sesuatu dalam proses resume _triggers_ yang memperbaikinya tetapi saya perlu menyelidikinya.

Aku akan memberitahu Anda.

Ini adalah masalah jendela khusus ketika keymap windows tampaknya diterapkan sebelum tombol dicegat oleh penghalang. Secara khusus mengubah bahasa keyboard memengaruhi kunci yang dikirim oleh penghalang.

Saya juga terpengaruh, saya memiliki server linux dan klien windows. Ketika saya mengetik AltGr + 7 untuk mengetik simbol '{', simbol '[' muncul dan klien windows mengubah tata letak keyboard dari SV ke EN. Hal serupa terjadi untuk simbol lain.

Permasalahan yang sama.

Server: Ubuntu 18.04
Klien Windows 10

Masalahnya juga sama.

Server: Ubuntu 18.04
Klien Windows 10 Pro

Permasalahan yang sama. ubuntu server 2.3.2 snapshot 9080ce45, klien menang 10 2.3.2 snapshot 210c2b70)

Saya telah memasukkan solusi @niikoo dan tampaknya berhasil untuk banyak kasus. Digunakan untuk beberapa waktu, tetapi akhirnya mengalami masalah.

Sementara alt + o menghasilkan karakter "ó" yang tepat di sebagian besar pengaturan (misalnya, notepad) gagal di pengaturan lain. Misalnya di ms word.
Apa yang terjadi jika saya menggunakan alt gr + o pada keyboard fisik klien: karakter "ó"
Apa yang terjadi jika saya menggunakan alt + o kanan di server dan melewati penghalang: ms word membuka pita kerangka

Ini cukup melanggar dari sudut pandang saya, secara terang-terangan tidak bisa mengetikkan polesan dengan kecepatan yang masuk akal.

Ini konfigurasi saya:

section: screens
    fasada:
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        switchCorners = none 
        switchCornerSize = 0
    DESKTOP-QA8BAEH:
    meta = altgr
    altgr = shift
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        switchCorners = none +top-left +bottom-left 
        switchCornerSize = 0
end

section: aliases
end

section: links
    fasada:
        right = DESKTOP-QA8BAEH
    DESKTOP-QA8BAEH:
        left = fasada
end

section: options
    relativeMouseMoves = false
    screenSaverSync = true
    win32KeepForeground = false
    clipboardSharing = true
    switchCorners = none 
    switchCornerSize = 0
end

Masalahnya juga sama.

Server: macOS Catalina 10.15.2 (keyboard mackbook)
Klien: Kali linux 2019.4 (keyboard pc windows klasik)

Selain itu di mac, tombol alt gr tidak ada.

Masalah yang sama - membuat sistem tidak berkelanjutan untuk pengguna bahasa dengan karakter non-standar (milik saya adalah Polandia).

Saya baru saja mengamati sesuatu yang aneh:
Sementara minggu lalu saya menyadari bahwa AltGr tidak akan berfungsi (Windows 10 sebagai Server, Debian Buster sebagai Klien) dan saya tersandung bug ini dan sebenarnya tidak melihat bagaimana ini dapat diselesaikan - anehnya masalah itu lenyap tanpa saya mengubah apa pun.

Namun apa yang saya lakukan: saya menginstal WSL dan XcXsrv ... saya ingin tahu apakah itu mengubah sesuatu di sisi Server ...

Terima kasih! Saya mencobanya (saya menginstal WSL dan kemudian XcXsrv) dan sayangnya itu tidak berhasil untuk saya.

Pembaruan: Sepertinya itu tidak ada hubungannya dengan apa yang saya instal di Windows, melainkan dengan pengaturan keyboard saya di klien linux. Tampaknya setelah penghalang berjalan, tata letak keyboard tidak sesuai dengan keyboard lokal, tetapi memiliki tata letak "kami" - atau lebih. Dan setelah beberapa upaya untuk memperbaikinya, dan reboot - beberapa kombinasi tombol berhasil. Bukan AltGr "asli", tapi setidaknya @ € {} ...

Aku melakukannya:
daftar xinput
setxkbmap -perangkat 5 di # 5 menjadi ID dari "Keyboard inti XTEST virtual" saya
lalu boot ulang kedua PC

Juga mengacaukan pengaturan dpkg-reconfigure keyboard-configuration dan kde keyboard, jadi tidak 100% yakin apa yang sebenarnya memicu perubahan perilaku tersebut.

Saya memiliki masalah serupa saat menggunakan keyboard Jepang, dan tombol multiply dilewatkan pada waktu dan seringkali tidak ada yang benar.

Saya memiliki masalah serupa saat menggunakan keyboard Jepang, dan tombol multiply dilewatkan pada waktu dan seringkali tidak ada yang benar.

Saya memiliki masalah serupa saat menggunakan keyboard Jepang, dan tombol multiply dilewatkan pada waktu dan seringkali tidak ada yang benar.

Saya memiliki masalah serupa dengan tata letak bépo Prancis (https://bepo.fr/wiki/Accueil)
Ini sangat bergantung pada AltGr, bahkan untuk karakter ascii murni (seperti {} <>)
mendirikan:
Ubuntu18 (server)
Windows10 (klien)

Inilah kunci yang saya tekan:
AltGr-X

(Di sini dengan X , maksud saya kunci fisik yang ditempatkan pada posisi huruf X pada keyboard AS)
Menurut tata letak bépo, ini akan menghasilkan {

Tetapi saya mengamati [ yang dihasilkan sebagai gantinya (dan indikator keyboard pada windows 10 beralih ke EN)

Berikut beberapa contoh lainnya:

| pukul | Diharapkan | Hasil | komentar |
| --- | --- | --- | - |
| AltGr-X | { | [ ||
| AltGr-C | } | ] ||
| AltGr-2 | < | , ||
| AltGr-3 | > | . ||
| AltGr-4 | [ | [ | benar! |
| AltGr-5 | ] | ] | benar! |
| AltGr-P | & | 7 ||
| AltGr-Q | \| | \ ||

Berikut adalah teori yang (sebagian) menjelaskan hasil tersebut.

Server (ubuntu) mengirimkan KeyCode ke klien (windows 10). Klien mencari di mana kode tombol itu pada keyboard AS, lalu menghapus pengubah shift dan menganggap ini adalah hasilnya.

Setidaknya ada korelasi yang kuat antara yang Diharapkan dan Hasil. Mereka selalu berada di tombol fisik yang sama di keyboard AS.

Saya memiliki masalah yang sama, saya menggunakan keyboard Apple di MacOS saya dan untuk mengontrol PC Win10 dan Alt-Gr tidak berfungsi (tombol Alt kanan + G harus menampilkan simbol @ tetapi saya tidak dapat mengaktifkannya Win10 kecuali saya menggunakan Ctrl + Alt kiri seperti yang dijelaskan oleh seseorang di utas itu ... itu menyebalkan, saya berharap saya bisa mengkonfigurasinya, tetapi saya sudah mencoba menambahkan
meta = altgr
altgr = shift
di file konfigurasi, itu tidak mengubah apa pun untuk saya.

Memiliki masalah yang sama dengan tata letak keyboard Finlandia .
Klien: Windows 10
Server: Pop! _OS 20.04 LTS x86_64

Masalah yang sama, keyboard Finlandia

server: Kubuntu 19.10
klien: Windows 10 Pro

Seperti yang ditunjukkan @ digitizer0 , untuk mengatasinya, tambahkan yang berikut ini ke konfigurasi layar Anda:

meta = altgr
altgr = shift

Di sini Anda adalah konfigurasi Layar di file konfigurasi Barrier:

section: screens
    curiosity:
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        preserveFocus = false
        switchCorners = none 
        switchCornerSize = 0
        meta = altgr
        altgr = shift
    DESKTOP-HJ8KL6M:
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        preserveFocus = false
        switchCorners = none 
        switchCornerSize = 0
        meta = altgr
        altgr = shift

meta = altgr tidak melakukan apa-apa dan altgr = shift hanyalah solusi sebagian karena beberapa kombinasi AltGr masih tidak berfungsi, seperti ~ (AltGr +) dan € (AltGr e) pada keyboard Jerman.

Juga saat melihat kunci sebenarnya yang diterima pada klien Windows dengan solusi ini, urutan kunci masih salah. Misalnya AltGr + diterima sebagai:

VK  SC  Type    Up/Dn   Elapsed Key
-----------------------------------------
A1  136 a   d   0.44    RShift          
A4  038 a   d   0.20    LAlt            
A2  01D a   d   0.00    LControl        
A1  136 a   u   0.00    RShift          
BB  01B a   d   0.00    +               
A2  01D a   u   0.00    LControl        
A4  038 a   u   0.00    LAlt            
A1  136 a   d   0.00    RShift          
BB  01B a   u   0.08    +               
A1  136 a   u   0.03    RShift

Di mana Altgr + yang ditekan secara lokal hanya dengan benar menunjukkan sebagai:

A2  01D     d   0.59    LControl        
A5  138     d   0.02    RAlt            
BB  01B     d   0.17    +               
BB  01B     u   0.11    +               
A2  01D     u   0.01    LControl        
A5  138     u   0.00    RAlt

Pelacakan dilakukan dengan perintah Autohotkey KeyHistory, dengan arti sebagai berikut:
VK = Kunci Virtual, SC = Kode Pindai, Berlalu = Detik sejak kejadian sebelumnya. Jenis: h = Hook Hotkey, s = Ditekan (diblokir), i = Diabaikan karena dibuat oleh skrip AHK, a = Buatan, # = Dinonaktifkan melalui # IfWinActive / Exist, U = karakter Unicode (SendInput).

Server: Debian 10 dengan Barrier 2.3.2
Klien: Windows 10 dengan Barrier 2.3.2

Server: Windows 10 dengan Barrier 2.3.3
Klien: macOS 10.15 dengan Barrier 2.3.3

Tidak dapat menggunakan AltGr karena mengirimkan Ctrl + Alt, dan dalam kasus saya (tata letak keyboard Polandia) tidak mengizinkan karakter diakritik untuk diketik. Breaking bug buat saya, karena Right Alt + L adalah salah satu huruf penting yang sering digunakan. Menukar ke kunci terdekat (Meta / Windows) menyebabkan Windows 10 log off (Win + L).