valve never encouraged people to support controllers, WORSE, 99% of games expect you to use XBOX controller, as a result XBOX controller are displayed even if you use a DUALSHOCK one
valve could have provided APIs so they can feed games with proper icons etc etc, but nothin"
Out of all of your rather dubious points against Valve's plans, this is by far the most absurd. Have you heard of a little thing called Steam Input? Valve in fact have provided an API that does everything you've listed including feeding the "proper icons". It's up to the developers to use it. That would not change even if the game was 100% native because xinput is still the industry standard. Controller support on Steam is second to none.
"you don't come up with such a device over night, they had years to think about that, they focused on emulation
we will see who was right in the end, i think i am"
No, I think it's safe to conclude that you are wrong even from this date. You're asking Valve to compete with a platform that has all the games available. You're also assuming that native is always better than non-native but as I've already seen, a crappy native port is often beaten in both performance and feature set by Proton. Instead of asking developers to gamble away valuable time on the OS of a device that could be a flop, it makes a lot more sense to release the device with the games currently available in the market in mind and then give developers an incentive to add special support for a device that is actually out in the wild in the hands of paying customers.
You also really do not need to implement every Windows API, you only need to translate draw calls to Vulkan and then a small subset of API's that actually relate to games such as sound. Your example doesn't make a lot of sense, the only way a security API would matter for Proton is if the game is from the Windows store but most people do not in fact use the Windows Store even on Windows so games tend to get released on Steam as well - including even many Microsoft titles.
At the end of the day though, Valve's approach has made it so that I already do not miss Windows for gaming even with the current non-ideal situation with anti-cheat. If they adopted your approach, we would have likely had a small increase in the number of native games but most of the industry would have probably ignored such a call. It would also be very unlikely to magically make desktop Linux a real competitor. I think we need to stop chasing that dream because frankly, it just doesn't make a lot of sense to me. The only way you would be able to compete with Windows and Mac is by having a similar marketing and UX budget and by removing or downplaying many of the attributes of desktop Linux that likely drew us towards it in the first place - package management, hyper-extensibility, the terminal, GPL licensing, etc.
I do not think it's worth it frankly. There is nothing wrong with being "niche".
valve never encouraged people to support controllers, WORSE, 99% of games expect you to use XBOX controller, as a result XBOX controller are displayed even if you use a DUALSHOCK one
valve could have provided APIs so they can feed games with proper icons etc etc, but nothin"
Out of all of your rather dubious points against Valve's plans, this is by far the most absurd. Have you heard of a little thing called Steam Input? Valve in fact have provided an API that does everything you've listed including feeding the "proper icons". It's up to the developers to use it. That would not change even if the game was 100% native because xinput is still the industry standard. Controller support on Steam is second to none.
"you don't come up with such a device over night, they had years to think about that, they focused on emulation
we will see who was right in the end, i think i am"
No, I think it's safe to conclude that you are wrong even from this date. You're asking Valve to compete with a platform that has all the games available. You're also assuming that native is always better than non-native but as I've already seen, a crappy native port is often beaten in both performance and feature set by Proton. Instead of asking developers to gamble away valuable time on the OS of a device that could be a flop, it makes a lot more sense to release the device with the games currently available in the market in mind and then give developers an incentive to add special support for a device that is actually out in the wild in the hands of paying customers.
You also really do not need to implement every Windows API, you only need to translate draw calls to Vulkan and then a small subset of API's that actually relate to games such as sound. Your example doesn't make a lot of sense, the only way a security API would matter for Proton is if the game is from the Windows store but most people do not in fact use the Windows Store even on Windows so games tend to get released on Steam as well - including even many Microsoft titles.
At the end of the day though, Valve's approach has made it so that I already do not miss Windows for gaming even with the current non-ideal situation with anti-cheat. If they adopted your approach, we would have likely had a small increase in the number of native games but most of the industry would have probably ignored such a call. It would also be very unlikely to magically make desktop Linux a real competitor. I think we need to stop chasing that dream because frankly, it just doesn't make a lot of sense to me. The only way you would be able to compete with Windows and Mac is by having a similar marketing and UX budget and by removing or downplaying many of the attributes of desktop Linux that likely drew us towards it in the first place - package management, hyper-extensibility, the terminal, GPL licensing, etc.
I do not think it's worth it frankly. There is nothing wrong with being "niche".