| Main > Main Forum |
| USB vs PS/2 vs COM vs LPT |
| << < (22/43) > >> |
| MonMotha:
I'm really running out of patience for your blathering. You clearly have no idea what you're talking about, so please just can it. I can only hope that this will be my last post to correct your obvious misconceptions. (FYI, I have discovered the hard way that you can't let that asm sourced program you posted run very long - it's a very tight loop that produces output far faster than Windows can display it; I had to hard power my system to kill it. This is arguably a Windows bug, but I figured I'd let people know if they want to try this stuff for themselves) --- Quote from: Driver-Man on September 25, 2010, 01:16:31 am --- --- Quote from: JustMichael ---I have no idea where you get all your misconceptions but you definitely have a ton of them.... Today, USB doesn't go to port 0x60 in windows nor does it get "converted" to ps/2 protocol. --- End quote --- a.) My "old" program works on your "modern" computer, yes? b.) http://wiki.osdev.org/PS2_Keyboard - "The Keyboard Controller (KBC) is located on the mainboard. The name is misleading because the Controller does more than controlling the communication with the hardware on the keyboard. In the early days the controller was a single chip (8042). As of today it is part of the Advanced Integrated Peripheral." - "USB Legacy Support... To remain compatible with old software, the mainboard emulates USB Keyboards and Mouses as PS/2 devices. This is called USB Legacy Support." --- End quote --- a) Only when built as a DOS application and running inside NTVDM. Note that NTVDM does not exist on 64-bit versions of Windows. You'll get a "does not support this computer" error when trying to run it (yes, I tried it on 64-bit Windows 7 - screencap of the dialog attached since you won't believe anybody). b) The keyboard controller is now part of what is commonly referred to as the "SuperIO" chip, usually living on the LPC bus (used to be the ISA bus, but those are gone, now) but sometimes integrated into the "southbridge". USB legacy support is a BIOS function. Basically, when a "real" OS that talks directly to the USB HCI doesn't exist, the BIOS will emulate port 0x6n accesses and stuff USB HID keyboard data into it merged with PS/2 port keyboard data. Once a "real" OS (like Windows or Linux, but NOT DOS) loads, it takes over control of the USB HCI and handles input merging on its own since the OS will have its own APIs to grant userspace processes access to keyboard data. For applications running in NTVDM (DOS applications), this just happens to be the port 0x6n interface the BIOS originally provided (this is for compatibility). For native Windows applications, the interface is different. --- Quote from: Driver-Man on September 25, 2010, 01:16:31 am ---Are you saying there is any chance "inportb(0x60)" might not work on some PC? --- End quote --- It doesn't work at all how you'd intend on my 64-bit Windows 7 system. The DOS version of the program can't be run at all due to the lack of NTVDM (and really, does an OS really need to support 20 year old DOS applications?), and the Win32 version crashes due to the attempt to use a privileged instruction (and bypassing this restriction doesn't do what you want, either: see below). Given that Windows 7 is current, and 64-bit is becoming popular (with good reason), I'd say yeah, there's a good chance "inportb(0x60)" won't work on some PCs. Note that the Windows API doesn't include "inportb" and hasn't for years. I had to define it to use it. If your intent is to say that "inportb" will or won't compile, it won't on anything remotely modern. Either way ("does it compile?" or "does it work?"), you're sunk. It doesn't work, at least not how you seem to be wanting it to. --- Quote from: Driver-Man on September 25, 2010, 01:16:31 am --- --- Quote ---The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes. --- End quote --- Nonsense. By the way, you are contradicting MonMotha, he said USB does not use keyboard controller at all. --- End quote --- No, he's not. He's referring to something else. He's referring to the controller chip on the USB keyboard (the source of the data, rather that the sink). At least, that's how I read it, and it makes sense in that context. --- Quote from: Driver-Man on September 25, 2010, 01:16:31 am --- --- Quote ---Simply put in order to find out the absolute maximum a keyboard controller can read its own inputs you will have to make your own and then the information will only apply to that device. I don't think any of the manufacturers will let you read the source code for their devices. I know I wouldn't. --- End quote --- We are not talking about keyboard encoder anymore. We are now talking only about the "keyboard controller", which is located on computer motherboard. Anyway, shell we trust this document then, or not: ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf Keyboard/Mouse Input The Interrupt Transfer Descriptor for the USB keyboard and/or mouse is processed at the rate established by the Endpoint Descriptor’s location(s) in the interrupt list (a 1-ms rate is the recommended rate for emulation). The Transfer Descriptors are processed as normal by the Host Controller. When a successful transfer of data has occurred from the keyboard, the Transfer Descriptor is moved to the Done Queue by the Host Controller. At the beginning of the next frame when the interrupt associated with the transfer completion is to be signaled, an interrupt is generated. System software should ensure that the Interrupt Routing bit in HcControl is set to 1 so that these interrupts will result in an SMI. Upon receipt of the SMI, the emulation software removes the Transfer Descriptor from the Done Queue, clears the HC IRQ, and translates the keyboard/mouse data into a equivalent PS/2-compatible sequence for presentation to the application software. For each byte of PS/2-compatible data that is to be presented to the applications software, the emulation code writes to the HceOutput register. The emulation code then sets the appropriate bits in the HceStatus register. If keyboard/mouse interrupts are enabled, setting the HceStatus register bits cause the generation of an IRQ1 for keyboard data and IRQ12 for mouse data. The emulation code then exits and waits for the next emulation interrupt. When the host CPU exits from SMM, it can service the pending IRQ1/IRQ12. This normally results in a read from I/O port 60h. When I/O port 60h is read, the Host Controller intercepts the access and returns the current contents of HceOutput. The Host Controller then also clears the OutputFull bit in HceStatus and de-asserts IRQ1/IRQ12. If the emulation software has multiple characters to send to the application software, it sets the CharacterPending bit in the HceControl register. This causes the Host Controller to generate an emulation interrupt on the next frame boundary after the application has read from port 60h. --- END QUOTE --- End quote --- The section you're quoting simply describes how emulation software in the BIOS should operate. Most BIOSes do provide this emulation so that DOS can be used. Bootloaders (e.g. LILO, GRUB, the Windows boot menu, etc.) that need a user interface also commonly use the BIOS on PCs to do that I/O since it's one of the few standard methods available without needing lots of driver code. The BIOS needs this code to support USB keyboards in its configuration menus, anyway, so it's not a big deal to pass this support on. Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off). They provide their own input APIs that don't involve applications directly accessing IO port 0x60, so this emulation is not needed and would conflict with direct access to the USB HCI (necessary for non-boot HID devices). They are aware of the multiple sources of keyboard data on modern PCs and don't need the data merged into the ancient interface DOS expects. These OSes *do* still talk to port 60, but only to retrieve actual PS/2 keyboard data. They *also* talk to the USB HCI directly to receive HID data (and other USB data). This HID data is then merged with data from other sources (PS/2 port, Bluetooth HID, onscreen keyboard, etc.) and presented to userspace applications in whatever manner the OS uses. Typically, this is a kernel syscall or a file stream (standard input). So, to settle this (or at least attempt to, since I'm sure you won't believe me, anyway), I did some further testing: For grins, I unblocked access to port 0x60 on my 32-bit Windows XP SP3 machine using the "userport" program I mentioned in a previous post to Derrick Renaud. All this program (which includes a kernel-mode driver) does is enable userspace processes to access the IO ports you specify. The system a laptop, and Linux says that the onboard keyboard is on the PS/2 port (this is typical). I ran the Win32 native application that bangs directly on port 0x60. It got data from the onboard PS/2 keyboard but neither of the USB keyboards I had attached. This is consistent with what I just said: Windows reads port 0x60 for PS/2 keyboard data but gets USB data from elsewhere (directly from the HCI) and merges it together itself for presentation to userspace applications via the Win32 API. Since reading port 0x60 bypasses the Win32 API, it will only get data actually present on port 0x60 which is PS/2 data. The DOS version *DOES* get data from all sources because it's running inside NTVDM. NTVDM uses the conventional Windows APIs to get keyboard data before stuffing it into an emulated port 0x60 interface. Hence, any keyboard Windows knows about will be passed to a DOS application inside NTVDM via port 0x60. This ONLY happens because that DOS application is running inside an EMULATION LAYER to emulate DOS. That emulation layer is NOT present for native Win32 applications, and it's not necessary because native Win32 applications don't bang directly on the hardware. |
| JustMichael:
--- Quote from: Driver-Man on September 25, 2010, 01:16:31 am ---Currently we are side-tracked in argument whether USB keyboard data is ALWAYS interfaced via PS/2 emulation and so through the port 0x60 of the keyboard controller, or not. Also, it is not quite clear whether I am really a Driver-Man, or perhaps the Green Goblin (Troll). There is drama, there is dilemma, it's your new summer blockbuster, get your pop-corn and jump in, it's interactive! --- End quote --- From that statement we can surmise troll... definitely troll. --- Quote from: Driver-Man --- --- Quote from: JustMichael ---I have no idea where you get all your misconceptions but you definitely have a ton of them.... Today, USB doesn't go to port 0x60 in windows nor does it get "converted" to ps/2 protocol. --- End quote --- a.) My "old" program works on your "modern" computer, yes? b.) http://wiki.osdev.org/PS2_Keyboard - "The Keyboard Controller (KBC) is located on the mainboard. The name is misleading because the Controller does more than controlling the communication with the hardware on the keyboard. In the early days the controller was a single chip (8042). As of today it is part of the Advanced Integrated Peripheral." - "USB Legacy Support... To remain compatible with old software, the mainboard emulates USB Keyboards and Mouses as PS/2 devices. This is called USB Legacy Support." --- End quote --- a) Can your old program work on a modern computer? In a dos box, yes it can through EMULATION. In case you haven't noticed the E in MAME stands for EMULATION. b) The USB Legacy Support allows a modern computer to have its bios emulate USB keyboards and mice as PS/2 devices for non-USB aware environments like DOS. --- Quote from: Driver-Man ---Are you saying there is any chance "inportb(0x60)" might not work on some PC? --- End quote --- Running in a current windows environment (not an emulated dos box), the program will error out. Which error displayed would depend upon which windows environment you are running. --- Quote from: Driver-Man --- --- Quote from: JustMichael ---Your misconceptions with USB bare little resemblance to the reality. You can read the specifications if you wish as they are online but yet you choose not to for some reason. --- End quote --- What the...? Read what exactly? Stop talking about me, just show us the part of "the specification" you are referring to, copy/paste - can you do that? --- End quote --- You can read the HID 1.11 specification here: http://www.usb.org/developers/devclass_docs/HID1_11.pdf --- Quote from: Driver-Man ---OpenHCI - Open Host Controller Interface Specification for USB (Compaq, Microsoft, National Semiconductor @ 09/14/99 2:33 PM) ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf - "To minimize hardware impact, the Host Controller accesses a USB keyboard and/or mouse using the standard OpenHCI descriptor-based accesses. The emulation code sets up the appropriate Endpoint Descriptors and Transfer Descriptors that cause data to be sent to or received from a USB keyboard/mouse using the normal USB protocols. When data is received from the keyboard/mouse, the emulation code is notified and becomes responsible for translating the USB keyboard/mouse data into a data sequence that is equivalent to what would be produced by a PS/2-compatible keyboard/mouse interface. The translated data is made available to the system through the legacy keyboard interface I/O addresses at 60h and 64h." What now? --- End quote --- Did you even read the document you are quoting? I am betting that you did not. Here is the second sentence: --- Quote from: the document Driver-Man presented ---The purpose of OpenHCI is to accelerate the acceptance of USB in the marketplace by promoting the use of a common industry software/hardware interface. --- End quote --- When USB keyboards and mice were starting out they WERE often emulated as ps/2 devices for compatibility. If they weren't, you couldn't have used them with DOS programs. Here is the paragraph previous to the one you quoted: --- Quote from: the document Driver-Man presented ---OVERVIEW To support applications and drivers in non-USB-aware environments (e.g., DOS), the Host Controller needs to provide some amount of hardware support for the emulation of a PS/2 keyboard and/or mouse by their USB equivalents. For Open HCI, this emulation support is provided by a set of registers that are controlled by code running in SMM. Working in conjunction, this hardware and software produces approximately the same behavior-to-application code as would be produced by a PS/2-compatible keyboard and/or mouse interface. --- End quote --- From what I have seen, windows seems to be a pretty USB-aware environment. Is there some reason you brought a document that talks about DOS when we are talking about USB HID devices in windows? --- Quote from: Driver-Man --- --- Quote from: JustMichael ---The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes. --- End quote --- Nonsense. --- End quote --- Nonsense? You can't transmit data faster than the specification allows. I bet you ignored the sentences that followed the one you quoted: --- Quote from: JustMIchael ---That maximum is set by how fast the USB connection is. For example, a USB 1.0 device can't transmit faster than 1.5Mhz (roughly 180K/sec). Simply put, you can't send stuff faster than your connection is. --- End quote --- --- Quote from: Driver-Man ---By the way, you are contradicting MonMotha, he said USB does not use keyboard controller at all. --- End quote --- By keyboard controller I was meaning the chip in the keyboard or the USB HID device. The next quote from you shows that you understood what I meant. Yes, I should have used the word "encoder" to be proper. Monmotha means that the keyboard controller inside the pc is NOT used for USB. --- Quote from: Driver-Man --- --- Quote from: JustMichael ---Simply put in order to find out the absolute maximum a keyboard controller can read its own inputs you will have to make your own and then the information will only apply to that device. I don't think any of the manufacturers will let you read the source code for their devices. I know I wouldn't. --- End quote --- We are not talking about keyboard encoder anymore. We are now talking only about the "keyboard controller", which is located on computer motherboard. Anyway, shell we trust this document then, or not: ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf Keyboard/Mouse Input The Interrupt Transfer Descriptor for the USB keyboard and/or mouse is processed at the rate established by the Endpoint Descriptor’s location(s) in the interrupt list (a 1-ms rate is the recommended rate for emulation). The Transfer Descriptors are processed as normal by the Host Controller. When a successful transfer of data has occurred from the keyboard, the Transfer Descriptor is moved to the Done Queue by the Host Controller. At the beginning of the next frame when the interrupt associated with the transfer completion is to be signaled, an interrupt is generated. System software should ensure that the Interrupt Routing bit in HcControl is set to 1 so that these interrupts will result in an SMI. Upon receipt of the SMI, the emulation software removes the Transfer Descriptor from the Done Queue, clears the HC IRQ, and translates the keyboard/mouse data into a equivalent PS/2-compatible sequence for presentation to the application software. For each byte of PS/2-compatible data that is to be presented to the applications software, the emulation code writes to the HceOutput register. The emulation code then sets the appropriate bits in the HceStatus register. If keyboard/mouse interrupts are enabled, setting the HceStatus register bits cause the generation of an IRQ1 for keyboard data and IRQ12 for mouse data. The emulation code then exits and waits for the next emulation interrupt. When the host CPU exits from SMM, it can service the pending IRQ1/IRQ12. This normally results in a read from I/O port 60h. When I/O port 60h is read, the Host Controller intercepts the access and returns the current contents of HceOutput. The Host Controller then also clears the OutputFull bit in HceStatus and de-asserts IRQ1/IRQ12. If the emulation software has multiple characters to send to the application software, it sets the CharacterPending bit in the HceControl register. This causes the Host Controller to generate an emulation interrupt on the next frame boundary after the application has read from port 60h. --- END QUOTE --- End quote --- More of this DOS document?? As far as I know we are supposed to be talking about a windows environment or did that change too when you said we aren't talking about encoders anymore? Oh ya almost forgot, there is a pretty picture for you on page 10 of that 1.11 spec. It is in section 4.4 and shows how a USB HID device communicates with the pc (or in this case the HID driver). For some reason I just can't seem to find any PS/2 stuff in this specification. Could that be because it isn't used in USB? ;D |
| Driver-Man:
--- Quote from: SavannahLion ---Or insisting they show "proof" of their statements when the answers are right there in the documentation? --- End quote --- Yes, all I told you can also be found @ www.usb.org -- Don't you find it ridiculous you can not find a piece of text to quote and confirm your claims? --- Quote from: MonMotha ---Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off). --- End quote --- According to what? Show me. OpenHCI - Open Host Controller Interface Specification for USB (Compaq, Microsoft, National Semiconductor @ 09/14/99 2:33 PM) ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf That specification above, there is nothing to support your claims, you think they forgot to mention it there? Your PDF, why there is nothing there? The Internet, the whole world wide web contains no piece of text to support your claims? --- Quote ---I ran the Win32 native application that bangs directly on port 0x60. It got data from the onboard PS/2 keyboard but neither of the USB keyboards I had attached. This is consistent with what I just said: Windows reads port 0x60 for PS/2 keyboard data but gets USB data from elsewhere (directly from the HCI) and merges it together itself for presentation to userspace applications via the Win32 API. Since reading port 0x60 bypasses the Win32 API, it will only get data actually present on port 0x60 which is PS/2 data. --- End quote --- No source code, no binary downloads, can we not try it out? --- Quote ---The DOS version *DOES* get data from all sources because it's running inside NTVDM. NTVDM uses the conventional Windows APIs to get keyboard data before stuffing it into an emulated port 0x60 interface. Hence, any keyboard Windows knows about will be passed to a DOS application inside NTVDM via port 0x60. This ONLY happens because that DOS application is running inside an EMULATION LAYER to emulate DOS. --- End quote --- According to what? Why is it OpenHCI USB specification only confirms what I said? Why can you not quote any source to confirm your claims? Show me. --- Quote from: JustMichael ---In a dos box, yes it can through EMULATION. --- End quote --- Emulation of KEYBOARD CONTROLLER and translation to PS/2 is in HARDWARE, not DOS BOX. See the specification and links above. --- Quote --- --- Quote ---What the...? Read what exactly? Stop talking about me, just show us the part of "the specification" you are referring to, copy/paste - can you do that? --- End quote --- You can read the HID 1.11 specification here: http://www.usb.org/developers/devclass_docs/HID1_11.pdf --- End quote --- Can you actually *say* (copy/paste) it? What part are you talking about exactly? --- Quote ---More of this DOS document?? As far as I know we are supposed to be talking about a windows environment or did that change too when you said we aren't talking about encoders anymore? --- End quote --- DOS document?!? Open Host Controller Interface Specification for USB ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf Uh. Windows? Ok, show me anything, anything at all where it even suggest your claims are correct. Why is it you can not point any specific part in any of these documents? Show me. --- Quote ---For some reason I just can't seem to find any PS/2 stuff in this specification. Could that be because it isn't used in USB? --- End quote --- You are looking at the wrong document, you can not find anything there to support your point either, though you can find some hints to confirm mine, of course. This is THE specification: Open Host Controller Interface Specification for USB ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf |
| newmanfamilyvlogs:
from the PDF you linked: --- Quote ---To minimize hardware impact, the Host Controller accesses a USB keyboard and/or mouse using the standard OpenHCI descriptor-based accesses. The emulation code sets up the appropriate Endpoint Descriptors and Transfer Descriptors that cause data to be sent to or received from a USB keyboard/mouse using the normal USB protocols. When data is received from the keyboard/mouse, the emulation code is notified and becomes responsible for translating the USB keyboard/mouse data into a data sequence that is equivalent to what would be produced by a PS/2-compatible keyboard/mouse interface. The translated data is made available to the system through the legacy keyboard interface I/O addresses at 60h and 64h. Likewise, when data/control is to be sent to the keyboard (as indicated by the system writing to the legacy keyboard interface), the emulation code is notified and becomes responsible for translating the information into appropriate data to be sent to the USB keyboard/mouse through the transfer descriptor mechanism. --- End quote --- If that's legacy, then what superseded it? |
| CheffoJeffo:
It's like deja vu all over again! ::) |
| Navigation |
| Message Index |
| Next page |
| Previous page |