That setting only sizes the window that mirrors your view on the desktop, and has nothing to do with what you get in the headset.
Resolution settings in the various stages along the VR pipeline do not “interact”, as such - they are just “inherited” from start- to end point:
-
The resulting resolution given by your PiTool settings (Quality, and PP on/off), is the headset resolution piserver tells to SteamVR…
-
SteamVR then applies its own modifying factors (global and per-game) on this, producing the resolution it recommends the game to use (…which the game is perfectly free to ignore, and which e.g. many UnrealEngine4-based games infamously do).
-
The game in turn can multiply the size of the bitmap rendered, as recommended to it by SteamVR, using its own “HMD Quality” setting.
-
The frame pair, information on how large they ended up, attached, is then handed back down the line, from the game, thru SteamVR (…which may add some overlays, if active)…
-
…to Piserver, which pre-distorts them, so that they come out right when being seen through the opposite distortion caused by the HMD lenses; Resampling them for native screen output in the process (possibly with optimised texture filtering depending either dynamically determined on the the size of the incoming frames, or on the Pitool Quality setting at the bottom of the stack, but this possibility has only ever been implied, so how knows). .
Elite also has a “Supersamling” setting, which basically (…for this game - others titles may call things differently) does the same thing as “HMD Quality” - rendering smaller or larger images than requested, but, crucially, resamples to the requested resolution on its own, before handing the finished frame pair over to SteamVR. This means any extra detail rendered will be “baked in” into the picture, so to speak, and can therefore detrimentally not be of benefit when piserver does its pre-distortion pass (it is locked in place as a downsampled part of a certain texel, and can not be spatially moved individually, to its new location on the output bitmap, which loses some precision).
That said: This ED option; “supersampling” (…other than it working when playing on a monitor as well…) does have its place, because most fast sampling algorithms will get to the point where they start to skip source-image pixels, if their incoming source pictures are overly large - often around the region where the input is twice the size (twice width and height - not twice the area) of the output.
If one’s final render resolution (PiQ x SteamVR x HMDQ) surpasses that size, more detail will be preserved, rather than rendered and then just discarded, if pre-sampled-down to the 2x point, before we get to the final resampling step to native screens.
In the past, some have actually professed a preference for using the slight blurring cused by using a little bit of the Elite Dangerous “supersampling” (typically a value less than 1, rendering smaller images, which are then up-scaled" to game output resolution (which may include a countering greater than 1 HMDQ), to somewhat blur out the strong aliasing associated with the game.
I’ve never agreed with this myself, hating blur even more than I do aliasing, but may have to reconsider my stance come ED:Odyssey, some of whose new distant terrain detailing comes very high in both frequency and amplitude, which (at least in the alpha - we’ll se about release) produced a lot of discretely light and dark pixels blinking in- and out in a ludicrous turmoil of aliasing, as one flew over it - here I found that tuning down some of one’s HMDQ, and bringing in a bit of SS in its place, produced some more natural-looking mid tones, and began to eliminate the sense that the ground looked like TV static. 
