Disable COM port or disable auto detection of COM ports

Questions about Wine on Linux
Locked
yarda
Newbie
Newbie
Posts: 3
Joined: Wed Sep 13, 2023 4:58 pm

Disable COM port or disable auto detection of COM ports

Post by yarda »

Hi,

I have a SW which doesn't open exclusively the serial device, but Wine port detection is toggling the DTR pins on all COM ports during the auto-detection which interacts strangely with the HW connected to the serial device.

Is there a way how to:
- exclude some COM port from the auto detection, or
- disable the auto-detection of COM ports, or
- prevent toggling of the DTR pin during the auto detection?

I found two workarounds:
- rename the serial device, because it seems the auto-detection uses hard coded patterns, e.g. renaming /dev/ttyACM0 to the /dev/tty_my_ACM0 did the trick for me - this is really strange workaround,
- tweak the device permissions or incorporate SELinux or similar ACL for the Wine not to have permissions to access the port - this seems like unnecessary complexity.
BobLovesWine
Level 1
Level 1
Posts: 8
Joined: Mon Feb 06, 2023 8:17 pm

Re: Disable COM port or disable auto detection of COM ports

Post by BobLovesWine »

Hi.

Ha. Know this one. I'm familiar with FDTI DTR low pin getting pushed high and blocking. uC and PC serials under linux are bad enough without adding wine or VMs into the mix, this can be a "fun" thing to troubleshoot. (I didn't mean "fun" I am sure you know.) BTW - Great workaround, a bit hampering, but you found a solution is the point, so I do love that! People answering their own technical questions makes my day.

Did you try just removing the syminks for $WINEPREFIX/dosdevices/ -- via the registry, you can't just delete them -- it shouldn't be initializing anything much less pulling a pin high or low, if it can't "see" something. 'WINEPREFIX=~/.wine-blah-x64 wine regedit' ... navigate to HKLM\Software\Wine, right-click on Ports, new String value, name 'com1' and value left blank. Repeat as necessary. This will exclude these ports from wine, and (I think!) from the auto-enumeration routine.

I have to do this for uC work, but then I also require them for older micro stuff, like PIC/AVR Windows-only tools, hw JTAG debugger, even my fancy serial digital storage oscilloscope comes with Windows-only software, because of course it does. Just keep dozens of isolated wine bottles is my solution. wine is incredible. Got to say it occasionally.

( I should also point out, this is in the UG: https://wiki.winehq.org/Wine_User's_Gui ... llel_Ports )

If you don't stick with your solution, then good hunting!
---

PS: Know that you are addressing three problems as one... 1) the hardware in question; if the device microcode was flashed in a way that DTR is blocked at powerup, and it gets annoyed if anything "touches" the pin, well, you'll have to re-initialize it manually, sometimes just good ol plug-out, 5.4.3.2.1, plug-in... that's life, isn't it? 2) Since wine access is the user context access, and the way hald udev etc work, providing acess rights to the things they detect being attached, and since these days lots of linux is single-user desktops, leads to 3) implicit ACLs you don't always want - by default most distros grant local users access to tty/USB devices if they have storage flags, and defer to file system permissions for access control, assuming most other things being attached will require a different driver or just raw access. There are custom udev rule directives you can make to prevent these auto-granted rights, of course. Search for "drake writing udev rules" to get a great article for a starting point.

If you do that to your main user account, this might impact computing life, much like renaming a serial port. Having to manually giving yourself access after plugging in stuff would get annoying fast here, so if I were you, I'd create a new user, let's call him 'winenoserial' and remove such accesses from him, no dialout TTY group, no implicit rights now blocked by your custom udev rule(s), and run in that user context with 'sudo -u winenoserial WINEPREFIX=~/.wine-blah-x64 wine appname'

Let's hope the official way above works, because both mine and yours are have complexity.
---
yarda
Newbie
Newbie
Posts: 3
Joined: Wed Sep 13, 2023 4:58 pm

Re: Disable COM port or disable auto detection of COM ports

Post by yarda »

BobLovesWine wrote: Thu Sep 14, 2023 10:57 am Did you try just removing the syminks for $WINEPREFIX/dosdevices/ -- via the registry, you can't just delete them -- it shouldn't be initializing anything much less pulling a pin high or low, if it can't "see" something. 'WINEPREFIX=~/.wine-blah-x64 wine regedit' ... navigate to HKLM\Software\Wine, right-click on Ports, new String value, name 'com1' and value left blank. Repeat as necessary. This will exclude these ports from wine, and (I think!) from the auto-enumeration routine.
Yes, I tried this first, but unfortunately it doesn't work. The autodetection is "smart" enough and adds the port as another number, e.g. COM33. If I add COM33 blank, it adds it as COM34. I also tried symlinking to /dev/null and I also tried to add the port as the LPT in the registry, e.g. LPT1 = "/dev/ttyACM0", unfortunately it also doesn't exclude it from the COM port auto-detection.
BobLovesWine wrote: Thu Sep 14, 2023 10:57 am PS: Know that you are addressing three problems as one... 1) the hardware in question; if the device microcode was flashed in a way that DTR is blocked at powerup, and it gets annoyed if anything "touches" the pin, well, you'll have to re-initialize it manually, sometimes just good ol plug-out, 5.4.3.2.1, plug-in... that's life, isn't it? 2) Since wine access is the user context access, and the way hald udev etc work, providing acess rights to the things they detect being attached, and since these days lots of linux is single-user desktops, leads to 3) implicit ACLs you don't always want - by default most distros grant local users access to tty/USB devices if they have storage flags, and defer to file system permissions for access control, assuming most other things being attached will require a different driver or just raw access. There are custom udev rule directives you can make to prevent these auto-granted rights, of course. Search for "drake writing udev rules" to get a great article for a starting point.
The DTR is controlling PTT on the radio, it's quite common design in ham radio world, so if I start Wine it keys the radio and it starts transmitting all the time until I kill wine or run win32/64 helper that returns the DTR state back, this is quite strange.

I think having the Wine option to disable the COM autodetection could be really helpful for such use cases.
jkfloris
Level 12
Level 12
Posts: 3201
Joined: Thu Aug 14, 2014 10:10 am

Re: Disable COM port or disable auto detection of COM ports

Post by jkfloris »

I found two workarounds:
- rename the serial device, because it seems the auto-detection uses hard coded patterns, e.g. renaming /dev/ttyACM0 to the /dev/tty_my_ACM0 did the trick for me - this is really strange workaround,
You're right. Wine is looking for ttyS*, ttyUSB*, and ttyACM*.
The lookup is done by mountmgr.sys. You can disable it with:
Note: I don't know if this has any side effects!

Code: Select all

WINEDLLOVERRIDES="mountmgr.sys=d" wine program.exe

- tweak the device permissions or incorporate SELinux or similar ACL for the Wine not to have permissions to access the port - this seems like unnecessary complexity.
Another similar solution is to use firejail.

Code: Select all

firejail --noprofile --blacklist="/dev/ttyACM0" wine program.exe
yarda
Newbie
Newbie
Posts: 3
Joined: Wed Sep 13, 2023 4:58 pm

Re: Disable COM port or disable auto detection of COM ports

Post by yarda »

jkfloris wrote: Thu Sep 14, 2023 4:07 pm You're right. Wine is looking for ttyS*, ttyUSB*, and ttyACM*.
The lookup is done by mountmgr.sys. You can disable it with:
Note: I don't know if this has any side effects!

Code: Select all

WINEDLLOVERRIDES="mountmgr.sys=d" wine program.exe
Thanks, this is what I was looking for. Maybe it could be useful to add it to the documentation.
Locked