From owner-freebsd-current Sat Apr 6 17:16:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA28536 for current-outgoing; Sat, 6 Apr 1996 17:16:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA28531 for ; Sat, 6 Apr 1996 17:16:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA28868; Sat, 6 Apr 1996 18:10:25 -0700 From: Terry Lambert Message-Id: <199604070110.SAA28868@phaeton.artisoft.com> Subject: Re: psm.c PS/2 mouse driver and devfs To: louie@TransSys.COM (Louis A. Mamakos) Date: Sat, 6 Apr 1996 18:10:25 -0700 (MST) Cc: current@freebsd.org In-Reply-To: <199604070039.TAA15273@whizzo.transsys.com> from "Louis A. Mamakos" at Apr 6, 96 07:39:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've noticed messages like this in syslog, and finally decided to go > looking for the cause: > > Apr 1 17:15:03 whizzo /kernel: Device psm0: name slot allocation failed (E=17) > Apr 1 17:15:03 whizzo /kernel: Device npsm0: name slot allocation failed (E=17) > > It seems that the code which calls devfs to instantiate the device > actually happens in the open routing of the driver, rather than the > attach. So, if you start up another X session, the next time the > device is opened you'll get the messages above. > > Hopefully there's nothing that's not obvious behind this; the mse.c > driver has the devfs invocation where you'd expect, in the attach > routine. Further, with the current state of affairs, you'd never be > able to open the mouse using a devfs /dev since it's not there yet.. Mice are insufficiently virtualized to allow this to work at the present time. In reality, mice should be bound through the console code, and then virtualized along with the screen and keyboard instances as a result. The Microsoft Windows95 DDK has sample code that probes serial ports for mice and assigns them as class devices based on whether the device probes true or not. This type of code should probably go into the serial port probes to tell the system that a serial port with a mouse is not a serial port. There is still the issue of dealing with busmouse polling, and abstracting the mouse protocol, as well as all the other well known failings of the console code and X doing direct port I/O to set modes of which the console code has no knowledge. This is not abug which can be simply fixed if it is to be fixed completely. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.