The driver dilemma

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
wdstudios
Posts: 9
Joined: Mon Aug 13, 2018 8:53 pm

The driver dilemma

Post by wdstudios » Mon Aug 13, 2018 9:17 pm

Hardware vendors have begun dropping driver support for Windows NT 5.1 and 5.2, and therefore, ReactOS.

LGA 1155 was the last Intel socket for which Windows XP/Server 2003 drivers exist. AM3+ was the last AMD socket for which such drivers exist. Radeon graphics cards for XP/Server 2003 don't go any better than the R9 270x, while Nvidia held out all the way up through and including the Geforce 900-series, but has dropped support in the Geforce 10 line.

Additionally, many programs, ranging from Pale Moon to Paint.net to World of Warcraft, have dropped XP support in their newest versions.

So... how will ReactOS deal with this?

hbelusca
Developer
Posts: 997
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: The driver dilemma

Post by hbelusca » Mon Aug 13, 2018 9:39 pm

As long as ReactOS does not update its kernel compatibility to Windows 7+, you will be condemned to use ReactOS on hardware for which vendors offered drivers for Windows XP/2k3.

Zombiedeth
Posts: 100
Joined: Fri Jun 27, 2014 9:01 am

Re: The driver dilemma

Post by Zombiedeth » Tue Aug 14, 2018 12:23 am

The problem is worse then that you can't get windows 7 or 8 motherboard drivers for brand new hardware. But have to see first and for most if ReactOS can complete XP driver compatibility. Trying to do xp and 7 driver compatibility just seems like it would become a mess

cb88
Posts: 49
Joined: Fri Oct 06, 2017 3:26 pm

Re: The driver dilemma

Post by cb88 » Tue Aug 14, 2018 12:33 am

You can inf mod the iCafe 32bit XP driver to support up to the Radeon R9 Fury etc... Haven't tried it but others have.

https://support.amd.com/zh-cn/kb-articl ... ified.aspx

Zombiedeth
Posts: 100
Joined: Fri Jun 27, 2014 9:01 am

Re: The driver dilemma

Post by Zombiedeth » Tue Aug 14, 2018 12:53 am

I wonder though will ReactOS be able to support multiple driver versions seems like even microsoft couldn't manage it properly. If you tried to use drivers for a previous version of windows they would often be buggy. For ReactOS it seems like it would be even more of a hurdle since it would be a old architecture trying to support a newer one.

PurpleGurl
Posts: 1593
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: The driver dilemma

Post by PurpleGurl » Tue Aug 14, 2018 11:56 am

I had a brainstorm earlier based on what Hermes said. Why not, down the road, have several different kernels and an installer that detects what kind of hardware it is, and installs the appropriate kernel with the rest of the OS and any appropriate shims, and reports whatever kernel that was installed and require those drivers. Maybe have an override to install a different compatibility tier in case the individual manufacturer provided newer (or older) drivers than what was available for comparable boards at the time.

With this type of system, only one kernel would be running and one set of drivers would be in use, and no mixing of Windows version levels. Now I don't know how the Windows 7 driver compatibility layer works. But I do understand that because of that layer, Windows 7 does not always have to reboot to install drivers, particularly when discussing sound and network drivers. Software that installs drivers doesn't always make use of this ability, since it might also install startup programs too.

cb88
Posts: 49
Joined: Fri Oct 06, 2017 3:26 pm

Re: The driver dilemma

Post by cb88 » Tue Aug 14, 2018 3:54 pm

That seems too complex.

What is more likely to happen is later driver APIs will be added to ReactOS but the UI will remain roughly XP/Server 2003... so that all driver API levels can run it. On MS Windows, the problem is they introduce new features that require the newer driver APIs in the UI mainly for marketing reasons honestly.

There probably aren't any real showstoppers for ReactOS supporting every XDDM and WDDM driver API revision there is as far as I know... win2k drivers though win10.

wdstudios
Posts: 9
Joined: Mon Aug 13, 2018 8:53 pm

Re: The driver dilemma

Post by wdstudios » Tue Aug 14, 2018 8:49 pm

Well then... it sounds like there is very little reason, if any, to switch from Xp x64 Edition to React, unless something bad happens to my XP x64 disk :\

karlexceed
Posts: 292
Joined: Thu Jan 10, 2013 6:17 pm

Re: The driver dilemma

Post by karlexceed » Tue Aug 14, 2018 11:51 pm

At this point, there's no reason to use ROS for anything beyond testing - it's alpha release software.

PurpleGurl
Posts: 1593
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: The driver dilemma

Post by PurpleGurl » Wed Aug 15, 2018 11:19 am

cb88 wrote:
Tue Aug 14, 2018 3:54 pm
That seems too complex.

What is more likely to happen is later driver APIs will be added to ReactOS but the UI will remain roughly XP/Server 2003... so that all driver API levels can run it. On MS Windows, the problem is they introduce new features that require the newer driver APIs in the UI mainly for marketing reasons honestly.

There probably aren't any real showstoppers for ReactOS supporting every XDDM and WDDM driver API revision there is as far as I know... win2k drivers though win10.
My loosely proposed system is likely less complex than the alternatives to do similar. Imagine needing some bulky compatibility layer that's emulating the kernel environment for every Windows driver. And quite a few have thrown out worse ideas such as being able to use Linux drivers, presumably alongside Windows drivers. Well, video drivers would never work that way (Windows video drivers operate in the kernel, not user space like Linux), and there are so many fundamental differences between Linux and Windows drivers.

Well, I don't think you'd just have to add driver APIs, you pretty much have to change the driver compatibility target. Neither the drivers nor the allowed software has any direct bearing on the UI. We have more freedom on the software compatibility side, since our software compatibility engine is being made to provide compatibility in both directions (restrict features for older things and use different .DLLs or whatever with the newer ones).

Zombiedeth
Posts: 100
Joined: Fri Jun 27, 2014 9:01 am

Re: The driver dilemma

Post by Zombiedeth » Wed Aug 15, 2018 6:04 pm

PurpleGurl wrote:
Wed Aug 15, 2018 11:19 am
My loosely proposed system is likely less complex than the alternatives to do similar. Imagine needing some bulky compatibility layer that's emulating the kernel environment for every Windows driver. And quite a few have thrown out worse ideas such as being able to use Linux drivers, presumably alongside Windows drivers. Well, video drivers would never work that way (Windows video drivers operate in the kernel, not user space like Linux), and there are so many fundamental differences between Linux and Windows drivers.
While xp video drivers operate in kernel space vista+ drivers do not they are user space like Linux. The question is it even possible to make a user space video driver work under xp architecture. Would adding the api's be enough to support vista+ drivers?

cb88
Posts: 49
Joined: Fri Oct 06, 2017 3:26 pm

Re: The driver dilemma

Post by cb88 » Wed Aug 15, 2018 7:38 pm

Well you could always just use Mesa3d with a xddm winsys layer.... effectively giving you all the Linux 3d drivers for recent hardware as XP drivers. I think at the very least there are remenants of this in current mesa code though it probably hasn't been tested in ages. You'd still need modesetting drivers though I guess. The problem there is finding someone interested in doing that...

There is probably more to a Vista+ wddm driver... however it should in theory be easier to implement than xddm since larger parts of it are in userspace.

The advantage of finishing porting and creating the modesetting side of things and Mesa3d would mean you'd have a reference XDDM driver that you can fully understand. As far as that goes it may be possible to wrap the Linux modesetting stuff (and a lot of if not all of the Linux graphics stack is MIT licesed even the stuff that is part of the Linux kernel is dual licensed so there shouldn't be any licensing issues).

As far as to the question of WDDM working under XP architecture, No of course not... NT architecture yes but it is inevitable that ReactOS must start adding at least some things from newer releases or there won't be any hardware at all that it will run on.

Zombiedeth
Posts: 100
Joined: Fri Jun 27, 2014 9:01 am

Re: The driver dilemma

Post by Zombiedeth » Wed Aug 15, 2018 9:32 pm

I like the idea of MESA3d winsys Layer too it would be a good long term solution unlike proprietary drivers that microsoft wants to change every few years. The problem is unless there was money on the table i don't think anyone is going to come forward and write the code for it. Maybe something like a community driven fundraiser. I feel like ReactOS is gathering more steam lately so to speak and public sentiment.

PurpleGurl
Posts: 1593
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: The driver dilemma

Post by PurpleGurl » Sat Aug 18, 2018 2:01 am

It isn't just Microsoft who keeps changing the drivers. It is the hardware manufacturers. Sure, Microsoft changes the format, but it is the manufacturers who create the drivers. They could code for more versions, but they've reached a point where they won't. So if you have a Core i9, you'd have to use Windows 10, as Intel won't provide older drivers for it. Intel gives the reason that the chip is tuned to the Windows version, and thus drivers for another target could have unforeseen problems. I'm not sure I'm buying that, or if they're just getting pressure from Microsoft.

As a way around that, I'm sure folks could use reverse cleanroom engineering to get the information like port addresses and other details, and write drivers for older OS targets. Not sure if the CPU, chipset, and EFI would like that, but it might be possible.

And there is one other problem with trying to do open source vs. proprietary drivers, with video cards in mind. A number of newer cards now how safeguards to prevent 3rd party drivers from working. They might have an internal activation key system. So the driver has some secret activation codes or some sort of PGP scheme to unlock the high performance modes. So while 3rd party drivers could get the video card to limp in 640x480-16 mode (we might get it to do 640x480-256 since our "default" driver uses some VESA compatibility tricks), the driver would need to unlock the card to get the higher resolutions and bit depths. And thus not even Linux could do that, as that information is highly proprietary. My guess, as to part of the why, likely has to do with industry pressure to reduce media piracy. The new laws or whatever require that signals cannot be intercepted, which is partly why even the cabling interfaces are different these days. So if you could hack the drivers or use 3rd party ones, you could redirect and record the signal.

cb88
Posts: 49
Joined: Fri Oct 06, 2017 3:26 pm

Re: The driver dilemma

Post by cb88 » Sun Aug 19, 2018 3:25 am

PurpleGurl wrote:
Sat Aug 18, 2018 2:01 am
And there is one other problem with trying to do open source vs. proprietary drivers, with video cards in mind. A number of newer cards now how safeguards to prevent 3rd party drivers from working. They might have an internal activation key system. So the driver has some secret activation codes or some sort of PGP scheme to unlock the high performance modes. So while 3rd party drivers could get the video card to limp in 640x480-16 mode (we might get it to do 640x480-256 since our "default" driver uses some VESA compatibility tricks), the driver would need to unlock the card to get the higher resolutions and bit depths. And thus not even Linux could do that, as that information is highly proprietary. My guess, as to part of the why, likely has to do with industry pressure to reduce media piracy. The new laws or whatever require that signals cannot be intercepted, which is partly why even the cabling interfaces are different these days. So if you could hack the drivers or use 3rd party ones, you could redirect and record the signal.
What? the only companies doing anything like that is NVidia and mobile GPU companies to deter 3rd partry drivers, you can write your own drivers for Intel and AMD hardware all day long, and some very stubborn people (a compliment in this case) continue to reverse engineer NVidia hardware with some sucess. AMD and Intel provide signed firmware blobs for the open source drivers that you just have to upload to the card to boot it up essentially.....

The main thing that holds back NVidia driver development on Linux is actually documentation, which is provided to Mesa developers either openly or with NDA. The mesa driver is sort of living documentation of that hardware also... because it doesn't just run it runs fast and competitively with the closed drivers, and that's better than any documentation writtten or generated by an engineer as that always leaves out important details.

Post Reply

Who is online

Users browsing this forum: karlexceed and 12 guests