Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!elroy.jpl.nasa.gov!ames!data.nas.nasa.gov!taligent!apple!veritas!amdcad!BitBlocks.com!bvs From: bvs@BitBlocks.com (Bakul Shah) Newsgroups: comp.unix.bsd Subject: Re: com woes Message-ID: <1992Aug12.210501.17721@BitBlocks.com> Date: 12 Aug 92 21:05:01 GMT References: <1992Aug9.085755.6237@news.tu-graz.ac.at> Organization: Bit Blocks, Inc. Lines: 33 chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko) writes: >I had the problem with select() not working on com ports. I got no >response from a post regarding this one, so I started to look into it >myself. I found out that the com driver calculates unit = minor(dev) -1; >This has the following implications: > /dev/com1 corresponds to COM0, /dev/com2 to COM1 (very confusing > in kernel messages) > It is incompatible with the config file entries com1 at..., com2 at... > Unpredictible results will occur if someone puts a com0 at.. in > his config file. > It is incompatible with the DOS usage of COM1, COM2 (But who cares 8-) > ttselect() calculates unit = minor(dev), and uses this as an index in > com_tty. Because this index is different from that used > in the com driver, select() on /dev/com1 looks at > /dev/com2 and select() on /dev/com2 looks at an undefined > entry in com_tty and returns always true. Aha! This explains why when the mouse on COM2 the X server hogs the machine, and, why when the mouse is on COM1 its moves and button presses are accepted only after hitting a key or some activity on COM2. Thanks for the patch! The mouse and the X server behave much better now (mouse button presses are still not recognized right away but that has something to do with x386Io.c -- I'll probably implement either a `mouse' line discipline or /dev/mouse, with ioctls to set mouse type etc, so that non X programs can also make use of mice). I have also switched over to using /dev/com0 & /dev/com1 instead of /dev/com1 & /dev/com2 (with appropriate changes in the /sys/i386/conf/<HOST> and MAKEDEV files). -- bakul shah <bvs@bitblocks.com>