Maybe it's timw to pay for some more bandwidtth
Maybe it’s time to talk about a new Linux Display Driver Model
51–60 of 69 posts
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#52Earlier quoted context omitted.
So no endless hours trying to get a config file that wouldn't set the monitor in flames? Because I did spent such hours back with Slackware 2.0.
I started with SLS linux which pre-dated Slackware and I certainly remember the scary warnings. But with a plain-vanilla graphics card and using ordinary settings, it wasn't an issue.
I would get a bare 640x480 resolution without tweaking.
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#53How much of the compositor problems will be fixed by Wayland? I know a big goal of Wayland is to address tearing and corruption.
Anecdotal, but these "compositor problems" are not inherent to Linux or X11. I am extremely sensitive to things like tearing, and I can tell you it simply doesn't occur on my linux machines (though it does require enabling a TearFree X11 option on my intel GPU). Wayland, unfortunately, seems to be the type of project that has been a year or two away from usability since its first release in 2012. I suspect we'll be s…
The open source Radeon driver also does a good job of avoiding tearing. I think there are some pathological cases where it can still occur, but it is pretty rare. Catalyst was terrible at avoiding tearing the last time I used it (getting on to be 3 years ago now). I haven't looked into it, but it is possible that the tearing issue may not be solvable without a KMS driver (i.e. no binary blob drivers can do it).
I used Wayland/Weston for a full work day about a year ago to try it out. It really was very nearly ready. I can't quite remember what problems I ran into, but I could do my work (as a web developer) with very few real problems. Probably it's time to look at it again.
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#54Re: Maybe it’s time to talk about a new Linux Display Driver Model
#55Earlier quoted context omitted.
Depends on what you mean. I've been running Linux for 20+ years and have never had a graphics card that I couldn't get to work. If you're talking about acceleration, there have obviously been issues getting manufacturer support, but as a non-gamer, that mattered little to me.
So no endless hours trying to get a config file that wouldn't set the monitor in flames? Because I did spent such hours back with Slackware 2.0.
Slackware 2.0 was released in August 1994. Even 1.0 (which is probably the first distro to have XFree86) was released in July 1993. I used MCC before that and I don't think X was available (though, to be fair, I can't really remember when I first got X working on my machine). I distinctly remember having to wait until mmap() was implemented before anyone could even think about getting X to work. :-)
It is quite possible that one had to still edit modelines by hand at that time, but it really wasn't long before the modeline db came out and you could just plonk in canned values with a good expectation it would work untouched. Certainly after that time I never had any difficulty. About the only thing I ever did was to follow instructions to modify a couple of numbers for monitors that had bizarre refresh rates.
I think that this would probably fall pretty close to the "20 years ago" time frame (August 1995). Slackware 3.0 came out in November of that year. 2.0 of the kernel came out in 1996 and I'm quite sure that I wasn't spending any time editing modelines then.
If you wanted to get total plug an play without any configuration at all, I think you would have to wait until 2004, when Ubuntu was first released. So while the original statement that it took 10 years to get video drivers working is completely wrong, I think it would be fair to say that it took 10 years to have an equivalent install experience to Windows on that front.
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#56I am currently using 2 displays connected to my graphics card and one connected to my igpu on my Linux desktop at home, and it's really not that hard to set up. Unfortunately the GPU does all the rendering and passes images to the iGPU, but I believe this is the case too with Windows. Also there are a few bugs when using this setup to do with monitor positioning.
Oh. How did you do this? Are you using an NVidia GPU? Does XRandR work? I couldn't get this to work at all, though I was using the closed drivers (since I couldn't find any evidence CUDA works with the open ones). Do you need the open drivers for this? In the end I spent £30 on a second GPU. Problem solved... ish. XRandR still didn't work, and GNOME3 switched to fallback mode, which is basically GNOME2, i.e., a total…
I used xrandr --setprovideroutputsource to set one image provider as the source of the others image.
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#57Earlier quoted context omitted.
Perhaps you would be interested in my project, subuser.org Unfortunately, it does absolutely NOTHING with regard to OpenGL isolation :( (That is if you give programs permission to talk to the graphics card, which is denied by default...)
Neato! Many years back I was playing with Xpra for this, but it was in the days before either Docker or useful seccomp. Glad to see something making progress here. Have you looked at OpenGL virtualization e.g. Virgil ( https://virgil3d.github.io/ , https://www.kraxel.org/blog/tag/virgl/ ) for that problem? The idea is to use Gallium to give them just enough access to get host 3D acceleration, but not direct access to…
Looks interesting. But no, I have not tried it. It isn't really a priority for me. I'm not a gamer, nor am I a climatologist, and while I do use CAD, I've had other, simpler, problems to solve :D
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#58Earlier quoted context omitted.
So no endless hours trying to get a config file that wouldn't set the monitor in flames? Because I did spent such hours back with Slackware 2.0.
Slackware 2.0 was released in August 1994. Even 1.0 (which is probably the first distro to have XFree86) was released in July 1993. I used MCC before that and I don't think X was available (though, to be fair, I can't really remember when I first got X working on my machine). I distinctly remember having to wait until mmap() was implemented before anyone could even think about getting X to work. :-) It is quite possi…
If you wanted basic 2D stuff yeah, then there were the adventures with hardware accelerated 2D and the first batch of 3D accelerator cards, followed by first generations of integrated 2D/3D cards.
It wasn't just getting the monitor refresh rate working.
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#59Still remember the days where one had to compile the kernel to enable sound in doom. The fact that most hardware is supported today is a blessing. And agree with the author. X11 has aging issues.
Or for that matter XFree86 / Xorg and Xlib have aging issues. IMHO the protocol is okay (it's not perfect). Maybe cut away some of the legacy cruft, implement antialiased rendering for core primitives (yes, even if they are just lines, arcs and ellipses, those are still needed even on modern screens; heck with all the flat style UIs currently being all the rage on a HighDPI screen you could probably disable XRender and nobody would notice).
The whole framebuffer handle management of Wayland is a huge step in the right direction, but I despise Wayland's input and inter client communications model; not to say that X11 was anyway better, but whenever I code against Wayland, that part feels just wrong. Also the obsession of the Wayland devs of getting VSync right has its own share of issues (especially for low latency graphics, like you need it for VR).
Re: Maybe it’s time to talk about a new Linux Display Driver Model
#60I am currently using 2 displays connected to my graphics card and one connected to my igpu on my Linux desktop at home, and it's really not that hard to set up. Unfortunately the GPU does all the rendering and passes images to the iGPU, but I believe this is the case too with Windows. Also there are a few bugs when using this setup to do with monitor positioning.
You misread OPs point. He is saying Windows can do both. And vsync across cards. That is quite a feat. If using separate outputs, this is probably achievable on Linux with a bit of work. Also vsync with a compositor shouldn't be impossible. However, if the processing is done on on two graphics cards and we output only on one of them then we need cooperation from the device manufacturers to provide us drivers or imple…
> And vsync across cards. That is quite a feat.
Well, what it does is, that the compositor (DWM) keeps a (small) backlog of presented window framebuffers (think GL SwapBuffers, that add to the queue) and whenever a screen's VSync comes along it blits the most recent picture presented to it. Which has the effect that if you have a window spanning multiple GPUs' outputs they may not all show the same frame, because the display refresh frequencies will beat (even if you set the same refresh frequency on all outputs, since between different GPUs they're not driven by the same clock, you'll get a little bit of clock skew; and video clocks are usually not of the low drift type, because for video it doesn't matter if you're off a few ppm). If you need synchronized video sync vendors are happy to sell you genlock-able cards for $$$.