gbdev
"PAD" symbols are not hardware-related
Despite the name of the file, the _PAD_ symbols are not related to hardware at all. They are a common software convention used by algorithms that aim to make button input easier to use.
When I reading through the file, it was very confusing that these symbols are included. While it would make more sense to remove them completely (so algorithms have to ship with the constants that apply to specifically that algorithm), I can understand that they should remain in place for compatibility reasons. In that case, a note should be added, clearly marking them as a software convention.
Duplicate of #37.
Anyhow, I think the comment mentioning that this is "conventional order" should make it clear enough that this is, indeed, a mere convention.
Might be a language thing here. "conventional" is not specifically thought of as related to "convention". In my usage, it is equal to "usual" or "old but still valid". I admit that even being the "usual" order implies that it is a convention if you assume that hardware is unambiguous, though it would not exclude that there could be a way to set the hardware to use the combined styles (wasn't this planned for the CGB?). I think it should be unambigously stated that this is a software convention. Since this the symbols are useless without the algorithm that provides the value that they are meant to be applied to, one might even consider providing an example for such algorithm in a comment.
The PAD constants have been around ever since the start of hardware.inc. They're useful because people almost always (or literally always) pack their eight inputs into high and low nybbles, so hardware.inc prevents them from reinventing one of two wheels. It's not just backwards compatibility -- if they didn't already exist, we would want to create them.
For very precise and detailed explanations of Game Boy hardware properties, we have Pan Docs. hardware.inc is only secondarily a hardware reference; its main purpose is to be usefully included in people's Game Boy software projects. As such, the PAD constants are very appropriate in it, even though they don't correspond to a literal property of the hardware. (And I do think that having "conventional" and "swapped" orders makes that sufficiently clear.)
