Standard Ps 2 Keyboard Driver Download Windows 7
Casandro Diveley
Why does the Windows device manager show my laptop keyboard as a Standard PS/2 Keyboard on one laptop and as a HID Keyboard Device on the other, even though I already know that it is only connected via a ribbon cable directly to the motherboard and none of the doesn't it use the interfaces mentioned above? Is this perhaps a mistake?
There is no reason for them to use those connectors within a laptop, but there are definitely convenience reasons to use the communications protocol such as the electrical signalling and communications methods within a device. There may be an off-the-shelf keyboard (or one that they have already designed) that uses one protocol or another. They may already have drivers that they know works for one device or another within the laptop that can talk to whatever keyboard they have.
Just because there is a ribbon cable does not mandate any given protocol or connector type either. All you need to do is be aware of the general design rules and signal integrity requirements for that electrical signal. I've personally designed ribbon cables that run USB, Ethernet and and other signals and never used a "standard" USB or RJ-45 socket.
The keyboard needs to work out of the box in almost all situations, because without a working keyboard it's rather hard to complete the installation of an operating syste or to fix the problem of not having a working keyboard. This applies both when the firmware/bios is in control of the hardware, and after the operating system takes over control of the hardware. The same applies to some extent without a working mouse, but if you know what you are doing it was usually easier to deal with a keyboard and no mouse than a mouse and no keyboard.
The result is that the standard interface for keyboards on PCs stayed much the same from the introduction of the PC/AT in 1985 to the switch to USB in the 2000s. The IBM PS/2 changed the connector and the new connector was eventually adopted by clones, though there was a long period when both were in use, but as far as I know both the electrical interface and the logical interface stayed the same. The PS/2 also added a mouse interface that was electrically similar to the keyboard interface.
Laptops had a more complex keyboard and mouse situation, they would have an internal keyboard, an internal pointing device (touchpad, trackball or trackpoint) and count often support an external keyboard, an external mouse or both on a splitter, but they still needed to look sufficiently like standard keyboards and mice that someone could boot and install an operating system suceefully. Combining internal and external signals, and detecting what was plugged into the combo PS/2 port would have to be handled by firmware in the laptop's keyboard controller.
USB was first introduced in 1996 but it took a while to find it's feet. There was a version of windows 95 with USB support, but in my experiance it was viritually unusable due to lack of perphiheral drivers.
Windows 98 was better but still problematic, I remember plugging USB keyboards and mice into windows 98 boxes, and they worked fine once you got past the "found new hardware" wizard but without a working keyboard or mouse there was no way to get past the found new hardware wizard. Also bios's from that era generally did not understand USB keyboards or mice, so you couldn't use them at the BIOS or bootloader screens.
So that brings us to where we are today, if you as a hardware designer want to make a keyboard that will work out of the box almost everywhere, the safe options are to either make it look like a traditional PC keyboard, or make it look like a USB HID keyboard.
I got the same issue. I am a Help desk and most of our agents who have HP devices are having this issue and it is preventing them to access their remote desktop because the system is detecting that update that needs to be installed. I've checked other threads and running the wushowhide troubleshooter from Microsoft and DISM tool wont do any help.
I will give this a try, because the last time I tried to check the updates using the HP Assistant, the update for "Hewlett-Packard Development Company, L.P. - Keyboard - Standard 101/102-Key or Microsoft Neutral PS/2 Keyboard for HP Hotkey Support" didn't show up .
So why this driver : "Hewlett-Packard Development Company, L.P. - Keyboard - Standard 101/102-Key or Microsoft Neutral PS/2 Keyboard for HP Hotkey Support" keeps showing up if it is already installed? We cant tell the agents to ignore it since their remote desktop detects the driver update and it wont allow them to open it.
I'm also waiting for that patch that will provide permanent resolution on this one. It was funny that when I assisted an agent and she was with HP support doing a remote session with her laptop, they cant figure out what causing the drivers not to installed on the devices, and they already reset the laptop.
We found a workaround (cause we need to get them on the phone), we just suggested the agents to use a USB keyboard and keep on deleting the PS/2 driver on Device Manager (it keeps on coming back after the restart though), but c'mon, we need a permanent fix on this one.
Things are getting worse because for the past days, we have been receiving reports from the agents that another HP driver (Hewlett-Packard - Enterprise WSD Multi-Function Printer, Multi-Function Printer, Other hardware - HP Printer (BIDI)) is having an issue installing (aside from the Keyboard driver) that hinders them from logging in to their remote desktop. Good thing that we found a temporary fix to get rid off of those updates, but it was a tedious workaround.
But still wants to be installed. My laptop (in the last 3 days) has started running very slow compared to normal and the fan is constantly running even though the laptop is is cool, CPU usage is under 2-3% and the fan is running like a dog.
Your best chance for a Windows keyboard driver will probably be to get the Windows DDK (Device Driver development Kit). OTOH, based on the questions' tags (especially vb.net) I'm left wondering exactly why you'd want that. The keyboard driver itself mostly just gets activated when the user presses a key, gets the data, and goes back to sleep. If you're interested in something like mapping keys to different characters, that's not in the keyboard driver itself at all (without even looking at any code for the driver itself).
I have looked my product up and there is 0 I have seen in the drivers section for a simple pre installed driver that has a tendency to self corrupt. I need a viable link for a standard ps/2 keyboard driver for my hp 15-bs212wm to manually update it. my cntrl key and b,n stopped working . I have seen this issue before on my hp products. Its driver corruption. To see this simple driver isn't hosted in your drivers section makes me question whats going on.
Non-HID keyboards and mice can connect over multiple legacy buses but still use the same class driver. This section contains details on the class drivers themselves. The following sections goes into details on the controllers.
The figure on the left shows a keyboard and a mouse connected to a system bus through independent controllers. A typical configuration consists of a PS/2-style keyboard operated through an i8042 controller, and a serial-style mouse operated through a serial port controller.
The following figure shows the configuration of device objects for a Plug and Play PS/2-style keyboard and mouse device. Each class driver creates an upper-level class filter device object (filter DO) that is attached to a function device object (FDO) through an optional upper-level device filter DO. An upper-level device filter driver creates the upper-level device filter DO. I8042prt creates the function DO and attaches it to a physical device object (PDO) created by the root bus driver.
Kbdclass and Mouclass can support more than one device in two different modes. In the one-to-one mode, each device has an independent device stack. The class driver creates and attaches an independent class DO to each device stack. Each device stack has its own control state and input buffer. The Microsoft Win32 subsystem accesses input from each device through a unique file object.
Kbdclass and Mouclass operate in the one-to-one mode if their registry entry value ConnectMultiplePorts is set to 0x00 (under the key HKLM\Services\CurrentControlSet\\Parameters, where class service is Kbdclass or Mouclass). Otherwise Kbdclass and Mouclass operate in grandmaster mode.
The Microsoft Win32 subsystem opens all keyboard and mouse devices for its exclusive use. For each device class, the Win32 subsystem treats input from all the devices as if the input came from a single input device. An application cannot request to receive input from only one particular device.
The Win32 subsystem dynamically opens Plug and Play input devices after it receives notification from the Plug and Play manager that a GUID_CLASS_KEYBOARD or GUID_CLASS_MOUSE device interface is enabled. The Win32 subsystem closes Plug and Play devices after it receives notification that an opened interface is disabled. The Win32 subsystem also opens legacy devices by name (for example, "\Device\KeyboardLegacyClass0"). Note that once the Win32 subsystem successfully opens a legacy device, it cannot determine if the device is later physically removed.
If the device is in the Plug and Play started state, the class driver sends the IRP_MJ_CREATE request down the driver stack. Otherwise the class driver completes the request without sending the request down the driver stack. The class driver sets the trusted file that has read access to the device. If there is a grandmaster device, the class driver sends a create request to all the ports that are associated with the subordinate class devices.
The class drivers must connect their class service to a device before the device can be opened. The class drivers connect their class service after they attach a class DO to a device stack. The function driver uses the class service callback to transfer input data from a device to the class data queue for the device. The function driver's ISR dispatch completion routine for a device calls the class service callback. Kbdclass provides the class service callback KeyboardClassServiceCallback, and Mouclass provides the class service callback MouseClassServiceCallback.
7fc3f7cf58