geekhack
geekhack Community => Keyboards => Topic started by: JZM on Mon, 15 July 2013, 22:03:08
-
Not happening now, and there is no tab in Device Manager with the usual checkbox. (Kinesis shows as HID Keyboard Device in Windows 8.)
Suggestions welcome--thanks!
-
Not happening now, and there is no tab in Device Manager with the usual checkbox. (Kinesis shows as HID Keyboard Device in Windows 8.)
Suggestions welcome--thanks!
You cannot wake with 99% of USB devices, including keyboards, as the G1,S2+ states do not provide any power to USB. Wake from USB is only possible from G1,S1 and not all devices support it - if USB 'power saving' is enabled, keyboards will go to D2 (host-side wake only) or D3 cold (no power).
That's why you can do G2(S5) -> G0 with PS/2 on some boards - they route 5VSB to ACPI_Switch and PS/2 +VCC - but not USB, because the controller (on the chipset) cannot be powered up.
-
So, in English, you're saying it depends which state you want to wake from.
D3 is partially powered (not cold, no power), and allows wake-up from the device. Did you mean D4?
I guess the answer is simply that the Kinesis does not support waking.
-
So then I could disable USB power saving and wake with Kinesis? If so, how would I do that?
Logitech mouse and Microsoft keyboard both woke the computer, no prob. Both wireless if that makes a diff...
-
Well that also points to the Kinesis not being able to do wake up... there's a flag in the configuration descriptor that USB devices send to the OS that says if it can or not. Sounds like Win8 is reading that flag, finding it unset, and so disables the checkbox. Nothing you can do about it, if that's the case :(
-
So, in English, you're saying it depends which state you want to wake from.
D3 is partially powered (not cold, no power), and allows wake-up from the device. Did you mean D4?
I guess the answer is simply that the Kinesis does not support waking.
No, I meant D3. D4 is a misnomer; it's D3hot/D3cold. Windows defaults to D3cold, and even when not, D3hot also doesn't work. e.g. A USB mouse in D3 hot cannot wake the system. USB is a (sarcasm)delightfully(/sarcasm) half-baked bus. The only difference is that D3 hot can be used for charging devices because it provides 5VCC but disables DATA+ and DATA-, and D3 cold disables all pins including 5VCC.
As far as presence/absence, yeah, no. It doesn't point to anything other than current device state and even that's pretty iffy more often than not. Windows USB stack is a nightmare and a half - I say this having had to do some SERIOUS troubleshooting of USB devices. (When you're doing things 'Run as SYSTEM' you know it's gone pear-shaped.) What's disabled one boot may or may not be enabled the next, or vice versa. My general suggestion is for anything without kernel level drivers, presume it will not work for S2 or S3 wakeup.
-
I had hoped to mod this until I don't need a mouse at all--but that's not going to work if the keyboard can't wake the computer...
-
Ah... well if you're into modding it, would replacing the controller be an option?
Bottom line is that if other USB keyboards worked to wake the computer, then something is up with the Kinesis. You could check the wake-up flag with a tool such as USBlyzer (the trial version works fine).
Apparently (http://geekhack.org/index.php?topic=37991.msg906779#msg906779), the Advantage is mostly a PS/2 keyboard with a PS/2 to USB converter tacked on. That could be a reason for it not having wake support, since it can't easily go to a low power state.
-
Apparently (http://geekhack.org/index.php?topic=37991.msg906779#msg906779), the Advantage is mostly a PS/2 keyboard with a PS/2 to USB converter tacked on. That could be a reason for it not having wake support, since it can't easily go to a low power state.
Ding ding ding.
This is pretty much exactly why I still prefer PS/2. Because all USB is doing is trying to copy it (badly) and offering nothing of significant value. I like just smacking space bar to turn on my computer.
-
Apparently (http://geekhack.org/index.php?topic=37991.msg906779#msg906779), the Advantage is mostly a PS/2 keyboard with a PS/2 to USB converter tacked on. That could be a reason for it not having wake support, since it can't easily go to a low power state.
Ding ding ding.
This is pretty much exactly why I still prefer PS/2. Because all USB is doing is trying to copy it (badly) and offering nothing of significant value. I like just smacking space bar to turn on my computer.
Because PS/2 has such great low-power support, right?!
From what I can tell, a properly Energy Star compliant motherboard ought to be powering down the PS/2 port as well, in S5.
Look, the problem isn't with USB - it supports low-power states just fine. PS/2 to USB converters have the problem that they don't want to add circuitry to shut off power to the PS/2 keyboard, so they can't go low-power (mine can sleep, and wake-up the PC from standby, but it breaks the rules on power).
The problem really seems to be with Energy Star and the definition (or interpretation?) of S5 'Soft Off'. This short thread on Intel Communities (http://communities.intel.com/message/177233) seems to sum it up - reading between the lines, manufacturers don't give a crap as long as governments will buy their stuff!
The whole policy of minimising S5 power consumption backfires because people get what they want from S3 or S4 instead, using more power overall!! For example, people wanting to be able to press space to start their machine up in the morning will just use Standby instead of Shutdown. S5 needs to be more flexible.
-
So with all this talk of USB devices not being able to wake computers from sleep, or at least they shouldn't be able to, why can I wake any computer I have with any USB keyboard or mouse that I have connected to it?
-
I just tested this on a Windows 8 computer here at Kinesis and the Advantage keyboard wakes the computer perfectly fine. I'm not very familiar with Windows 8 so I'll have to look into possible settings in the OS, but from my testing here it worked. We haven't heard of any reports from any users of this being a problem on Windows 8 (or Windows 7).
-
Apparently (http://geekhack.org/index.php?topic=37991.msg906779#msg906779), the Advantage is mostly a PS/2 keyboard with a PS/2 to USB converter tacked on. That could be a reason for it not having wake support, since it can't easily go to a low power state.
Ding ding ding.
This is pretty much exactly why I still prefer PS/2. Because all USB is doing is trying to copy it (badly) and offering nothing of significant value. I like just smacking space bar to turn on my computer.
Because PS/2 has such great low-power support, right?!
From what I can tell, a properly Energy Star compliant motherboard ought to be powering down the PS/2 port as well, in S5.
Wrong. EStar does not require depower of SuperIO unless it is A) not LPC B) cannot exclusively use 5VSB. Which is NOT THE 5V LINE. G2(S5) mandates that 5VSB stay hot, and ACPI does not preclude WOL (magic packet) or Wake-From-Device-Arrival unless said support requires any line other than 5VSB remain hot.
An EStar and ACPI compliant motherboard which can do power-on from PS/2 in S5 state is literally doing nothing more than using the LPC SIO as a soft switch from G2(S5) and does not go to G3 except on AC loss or specific command. EStar does not mandate G3 use. Hell, it doesn't even specify or require G2. See here (http://www.energystar.gov/index.cfm?c=power_mgt.pr_power_mgt_ez_gpo_faq) for more details.
As far as "low power" what part of "PS/2 limit is 275mA" is unclear? FYI that's less at maximum than a USB "Medium" (500mA) request, and barely over a "low" (250mA) request. Combined with the LPC SIO, you're talking about a total of around maybe 250mA-500mA (0.5A) demand for PS/2. Uh, yeah, that's less than WOL allowance. This is a typical high end Super I/O ASIC (http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=51f8b3a0-406a-47fa-8c57-7f1ace284be7) from Nuvoton. It operates off the 3.3V line normally and is '5V tolerant' (meaning 5VSB supply capable.) It also draws a whopping 8.0mA @ 3.3V with +-10μA leakage. Pretty sure that qualifies as "low power."
By comparison, the Renesas μPD720202 USB3 host controller (2 port) requires 3.3V (so a 5VSB->3.3V or 3.3V hot), external 24MHz reference crystal, and 3.6mA with nothing attached. A single device brings that 'low power USB3' to 148mA @ 3.3V for just the controller - excluding the USB device power draw. Yes, the controller itself draws 18.5x as much as a high end Super IO with PS/2, GPIO, UART and INT trigger capability.
Look, the problem isn't with USB - it supports low-power states just fine. PS/2 to USB converters have the problem that they don't want to add circuitry to shut off power to the PS/2 keyboard, so they can't go low-power (mine can sleep, and wake-up the PC from standby, but it breaks the rules on power).
Sigh. Why do people continually hear things I didn't say and put words in my mouth? That is beyond annoying. I'm not addressing the converter either.
What I said was the USB controller typically resides on the chipset and requires more than 5VSB. Do not claim I said it did not support low power. That is not what I said, period. What I also said was in essence you cannot use USB to wake from G2(S5) because it requires more than 5VSB for the root complex - the exception being non-chipset root complexes with specific 5VSB support.
In either case, you cannot wake from a device in D3 Cold because the point of D3 Cold is that it won't do that. The EStar rules do not mandate a specific state, only capabilities, thus neither D2, D3 Hot or D3 Cold specifically violate rules. Because there's no rule for it. Complete EStar rules for computers are here (http://www.energystar.gov/ia/partners/prod_development/revisions/downloads/computer/Version5.0_Computer_Spec.pdf?8b2d-6ae1). TL;DR version is: EStar only requires capability, it does not mandate specific operation modes.
Your typical maximum source side (PSU) on 5VSB is 1A; this has to supply all 5VSB demand from both switches and motherboard components. Factoring in expected draws and efficiency losses, you end up with <200mA on a 5VSB source of 1A - before keyboard. Which means exactly what you think it does - a 1A 5VSB cannot supply an M5/M13 using double Y cable (single PS/2 on motherboard a la Gigabyte.) Yes, this makes engineering "fun."
And yes, the same token applies to USB and this is why 'charge while shut down' features mandate a 2A+ 5VSB supply. Usually runs right around 950mA (0.95A) before root complex (non-chipset, typically ASMedia, NEC/Renesas, etc.) power. Which frequently has either a dedicated 5VSB input line or a source switching circuit forward of the root complex controller. 'Supercharger' setups (>1A over USB) use in-controller limit bypass for pre-USB3 and take off the primary +5VDC or +12VDC.
As far as the peripheral side behaviors, I don't know and I stay out of that rat's nest for exactly those reasons. It is a rat's nest, there is little to no consistency despite claims to the contrary (don't even try claiming UHID is consistent with the "N-Key" hacks and 'guess if SELSUS breaks it' going on.)
The problem really seems to be with Energy Star and the definition (or interpretation?) of S5 'Soft Off'. This short thread on Intel Communities (http://communities.intel.com/message/177233) seems to sum it up - reading between the lines, manufacturers don't give a crap as long as governments will buy their stuff!
Yes, that is part of the problem. ACPI clearly defines G2 but EStar does not and doesn't care, because they attempt to lump all systems (desktop, notebook, server, etc) into a single category. Look at the actual rules - they include Game Consoles. Basically EStar is purely a marketing thing from a manufacturer and vendor standpoint. It doesn't mandate anything and the grand extent of it is their 'EZ GPO' as best practices.
EStar also doesn't use ACPI definitions because they lump in non-ACPI devices (consoles, non-x86 servers, etc) and manufacturers also need capability for non-ACPI defined states (e.g. Hot Standby S1+Global D0). I mean seriously - EStar 5.0 qualified devices include Xbox 360 (New Version), HP Integrity servers, and IBM zEnterprise. They all work off that same sheet. So yeah. EStar is pretty much worthless.
The whole policy of minimising S5 power consumption backfires because people get what they want from S3 or S4 instead, using more power overall!! For example, people wanting to be able to press space to start their machine up in the morning will just use Standby instead of Shutdown. S5 needs to be more flexible.
This is absolutely and totally wrong. On a level that scares the crap out of me. Did you not actually read the ACPI state descriptors?
S3: Suspend To RAM (STR) - maintain voltage to DRAM and related controllers (e.g. chipset, CPU) to maintain state
G2: AKA S5, Soft-Off - only 5VSB is maintained. No states are preserved.
What the hell? Seriously. They're not even comparable states, period - S3 requires 5VSB, 3.3VDC, 5VDC and 12VDC lines all remain hot. (Selected CPU registers and cache elements must remain hot.) Albeit at a low power state, but still hot for the duration. Which is a significant amount of power draw - typically on the order of several watts. Usually around 10+ for older/low efficiency and still 4+ for high efficiency.
The whole point of S3 is that the system is still on and powered. The whole point of G2 is that the system is off. In a G2 state with 5VSB hot and an IBM Model M attached the maximum typical draw of a 2A rated 5VSB is less than 3/4 of a watt (at 110V). You don't freaking need flexibility for G2, period, at all. The whole POINT of G2 is "system == off." If you want to boot faster from G2, get on Phoenix, Award and AMI to magically make Real mode not be 16-bit, make it faster, and/or get an SSD.
More to the point, you're pointing fingers at the wrong people with your complaints. ACPI states define system state and do not define anything else. If I want to implement G2 and suck down so much power I need a 10A 5VSB because it's powering a dozen blinkenlights and crap? That will pass ATX and ACPI (5VSB does not have an upper bound.) If I want to use GPIO and a 3 position switch to go between S0-S3-G2 and power that exclusively off 5VSB, it will also pass.
Or to address the specific complaint: absolutely you can use a USB device to do a G2->S0 transition switch. And it will pass ATX, ACPI and EStar with flying colors. All you need is A) external root complex which can operate independent of BIOS from 5VSB, B) must maintain device in D2 or D3 Hot off 5VSB at <500mA, C) root complex must differentiate devices (e.g. UHID from Mass Storage), selectively suspend non-HID, and devices must support signalling in D3 Hot D) ability for external root complex to act as soft switch (presumably via GPIO pin) to BIOS watch lines. You have a total headroom for EStar of 2W @ 115VAC. And yes, the problem is that the manufacturers are half $&*@ing A and just not doing C or D. Mostly because external root complexes just don't do C period, because it is complex and expensive - you pretty much need a full stack to do C. In a single tiny and already complex ASIC. Adding the PROM into the silicon is bad enough - but then you get into the compatibility nightmares, because the other side of C is peripheral manufacturers. And we already know what a mixed bag that is.
So HOPEFULLY this explains why you can't do S4,G2->S0 with USB or S3->S0 with D3 Cold or Selective Suspend currently and why I HATE USB from that perspective in sufficient detail to answer ALL questions.
Yeah. Heat index of 98F (over 36C) and no A/C makes me a touch grumpy. Promise I'll be less grouchy when the weather stops being crap. :P
(Also possibly more coherent.)
-
Dang! If you had thought a ltitle about what I was saying, you might not have had to write quite so much!
On some points we are in agreement, yet you are arguing anyway... I can't fathom that, or reply to it.
275mA at 5V is 1.375 Watts - massive compared to Energy Star's allowance, which as you say is 2 Watts.
By comparison, an AVR set to a mode where it will wake itself on a keypress is microamps. Totally insignificant.
FFS, I know S3 isn't comparable to S5 - that's the exact point I was trying to make. I'm saying that IF a user can't get the behaviour they want from S5, they'll use S3 or S4. Even for something trivial. So there's not much point making S5 too restrictive (wake-up stuff should all be off by default anyway).
Agreed on the USB controller / chipset problem though (if I take your word that they suck power) - it's really up to the manufacturers to solve it so that there is a way to keep USB stuff powered enough to do wake-up, while using very little power in the controller itself.
So the point is that powering the USB controller will take more power than not, obviously, but if that means systems spend more time in S5 than S3 or S4 it would be a good thing.
(Note to OP - this tangent has nothing to do with your problem if other USB keyboards will wake your computer. Sorry for the disruption).
-
I just tested this on a Windows 8 computer here at Kinesis and the Advantage keyboard wakes the computer perfectly fine. I'm not very familiar with Windows 8 so I'll have to look into possible settings in the OS, but from my testing here it worked. We haven't heard of any reports from any users of this being a problem on Windows 8 (or Windows 7).
Are there multiple revisions of the USB controller in the Advantage?
I'm just wondering what other info the OP might be able to provide to help narrow it down...
-
Dang! If you had thought a ltitle about what I was saying, you might not have had to write quite so much!
On some points we are in agreement, yet you are arguing anyway... I can't fathom that, or reply to it.
Well, answering a whole batch of questions at once which involves going into extreme detail on how sub-BIOS level calls work, without getting into 2-wire interfaces. So not just answering your stuff. I swear, it's the heat. :P
275mA at 5V is 1.375 Watts - massive compared to Energy Star's allowance, which as you say is 2 Watts.
Yes, but that's 275mA maximum, remember. Pretty much nothing draws that. A typical PS/2 rubber dome, you're talking on the order of <100mA with the numlock LED lit. Plus you have to factor in host-side controller - which adds 8mA giving a total of 1.38W off the top of my head, and that's absolute maximum before losses. (Losses give you around 1.4W.) WOL allowance is 0.7W but typical usage is <0.5W so really you're looking at ~1.9W on the 5VSB full bore G2.
By comparison, an AVR set to a mode where it will wake itself on a keypress is microamps. Totally insignificant.
Yes, but that's the catch. It has to wake itself. In order to wake itself, it needs to supply sufficient power for the uC to be operating. Otherwise, may as well wire GPIO or UART on SIO. Somewhere around here I have a diagram for setting up SIO w/UART to sit at the 8mA and trigger power on with a Tx signal over serial, if you wanna go really low power. Or you can use an unpowered switch and watch GPIO for short.
FFS, I know S3 isn't comparable to S5 - that's the exact point I was trying to make. I'm saying that IF a user can't get the behaviour they want from S5, they'll use S3 or S4. Even for something trivial. So there's not much point making S5 too restrictive (wake-up stuff should all be off by default anyway).
The point I was making is that S5 isn't an S state, it's a G state. G2 contains one sub-state, S5. G2 defines all sub-states as 'no saved states, system off.' If you wanted something between S4 and S5, it would have to go in G1 below S4. It cannot go in G2. Not unless you want to completely invalidate all prior ACPI and create a giant OS compatibility nightmare. (Every developer will string you up by your thumbs if you do.)
Agreed on the USB controller / chipset problem though (if I take your word that they suck power) - it's really up to the manufacturers to solve it so that there is a way to keep USB stuff powered enough to do wake-up, while using very little power in the controller itself.
Which isn't going to happen. A) USB uCs are stupid complex. B) USB is a power hog comparatively, period. Especially 1/2. C) You're over a 64TQFP if you want to add GPIO. D) You'd have to do USB over 2-wire or speaking 2-wire at root complex so yeah that's NOT happening. In G2, the CPU is halted and depowered with no state information. Meaning you don't have a running BIOS. Well, USB3 uCs are loading at least partial from BIOS minimum. Most depend on running BIOS for IPL via OROM structure. Actually - I don't think there's any that isn't reliant on BIOS for IPL. Sans running BIOS, you basically have a dumb pile of silicon.
Any device wanting to be used to wake the computer must operate as a standard 'soft (momentary close) switch.' As opposed to the AT standard 'hard switch' push-lock style. LPC provides a specific hook method in some implementations, making this possible, as do older I2C-style implementations among others. Fundamentally, this is trivial - the most basic implementation would be a 'pull low' GPIO pair on an AVR directly cabled to the PWRSW 2-pin header on the motherboard. Laugh all you want, but that's the simplest way to explain and implement. So provided you keep the keyboard side hot using external power source (these don't count for EStar, ha!) you could do wake-from-keyboard using anything. Hell, you can use a Cherry MX switch as a power button internal OR external.
... brb, drawing up plans to that effect.
But I digress; as I said, the biggest issue is that USB root complexes are a big fat power-gobbling pain in the ass. And they aren't going to improve any time soon, especially as the trend is to provide MORE power over USB, which necessitates larger and more complex silicon, which creates greater leakage at low voltages to handle the high ampere loads, with 'advanced power management' making the implementation even more complex, necessitating more transistors for processing work, and so on. You get the idea. LPC SIO draw has basically bottomed out around 4.0mA (four point zero) for the most basic of implementations, while USB root complexes keep going up toward 4A+ (e.g. the Renesas 4 port USB3.)
So the point is that powering the USB controller will take more power than not, obviously, but if that means systems spend more time in S5 than S3 or S4 it would be a good thing.
Except as I mentioned above - you're getting up to 4A+ 5V supply plus 1A 3.3V before losses. Plus you need a full running stack with full state if you want to filter device by type, much less restrict it to actual input. e.g. not turning on when a mass storage device produces jabber or jitter. I've tested some experimental-ish implementations of turn-on from USB which basically would randomly turn on and off if any slightly imperfect USB device was introduced to the bus.
To get that full stack, you need at minimum a real-mode CPU (16-bit) and you need several megabits of storage - which has to be supplied by the BIOS via OROM. Well, hey, OROM space is limited since OROM has to go into protected memory and some of the crap that ships these days is just ridiculously huge - even with LHA/LZMA compression enabled. They don't usually load a full stack as a result; usually it's a partial stack loaded from OROM which only includes UHID Keyboard and USB Mass Storage support. Other devices may be detected and identified, but don't function.
-
OH dear, another wall of text that COMPLETELY misses the point of what I was saying.
G2 / S5 / G2(S5) - who cares? - S5 is S5 and everyone knows exactly what I'm refering to when I say that.
Besides, S5 is more specific than G2. G2 could theoretically include further states in the future, but S5 will still be S5.
I don't want something between S4 and S5 or any other such imagined nonsense. I want them to produce hardware that works to allow wake-up using minimal power when in S5. I don't want to see cop-out answers like that one from Intel.
I'm not saying run a power hungry controller in S5. I'm saying (for the third time) that people end up using S3 or S4 if they can't get what they want from S5. So S5 doesn't get used as much as it could IF people could do what they wanted with it (like wake up from a USB keyboard). It simply depends on having a low-power way to detect the USB resume signal coming from a device.
Detecting that resume signal does not require even a partial USB stack etc. running. Responding to it does, but then that's kinda the point of a wake-up signal!! In theory. In practice of course it's limited by available components. But just because certain implementations might be 'bad' doesn't make the whole USB standard 'bad'.
Bottom line: you don't need power hungry silicon or code to detect this...
(http://www.usbmadesimple.co.uk/ums_g_resume.gif)