The inverse of the transformation matrix that transforms user space to surface space (i.e. device space) can transform coordinate input to the coordinate system the user (programmer) is working in.
Depending on the scale of the transformation it's possible for the result to be inaccurate to a degree that the result is inaccurate, but that can easily be cured with a function that returns the input coordinates in surface space, which uses should use if the scaling factor of their transformation from user space to surface space is large enough.
It can only be cured, to an extent, when the spaces are equally dimensioned. I work in a field where I need to meld 1d, 2d and 3d input coming from varied sources with 1d, 2d, and 3d output. Hence I understand the challenges in making all that work without loosing precision+accuracy, and your sanity :-)
1d can be interpreted as being 2d, with the second dimension having no meaningful value. 3d graphics ultimately resolve to 2d on all displays I'm familiar with. That said, 2d graphics is only concerned with 2d graphical output. 3d graphics is a steadily evolving field in terms of functionality. 2d graphics has been functionally stable no later than the introduction of PostScript in the early 80s. Methods of implementing 2d graphics have changed, but the basic functionality (paint, stroke, fill, mask, and text rendering) have remained the same since then. Indeed, even text rendering is one or more combinations of stroke, fill, and mask, such that there are only four core functionalities involved.
-Mike