Can anyone explain to my why people are creating new embedded systems with Windows?
It seems to me that the developer experience, ecosystem and driver support is worse in literally every single way, not to mention you don't have control over the OS code.
Working video support (without hardware acceleration) out of the box without any external drivers for all current and future graphics cards because they actually implement the “core” vga spec (plus all the official and unofficial revisions to get higher resolutions working).
We have to ship updates to our bootable Linux and BSD applications every six months just so customers don’t get stuck in text mode, or worse yet, without a frame buffer after BIOS posts. Never had that problem with WinPE (RIP).
My go-to solution to booting an older Linux version on a newer GPU is `nomodeset` and possibly other flags that force-disable the use of device-specific drivers. I don't see how this is different on Windows.
That wasn’t a hypothetical, and yes, I looked for simple kernel cmdline parameters before hacking away at the VGA and UEFI framebuffer drivers in the kernel.
I’m not talking about KMS, that’s another ballgame altogether. You ship a fixed image starting up on unknown hardware that could have any card from 1999 to 2020 in it. You can’t load all drivers at startup because a) that’s crazy talk, b) many can’t be loaded simultaneously anyway. You can manually identify the VID and PID and create a database but it’s a monumental task, and you’re bound to miss some (and what about new releases?). You don’t want to ship with every driver under the sun anyway, because that’s huge, there are licensing issues, and many are buggy or error prone on recent kernel releases. All you want is a basic driver to give you a software-accelerated framebuffer and use the generic VGA/SVGA/XVGA/whatever standards to init the hardware, give you a workable resolution for GUI mode applications, query the monitor and use the EDID database to select a resolution and refresh rate supported by both the hardware and the attached display device, use the correct aspect ratio, avoid overscan or unnecessary scaling, etc. and give you an abstraction supported by your desktop environment including the window manager and your applications, without needing to hack away at every program you ship with to get them to support the sw framebuffer.
Xfree86 was such an effort but a) it’s long dead, and b) never really got there.
They start at the same place but it works better (more resolutions, greater hardware support, fewer bugs, etc), includes features that are outside the scope of the driver itself in the Linux design (EDID querying and matching for dynamic resolution and refresh rate detection), performs much better when doing software-accelerated operations, has driver/abstraction-level DPI scaling, and is compatible with all DE/software that doesn’t try to directly use OpenGL.
Mostly it’s just that the video abstraction on Linux is driver-dependent (eg access to video device/fb is dependent on choice of driver) functioning at a lower level than the Windows equivalent.
I’m not sure if it’s true but I hear Wayland is throwing away all support for non-drm framebuffers?
It seems to me that the developer experience, ecosystem and driver support is worse in literally every single way, not to mention you don't have control over the OS code.