I’m working on a Linux application where I interact with a pseudo-terminal (PTY). Specifically, I’ve implemented the following:

• I create a PTY slave and monitor writes and reads on the PTY master handler.
• When writing to the PTY master, the content is displayed on the slave (e.g., when using picocom on the slave side).
• Input events are handled by monitoring the PTY master and reading from it when data is available (e.g., writting some data in the picocom).

The Problem

When I attempt to write into the PTY master in two different scenarios, I observe different behaviors:

Scenario #1 (No slave program running, only the PTY):

Writing to the PTY master triggers an input event on the master side. For example, the write operation causes the input monitoring mechanism (e.g., epoll()) to indicate that data is available for reading.

Scenario #2 (Slave program picocom running):

Writing to the PTY master does not trigger an input event. While the data is correctly displayed on the picocom pseudo-terminal, my input monitoring mechanism on the master side does not detect any event or indicate that data is available for reading.

My Goal

I want the PTY master to only receive input events when actual input characters are available to read (as in Scenario #2). However, I do not understand why the behavior differs depending on whether a slave program like picocom is running.

Questions

• Why does writing to the PTY master trigger an input event when no slave is attached (Scenario #1)?
• Why does this behavior change when a program like picocom is attached to the PTY slave (Scenario #2)?
• How can I ensure that the input event on the PTY master is only triggered when actual input characters are available (Scenario #2 behavior)?

Any insights into the differences in PTY behavior between these scenarios or how to achieve my desired behavior would be greatly appreciated.

Note: I tried monitoring input events on the PTY master using mechanisms like epoll(). I expected to receive an input event only when actual input characters were available from the PTY slave, regardless of whether the slave was picocom or nothing at all. However, in Scenario #1 (no slave program running), writing to the PTY master unexpectedly triggered an input event, which doesn’t happen in Scenario #2 (when picocom is running).