2

I would like to open a character device e.g. /dev/tty1 by multiple processes in a way that would not interfere reads between them. I noticed that if one process consumes a byte, no other process would receive it.

Problem details: I'm writing console app on Linux, which requires receiving both: key presses and key releases. I managed already to switch from default terminal mode K_XLATE to K_RAW mode using ioctl(fd,KDSKBMODE,K_RAW) on newly opened /dev/tty1. Unfortunately reading from this descriptor resulted in missing bytes as mc tries to intercept Ctrl+O key strokes in parallel (to bring its interface on top or hide it back) by reading from same device.

So I tried also to read data from stdin, pseudo terminal pipe created by mc (after setting /dev/tty to K_RAW mode). It almost worked, except now I have collision of Ctrl+O character code 0x0F with Tab key scancode (also 0x0F).

I'm looking for solution to that interference problem in a way not requiring more privileges than cap_sys_tty_config, so accessing /dev/input in order to read keyboard directly is not way to go for me.

  • So you want to buffer bytes for all processes that read e.g. /dev/tty1? What should happen if 10 processes happily read kilobytes of characters per second, while the 11th is really slow, and reads one character per hour? Should you buffer all for the 11th process? When does that buffer overflow? – dirkt Mar 13 '18 at 13:33
  • Yeah, that would cause problem, but such problem already exists at the writer end, even with a single reader, writer is simply blocked if too much data is written, right? Same thing OS could do if a reader is too much ahead of other readers. Do you confirm it is not possible on Linux? – Anonymous Mar 13 '18 at 16:41
  • 1
    You can't block the "writer" (which, in the end, is the guy at the keyboard, or the other computer on a serial line), because hardware events are the "writer" as far as Linux is concerned. The point I was trying to make is that your configuration is not trivial, and you have to make design decisions. That's why it's not in-built. And anything is possible, you just have to sit down and make it if it's not there already. E.g. you can use tee, or rewrite the tee code if you want different design decisions, or pass through terminal ioctl's etc. – dirkt Mar 14 '18 at 7:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.