Ohledně nastavení hardwaru sériových portů (UARTů) proti sobě: bacha ať Vám sedí vedle baudu, datových bitů a parity taky flow control. V pythonovém kódu vidím "xonxoff: false" - ale xon/xoff je jenom jedna možnost, jak může flow control běhat (navíc poměrně problematická). Další možnosti jsou "hardware" (aka RTS/CTS) nebo skutečně "none", jak je vidět v té "documentaci" co jste odkázal. Pokud máte proti sobě flow control none/none, tak jede sériák prakticky po třech drátech: RX, TX a zem. Pokud byste zapnul HW flow control = RTS/CTS, tak tím zajistíte odolnost proti přetečení FIFO bufferů na obou UARTech v RX směru, ale potřebujete mít fyzicky zapojené ty dva dráty navíc (RTS a CTS). A samozřejmě pokud byste měl tuhle vlastnost proti sobě navzájem rozkonfigurovanou, tak to nejspíš nebude fungovat vůbec.
Jak říkali ostatní, že se dá bavit po sériáku jenom bod-bod, tak pod Windows existuje kumpán ovladače com0com, user-space prográmek zvaný hub4com - který umí "virtuálně" vytvořit sběrnici. Můžete vzít tři a více COM portů, fyzických nebo virtuálních, a stanovit pravidla, odkud kam se mezi nimi mají kopírovat data - každej s každým, nebo nějakou omezenou podmnožinu.
Nakonec mám ale pocit, že možná špatně chápu zadání. Ten originální software co řeší "markers na sériovém portu" (Emotiv)... podle mého on je s tím headsetem nějak trvale ve spojení. Je mi jedno jak, jestli přes sériák, USB nebo jak... ale vlak proti tomu nejede. Tazatel teď IMO řeší něco jiného: vstup externích událostí do Emotivu. To je další, nezávislý, komunikační kanál. S komunikací mezi Emotiv SW a headsetem to nemůže běžet po tomtéž sériovém portu. Musí být k dispozici (další) dedicated sériák pro Emotiv, na kterém si může povídat s "námi". A ano, ten může být buď fyzický, nebo virtuální. Třeba com0com se na to výborně hodí, z jedné strany dáte Emotiv, z druhé na základní ozkoušení třeba terminál (klasický Hyperterminál bych prakticky úplně nedoporučil, spíš Putty nebo nejlíp RealTerm). A pokud dokážu vyvolat událost posláním pár znaků z terminálu, tak potom zkoušet něco programovat. BTW ono to vypadá, že com0com má víc problémů, než jenom závislost na .NET frameworku 2.0. Ten starý kernelový ovladač údajně už nevoní Windows 10. Takže buď zkusit starší windowsy, nebo koupit nějaký komerční soft, co dělá virtuální COM porty.
Trochu nechápu, proč ten drahý proprietární software neumí přijímat události přes TCP/IP. Třeba přes UDP socket. To je zcela univerzální rozhraní, základními prostředky OS, navíc multiplatformní. Není potřeba kuchat drivery prastarého sériáku do Windows kernelu.
Jako další možnost předávání "zpětnovazebních událostí" (markerů), údajně nepříliš přesnou, zmiňuje dokumentace Emotivu úhozy do klávesnice. Ty se IMO dají vsunout do bufferu softwarově, a to poměrně snadno, každopádně v user space. Zkuste hledat WinAPI funkci
SendInput .
Koukám, jestli někdo nemá hotový "keyboard server" pro Windowsy, jako že by něco poslouchalo na socketu a přijaté úhozy vsouvalo do bufferu klávesnice na běžícím desktopu... jako že pro volné další zneužití. Nic takového jsem nenašel, asi nejblíž je serverová část od Air Keyboard App, což asi nebude přímo volně použitelné.