r is just a number and doesn't explicitly store or encode any point coordinates. In a signature,
r is set to the X coordinate of the point
R, which is really
k is the secret nonce used during signing, then reduced mod the curve order.
In secp256k1, this usually means that
r is in fact the X coordinate (because
r itself is usually very big), but it is not always so.
During verification, the verifier attempts to reconstruct the original
R point by from the signature values
(s, r), the message
z and the signer's public key
P by solving the equation
s*R' = z*G + r*P, then reduce the X coordinate of
R' mod the curve order and check that it is equal to
r given in the signature.
I've never used openssl, but the process seems to be in
ossl_ecdsa_verify_sig(). So you can see
R' being computed here :
After these lines, the reduction mod the order is done and finally the equality test. In simple signature verification, the Y coordinate of
R' is not used, but it is available from the value
point (which is
R') in openssl's implementation.
Also, I just realized I should add a something about pubkey recovery since you mention the
recid value in your question.
When doing pubkey recovery from message and signature (as in the case when the signer's pukey is not given), to get the Y coordinate from a possible
R' point, you would try a few values based on
r as the candidate X coordinates.
The possible X coordinates of
R' will be
r itself, or
r + curve_order (and both can be valid X's). You can then solve the curve's equation
y^2 = x^3 + 7 to get the possible Y values for each.