Live data from Hacker News

Maybe it’s time to talk about a new Linux Display Driver Model

yosoygames.com.ar

1–10 of 69 posts

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#2
I 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.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#6

The thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.

Should be pretty straightforward to fix. I wonder why it isn't. Is someone discussing the issue?

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#7
post #5

The thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.

This is extra fun considering WebGL.

WebGL implementations zero out newly allocated buffers for exactly that reason.

https://www.khronos.org/registry/webgl/specs/latest/1.0/#4

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#8
post #2

I 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 implementation details on how to drive their hardware muxers. Without that info, we're dead in the water.

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#9
post #6

The thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.

Should be pretty straightforward to fix. I wonder why it isn't. Is someone discussing the issue?

[deleted]

Re: Maybe it’s time to talk about a new Linux Display Driver Model

#10
post #6

The thing about being able to read other process memory under Linux has always driven me nuts. Linux is fairly secure _except_ for this one giant gaping hole that nobody mentions.

Should be pretty straightforward to fix. I wonder why it isn't. Is someone discussing the issue?

Knowing nothing about the issue, I speculate many programs have come to depend on the behavior. Similar to antique bugs in x86 that were baked in to the architecture when programmers had to work with them on the 286 & 386. After that they couldn't be fixed because programs depended on the presence of the bug.
Post reply on HN