# How does XNA's KeyboardState represent all keyboards?

I already understand how to work with Keyboard and KeyboardState, but when debugging I happened to take a look at the KeyboardState's non-public members via the VS debugger. I expected to see a large list of values, but instead, only saw 8 uints at a static level, and another 8 uints per instance:

Non-Public members  (static)

Non-Public members  (instance)
currentState0   uint    0
currentState1   uint    0
currentState2   uint    0
currentState3   uint    1048576
currentState4   uint    0
currentState5   uint    0
currentState6   uint    0
currentState7   uint    0


There are 32 bits per uint, so having 8 of them essentially acts as a field of 256 boolean values, which loosely corresponds with the Keys enum type, so I assume that the static values act as a way to test which buttons are present on a device. However, XNA supports up to 4 keyboards, so I'm not sure how it both translates this to a button state, nor how it can differentiate between different keyboards in this way.

XNA only supports one keyboard. It supports up to four chatpads, which look exactly like keyboards in terms of the state they track (note the subtle differences in the overloads of Keyboard.GetState).
Anyhow, KeyboardState object just reflects the state of a keyboard or chatpad. On its own, it doesn't know or care about whether or not it's representing the state of the keyboard or the state of a particular player's chatpad, or what.
When you call the GetState overload that takes a player index, the Keyboard interface can kill out the KeyboardState with the appropriate bits for the specified player at that point, so KeyboardState itself only needs enough storage to represent a single keyboard state.