OSDev.org

Nor does it always make sense to have multiple driver instances for multiple video cards, when they're linked by SLI and drive the output on just one display.

Most replies seem to jump from monitor to video driver, and omit the video card?

I would have a drive instance for each video card. I don't know why SLI would make much of a difference to this, The possibility of mixing models and makes of cards with SLI implies you'd still want a driver instance for each card.

cxzuk wrote:Most replies seem to jump from monitor to video driver, and omit the video card?

I would have a drive instance for each video card. I don't know why SLI would make much of a difference to this, The possibility of mixing models and makes of cards with SLI implies you'd still want a driver instance for each card.

The mixing of SLI video cards is VERY limited. They are run by the same driver instance.

Gigasoft wrote:Except that it doesn't make sense. The OS doesn't even know how many monitor outputs there are, only the video driver knows. Once the video driver "detects" a monitor output, what driver should be loaded and what would be the purpose of such a driver? Should it load more copies of itself? Which one would be responsible for managing VRAM and issuing commands to the card? What would the others be doing?

The operating system would need to identify the logically distinct devices which occur on the PCI, ISA and USB busses. Then it would need to have a way of tying together particular keyboards to particular monitors. Of course, it would have no guarantee that a monitor was actually plugged in to a video card, or that it was switched on. That is just an assumption that it would have to make.

The kernel or boot loader can "know" anything a driver can "know". Probably more. My name isn't Microsoft, so nobody is going to be writing proprietary drivers with hard coded "knowledge" for my system.

The good thing is that you can't have false positives with connected monitors: if it responds to DDI you know it's connected. if it's not connected, the result is obvious. Several monitors don't respond when unpowered, but finding a monitor these days that doesn't respond at all is rare.

Brendan wrote: Multiple user, single monitor, single video card (split screen?):

Code: Select all

                                _________      _____      _______
                               |         |    |     |    |       |
   _________      ________     | Virtual |----| GUI |----| App/s |
  |         |    |        |----| Console |    |_____|    |_______|
  | Monitor |----| Video  |    |_________|
  |_________|    | Driver |     _________      _____      _______
                 |________|----|         |    |     |    |       |
                               | Virtual |----| GUI |----| App/s |
                               | Console |    |_____|    |_______|
                               |_________|

Of course more bizarre setups could be possible - e.g. 3 users sharing 4 monitors (with 1.33 monitors each). Mostly; each video card would provide an interface for each (real or virtual) monitor, and you only really need a flexible way to map "monitor interfaces" (and keyboard, mouse, joystick, touchscreen) to virtual consoles.


Cheers,

Brendan

I wouldn't even try to cater for the last one. The line has to be drawn somewhere, unless you have 6 million lines of code to spare.

The line has to be drawn somewhere,

Horizontally or vertically?

Splitscreen has been used in many games, so it must have some merit, no?

Combuster wrote:

The line has to be drawn somewhere,

Horizontally or vertically?

Splitscreen has been used in many games, so it must have some merit, no?

If I was doing this as a money making project, rather than a hobby, then I would have to think about the market segment I was aiming at. And, if I was really really intent upon making money, trying to dethrone Windows as the world's general purpose (and game playing) operating system, probably would not be the wisest course of action.

Hi,

mathematician wrote:

Brendan wrote:Multiple user, single monitor, single video card (split screen?):

I wouldn't even try to cater for the last one. The line has to be drawn somewhere, unless you have 6 million lines of code to spare.

Realistically; this is likely to be the first "multi-user" variation an OS is able to support; because it can be done on top of a plain framebuffer (before the OS has any native video drivers) and can be tested in emulators.


Cheers,

Brendan

mathematician wrote:I wonder whether anybody has toyed with the idea of writing a multi user OS for the PC. Modern base units ought to be easily capable of supporting at least two users. I am not asking whether there is a demand for such a thing (although it might be cheaper than two complete systems), but just whether it could be done just for the hell of it. Apart from pairing off keyboards with monitors, to form "dumb terminals", I can't see any obvious problems.

All major OSes for the PC are multi-user. Solaris, *BSD, Linux, etc. (I'd say Windows but they crippled the non-enterprise versions). So what I'm talking about is multiple users can SSH in and run commands while you are talking about two or more people sitting at the same PC but think about it, what is the difference? The difference is how input and output are handled. Can we eliminate the difference between local and network input/display (within reason)? Maybe if you abstract the input/output handling to a network protocol (maybe rewrite it eleven times) - we'll give it a name like X11 for giggles. Physically local users would each get their own X server (either one per video card or even nested X servers for split screen action). Remote users could have a very low power device that only handles running an X server (think raspberry PI).

The common term for a multiple physical user configuration is https://en.wikipedia.org/wiki/Multiseat_configuration. You can find docs on how to set it up for most distros - https://help.ubuntu.com/community/MultiseatX